| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-12-12 | |||
| 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 | |
| 16:57:04 | mordred | it's been really easy to work with | |
| 16:57:21 | Shrews | sshnaidm: it is the openstack process we've agreed to as an openstack project | |
| 16:57:34 | mordred | I mostly think we shouldn't overcomplicate this until we need to | |
| 16:57:38 | Shrews | ++ | |
| 16:57:43 | gtema | +1 | |
| 16:57:52 | sshnaidm | and not overcomplicating is..? | |
| 16:58:08 | sshnaidm | manual releasing? | |
| 16:58:10 | mordred | we can cut releases whenever - that can be 20 times a week or no releases for 20 weeks - and we can just use our human judgement for a while until we can identify a flaw in that | |
| 16:58:24 | mordred | so we all have a common basis of understanding of the problem we're trying to solve | |
| 16:58:49 | mordred | we can also, similar to openstack, produce master artifacts probably | |
| 16:58:53 | sshnaidm | I'm not against releases, just trying to get the point where it helps | |
| 16:58:56 | mordred | for people who do want to consume CD | |
| 16:59:39 | pabelanger | yes, building the collection isn't difficult | |
| 16:59:55 | mordred | sshnaidm: I'm not sure it helps or hurts - it's just that to actually release semver versioned artifacts on every commit would involve inventing a bunch of new automation and I don't know that effort on that is worth it | |
| 17:00:08 | sshnaidm | ok, so anybody objects to manual releases and want CD only? | |
| 17:00:30 | sshnaidm | #agreed on having manual releases as much as we need | |
| 17:00:30 | gtema | not me | |
| 17:00:40 | dtantsur | sounds good | |
| 17:00:41 | sshnaidm | well, we're out of time | |
| 17:00:46 | dtantsur | yay, thanks all! | |
| 17:00:49 | mordred | woot! | |
| 17:00:51 | pabelanger | mordred: I can share what we are doing in network, atleast as a discussion point. But is also a step towards buildset-galaxy too, not sure if there is interest in that right now | |
| 17:01:08 | sshnaidm | #endmeeting | |
| 17:01:10 | openstack | Meeting ended Thu Dec 12 17:01:07 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 17:01:11 | openstack | Minutes: http://eavesdrop.openstack.org/meetings/api_sig/2019/api_sig.2019-12-12-16.00.html | |
| 17:01:12 | openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/api_sig/2019/api_sig.2019-12-12-16.00.txt | |
| 17:01:12 | mordred | pabelanger: I want buildset-galaxy the instant we can have it | |
| 17:01:13 | openstack | Log: http://eavesdrop.openstack.org/meetings/api_sig/2019/api_sig.2019-12-12-16.00.log.html | |
| 17:01:24 | mordred | :) | |
| 17:01:42 | gtema | dtantsur, can I sleep now? | |
| 17:02:21 | dtantsur | gtema: I shall permit that | |
| 17:02:29 | sshnaidm | mordred, I think I'll get my CI job patch on top of yours with modules | |
| 17:02:32 | gtema | thks | |
| 17:02:55 | sshnaidm | mordred, to have it ready for running basic tests for them | |
| 17:03:23 | pabelanger | sshnaidm: how do you plan to run unit tests? | |
| 17:03:39 | sshnaidm | pabelanger, we don't have these afaik | |
| 17:03:44 | sshnaidm | pabelanger, with tox? | |
| 17:03:53 | pabelanger | sshnaidm: this is unit tests? | |
| 17:04:12 | sshnaidm | pabelanger, we have a job that runs functional tests and was running on ansible patches before | |
| 17:04:29 | sshnaidm | pabelanger, I convert it to run on sig repo now | |
| 17:04:30 | pabelanger | yah, that is devstack right? | |
| 17:04:34 | sshnaidm | pabelanger, yep | |
| 17:05:03 | sshnaidm | pabelanger, I didn't see unittests, lemme check in ansible repo.. | |
| 17:05:13 | pabelanger | k, so should be able to just build collection and install, and ansible dev find it | |
| 17:05:21 | pabelanger | using ansible-galaxy | |
| 17:05:32 | Shrews | there were no unit tests, only functional tests | |
| 17:05:48 | Shrews | i wouldn't even know how to unit test an ansible module | |
| 17:06:08 | pabelanger | yah, it is a little messy IMO | |
| 17:07:05 | sshnaidm | yeah, no unit tests | |
| 17:07:21 | sshnaidm | there is a guide in ansible docs | |
| 17:07:23 | Shrews | and the current functional tests are woefully inadequate and hopefully will be improved uon | |
| 17:07:25 | Shrews | upon | |
| 17:07:39 | sshnaidm | https://docs.ansible.com/ansible/latest/dev_guide/testing_units_modules.html | |
| 17:07:52 | sshnaidm | didn't try it yet | |
| 17:08:01 | Shrews | yeah, i know it's possible, i've never had interest to learn how though | |
| 17:08:17 | gtema | mordred: what can you say about https://review.opendev.org/#/c/650374/15/openstackclient/image/v2/image.py@127 | |
| 17:08:23 | pabelanger | no, I wouldn't use ansible-test for unit tests. I would much rather do something like stestr for it | |
| 17:08:37 | pabelanger | ansible-test is very opionioned in that case | |
| 17:09:03 | sshnaidm | pabelanger, is it usable for something? | |
| 17:09:08 | sshnaidm | ansible-test I mean | |
| 17:09:19 | sshnaidm | it has a lot of sanity checks I saw | |
| 17:09:23 | pabelanger | we use it for integration testing, in network | |
| 17:09:28 | pabelanger | it works, but is also slow in some cases | |
| 17:09:42 | sshnaidm | pabelanger, can you drop a link please? | |
| 17:09:47 | pabelanger | but not for unit tests for sanity | |
| 17:10:04 | sshnaidm | I'm curios if we can use molecule for tests | |
| 17:10:45 | mordred | Shrews, sshnaidm, pabelanger: perhaps once we're structured a bit more like this: https://review.opendev.org/#/c/698044/ it'll be easier to write "normal" unit tests? | |
| 17:10:50 | pabelanger | molecule uses pytest | |
| 17:11:20 | mordred | or maybe it won't be - who know | |
| 17:11:23 | mordred | knows | |
| 17:11:48 | pabelanger | sshnaidm: https://dashboard.zuul.ansible.com/t/ansible/build/6060fe2d015a4b718f1ab81f59a97a4f is a integration test for network and collections | |
| 17:11:57 | pabelanger | https://github.com/ansible-network/ansible_collections.arista.eos/pull/50 | |
| 17:12:27 | pabelanger | basically, we have a parent job for build-ansible-collection, which creates the artifacts and passed is back into swift (soon galaxy) | |
| 17:12:41 | pabelanger | then ansible-test jobs, fetch collections and ansible-galaxy collection install it | |
| 17:12:45 | pabelanger | to then run ansible-test | |
| 17:12:47 | sshnaidm | mordred, yeah, need to try.. | |
| 17:13:23 | mordred | https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/test-upload-logs-swift/library/test_zuul_swift_upload.py | |
| 17:13:27 | pabelanger | I'm not sure I'd try to use molecule... personally, I haven't see much work on ansible side to update it for collections | |
| 17:13:30 | mordred | that's how we unittest modules in zuul-jobs | |
| 17:14:02 | mordred | pabelanger: yah - also molecule seems a bit focused on being able to make test envs for you and stuff- I don't know that it's a great fit here | |
| 17:14:09 | pabelanger | mordred: yah, it would be great to some how loop that into a test runner, for both zuul and local | |
| 17:14:22 | mordred | pabelanger: I think we can do that pretty easily | |
| 17:14:31 | pabelanger | +1 | |
| 17:14:39 | mordred | if you run stestr in zuul-jobs it'll run those unit tests | |
| 17:14:51 | pabelanger | oh, today? | |
| 17:14:53 | pabelanger | nice | |
| 17:14:57 | pabelanger | that is what I want to do for network | |
| 17:15:04 | mordred | yeah | |
| 17:15:17 | mordred | it'll need to be slightly adapter - but it should be mostly cargo-cultable | |
| 17:15:23 | pabelanger | then, even add support for ansible-playbook and inventory file, like we did with zuul functional testing | |
| 17:15:29 | mordred | tests/test_discovery.py is what drives finding the tests to run | |
| 17:15:33 | mordred | ++ | |