Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2019-12-12
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
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 gtema not me
17:00:30 sshnaidm #agreed on having manual releases as much as we need
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 mordred pabelanger: I want buildset-galaxy the instant we can have it
17:01:12 openstack Minutes (text): http://eavesdrop.openstack.org/meetings/api_sig/2019/api_sig.2019-12-12-16.00.txt
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

Earlier   Later