[08:19] <SlimG> Does /quit
[08:36] <lordievader> Good morning
[08:41] <cpaelzer> hi lordievader
[08:41] <lordievader> Hey cpaelzer
[08:41] <lordievader> How are you doing?
[08:41] <cpaelzer> as good as always (means I'm good but prefer to complain most of the time)
[08:41] <cpaelzer> and you?
[08:43] <lordievader> I'm dutch, we like to complain all the time. I.e. I'm doing good 😉
[08:44] <cpaelzer> \o/
[09:59] <cpaelzer> jamespage: any ETA on https://code.launchpad.net/~paelzer/ubuntu/+source/nova/+git/nova/+merge/324778
[10:00] <cpaelzer> jamespage: I'm ok rejecting the MP and saying do it in 18.04 - but I start with more real (no prep) libvirt work and really want to get bug 1694159 done
[10:00] <ubottu> bug 1694159 in nova (Ubuntu) "Complete libvirt migration to Debian style packaging (dependencies, conffiles)" [Critical,Triaged] https://launchpad.net/bugs/1694159
[10:00] <cpaelzer> as you are "the last one left" I raised the importance
[10:01] <cpaelzer> let me know what you expect when this minor change could land
[10:01] <cpaelzer> I don't mind if it is bundled with your actual nova upload or not :-)
[11:30] <jamespage> cpaelzer: forgot will merge into master branch today
[11:34] <jamespage> cpaelzer: done - I'll include it with the next upload to bionic
[11:36] <jamespage> cpaelzer: follow up on that one - whats the actual name of the systemd unit for libvirt these days? I need to tweak the depends for the nova-compute service to align with any changed
[11:37] <cpaelzer> libvirtd
[11:37] <cpaelzer> I'll keep the libvirt-bin alias into 18.04 for safety
[11:37] <cpaelzer> for the service
[11:38] <cpaelzer> but want to drop the deps
[11:38] <cpaelzer> as then I can finally clean up all remainders of that in 18.10
[11:38] <cpaelzer> thanks for the reply jamespage
[11:38] <cpaelzer> will that upload include the bug, so I'll see a ping on that when I'm subscribed?
[11:39] <cpaelzer> usually it would, but I admit nova is complex enough that there might be reasons not to :-)
[11:42] <jamespage> cpaelzer: yes
[11:43] <cpaelzer> thx
[14:08] <rh10> guys, what differencies between ubuntu desktop and ubuntu server? if i switch off xorg in ubuntu desktop, install needed packages e.g. LAMP - is it the same as ubuntu server?
[14:09] <rh10> or they have different kernels?
[14:09] <rh10> i mean 16.04
[14:09] <Ussat> Same kernel, when it comes down to it, the difference is packages installed, at their core, Linux is Linux
[14:10] <rh10> Ussat, got it thanks
[14:10] <Ussat> Server by default does not have a GUI, workstation does, etc...
[14:10] <rh10> yep. got it,
[14:10] <Ussat> I have both here, as well as RHEL
[14:16] <cpaelzer> rh10: default network management might be different, so switching of x11 isn't all
[14:17] <cpaelzer> rh10: in general better start minimal on what you actually want and then add
[14:17] <rh10> cpaelzer, got it
[14:17] <cpaelzer> you can just as well install -desktop meta package on a -server install
[14:17] <cpaelzer> e.g. I do that on NAS if upgrading to htpc with it
[14:17] <rh10> thanks
[14:34] <zioproto> hello all
[14:34] <zioproto> I have a "not Openstack" question today :D
[14:35] <zioproto> We run our datacenter with IPv6, and we found our Kernel suffers from a bug, that is fixed by this patch https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bbfcd77631573ac4a9f57eb6169e04256a111bc1
[14:35] <Ussat> Yea I always start minimal and add what I need also
[14:35] <zioproto> The patches is merged in 4.15, but our Xenial servers are running 4.4. I rebuilt the 4.4 kernel patching with this patch, and I can confirm it fixes the IPv6 networking issue
[14:36] <zioproto> now, what is the best way to deploy the fix to my Xenial hosts ?
[14:36] <zioproto> Should I open a bug on launchpad against the Kernel package, and give a pointer to that patch ? hoping in a backport to the Xenial stable kernel ?
[14:36] <zioproto> Should I just starting using my own deb kernel packages ?
[14:40] <zioproto> should I open the bug here ? https://launchpad.net/~ubuntu-kernel or there is a better place ?
[14:42] <sdeziel> zioproto: this patch should be backported to stable kernels. I'd flag the kernel team that you need this on 4.4
[14:42] <sdeziel> zioproto: better have it fixed for everyone and save you the trouble of rolling your own kernel .deb ;)
[14:49] <Jeffrey4l> is any UCA guys could check and fix this issue? https://bugs.launchpad.net/cloud-archive/+bug/1738213
[14:49] <ubottu> Launchpad bug 1738213 in Ubuntu Cloud Archive "in pike release, UCA changed the nova code and break the old qemu binary" [Undecided,Confirmed]
[14:55] <zioproto> sdeziel: OK. How do I flag the Kernel team ? can you give me an URL where to submit the bug ?
[14:55] <zioproto> sdeziel: thanks
[14:56] <sdeziel> zioproto: I'd use: ubuntu-bug linux-image-$(uname -r)
[14:58] <cpaelzer> Jeffrey4l: that is not really a supported case
[14:58] <cpaelzer> the code in the UCA nova is tied to the versions in the UCA
[14:58] <cpaelzer> Without that particular change it would not work with qemu >=2.9
[14:59] <Jeffrey4l> cpaelzer, yes. but nova support all version of qemu. just bump the nova version please :(
[14:59] <cpaelzer> I'm no UCA person, but the nova version in each release is kind of fixed, except bug-fixes
[15:00] <cpaelzer> Jeffrey4l: if there is an upstream commit that makes this work with both old and new please link it
[15:00] <cpaelzer> they might integrate this to help cases like yours
[15:00] <cpaelzer> E.g. via a version or capability check before setting the option
[15:00] <Jeffrey4l> cpaelzer, nova UCA compile qemu with ceph Luminous, which is bad. we just want to pin ceph version. But it result in pin the qemu version too.
[15:00] <cpaelzer> you need someone else to sort this out
[15:01] <cpaelzer> jamespage: coreycb: ^^
[15:01] <Jeffrey4l> thanks. ping other guys. ( no familiar with this channel ;) )
[15:02] <Jeffrey4l> just one line fix. i think it is worth to merged into UCA from upstream.
[15:02] <zioproto> sdeziel: I am not sure I got it... is there a specific Launchpad project I should use to open the bug ?
[15:03] <zioproto> https://launchpad.net/~ubuntu-kernel-team ?
[15:03] <jamespage> Jeffrey4l: 16.0.3 is in proposed and drops the use of that distro specific patch in favor of the upstream fix
[15:04] <sdeziel> zioproto: "ubuntu-bug" is a command that will automatically figure out how to open the bug on Launchpad based on the package your report as buggy
[15:04] <Jeffrey4l> thanks is there any plan that when 16.0.3 will be the final(?) repo?
[15:04] <Jeffrey4l> jamespage, ^^
[15:05] <jamespage> Jeffrey4l: watch this bug - https://bugs.launchpad.net/ubuntu/artful/+source/nova/+bug/1734990
[15:05] <ubottu> Launchpad bug 1734990 in nova (Ubuntu Artful) " [SRU] pike stable releases" [Undecided,Fix committed]
[15:06] <Jeffrey4l> cool.
[15:06] <jamespage> coreycb completed verification yesterday - nothing is blocking that for release so it should go out rsn
[15:07] <Jeffrey4l> got. thanks.
[15:07] <jamespage> Jeffrey4l: fwiw using UCA pockets in a mixed mode like this is not tested by the Ubuntu team
[15:08] <jamespage> you're either in or out
[15:08] <jamespage> ;)
[15:08] <Jeffrey4l> understand. but we have to pin ceph to Jewel. ;( no other better solution right now ;(
[15:20] <jamespage> Jeffrey4l: is the context here kolla?
[15:21] <zioproto> I opened the bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1738219
[15:21] <ubottu> Launchpad bug 1738219 in linux (Ubuntu) "the kernel is blackholing IPv6 packets to linkdown nexthops" [Undecided,New]
[15:21] <Jeffrey4l> jamespage, yes.
[15:21] <jamespage> Jeffrey4l: and why do you need to pin to jewel? is that image build or deployment problems?
[15:21] <Jeffrey4l> jamespage, during the pike release, it is too late to implement this.
[15:22] <necrophcodr> I've had some trouble with grub, and now I have grub-mkdevicemap processes from 2016 still running. They do not respond to `kill -9`. How do I solve this without rebooting?
[15:23] <Jeffrey4l> and ceph Lunimous is just released. at that time. very new version, and no time to test it. and centos is not support Lunimous at that time.
[15:23] <metastable> necrophcodr: Can you paste an example process?
[15:23] <Jeffrey4l> so we do not bump to Luminous
[15:23] <sdeziel> zioproto: thanks. You tested with 4.4.0-21 but that's terribly old. We are at 4.4.0-103 ATM so maybe you'd like to retest with a fresher 4.4 kernel?
[15:23] <necrophcodr> metastable: you mean output from `ps aux` or what?
[15:23] <metastable> necrophcodr: Yes.
[15:24] <necrophcodr> metastable: root        6265  0.0  0.0  40744  2640 ?        D     2016   0:00 grub-mkdevicemap -m -
[15:25] <metastable> necrophcodr: It's in an uninterruptable wait state. Rebooting is your only option, they won't respond to any signals.
[15:25] <necrophcodr> if i reboot the system won't start again, so that'll suck a bit.
[15:26] <necrophcodr> you're 100% sure there are no other options?
[15:26] <jamespage> Jeffrey4l: ack - we don't often have to hold a distro patch like that one but sometimes is happens; we have to make assurances about the compatibility of pkgs within a UCA pocket
[15:26] <metastable> necrophcodr: Yes.
[15:26] <metastable> necrophcodr: Either it gets what it's waiting for (since 2016), or the system reboots. That's it.
[15:27] <jamespage> coreycb: bumpped gnocchiclient to 6.0.0 - needed for ceilometer/gnocchi stuff
[15:27] <jamespage> glad I shoved in that snapshot :-)
[15:27] <coreycb> jamespage: ok. agreed :)
[15:27] <Jeffrey4l> curiosity but no idea why qemu in UCA depends on the ceph version. in centos, it's qemu support ceph Jewel and Luminous. ( in fact, they are in the different repo ) jamespage
[15:29] <jamespage> Jeffrey4l: well qemu gets built against the ceph/librbd version in the UCA - as to why that does not support use with Jewel for the Pike UCA I'm not sure
[15:29] <jamespage> librbd should be backwards compatible I think
[15:30] <Jeffrey4l> yes. i think so. than i guess we can change the qemu dependency. maybe it works.
[15:30] <jamespage> Depends: libc6 (>= 2.14), libcurl3-gnutls (>= 7.16.3), libglib2.0-0 (>= 2.24.0), libiscsi2 (>= 1.10.0), librados2 (>= 0.72.2), librbd1 (>= 12.0.3)
[15:31] <jamespage> note the last versioned depends; thats automatically generated based on symbols used
[15:31] <jamespage> but I still think it should be backwards compatible i.e. librbd1@12.2.x should work with Ceph Jewel
[15:32] <Jeffrey4l> let me search the dependency in centos.
[15:32] <jamespage> but maybe its the other way around - librbd1@10.2.x is forward compatible with ceph luminous
[15:32] <jamespage> providing that upgrade capability
[15:32] <Jeffrey4l> i think librdb1 can be >= 10.x.x, then if librbd1 10 is install, the whole ceph jewel will be installed.
[15:33] <jamespage> I'd hope not :-)
[15:33] <zioproto> sdeziel: I will. But I downloaded the sources with apt-get source linux-image-$(uname -r) on a machine where I have 4.4.0-103-generic. And when I finished compiling those packages came out
[15:33] <jamespage> ceph depends on librbd1
[15:33] <zioproto> sdeziel: I guess I did something wrong when compiling the kernel
[15:33] <zioproto> sdeziel: https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
[15:34] <cpaelzer> Jeffrey4l: librbd1 definetly doesn't bring all of ceph from the archive
[15:34] <sdeziel> zioproto: what I meant to say was to test with 4.4.0-103 as it's possible it has the commit already *maybe*
[15:35] <zioproto> sdeziel: found the problem with my apt.list
[15:35] <zioproto> deb-src were not good
[15:35] <zioproto> building new kernel now
[15:36] <cpaelzer> as jamespage says, the dep is vice versa ceph-common would depend librbd1 (= 12.2.1-0ubuntu1)
[15:37] <Jeffrey4l> in the centos , qemu-kvm depends on  librbd1.x86_64 1:0.94.5-2.el7
[15:37] <Jeffrey4l> so it works with ceph jewel and luminous.
[15:37] <cpaelzer> but that is qemu 1.5 or such isn't it ?
[15:38] <Jeffrey4l> oh wait. i am wrong. hold on.
[15:38] <Jeffrey4l> cpaelzer, nothing is wrong. i am installing "qemu-kvm-ev" actually, and its version is 2.9.0
[15:39] <cpaelzer> ok
[15:40] <zioproto> sdeziel: the bug is in Incomplete. But this is a bug that does not have log files. Also, the bug is confirmed and fixed in the upstream kernel. What should I do ?
[15:40] <Jeffrey4l> after installed "centos-release-ceph-lunimous" repo, when install qemu-kvm-ev, it will install librbd1.x86_64 2:12.2.1-0.el7
[15:40] <Jeffrey4l> so i guess librbd is compatible.
[15:40] <zioproto> sdeziel: I was able to mark it as Confirmed my self :O
[15:41] <cpaelzer> Also https://www.rpmfind.net/linux/rpm2html/search.php?query=librbd.so.1()(64bit) suggests that the 0.94 dependency is since this is what is in CentOs atm
[15:42] <sdeziel> zioproto: ubuntu-bug should have attached some information to the bug. In your case there are no logs of course
[15:42] <zioproto> ok
[15:43] <sdeziel> zioproto: you may want to hop on #ubuntu-kernel and ask for some instructions
[15:50] <zioproto> ok
[17:38] <jamespage> coreycb: some setuptools fun in the queens uca - patched out the offending dep change
[17:38] <jamespage> in ca-patches
[18:15] <lucidguy> Openstack users?
[18:36] <boxrick> Is there any way to supress any ntp messages in preseed?
[18:37] <boxrick> Not NTP, Namerserver
[18:37] <boxrick> nameserver*
[18:37] <boxrick> My DHCP server doesn't assign any DNS right now, and I want Ubuntu to carry on and suppress its warning
[18:37] <boxrick> Any tips?
[18:44] <metastable> boxrick: I'm interested in your use case, there. What's the reason to not hand out DNS with DHCP?
[18:47] <boxrick> Because its early in the bootstrap process and DNS simply doesn't exist yet
[18:47] <boxrick> Everything is done via IP through a proxy
[20:44] <DevilTiger> my fresh install keeps pulling a WAN IP instead of a local IP from my router's DHCP. am i missing something?
[20:49] <metastable> That sounds like something's bridged to something that's intended to be upstream from the router.
[20:49] <metastable> I'd suggest confirming that everything's connected where it ought to be.
[20:50] <DevilTiger> its running inside hyper-v on windows 10 which is connected to the switch->router
[20:51] <sarnold> or something is configured to be in bridge mode when you expected NAT mode or something simlar?
[20:52] <DevilTiger> i'm not sure
=== keithzg_ is now known as keithzg
[21:40] <Neo3> hi
[21:40] <Neo3> Who know how work internet?
[21:40] <sarnold> it's a series of tubes .. it's not a like a truck.
[21:40]  * sarnold nods
[21:40] <Neo3> I can access my site using domain name and IP?
[21:41] <TJ-> sarnold: yours is tubes? Mine is box-section :)
[21:41] <Neo3> why? Where DNS server? It resides between me and my server?
[21:41] <sarnold> Neo3: every domain needs two or more DNS servers online, so that clients can figure out the IP address to use when asked to connect to a given name
[21:42] <Neo3> if I use ip I'm bypassing DNS?
[21:42] <sarnold> Neo3: if you're asking the question, then you absolutely do not want to run your own DNS servers. Probably your domain registrar or your hosting company can run them for you. If not, there are commercial service providers who can run them for you.
[21:42] <Neo3> seems yes
[21:43] <Neo3> I use digitalocean, just I'm interesting how it works
[21:43] <Neo3> in internet exists many DNS servers?
[21:44] <sarnold> probably millions
[21:44] <Neo3> where placed DNS servers? It's some big key server that is redirect requests to servers with ip?
[21:44] <Neo3> and see I have domain name, I put it to browser and browser send request to DNS server yes?
[21:45] <sarnold> there's a few hundred 'root' dns servers that serve the top level '.' domain. They know the addresses of DNS servers running the .com., .org., .net., .io., etc domains
[21:45] <metastable> I'm struggling to understand the scope of the actual problem we're trying to address, here.
[21:45] <sarnold> those DNS servers know the address of example.org. dns servers
[21:45] <Neo3> then DNS server says my browser my real IP and my browser send request to my real IP?
[21:45] <sarnold> and the example.org. dns servers know the address of www.example.org., etc
[21:46] <sarnold> your browser contacts a "recursive resolver" dns server run by your ISP
[21:46] <sarnold> that server will contact the roots, the TLD servers, etc. on down the chain, and give you a single result
[21:46] <metastable> Or on your router, which is a more common home configuration.
[21:46] <sarnold> this diagram may help a bit http://dnsviz.net/d/www.ubuntu.com/dnssec/
[21:47] <TJ-> Neo3: "How does the Internet Work?" see the diagrams and explanation in section 7 for DNS: http://www.theshulers.com/whitepapers/internet_whitepaper/index.html#dns
[21:47] <Neo3> well, thanks! I've saved those link, will read later
[21:48] <sarnold> TJ-: beautiful example.
[21:48] <sarnold> Neo3: ignore more, TJ-'s link is better :)
[21:49] <Neo3> this is better? http://prntscr.com/hnmgz6
[21:49] <JanC> most routers don't run a recursive resolver
[21:49] <sarnold> yeah
[21:49] <sarnold> that whole page looks good
[21:49] <metastable> JanC: Most home routers in fact do. Their default configuration is to pass itself as the DNS entry via DHCP, and perform resolution on behalf of LAN clients.
[21:50] <Neo3> ok, there many diagrams and info. will read later
[21:50] <sarnold> metastable: most are just forwarders, they ask the ISP-provided recursors..
[21:50] <JanC> and they forward everything to the DNS from the ISP
[21:50] <JanC> basically, those routers run dnsmasq or the like
[21:51] <JanC> or something similar
[21:51] <metastable> Doh, yeah. For some reason, I'm treating those as the same thing.
[21:51] <metastable> Which is wrong, so yeah.
[21:51] <sarnold> depends if you're trying to fix a problem with them or not :) hehe
[21:52] <JanC> if you have some open source router firmware it might be possible to run a recursive resolver though
[21:52] <JanC> (and some NAS devices have them as an option too)
[21:52] <sarnold> or run a recursive server on a different machine on the lan, it doesn't have to be the router
=== jc is now known as danrik
[22:09] <danrik> why all examples online re ubuntu 16.04 & varnish say that varnish service is located in `/etc/systemd/system/varnish.service`, but on my suystem it's under /etc/init.d....
[22:13] <TJ-> danrik: It's actually at /lib/systemd/system/varnish.service
[22:13] <danrik> ah ok. thx
[22:14] <TJ-> danrik: You can use "dpkg -L varnish" to see all the files in the package, and where they live