| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-12-12 | |||
| 16:26:08 | mordred | and people using collection explicitly will use colledction paths | |
| 16:26:15 | dtantsur | (and assuming we won't need other per-module breaking changes) | |
| 16:26:27 | mordred | dtantsur: well - it's sounding like there's less implicit breaking than we thought before | |
| 16:26:33 | gtema | let's do all breaking as new modules | |
| 16:26:43 | gtema | with a fresh design | |
| 16:26:44 | mordred | so maybe we should figure out what we want to do with auth and see if we can figure out a way to do it non-breaking | |
| 16:26:47 | dtantsur | gtema: the question was whether we need new modules | |
| 16:26:59 | gtema | sure we need | |
| 16:27:02 | mordred | gtema: I don't want two different designs - we don't have enough people working on this to support that :) | |
| 16:27:11 | pabelanger | +1 | |
| 16:27:12 | mordred | we *barely* have enough people to keep the ones we have going | |
| 16:27:20 | gtema | we currently do not have possibility to manage tags, and I do not really want to modify each module with tagging mess | |
| 16:27:27 | dtantsur | at the very least we need to think how to support all session AND adapter options | |
| 16:27:32 | mordred | yes | |
| 16:27:32 | dtantsur | I think we don't do it now | |
| 16:27:41 | mordred | well - we assume for complex options you'll use clouds.yaml | |
| 16:28:01 | mordred | dtantsur: and you can pass a full clouds.yaml yaml snippet to the cloud parameter of the module too | |
| 16:28:02 | sshnaidm | there are some modules like ironic_node that should be redesigned at all | |
| 16:28:18 | dtantsur | I'm talking simple: {auth_type: none, endpoint_override: https://bare.metal} | |
| 16:28:23 | mordred | that said- if we NEED to redesign a module and deprecate the old one - we should totally do that | |
| 16:28:31 | mordred | dtantsur: that should work by passing to cloud: | |
| 16:28:46 | dtantsur | mordred: in cloud.yaml - yes (well.. maybe) | |
| 16:28:51 | mordred | no - in the module | |
| 16:29:04 | mordred | you can pass _anything_ to cloud: that you can put in a clouds.yaml cloud entry | |
| 16:29:27 | sshnaidm | mordred, I'm afraid changes in openstack.py may require redesign in most of modules.. | |
| 16:29:28 | dtantsur | I remember I had some problem. I need to check. | |
| 16:29:41 | mordred | sshnaidm: they might - and we might need to do some things | |
| 16:30:00 | mordred | I think what I'm saying is that it sounds like ansible/ansible is providing mechanisms to make this not an inhernet breaking change | |
| 16:30:08 | mordred | so our ground cover for making additional breaking changes is lower | |
| 16:30:17 | mordred | so we should at least TRY to not immediately make breaking changes | |
| 16:30:29 | mordred | we might find something that needs to be changed and we can't figure out non-breaking | |
| 16:30:29 | sshnaidm | mordred, deprecating old modules gives you more freedom to break things, then trying to keep backward compatibility | |
| 16:30:36 | mordred | and we'll just need to figure out how to not screw our users | |
| 16:30:42 | pabelanger | yes, please for users, don't break things out of gate :) | |
| 16:30:46 | mordred | sshnaidm: it does. but right now we're just supposing | |
| 16:30:53 | mordred | we don't have an actual thing that must be done that must be breakingm | |
| 16:31:14 | mordred | I agree - we can deprecate, we can copy/modiify - do lots of things | |
| 16:31:16 | mordred | let's just do those | |
| 16:31:34 | mordred | and not immediately jump to "upstream is breaking everyone anyway so we're safe" | |
| 16:31:49 | gtema | ok for me | |
| 16:31:51 | mordred | in fact ... OOH | |
| 16:31:57 | pabelanger | +100 | |
| 16:32:12 | mordred | no - neverind- I thought I had a new idea | |
| 16:32:14 | mordred | :) | |
| 16:32:29 | sshnaidm | ok, so what are we agreed on currently? :) | |
| 16:32:40 | mordred | that everyone here is awesome :) | |
| 16:32:43 | gtema | not to break immediately | |
| 16:32:48 | odyssey4me | I expect we'll be wanting to deprecate the dynamic inventory, given that the plugin interface is better anyway? | |
| 16:32:51 | sshnaidm | we continue to develop modules with old names and trying not to break current users? | |
| 16:32:58 | sshnaidm | mordred, ^^ ? | |
| 16:33:11 | mordred | odyssey4me: that's already dprecated? people should be using the plugin and not the script already | |
| 16:33:25 | mordred | sshnaidm: I think ansible/ansible has a solution for name mapping | |
| 16:33:33 | gtema | sshnaidm not to break != continue with old names for new things | |
| 16:33:41 | mordred | so I think we *can* rename | |
| 16:33:41 | odyssey4me | mordred: one would hope - I guess we could then remove it from ansible/ansible and not put it into the collection | |
| 16:33:50 | mordred | we just have to put the name mapping into botmeta in ansible/ansible | |
| 16:34:08 | sshnaidm | it's akward to have same modules with different names, either I don't understand something.. | |
| 16:34:16 | mordred | odyssey4me: you raise a good question ... can the inventory _plugin_ go into the collection too? | |
| 16:34:22 | pabelanger | yes | |
| 16:34:28 | mordred | sshnaidm: let me try to explain from scratch with an example | |
| 16:34:30 | sshnaidm | mordred, can you bring an example of rename? | |
| 16:34:33 | mordred | let's take os_server | |
| 16:34:36 | gtema | technically everything can go into collection | |
| 16:34:54 | pabelanger | gtema: yup! | |
| 16:35:01 | mordred | we put os_server into our collection, let's call it openstack.api for now (we need to bikeshed on that - but roll with it for a sec) | |
| 16:35:31 | mordred | so then the canonical name of the module ios openstack.api.os_server | |
| 16:35:46 | pabelanger | yes | |
| 16:35:53 | mordred | now - in the ansible/ansible repo there is a yaml file, BOTMETA.yml - and in it we put in an entry like: | |
| 16:36:00 | mordred | openstack.api.os_server: os_server | |
| 16:36:34 | mordred | this will cause ansible, when it builds its distros for pip and whatnot to grab the collection and make a symlink from os_server to openstack.api.os_server | |
| 16:36:45 | mordred | so people who aren't paying attention will have no changes happen to that | |
| 16:36:48 | sshnaidm | yeah, but where is the rename? | |
| 16:36:52 | mordred | hang on | |
| 16:37:11 | mordred | since that is the mechanism, there is then nothing stopping us from renaming the module in our collection to openstack.api.server | |
| 16:37:18 | mordred | and making the mpapping be openstack.api.server: os_server | |
| 16:37:28 | mordred | people using fully qualitied are fine | |
| 16:37:33 | mordred | people using omnibus symlinks are fine | |
| 16:37:36 | mordred | everyone is fine | |
| 16:37:54 | pabelanger | so, if I was do to ansible-galaxy collection install openstack.api I could both do openstack.api.os_server: ... and os_server: ... from playbook | |
| 16:37:57 | mordred | and eventually, in the fullness of time, maybe the synlink mapping goes away | |
| 16:38:01 | mordred | pabelanger: yah | |
| 16:38:02 | pabelanger | without botmeta.yml | |
| 16:38:02 | sshnaidm | mordred, that exactly what I mean, you install os_server and something new like openstack.api.server and it's the same module exactly | |
| 16:38:22 | mordred | pabelanger: right - but that keeps us tied to the old names | |
| 16:38:31 | mordred | botmeta lets us rename in teh collection without screwing people | |
| 16:38:33 | pabelanger | yes, agree | |
| 16:38:54 | pabelanger | so, if we did rename in collection | |
| 16:38:58 | mordred | assuming taht support exists and works - but according to gundalow it's pretty essential that it does | |
| 16:39:23 | pabelanger | actually | |
| 16:39:25 | sshnaidm | can we alert people that use os_server that it will be deprecated? | |
| 16:39:33 | sshnaidm | and not people that use openstack.api.server | |
| 16:39:50 | gtema | I guess they will need to adapt with Ansible 2.12 anyway | |
| 16:39:52 | pabelanger | okay, I need to look on our side, I am not sure how ansible-galaxy collection install reads BOTMETA | |
| 16:39:55 | pabelanger | because, today it doesn't | |
| 16:39:56 | sshnaidm | or we'll be stuck forever with the old names :) | |
| 16:40:00 | mordred | pabelanger: it doesn't | |
| 16:40:05 | pabelanger | okay | |
| 16:40:08 | mordred | this have nothing to do with ansible-galaxy | |
| 16:40:19 | mordred | this is something that is a build-time facility for ansible itself | |
| 16:40:38 | pabelanger | okay, standing by | |