| paulmey | https://code.launchpad.net/~paul-meyer/cloud-init/+git/cloud-init/+merge/323532 | 00:35 |
|---|---|---|
| paulmey | found and fixed a bug... | 00:35 |
| paulmey | bug # 1687712 | 00:36 |
| blackboxsw | thx for that paulmey. I'm end of day now. but I'll get you a thorough review on this tomorrow if it isn't reviewed before then. | 00:52 |
| === smatzek_ is now known as smatzek | ||
| === rangerpbzzzz is now known as rangerpb | ||
| blackboxsw | forgot to mention powersj I found an existing project registered over in opensuse build service https://build.opensuse.org/package/show/Cloud:Tools/cloud-init | 15:23 |
| blackboxsw | for when we start looking at trying to auto-gen RPMs | 15:23 |
| powersj | ah yes I did see this the other day. Looks like someone setup cloud-init builds for suse | 15:23 |
| blackboxsw | not sure how we'd coordinate w/ that (or avoid stepping on toes). But yeah it looked like it was about ~2 months old | 15:24 |
| powersj | +18 patches | 15:24 |
| blackboxsw | yeah lots of patch love | 15:24 |
| blackboxsw | some of those I checked against our master and saw fixes already landed | 15:24 |
| smoser | blackboxsw, powersj i signed up for fedora account yesterday (actually had one already, as i'm cool like that) | 15:41 |
| smoser | signed up for copr | 15:41 |
| smoser | i think copr is right for centos/fedora/rhel rpms | 15:41 |
| smoser | and then suse build for suse | 15:41 |
| smoser | thoughts? | 15:41 |
| blackboxsw | smoser: yeah that sounds good to me. I signed up for one end of last week as I'm not cool like that | 15:44 |
| blackboxsw | it's doable. | 15:44 |
| blackboxsw | both looked viable | 15:45 |
| blackboxsw | and copr is probably best in class for RHEL centos anyway (though it didn't seem to have a *ton* of projects registered if I recall) | 15:45 |
| blackboxsw | smoser, I've setup a digital ocean account and am spinning up a couple test instances to validate failed behavior of https://bugs.launchpad.net/cloud-init/+bug/1676908. Will wrap up these SRU templates today I hope | 15:47 |
| ubot5` | Ubuntu bug 1676908 in cloud-init (Ubuntu Zesty) "DigitalOcean network improvements" [Medium,Confirmed] | 15:47 |
| smoser | blackboxsw, i can just bother utlemming and ask him for help on that | 15:48 |
| smoser | and i'm perfectly fine to have him veriy | 15:48 |
| smoser | this is quite reasonable. he opened bug, he mostly did work, his company benefit.. | 15:48 |
| blackboxsw | smoser: +1 on bothering BHoward :) | 15:48 |
| * smoser pings utlemming | 15:49 | |
| utlemming | smoser: here....I thought I was hanging out, but was disconnected :) | 15:51 |
| smoser | utlemming, thanks | 15:52 |
| smoser | blackboxsw, bother utlemming | 15:52 |
| blackboxsw | hi ben, time to bother you about https://bugs.launchpad.net/cloud-init/+bug/1676908 | 15:53 |
| ubot5` | Ubuntu bug 1676908 in cloud-init (Ubuntu Zesty) "DigitalOcean network improvements" [Medium,Confirmed] | 15:53 |
| utlemming | yup | 15:53 |
| blackboxsw | I was going to try setting up a test config droplet in DO that'd reproduce the problem you fixed with your branch | 15:53 |
| smoser | utlemming, we'd like for you to do the sru template and verify fix | 15:53 |
| smoser | as your knowledge of digital ocean surpasses even blackboxsw's (who signed up more than 8 hours ago) | 15:54 |
| blackboxsw | but wanted to get some guidance on a general test config/setup that'd expose this original proble | 15:54 |
| utlemming | I'd be happy too... | 15:54 |
| utlemming | smoser: any chance that https://code.launchpad.net/~utlemming/cloud-init/+git/cloud-init-1/+merge/323273 could be included? | 15:54 |
| utlemming | that is the root cause on another bug....let me fetch that for you | 15:55 |
| utlemming | smoser: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1681531 | 15:57 |
| ubot5` | Ubuntu bug 1681531 in cloud-init (Ubuntu) "networking.service fails on ifup if networking configured via cloud-init" [Undecided,Incomplete] | 15:57 |
| blackboxsw | yep, I've created my first droplet and it looks like your initial changes from #1676908 are already present http://paste.ubuntu.com/24505957/ | 16:02 |
| blackboxsw | so DO pulls from xenial-updates | 16:03 |
| blackboxsw | wow spelling auto-correction by irccloud. hmm don't think I like that | 16:03 |
| blackboxsw | DO droplets pull from xenial-updates and I see part of ben's changes already present. | 16:04 |
| utlemming | blackboxsw: we're using the official images, but that is a dpkg-divert because...welp, broken | 16:07 |
| smoser | blackboxsw, of course they pull from -updates | 16:10 |
| smoser | ah. | 16:10 |
| smoser | hm.. | 16:10 |
| blackboxsw | AMheh. | 16:14 |
| * blackboxsw steps out for an early lunch | 16:30 | |
| ragechin | rharper: Do you have that documentation PR from yesterday handy? I seem to have lost it. | 16:41 |
| rharper | i do | 16:41 |
| rharper | https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+merge/321397 | 16:42 |
| rharper | ragechin: feel free to nudge smoser to land it; then it will get published on cloud-init's read-the-docs | 16:42 |
| ragechin | THanks. | 16:42 |
| smoser | utlemming, why wouldn't you fix your metadata on digital ocean? | 17:05 |
| smoser | essentially https://code.launchpad.net/~utlemming/cloud-init/+git/cloud-init-1/+merge/323273 looks like the MD is provding a gateway that you're saying doesnt work. | 17:05 |
| utlemming | smoser: checking, on that | 17:25 |
| utlemming | but I would still like to ignore the second nics | 17:25 |
| utlemming | for the purpouses of a gateway | 17:25 |
| smoser | :) | 17:26 |
| smoser | utlemming, do you agree that the information provided to cloud-init is kind of broken ? | 17:40 |
| smoser | why would you have gateways on two nics? | 17:41 |
| ragechin | DHCP assigned addresses on both NICs | 17:41 |
| ragechin | see: AWS | 17:41 |
| utlemming | smoer: yup, I'm getting the history on that now | 17:42 |
| ragechin | hey smoser, any chance you can push this along please? | 17:42 |
| ragechin | https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+merge/321397 | 17:42 |
| paulmey | blackboxsw, smoser, I updated https://code.launchpad.net/~paul-meyer/cloud-init/+git/cloud-init/+merge/323532 | 17:59 |
| utlemming | smoser: so yeah, its wrong, but we're going to have use a different version of the json in order to fix that | 18:00 |
| paulmey | cleaned up tests, more specific assertions and added warnings for unused options | 18:00 |
| smoser | paulmey, thanks. | 18:00 |
| smoser | utlemming, ok, can you open a bug and provide info, then we comment in the MP on what we're doing | 18:00 |
| smoser | because otherwise i'm going to wonder WTH IS GOING ON in 6 months when i look at that again. | 18:01 |
| smoser | rharper, on https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+merge/321397 | 18:01 |
| smoser | hmm. | 18:02 |
| blackboxsw | paulmey: looking now, thanks | 18:02 |
| smoser | i'll just make some commits and sugest them, rharper | 18:03 |
| rharper | smoser: ok, more since the last time | 18:03 |
| rharper | I pulled your PR and fixed what you suggested | 18:03 |
| smoser | yeah. just some stuff i thin is confusing. its ard to type | 18:04 |
| rharper | sure | 18:05 |
| utlemming | smoser: updated the commit message to refence the bug, and updated https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1681531 | 18:07 |
| ubot5` | Ubuntu bug 1681531 in cloud-init (Ubuntu) "DigitalOcean DS defines mutliple gateways via meta-data" [Undecided,Incomplete] | 18:07 |
| blackboxsw | utlemming: are you generating an SRU template for https://bugs.launchpad.net/cloud-init/+bug/1676908 too ? | 18:18 |
| ubot5` | Ubuntu bug 1676908 in cloud-init (Ubuntu Zesty) "DigitalOcean network improvements" [Medium,Confirmed] | 18:18 |
| blackboxsw | smoser: I'm not really sure what the intent of extra_opts is in fs_setup. I see no docs about it in https://cloudinit.readthedocs.io/en/latest/topics/examples.html#disk-setup and the behavior of the code seems to lead me to think any functionality could have been handled by setting fs_setup: cmd: to include everything someone wants to do. | 18:38 |
| utlemming | blackboxsw: fwiw, with out my other patch requested, the SRU will fail. | 18:38 |
| utlemming | blackboxsw: both have been SRU'ified | 18:40 |
| utlemming | although I seem to have been kicked out of all my LP groups, so I can't even nominate the bugs | 18:41 |
| blackboxsw | excellent utlemming | 18:41 |
| blackboxsw | or should I saw darkmuggle | 18:41 |
| blackboxsw | say* | 18:42 |
| utlemming | either :) | 18:42 |
| smoser | rharper, http://paste.ubuntu.com/24506946/ | 19:06 |
| smoser | see HELPME comments ... | 19:06 |
| rharper | ok | 19:06 |
| smoser | rharper, does that stuff make sense ? | 19:23 |
| smoser | (the patch there) | 19:23 |
| smoser | utlemming, thanks. | 19:23 |
| smoser | paulmey, htanks | 19:23 |
| rharper | smoser: yes; extra docs for helping folks | 19:23 |
| rharper | working them now | 19:24 |
| blackboxsw | paulmey: minor comments added to your proposal. thanks | 19:39 |
| paulmey | blackboxsw: implemented all your suggestions. Thanks for reviewing! | 20:02 |
| blackboxsw | np paulmey | 20:03 |
| rharper | smoser: merged and re-pushed to branch; | 20:10 |
| anticw | i have vm images i want to use on openstack, ec2 and locally ... when using them locally there is nothing for cloud-init to talk to (which is fine) | 20:28 |
| anticw | however, i can't seem to make cloud-init time-out promptly or reliably | 20:28 |
| anticw | seeing a datasource and seting timeouts, etc i still see it retrying for 120s (default which i thought i changed) | 20:29 |
| rharper | anticw: you may want to use the NoCloud datasource locally instead of modifying the timeouts; | 20:43 |
| rharper | anticw: if you want to debug the timeout, getting /var/log/cloud-init.log along with the cloud-config you seeded in the image will help us debug | 20:45 |
| === rangerpb is now known as rangerpbzzzz | ||
| anticw | rharper: how does cloud-init know to use NoCloud on boot? | 20:56 |
| rharper | fileysstem label | 20:56 |
| rharper | http://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html | 20:56 |
| rharper | cidata is the volume label | 20:56 |
| anticw | cloud-drive? | 20:57 |
| rharper | yeah | 20:57 |
| anticw | but i 100% don't want that | 20:57 |
| anticw | why can't it just give up mucking about after 5s or so? | 20:57 |
| rharper | or, if you want to embed it directly in the image, you write files to /var/lib/cloud/seed/nocloud/{user-data,meta-data} | 20:57 |
| anticw | in ec2 it will easily get a response before then | 20:57 |
| anticw | no, i want the same images in all 3 envs | 20:57 |
| anticw | the exact same bits | 20:57 |
| rharper | but if you're not on ec2, the cloud-config won't apply | 20:58 |
| anticw | but then it delays usable boot times for 120s or more | 20:58 |
| anticw | VMs locally boot in about 2s or so | 20:58 |
| anticw | with it ... well, it's 125s+ | 20:58 |
| anticw | (boot meaning to the point i can login) | 20:59 |
| rharper | right, if you use NoCloud or ConfigDrive, with the same user-data, then cloud-init will find those and run them; | 20:59 |
| anticw | and if it can't find them ... can i not have it timeout? | 20:59 |
| rharper | if you supply the same user data to an ec2 instance, it will find the ec2 metadata service and consume the same user-data and run the same paths w.r.t cloud-config | 20:59 |
| anticw | i mean, i could also have an init process that looks to see if it's still there after 10s and shoots it | 20:59 |
| anticw | i must be missing something simple sorry | 21:00 |
| rharper | cloud-init is attempting to find a source of data; if you don't provide one, it currently assumes you *might* be on an ec2 instance; historically it;s had a long timeout for various reasons; | 21:01 |
| rharper | I'm suggesting that you keep the same image, but provide the user-data via a config drive, so cloud-init can find it when you boot locally | 21:01 |
| anticw | and if i don't want config drive but would rather a timeout? | 21:02 |
| rharper | that will provide the same results w.r.t applying user-data (ie, set this password, import this key, etc) as it would if you booted the image in ec2 | 21:02 |
| rharper | the default timeout is long, as you know; changing that requires modifying the image | 21:02 |
| rharper | embedding some cloud-config in /etc/cloud/cloud.cfg.d/ for the EC2 datasource | 21:02 |
| rharper | there's a max_wait: value; I'd need to read the code a bit more to write up the details | 21:03 |
| rharper | even if your time out, no user-data will be applied | 21:03 |
| rharper | anticw: do you want the image to not run cloud-init locally ? | 21:03 |
| anticw | i tried setting a max_wait without success; googling i find others struggling with this too | 21:03 |
| anticw | rharper: locally i do NOT want cloud-init right | 21:03 |
| rharper | if so, you can pass a kernel parameter to disable cloud-init altogether | 21:04 |
| anticw | but kernel parms come from the boot loader ... | 21:04 |
| rharper | yes, I see your concern here | 21:04 |
| anticw | if i can't reduce the 120s via config i can just hack the code i guess | 21:04 |
| rharper | well, I'll file a bug on ec2 timeout docs; there isn't much there | 21:05 |
| anticw | i could probably put a metadata server at 169.254.169.254 if there was a suitable reply that meant 'go away' but i'm not sure there is | 21:05 |
| anticw | rharper: there are docs/examples there but i can't get them working, likely it's me | 21:05 |
| rharper | anticw: in trunk cloud-init, the ds-identify feature will not run cloud-init unless it detects a local datasource; but on ec2 it woudl detect it's ec2 and enable itself | 21:06 |
| rharper | this is on it;s way back to previous releases (in zesty, yakkety, and eventually xenial) | 21:06 |
| anticw | this is ub1604 current upstream so likely not in that | 21:06 |
| rharper | not yet | 21:06 |
| rharper | you can modify it to use the strict policy now, if you like though | 21:06 |
| anticw | i could pattch and make a new pkg | 21:07 |
| rharper | you only need a new config file | 21:07 |
| anticw | patch even | 21:07 |
| anticw | oh? | 21:07 |
| rharper | % cat etc/cloud/ds-identify.cfg | 21:08 |
| rharper | policy: search,found=first,maybe=all,notfound=disabled | 21:08 |
| rharper | ci.datasource.ec2.strict_id=true | 21:08 |
| rharper | for 1604 with cloud-init version: 0.7.9-90-g61eb03fe-0ubuntu1~16.04.1 | 21:08 |
| rharper | which is in xenial-updates | 21:08 |
| rharper | that policy file will force cloud-init to ensure it finds a datasource or it won't run | 21:08 |
| rharper | this means for a local boot, without config drive, it will skip cloud-init running altogether | 21:09 |
| rharper | but the same image with config drive, or booted in ec2, will run | 21:09 |
| rharper | does that get you what you need? | 21:09 |
| anticw | i think it might, waiting for it to time-out to test | 21:10 |
| rharper | you might be interested in mount-image-callback tool which let's you mount and modify the image without booting it | 21:12 |
| rharper | in the cloud-image-utils | 21:12 |
| anticw | i can modify images just fine | 21:18 |
| anticw | the goal though is to have a base images that is *not* modified | 21:18 |
| anticw | i've had to mount the zvol more than a couple of times locally to unfark stupid things i did | 21:19 |
| rharper | hehe | 21:25 |
| anticw | rharper: i created ds-identify.cfg as you showed above but it cloud-init still runs | 21:29 |
| anticw | let me check i didn't goof | 21:29 |
| rharper | are you running the cloud-init version I pasted above ? | 21:30 |
| anticw | oh, i see ... i actually assumed i was but didn't check, sorry | 21:31 |
| anticw | that's a git version id in there so not release tag, my guess is not | 21:31 |
| rharper | ok, if you apt update && apt install cloud-init, it'll upgrade to the newer version which has ds-identify available for use | 21:32 |
| anticw | it's in the apt-repo very recently? | 21:32 |
| rharper | for a few weeks or more | 21:33 |
| anticw | i do have it | 21:33 |
| rharper | ok, then we can look at /run/cloud-init/ds-identify.log | 21:34 |
| rharper | the default behavior without the ds-identify.cfg is to always run (as it has in the past); the policy file should direct it to not run unless it detects a local datasource (or a some other cloud identifier, for say ec2) | 21:35 |
| anticw | https://pastebin.com/5xdMeUE1 && https://pastebin.com/S5HMyVTW | 21:36 |
| anticw | maybe for ec2 | 21:36 |
| anticw | "1 datasources returned maybe: Ec2" | 21:37 |
| rharper | ack, looking | 21:39 |
| rharper | anticw: do you have any Ec2 cloud-config in any of the /etc/cloud/* subtree ? | 21:46 |
| anticw | no | 21:47 |
| rharper | hrm, I have a plain 1604 image with that same policy loaded, but it doesn't return maybe for ec2 ... trying to figure out why yours is... | 21:47 |
| anticw | i did alter cloud.cfg to try and get things going and also to take out the apt modules, because with those in place source.list gets wrecked | 21:48 |
| anticw | i can [re]test with the stock cloud.cfg likely | 21:49 |
| rharper | that wouldn't affect it | 21:49 |
| rharper | if you're on your instance now;, you can remove /run/cloud-init/.ds-identify.result and then sh -x /usr/lib/cloud-init/ds-identify &> ds.log; that'll re-run ds-identify with execution tracing, and I can see how it got a maybe | 21:50 |
| anticw | --force? | 21:52 |
| anticw | otherwise cached | 21:52 |
| rharper | I think the dot file is the cache test | 21:52 |
| rharper | but you can also pass --force, won't hurt | 21:52 |
| anticw | so this time i got: 2 datasources returned maybe: OVF Ec2 | 21:53 |
| anticw | pastebin ds.log for you? | 21:53 |
| rharper | please | 21:53 |
| rharper | =/ | 21:53 |
| rharper | I think maybe OVF is expected ... and I've been down this path before; /me triple checks the contents of ds-identify.cfg | 21:53 |
| anticw | https://pastebin.com/Uz7hPdjZ | 21:54 |
| rharper | you need either the --force or rm /run/cloud-init/.ds-identify.result | 21:55 |
| rharper | the paste was from that cached run | 21:55 |
| anticw | oh sorry, i did it 2x and forgot to remove it the second time | 21:58 |
| anticw | rharper: https://pastebin.com/8jTnqpXX | 22:03 |
| rharper | k | 22:03 |
| blackboxsw | smoser: last SRU bug template for softlayer. For testing, shall I make-configdrive-dir, but remove the dated directory from the lxd leaving only the latest directory. Then I could run ds-identify and make sure it still finds the content? | 22:22 |
| blackboxsw | the bug I meant to reference: https://bugs.launchpad.net/cloud-init/+bug/1673637 | 22:22 |
| ubot5` | Ubuntu bug 1673637 in cloud-init "cloud-init - Hosts in softlayer receiving warning" [High,Confirmed] | 22:22 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!