| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-12-12 | |||
| 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 | |
| 16:54:59 | sshnaidm | it's almost CD :) | |
| 16:55:04 | mordred | :) | |
| 16:55:05 | sshnaidm | what is the advantage? | |
| 16:55:05 | gtema | we can do daily, aren't we? | |
| 16:55:15 | sshnaidm | then why not every patch | |
| 16:55:21 | mordred | because we have to tag to make a release | |
| 16:55:26 | pabelanger | for me, if I want to use the latest master version of openstack.api, that has to come from galaxy now, not git. Otherwise, there needs to be some process to first build the colleciton to install | |
| 16:55:27 | mordred | and that goes through openstack-release | |
| 16:55:30 | elmiko | dtantsur: yeah, it's all good. the sig office hour is slow, so i think the multiplexing is fine ;) | |
| 16:55:43 | odyssey4me | we could just do a release release whenever there's a change which doesn't match an exception list (docs, tests, etc) - we could then somehow automate whether the increment is major, minor of patch | |
| 16:55:48 | sshnaidm | mordred, I'm just curios if it has some advantages over CD | |
| 16:55:58 | mordred | pabelanger: sure ... I guess what I'm sayuing is - why woudln't we just cut a real release? | |
| 16:56:27 | Shrews | sshnaidm: we have to submit a separate review to release a new version. not quite CD | |
| 16:56:35 | pabelanger | mordred: Yup, that works too. A pre-release just avoids the need for asking | |
| 16:56:45 | mordred | yeah. and some people don't want actual constant upgrades | |
| 16:56:48 | sshnaidm | Shrews, it seems like more maintenance | |
| 16:56:52 | mordred | so we try to just use judgement | |
| 16:56:59 | mordred | it's not a burden on us sdk side | |
| 16:57:03 | pabelanger | odyssey4me: https://github.com/ansible-network/releases/blob/master/ansible_releases/cmd/generate_ansible_collection.py, how we do it today for network | |