[10:51] <sambetts> Hi cloud-init team, I have recently been experimenting with cloud-init 0.7.9 and Centos to try to make OpenStack network_data.json work and it seems I've found and issue when processing bonded interfaces in the sysconfig renderer, what is the process for getting this resolved? and/or how can I contribute?
=== shardy is now known as shardy_lunch
=== shardy_lunch is now known as shardy
[13:29] <smoser> sambetts, please open a bug if you dont see any existing.
[13:30] <smoser> if you're looking at helping out, https://github.com/openstack/cloud-init/blob/master/HACKING.rst
[13:30] <smoser> powersj, just a utility.
[13:30] <smoser> ideally i think that functionality gets into cloud-init as a sub command.
[14:25] <sambetts> smoser: is the openstack/cloud-init repo the right repo to commit too? That repo is out of date with the launchpad.net one, launchpad is one 0.7.9 the openstack/cloud-init repo is only on 0.7.6
[14:25] <smoser> shoot
[14:25] <smoser> i gave bad uurl
[14:26] <smoser> follow HACKING. there is a push mirror of launchpad on github
[14:26] <smoser>  https://github.com/cloud-init/cloud-init/commits/master
[14:26] <smoser> but the openstack/cloud-init should probably get deleted.
[14:26] <smoser> https://github.com/cloud-init/cloud-init is the github, but launchpad is where merge proposals are done so really use that.
[14:27] <smoser> make sense ?
[14:30] <sambetts> Yup thanks! whats the release process for cloud-init, e.g. if a bug fix goes in how long does it take to get tagged?
[14:33] <smoser> well... it has varied a lot :)
[14:34] <smoser> but recently coming more frequently, and i'd really like to be in the realm of 3 months or less between releases.
[14:34] <smoser> we are nearing one now.
[14:34] <smoser> utlemming, i'm around if you want to chat some about your MPs
[14:36] <sambetts> awesome :) whats the cloud-init project's relationship with packaging? I noticed that the version included on centos7 is quite old
[14:40] <utlemming> smoser: yup, I'm here
[14:41] <smoser> sambetts, larsks i think is the best contact with centos packaging. We're working on getting integration tests flushed out so we can run tests on centos and such.
[14:41] <smoser> and would like to get closer to sane packaging available in trunk so that i was easier for maintainers.... not sure if thats totally possible or desireable though
[14:42] <sambetts> makes sense, thanks for answering my questions, hopefully I can get permission to contribute to the project :)
[14:46] <utlemming> I also filed this little gem: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1681531
[14:46] <utlemming> I was planning on taking a look at it later today. tl;dr is network.service fails because the nic's have been ifup'd already
[14:46] <utlemming> (just realized that ifup'd looks like a dirty word...)
=== jgrimm is now known as jgrimm-away
[16:25] <smoser> utlemming, cloud-init should not 'ifup'... did you see it specifically doing that ?
[16:27] <utlemming> smoser: yup
[16:27] <utlemming> smoser: pulliung a log now
[16:57] <smoser> powersj, https://bugs.launchpad.net/cloud-init/+bug/1636531
[16:57] <powersj> smoser: yes
[16:57] <smoser> can you recreate that?
[16:58] <powersj> if I modify my path then yes
[16:58] <smoser> i think ideally we're not calling blkid... but even then if we are, id' like to know what your change was there
[16:58] <smoser> you said what you set it *to*
[16:59] <powersj> :/sbin: is what was added
[17:00] <smoser> odd that that was not in your path
[17:00] <smoser> that is almost a bug itself
[17:01] <smoser> ie, ubuntu has /sbin in path by default, so s390x ubuntu *not* having it is just asking for other people to find that
[17:01] <smoser> dont worry about recreate, powersj : http://paste.ubuntu.com/24361950/
[17:02] <powersj> smoser: I wouldn't say it was an ubuntu thing, rather a jenkins not having /sbin in the path by default
[17:04] <smoser> if you made that change on alkl other jenkins, then i agree. but one should typically not have to set PATH ... why would jenkins not just inherit its default PATH as your user does ?
[17:10] <powersj> smoser: I did update all slaves to that path as I put in the bug. the slaves run by default on a more limited path, I'm trying to find the default
=== sambetts is now known as sambetts|afk
[17:25] <utlemming> smoser: three MP's that break up the imrpovments for DigitalOcean. One for the resolvers, one for configuring all Nics, and one for the NIC userd for the meta-data selection. All tested and confirmed to work.
[17:34] <smoser> utlemming, do those overlap too much to submit them without the others ?
[17:34] <smoser> i have comments on each
[17:35] <smoser> and the second and third have the first 2 so reading the diff is combined rather than individual
[17:37] <utlemming> smoser: the first two definately overlap
[17:38] <utlemming> I can break the third up
[17:38] <smoser> do you know how this affects sysconfig rendering ?
[17:40] <utlemming> I don't....but I suspect that it will fix some of the problems that I've seen. I can try and get a test fix. Right now only Ubuntu and Debian use that DS for now.
[18:07] <smoser> powersj, https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/322386
[18:10] <powersj> smoser: I like it, thank you
[18:17] <utlemming> smoser: https://code.launchpad.net/~utlemming/cloud-init/+git/cloud-init-1/+merge/322385 is broken out from the others. Nice and clean.
[18:20] <smoser> utlemming, i'm not sure ifindex is what you want
[18:20] <smoser> https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net
[18:21] <smoser> i dont see any indication on order or anything
[18:24] <utlemming> smoser: in testing it, it represent the device order....starting with lo being 0, and ens3 being 1.
[18:24]  * utlemming digs further on it
[18:32] <utlemming> smoser: I actually think that its safe. The ifindex is incremented by 1 as the devices are added, regardless of the name. Since we are on the virtio-bus and there is a check to make sure that the interface is physical, the first nic will always have a lower index, even if its not 1.
[18:32] <utlemming> i.e. if a user has defined 'dummy0' it wouldn't be a phyisical nic and therefore excluded from the check.
=== mgagne_ is now known as Guest89317
[18:37] <smoser> rharper, ^ ? we were trying to kind of use ifindex to indicate order on the virtio bus
[18:38] <smoser> utlemming, you have an instance up that i can ssh into ?
[18:38] <smoser> or shall i launch one on digital ocean
[18:39] <utlemming> smoser: root@138.197.119.118
=== mgagne_ is now known as Guest4366
=== Guest4366 is now known as mgagne
[19:30] <smoser> utlemming, where did you find '-1' ?
[19:40] <smoser> utlemming, http://paste.ubuntu.com/24362776/
[19:40] <smoser> that is basically "get nic with lowest ifindex". although i' still not sure if that is the right thing.
[19:41] <smoser> powersj, would you +1 https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/322386 ?
[19:42] <powersj> smoser: done
[19:57] <utlemming> smoser: -1 was to indicate that a nic hadn't been tested yet
[19:58] <utlemming> smoser: +1 on that....its clean
[19:59] <smoser> utlemming, so update your MP then with that... and i guess drop the 'LOG.warn' that i added, just return None.
[20:00] <smoser> as the caller there is going to raise RuntimeError
[20:00] <utlemming> smoser: ack, doing so now
[23:06] <cmart> Hi folks - I'm troubleshooting a particular OpenStack image that runs cloud-init 0.7.5 (old, I know). The image will launch on an older OpenStack deployment (running version "Havana") but not a newer OpenStack (running version "Newton"). Looking at cloud-init.log: on the newer cloud, cloud-init seems to be blocking the instance boot process. the last thing it does is finish the mode "init" (setting SSH configuration, host keys, authorized_keys, etc). it doe
[23:06] <cmart> it appears that the process has hung but I don't have a usable console or way to log in locally and check -- at the moment I can only inspect the filesystem of the failed instance. Looking for troubleshooting tips :)