| === shardy is now known as shardy_lunch | ||
| === shardy_lunch is now known as shardy | ||
| === jgrimm-away is now known as jgrimm | ||
| smoser | larsks, here. reading | 13:28 |
|---|---|---|
| larsks | smoser: thanks. Any thoughts? Mostly I was confused by the "vendor-data is just like user-data" in the docs vs. the whole discussion about json blobs and a "cloud-init" key in the bug report (e.g., in comment #6). | 13:54 |
| smoser | larsks, https://public.etherpad-mozilla.org/p/cloud-init-vendordata maybe helps ? | 13:56 |
| larsks | smoser: but it this correct? http://cloudinit.readthedocs.io/en/latest/topics/vendordata.html | 13:57 |
| larsks | "Vendordata is handled exactly like user-data." E.g., pass it a '#cloud-config' file and everything is happy... | 13:58 |
| larsks | That seems different from "The ideal situation is for vendor-data to come in a dictionary with a top level 'cloud-init' key." | 13:58 |
| smoser | passing just a 'cloud-config' blob should work, yes. | 13:59 |
| smoser | as the datasource woul d just load that as a string | 13:59 |
| smoser | and pass it to convert_vendordata | 13:59 |
| smoser | which would return that string | 13:59 |
| larsks | But *also* a JSON document (with no #<type> header)? | 13:59 |
| smoser | i'm not sure what you're getting at. | 13:59 |
| larsks | Can the vendor-data blob be a JSON document? (instead of, e.g., a #cloud0-config document) | 14:00 |
| smoser | if its a '#cloud-config' blob that will work. but it will just be a single 'part' | 14:00 |
| smoser | it could be, yes. | 14:00 |
| smoser | but thats kind of up to the datasource code to know that this vendor might send json | 14:00 |
| larsks | I see. So for openstack, at least, the assumption is that there is a top-level 'cloud-init' key in the JSON, and the value of that key is a string that is a user-data style format of some sort. | 14:01 |
| smoser | a string or a list | 14:01 |
| smoser | but yeah, thats best. as it is then multiple parts (which is nice) and namespaced to cloud-init | 14:02 |
| larsks | Sure. Thanks. I'm trying to reproduce a problem someone reported and just trying to understand how vendor-data is handled. Thanks! | 14:02 |
| smoser | yeah, those docs are not clear :-( | 14:03 |
| utlemming | smoser: hey, sorry I just got back from vacation and was looking at https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/321623 | 14:37 |
| utlemming | it looks like that conflicts with my MP at: https://code.launchpad.net/~utlemming/cloud-init/+git/cloud-init-1/+merge/321183 | 14:37 |
| utlemming | specifically, my MP allows for arbitrary nics | 14:38 |
| smoser | utlemming, well, i did drop the nic renaming. but that is by desing. | 14:47 |
| smoser | so the scenario that you were trying to allow for (i think) should never occur. | 14:47 |
| smoser | you were papering over an problem where the metadata described nics attached that were not attached. | 14:48 |
| smoser | (by mac address) | 14:48 |
| smoser | i think | 14:48 |
| smoser | yeah. if digital oceans metadata gives me bad data, cloud-init randomly picking a "first nic" is not really going to do anyone any good. | 14:49 |
| utlemming | sure, that makes sense | 14:52 |
| utlemming | I'm double checking my MP because I think yours and mine does the same thing | 14:52 |
| utlemming | smoser: so https://git.launchpad.net/~utlemming/cloud-init/tree/cloudinit/sources/helpers/digitalocean.py?h=lp-1676908&id=ca7acab88e42d8861ea00b2e1ca12fb58ea7a7bb is what I proposed | 14:54 |
| utlemming | and that drops the entire warn thing | 14:54 |
| utlemming | let me fix that up real fast to give you the explicit check | 14:54 |
| smoser | which warn thing ? | 14:55 |
| utlemming | https://git.launchpad.net/~smoser/cloud-init/tree/cloudinit/sources/helpers/digitalocean.py?h=feature/digital-ocean-more-strict&id=09b7035d3f448b1f8b7fab29d3884c903bce8d97#n148 | 14:55 |
| smoser | utlemming, so that warn happens when cloud-init sees a 'nic type' that it doesnt understand. | 14:57 |
| smoser | ie, 'public' or 'private'. | 14:57 |
| smoser | if d.o added a new 'semi-private' type | 14:57 |
| smoser | then cloud-init would warn there. | 14:57 |
| utlemming | right, and I've dropped that logic | 14:58 |
| smoser | which i think is sane. we could raise a RuntimeException | 14:58 |
| smoser | but at very least we should warn. | 14:58 |
| utlemming | I dropped it for a couple of a reasons, mostly be because we' | 14:58 |
| utlemming | we have seen problems on our private management network with it | 14:58 |
| utlemming | because we have a 'management' network that we use | 14:58 |
| utlemming | and it breaks in that space | 14:59 |
| smoser | well, what is the right thing to do there ? | 15:01 |
| smoser | a.) handle correctly the 'management' network | 15:01 |
| smoser | b.) WARN "hey, there is this thing called management i dont understand!" | 15:01 |
| smoser | c.) FAIL "hey, there is this thing...." | 15:01 |
| smoser | in my mp, i think taht its just doing 'b' | 15:01 |
| smoser | d.) add minimal knowledge of 'management' and change that to just do nothing but with a DEBUG message | 15:02 |
| smoser | but doing nothing doesnt seem right | 15:02 |
| smoser | utlemming, i have to run, i'm sorry. i'll be back in tomorrow AM | 15:03 |
| erick3k | hello | 15:03 |
| erick3k | nacc i ended up installing ubuntu 16 manually | 15:03 |
| erick3k | 0 problems | 15:03 |
| nacc | erick3k: rather than using cloud-init? | 15:04 |
| utlemming | smoser: sure thing, I'll look at it and send something up :) | 15:04 |
| utlemming | thanks for looking | 15:04 |
| erick3k | nacc i mean rather than using cloud image | 15:04 |
| erick3k | i isntalled ubuntu with the iso | 15:04 |
| nacc | erick3k: ah | 15:04 |
| erick3k | works like a charm man | 15:04 |
| nacc | erick3k: but you are using the 14.04 cloud image? | 15:05 |
| erick3k | except for the 5 mins timout that i removed is perfect | 15:05 |
| erick3k | yes 14.04 is cloud image and works | 15:05 |
| erick3k | anyways | 15:05 |
| erick3k | i installed debian 8 (iso cloud image also does not work properly) | 15:06 |
| erick3k | and installed cloud-init but the / partition does not grow | 15:06 |
| erick3k | tried installing cloud-initiramfs-growroot but does not exist | 15:06 |
| erick3k | any idea whats the package needed ? i thought cloud-init came with it | 15:06 |
| nacc | erick3k: no idea, maybe smoser or rharper know | 15:08 |
| erick3k | ty | 15:08 |
| erick3k | found it apt-get install cloud-initramfs-growroot i think | 15:09 |
| rharper | growroot requires specific partitioning | 15:11 |
| nacc | erick3k: ah, typo before? | 15:11 |
| rharper | it basically calls resize2fs | 15:11 |
| erick3k | nacc i guess haha | 15:11 |
| rharper | so, if you're root device has no extra partitions past where root is (like say root is on sda1 and no other partitions, but free space) | 15:11 |
| rharper | then resize can grow | 15:11 |
| erick3k | rharber by specific you mean a single / partition with ext4? | 15:12 |
| rharper | y | 15:12 |
| nacc | rharper: oh that makes sense -- just a general wrapper around that normal use-case? | 15:12 |
| erick3k | yes thats how i install my templates so should work now | 15:12 |
| rharper | nacc: yes | 15:13 |
| rharper | openstack for example can have arbitrary sized block devices | 15:13 |
| rharper | so they lay down the cloud-image, and upon first boot, will grow the rootfs to fill the disk | 15:13 |
| nacc | rharper: right, that makes sense | 15:13 |
| nacc | and means you don't need to know the disk size up front | 15:13 |
| rharper | unless you inject your own config (cloud-init can also do disk partitioning and such) | 15:13 |
| rharper | nacc: exactly | 15:13 |
| erick3k | now it worked, wonder why apt-get install cloud-init doesn't install the growpart utility | 15:22 |
| nacc | erick3k: presumably because installing that package changes functionality which should be opt-in not on by default? | 15:23 |
| rharper | it's part of the cloud-guest-utils | 15:24 |
| erick3k | nacc i agree but i think it is installed on ubuntu and not on debian | 15:24 |
| rharper | so it's in the *guest* image by default; the server ISO is not a cloud image itself | 15:24 |
| erick3k | ok | 15:25 |
| === rangerpbzzzz is now known as rangerpb | ||
| rharper | there's always a tradeoff w.r.t default package lists | 15:25 |
| === rangerpb is now known as rangerpbzzzz | ||
| powersj | smoser: I found a bug with a reference to "ci-tool". Appears to be https://bazaar.launchpad.net/~smoser/cloud-init/ci-tool/view/head:/ci-tool | 22:29 |
| powersj | Is this in cloud-init under a new name now or just a handy utility you had? | 22:29 |
| rharper | powersj: I've not heard of ci-tool | 22:44 |
| rharper | under bazaar means it's likely and older tool | 22:44 |
| powersj | rharper: ok, thanks! | 22:44 |
| rharper | looks like a handy util; it could be merged under cloud-init/tools if it's still useful | 22:45 |
| powersj | rharper: there was a suggestion to put it in cloud-utils as well | 22:49 |
| rharper | ah | 22:55 |
| rharper | powersj: that's also a possibility | 22:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!