[00:16] <blkadder> Is there a way to specify installation order of packages?
[00:16] <blkadder> I’m finding that they aren’t necessarily done in the order specified.
[02:55] <redcavalier> A few weeks ago, I ended up filing a bug related to the cloud-init package on centos 7 on the centos bug tracker. I haven't had any feedback from centos since, but I'm figuring out I'll probably need to make my own package. Are there any pointers as to how to properly make a spec file for the rpm for cloud-init? I've never built my own packages before.
[02:56] <redcavalier> (btw, the bug prevents root filesystem resize on boot)
[02:57] <blackboxsw> redcavalier: we have nightly builds in our copr repo at  https://copr.fedorainfracloud.org/coprs/g/cloud-init/cloud-init-dev/ if you'd like a centos specific bug fix in cloud-init upstream I'm sure we'd be happy to look it over with a bug filed at https://bugs.launchpad.net/cloud-init/+filebug referencing your centos bug
[02:58] <blackboxsw> to get yourself started, we have some build tools that help us out when testing:
[02:58] <blackboxsw> if you are building yourself. you could look at running: "make ci-deps-centos" to get all build dependencies
[02:58] <blackboxsw> then try "make rpm"
[03:00] <blackboxsw> it builds an rpm for us from cloud-init/packages/redhat/cloud-init.spec.in
[03:01] <redcavalier> I see. I'll make the launchpad bug and then go forward with testing newer versions.
[03:03] <blackboxsw> that'd be good, we have addressed a couple of resize fs bugs in recent history on lp:cloud-init/master
[03:03] <redcavalier> Out of curiosity, are you aware if the the centos official builds are based on the latest cloud-init versions? Or do they generally use older versions? I'm not sure if their numbered releases match the upstream numbers, or if they just renumber them when released as a centos package.
[03:05] <blackboxsw> redcavalier: most distros generally lag the latest cloud-init version by a little bit. We are working on improving the distro & cloud adoption frequency
[03:06] <blackboxsw> I'd expect centos is still on 0.7.9, but we've recently released 17.1 (re-versioned to match <YEAR>.<minor-release-num>
[03:06] <redcavalier> blackboxsw, yes, centos just release 0.7.9 last month, they were on 0.7.5 before
[03:08] <redcavalier> Normally I would have downgraded until my issue is fixed, but I'm getting pressure from higher up to not downgrade so I'm looking for alternatives. Since this issue needs to be fixed pretty much yesterday, as it affects all our customers, I'm crossing my fingers that upgrading will fix it.
[03:09] <blackboxsw> out of curiosity: redcavalier, do you have a link to that centos bug
[03:10] <redcavalier> yes, https://bugs.centos.org/view.php?id=13931
[03:12] <blackboxsw> redcavalier: that texture of error looks like it might be pointing to invalid vendordata from your cloud instance
[03:12] <redcavalier> ftr, our cloud-init userdata does quite a few operations, like writing network files, changing passwords, executing scripts, but the only operation that has started to fail is the resize.
[03:13] <redcavalier> blackboxsw, yea, but vendordata is empty and has always been
[03:13] <redcavalier> This is on openstack Ocata btw
[03:14] <blackboxsw> hrm. I'll peek at our ocata instances as well tomorow. and I'll look back in the irc log for when you first brought this up
[03:14] <blackboxsw> this convesation/problem rings a bell
[03:14] <redcavalier> yea, it was last month, I have the log right here
[03:15] <redcavalier> Thu Sep 28 around noon japan time
[03:15] <blackboxsw> cheers. will look it up a bit and see if anything jogs a memory.
[03:15] <blackboxsw> ahh thanks again for the reference
[03:17] <redcavalier> I'll come back tomorrow at around the same time to see if you'Ve seen anything. In the meantime though, I'll continue testing with more recent versions on my side.
[13:58] <smoser> paulmey, so azure clients... the python one 'az' is generally the future plan ? rather than the node 'azure' ?
[14:38] <paulmey> Oh yes, smoser , definitely
[14:40] <smoser> paulmey, ok. thanks.
[14:40] <smoser> i filed https://github.com/Azure/azure-sdk-for-python/issues/1527
[14:40] <smoser> find its usage odd.
[14:41] <smoser> i dont htink that was the right place though
[14:45] <smoser> there. https://github.com/Azure/azure-cli/issues/4656
[18:27] <paulmey> smoser: there was much complaining about positional parameters on the nodejs cli... so now everything is a named parameter. Thanks for giving feedback though!
[18:28] <smoser> paulmey, funny
[18:29] <smoser> its very reminiscent of lxc 1.0 interface
[18:29] <smoser> lxc-create -n containername
[18:29] <paulmey> in a boo hoo way or in a ha ha way?
[18:29] <smoser> but containername was required (and quite possibly the only argument needed)
[18:29] <smoser> lxc-delete -n containername
[18:29] <smoser> WHY DO I NEED -N !
[18:29] <smoser> but lxc 2.0/lxd is:
[18:29] <smoser>  lxc delete containername
[18:29] <smoser> oh well
[18:30] <paulmey> I guess you'll have to wait for az 2.0 then...
[18:34] <smoser> blackboxsw, https://bugs.launchpad.net/cloud-init/+bug/1723213
[18:34] <smoser> its not as bad as we thouguht though
[18:34] <smoser> the key thing i realized...
[18:34] <smoser> nothing uses the vendordata_raw.
[18:35] <smoser> we dont ever read it back. its just there for other consumers. it should be a blob.
[18:36] <blackboxsw> for other consumers that load the bpickle and run get_vendordata() on the datasource?
[18:36] <smoser> other consumers ?
[18:36] <blackboxsw> per "its just there for other consumers"
[18:37] <smoser> yeah, and i suspect there arent many.
[18:37] <smoser> and it really should be a blob.
[18:37] <blackboxsw> s/m// :)
[18:37] <blackboxsw> just because it's also broken right?
[18:37] <smoser> well that does make it harder :)
[18:42] <smoser> blackboxsw, ok... so i'll start at bottom of the checklist
[18:42] <smoser> in https://trello.com/c/wROS4mKT
[18:42] <blackboxsw> smoser: I'm testing landscape right now
[18:49] <powersj> smoser: that bug you just filed, isn't it the same as LP: #1722992
[18:49] <smoser> it probably is.
[18:49] <smoser> whoops
[18:51] <powersj> smoser: thx
[19:18] <smoser> blackboxsw, i'm going to try to fix mount-image-callback lxd:
[19:18] <blackboxsw> smoser: yes please.
[19:18] <smoser> as i tried to use it (through lxc-proposed-snapshot) and foobar
[19:18] <blackboxsw> I'll need that shortly I suspect
[19:18] <blackboxsw> yeah, I had been using artful, so hadn't gotten that far yet
[19:19] <blackboxsw> mount-image-callback is used by lxc-proposed-snapshot right?
[19:19] <smoser> yes. as i found :)
[19:19] <smoser> i didnt remmeber, but yeah
[19:33] <blackboxsw> pushed two bug updates to sru-info for puppet and landscape
[19:33] <blackboxsw> moving onto the list from the top of the trello card
[20:51] <blackboxsw>  Unapproved: rejected cloud-init [source] (zesty-proposed) [17.1-17-g45d361cb-0ubuntu1~17.04.1]
[20:51] <blackboxsw> hmm checking it out
[21:04] <blackboxsw> well see it in rejected state in the queue https://launchpad.net/ubuntu/zesty/+queue?queue_state=4&queue_text=
[21:04] <blackboxsw> trying to find the history of it
[21:05] <smoser> blackboxsw, 17 is less than 18
[21:05] <smoser> 18 is in
[21:05] <blackboxsw> ahh dumb me
[21:05] <smoser> https://launchpad.net/ubuntu/+source/cloud-init
[21:05] <smoser> and on that link above ...
[21:05] <smoser> "higher numbers are better"
[21:05] <smoser> :)
[21:05] <smoser> the source of my confusion earlier
[21:06] <smoser> i think the best thing to do for mount-image-callback is to drop support for lxd:
[21:06] <powersj> doh
[21:06] <smoser> but add a 'lxc-chroot' which does something like it did
[21:08] <smoser> i had a lxc-chroot before, but moved to using mount-image-callback as it was nice. but the chroot path seems quite plausable now.
[21:11] <blackboxsw> smoser: you mean like sudo chroot /var/lib/lxd/containers/a1/rootfs/
[21:12] <blackboxsw> and then manipulate the rootfs before lxc start a1
[21:12]  * blackboxsw looks at mount-image-callback again to see what it thinks it is doing
[21:13] <smoser> thats mostly what mount-image-callback does
[21:13] <smoser> the two things it really aded for lxd was
[21:14] <smoser> well... it effectively gave you "chroot" into a lxd container
[21:14] <smoser> which meant no network namespace
[21:14] <smoser> and mic would set up /etc/resolv.conf to work, and then it appeared that networkign was all golden
[21:43] <blackboxsw> done testing chef on artful
[21:43] <blackboxsw> and pushed an sru-info test for it