On Dec 16, 2019, at 11:46 AM, Sagi Shnaidman sshnaidm@redhat.com wrote:
Hi, all
recently we had an Openstack Ansible modules meeting, when were discussing how we will manage current modules and new planned modules. Because it was a hot topic which took most of the time and no agreement was reached, I think it's worth to discuss it here in ML.
Options that have been raised in the discussion[1]:
- To freeze current modules and start writing new modules from scratch
- To freeze current modules and based on them develop new modules
- To continue to work on current modules and change them step by step
I believe we should, generally speaking, do this. The ansible folks have some things in place (or plan to have some things in place) that should make this reorg otherwise transparent, so I don’t think we should just change things on users.
I followed up with gundalow about how things are going to work - here is a summary:
In ansible/ansible there is a file called BOTMETA.yml. In that file, we’ll put in entries like:
$modules/cloud/openstack/openstack/os_server: migrated_to: openstack.cloud.server
This lets us map old module names `os_server` to new collection paths `openstack.cloud.server`.
When the ansible source tarball or wheel are made, BOTMETA will be consulted, needed collections will be downloaded and symlinks will be made from the old module names to the new module names.
So - for a user who runs “pip install ansible” (and presumably also dnf install ansible or apt-get install ansible) - they will get things installed as they always have been and they will not need to break any of their playbooks.
This is intended to be done in perpetuity.
The lifecycle of our new modules n the collection is a continuation of the existing modules - so I believe we should take care to maintain backwards compat.
Also - since someone asked at the meeting - yes, this includes things like the dynamic inventory plugin - so we’ll be moving all of the content over.
It is currently undefined what the behavior will be if someone says “pip install ansible ; ansible-galaxy collection install openstack.cloud” For sure doing that and then referencing openstack.cloud.server in a playbook will get the new content. It is undefined as of now whether that will update os_server. Toshio is working on defining this, so if we have opinions we should talk to him about it.
Because we have the renaming capability via BOTMETA - we get a nice opportunity to clean things up in our collection. For that reason, I believe we are all agreed to:
* Drop os_ underscore in the collection version * Drop service_type prefix on ‘admin” modules
So that will have: * os_server -> oppenstack.cloud.server * os_ironic_node -> openstack.cloud.baremetal_node (or something better)
NOW - there are some modules we may need to be more aggressive with as far as changes go. I think for those, we have a few options:
- Do the breaking changes behind a feature flag in the parameters, set a deprecation on the old behavior and after 2 releases change the default on the feature flag. - Make a completely new module and deprecate the old one.
But I think we should take each case of that as it comes as a specific case. The one thing that has been brought up specifically is Dmitry mentioned we may need to improve the auth story for standalone ironic. That may be true - but I’m not yet convinced this needs to be breaking. Yet. But if it needs to be - we can solve it.
Because we have control over the whole collection - we can do a better job with module_utils - and we can make additional constructor methods if needed. I’ve got a patch up:
https://review.opendev.org/#/c/698044/
With an example of making a base class instead of a factory function. It might not yet be the right design, but hopefully it shows how we can clean some things up as we move forward.
- In case of freezing current modules, deprecate them later
Things to consider:
- People are using current modules in playbooks and we don't want to break them, so current modules interfaces should stay available and not change for not breaking backward compatibility
- We might redesign some of modules, including big changes in common modules parts
- We might redistribute current module functionality over other and new modules
I think it can be a start for the discussion on how to move further, please comment.
Thanks
[1] http://eavesdrop.openstack.org/meetings/api_sig/2019/api_sig.2019-12-12-16.0...