[13:28] <smoser> larsks, here. reading
[13:54] <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:56] <smoser> larsks, https://public.etherpad-mozilla.org/p/cloud-init-vendordata maybe helps ?
[13:57] <larsks> smoser: but it this correct? http://cloudinit.readthedocs.io/en/latest/topics/vendordata.html
[13:58] <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:59] <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.
[14:00] <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:01] <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:02] <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:03] <smoser> yeah, those docs are not clear :-(
[14:37] <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:38] <utlemming> specifically, my MP allows for arbitrary nics
[14:47] <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:48] <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:49] <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:52] <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:54] <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:55] <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:57] <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:58] <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:59] <utlemming> and it breaks in that space
[15:01] <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:02] <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:03] <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:04] <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:05] <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:06] <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:08] <nacc> erick3k: no idea, maybe smoser or rharper know
[15:08] <erick3k> ty
[15:09] <erick3k> found it apt-get install cloud-initramfs-growroot i think
[15:11] <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:12] <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:13] <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:22] <erick3k> now it worked, wonder why apt-get install cloud-init doesn't install the growpart utility
[15:23] <nacc> erick3k: presumably because installing that package changes functionality which should be opt-in not on by default?
[15:24] <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:25] <erick3k> ok
[15:25] <rharper> there's always a tradeoff w.r.t default package lists
[22:29] <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:44] <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:45] <rharper> looks like a handy util;  it could be merged under cloud-init/tools  if it's still useful
[22:49] <powersj> rharper: there was a suggestion to put it in cloud-utils as well
[22:55] <rharper> ah
[22:55] <rharper> powersj: that's also a possibility