=== mikal_ is now known as mikal
=== IdleOne- is now known as IdleOne
[01:54] <roaksoax> win 4
=== magicalChicken_ is now known as magicalChicken
[05:00] <caliculk> I have a ubuntu machine, that whenever the primary router restarts, the network interface never comes back up on the ubuntu server. I have a crash log, but am unable to switch kernels (mainly due to lack of out of band management/ipmi). I have the crash log here: http://pastebin.com/0jb8VxJN but was wondering if anyone had any other suggestions.
[05:36] <sarnold> caliculk: you could also try linux-lts-wily or linux-lts-xenial kernels, too; it might have been fixed upstream in the meantime, too
=== trochej is now known as madwizard
[08:01] <jamespage> coreycb, pushed microversion-parse to git, uploaded to unstable  - I see you shoved it in the PPA already
[08:01] <jamespage> coreycb, so pushed relevant changes to nova master packaging branch as well
[08:24] <sivir> sudo dnf install p7zip
[08:46] <EmilienM> jamespage: hi, we'll need this backport in ceilometer: https://review.openstack.org/#/c/318503/ otherwise it's impossible to run tempest against Ceilometer Mitaka (see commit message)
[08:50] <EmilienM> jamespage: do you think it's possible?
[08:51] <jamespage> EmilienM, is there an associated bug for that?
[08:52] <jamespage> EmilienM, and do the ceilometer team plan a point release anytime soon?
[08:52] <EmilienM> jamespage: I don't know
[08:53] <EmilienM> maybe we can ask on #openstack-telemetry
[08:59] <jamespage> EmilienM, I'd not put that through the SRU process individually, so really it would be nice to get a ceilometer point release made including other things
[08:59]  * jamespage looks to see what's been added since mitaka release.
[09:01] <jamespage> hmm only two fixes so far - one for a gate break and the other is some re-alignment only
[09:05] <EmilienM> jamespage: in the meantime, I'm trying to revert https://review.openstack.org/#/c/318519/
[09:05] <EmilienM> jamespage: because the problem is also in Liberty
[09:21] <sobersabre> hi. I want to add a machine to AD domain. I've tried using SSSD instructions: https://help.ubuntu.com/lts/serverguide/sssd-ad.html
[09:22] <sobersabre> And I think this one is a bit too simplistic. even though my setup is not complicated.
[09:31] <cpaelzer> nacc: is the section sobersabre reports here part of what you rewrote for the updated serverguide?
[09:32] <cpaelzer> nacc: is this even the new content already?
[09:33] <cpaelzer> sobersabre: while he (nacc) isn't here yet could you describe a bit what more or less compelx steps would be missing?
[09:33] <cpaelzer> sobersabre: or was that just a general statement of it being too simplistic?
[10:00] <halvors1> Where could i add a network script?
[10:00] <halvors1> I need to add a VTI interface, but because ifupdown is massivly lacking support for stuff like that, i need to do this using iproute2.
[10:02] <halvors1> Is there a ny good way to add a persistent iproute2 interface in Ubuntu?
[10:15] <sobersabre> cpaelzer: the problem is that sssd is hiding (naturally) most of subsystems of AD, so it would be very helpful to have tests for those subsystems, namely - ntpd, nmbd, smbd, krb and their integrations
[10:16] <sobersabre> I mean, I did all, and after joining the domain users don't show in getent passwd or getent group
[10:17] <sobersabre> There is a lot that could've gone wrong, and I'm now digging the logs.
[10:17] <sobersabre> I did similar flow with centos/fedora and it worked well. I don't know what goes wrong here exactly.
[10:17] <sobersabre> cpaelzer: ^^^ you here, aye?
[10:25] <cpaelzer> sobersabre: yes, still here
[10:25] <sobersabre> well, cpaelzer the howto didn't work :-]
[10:25] <cpaelzer> sobersabre: was at lunch for a few :-)
[10:25] <sobersabre> yep, people eat.
[10:26] <cpaelzer> sobersabre: I get with tests you mean kind of verification steps for each of those things so that one can track down if/where things fail
[10:38] <rbasak> jamespage: bug 1331630 is one for you I think? jgrimm: did this get missed from your subscription rearrangement?
=== Boltermor is now known as Guest38878
=== JanC is now known as Guest23785
=== JanC_ is now known as JanC
[11:45] <Black-Ridder> hi :)
[11:46] <Black-Ridder> i'm a student and i've to make a server with bind9 an apache2, so i made it, but there is a little think that i don't understand
[11:47] <Black-Ridder> can someone help me please?
[11:47] <hateball> !help | Black-Ridder
[11:47] <hateball> mhm.
[11:49] <Black-Ridder> hateball : it's about virtual hosts
[11:49] <Black-Ridder> i've a server with differents website hosted
[11:49] <Black-Ridder> toto.com, tata.com (for example lol)
[11:50] <Black-Ridder> so in my bind9 server i've made a "zone" named ServerTestEcole.com.
[11:51] <Black-Ridder> but i can't link toto.com, tata.com etc
[11:52] <Black-Ridder> when i wrote www.toto.com i go to the default site of apache :'(
[11:54] <Black-Ridder> hateball : can you help me?
[11:54] <hateball> Black-Ridder: Not quite sure I understand it all, but perhaps someone else does
[11:54] <hateball> Be patient :)
[11:55] <Black-Ridder> okay thanks
[11:55] <Black-Ridder> is it my sentenses?
[11:56] <Black-Ridder> i'm from belgium so i probably make some error in my sentenses, sorry :p
[11:56] <hateball> well you need to configure apaches various sites to show you different things depending on what url used to reach it
[11:58] <Black-Ridder> yes
[12:00] <Black-Ridder> with apache's virtual host you can had many website on the same server (1website = 1 address; www.toto.com, www.tata.com,.. etc)
[12:01] <Black-Ridder> so in my link they explain how to do it with apache2 but they don't explain the bind9'part of the configuration :/
[12:39] <jgrimm> rbasak, i'll add suds to the list of things that should move to openstack.  i'm not done auditing the full server list yet for places where openstack isn't yet subscribed.
[12:40] <rbasak> jgrimm: OK
[12:55] <jamespage> EmilienM, hey - not sure what the puppet module for ceph does but https://review.openstack.org/#/c/318612/ is something to be aware of
[12:55] <jamespage> that changed between final rc and release of ceph jewel
[12:57] <EmilienM> jamespage: oh nice! we have some troubles to make it work, I'm sure this link will help
[12:57] <EmilienM> jamespage: thanks a lot for that
[12:58] <jamespage> EmilienM, np - it only effect use of OSD's on things other than xfs
[12:58] <jamespage> so we saw impact on zfs and ext4
[12:58] <EmilienM> jamespage: yeah OpenStack Infra is providing nodes with ext4 and we have issues
[12:58] <EmilienM> cool
[12:58] <EmilienM> thx for sharing that
[12:58] <jamespage> EmilienM, you are welcome
[13:00] <jamespage> coreycb, one patch away from newton/nova being functional  https://review.openstack.org/#/c/318568/
[13:01] <coreycb> jamespage, \o/
[13:02] <rbasak> nacc: o/
[13:04] <frickler> can anyone successfully run an yakkety cloud image? I'm stuck without networking even after 20 minutes: http://paste.ubuntu.com/16506150/
[13:04] <EmilienM> jamespage: did you see the logs yesterday about SSL?
[13:05] <jamespage> EmilienM, I did but I don't have an answer as to why its not working
[13:06] <jamespage> EmilienM, all I can think is that the nature of the cert you add to the ca-certifacates file means that its still not trusted - but I'm not 100% sure
[13:06] <EmilienM> jamespage: http://logs.openstack.org/30/308530/18/experimental/gate-puppet-openstack-integration-3-scenario002-tempest-ubuntu-xenial/e17a5b4/console.html#_2016-05-18_15_26_13_161
[13:06] <EmilienM> ok
[13:06] <jamespage> EmilienM, Replacing debian:puppet_openstack.pem
[13:06] <jamespage> yeah got that
[13:06] <EmilienM> ok I'll try with another cert
[13:06] <jamespage> so we can see it being added, but for some reason the clients are still not trusting it
[13:06] <EmilienM> thx
[13:07] <jamespage> EmilienM, the testing I did was a little different - I installed the cert for the private CA we setup, not the cert for each of the services...
[13:07] <rbasak> Odd_Bloke: see frickler's question above
[13:07] <jamespage> EmilienM, it would be handy to run something over that to see why - maybe openssl has a 'figure out trusted-ness' type thing?
[13:08] <jamespage> as I think that's what python actually uses for the verfication
[13:08] <EmilienM> jamespage: yeah, I would investigate that
[13:09] <jamespage> EmilienM, openssl s_client -connect 127.0.0.1:5000 might tell you more
[13:10] <EmilienM> I need to reproduce all of that in a VM
[13:10] <EmilienM> degorenko: ^ FYI
[13:10] <degorenko> EmilienM, i have VM with my 15 patch set, without ssl, but i'll deploy latest for you :)
[13:12] <jamespage> EmilienM, yup
[13:12] <jamespage> tested against my deploy - verified OK with the CA cert installed for me
[13:13] <Odd_Bloke> frickler: I have run one, but it did take ~7 minutes to get networking; I expect you're seeing https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1577844.
[13:13] <Odd_Bloke> rbasak: (Thanks!)
[13:14] <jamespage> EmilienM, for example http://paste.ubuntu.com/16506393/
[13:14] <EmilienM> ok
[13:14] <Odd_Bloke> frickler: Does xenial work for you?
[13:15] <jamespage> EmilienM, that will at least give you more information about what's not working properly
[13:16] <halvors1> Hi.
[13:17] <halvors1> I want to add a tunnel using the "ip -6 tunnel add" command of iproute2, but i want it to be persistent so that it is loaded at boottime.
[13:17] <halvors1> How can i do this in ubuntu?
[13:21] <EmilienM> jamespage: ok we'll investigate, thanks again for your help
[13:21] <jgrimm> rbasak, billard can possibly be demoted?  i think it had been drug in as dependency for celeryd & friends at some point, but they've been demoted since.  for consideration.
[13:22] <jgrimm> rbasak, noticed this while doing my package audit
[13:22] <rbasak> jgrimm: billard?
[13:23] <jgrimm> rbasak, https://launchpad.net/ubuntu/+source/billiard
[13:26] <rbasak> jgrimm: looks like it's seeded only by the development seed now: http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.yakkety/view/head:/development#L62
[13:27] <rbasak> jgrimm: so up to Foundations I guess? They should have the bug subscription or demote it I think.
[13:38] <frickler> Odd_Bloke: xenial runs fine, yes
[13:46] <halvors1> Is network interfaces handled by systemd or ifupdown in ubuntu 16.04?
[13:49] <frickler> halvors1: should still be ifupdown by default, but you can enable systemd-networkd.service if you want to have that
[13:50] <frickler> Odd_Bloke: well, there is one issue for Xenial, the ensX names are non-predictable and may get changed after a reboot
[13:50] <Odd_Bloke> frickler: Hmm, that's definitely a bug.
[13:50] <Odd_Bloke> smoser: rharper: ^
[13:52] <frickler> start with one interface: ens3, add a second via "nova interface-attach": ens7, do a "nova reboot": get ens3+ens4 instead
[13:54] <jamespage> coreycb, added manila to mitaka and newton ci
[13:55] <coreycb> jamespage, thanks.  I'm taking a look at the neutron liberty failure.
[13:55] <jamespage> coreycb, okies
[13:55] <jamespage> coreycb, ostestr might be a good first change
[13:55] <jamespage> the wily failure looks like bad mocking to me
[13:55] <jamespage> chance that it passed on trusty...
[13:55] <coreycb> jamespage, yep!
[14:01] <halvors1> Um. Someone said something but my IRC client crashed.
[14:02] <halvors1> Can you please repeat? :)
[14:02] <frickler> halvors1: should still be ifupdown by default, but you can enable systemd-networkd.service if you want to have that
[14:09] <halvors1> Ah ok.
[14:09] <halvors1> frickler: Is it possible to use both?
[14:13] <frickler> halvors1: maybe it is, but I don't think that that would be really stable
=== deadnull is now known as _deadnull
=== _deadnull is now known as deadnull
=== deadnull is now known as _deadnull
=== _deadnull is now known as deadnull
[14:29] <smoser> frickler, that is very odd.  cloud-init is trying (which needs improvements) to make sure that ens3 good, but the second attached nic should also be stable in name.
=== skeezix-hf is now known as PaulHarvey
=== PaulHarvey is now known as skeezix-hf
[14:36] <jamespage> frickler, hey - thanks for the quality of your bug reports btw - much appreciated...
[14:38] <frickler> smoser: it isn't, when nova recreates the libvirt.xml, the order of pci slots may change. it even gets fancier if you also attach and detach volumes
[14:41] <frickler> smoser: I would think going back to using ethX for cloud instances would be much more sensible. Like special case this for Virtio network devices maybe
[14:43] <degorenko> jamespage, hey, about checking ssl, my output on vm for openssl s_client command:http://paste.openstack.org/show/497729/ i have not experience with ssl. May be it can help you somehow
[14:44] <degorenko> and also i see this error: 2016-05-19 14:43:45.106 30584 ERROR oslo.messaging._drivers.impl_rabbit [req-2198cd2f-e791-47c9-ad41-d064f25750cb - - - - -] AMQP server on 127.0.0.1:5671 is unreachable: [SSL: TLSV1_ALERT_INSUFFICIENT_SECURITY] tlsv1 alert insufficient security (_ssl.c:590).
[14:44] <sdeziel> frickler: special casing virtio NICs only would miss the SR-IOV one
[14:44] <jamespage> degorenko, that's something quite different...
[14:45] <degorenko> EmilienM, fyi ^
[14:45] <jamespage> degorenko, but your first paste lgtm - the cert verified ok
[14:45] <degorenko> jamespage, any ideas? :)
[14:45] <sdeziel> frickler: but PCI ordering is really annoying I must admit
[14:45] <jamespage> Verify return code: 0 (ok)
[14:45] <jamespage> degorenko, second is probably rmq is not configured to support tlsv1.2
[14:45] <jamespage> v1 has some issues I think
[14:45] <EmilienM> weird all of this worked on trusty
[14:45] <EmilienM> maybe a dep in python or?
[14:46] <degorenko> jamespage, same error from rabbit log =ERROR REPORT==== 19-May-2016::14:45:38 ===
[14:46] <jamespage> EmilienM, I think it all worked on trusty because python 2.7 ignores certificate validate chains in trusty
[14:46] <degorenko> SSL: hello: tls_handshake.erl:167:Fatal error: insufficient security
[14:47] <degorenko> for the recored - rabbitmq is running
[14:47] <jamespage> degorenko, I've not seen that problem before - I'd have to google it but I would suspect its something related to tls version level negiotiation
[14:48] <degorenko> jamespage, i will try also to find out the problem, thanks in advance, ping me, if you will have something
[14:48] <jamespage> degorenko, https://www.rabbitmq.com/ssl.html good reference for checking
[14:49] <degorenko> thanks, going to read article :)
[15:00] <smoser> frickler, thats an openstack bug honestly.
[15:01] <smoser> using eth0 and eth1 was only randomly better if it was
[15:01] <smoser> if openstack arbitrarily moves nics around on a bus on reboot or shutdown / startup, then it really needs to stop doing that.
[15:02] <smoser> really, even in the old 'eth0' and 'eth1' world, it could brea
[15:02] <smoser> break.
[15:03] <smoser> i'm sure that they keep the mac, so it seems that the solution would be to really have to "pin" nics to a given name based on mac.
[15:12] <nacc> rbasak: hey, would you be free after the team hangout today?
[15:12] <rbasak> nacc: yeas
[15:12] <nacc> rbasak: great, thanks!
[15:34] <coreycb> ddellav, hey, ping me your package for review in #ubuntu-server if it's ready
[15:34]  * coreycb thought he was in another channel
[15:38] <ddellav> will do, one sec coreycb
=== deadnull is now known as _deadnull
[15:46] <frickler> smoser: well, they keep the ordering stable (at least I hope, will have to check), so if eth0 is the first virtio-nic and eth1 the second one (as it is with e.g. Trusty IIUC), everything should be fine
[15:46] <frickler> smoser: the trouble comes from systemd-udev assuming that PCI slot ids are stable, which is pretty fine for real hardware, but less so for virtual environments
[15:49] <smoser> yes. thats absolutely it, but for a vm, why is it *not* stable ?
[15:50] <smoser> why does openstack arbitrarily move nic devices around. that is silly.
[15:52] <nacc> is this a hotplug case? looking above, i see a nova-attach invocation. And maybe something ensures that the new device comes "after" the current one? But on reboot, it gets normally detected and the order can be whatever hte bus order is?
[15:52] <frickler> nacc: yeah, that is about what I gather happens
[15:53] <frickler> or rather, on reboot/recreate the default ordering happens, which is network interfaces first, then console/vga, then block devices
[15:54] <nacc> smoser: i don't know about the first part (what nova attach does), tbh, but i do recall seeing (in other contexts) a device being added, and then the order can be different on a normal boot with the same config
[15:55] <smoser> i really think the thing we have to do is to make the names based on nic
[15:55] <smoser> er... based on mac address
[15:55] <nacc> smoser: ack, that's the only "stable" thing
[15:56] <nacc> smoser: and also means if you hotplug in, hotplug out, hotplug in a second, and then reboot, you'll get the right config for the second, not just happen to share the config from the prior (if you went off device naming and happened to get the same name)
[15:56] <nacc> smoser: with newer setups, i guess the "stable naming" implies mac address? (it's in the suffix), but i'm not savvy with how that all works and where it exists
[16:04] <smoser> fyi, ubuntu-server and such do get logged at
[16:04] <smoser>  http://irclogs.ubuntu.com/2016/05/19/%23ubuntu-server.html
[16:04] <smoser> and i quite often link to those things from bugs.
[16:20] <smoser> sdeziel, is https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1573192 a regression ?
[16:20] <smoser> from 15.10 or 14.04 ?
[16:20] <ubottu> Launchpad bug 1573192 in libvirt (Ubuntu) "apparmor prevents using SCSI hostdevs" [Undecided,New]
[16:21] <sdeziel> smoser: I never tried on anything before 16.04
[16:21] <smoser> sdeziel, ah. ok. thanks.
[16:21] <sdeziel> smoser: I could check that out since I have some trusty laying around
[16:25] <smoser> sdeziel, youd ont have to just jump and do it right now. would be good to know as that would raise my feeling of priority on nit.
[16:25] <sdeziel> smoser: OK, thanks
[16:30] <coreycb> jamespage, I'm surprised the midonet plugin was removed by upstream in a stable branch - https://github.com/openstack/neutron/commit/f5d1a42ee252605e51694352b8521c78201603e5
=== Bae is now known as middlefingers
[16:34] <degorenko> jamespage, hey, i've also checked rabbit port for openssl s_client, there are no any tls session tickets, is it ok? http://paste.openstack.org/show/497736/
[16:58] <sdeziel> smoser: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1573192 is reproducible on Trusty
[16:58] <ubottu> Launchpad bug 1573192 in libvirt (Ubuntu) "apparmor prevents using SCSI hostdevs" [Undecided,New]
=== Kehet_ is now known as Kehet
=== _deadnull is now known as deadnull
[17:16] <smoser> sdeziel, thanks
=== degorenko is now known as _degorenko|afk
=== InfoTest1 is now known as InfoTest
=== deadnull is now known as _deadnull
=== mfisch is now known as Guest76268
[18:35] <ddellav> coreycb here the heat repo, lp:~ddellav/ubuntu/+source/heat, it builds successfully and i believe the config file matches yours
[18:35] <ddellav> sorry for the delay, i got wrapped up with this backport reading docs and forgot to paste that to you
[18:39] <coreycb> ddellav, can you fix that on the master branch instead?  we have to fix the current release first.
[18:39] <ddellav> coreycb ah ok, sure
[18:40] <coreycb> ddellav, also does it work?  I would think the PYTHONPATH=.  would need to be on the same line as oslo-config-generator
[18:40] <ddellav> coreycb i copied it from the barbican package and when I installed the produced heat deb it looked right but i'll double check
[18:42] <fermulator> Hey all, I've recently been trialling landscape for personal server/desktop admin/management, it's pretty sweet! saves me oodles of time on system maintenance, (especially pkg upgrades atm).  My unfortunate situation though is that all (~7-8) desktops+servers are Ubuntu, except ONE (1), which is Fedora. Has anyone any information/refs on if it's possible to hook a non-Ubuntu Linux distro into landscape
[18:42] <fermulator> ? (obviously not all features would be available, but I'm interested in at least the ability to monitor the system via landscape web UI)
[19:03] <Sebastien> ok, so. i want to manage emails on my box, and also subdomains. Is it possible to do this with webmin ?
[19:05] <rharper> nacc: smoser: frickler: re the MAC; that is probably the only uniq thing that won't change;  the MAC in nic name however, presents a challenge w.r.t stacking devices since en+strlen($MAC)+\n is like 15, to a 16 char limit for ifname; so things like bridges, aliased interaces, vlans, all become problematic due to existing mechanism to assume appending extra stuff , eth0.123;
[19:06] <nacc> rharper: ah yeah i remember talking about that at the sprint
[19:07] <nacc> rharper: yep, so makes sense to somehow keep a mapping of MAC -> data about interface somewhere?
[19:07] <fermulator> Sebastien, your question may be better asked in #webmin
[19:07] <rharper> yeah; aka udev-rule/systemd.link file; which is eactly this MAC -> NAME mapping;
[19:08] <rharper> openstack has a network_data.json which can export this information (and could update it upon nic hotplug);  cloud-init is parsing that and can emit the mapping;  the remaining on-hotplug trigger cloud-init to regenerate netconf and name nics as the remaining todo here;
[19:09] <rharper> I agree with smoser though that there is little reason for openstack/libvirt to reorder the devices on the bus;
[19:09] <rharper> mapping that to a real hotplug of a nic; one usually don't move all of the boards around when adding one new one
[19:10] <rharper> that's causing churn for no reason;
[19:10] <nacc> rharper: does hotplug have some special cases for adding the bus? like it puts it "after" existing busses when live-hotplug?
[19:11] <rharper> libvirt has code for walking the existing topology in the case that the libvirt hotplug xml doesn't include an explicit bus address
[19:12] <rharper> it's possible that they've got some code that collects them all and then writes out a new xml file;  so you can see a nic get plugged into slot 3 at hotplug time, but when rebooting, the on-disk xml has it in a different slot
[19:12] <nacc> i'm just wondering if somehow the non-xml state (live) isn't matched up to the xmls tate
[19:12] <nacc> yeah
[19:12] <rharper> yes
[19:12] <rharper> happens quite often
[19:12] <rharper> with disks as well
[19:12] <nacc> right, makes sense
[19:12] <nacc> hence why UUIDs are important :)
[19:12] <rharper> but disks have fancy things like /dev/disk/by-id which map to disk serial
[19:13] <rharper> however, oddly; qemu doesn't provide default serial number (unlike default mac addrs) except for HDA types.
[19:13] <nacc> yeah, wasn't there a request at some point to have a /dev/net/by-id by-mac etc
[19:13] <rharper> we never fixed that  silliness
[19:13] <rharper> yeah; but the kernel interface doesn't allow for filesystem ops
[19:13] <nacc> oh right
[19:13] <smoser> rharper, but tha trequirees the serial :). which they're not providing.
[19:13] <rharper> my current reading of the code is that the only real thing is the ifindex
[19:14] <rharper> then ifname is field of a structure indexed
[19:14] <nacc> right
[19:14] <rharper> smoser: yeah, uuidgen[:20]
[19:14] <nacc> so is the issue in the above queries that the device got renamed or that hte libvirt busses got reordered on reboot?
[19:14] <rharper> that's good enough and can be "persisted" in the xml
[19:16] <rharper> nacc: it's the classic nic hotplug case where a nic shows up, it's been hotplugged into slot 7; but libvirt wrote out an xml on disk that didn;t put the hotplug nic in slot7; so upon reboot the hotplug nic is now in slot4
[19:16] <nacc> ah ok, now i get it
[19:16] <rharper> since we're using systemd "persistent" naming, we don't trigger a udev-write-net-persist script which could have recorded MAC -> name (ens7) mapping
[19:16] <nacc> so a "fix" would also be to write to the XML the live state?
[19:16] <rharper> but slots aren't as persistent as MAC->NAME mapping
[19:16] <rharper> yeah, or figure out why libvirt persistent of hotplug devices changes slots
[19:16] <nacc> i guess s/"fix"/"hack"/
[19:17] <nacc> and i'm sure from a data-structure, cleanliness perspective, there are advantages to compressing the bus namespace down
[19:17] <rharper>  s/hack/return-to-previous-mostly-sane-behavior
[19:17] <nacc> :)
[19:17] <rharper> nacc: I doubt it's that level of sanity
[19:18] <nacc> rharper: this is libvirt? probably not, you're right
[19:18] <rharper> my guess is that no one noticed the movement due to persistent rules being written in the past
[19:18] <rharper> libvirt
[19:19] <rharper> now that everyone is 'persistent'; the OS is taking the "hardware" at it's word; turns out the machine builder (nova/libvirt/qemu) aren't actually providing a persistent hardware machine
[19:19] <rharper> sorta moving the bubble around
[19:19] <nacc> right
[19:20] <rharper> I thought about playing around if the ifalias structure in the kernel (it supports up to 256 chars) per interface
[19:20] <rharper> there are some existing users of that though (snmp MOBs use those for tagging)
[19:21] <rharper> but it'd be nice to have 256 char space per device for naming and such; though I don't think anyone really wants to type in: ifconfig enx8cae4cfdb971
[19:21] <rharper> maybe if we add tab-completion for ifconfig and ip with the netdev names
[19:21] <nacc> people already don't want to type eth<anything other than 0> it feels like :)
[19:21] <rharper> that's probably a really nice thing to do  now
[19:21] <sdeziel> rharper: in your previous example, if you persisted the name ens7 to map to your hotplugged NIC that later gets moved to slot4, what will happen when you hotplug another NIC that lands in slot7?
[19:22] <rharper> sdeziel: it'll fall back to the kname (like eth3)
[19:22] <sdeziel> rharper: OK. This is going to be confusing at some point
[19:22] <rharper> the systemd.network manpage on NamingPolicy talks about the order in which it attempts to get a name
[19:22] <rharper> sdeziel: at some point? =)
[19:23] <nacc> i think the notion should be that if it's consistent over reboot, and there is a way to go from the name to the 'physical' location, then the name is just a handle
[19:23] <sdeziel> ens7 sets some expectations on the location of the said NIC.
[19:23] <nacc> sdeziel: if it's explicit that the name isn't hte location, but there is a mapping somewhere, then we just break that expectation from the get-go
[19:24] <rharper> sdeziel: right, which is why we don't currently write out a persistent rule
[19:24] <rharper> the name is supposed to reflect where it is
[19:24] <rharper> sdeziel: and in this example, the admin (libvirt/nova) did move it (ens7 -> ens4)
[19:24] <rharper> that's like someone in the lab pulling the card and putting it somewhere else
[19:25] <rharper> one probably wants to know that;  though we had large discussion about the location of the interface not mattering as much as what the nic is connected to
[19:25] <rharper> which is opposite of say disks which are more concerned with the data _in_ them
[19:25] <nacc> right, you want subnet information, roughly (connectivity like you said)
[19:26] <rharper> nacc: right; in the case of openstack which _can_ tell us about the nics; there's no reason to use the "location" mapping at all
[19:26] <nacc> yep
[19:26] <nacc> it only leads to confusion :)
[19:26] <rharper> the oracle, as we say, can then name it whatever  red, blue, management, private
[19:26] <TJ-> we need a /dev/net/by-route/ like /dev/disk/by-uuid/
[19:26] <rharper> TJ-: yeah
[19:26] <rharper> that'd be super cool
[19:26] <nacc> yeah i guess that'd just the gateway(s)
[19:26] <rharper> by-mac, by-ip, etc
[19:27] <rharper> but that's, I think, a rather large endeavor
[19:27] <TJ-> I always wondered why that wasn't the systemd solution seeing as it absorbed udev, which love symlinks
[19:27] <nacc> yep, and one most people have just avoided :)
[19:27] <rharper> where's 9P
[19:27] <sdeziel> what I'm saying is persisting a name that embeds slot location is confusing at best
[19:27] <rharper> sdeziel: how so?
[19:27] <rharper> for a real server in the lab
[19:27] <rharper> it's useful information;  which card do I pull out ?
[19:27] <rharper> the one in slot 7
[19:28] <rharper> ens9 doesn't have a link (go plug in a cable)
[19:28] <TJ-> it could just be a tag though, it doesn't need to be the if name, which should be something that means something to the network admin
[19:28] <rharper> TJ-: yeah; so the ifalias field has 256
[19:28] <sdeziel> in the ens7 -> ens4 case, if you persisted the name ens7 and the card actually moved to slot4 you can not longer figure out where it is hooked by the name
[19:28] <rharper> one could come up with some tooling to apply info to that field and then assemble symlinks
[19:28] <rharper> but all of the ip tools work on ioctls
[19:29] <rharper> so a lot of effort to revamp tooling to look at symlinks to figure out which ifindex to use to query more info and set values
[19:29] <rharper> sdeziel: correct; we'rre not suggesting to persist the nic name based on slot location into the OS;  rather in libvirt which is like the machine definition
[19:30] <rharper> sdeziel: instead, the cloud should provide a name -> mac mapping in the config (openstack can do this) and cloud-init will generate mappings between name and mac via systemd.link files
=== Guest76268 is now known as mfisch
[19:30] <sdeziel> rharper: ah OK, I had missunderstood
[19:32] <rharper> we're in a unstable time now that cloud-init can do this for some clouds (openstack has a network_data.json source);  other clouds may have theres too, and we need those clouds to start providing that level of netconf
=== _deadnull is now known as deadnull
[20:29] <sirhumpalot> anyone have experience expanding an ext4 fs while online with TB of data and connected users?
=== rattking is now known as deadlocks
[22:35] <hallyn> drat.  my qemu 2.6.0 merge fails a guest scsi test.
[23:45] <hallyn> well this is maddening.  my yakkety vms won't boot
[23:47] <hallyn> all right purging cloud init helped
[23:58] <HappySomethingSo> hi
[23:58] <HappySomethingSo> I'm having problems setting up a static ip on ubuntu 16
[23:59] <HappySomethingSo> I used to edit /etc/network/interfaces on ubuntu 14 to set it up, but that no longer works
[23:59] <HappySomethingSo> and everything I do in /etc/network/interfaces.d gets erased on system boot