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