| smoser | blackboxsw, yeah, i got the gist. | 01:00 |
|---|---|---|
| smoser | blackboxsw, your python2 shines through | 01:08 |
| smoser | (iteritems() is not python3 :) | 01:08 |
| smoser | pushed to https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+ref/cleanup/mask2cidr | 01:13 |
| blackboxsw | whoopsie. right grr, need to be more careful | 01:22 |
| smoser | <smoser> powersj, if your'e still arond | 01:41 |
| smoser | <smoser> i think that centos6 migith be as easy as | 01:41 |
| smoser | <smoser> https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/324585 | 01:41 |
| smoser | blackboxsw, then... some python2.6 breakage from ntp | 01:41 |
| smoser | :-( | 01:41 |
| smoser | http://paste.ubuntu.com/24650034/ | 01:41 |
| smoser | there... https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/324585 | 01:45 |
| smoser | that fix there too now | 01:45 |
| smoser | and /me goes away 25 minuts late | 01:46 |
| askb | smoser, seems like running into other ssh issues with 0.7.9 | 02:42 |
| blackboxsw | https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/324585 approved | 02:42 |
| askb | smoser, here are the logs: http://paste.openstack.org/show/610611/ | 02:45 |
| powersj | I propose we use 0.8 to drop python 2.6 support ;) centos 6 dropped full update last month and is only in maitence mode if I am reading dates right. | 03:14 |
| askb | powersj, is there a python version dependency for cloud-init to work with centos7 ? | 03:20 |
| powersj | askb: I think since centos 7 has 2.7 if I recall it isn't an issue | 03:23 |
| askb | powersj, is 0.7.9 tested to work with centos7, running into issues: http://paste.openstack.org/show/610611/ | 03:26 |
| askb | powersj, mainly with ssh restart failure and failed to disable password for ubuntu user | 03:27 |
| askb | Is this a known issue ? | 03:27 |
| powersj | I'm not familiar with any issues, if you run the command manually what happens? | 03:30 |
| powersj | As far as testing l, all I have in place right now is unit testing and package build. Working on getting some initial integration tests going next month. | 03:30 |
| powersj | All on centos 6/7 | 03:30 |
| powersj | I'm not too sure how the version of cloud init gets into the images or that process but also need to research that | 03:31 |
| askb | how do you run the cmd manually ? | 03:32 |
| powersj | Askb did you file a bug? | 03:32 |
| askb | cloud-init single -n cc_scripts_user | 03:32 |
| askb | yes - the original issue was with version 0.7.5 which is pretty old from centos7 repo | 03:33 |
| askb | bug: https://bugs.launchpad.net/cloud-init/+bug/1692424 | 03:33 |
| ubot5 | Ubuntu bug 1692424 in cloud-init "util.py[WARNING]: Failed to disable password for user centos" [Undecided,New] | 03:33 |
| powersj | Sorry to be more clear, try running the failing commans "passwd -l ubuntu" | 03:33 |
| askb | so I built an rpm with 0.7.9, now testing it again with the latest centos7 image has brought me to http://paste.openstack.org/show/610611/ | 03:34 |
| askb | for running the cmd manually, now my user data script is not even available under /var/lib/cloud/scripts/* | 03:36 |
| powersj | askb, Hmm I can try to look in the morning, easier when I'm not on my phone. Thanks for filing a big. Tbh I'm not familiar with the heat templates, but will look | 03:39 |
| askb | powersj, thanks would appreciate that! ... btw ... there are several post on the net with users running into similar issues with 0.7.5 with no solution/work around unfortunately | 03:41 |
| powersj | askb: if you have time can you add an example of those posts to the bug as well as what image you are using in the first place | 03:42 |
| askb | sure thing! | 03:43 |
| askb | 2017-05-25 03:48:22,464 - util.py[WARNING]: Failed to disable password for user ubuntu | 03:49 |
| askb | 2017-05-25 03:48:22,465 - util.py[WARNING]: Running module users-groups (<module 'cloudinit.config.cc_users_groups' from '/usr/lib/python2.7/site-packages/cloudinit/config/cc_users_groups.pyc'>) failed | 03:49 |
| === sambetts|afk is now known as sambetts | ||
| === rangerpbzzzz is now known as rangerpb | ||
| smoser | blackboxsw, you have merge conflicts https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/324499 | 15:34 |
| blackboxsw | smoser: oops botched the conflict resolution in lp, clean proposal is at https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/324640 | 17:18 |
| === sambetts is now known as sambetts|afk | ||
| blackboxsw | trashed cc-ntp-schema branch | 17:18 |
| blackboxsw | s/trashed/deleted | 17:19 |
| smoser | blackboxsw, ok. i will review locally | 17:20 |
| blackboxsw | thanks | 17:21 |
| smoser | blackboxsw, fyi, that has c-i Needs fixing | 17:21 |
| blackboxsw | looking it over | 17:21 |
| smoser | blackboxsw, | 17:23 |
| smoser | $ ./tools/cloudconfig-schema --doc # to dump rst from the schema definition | 17:23 |
| smoser | bash: ./tools/cloudconfig-schema: No such file or directory | 17:23 |
| blackboxsw | smoser: are you refering to "RuntimeError: Device /dev/xdb1 did not exist and was not created with a udevamd settle."/ | 17:23 |
| smoser | i was talking about https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/324640 | 17:24 |
| smoser | blackboxsw, and also ^ . wasa the description still supposed to be valid ? | 17:24 |
| smoser | you didnt add tools/cloudconfig-scheme | 17:25 |
| smoser | you didnt add tools/cloudconfig-schema | 17:25 |
| blackboxsw | smoser: just pushed thx | 17:25 |
| blackboxsw | 4858a34 | 17:26 |
| smoser | blackboxsw, git push --force ? | 17:31 |
| smoser | i dont see it here. | 17:31 |
| blackboxsw | smoser: now? | 17:31 |
| smoser | blackboxsw, https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+ref/cc-ntp-schema-validation | 17:35 |
| smoser | "28 minutes ago" | 17:35 |
| blackboxsw | smoser: dumb. fixed | 17:40 |
| blackboxsw | PEBKAC | 17:40 |
| sauloaislan | Hi!! | 17:43 |
| sauloaislan | I'm having a problem, my cloud init does not work on openstack with network interface neutron. I'm doing a deploy with network interface neutron using a simple cloud init, but I can not log in to the VM. | 17:46 |
| smoser | sauloaislan, can you see a console log ? | 17:47 |
| smoser | or ideally you can get the cloud-init.log file off the system as that will likely have some info. | 17:47 |
| sauloaislan | If I do a deploy with the network flat interface and the same cloud init I can login | 17:48 |
| rharper | smoser: hrm, so, the .link files for rename are somewhat racy with udevd and the udev hotplug rules 80-ifupdown.rules I'm seeing the ipv6 vlan network configuration ... | 17:58 |
| smoser | rharper, i dont think they should be racy | 18:00 |
| rharper | well, I wish it weren't either | 18:00 |
| smoser | it should be very deterministic. it may not do what you want. but i dont think it should be racy. | 18:00 |
| smoser | the .link files definitely run last | 18:01 |
| smoser | and only apply if the device hasnt already been renamed | 18:01 |
| smoser | (that is what i recall at least) | 18:01 |
| rharper | I need to keep digging, but if I move the .link files out of the way, it all works fine; | 18:02 |
| rharper | my concern is that I don't at which point the .link files apply vs. when the 80-ifupdown.rules run ; this is all prior to cloud-init local; | 18:02 |
| smoser | https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1579130 | 18:02 |
| ubot5 | Ubuntu bug 1579130 in systemd (Ubuntu) "need to support renaming of devices in container and on first boot" [Wishlist,Triaged] | 18:02 |
| smoser | theres a lot of info there. | 18:02 |
| rharper | it appears like the interfaces are already named correctly but there's something going on with the vlan interface names | 18:02 |
| smoser | remember the .link files get into the initramfs | 18:03 |
| smoser | (although the udev rules would to) | 18:03 |
| rharper | hrm | 18:03 |
| rharper | on the second reboot ? | 18:03 |
| rharper | or after reboot,? | 18:03 |
| smoser | well, cloud-init doesnt actully force re-generation of initramfs | 18:03 |
| smoser | as that'd be really heavy | 18:04 |
| smoser | and as we found in that bug above, wouldnt necessarily fix anything | 18:04 |
| smoser | so cloud-init makes sure it renames everthing it can by itself | 18:04 |
| rharper | smoser: https://code.launchpad.net/~raharper/curtin/trunk.passthrough-netconfig , and XenialTestNetworkIPV6Vlan (or any of the IPV6Vlan) break | 18:05 |
| rharper | if we write the .link files (which we do in cloud-init, but not in curtin) | 18:05 |
| smoser | rharper, https://bugs.launchpad.net/cloud-init/+bug/1594546 | 18:10 |
| ubot5 | Ubuntu bug 1594546 in cloud-init "no need to write systemd.link files" [Medium,Fix released] | 18:10 |
| smoser | we *had* stopped writing them at one point. | 18:10 |
| smoser | whyd'd we start again | 18:10 |
| rharper | ISTR we thought it was harmless | 18:13 |
| smoser | ef18b8ac4 put them back | 18:15 |
| smoser | :-( | 18:15 |
| smoser | rharper, i think what you're saying is that when cloud-init does netplan config it is still writing those .link files | 18:16 |
| smoser | and netplan is (i assume) also writing .link files | 18:16 |
| smoser | so that' dget harry | 18:16 |
| rharper | netplan will write .link files; | 18:17 |
| * rharper looks at ef18b8ac4 | 18:17 | |
| rharper | hrm, I'm not seeing it, the links_path shouldn't be set when we instantiate an eni renderer | 18:24 |
| smoser | oh. maybe i read wrong | 18:28 |
| smoser | but as you see, we are creating them, right? | 18:28 |
| smoser | rharper, thoughts on https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/324639 | 18:29 |
| smoser | it doesnt adda unit test, but unit tests aren't easily useful in this scenario | 18:30 |
| Odd_Bloke | Hmph, just discovered I've been sitting in #cloud-init on Canonical IRC since I last restarted weechat. >.< | 18:32 |
| smoser | Odd_Bloke, do you know.. was https://code.launchpad.net/~daniel-thewatkins/cloud-init/+git/cloud-init/+merge/324642 | 19:02 |
| smoser | always just *wrong* or did it get changed? | 19:02 |
| smoser | it seems odd that they would change instance/attributes/sshKeys to instance/attributes/ssh-keys while leaving the camelcase project/attributes/sshKeys | 19:03 |
| Odd_Bloke | smoser: It did get changed. | 19:12 |
| Odd_Bloke | smoser: Changing instance metadata keys is easier for them than project metadata keys. | 19:13 |
| rharper | smoser: yes, they are getting created, I need to see why | 19:13 |
| smoser | Odd_Bloke, i asked in the mp, and asked for an update. | 19:14 |
| smoser | it seems very odd. | 19:14 |
| smoser | pylint tells me now: | 19:14 |
| smoser | Your code has been rated at 10.00/10 (previous run: 10.00/10, +0.00) | 19:15 |
| smoser | which is odd. | 19:15 |
| smoser | Odd_Bloke, if you fix that quick, i'll grab it and get it into artful end of day | 19:18 |
| smoser | and intend to prepare sru of trunk soon | 19:18 |
| Odd_Bloke | smoser: Updated. | 19:24 |
| rharper | smoser: turns out that with no config passed to the renderer class, you get the defaults, which currently defaults to rendering the .link files for eni | 19:34 |
| rharper | I think it may make sense to set in the ubuntu distro class the links path to None, which would stop rendering them | 19:36 |
| smoser | rharper, that is what it previously had, right? | 19:37 |
| smoser | efef1c263ab1c473fd90f3782a785edab7d02430 | 19:37 |
| rharper | hrm, we also have the 70-persistent rules | 19:37 |
| rharper | smoser: I think so | 19:37 |
| smoser | we do need the 70-persistent rules, i think. | 19:38 |
| smoser | maybe not. | 19:38 |
| rharper | well, cloud-init does the rename | 19:39 |
| smoser | cloud-init will take care of renaming any non-virtual devices that are present when init runs | 19:39 |
| rharper | right | 19:39 |
| smoser | but if they are not present, then it wont do it | 19:39 |
| rharper | and udev rules and .link files are for physical | 19:39 |
| smoser | so i think we were relying on udev to do anything cloud-init couldnt do because it wasnt there yet. | 19:40 |
| Odd_Bloke | smoser: Thanks for the review+merge. :) | 19:41 |
| rharper | smoser: I think you're right; after lxd, we had to do rename in cloud-init; | 19:45 |
| rharper | which removed the need to rely on udev for that | 19:45 |
| smoser | except for devices that are not present when cloud-init runs | 19:46 |
| smoser | a device could have a name and networking infromation but not a address | 19:46 |
| smoser | and cloud-init should then arrange for it to get the right name | 19:47 |
| smoser | even though it wont be up (and may not even be around yet) when cloud-init init runs. | 19:47 |
| smoser | ii think | 19:47 |
| smoser | rharper, or blackboxsw i'd appreciate https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/324639 | 19:50 |
| rharper | smoser: you're thinking a manual interface? cloud-init will still attempt to provide a name for physical interfaces in network-config no matter if it has a subnet or not | 19:51 |
| rharper | on the control-hotplug; that may be right | 19:52 |
| rharper | we could modify the rules and links to be rendered for missing interfaces or ones marked control: hotplug | 19:52 |
| rharper | but it does seem strange to have some in the rules/links file but not others; however; I don't see how we can disentangle the different rules which are attempting to do renames | 19:53 |
| smoser | http://paste.ubuntu.com/24658740/ | 19:55 |
| smoser | that would seem valid config. and if 'eth1' just wasnt there when cloud-init ran, you'd hope that it wouuld have still arranged for it to get the right name | 19:56 |
| smoser | rharper, i think we just render the udev rules for everything | 19:56 |
| smoser | we can't rely on .link files... they suck | 19:57 |
| smoser | so we render udev rules for everything | 19:57 |
| rharper | for all physical devices, yes | 19:57 |
| smoser | cloud-init does the right thing and only attempts rename if it needs to | 19:57 |
| rharper | yes | 19:57 |
| smoser | "physical" including veth | 19:57 |
| smoser | :) | 19:57 |
| rharper | that bears out too, if I remove the .link files and leave the .rules one, we;re fine | 19:57 |
| rharper | sure | 19:57 |
| smoser | i dont understand though why the .rules would break anything | 19:57 |
| rharper | I was referring to the possible interfaces from the network config | 19:58 |
| smoser | i really thought they are not supposed to do anything if a udev rule named them | 19:58 |
| rharper | I;m not sure that they do interfere at this time | 19:58 |
| rharper | was just wondering why we did both .link and .rules | 19:58 |
| smoser | by accident | 19:58 |
| smoser | :) | 19:58 |
| smoser | doh! | 19:58 |
| smoser | so when you fix that, please add a test case | 19:59 |
| rharper | yes | 19:59 |
| smoser | it always feels wrong to remove code that you think you might need in the future | 20:01 |
| rharper | heh | 20:01 |
| smoser | but it might be the right thignto do to remove the support for rendering of the .link files | 20:01 |
| rharper | I think so | 20:01 |
| rharper | smoser: so I'll do a patch that just pulls .link rendering completely | 20:07 |
| rharper | that should keep this pretty clean, and then unittest updates should all be that's needed | 20:08 |
| === rangerpb is now known as rangerpbzzzz | ||
| askb | powersj ping | 23:10 |
| powersj | askb: howdy | 23:11 |
| askb | powersj, hey ... | 23:11 |
| askb | re the auth_url message, wondering how I could help with that | 23:12 |
| askb | you are most likely seeing the error "Missing value auth-url required for auth plugin password" because that has to be source through ~/.config/openstack/clouds.yaml or RC file or as an env variable | 23:12 |
| powersj | ah ok | 23:13 |
| powersj | can you try running the validation script and get the results? | 23:13 |
| askb | basically, the template itself works pretty well, since about 200 jobs run using those template | 23:13 |
| askb | until recently cloud-init stopped working | 23:14 |
| askb | sure, let me check | 23:14 |
| powersj | askb: interesting. Do you have copies of the images you used? Is it possible to see what changed to the image? | 23:15 |
| powersj | originally I believe you said you were running a fairly old version of cloud-init, so I find it unlikely that behavior in cloud-init has changed causing the issue | 23:15 |
| askb | when I run the validate-script on the template, it returns nothing, no errors | 23:17 |
| askb | so that should be good | 23:17 |
| askb | centos7 repo distributes 0.7.5 version of cloud-init | 23:18 |
| askb | the newer images have package updates of possible dependencies | 23:20 |
| askb | I need to dig into the images to get a proper delta of the deps between new and old image | 23:20 |
| askb | will do it a bit later today | 23:20 |
| askb | in the meantime, are there any basic tests for cloud-init which could be run on the instance to make sure its working fine or narrow down the issue | 23:21 |
| askb | yesterday, while running 0.7.9 this gives a different error: | 23:22 |
| askb | 2017-05-25 02:07:00,591 - util.py[WARNING]: Failed to disable password for user ubuntu | 23:22 |
| askb | 2017-05-25 02:07:00,593 - util.py[WARNING]: Running module users-groups (<module 'cloudinit.config.cc_users_groups' from '/usr/lib/python2.7/site-packages/cloudinit/config/cc_users_groups.pyc'>) failed | 23:22 |
| askb | I am unable to understand why its looking for ubuntu user on centos box ? | 23:23 |
| powersj | As the pastebin's showed cloud-init was trying to run the passwd command when it failed, yeah the ubuntu user was also odd. | 23:23 |
| askb | powersj, is the issue with 0.7.9 and 0.7.5 possibly the same ? | 23:32 |
| askb | from the logs | 23:32 |
| askb | other than the dependencies is there anything else I could provide or run some other tests | 23:33 |
| powersj | askb: well you got the same error messages if I recall. However, I still wonder what changed on the system to cause the error in the first place. If you aren't expecting an ubuntu user, what change caused that? trace back to that first and that might determine why cloud-init is failing. | 23:34 |
| powersj | if you can get us the images themselves that might help. | 23:34 |
| askb | the ubuntu user error was seen with 0.7.9 and centos user error was seen on 0.7.5 | 23:35 |
| askb | ok will see if I can get the images | 23:35 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!