[15:52] <msbrown> Hey, have an oddball situation. I've taken a server installed via maas (d-i install), and moved it off of maas to be a stand-alone server. What's the best way to disable the cloud-init boot sequence?
[16:14] <smoser> msbrown, you can probably 
[16:14] <smoser> dpkg-reconfigure cloud-init
[16:14] <smoser> and just seleect the None datasource
[16:14] <msbrown> thx
[16:15] <smoser> if that doesn't work, then i'd just put some data in /var/lib/cloud/nocloud/seed
[16:15] <smoser> so that it would think it found *that* datasource all the time.
[16:15] <msbrown> I'll try the first method
[16:17] <msbrown> well, that makes the boot faster, you get some ugly messaging but as long as you know to ignore it....
[16:21] <msbrown> (whatever you do, *don't* just delete all the cloud* entries from /etc/init :-)
[16:41] <SpamapS> smoser: question
[16:41] <SpamapS> smoser: oh and HI
[16:41] <SpamapS> smoser: so, cloud-config sets the hostname right?
[16:41] <SpamapS> smoser: I'm considering that we need to delay runlevel 2 until after cloud-config finishes
[16:42] <SpamapS> smoser: thoughts on that?
[16:42] <SpamapS> smoser: we're having problems where things don't always get the same hostname on reboot because they start faster the second time for whatever reason.. just before cc_set_hostname runs
[16:57] <smoser> ubuntu ?
[16:58] <smoser> SpamapS, ?
[17:00] <SpamapS> smoser: yeah
[17:02] <SpamapS> smoser: this is with baremetal hardware, but using EC2 metadata.. so.. yeah.. we're on crack a bit. :)
[17:03] <smoser> cloud_init_modules should set hostname per default config
[17:03] <smoser> which should execute 
[17:03] <smoser> start on mounted MOUNTPOINT=/ and stopped cloud-init-nonet
[17:04] <smoser> which almost certainly should block the starting of runlevel 2
[17:06] <SpamapS> smoser: so cloud-config doesn't run the cc_* modules?
[17:11] <smoser> see cloud.cfg, SpamapS 
[17:11] <smoser> they run at different stages per that config
[17:11] <SpamapS> smoser: AH
[17:11] <SpamapS> misunderstanding resolved
[17:12] <SpamapS> smoser: ok.. so hm.. why are we seeing our hostname different on two successive boots.. argh
[17:12] <SpamapS> first boot we get no .novalocal
[17:12] <SpamapS> or we do, then second we don't get it.. I can't remember now
[17:13] <smoser> SpamapS, based on very little info, i guess its related to
[17:14] <smoser> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/sources/__init__.py#L169
[17:18] <SpamapS> smoser: we do have local-hostname
[17:19] <SpamapS> smoser: but good thinking :)
[19:01] <harlowja> SpamapS who are u, lol
[19:01] <harlowja> no cloudinit for u
[19:01] <harlowja> lol
[20:09] <SpamapS> harlowja: i can haz hostname plzzzzz
[20:45] <harlowja> SpamapS ha
[20:47] <harlowja> SpamapS let me know if u figured it out, can help if u don't
[20:48] <SpamapS> harlowja: I don't think our problem is cloud-init
[20:48] <SpamapS> something else subtle going on
[20:48] <harlowja> k
[20:49] <harlowja> stop doing those bad things then
[20:49] <harlowja> lol
[20:49] <SpamapS> am I the only one that thinks lol looks like a ghost raising its arms and chasing somebody from right to left?
[20:49] <SpamapS> lol==---...
[20:49] <harlowja> :)
[20:49] <harlowja> run away!
[20:50] <SpamapS> ..---[20:50] <harlowja> ha
[20:50] <SpamapS> well now it looks like bennie hill
[20:50] <harlowja> SpamapS do u know if anyone from HP is going to http://www.meetup.com/openstack/events/172017412/ ?
[20:50] <SpamapS> just need doors and gratuitous un-garmenting
[20:50] <harlowja> "OpenStack at Mega-scale"  (whatever that means)
[20:51] <SpamapS> harlowja: I hope so
[20:51] <harlowja> ya, i'm not sure i want to go yet, lol
[20:51] <SpamapS> harlowja: but most of our actual dev/ops who would be able to contribute are in "not bay area"
[20:51] <harlowja> megascale sounds to much like marketing blah blah
[20:51] <SpamapS> gigascale would be better
[20:51] <SpamapS> terascale
[20:52] <SpamapS> Have a competing meetup next door. "OpenStack at petascale"
[20:52] <harlowja> :)
[20:52] <harlowja> +2
[20:52] <harlowja> mine bigger than yours meetup
[20:52] <harlowja> *maybe shouldn't call it that*
[20:53] <SpamapS> might attract the wrong crowd
[20:53] <harlowja> :)
[20:53] <SpamapS> lol[20:53] <harlowja> ha
[20:53] <harlowja> ..---[20:53] <harlowja> ha
[20:54] <SpamapS> o/` [ kazoo music ] o/`
[20:55] <harlowja> ^ did the ghost just pass threw a kazoo?
[20:55] <harlowja> cause ghosts can do that afik
[20:55] <harlowja> *afaik
[21:33] <lipinski> How do I get a VMs instance id via cloud init?  e.g., the one that is in openstack meta-data.json?
[21:39] <harlowja> cat /var/lib/cloud/data/instance-id
[21:39] <harlowja> *thats one way
[21:45] <lipinski> harlowja: that's not the instance ID I need.  I think that's the EC2 one?  I need the one that is available via Openstack metadata
[21:45] <lipinski> e.g., curl 169.254.169.254/openstack/latest/meta_data.json (uuid)
[21:45] <harlowja> ah, which cloud-init are u using
[21:46] <lipinski> My problem is that using the 169.254.169.254 ties me to the network-based metadata service.  I would like to use Cloud-init so that I am abstracted from metadata via network vs cloud-drive
[21:46] <lipinski> one sec
[21:46] <harlowja> yup, the newest cloud-init has that abstraction
[21:46] <lipinski> 0.7.2-2.el6.noarch
[21:46] <harlowja> ya, that one only knows how to fetch from the EC2 metadata/userdata from 169
[21:47] <harlowja> which is why u see the ec2 id
[21:47] <lipinski> Is there a newer Cloud-Init that would give me what I need?
[21:47] <lipinski> (hopefully in a RHEL6 RPM form.. :) )
[21:48] <harlowja> ya, 0.7.5 would have what u need, although u'll need to build your own rpm afaik
[21:48] <harlowja> which isn't that hard to do since the cloud-init code has that
[21:48] <harlowja> i don't think rhel has published that version yet
[21:49] <lipinski> harlowja: thanks a bunch.  So, the UUID/VMID that I'm looking for would then be accessible via /var/lib/cloud/data/instance-id ?  Or somewhere else?
[21:49] <harlowja> that'd be the place
[21:54] <lipinski> fantastic.  thanks again.
[21:58] <lipinski> harlowja: sorry to bother again.  0.7.4-2 have what I need, or do I need 0.7.5?
[22:05] <harlowja> i think 0.7.5
[22:05] <harlowja> which was just released afaik
[22:09] <harlowja> the other option is u can just add a script into user-data that fetches that information lipinski (basically running `curl 169.254.169.254/openstack/latest/meta_data.json`)
[22:11] <lipinski> harlowja: thanks.  Yes - I may do that as a stop-gap measure until we can get to 0.75.
[22:11] <harlowja> right
[22:11] <harlowja> shouldn't be to bad, could even do something simple in python to get it
[22:12] <harlowja> although u should be able to checkout cloud-init and run 'make rpm' and a rpm should pop out
[22:12] <lipinski> I didn't want to get into the "business" of interfacing with metadata services.  Prefer Cloud-Init do the lifting for me and that way I get cloud-drive+metadata support without any change on my side :)
[22:12] <harlowja> yup
[22:13] <lipinski> I've never downloaded cloud-init before (since we get RPMs).  
[22:13] <lipinski> Thanks again.
[22:14] <harlowja> np