[09:44] <harmw_> I have no idea how the current/latest fbsd stuff works out for c-i
[09:44] <harmw> it's been quite a while
[14:18] <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:19] <smoser> but i have said before, attempting to do  dynamic interface over config drive is really just stupid, and should not be attempted.
[17:48] <harlowja> smoser ya, the shitty part is that we have folks here who poll the metadata stuff to see when it changes
[17:49] <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:50] <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:51] <smoser> what would change in the md ?
[17:51] <harlowja> so the guys here alter the instance users via it apparently
[17:52] <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:53] <harlowja> not sure why nova allows updating that stuff and having it be reflected
[17:53] <harlowja> (abuse waiting to happen)
[17:54] <harlowja> (maybe its one of those bug-features, lol)
[17:54] <harlowja> (that snuck in)
[17:55] <harlowja> anyways, i'm not super-attached to that, the guys here have 'used this feature' (for better/worse), ha
[17:58] <harlowja> it just does raise the question, how do things that change get reflected in the instance (long polling metadata, repeated polling ... blah blah)
[18:00] <harlowja> smoser how does amazon do this, just repeated polling?
[18:04] <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:05] <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:06] <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:07] <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:08] <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:09] <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:10] <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:11] <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:12] <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:13] <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:17] <harlowja> openstack is weird
[18:17] <harlowja> ha
[18:23] <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:24] <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:30] <smoser> harlowja, i didn't know of pythonn -m json.tool
[18:30] <smoser> thats nice
[18:31] <smoser> rharper, ^ . that is easy pretty print of json
[18:32] <smoser> harlowja, yeah, you need etcd or zookeeper.
[18:33] <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:35] <harlowja> :)
[18:47] <rharper> smoser: nice
[18:56] <smoser> harlowja, so in rhel/centos
[18:57] <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:58] <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:59] <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
[19:00] <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:05] <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:06] <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:07] <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:08] <harlowja> pretty sure i can just use the better one and delete mine, lol
[19:10] <smoser> yeah. i think so. get rid of yours. as the other is pretty good at thsi point.
[19:18] <harlowja> ya
[20:14] <sather> when making a custom module, why is #cloud-config needed at the top of the injected user-data to 'activate' the module?
[20:32] <smoser> sather, custom module ?
[21:00] <sather> smoser: cloud-init directive
[21:01] <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:02] <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:03] <sather> Passing it as user-data though will get it to run?
[21:04] <sather> (assuming it has #cloud-config as first line of the file)?
[21:06] <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:08] <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:09] <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:10] <sather> when the user-data text has the key `do_something:` it runs that module
[21:11] <sather> so it's not a part-handler
[21:12] <smoser> sather, right. it doesn't work like that.
[21:12] <smoser> you have to enable your module
[21:13] <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:14] <sather> interesting. I'm not sure how this is working then
[21:15] <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:16] <sather> (original question was escaping #cloud-config at the top of the injected user-data)
[21:18] <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