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