[14:05] <larsks> smoser: you around yet?
[14:08] <larsks> When you are: Someone had a system on which /etc/resolv.conf was mode 0444, causing cloud-init to fail with a traceback.  It would be better if we logged an error and continued instead.  Should this be in util.write_file itself, or should this be "on the edge", e.g., have explicit try/except blocks for particular files?
[14:14] <smoser> larsks, here.
[14:15] <smoser> you're asking if write_file should have a "on failure just warn" option ?
[14:15] <smoser> or "on failure call this function with the exception" ?
[14:16] <smoser> this sort of stuff is hard though...
[14:16] <larsks> Or if we should even default to that.  The problem with tracebacks in cloud-init is that it can cause cloud-init to exit before it has done things like configure credentials, making it impossible to log into a system.
[14:16] <smoser> if cloud-init can't write your /etc/resolv.conf (and it thinks it should), then stuff quite likely not going to work all that well
[14:16] <smoser> if all we do is just warn, then no one will ever file a bug
[14:16] <larsks> Well, in this case, it was just resolv.conf that was a problem.  Everything else would have worked just fine.
[14:17] <larsks> I agree that fundamentally the bug in this case is somewhere else (who knows where, though).
[14:17] <larsks> But I wonder if we should handle this situation with more aplomb.
[14:19]  * smoser brings up dictionary.com
[14:19] <larsks> s/with more aplomb/more gracefully/
[14:19] <smoser> :)
[14:19] <smoser> self-confidence or assurance, especially when in a demanding situation.
[14:20] <smoser> larsks, but yeah, i agree there is a general problem.
[14:20] <smoser> something goes wrong, and user can't get in to help tell you what
[14:20] <smoser> the stack traces at least do go to the console i hope. but that is often times not enough.
[14:22] <smoser> i'm interested in ideas
[14:22] <smoser> i dont want to sound like i'm trying to block you fixing an issue.
[14:23] <larsks> Don't worry, you're not.  I'm honestly not sure what the best choice is.  I feel like a fix that is specific to resolv.conf is the wrong way to go, but I'm not sure that a blanket "always warn never traceback" policy is any better.
[15:08] <larsks> smoser: what about this (this is against 0.7.9): http://chunk.io/f/e65bff7039714d498dbb6c683fa0edce
[15:09] <larsks> That would allow network configuration to fail w/o bombing out completely which...might be better? I dunno.  I give up for now :)
[15:23] <dpb1> smoser, rharper: FYI: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1701297
[15:25] <rharper> =/
[15:25] <rharper> there's not a lot going on
[15:28] <rharper> dpb1: one wonders why they don't run a -proposed test
[15:30] <dpb1> it's almost like we should all be doing proposed testing!
[15:30] <rharper> no way
[15:30] <dpb1> let's all send that round the echo chamber
[15:30] <rharper> too much work
[15:30] <powersj> rharper: smoser "2017-06-29 15:29:06,765 - util.py[WARNING]: failed read of /sys/class/dmi/id/product_serial"
[15:30] <rharper> I'd rather wait till it breaks in the archive
[15:30] <powersj> that was on lxc ubuntu-daily:xenial updated to verison in proposed after cleaning out /var/lib
[15:33] <smoser> powersj, thanks. unfortunate.
[15:33] <powersj> cloud-init is still running
[15:33] <powersj> but here are logs
[15:33] <powersj> https://paste.ubuntu.com/24982063/
[15:33] <powersj> https://paste.ubuntu.com/24982065/
[15:34] <powersj> should I try without proposed enabled?
[15:34] <powersj> just to make sure this isn't my own system
[15:40] <powersj> smoser: I ran with the version in updates, blew away /var/lib/cloud, and same thing happened. Here is a full log: https://paste.ubuntu.com/24982084/
[16:38] <smoser> powersj, :-(
[16:38] <powersj> sounds like a new bug?
[16:39] <smoser> i dont see it in 0.7.9-153-g16a7302f-0ubuntu1~16.04.2
[16:39] <smoser> i used lxc-proposed-snapshot
[16:40] <smoser> this is in a lxc, right ?
[16:40] <powersj> yeah
[16:41] <smoser> i jsut tried
[16:41] <smoser>  lxc launch ubuntu-daily:xenial x1t
[16:42] <smoser>  .. wait ..
[16:42] <powersj> https://paste.ubuntu.com/24982658/
[16:42] <powersj> something like ^
[16:42] <smoser>  enter, enable prposed update ...
[16:42] <smoser>  reboot
[16:43] <smoser> oh
[16:43] <smoser> right
[16:43] <smoser> yeah
[16:43] <smoser> whew
[16:44] <smoser> so you cleaned out /var/lib/cloud/seed/
[16:44] <smoser> which is where lxc put its datasource
[16:44] <smoser> so... this time there was no datasource
[16:44] <powersj> ahhhh
[16:44] <smoser> and it tried everything looking for one.
[16:44] <powersj> yeah that makes sense why it took so long to complete then
[16:45] <smoser> https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/tree/bin/do-reboot
[16:45] <smoser> do-reboot has 'clean' option. which cleans in a lxc-friendly way
[16:46] <powersj> will that work on other clouds as well?
[16:46] <smoser> yeah
[16:46] <powersj> sweet
[16:46] <smoser> rm -Rf /var/lib/cloud works everywhere except for lxc (and Softlayer, which does really wierd things)
[16:46] <powersj> heh
[16:46] <smoser> the seed dir really should be elsewhere.
[16:46] <smoser> hindsight
[17:04] <powersj> smoser: rharper: tested a few clouds and put pastebins of logs into the card
[17:05] <powersj> Basically updated to proposed + rebooted then got logs; then cleared out /var/lib/cloud + rebooted then got logs;
[17:05] <powersj> I didn't see anything out of the ordinary in any of the logs
[17:06] <smoser> right. no WARN string
[17:06] <smoser> i just opened https://bugs.launchpad.net/cloud-init/+bug/1701325
[17:07] <smoser> and will fix that, but that is artful (and trunk) only at this point
[17:07] <powersj> thx
[17:08] <powersj> the only areas I haven't done is openstack, I have to find my creds
[17:08] <powersj> and I did no-cloud via uvt-kvm, so does that count for kvm and no-cloud?
[17:19] <smoser> powersj, yes. that was good.t hank you.
[17:37] <smoser> https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/326546
[17:37] <smoser> powersj, ^
[17:38] <powersj> smoser: awesome, I'll give it a shot when I get back, need to run to Dr real quick
[17:39] <smoser> kind of wierd
[17:39] <smoser> az group delete --name=foo
[17:41] <smoser> does not require a --location
[17:41] <smoser> but az group create *does*
[17:42] <smoser> group names are unique across regions
[19:18] <paulmey> ola
[19:19] <paulmey> az group location is the region that will be the primary master of that group
[19:19] <paulmey> i.e. where it is administered
[19:19] <paulmey> not sure if that makes sense
[19:24] <smoser> right. it does make sense.
[19:25] <smoser> i didn't realize at first that group names were "global", and thought that vm create *required* a --location.  so i was mostly just confused.
[19:25] <smoser> i'm sorted now.
[19:25] <smoser> paulmey, is there a way to launch (with 'az') by "sku" ?
[19:26] <smoser> i think there is some magic that picks the most recent version of a sku in the portal
[19:26] <smoser> and i'd like to launch with 17.10-DAILY
[19:27] <smoser> since there is no obvious way for me to get the urn of "latest".
[19:27] <smoser> https://bugs.launchpad.net/cloud-images/+bug/1701062
[19:27] <paulmey> do `az vm image list --publisher Canonical --all -o table` to see all available images
[19:28] <paulmey> then, use the urn in the --image parameter for `az vm create`
[19:28] <paulmey> instead of a version, you can specify :latest, which will use latest
[19:29] <paulmey> so something like `az vm create -n testvm -g $rg --image Canonical:UbuntuServer:17.10-DAILY:latest -l westus2`
[19:30] <paulmey> the portal is 'curated' with nice pictures and stuff... it's a separate process... don't ask. :-)
[19:31] <smoser> so a urn is not really a 'urn'
[19:32] <smoser> (i assume that is "universal resource name")
[19:32] <smoser> but that is a very helpful answer, thanks.
[19:32] <smoser> so that works for the cli
[19:32] <smoser> it'd be nice for *me* at least if the portal allowed you to specifically provide it with a urn like that.
[19:34] <smoser> its kind of unfortunate that our sku for lts contains the string lts
[19:35] <smoser> that  makes launching things much more difficult than necessary
[19:35] <smoser> UbuntuServer:16.04-DAILY-LTS:latest
[19:35] <smoser> but
[19:35] <smoser> UbuntuServer:16.10-DAILY:latest
[19:39] <paulmey> I can see that... You can talk to the cloud image team to see what their reasons were
[19:40] <paulmey> and yes, it's more like a colon-separated-value thing... but anyways... it's quite useful
[19:41] <paulmey> I think they added -LTS in the sku to indicate to cli users that it's an lts version
[19:41] <paulmey> it would be nice if we had some way to define aliases for images/skus...
[19:42] <paulmey> but that's not on the horizon...
[19:42] <smoser> it doesnt really seem very "helpful". other than to someone who is looking at a list of skus, *and* doesn't know which ubuntu releases are lts.
[19:43] <smoser> ie, thats kind of "low tech". but they made it more difficult for someone trying to be smarter.
[19:43] <smoser> anywah. oh well.
[19:43] <smoser> other request that might hvae been lost up above was for the portal to let me put a urn in for the image...r ather than just letting me search.
[19:43] <smoser> maybe thats possible and i just dont know.
[19:48] <paulmey> I don't think there is a standard form in the portal, but you could do something like https://github.com/Azure/azure-quickstart-templates/tree/master/101-vm-simple-linux
[19:48] <paulmey> I think that particular template is a bit outdated, but the 'deploy' link in the readme.md opens it up in the portal
[19:49] <paulmey> you can put your own values in the parameters section or just leave it user-editable...
[19:50] <paulmey> is that close to what you're looking for?
[20:01] <smoser> hm..
[20:03] <smoser> thats neat
[20:03] <smoser> thanks paulmey
[20:06] <paulmey> np
[21:36] <smoser> rharper, powersj
[21:36] <smoser> https://code.launchpad.net/~cloud-init-dev/+recipe/cloud-init-daily-xenial
[21:36] <smoser> and friends (-yakkety, -zesty) should be good now.
[21:36] <smoser> and dailiy archive builds should not pick up the jsonschema dependency
[21:38] <powersj> smoser: what change caused that?
[21:54] <smoser> powersj, https://git.launchpad.net/cloud-init/commit/?h=ubuntu/xenial&id=0debd0ab3104812e92f6927c91d38fbeec768d98
[21:55] <powersj> ah
[22:05] <rharper> smoser: cool