[01:15] <kylestev> why isn’t `blkid` mocked? basically, why do I have to run tests as root on debian? ;_;
[12:46] <linuxgeek_> ping
[12:46] <linuxgeek_> !ping
[12:46] <linuxgeek_> hey harlowja_away 
[19:02] <linuxgeek_> hi harlowja 
[19:02] <harlowja> linuxgeek_ howdy
[19:02] <linuxgeek_> harlowja, fairly well, thanks.
[19:03] <linuxgeek_> re yesterday's thingy on the cloudinit. with a trusty ubuntu cloud image
[19:03] <linuxgeek_> i was able to test the http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/examples/cloud-config-boot-cmds.txt
[19:03] <linuxgeek_> and it works
[19:03] <harlowja> woot
[19:03] <linuxgeek_> there is another cloud image which is vmdk fedora 19
[19:04] <harlowja> k
[19:04] <harlowja> that one might not have cloud-init built in, or does it?
[19:04] <linuxgeek_> and that is not able to reach the metadata service url http://169.254.169.254
[19:04] <linuxgeek_> hence the userdata also does not work
[19:05] <linuxgeek_> how is it that one image works while the other does not
[19:05] <linuxgeek_> is this specific to how the image is built?
[19:05] <linuxgeek_> yes it does have cloud-init in it
[19:05] <linuxgeek_> i can see the cloud directory in /var/lib and cloud-init.log in /var/log
[19:06] <linuxgeek_> so it is a cloud-init enabled image
[19:06] <harlowja> it is likely more how the image was built, what firewall settings (?) could be by default on
[19:06] <harlowja> that should be the only difference really
[19:06] <linuxgeek_> ok
[19:06] <harlowja> and those differences could stop it from contacting 169
[19:07] <linuxgeek_> is this a internal url?
[19:07] <harlowja> define internal ;)
[19:07] <linuxgeek_> lol :-)
[19:07] <harlowja> its a special IP
[19:07] <linuxgeek_> internal = within the instance and not going outside
[19:08] <harlowja> not usually
[19:08] <harlowja> http://stackoverflow.com/a/7499376  is an idea of what it does
[19:08] <harlowja> but it varies depending on the cloud u are on (the exact details vary)
[19:08] <harlowja> openstack clouds do it differently than amazon and so-on...
[19:09] <harlowja> so its 'special'
[19:10] <linuxgeek_> yes o~s and ec2 is so different
[19:11] <linuxgeek_> and i have o~s based cloud env
[19:11] <linuxgeek_> i read http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AESDG-chapter-instancedata.html
[19:11] <linuxgeek_> and the stackoverflow post.
[19:12] <linuxgeek_> so it says ec2 knows what instance is making the request and it knows the info abt the instance 
[19:12] <harlowja> right, openstack is the same
[19:12] <linuxgeek_> so ec2 can return the metadata that is requested
[19:12] <harlowja> right
[19:13] <linuxgeek_> so this happens even before the request reaches the special ip?
[19:13] <harlowja> right, it happens during vm building time
[19:13] <harlowja> so my guess is if it works for one image and not another, then its an image thign
[19:13] <linuxgeek_> ok
[19:13] <harlowja> thats my gut feeling
[19:13] <harlowja> i'm not sure what the solution is though ;)
[19:14] <linuxgeek_> the flow is, the instance makes a request to the special ip based on the userdata injected to it
[19:14] <harlowja> and before that happens, neutron, nova, make it possible for that special IP to be directed somewhere
[19:14] <linuxgeek_> the openstack sees this request and knows which instance is sending this request
[19:14] <harlowja> ya
[19:14] <harlowja> and sends back some data
[19:15] <harlowja> and that goes through the pipes and pops back up in the instance
[19:15] <harlowja> the instance thinks it talked to a magic 169 address and was none-the-wiser
[19:15] <harlowja> ^ pipe magic
[19:16] <linuxgeek_> is it nova neutron which plays a role in routing the request to the special ip via the nova/neutron security groups and rules?
[19:17] <harlowja> both afaik
[19:17] <linuxgeek_> i'm planning to convert the trusty.img file [which works] to a trusty.vmdk and test
[19:17] <harlowja> i believe nova is the endpoint and has the instance data, neutron sets up the plumbing
[19:17] <harlowja> so both are involved
[19:19] <linuxgeek_> i browsed through the o~s docs and the net too, i did not find details about how nova and neutron play a role in the metadata part. do you happen to know of a doc or a guide which talks about this?
[19:19] <harlowja> i do not, but if u jump in #openstack-neutron  channel u might find someone who does
[19:19] <harlowja> there should be something somewhere i would think
[19:21] <linuxgeek_> have u used qemu-img convert?
[19:21] <harlowja> i have
[19:21] <linuxgeek_> sure, i'm on the neutron channel. i'll ask arnd for the docs
[19:21] <linuxgeek_> cool, have u converted a .img file to .vmdk?
[19:22] <harlowja> negative, i haven't touched vmdk stuff :)
[19:22] <harlowja> i have done raw -> qcow2 and qcow2 -> raw
[19:22] <harlowja> but not vmdk stuff
[19:22] <harlowja> linuxgeek_ mestery on the neutron channel should be able to find something
[19:23] <harlowja> i thought arnd was more in glance (maybe different arnaud)
[19:23] <harlowja> or maybe someone else, haha
[19:23] <linuxgeek_> haha, yep sure.