| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-12-12 | |||
| 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 | mordred | no need to be different | |
| 16:45:39 | pabelanger | WFM | |
| 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 | pabelanger | +1 | |
| 16:46:33 | mordred | yes? | |
| 16:46:35 | dtantsur | ++ | |
| 16:46:35 | gtema | yes | |
| 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? | |
| 16:48:17 | mordred | we can write a publication job for that - or reallky just steal the ones pabelanger has already written | |
| 16:48:25 | sshnaidm | mordred, are there admins for specific collections? | |
| 16:48:29 | sshnaidm | pabelanger, gundalow ^^ | |
| 16:48:37 | mordred | odyssey4me: you can totally unit test modules | |
| 16:48:40 | pabelanger | yes, I have a job for that in zuul | |
| 16:48:47 | pabelanger | unit tests is via ansible-test | |
| 16:48:54 | mordred | yeah. it's pretty col | |
| 16:48:55 | mordred | cool | |
| 16:48:56 | odyssey4me | mordred: hooray! I'll have to look into that | |
| 16:48:59 | Shrews | the current openstacksdk tests should likely move to the new project | |
| 16:49:00 | sshnaidm | odyssey4me, yeah, there are examples in ansible repo | |
| 16:49:02 | mordred | sshnaidm: no - to my knowledge it's a namepsace level | |
| 16:49:07 | Shrews | s/tests/module tests/ | |
| 16:49:09 | mordred | Shrews: ++ | |
| 16:49:19 | pabelanger | however, I would love to build some sort of stestr ansible-playbook things, to work with any playbook | |
| 16:49:26 | odyssey4me | thanks - good to know that I have some homework to do :) | |
| 16:49:33 | sshnaidm | I've already have a patch to migrate the job to this repo | |
| 16:49:49 | sshnaidm | ok, let's move on | |
| 16:49:56 | sshnaidm | versioning and branching | |
| 16:50:10 | sshnaidm | we want to keep modules up to date, right? | |
| 16:50:15 | sshnaidm | not as they were in ansible rpeo | |
| 16:50:17 | gtema | no, what for | |
| 16:50:25 | gtema | :D | |
| 16:50:42 | mordred | I don't understand the question? | |
| 16:51:07 | sshnaidm | will we have manual releases as some openstack repos do? or it will be continuous delivery | |
| 16:51:20 | mordred | ah - that's a _great_ question | |
| 16:51:29 | sshnaidm | and should we be tied to openstack releases? | |
| 16:51:31 | mordred | no | |
| 16:51:36 | mordred | that is a for sure no | |
| 16:51:50 | odyssey4me | no tie to openstack releases IMO, and CD would be great IMO | |
| 16:51:52 | mordred | but for the other - I think the intent is for collections to be versioned with semver right? | |
| 16:51:53 | gtema | it's more likely to tie somehow to SDK version | |
| 16:52:01 | Shrews | yeah, ansible users do not want to wait for an openstack release to get a bug fix/feature | |
| 16:52:09 | mordred | yeah - a version of the collection will have a minimum sdk version | |
| 16:52:21 | mordred | but neither of those need to be tied to an openstack release | |
| 16:52:30 | pabelanger | and depend on ansible engine (stdlib / minimal) | |
| 16:52:34 | mordred | so - maybe we start with "tag releases as needed?" | |
| 16:52:38 | elmiko | dtantsur: no worries, i actually missed the start here =( | |
| 16:52:43 | sshnaidm | we won't have branches like ussuri, train, etc, right? | |
| 16:52:49 | pabelanger | mordred: I'd love to see us upload pre-release versions to galaxy | |
| 16:52:50 | mordred | that's been working pretty will for sdk | |
| 16:52:50 | dtantsur | elmiko: :) | |
| 16:52:55 | pabelanger | then tag when want to support it | |
| 16:53:13 | mordred | pabelanger: I mean - I don't know why we'd... can you give me an example of what we'd do with that use case? | |
| 16:53:15 | pabelanger | as, collections are artifacts, not git repos now | |
| 16:53:23 | pabelanger | you need to build the collection, to install | |
| 16:53:31 | sshnaidm | mordred, I'd prefer CD, but with good CI tests for it :) | |
| 16:53:33 | elmiko | dtantsur: fwiw, i say keep using this slot as long as it is useful and productive for the group =) | |
| 16:53:57 | dtantsur | elmiko: cool! I would expect some more times before we settle down on everything | |
| 16:54:02 | mordred | yeah. but like - we don't publish pre-releases of sdk to pypi - we just release all the time - so I want to make sure I understand when we'd maybe need to diverge from that? | |
| 16:54:25 | sshnaidm | mordred, all the time - how often? | |
| 16:54:33 | mordred | (also - I have no problem supporting uploading pre-releases - that's a great idea - I just want to understand when we'd choose to use that support) | |
| 16:54:33 | Shrews | when requested :) | |
| 16:54:45 | mordred | yeah- we can cut 3 sdk releases in a week if we need to | |