[13:44] <smoser> cn28h, it stops at the first.
[13:45] <cn28h> aha ok, hm
[13:45] <Odd_Bloke> cn28h: You can configure which data sources it will look at, though.
[13:45] <smoser> gamename (who is gone), cloud-init doesn't currently "pick" eth0. it starts running when the OS's networking is up.
[13:45] <smoser> right, Odd_Bloke you coudl tell cloud-init to not use the openstack, but another entirely.
[13:46] <smoser> or you could (i think) tell cloud-init to use the openstack one, but with a different url (ie, not 169.254.169.254, and use a URL you have control of)
[13:46] <smoser> those things have to be configured prior to cloud-init running.
[13:46] <Odd_Bloke> (I guess you'd also need to skip EC2, as OpenStack provides an EC2-compatible metadata service)
[13:46] <smoser> ie, you can't tell cloud-init where to find data in the data that you're providing it.
[13:46] <smoser> it unfortunately can't read your mind.
[13:47] <smoser> openstack is before EC2 in the order, so that cloud-init will prefer the openstack MD to ec2.
[13:47] <smoser> but, yeah, Odd_Bloke you're right. youd' have to tell it not to look ther also.
[13:48] <smoser> nk121, you should 'apt-get install pastebinit'
[13:48] <smoser> and use pastebinit  :)
[13:48] <smoser> then i dont have to go to pastebin.com urls and look at all those adds.
[13:48] <smoser> er... ads.
[13:48] <cn28h> smoser: you mean, there may be a way to configure the openstack datasource to look elsewhere? (that would be great -- I'd been thinking I'd have to actually go subclass the implementation and replace the user data logic)
[13:49] <smoser> yeah, that may be configurable
[13:49] <smoser> the openstack one is.
[13:49] <smoser> er.. the ec2 one is.
[13:49] <cn28h> ah, very interesting
[13:49] <smoser> or you could use "nocloud"
[13:49] <smoser> which is pretty simple also.
[13:49] <smoser> you just need a base-url with a 'user-data' and 'meta-data'
[13:50] <smoser> harlowja_away, what "archive" format would you want for multipart
[13:50] <cn28h> yeah that's an interesting idea -- we *are* using other features like key injection via openstack, but I suppose I can use a shellscript to grab that from the metadata service and stage it.. less elegant but workable
[13:51] <smoser> :)
[13:51] <smoser> yeah.
[13:52] <smoser> cn28h, look at doc/examples/cloud-config-datasources.txt
[13:52] <smoser> thats how you confgiure a datasource... the key 'metadata_urls' that you see in Ec2 is also valid for openstack
[13:52] <smoser> per my reading of the code
[13:53] <smoser> it looks like it reads:
[13:53] <smoser>  metadata_urls
[13:53] <smoser>  max_wait
[13:53] <smoser>  timeout
[13:55] <smoser> nk121, i think you're using vivid ?
[13:56] <nk121> smoser: no trusty
[13:57] <cn28h> nice, yeah that will be great.  Now I just need to think of how to correlate it so I can return the right user data for that instance, hm
[13:57] <smoser> right.
[13:57] <smoser> that does suck.
[13:57] <smoser> you oculd look at source ip
[13:57] <smoser> as you should be albe to get the instances ip address
[13:57] <smoser> from openstack
[13:58] <smoser> that is essentially how the opestnack metadata service works
[13:58] <cn28h> ah, yeah that makes sense
[13:58] <cn28h> map it backwards by talking to neutron and figuring out which instance has that IP or some such
[14:04] <smoser> right.
[14:05] <smoser> cn28h, if you do this , it might be somewhat useful generically.
[14:05] <smoser> ie, a opensta-ck-metadata-aware proxy 
[14:05] <cn28h> hm
[14:05] <smoser> s/sta-ck/ck/
[14:06] <smoser> fairly simple given openstack admin credentials.
[14:06] <smoser> you just take input of a IP address and render the result.
[14:06] <smoser> you may even be able to re-use the openstack one.. but that might be difficult
[14:06] <cn28h> yeah, I will have to do some digging
[14:07] <cn28h> and discussion with the rest of my team -- they may well just tell me it's too crazy for their tastes and thatI need to find a different way ;p
[14:07] <cn28h> but it sounds like an interesting possibility
[14:08] <cn28h> really it would be nice if the other service currently camping on the user-data field was cloud-init compatible
[14:08] <cn28h> because it's just a handful of key-value pairs that could easily be written to a file and read from there instead ...
[14:09] <cn28h> but that belongs to a codebase we don't own
[14:09] <smoser> cn28h, so... if you're talking to that other service...
[14:09] <smoser> tell them they should support mime-multipart and pick out the pieces they're interetsed in
[14:09] <smoser> or use cloud-config-archive format (which i woudl admit is less "standardy")
[14:10] <smoser> this is waht cloud-init does... it pays attention only to things that are destined for it and ignores other things.t
[14:10] <cn28h> yeah, that makes much more sense so that you can share the user data
[14:10] <smoser> right.
[14:10] <cn28h> maybe I will open a JIRA with a feature request
[14:12] <smoser> nk121, i'm not sure what i'm seeing there really... 
[14:12] <smoser> nk121, /var/log/cloud-init-output.log might hvae more info
[15:54] <gamename> Hi.  How does cloud-init know which device (e.g. eth0)  as the preferred network interface?
[16:20] <Odd_Bloke> 14:45:33 < smoser> gamename (who is gone), cloud-init doesn't currently "pick" eth0. it starts running when the OS's networking is up.
[16:29] <gamename> Odd_Bloke: Eh? Gone?  Is the status showing me offline?  Re: the question. Ah, ok.  cloud-init is agnostic about the network. It just uses whatever interface comes up. All correct? 
[16:33] <Odd_Bloke> gamename: You were gone when smoser said that, ~3 hours ago. :)
[16:33] <Odd_Bloke> gamename: I believe your conclusion is correct, yes.
[16:33] <gamename> Odd_Bloke: Got it.  I didn't get the response. Sorry for the confusion. I'll check my client (or change the damn thing).
[17:05] <cn28h> smoser: so I had an interesting thought and figured I'd share.  If I create a really minimal web app that proxies *locally* I can leave all the heavy lifting in terms of correlation up to openstack because I can just forward requests off to the real thing locally. Then, I can intercept user-data and send that off somewhere else, along with fields I can pull from the metadata service myself to help correlate on the remote end. Should work as
[17:05] <cn28h> long as I can guarantee it's up and running before cloud-init runs.
[17:32] <harlowja> smoser just some simple directory structure would seem like it could replace the whole MIME stuff
[17:32] <harlowja> file + directory struture
[17:32] <harlowja> ^ is also then easily examinable...
[22:54] <harlowja> smoser https://code.launchpad.net/~harlowja/cloud-init/write-files-fetch-from-somewhere should be fixed up