larsks | smoser: you around yet? | 14:05 |
---|---|---|
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:08 |
smoser | larsks, here. | 14:14 |
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:15 |
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:16 |
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:17 |
* 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:19 |
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:20 |
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:22 |
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. | 14:23 |
larsks | smoser: what about this (this is against 0.7.9): http://chunk.io/f/e65bff7039714d498dbb6c683fa0edce | 15:08 |
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:09 |
dpb1 | smoser, rharper: FYI: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1701297 | 15:23 |
ubot5 | Ubuntu bug 1701297 in cloud-init "NTP reload failure (causing deployment failures with MAAS)" [Undecided,Incomplete] | 15:23 |
rharper | =/ | 15:25 |
rharper | there's not a lot going on | 15:25 |
rharper | dpb1: one wonders why they don't run a -proposed test | 15:28 |
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:30 |
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:33 |
powersj | should I try without proposed enabled? | 15:34 |
powersj | just to make sure this isn't my own system | 15:34 |
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/ | 15:40 |
smoser | powersj, :-( | 16:38 |
powersj | sounds like a new bug? | 16:38 |
smoser | i dont see it in 0.7.9-153-g16a7302f-0ubuntu1~16.04.2 | 16:39 |
smoser | i used lxc-proposed-snapshot | 16:39 |
smoser | this is in a lxc, right ? | 16:40 |
powersj | yeah | 16:40 |
smoser | i jsut tried | 16:41 |
smoser | lxc launch ubuntu-daily:xenial x1t | 16:41 |
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:42 |
smoser | oh | 16:43 |
smoser | right | 16:43 |
smoser | yeah | 16:43 |
smoser | whew | 16:43 |
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:44 |
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:45 |
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 | 16:46 |
powersj | smoser: rharper: tested a few clouds and put pastebins of logs into the card | 17:04 |
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:05 |
smoser | right. no WARN string | 17:06 |
smoser | i just opened https://bugs.launchpad.net/cloud-init/+bug/1701325 | 17:06 |
ubot5 | 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:06 |
smoser | and will fix that, but that is artful (and trunk) only at this point | 17:07 |
powersj | thx | 17:07 |
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:08 |
smoser | powersj, yes. that was good.t hank you. | 17:19 |
smoser | https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/326546 | 17:37 |
smoser | powersj, ^ | 17:37 |
powersj | smoser: awesome, I'll give it a shot when I get back, need to run to Dr real quick | 17:38 |
smoser | kind of wierd | 17:39 |
smoser | az group delete --name=foo | 17:39 |
smoser | does not require a --location | 17:41 |
smoser | but az group create *does* | 17:41 |
smoser | group names are unique across regions | 17:42 |
paulmey | ola | 19:18 |
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:19 |
smoser | right. it does make sense. | 19:24 |
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:25 |
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:26 |
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 |
ubot5 | Ubuntu bug 1701062 in cloud-images "azure stream data is not useful for 'arm' (Azure Resource Manager) mode" [Medium,Confirmed] | 19:27 |
paulmey | do `az vm image list --publisher Canonical --all -o table` to see all available images | 19:27 |
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:28 |
paulmey | so something like `az vm create -n testvm -g $rg --image Canonical:UbuntuServer:17.10-DAILY:latest -l westus2` | 19:29 |
paulmey | the portal is 'curated' with nice pictures and stuff... it's a separate process... don't ask. :-) | 19:30 |
smoser | so a urn is not really a 'urn' | 19:31 |
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:32 |
smoser | its kind of unfortunate that our sku for lts contains the string lts | 19:34 |
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:35 |
paulmey | I can see that... You can talk to the cloud image team to see what their reasons were | 19:39 |
paulmey | and yes, it's more like a colon-separated-value thing... but anyways... it's quite useful | 19:40 |
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:41 |
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:42 |
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:43 |
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:48 |
paulmey | you can put your own values in the parameters section or just leave it user-editable... | 19:49 |
paulmey | is that close to what you're looking for? | 19:50 |
smoser | hm.. | 20:01 |
smoser | thats neat | 20:03 |
smoser | thanks paulmey | 20:03 |
paulmey | np | 20:06 |
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:36 |
powersj | smoser: what change caused that? | 21:38 |
smoser | powersj, https://git.launchpad.net/cloud-init/commit/?h=ubuntu/xenial&id=0debd0ab3104812e92f6927c91d38fbeec768d98 | 21:54 |
powersj | ah | 21:55 |
rharper | smoser: cool | 22:05 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!