Investigate and merge OpenStack-related LXD patches
via IRC:
180913 14:46:11 <boxrick> Hello!
180913 14:46:48 <boxrick> dw: I have had to put a hack in mitogen for the lxd stuff to make it work. See https://github.com/boxrick/mitogen/commit/1a2af1cbc52e39c5571a22a303b2ea1bb4ad41eb
180913 14:47:08 <boxrick> But basically LXD can never work with FQDN or . so ideally it should be hostname.
180913 14:47:40 <boxrick> I am not sure if it needs some sort of override or to do something similar to my hack above, any suggestions would be welcomer
180913 14:47:44 <boxrick> welcome*
See also https://github.com/dw/mitogen/issues/409
Related patches are in jrosser@edba3fb
I think this LXD issue is fine and fixes the specific issue for LXD, using mitogen_via.
The issue with OSA (remember that is LXC, but fundamentally the same low level stuff) is that the 'via' host is already expressed differently in the OSA inventory as the hostvar 'physical_host', so it may be as trivial as mitogen_via: {{ physical_host | default(inventory_hostname) }} or somesuch. I tried rebasing my one line hack onto master and it looks like the connection code has been refactored a little - perhaps time to address the root of it rather than just hack it?
I split out the big hairy config dict building into classes, it still works the same way as before, just a lot more room to breathe, and also a little CPU saved because the expressions are lazy now.
I haven't checked what upstream does -- but if the current field being used doesn't match there, and that's why you need to hack it, we could just treat this as a compatibility bug and flip the current default.
IIRC your suggestion was to make this configurable somehow. I'm more than happy with that. "mitogen_
# PlayContextSpec
def mitogen_foo_container_field(self):
return self._connection.get_task_var('mitogen_foo_container_field')
# MitogenViaSpec
def mitogen_foo_container_field(self):
return self._host_vars.get('mitogen_foo_container_field')
In the classes of transport_config.py, then in the LXC argument building function, just parameterize the field based on that.
The alternative is a quietly undocumented environment variable :) I'm easy either way. Those spec classes are going to grow over time regardless.