=== rangerpb is now known as rangerpbzzzz
=== sambetts|afk is now known as sambetts
=== rangerpbzzzz is now known as rangerpb
=== natorious_ is now known as natorious
[16:28] <blackboxsw> hey smoser, so where do things stand with the current SRU process? I'm trying to find an sru bug related to the work.
[16:30] <smoser> blackboxsw, ok.. collecting some info
[16:30] <blackboxsw> good deal, thanks.
[16:31] <smoser> typing https://public.etherpad-mozilla.org/p/cloud-init-sru-info
[16:35] <smoser> blackboxsw, so i guess the easiest thing to do is just start doing it... we can walk down the list and pick one by one. if you dont understand the test case / verification that i put in for anything, then you can either
[16:35] <smoser> a.) ask questions
[16:35] <smoser> b.) go to the next one
[16:36] <smoser>  (until you run out and are forced to 'a')
[16:37] <blackboxsw> yeah that sounds like a good loop. expect the a's
[16:39]  * blackboxsw starts at the top
[16:39] <blackboxsw> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1676460 xenial validation
[16:40] <smoser> blackboxsw, many of the bugs reference 'lxc-proposed-snapshot'
[16:40] <smoser> that one did not. it would be good to make yourself a lxc with proposed cloud-init in it.
[16:41] <smoser> see http://pad.lv/1674766 for an example.
[16:42] <blackboxsw> cool will do
[16:44] <smoser> that requires 'mount-image-callback' (cloud-utils) .. and it requires lxc1 for 'lxcnsuserexec'
[16:44] <smoser> err... lxc-nsuserexec
[16:47] <smoser> so i just ran
[16:47] <smoser>  ./bin/lxc-proposed-snapshot -vvv xenial --proposed xenial-proposed --publish
[16:48] <smoser> which means i can now:
[16:48] <smoser> lxc launch xenial-proposed xp1
[16:48] <smoser> and it starts with cloud-init inside from -proposed
[16:52] <blackboxsw> hrm /home/csmith/src/server/lxd:xenial-proposed-11791681: not a file   re-reading the script intent
[16:53] <blackboxsw> and I have lxc1 & cloud-utils
[16:53] <blackboxsw> per http://pastebin.ubuntu.com/24375059/
[16:54] <smoser> newer cloud-utils needed. :-(. that support i think went into zesty.
[16:55] <blackboxsw> updating... :/
[16:55] <smoser> if you want, you can probably just grab it
[16:55] <smoser> its a simplish script
[16:55] <smoser> and put it in $PATH
[16:56] <blackboxsw> yeah might just do that while waiting on my desktop upgrade.
[17:01] <smoser> yikes. you are brave.
[17:01] <smoser> (i run the development release but most do not :)
[17:01] <smoser> the other option is doing this on an instance somewhere. that is why lxd is nice.
[17:02] <smoser> blackboxsw, http://bazaar.launchpad.net/~cloud-utils-dev/cloud-utils/trunk/view/head:/bin/mount-image-callback
[17:11] <blackboxsw> ok, looks better thanks smoser with the path tweaked to reference the mount-image-callback script thanks.
[17:22] <blackboxsw> have a quick errand, back in 20
=== blackboxsw is now known as blackboxsw_bbl
=== sambetts is now known as sambetts|afk
[17:29] <smoser> k
[17:42] <ahasenack> blackboxsw_bbl: smoser reading the etherpad and backlog
=== blackboxsw_bbl is now known as blackboxsw
[17:51] <blackboxsw> meh, looks like my xenial flavor of lxc doesn't accept push -p
[17:54] <ahasenack> smoser: ok, read it all, +1 on the plan to go down the list and note which bug we are verifying
[17:54] <ahasenack> smoser: https://bugs.launchpad.net/cloud-init/+bug/1674946 has been commented by someone saying the fix worked
[17:55] <smoser> blackboxsw, yeah. you can use the snap i think for lxd
[17:55] <ahasenack> not the reporter, though
[17:55] <smoser> but migth still have the issue with mount-image-callback there.
[17:55] <smoser> ahasenack, so what i'd do is just comment:
[17:56] <smoser>  I'm marking this verification-done-xenial based on comment X
[17:56] <smoser> and then do that.
[17:56] <ahasenack> ok
[18:03] <smoser> ahasenack, blackboxsw i think you are both aware, but you tag with 'verification-done-xenial' and 'verification-done-yakkety'  rather than just 'verification-done'
[18:03] <ahasenack> right
[18:04] <blackboxsw> smoser, hmm looks like my xenial proposed validation fell over the for https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1674766  http://pastebin.ubuntu.com/24375361/
[18:04] <blackboxsw> the pastbin indicates ds-identify didn't process BigStep support right?
[18:05] <blackboxsw> I'll double check that I have setup the seed files properl
[18:05] <smoser> blackboxsw, right. let me try too
[18:06] <blackboxsw> smoser this might be because I had started this lxc in the first place before adding the seed files in an attempt to work around my lxc file push not supporting -p option
[18:07] <smoser> quite possibly. yes.
[18:07] <blackboxsw> start would have run through cloud-init I expect
[18:07] <blackboxsw> yeah sorting my lxc command version
[18:10] <ahasenack> it's good to see the "before" case
[18:18] <smoser> blackboxsw, yeah. so when working with cloud-init and lxc  i have some tools (like the lxc-propsed-snapshot) that help you to adjust a container without starting it.
[18:18] <smoser> the other option is to start it and then "clean" it.
[18:22] <smoser> the bin/do-reboot  script there helps do the clean
[18:23] <ahasenack> smoser: config-drive newbie here, sorry
[18:23] <ahasenack> how do I pass that to a container?
[18:23] <ahasenack> a config-drive configuration, and where can i find out what it should look like?
[18:24] <blackboxsw> TIL, thx smoser
[18:25] <ahasenack> going through https://bugs.launchpad.net/nova-lxd/+bug/1673411 for some reference, looks like it has a helper script attached
[18:25] <ahasenack> ah, it's in tools/
[18:30]  * ahasenack sees the commented bits about network_data.json
[18:34] <smoser> i've been walking up from the bottom
[18:34] <smoser> but i'm going to leave https://bugs.launchpad.net/cloud-init/+bug/1665694 for one of you as a introduction to integration test suite
[18:57] <blackboxsw> smoser, great. ok finally sorted things and have a zesty box at my disposal
[18:57] <blackboxsw> lxc file pull $name/run/cloud-init/result.json -
[18:57] <blackboxsw> {
[18:57] <blackboxsw>  "v1": {
[18:57] <blackboxsw>   "datasource": "DataSourceBigstep",
[18:57] <blackboxsw>   "errors": []
[18:57] <blackboxsw>  }
[18:57] <blackboxsw> }
[18:58] <blackboxsw> ok progress. now time to do some work
[18:59] <smoser> woot!
[18:59] <smoser> blackboxsw, you can take the https://bugs.launchpad.net/cloud-init/+bug/1665694
[18:59] <blackboxsw> will do thx
[19:08] <ahasenack> smoser: can I trigger this bug with just lxd, faking hyperv somehow? https://bugs.launchpad.net/cloud-init/+bug/1674946
[19:09] <ahasenack> I have a config drive in /config-drive in this lxd, with network_data.json, but it looks like it's not being read (I want to trigger the bug first, then check the fix)
[19:12] <ahasenack> or maybe I'm being hit by https://bugs.launchpad.net/nova-lxd/+bug/1673411, but this cloud-init in -proposed should have that fix
[19:12] <smoser> reading
[19:12] <ahasenack> which is also in our list
[19:13] <ahasenack> ah
[19:13] <ahasenack> ok, got it
[19:13] <smoser> ahasenack, (/me realizes for the first time that you have different internal and external personalities... andreas -> ahasenack)
[19:13] <ahasenack> I wanted to test the "before" case, but I can't because I need the fixed cloud-init for it to parse /config-drive according to #1673411
[19:13] <ahasenack> smoser: :)
[19:13] <ahasenack> andreas was already taken here, my ninjas didn't find him
[19:14] <smoser> so before the new version, you should be able to populate /var/lib/cloud/data/seed/ConfigDrive
[19:14] <smoser> i think
[19:14] <smoser> (with the same contents as /config-drive)
[19:14] <ahasenack> smoser: ok
[19:14] <smoser> and it should look there.
[19:33] <ahasenack> yay
[19:33] <ahasenack> I haz result.json
[19:40] <blackboxsw> interesting in running tox on the cloud-init tests is that my cd drive started spinning up. wondering if we're leaking some calls to mount that drive from the unit tests
[19:41] <smoser> blackboxsw, it probably is.
[19:41] <smoser> someone working on freebsd found one of those the other day ... let me se
[19:44]  * ahasenack injecting errors to see what happens
[19:44] <ahasenack>    "Unknown network_data link type: dvs-andreas-was-here",
[19:45] <ahasenack> good
[19:46] <smoser> nice ahasenack !
[19:47] <ahasenack> you made an MP against upstream to stop sending these deprecated link types, right
[19:47] <ahasenack> https://review.openstack.org/#/c/400883/2
[19:47] <smoser> yeah, and it just made it into trunk
[19:48] <smoser> they're really not "deprecated". as they're real and useful link types at the hypervisor level
[19:48] <smoser> but not at the guest level
[19:49] <ahasenack> right, wrong choice of words
[19:50] <ahasenack> smoser: is cloud-init also responsible for creating the ubuntu user?
[19:50] <smoser> yes
[19:50] <smoser> > precise at least
[19:50] <ahasenack> smoser: ok, because once I injected that failure in the network, the ubuntu user wasn't created: https://pastebin.canonical.com/185908/
[19:51] <smoser> yeah. if the datasource traces it wont go on
[19:51] <ahasenack> ok
[19:51] <smoser> well, in that way at least.
[19:51] <ahasenack> sorry about the canonical pastebin
[19:52] <ahasenack> habit
[19:52] <ahasenack> and bookmarks
[19:55] <smoser> ahasenack, well you can just use 'pastebinit' now!
[19:55] <smoser> i am constantly doing:
[19:55] <smoser>  xsel -o | pastebinit
[19:55] <ahasenack> indeed!
[19:55] <ahasenack> finally
[19:55] <blackboxsw> smoser, looks like I'm hitting a dependency error trying to install pylxd as the tox -e citest environment
[19:55] <smoser> (highlight something  and then paste and paste the url to something)
[19:56] <smoser> hm..
[19:56] <blackboxsw> http://paste.ubuntu.com/24375992/
[19:56] <smoser> i suspect you need python3-dev
[19:56] <rharper> blackboxsw: ping powersj ; he's worked through those before
[19:56] <smoser> yeah
[19:56] <blackboxsw> powersj, has been invoked :)
[19:57] <smoser> tox is wonderful
[19:57] <smoser> until you have c extentions
[19:57] <smoser> then it becomes honestly kind of silly in my opinion
[19:57] <smoser> but still better than lots of other stuff
[19:57] <smoser> blackboxsw, install python3-dev with apt
[19:57] <smoser> and try again
[19:58] <smoser> pylxc needs c bindings to lxc and thus the sillynees. python3-dev is pretty light though.
[19:59] <blackboxsw> getting closer. ok new traceback, missing C headers as well. I'll iterate over these to get them fixed. and report a list of the deps I had to install to get things working
[20:04] <blackboxsw> ok needed only libssl-dev too. So, the list of packages I've installed on a fresh zesty system: ls
[20:05] <blackboxsw> lxc1, cloud-utils, devscripts, python3-dev, libssl-dev
[20:06] <nacc> we use lxc1?
[20:10] <smoser> lxc1 provids lxc-usernsexec
[20:10] <smoser> which is used by mount-image-callback lxd:foo
[20:10] <smoser> to get the right user namespace when it chroots to the target
[20:10] <rharper> nacc: yeah; I suggested we get lxd to implement lxc-usernsexec but I forget why they said not to
[20:17] <smoser> blackboxsw, http://paste.ubuntu.com/24376111/
[20:17] <smoser> so inside an lxc container ^ worked.
[20:18] <smoser> well, it shows me jumping into the container
[20:18] <smoser> but that should list everything you need on xenial which i suspect is the same on zesty
[20:19] <blackboxsw> excellent, will not distrupt my other systems then
[20:20] <smoser> blackboxsw, well. you dont *really* want to run inside lxc
[20:20] <smoser> because then you can't use zfs
[20:20] <smoser> :)
[20:20] <smoser> i'm not certain if it works or not fully. but lack of zfs is reason enough for me to not want to do it.
[20:22] <blackboxsw> certainly. makes sense
[20:22] <smoser> if you want... you can walk the merge proposal path ...
[20:22] <smoser> with a doc enhancement to doc/rtd/topics/tests.rst
[20:22] <smoser> with the above
[20:23] <smoser> (the dependencies needed and such)
[20:23] <blackboxsw> +1 smoser sure I'll put up an mp.
[20:30] <ahasenack> smoser: ok, so I verified xenial and yakkety and added the respective verification-done-<release> tags. Someone else will flip the verification-needed tag into verification-done?
[20:30] <ahasenack> ops, for bug https://bugs.launchpad.net/nova-lxd/+bug/1673411 that is
[20:35] <smoser> ahasenack, no. you drop the verification-needed.
[20:35] <smoser> changing it to verification-done-<x>
[20:35] <smoser> really with 2 srus in flight at the same time... there really should be verificaton-needed-xenial and verification-needed-yakkety
[20:36] <smoser> the sru process really just doesn't handle the different releases at once all that well
[20:37] <ahasenack> smoser: how do they know they should hold pushing this to updates since we have the other bugs for the same package still being verified? Via debian/changelog?
[20:51] <smoser> ahasenack, https://people.canonical.com/~ubuntu-archive/pending-sru.html
[20:52] <smoser> look for cloud-init there. after everything gets verified, all its bugs should be green or gold (i dont understand the difference)
[20:52] <ahasenack> ok, I see the proposed package associated with all the bugs
[20:56] <blackboxsw> smoser, so I added verification-done-xenial verfication-done-yakkety tags to https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1674766
[21:00] <Rafael> Hello folks
=== Rafael is now known as Guest678
[21:00] <Guest678> can somebody help to clarify a doubt that I have
[21:01] <Guest678> do I need any special configuration to enable cloud-init to reset SSH keys?
[21:01] <Guest678> The first time I create an instance it assigns the configure SSH key to it, however, if I change the key, cloud-init is not updating it in the VM
[21:02] <smoser> change the key ?
[21:02] <smoser> hi Raboo
[21:02] <smoser> bah. sorry Raboo tab complete fail.
[21:04] <Guest678> yeap
[21:04] <Guest678> I mean change the public key that is inject into the VM
[21:05] <Guest678> When the VM is created cloud-init succesfuly install the keys under ~/.ssh/authrozied_keys
[21:05] <Guest678> However, if I change the keys in my cloud orchestrator, and then reboot the VM, cloud-init is not changing the keys
[21:06] <smoser> Guest678, yeah, that is only done on first instance boot.
[21:06] <Guest678> I am guessing it has something to do with these logs ""
[21:06] <Guest678> yep
[21:06] <Guest678> that is what I thought from reading the log files
[21:06] <smoser> it is not kept in sync. that is a feature that we'd like to have at some point.
[21:06] <Guest678> yes there a way to configure this?
[21:06] <Guest678> ah
[21:06] <smoser> um... maybe.
[21:07] <Guest678> is there a work around?
[21:07] <Guest678> I thought that there would be a way to indicate which modules I want to run once per instance, or once per boot, or constantly with the VM running
[21:08] <smoser> actually, not easily. you could turn the ssh config module (which is what puts those keys into the default user's .ssh/authorized_keys)
[21:08] <smoser> but changing that to run PER_ALWAYS (boot) would be not ideal
[21:08] <smoser> as that is the same thing that wipes the host keys
[21:08] <smoser> which you probably do not want ot happen every boot
[21:09] <smoser> what cloud provider is this ?
[21:09] <Guest678> ah
[21:09] <Guest678> the same script that configures SSH keys is setting up host keys?
[21:09] <Guest678> CloudStack
[21:09] <Guest678> the module you are talking about is the one called "ssh"?
[21:10] <Guest678> I noticed some other module called "ssh-authkey-fingerprints"
[21:10] <smoser> blackboxsw, on https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1674766
[21:11] <smoser> (and the others you have done)
[21:11] <smoser> the sru person will want to see a comment at least stating "i verified both xenial and yakkety following the test case template above"
[21:11] <smoser> i like to copy and paste evidence of having done that
[21:11] <smoser>  
[21:11] <smoser> https://bugs.launchpad.net/cloud-init/+bug/1674685https://bugs.launchpad.net/cloud-init/+bug/1674685
[21:12] <smoser> Guest678, yeah, that does sound silly doesnt it :)
[21:12] <smoser> yes, its ssh. we really should separate that out so you could tweak one wihtout the other.
[21:12] <smoser> but as it is right now... the datasources cache the data on disk (so as to not rely upon a metadata service on reboot)
[21:12] <Guest678> hmm
[21:12] <smoser> so.. they'd just re-aply the cached data.
[21:13] <smoser> this is a feature we'd like to have, but its not present now. sorry .
[21:13] <blackboxsw> +1 smoser will add that now and close those bugs appropriately
[21:13] <smoser> well, you dont change the state of the bugs..
[21:13] <blackboxsw> s/close/tag
[21:13] <Guest678> thanks @smoser
[21:13] <smoser> once the bug moves from -prpoosed to -updates it will automatically do that.
[21:17] <smoser> ahasenack, https://bugs.launchpad.net/cloud-init/+bug/1570325
[21:17] <smoser> you can do that one... that is a integration test also. (for learning to at least run the integration test)
[21:17] <ahasenack> deal
[21:21] <smoser> ok. /me has to run.
[21:27] <ahasenack> ok, https://bugs.launchpad.net/cloud-init/+bug/1674946 verified
[21:27] <ahasenack> this will go much faster from now on
[21:31] <ahasenack> ok, I'm EOD
[21:45]  * blackboxsw is spending some time walking through those integration tests on cloud-init
[21:45] <blackboxsw> see you smoser/ahasenack
[21:46] <powersj> blackboxsw: https://cloudinit.readthedocs.io/en/latest/topics/tests.html also worth a read
[21:50] <blackboxsw> excellent
[21:50] <blackboxsw> keep 'em coming
[21:51] <blackboxsw> actually, that's what I'm going to put up a simple doc mp for
[21:51] <blackboxsw> just trying to wrap up some verification first
[21:52] <powersj> blackboxsw: are you familiar with tox and running it?
[21:52] <powersj> both cloud-init and curtin use tox as a wrapper around our unit tests and style tests. When we get a MR that is what we expect to pass
[21:52] <blackboxsw> just a bit, TIL about environments. you guys have a bit more tox.ini config options/setup than services I've worked on
[21:52] <powersj> you can look at tox.ini in the root dir of both projects
[21:52] <powersj> ah ok :)
[21:53] <dpb1> powersj: MR... wth
[21:53] <powersj> O.o
[21:53] <powersj> merge request?
[21:53] <dpb1> step child of MP and PR
[21:53] <powersj> lol
[21:53] <blackboxsw> haha
[21:54]  * powersj is split brain due to github and launchpad usage
[21:54] <dpb1> :)
=== rangerpb is now known as rangerpbzzzz
[23:54] <powersj> Looks like pylint 1.7 was released today O.o