[00:28] <redcavalier> blackboxsw, it looks like my issue is indeed a cloud-init bug. I do have some questions remaining though : https://bugs.launchpad.net/cloud-init/+bug/1722992
[00:28] <ubot5> Ubuntu bug 1722992 in cloud-init "On the latest centos 7 release, we are unable to resize our instances filesystems" [Medium,Confirmed]
[00:33] <redcavalier> The explanation implies that vendordata is not fed in an appropriate format to cloud-init. I was wondering if there was a way I could change this, by forcing openstack to provide inconsequential vendor data, versus the empty data it currently gives.
[00:33] <redcavalier> Additinally, I'Ve been wondering if this bug is really the cause of growpart not running.
=== mgagne is now known as Guest53680
[03:40] <blackboxsw> redcavalier: do you see cc_growpart in your /var/log/cloud-init.log and also in /etc/cloud/cloud.cfg?
[03:41] <blackboxsw> In ubuntu I see  - growpart
[03:41] <blackboxsw>  - resizefs
[03:41] <blackboxsw>  - disk_setup
[03:41] <blackboxsw> in my /etc/cloud/cloud.cfg
[03:41] <blackboxsw> those cloud-config module names would  need to be listed in the cloud_init_modules: section if they were to get run at all during cloud-init
[03:42] <blackboxsw> and each module should be announced in /var/log/cloud-init.log if it is run (or ignored)
[03:42] <blackboxsw> on my system: 2017-10-12 02:31:52,089 - handlers.py[DEBUG]: start: init-network/config-growpart: running config-growpart with frequency always
[03:44] <blackboxsw> 2017-09-21 21:48:15,613 - stages.py[DEBUG]: Running module growpart ...
[03:44] <redcavalier> blackboxsw, let me check quickly the last logs I made yesterday
[03:45] <blackboxsw> anyway we've seen images that didn't have a couple of those disk related modules listed in /etc/cloud/cloud.cfg and that skipped some partition resizing.
[03:46] <redcavalier> ah, it is listed
[03:46] <redcavalier> It's a custom image we make ourselves
[03:46] <redcavalier> and it used to work on previous versions of cloud-init
[03:47] <blackboxsw> redcavalier: mind attaching your /etc/cloud/cloud.cfg to https://bugs.launchpad.net/cloud-init/+bug/1722992
[03:47] <ubot5> Ubuntu bug 1722992 in cloud-init "On the latest centos 7 release, we are unable to resize our instances filesystems" [Medium,Confirmed]
[03:47] <blackboxsw> just for reference
[03:47] <redcavalier> sure
[03:48] <blackboxsw> thanks a ton. yeah we looked at it today a bit and scott came up with the issue there which we need to address.
[03:48] <blackboxsw> it's a bit late in the evening tonight but we'll be looking at fixing this
[03:48] <redcavalier> yea, I'm just curious if that'S the no resize cause or just another issue
[03:51] <blackboxsw> in the cloud-init.log you attached to the bug, I don't see any reference to cc_growpart in var/log/cloud-init.log it makes me think that module is not configured to run in that image for some reason
[03:51] <blackboxsw> but I'll get some fresh eyes on it my tomorrow morn
[03:53] <blackboxsw> have a good one
[03:53] <redcavalier> Thanks, I'll probably drop by again tomorrow
[03:53] <redcavalier> have a good night
=== ahasenack is now known as andreas
[17:15] <paulmey> What is the approximate release cadence for cloud-init nowadays?
[17:15] <blackboxsw> paulmey: the goal is every 3 months.
[17:15] <blackboxsw> just agreed to that cadence for >= 17.1
[17:28] <blackboxsw> https://lists.launchpad.net/cloud-init/msg00106.html   explains the cadence and shows mid-sept release for 17.1, I'm expecting Xmas or New Year's for next release
[17:33] <sedition> happy friday
[17:38] <paulmey> Ah thanks blackboxsw, I now remember that email indeed. I must say I love holidays for releases... It's the best time to do live site support... ;-)
[17:41] <blackboxsw> absolutely, I say release on Fridays and a day before long vacations so 3rd tier support really gets a workout ;)
[17:42] <blackboxsw> and/or
[17:42] <paulmey> :-) so yeah, happy Friday indeed
[17:42] <blackboxsw> heh definitely :)
[17:43] <blackboxsw> working toward an Ubuntu SRU release of 17.1 into xenial and zesty, but I think we'll miss this friday for our validation and publishing :(
[17:45] <blackboxsw> tracking ubuntu 17.1 release progress here for those interested  https://trello.com/c/wROS4mKT/458-sru-171
[17:48] <smoser> paulmey, well, the release will be near the holiday.
[17:48] <smoser> it wont need to go to ubuntu (or any other distro) till after that
[17:49] <smoser> probably we'd' expect it to be in 18.04 (the in-development development release) right away
[17:49] <smoser> but not an aru
[17:49] <smoser> sru
[17:51] <paulmey> make sense
=== Guest53680 is now known as mgagne
[19:58] <blackboxsw> 6 bugs left to write SRU tests for
[21:17] <blackboxsw> hrm, tried to forkbomb via runcmd. in hopes of systemd task limit would have held runcmd  to a sensible limit for forked tasks...
[21:17] <blackboxsw> didn't work and bricked my lxc
[21:21] <blackboxsw> I actually set DefaultTaskMax=20 in /etc/systemd/system.conf with the thought that it'd stop too many processes from being forked
[21:25] <smoser> blackboxsw, link_up_and_dad
[21:25] <smoser> bah
[21:26] <smoser> https://gist.github.com/smoser/49444542158f2e5f88f1/#file-lxc-pstart-md
[21:26] <blackboxsw> ummm
[21:26] <smoser> thats what i got...
[21:26] <smoser> "sort of works"
[21:27] <smoser> so mount-image-callback lxd:foo
[21:27] <smoser> now can be done with
[21:27] <smoser>  lxc_pstart.py foo
[21:27] <smoser>  lxc exec foo <command>
[21:27] <smoser>  lxc stop foo
[21:28] <smoser>   # and then edit out the 'pstart' profile from 'foo'
[21:28] <blackboxsw> meh, forkbomb did work and systemd DefaultTaskMax=20 worked too
[21:28] <blackboxsw> from cloud-init-output.log d: /var/lib/cloud/instance/scripts/runcmd: 2: /var/lib/cloud/instance/scripts/runcmd: Cannot fork
[21:28] <smoser> hm..
[21:28] <blackboxsw> I had forgotted to set DefaultTaskMax=20 in /etc/systemd/systemd.conf (and remove the TaskMax=Infinite in cloud-init.final.service
[21:29] <blackboxsw> ok reading gist
[21:30] <smoser> i got to run. it seems to basically work, but right now the profile gets left over on the containers config.
[21:30] <smoser> see issues.
[21:32] <blackboxsw> wow nice smoser
[21:32] <blackboxsw> will test it a bit today
[21:32] <blackboxsw> have a good one
[23:02] <blackboxsw> smoser:think I'm running into lxc versionitis on xenial
[23:02] <blackboxsw> I'm hitting some usage errors with your scripts. lemme paste before I look
[23:03] <blackboxsw> http://pastebin.ubuntu.com/25734851/
[23:03] <blackboxsw> ahh b'\nerror: unknown command: network\n'
[23:03] <blackboxsw> ok will look it over (and will try on artful)
[23:04] <blackboxsw> i  lxd                                         2.0.9-0ubuntu1~16.04.2                                   amd64        Container hypervisor based on LXC - daemon
[23:04] <blackboxsw> ii  lxd-client                                  2.0.9-0ubuntu1~16.04.2
[23:04] <blackboxsw> ii  liblxc1                                     2.0.7-0ubuntu1~16.04.2                                   amd64        Linux Containers userspace tools (library)
[23:04] <blackboxsw> ii  lxc                                         2.0.7-0ubuntu1~16.04.2                                   all          Transitional package for lxc1
[23:04] <blackboxsw> ii  lxc-common                                  2.0.7-0ubuntu1~16.04.2