| kylestev | why isn’t `blkid` mocked? basically, why do I have to run tests as root on debian? ;_; | 01:15 |
|---|---|---|
| === harlowja is now known as harlowja_away | ||
| === praneshp_ is now known as praneshp | ||
| === evilissimo|afk is now known as evilissimo | ||
| === praneshp_ is now known as praneshp | ||
| === praneshp_ is now known as praneshp | ||
| linuxgeek_ | ping | 12:46 |
| linuxgeek_ | !ping | 12:46 |
| linuxgeek_ | hey harlowja_away | 12:46 |
| === zz_gondoi is now known as gondoi | ||
| === evilissimo is now known as evilissimo|afk | ||
| === harlowja_away is now known as harlowja | ||
| linuxgeek_ | hi harlowja | 19:02 |
| harlowja | linuxgeek_ howdy | 19:02 |
| linuxgeek_ | harlowja, fairly well, thanks. | 19:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| harlowja | so its 'special' | 19:09 |
| linuxgeek_ | yes o~s and ec2 is so different | 19:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:19 |
| 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:21 |
| 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:22 |
| 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. | 19:23 |
| === gondoi is now known as zz_gondoi | ||
| === praneshp_ is now known as praneshp | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!