Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2019-12-12
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 dtantsur elmiko: :)
16:52:50 mordred that's been working pretty will for sdk
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 Shrews when requested :)
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: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 gtema we can do daily, aren't we?
16:55:05 sshnaidm what is the advantage?
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 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

Earlier   Later