| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-12-12 | |||
| 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 | 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:02 | pabelanger | without botmeta.yml | |
| 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 | |
| 16:40:39 | mordred | so when they buikld the wheel for ansible - the build script will grab the collections, suck them in and make symlinks | |
| 16:40:44 | mordred | AIUI | |
| 16:41:00 | pabelanger | right, however people can do ansible-galaxy collection install out side of meta ansible package | |
| 16:41:06 | mordred | sure | |
| 16:41:17 | sshnaidm | I suggest we'll continue in ML about renaming, we're past half meeting | |
| 16:41:20 | pabelanger | in that install case, renames would break playbooks today | |
| 16:41:32 | mordred | ok. let's take this as an action | |
| 16:41:43 | gtema | let's make for safety own links inside of collection | |
| 16:41:48 | sshnaidm | #action sshnaidm to write ML to discuss renaming | |
| 16:41:50 | mordred | I'll cirlce up with gundalow and get to the point where I *completely* understand what the intent is | |
| 16:42:06 | sshnaidm | we have now openstack namespace hosted by mordred | |
| 16:42:14 | mordred | and then write up a summary for us as it relates to us, yeah? | |
| 16:42:17 | sshnaidm | do we want to put all modules in one collection? | |
| 16:42:18 | pabelanger | +1 | |
| 16:42:21 | mordred | yes | |
| 16:42:23 | pabelanger | yes | |
| 16:42:27 | gtema | yes | |
| 16:42:40 | sshnaidm | what would it be? openstack.cloud ? | |
| 16:42:50 | dtantsur | bikeshedding \o/ finally! | |
| 16:42:50 | gtema | weird | |
| 16:42:53 | sshnaidm | and then openstack.cloud.os_server etc | |
| 16:43:03 | mordred | that's a good option. when we did the .well-known support we picked openstack.api | |
| 16:43:04 | dtantsur | I don't dislike openstack.cloud | |
| 16:43:34 | sshnaidm | openstack.api.os_server..? | |
| 16:43:36 | gtema | pabelanger: what is the name for networking? | |
| 16:43:47 | sshnaidm | openstack.ansible ? | |
| 16:43:54 | sshnaidm | I have a lot of ideas :D | |
| 16:44:00 | mordred | I like both cloud and api - I do not like ansible :) | |
| 16:44:10 | dtantsur | same | |
| 16:44:27 | sshnaidm | api sounds weird for me | |
| 16:44:28 | mordred | but - let's make a quick distinction on something | |
| 16:44:31 | pabelanger | gtema: we don't have a meta collection, so we have things like cisco.ios / cisco.iosxr / junpernetwork.junos | |
| 16:44:38 | gtema | ah, ok | |
| 16:44:41 | pabelanger | I am trying to see what aws and google did | |
| 16:44:47 | pabelanger | they might be cloud.google and cloud.aws | |
| 16:44:54 | mordred | no _ I think it's google.cloud | |
| 16:44:56 | sshnaidm | aha | |
| 16:45:02 | mordred | (other way - they have namespaces?) | |
| 16:45:13 | pabelanger | yes, google.cloud | |
| 16:45:18 | pabelanger | https://github.com/ansible-collections/ansible_collections_google/blob/master/galaxy.yml | |
| 16:45:22 | mordred | so let's just do openstackcloud | |
| 16:45:25 | mordred | so let's just do openstack.cloud | |
| 16:45:27 | mordred | yeah? | |
| 16:45:36 | sshnaidm | +1 | |
| 16:45:37 | gtema | ok for me | |
| 16:45:39 | pabelanger | WFM | |
| 16:45:39 | mordred | no need to be different | |
| 16:45:49 | mordred | so - earlier the question was "do we put all of the modules in one collection" | |
| 16:45:58 | gtema | yes | |
| 16:46:03 | mordred | I think the answer is "yes" - as long as we're talking about modules that interact with teh openstack api | |
| 16:46:11 | sshnaidm | #agreed to have one collection as openstack.cloud | |
| 16:46:20 | sshnaidm | ok? ^ | |
| 16:46:22 | mordred | if there is, say, an openstack-ansible or tripleo module that does things like manipulates nova databases or somethingm | |
| 16:46:29 | mordred | then I think that can go into a different collection | |
| 16:46:33 | mordred | yes? | |
| 16:46:33 | pabelanger | +1 | |
| 16:46:35 | gtema | yes | |
| 16:46:35 | dtantsur | ++ | |
| 16:46:39 | sshnaidm | cool | |
| 16:46:52 | sshnaidm | admins to namespace | |
| 16:46:54 | mordred | (in fact, I would expect us to be able to have collections for tripleo/openstack-ansible roles and plugins and stuff) | |
| 16:47:13 | gtema | yes | |
| 16:47:34 | sshnaidm | do we need admins? should it be a zuul? | |
| 16:47:45 | mordred | for the namespace - currently it's tied in to auth things in such a way that it's likelky easiest if it's just infra/zuul who are admins and we just publish through jobs | |
| 16:47:55 | sshnaidm | zuul needs to post updated code to collection afaiu | |
| 16:48:00 | mordred | we'll need to figure that out long term - but it's complicated at the moment, so that would be my suggestion for now :) | |
| 16:48:04 | mordred | yah | |
| 16:48:15 | odyssey4me | As an aside - and excuse my ignorance - but is it possible to unit test modules at all, or are we stuck with only functional tests? | |