/srv/irclogs.ubuntu.com/2017/06/29/#cloud-init.txt

larskssmoser: you around yet?14:05
larsksWhen 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:08
smoserlarsks, here.14:14
smoseryou're asking if write_file should have a "on failure just warn" option ?14:15
smoseror "on failure call this function with the exception" ?14:15
smoserthis sort of stuff is hard though...14:16
larsksOr 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
smoserif cloud-init can't write your /etc/resolv.conf (and it thinks it should), then stuff quite likely not going to work all that well14:16
smoserif all we do is just warn, then no one will ever file a bug14:16
larsksWell, in this case, it was just resolv.conf that was a problem.  Everything else would have worked just fine.14:16
larsksI agree that fundamentally the bug in this case is somewhere else (who knows where, though).14:17
larsksBut I wonder if we should handle this situation with more aplomb.14:17
* smoser brings up dictionary.com14:19
larskss/with more aplomb/more gracefully/14:19
smoser:)14:19
smoserself-confidence or assurance, especially when in a demanding situation.14:19
smoserlarsks, but yeah, i agree there is a general problem.14:20
smosersomething goes wrong, and user can't get in to help tell you what14:20
smoserthe stack traces at least do go to the console i hope. but that is often times not enough.14:20
smoseri'm interested in ideas14:22
smoseri dont want to sound like i'm trying to block you fixing an issue.14:22
larsksDon'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.14:23
larskssmoser: what about this (this is against 0.7.9): http://chunk.io/f/e65bff7039714d498dbb6c683fa0edce15:08
larsksThat would allow network configuration to fail w/o bombing out completely which...might be better? I dunno.  I give up for now :)15:09
dpb1smoser, rharper: FYI: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/170129715:23
ubot5Ubuntu bug 1701297 in cloud-init "NTP reload failure (causing deployment failures with MAAS)" [Undecided,Incomplete]15:23
rharper=/15:25
rharperthere's not a lot going on15:25
rharperdpb1: one wonders why they don't run a -proposed test15:28
dpb1it's almost like we should all be doing proposed testing!15:30
rharperno way15:30
dpb1let's all send that round the echo chamber15:30
rharpertoo much work15:30
powersjrharper: smoser "2017-06-29 15:29:06,765 - util.py[WARNING]: failed read of /sys/class/dmi/id/product_serial"15:30
rharperI'd rather wait till it breaks in the archive15:30
powersjthat was on lxc ubuntu-daily:xenial updated to verison in proposed after cleaning out /var/lib15:30
smoserpowersj, thanks. unfortunate.15:33
powersjcloud-init is still running15:33
powersjbut here are logs15:33
powersjhttps://paste.ubuntu.com/24982063/15:33
powersjhttps://paste.ubuntu.com/24982065/15:33
powersjshould I try without proposed enabled?15:34
powersjjust to make sure this isn't my own system15:34
powersjsmoser: 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/15:40
smoserpowersj, :-(16:38
powersjsounds like a new bug?16:38
smoseri dont see it in 0.7.9-153-g16a7302f-0ubuntu1~16.04.216:39
smoseri used lxc-proposed-snapshot16:39
smoserthis is in a lxc, right ?16:40
powersjyeah16:40
smoseri jsut tried16:41
smoser lxc launch ubuntu-daily:xenial x1t16:41
smoser .. wait ..16:42
powersjhttps://paste.ubuntu.com/24982658/16:42
powersjsomething like ^16:42
smoser enter, enable prposed update ...16:42
smoser reboot16:42
smoseroh16:43
smoserright16:43
smoseryeah16:43
smoserwhew16:43
smoserso you cleaned out /var/lib/cloud/seed/16:44
smoserwhich is where lxc put its datasource16:44
smoserso... this time there was no datasource16:44
powersjahhhh16:44
smoserand it tried everything looking for one.16:44
powersjyeah that makes sense why it took so long to complete then16:44
smoserhttps://git.launchpad.net/~smoser/cloud-init/+git/sru-info/tree/bin/do-reboot16:45
smoserdo-reboot has 'clean' option. which cleans in a lxc-friendly way16:45
powersjwill that work on other clouds as well?16:46
smoseryeah16:46
powersjsweet16:46
smoserrm -Rf /var/lib/cloud works everywhere except for lxc (and Softlayer, which does really wierd things)16:46
powersjheh16:46
smoserthe seed dir really should be elsewhere.16:46
smoserhindsight16:46
powersjsmoser: rharper: tested a few clouds and put pastebins of logs into the card17:04
powersjBasically updated to proposed + rebooted then got logs; then cleared out /var/lib/cloud + rebooted then got logs;17:05
powersjI didn't see anything out of the ordinary in any of the logs17:05
smoserright. no WARN string17:06
smoseri just opened https://bugs.launchpad.net/cloud-init/+bug/170132517:06
ubot5Ubuntu bug 1701325 in cloud-init (Ubuntu) "attempt to read dmi data can cause warning and stacktrace in logs in a container." [Undecided,New]17:06
smoserand will fix that, but that is artful (and trunk) only at this point17:07
powersjthx17:07
powersjthe only areas I haven't done is openstack, I have to find my creds17:08
powersjand I did no-cloud via uvt-kvm, so does that count for kvm and no-cloud?17:08
smoserpowersj, yes. that was good.t hank you.17:19
smoserhttps://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/32654617:37
smoserpowersj, ^17:37
powersjsmoser: awesome, I'll give it a shot when I get back, need to run to Dr real quick17:38
smoserkind of wierd17:39
smoseraz group delete --name=foo17:39
smoserdoes not require a --location17:41
smoserbut az group create *does*17:41
smosergroup names are unique across regions17:42
paulmeyola19:18
paulmeyaz group location is the region that will be the primary master of that group19:19
paulmeyi.e. where it is administered19:19
paulmeynot sure if that makes sense19:19
smoserright. it does make sense.19:24
smoseri 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
smoseri'm sorted now.19:25
smoserpaulmey, is there a way to launch (with 'az') by "sku" ?19:25
smoseri think there is some magic that picks the most recent version of a sku in the portal19:26
smoserand i'd like to launch with 17.10-DAILY19:26
smosersince there is no obvious way for me to get the urn of "latest".19:27
smoserhttps://bugs.launchpad.net/cloud-images/+bug/170106219:27
ubot5Ubuntu bug 1701062 in cloud-images "azure stream data is not useful for 'arm' (Azure Resource Manager) mode" [Medium,Confirmed]19:27
paulmeydo `az vm image list --publisher Canonical --all -o table` to see all available images19:27
paulmeythen, use the urn in the --image parameter for `az vm create`19:28
paulmeyinstead of a version, you can specify :latest, which will use latest19:28
paulmeyso something like `az vm create -n testvm -g $rg --image Canonical:UbuntuServer:17.10-DAILY:latest -l westus2`19:29
paulmeythe portal is 'curated' with nice pictures and stuff... it's a separate process... don't ask. :-)19:30
smoserso a urn is not really a 'urn'19:31
smoser(i assume that is "universal resource name")19:32
smoserbut that is a very helpful answer, thanks.19:32
smoserso that works for the cli19:32
smoserit'd be nice for *me* at least if the portal allowed you to specifically provide it with a urn like that.19:32
smoserits kind of unfortunate that our sku for lts contains the string lts19:34
smoserthat  makes launching things much more difficult than necessary19:35
smoserUbuntuServer:16.04-DAILY-LTS:latest19:35
smoserbut19:35
smoserUbuntuServer:16.10-DAILY:latest19:35
paulmeyI can see that... You can talk to the cloud image team to see what their reasons were19:39
paulmeyand yes, it's more like a colon-separated-value thing... but anyways... it's quite useful19:40
paulmeyI think they added -LTS in the sku to indicate to cli users that it's an lts version19:41
paulmeyit would be nice if we had some way to define aliases for images/skus...19:41
paulmeybut that's not on the horizon...19:42
smoserit 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:42
smoserie, thats kind of "low tech". but they made it more difficult for someone trying to be smarter.19:43
smoseranywah. oh well.19:43
smoserother 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
smosermaybe thats possible and i just dont know.19:43
paulmeyI 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-linux19:48
paulmeyI think that particular template is a bit outdated, but the 'deploy' link in the readme.md opens it up in the portal19:48
paulmeyyou can put your own values in the parameters section or just leave it user-editable...19:49
paulmeyis that close to what you're looking for?19:50
smoserhm..20:01
smoserthats neat20:03
smoserthanks paulmey20:03
paulmeynp20:06
smoserrharper, powersj21:36
smoserhttps://code.launchpad.net/~cloud-init-dev/+recipe/cloud-init-daily-xenial21:36
smoserand friends (-yakkety, -zesty) should be good now.21:36
smoserand dailiy archive builds should not pick up the jsonschema dependency21:36
powersjsmoser: what change caused that?21:38
smoserpowersj, https://git.launchpad.net/cloud-init/commit/?h=ubuntu/xenial&id=0debd0ab3104812e92f6927c91d38fbeec768d9821:54
powersjah21:55
rharpersmoser: cool22:05

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!