| harmw_ | I have no idea how the current/latest fbsd stuff works out for c-i | 09:44 |
|---|---|---|
| === harmw_ is now known as harmw | ||
| harmw | it's been quite a while | 09:44 |
| === smoser` is now known as smoser | ||
| smoser | harlowja, i do not remember any specs per say on updating metadata. I'm not sure whether or not the MD gets updated if you add a device or not (in the openstack metadata service) | 14:18 |
| smoser | but i have said before, attempting to do dynamic interface over config drive is really just stupid, and should not be attempted. | 14:19 |
| harlowja | smoser ya, the shitty part is that we have folks here who poll the metadata stuff to see when it changes | 17:48 |
| harlowja | and instead if said polling turned into 'wait for event that configdrive ejected and reinserted' that'd at least avoid polling | 17:49 |
| smoser | you can't just pull a disk from a guest | 17:49 |
| smoser | and expect that that wont up upset something | 17:49 |
| smoser | try it, just yank your disk from your mac. see what happens. | 17:49 |
| smoser | its *not* a sane event mechanism. | 17:50 |
| harlowja | k | 17:50 |
| smoser | what would change in the md ? | 17:50 |
| harlowja | macs don't have disks | 17:50 |
| harlowja | lol | 17:50 |
| harlowja | my mac runs off pixie dust | 17:50 |
| harlowja | lol | 17:50 |
| harlowja | obviously | 17:50 |
| smoser | well, pry it open, get something to dissolve the glue, then rip it out | 17:50 |
| harlowja | lol | 17:50 |
| smoser | what would change in the md ? | 17:51 |
| harlowja | so the guys here alter the instance users via it apparently | 17:51 |
| harlowja | and apparently that works | 17:52 |
| harlowja | http://lists.openstack.org/pipermail/openstack-dev/2016-June/097705.html | 17:52 |
| harlowja | and it appears u can update said stuff, which is werid | 17:52 |
| harlowja | not sure why nova allows updating that stuff and having it be reflected | 17:53 |
| harlowja | (abuse waiting to happen) | 17:53 |
| harlowja | (maybe its one of those bug-features, lol) | 17:54 |
| harlowja | (that snuck in) | 17:54 |
| harlowja | anyways, i'm not super-attached to that, the guys here have 'used this feature' (for better/worse), ha | 17:55 |
| harlowja | it just does raise the question, how do things that change get reflected in the instance (long polling metadata, repeated polling ... blah blah) | 17:58 |
| harlowja | smoser how does amazon do this, just repeated polling? | 18:00 |
| smoser | i completely disagree with "abusing nova" | 18:04 |
| smoser | metadata is dynamic. config drive should not be. | 18:04 |
| harlowja | but config-drive has equivalent of metadata in it | 18:04 |
| harlowja | aka its a mirror of metadata | 18:04 |
| harlowja | so then its a bad equivalent of the metadata service | 18:05 |
| smoser | yes | 18:05 |
| smoser | web services are read/write and dynamic | 18:05 |
| harlowja | ya, so then maybe config-drive needs to be dumber | 18:05 |
| smoser | disks are read/write and dynamic, but i dont think you really want to deal with that. | 18:06 |
| harlowja | and not contain a full mirror | 18:06 |
| smoser | i really think basically config drive should provide you with networking information that is guaranteed static | 18:06 |
| smoser | and tells you where you can get dynamic information | 18:06 |
| smoser | wrt disks being read/write and dynamic... | 18:07 |
| smoser | one could argue that since disks *are* read/write, then the guest should be able to modify the contents of metadata by updating a key in the json and writing the new file | 18:07 |
| harlowja | ya, so it either is accepted that its not a full equivalent, orrr it is mutated into being that | 18:07 |
| smoser | and the host should have to deal with that | 18:07 |
| harlowja | right, the pull the disk solution | 18:08 |
| smoser | but that woudl be more insane than posting events through a iso9660 filesystem | 18:08 |
| smoser | (i was suggesting guest tells host, and host tells guest... | 18:08 |
| smoser | ie, bi-directional | 18:08 |
| harlowja | sounds like a qemu-metadata-agent would be better than | 18:08 |
| harlowja | which then is pretty much the metadata service | 18:09 |
| harlowja | lol | 18:09 |
| smoser | right. | 18:09 |
| smoser | except for web services do not poll well | 18:09 |
| smoser | as you suggested | 18:09 |
| smoser | but long-poll may be acceptable | 18:10 |
| smoser | i hadnt thought of metadata changing | 18:10 |
| harlowja | ya, i wasn't really aware this was a feature, ha | 18:10 |
| harlowja | until i tried it, lol | 18:10 |
| smoser | but for other events such as hotplug or remove of a disk or network, you do get an event sent to the guest | 18:10 |
| smoser | which it can respond to | 18:10 |
| smoser | ideally the networking information in the MD woudl get updated | 18:11 |
| harlowja | right, so its not like it would be impossible to do the eject metadata disk/cd | 18:11 |
| harlowja | (if full parity is really wanted) | 18:11 |
| harlowja | it might just be weird (ie for windows) | 18:11 |
| harlowja | (and the program doing something with that disk needs to be written so that it can have the disk drop at anytime..) | 18:11 |
| smoser | what happens if you eject while the guest is doing a read ? | 18:12 |
| smoser | or has it mounted. | 18:12 |
| smoser | and thus has whatever flag in that cdrom there is that says "no thank you" to the eject button | 18:12 |
| harlowja | ya, that sucks | 18:12 |
| harlowja | lol | 18:12 |
| smoser | there are solutions to this, and those solutions should be used. | 18:12 |
| smoser | ie, etcd or zookeeper | 18:13 |
| smoser | or fancier stuff like that. | 18:13 |
| harlowja | ya | 18:13 |
| harlowja | nova is weird | 18:13 |
| harlowja | lol | 18:13 |
| harlowja | in that this feature exists, people started using it, but it is pretty shoddy lol | 18:13 |
| harlowja | and half-parity and half... | 18:13 |
| harlowja | openstack is weird | 18:17 |
| harlowja | ha | 18:17 |
| smoser | the nova metadata service really should not be used as a replacement for zookeeper or etcd and the like. | 18:23 |
| smoser | i do agree that that is a bit of abuse. | 18:23 |
| smoser | i think its sane to expect metadata to change in it. | 18:23 |
| smoser | i think its *insane* to expect config drive to change | 18:23 |
| harlowja | k | 18:24 |
| harlowja | ya, the feature parity of what is config-drive and what is not then i think needs to happen | 18:24 |
| smoser | harlowja, i didn't know of pythonn -m json.tool | 18:30 |
| smoser | thats nice | 18:30 |
| smoser | rharper, ^ . that is easy pretty print of json | 18:31 |
| smoser | harlowja, yeah, you need etcd or zookeeper. | 18:32 |
| smoser | or probably one of 30 different other solutions | 18:33 |
| harlowja | ya | 18:33 |
| harlowja | something like that | 18:33 |
| smoser | and then... | 18:33 |
| smoser | in full openstack style | 18:33 |
| smoser | you should suggest a project to run that as a service | 18:33 |
| harlowja | :) | 18:35 |
| rharper | smoser: nice | 18:47 |
| smoser | harlowja, so in rhel/centos | 18:56 |
| smoser | we're not currently writing any .link files for renaming | 18:57 |
| smoser | but i tihnk you do write the 70-persistent-net files | 18:57 |
| smoser | is that right ? | 18:58 |
| harlowja | ya, i do write it | 18:58 |
| smoser | i jsut realized that on ubuntu, we're writing those .link files, but they will [almost] never be read. | 18:58 |
| smoser | or respected at least | 18:58 |
| smoser | as cloud-init then reads the config drive information and renames them himself. | 18:58 |
| harlowja | ya, i also noticed that the team here is injecting dns searchdomains into the old eni format | 18:59 |
| harlowja | and it appears neutron doesn't put those in yet | 18:59 |
| smoser | ? | 19:00 |
| harlowja | it only appears to put in the nameservers, but not the searchdomains (and there is ongoing/idle/dead? work in neutron to fix this) | 19:00 |
| smoser | oh. | 19:00 |
| smoser | so your openstack declares networking in the old ENI format way | 19:00 |
| harlowja | ya, which does look for search domains | 19:05 |
| harlowja | it appears the network_data json stuff doesn't have that, lol | 19:05 |
| harlowja | https://bugs.launchpad.net/neutron/+bug/1108644 | 19:05 |
| harlowja | not implemented (yet) | 19:06 |
| harlowja | so ummm, ya, oops | 19:06 |
| harlowja | and afaik the old renderers will use that if its avail | 19:06 |
| harlowja | while the newer ones may or may not | 19:07 |
| harlowja | ha | 19:07 |
| harlowja | https://code.launchpad.net/~harlowja/cloud-init/cloud-init-dns-sysconfig/+merge/297817 at least uses it if it exists (which in openstack case it won't, lol) | 19:07 |
| harlowja | pretty sure the eni renderer already uses it (if it exists) | 19:07 |
| harlowja | smoser also, something we need to cleanup is the 2 eni parsers that now exist, lol | 19:07 |
| harlowja | pretty sure i can just use the better one and delete mine, lol | 19:08 |
| smoser | yeah. i think so. get rid of yours. as the other is pretty good at thsi point. | 19:10 |
| harlowja | ya | 19:18 |
| sather | when making a custom module, why is #cloud-config needed at the top of the injected user-data to 'activate' the module? | 20:14 |
| smoser | sather, custom module ? | 20:32 |
| === gfidente is now known as gfidente|afk | ||
| sather | smoser: cloud-init directive | 21:00 |
| sather | http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/config/cc_foo.py | 21:01 |
| smoser | if you provide cloud-config via user-data, it must start with #cloud-config (or in a multipart archive, it must be type cloud-config) | 21:01 |
| sather | building off of ^^ | 21:01 |
| smoser | in order for a moulde to be run, though, it has to be listed in the /etc/cloud./cloud.cfg | 21:02 |
| smoser | they're not discovered. | 21:02 |
| sather | hmm | 21:02 |
| sather | Passing it as user-data though will get it to run? | 21:03 |
| sather | (assuming it has #cloud-config as first line of the file)? | 21:04 |
| smoser | no. | 21:06 |
| smoser | you cannot really pass in config modules | 21:06 |
| smoser | you *can* pass in 'handlers' | 21:06 |
| sather | ok, that's what I'm doing | 21:06 |
| sather | sorry for the confusion | 21:06 |
| smoser | well, i dont knwo that you are. | 21:06 |
| smoser | http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/examples/part-handler-v2.txt | 21:08 |
| smoser | that is a part handler | 21:08 |
| smoser | you can pass it in as user-data. | 21:08 |
| sather | ok no | 21:09 |
| sather | I'm passing a yaml-formatted text file | 21:09 |
| sather | with #config-data on top | 21:09 |
| smoser | right. | 21:09 |
| sather | I have a custom cc_do_something.py module in my /usr/lib/python/site-packages/cloudinit/config | 21:09 |
| sather | directory | 21:09 |
| sather | when the user-data text has the key `do_something:` it runs that module | 21:10 |
| sather | so it's not a part-handler | 21:11 |
| smoser | sather, right. it doesn't work like that. | 21:12 |
| smoser | you have to enable your module | 21:12 |
| smoser | by adding it to one of the sections (cloud_init_modules, cloud_config_modules, or cloud_final_modules) | 21:13 |
| smoser | then cloud-init will run it and feed it the whole config | 21:13 |
| smoser | which you can do whatever you want with | 21:13 |
| sather | interesting. I'm not sure how this is working then | 21:14 |
| sather | I kind of re-implemented cc_write_files.py because I have to use a specifically formatted yaml file and can't prepend the necessary info for write_files | 21:15 |
| sather | but it seems to work without touching /etc/cloud/cloud.cfg | 21:15 |
| sather | (original question was escaping #cloud-config at the top of the injected user-data) | 21:16 |
| sather | by 're-implemented' I mean I just used cc_foo.py as a base and wrote to a file using the value from cfg['key'] | 21:18 |
| sather | without using cloudinit.util | 21:18 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!