=== shardy is now known as shardy_lunch
=== shardy_lunch is now known as shardy
[15:35] <smoser> blackboxsw: tell me what to do
[15:41] <blackboxsw> smoser: sure, was making coffee, feel free to do that too
[15:41] <smoser> blackboxsw: ?
[15:41] <blackboxsw> ok I'm on puppet/landscape SRU verification now
[15:41]  * powersj must have missed a message
[15:41]  * smoser too
[15:41]  * blackboxsw made coffee
[15:41] <blackboxsw> :)
[15:41] <smoser> ah.
[15:42] <smoser> yeah, let me warm some up. tell me what sru item to work on
[15:42] <blackboxsw> smoser: if you wanted to grab  TEST: [5bba5db2](https://git.launchpad.net/cloud-init/commit/?id=5bba5db2) [#1686485](http://pad.lv/#1686485) cc_ntp: fallback on timesyncd configuration if ntp is not installable
[15:43] <blackboxsw> or - TEST: [10f067d8](https://git.launchpad.net/cloud-init/commit/?id=10f067d8) [#1717598](http://pad.lv/#1717598) GCE: Fix usage of user-data.
[15:43] <smoser> rharper: can you look at verifying https://bugs.launchpad.net/cloud-init/+bug/1718287
[15:43] <ubot5> Ubuntu bug 1718287 in cloud-init "systemd mount targets fail due to device busy or already mounted" [High,Fix committed]
[15:43] <blackboxsw> or the Azure dhcp networkd test. (need to verify xenial zesty still work
[15:43] <smoser> it is really just a ticky mark we're lookign for as I know you made significant effort to diagnose and verify on trunk.
[15:44] <smoser> or maybe suggest to someone else if they could test with -proposed .
[15:45] <blackboxsw> wow, smoser want to lopk at this. I'm seeing strange behavior from lxc
[15:46] <powersj> We do need to make sure we get MAAS test results, as well as a Curtin, run with cloud-init in proposed per our SRU exception.
[15:46] <blackboxsw> http://paste.ubuntu.com/25760062/  my user-data listed in /var/lib/cloud/instance/user-data.txt
[15:46] <blackboxsw> inside the lxc... but cloud-init.log says: 2017-10-17 15:21:16,445 - cc_runcmd.py[DEBUG]: Skipping module named runcmd, no 'runcmd' key in configuration
[15:47] <powersj> blackboxsw: is runcmd indented under puppet?
[15:47] <blackboxsw> yet is saw the puppet config key and ran that module
[15:47] <blackboxsw> ahh lemme see
[15:47] <blackboxsw> bah
[15:47] <blackboxsw> thanks powersj
[15:47] <blackboxsw> dumb
[15:47] <blackboxsw> what's a silly bit of whitespace between friends
[15:48] <blackboxsw> #timeforstrictschemavalidation
[15:48] <blackboxsw> I love how often I shoot myself in the foot w/ writing the yaml file
[16:14] <blackboxsw> ok done with landscape and puppet SRU verfication
[16:15]  * blackboxsw moves on to - TEST: [f761f2b5](https://git.launchpad.net/cloud-init/commit/?id=f761f2b5) [#1715738](http://pad.lv/#1715738) [#1715690](http://pad.lv/#1715690) cloud-config modules: honor distros definitions in each module
[16:15] <rharper> smoser: yes I'll look at that one (mounts)
[16:19] <blackboxsw> I'll also spin up a xenial-daily on aws for the ipv6 test
[16:39] <blackboxsw> ok done w/ #1715738
[16:39] <blackboxsw> ok done w/ bug#1715738
[16:40] <blackboxsw> onto aws ipv6
[17:10] <smoser> blackboxsw: sorry...  so on http://pad.lv/#1686485
[17:10] <smoser> you were the test you showed didnt really do much... right?
[17:10] <smoser> or was i missing something
[17:10] <smoser> you just tried an invalid 'ntp:' config.
[17:18] <blackboxsw> smoser: that ntp config is valid and should install only the ntp package not timesyncd on xenial zesty
[17:18] <blackboxsw> an emty ntp config only installs the 'ntp
[17:18] <blackboxsw> an emty ntp config only installs the '$ntp' package
[17:19] <blackboxsw> on snappy i'd expect that ntp doesn't get installed
[17:19] <blackboxsw> with that same config
[17:20] <blackboxsw> but yeah the test  didn't intend to test much other than ntp being installed (not broken by our  snappy-related  changes
[17:21] <blackboxsw> admitedly, that test doc needs work, as I have invalid comments about spacewalk/intent there
[17:24] <blackboxsw> I have a couple other tests docs that I've fixed as I went through the testing, I'll copy them into my sru-info in the next couple mins
[17:25] <blackboxsw> and smoser please review the bug verification suggestions I had for these bugs as you are already doing to make sure I
[17:25] <blackboxsw> am not going crazy (or testing nothing)
[17:26] <smoser> blackboxsw: thanks.
[17:26] <smoser> i think you probably gave invalid config there.
[17:27] <smoser> ntp:
[17:27] <smoser> oh. guess not.
[17:27] <smoser> $ python3 -c 'import yaml;  print(yaml.load("ntp:\n"))'
[17:27] <smoser> {'ntp': None}
[17:27] <blackboxsw> If both pools and servers are
[17:27] <blackboxsw>                          empty, 4 default pool servers will be provided of
[17:27] <blackboxsw>                          the format ``{0-3}.{distro}.pool.ntp.org``.
[17:27] <smoser> YYy
[17:27] <blackboxsw> :)
[17:28] <smoser> actually.
[17:28] <blackboxsw> yeah we had a discussion w/ rharper on that when I was doing json schema definition for that module
[17:28] <smoser> code though does
[17:28] <smoser>   if not isinstance(ntp_cfg, (dict)):
[17:28] <blackboxsw> so it should default
[17:28] <smoser> raise runtiome
[17:28] <smoser> i sued
[17:28] <smoser> used
[17:28] <smoser> printf "%s\n%s\n%s\n" "#cloud-config" "ntp:" " pools: []" > my.cfg
[17:28] <blackboxsw>     ntp_cfg = cfg.get('ntp', {})  # at the start though
[17:29] <blackboxsw> so it'll default to empty dict if None
[17:29]  * blackboxsw checks my python 
[17:30] <blackboxsw> umm
[17:30] <blackboxsw> bah
[17:30] <blackboxsw> right if None is actually set for the key, then it falls over as you said, becuase
[17:30] <smoser> mine works.
[17:30] <smoser> and verified.
[17:30] <smoser> are you putting stuff int he bugs ?
[17:32] <blackboxsw> I was going to put the SRU templates in all the bugs once verification is done (and my test scripts are vetted ;) )
[17:32] <blackboxsw> I can start putting the templates up on each bug description for the logs I've already handled
[17:32] <smoser> i'm not rushed on it.
[17:32] <smoser> i'll update the sru template that have.
[17:32] <blackboxsw> but, do you think it's a good idea to put them there?
[17:32] <smoser> would like to show results too...
[17:33] <blackboxsw> sounds good.
[17:34]  * blackboxsw needs to run an errand back in a bit
[17:54] <smoser> powersj: i remember that i was supposed to provide a list of "launch on cloud" commands
[17:54] <smoser> from our sprint
[17:54] <smoser> i dont know that i did
[17:54] <powersj> smoser: correct
[17:54] <smoser> http://paste.ubuntu.com/25760727/
[17:54] <powersj> or a link to a gist :)
[17:55] <smoser> that is what i have.
[17:55] <smoser> just written down once during an sru when i wanted to validate stuff.
[17:55] <powersj> smoser: awesome
[17:59] <intheclouddan[m]> has anyone run into issues with cloud-init and creating multiple directories with mkdir -p? I'm passing in a shell script on AWS that has mkdir -p /opt/path1 /var/log/path1 but when I look at the output of cloud-init it's only showing mkdir =p /opt/path1....I'm really confused as to how this could be happening
[18:02] <smoser> intheclouddan[m]: can you give config you're  using ?
[18:02] <smoser> you're using runcmd?
[18:02] <smoser> runcmd:
[18:02] <smoser>  - [sh, -c, 'mkdir /foo//bar/ /zee/wark']
[18:02] <smoser>  - mkdir /foo/bar /zee/wark
[18:03] <smoser>  - ['mkdir', '/foo/bar', '/zee/wark']
[18:03] <intheclouddan[m]> no passing in a bash script
[18:03] <smoser> well, output shoudl be collected in /var/log/cloud-init-output.log
[18:03] <smoser> i'd look there for errors.
[18:03] <smoser> and also /var/log/cloud-init.log
[18:03] <smoser> for WARN
[18:21] <blackboxsw> nice paste reference smoser
[18:43]  * blackboxsw is trying to figure out (remember) again how I setup the ipv6 association on an instance 
[18:43] <blackboxsw> it seems I had it setup on my xenial vm, but not on my zesty vm
[18:43] <blackboxsw> ... ec2 that is. gotta dig through the docs
[18:44]  * blackboxsw is specifically not asking the tome of smoser knowledge for this, because I want to make this painful for me so I learn it 'right'
[18:49] <rharper> blackboxsw: likely a flag during instance launch under advacned
[18:49] <rharper> google knows the awscli command to toggle it
[18:50] <blackboxsw> heh, tome of rharper knowledge.
[18:50] <rharper> well, possible answers book
[18:50] <blackboxsw> hah
[18:56] <rharper> smoser: testing underway on the fstab one;  an up-to-date xenial VM falls over right away;  -proposed is 8 reboot loops in with no issues;  how far do we want to run up the count to declare success ?
[18:58] <rharper> smoser1: testing underway on the fstab one;  an up-to-date xenial VM falls over right away;  -proposed is 8 reboot loops in with no issues;  how far do we want to run up the count to declare success ?
[19:11] <rharper> blackboxsw: where are we updating our test-case and results for the SRU ?  a single bug, or the various bugs we're validating ?
[19:11] <blackboxsw> rharper: I've only so far been adding a log comment to the megabug. https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1721847
[19:11] <ubot5> Ubuntu bug 1721847 in cloud-init (Ubuntu Zesty) "sru cloud-init 2017-10-06 (17.1-18-gd4f70470-0ubuntu1)" [Medium,Fix committed]
[19:12] <blackboxsw> but when done, all test verification and log output will be updated  on each specific bug description
[19:12] <blackboxsw> so each separate bug that relates to ubuntu will have it's desc updated with verification script  && results
[19:12] <blackboxsw> s/it's/its/
[19:14] <rharper> blackboxsw: ok, so I'll keep my own log for this specific bug, and we can append to both places as needed
[19:16] <rharper> I think I'm going to call success on this case, 1) the change ensures that datasourceOVF doesn't poke any block device unless it has iso9660 files on that; I can verify that current cloud-init pokes *each* block device and -proposed pokes *none*;  I've got about 28 reboots with no issue so far.
[19:37] <blackboxsw> ok sounds good rharper
[19:37] <blackboxsw> thanks for the reboot run. just attaching output of the reboot script w/ anecdotal evidence of # of successful reboots should be good
[19:38] <blackboxsw> I just attached updated SRU validation for ec2 ipv6 support to the megabug
[19:38] <blackboxsw> found the cli params needd
[19:39] <blackboxsw> aws ec2 assign-ipv6-addresses --network-interface-id eni-3b32d910 --ipv6-address-count 1
[19:39] <blackboxsw> then clean-reboot (rm -rf /var/log/cloud-init* /var/lib/cloud*);
[19:41] <blackboxsw> smoser: rharper anyone working on - TEST in artful: [9d2a87dc](https://git.launchpad.net/cloud-init/commit/?id=9d2a87dc) [#1718029](http://pad.lv/#1718029) Azure, CloudStack: Support reading dhcp options from systemd-networkd.?
[19:41] <rharper> blackboxsw: I'm not, collecting my logs for the fstab one
[19:42] <blackboxsw> and s-"=frequent IRC quits"-moser is probably dealing with network issues today :)
[19:45] <smoser> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1724354
[19:45] <ubot5> Ubuntu bug 1724354 in cloud-init (Ubuntu Zesty) "WARNING in logs due to missing python-jsconschema" [Medium,Confirmed]
[19:45] <smoser> :-(
[19:47] <smoser> blackboxsw: that and i am transitioning (i think) to weechat from xchat+bip
[19:48] <smoser> partially as a result of finicky network... i for some reason when teathering i'd get errors connecting to freenode about needing SASL and bip does not support that at all
[19:48] <smoser> so, here i am learning a new irc client.
[19:54] <blackboxsw> heh, agreed, I figured I'd give this irccloud a try for a year, but yeah I'm compelled to go back to xchat+bip. I'm not a fan of the forced backscroll to pull content from overnight or last week etc .
[19:55] <blackboxsw> so irccloud you have to keep requesting to download a zipped collection of all IRC back channels so you can grep them etc.
[19:57] <blackboxsw> smoser: I'm working on cmdline azure test for SRU
[19:57] <blackboxsw> and I'll update the sru-info/bug for that when I get the magic
[20:13] <blackboxsw> just ran into this v
[20:13] <blackboxsw> https://github.com/Azure/azure-cli/issues/4692
[20:13] <blackboxsw> on azure-cli (artful)
[20:13] <blackboxsw> trying xenial
[20:15] <smoser> blackboxsw: fun
[20:16] <blackboxsw> yeah, tempted to just use the UI for the moment. even the cli install instructions are busticated.
[20:16] <smoser> blackboxsw: hold on.
[20:17] <blackboxsw> smoser: can you check your env for where you grabbed "azure" cli
[20:17] <smoser> https://gist.github.com/smoser/5806147/
[20:17] <smoser> 'azure' is the node version
[20:17] <smoser> 'az' is the (newly favored) python client.
[20:19] <smoser> i think if you use that 'az-ubuntu' it should work
[20:20] <smoser> worked for me a couple days ago
[20:20] <smoser> spits a command line like you'd never want to type
[20:20] <smoser> $ az-ubuntu . --dry-run
[20:21] <smoser> az vm create --name=smoser1017x --image=Canonical:UbuntuServer:16.04-DAILY-LTS:latest --admin-username=smoser "--ssh-key-value=ssh-rsa AAAAB3...keydata.kerhe...Hw== smoser@brickies"
[20:22] <blackboxsw> awsome thanks
[20:38] <smoser> blackboxsw: you can 'snap install azure-cli' . i think i just installed it with pip.
[20:38] <blackboxsw> npm version works well
[20:39] <blackboxsw> at least for login and group creation
[20:39] <blackboxsw> still looking over your az-ubuntu
[20:42] <smoser> blackboxsw: its a mess. :) 'azure-ubuntu' (which may well work if you have the npm cli) was what i had originally, but that only works with the old 'asm' mdoe.
[20:43] <blackboxsw> looks like cmdline options changed
[20:43] <blackboxsw> here's what works for me
[20:43]  * rharper moves to zesty for the fstab tessts 
[20:43] <rharper> tests even
[20:43] <blackboxsw> azure vm create  -n xenial-azure-test -g srugroup1 --image-urn=Canonical:UbuntuServer:17.04-DAILY:latest --ssh-publickey-file=/id_rsa.pub --admin-username=ubuntu
[20:44] <blackboxsw> hrm looks like it's still prompting me for location even though my group is defined in useast2
[20:45] <blackboxsw> man naming convention is bogus eastus2 not useast2
[20:45] <blackboxsw> improper ordering
[20:46] <blackboxsw> just to be != EC2
[20:47] <smoser> blackboxsw: it changed too between ASM and ARM mode
[20:48] <rharper> what about that launcher that Robert had ?
[20:49] <smoser> Robert ?
[20:49] <smoser> rcj ?
[20:50] <rharper> SUSE
[21:17] <smoser> blackboxsw: https://gist.github.com/smoser/5806147
[21:17] <smoser> that is updated, and just "worked for me" here.
[21:26] <blackboxsw> trying again. I went UI for xenial
[21:26] <blackboxsw> but will test
[21:26] <smoser> well, it did just work for me.
[21:26] <smoser> and i mentioned that you ahve to add the group
[21:26] <smoser> thats a pita
[21:26] <smoser> but.. oh well, and also showed how to get a list of locations.
[21:26]  * smoser goes to dinner
[21:42] <blackboxsw> smoser: here's the diff to your script that works for me http://paste.ubuntu.com/25761944/
[21:46] <blackboxsw> since I'm also reckless and run as root in my lxc I also specify --admin-username=ubuntu as azure is smart and says (don't use root)
[22:05] <blackboxsw> ok azure  verification done. thx smoser  for the az-ubuntu love
[22:13]  * rharper kicks off recreate loop on zesty instance and grabs dinner 
[22:14] <blackboxsw> smoser: I'm marking Azure validated for https://bugs.launchpad.net/cloud-init/+bug/1718029  for the cloudstack component. we'll probably just notify the most recent interested party
[22:14] <ubot5> Ubuntu bug 1718029 in cloud-init "cloudstack and azure datasources broken when using netplan/systemd-networkd" [High,Fix committed]
[22:14] <blackboxsw> rharper: same above
[22:21] <blackboxsw> ok two SRU bugs remain needing verification
[22:21] <blackboxsw> - TEST: [da6562e2](https://git.launchpad.net/cloud-init/commit/?id=da6562e2) [#1718287](http://pad.lv/#1718287) DataSourceOVF: use util.find_devs_with(TYPE=iso9660)
[22:21] <blackboxsw> I think rharper is on this one
[22:22] <blackboxsw> ^
[22:22] <blackboxsw> and I think smoser is on this one - TEST: [10f067d8](https://git.launchpad.net/cloud-init/commit/?id=10f067d8) [#1717598](http://pad.lv/#1717598) GCE: Fix usage of user-data.
[22:22] <blackboxsw> for tomorrow of course.
[22:22] <blackboxsw> but I think that wraps up ubuntu's 17.1 SRU  for xenial/zesty
[23:21] <rharper> ah, that's why we can't recreate on Zesty, it only runs the EC2 datasource since Zesty doesn't have the backwards compat ds-identify configuration; we  never run OVF on Zesty EC2 instances
[23:22] <rharper> smoser: blackboxsw: so, I think in the SRU detail I'm mention that Zesty doesn't run the OVF datasource so the bug was never present there;
[23:41] <rharper> blackboxsw: smoser: ok, updated fstab test-case log;  on zesty which used strict-mode ds-identify, OVF never runs so it always passed, I showed that it worked on current version and proposed didn't regress that.