16:00:48 <dtantsur> #startmeeting api-sig
16:00:49 <openstack> Meeting started Thu Dec 12 16:00:48 2019 UTC and is due to finish in 60 minutes.  The chair is dtantsur. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:50 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:53 <openstack> The meeting name has been set to 'api_sig'
16:00:59 <dtantsur> #chair sshnaidm elmiko
16:01:00 <openstack> Current chairs: dtantsur elmiko sshnaidm
16:01:05 <sshnaidm> dtantsur, thanks!
16:01:15 <sshnaidm> o/
16:01:26 <dtantsur> #link https://etherpad.openstack.org/p/openstack-ansible-modules agenda
16:01:38 <dtantsur> anyone else here? :)
16:01:42 <gtema> me
16:02:53 <dtantsur> a nice private party :)
16:02:57 <gtema> sure
16:03:00 <gtema> as usual
16:03:06 <sshnaidm> mnaser, mordred, odyssey4me
16:03:11 <gtema> last week was weird - too much people :D
16:03:18 <sshnaidm> just calling people from etherpad :)
16:03:21 <odyssey4me> o/
16:03:27 <sshnaidm> holidays I assume
16:03:37 * odyssey4me is in two meetings, but will try to participate
16:03:51 <gtema> it's tooooooo early for holidays, who will do the work
16:04:03 <sshnaidm> so I've sent a mail to legal-discussion: http://lists.openstack.org/pipermail/legal-discuss/2019-December/thread.html
16:04:15 <sshnaidm> it's the only thread there
16:04:48 <sshnaidm> got responses that we'd better to keep developing in ansible sig repo under GPL
16:05:41 <sshnaidm> any other opinions about that? ^
16:05:45 <odyssey4me> hmm, is that an OK thing for openstack repositories?
16:05:50 <mordred> ohai!
16:06:05 <gtema> well, reading inside I would say there are no answers (mordred doesn't count)
16:06:10 <sshnaidm> odyssey4me, well, it's not really openstack repository
16:06:38 <sshnaidm> gtema, yeah, responses were from people of this meeting actually :)
16:07:10 <mordred> yeah - although while I don't count - the takeaway I've gotten from past encounters is that as along as it's not part of "the software" called openstack, it's ok
16:07:10 <dtantsur> it seems that we can host GPL code, just not make it official openstack delivarables
16:07:18 <mordred> yah
16:07:26 <odyssey4me> is that a problem?
16:07:39 <sshnaidm> I'd like to know what it blocks for us
16:07:42 <mordred> nope. should be fine. this is an effort of a sig
16:08:00 <mordred> I don't thnk it's blocks anything. ansible is already GPL
16:08:00 <dtantsur> nothing blocking. just a bit unfortunate that we cannot proudly call these modules official
16:08:03 <sshnaidm> what is consequences of not having this as deliverable?
16:08:13 <odyssey4me> we have imports both ways, right - the module imports ansible (GPL) stuff, and also imports openstack (Apache) stuff
16:08:15 <mordred> so anything that would use these modules must by definition be ok consuming gpl software
16:08:22 <dtantsur> sshnaidm: no promotion on openstack.org?
16:08:38 <mordred> I don't think it's a matter of not being able to call these modules official
16:08:49 <dtantsur> one things that I think is important re licensing:
16:08:50 <sshnaidm> mordred, this won't change anyway, we don't relicense them
16:08:51 <mordred> it's that they can't be part of an OpenStack release
16:09:01 <mordred> which they wouldn't be anyway, since that makes no sense
16:09:05 <dtantsur> if we write something that looks like logic independent of ansible, we should better put it somewhere else
16:09:16 <dtantsur> otherwise we won't be able to easily reuse it in other parts of openstack
16:09:17 <mordred> dtantsur: right. and that's stuff we tend to put in sdk
16:09:22 <dtantsur> e.g. it will be troublesome to put it to sdk
16:09:23 <dtantsur> exactly
16:09:31 <pabelanger> right, this should be the ansible community openstack collection
16:09:34 <dtantsur> last time I proposed that any logic goes to sdk
16:09:35 <mordred> (which is one of the reasons we have sdk and are so adamant about butting things in there)
16:09:40 <mordred> ++
16:09:54 <odyssey4me> yep, the thinner the module is as a layer - the better
16:09:55 <mordred> the modules should be thin glue code between the ansible module structure and logic entities in sdk
16:09:59 <odyssey4me> *modules
16:10:02 <mordred> this will be easier to accomplish with the modules in gerrit now
16:10:12 <dtantsur> #agreed Try to put most of the logic into openstacksdk, keep the ansible modules as thin glue
16:10:19 <dtantsur> right?
16:10:20 <sshnaidm> having lite modules with sdk logic is totally fine for me too, but here comes question of compatibility between versions
16:10:23 <mordred> yah
16:10:37 <mordred> the sdk supports all versions of openstack
16:10:43 <mordred> so that direction is fine
16:10:43 <dtantsur> sshnaidm: any logic code is anyway tied to openstack, not to ansible
16:11:10 <sshnaidm> dtantsur, right, agree
16:11:17 <Shrews> yes, there is no reason to not continue that abstraction/separation. also, hi!
16:11:20 <mordred> the version support matrix is then for different versions of ansible - maybe something changes in newer versions of ansible and we need to update the module interface for that
16:11:34 <dtantsur> wow, I wild Shrews appears :)
16:11:39 <dtantsur> * a wild
16:11:41 <dtantsur> (sigh)
16:11:45 <Shrews> i'm tame now
16:11:45 * mordred hands Shrews a bunny
16:11:58 <gtema> atm collection does not define dependency to Ansible (requires version)
16:12:16 <gtema> so assume this should not happen in near future
16:12:29 <dtantsur> gundalow: ^^^?
16:12:32 <mordred> yah. so hopefully we can have our modules support all extant versions of ansible too
16:12:40 <sshnaidm> I hope won't happen at all
16:12:45 <mordred> (even if the modules have to have some if logic in them to do so)
16:12:55 <mordred> but the module interface has been *VERY* stable for the past several years
16:13:06 <odyssey4me> I guess we're going to have to limit the collection version support for Ansible. Ansible does tend to make pretty heavy changes from time to time.
16:13:07 <gtema> don't kill me: should we introduce support for microversions in Ansible?
16:13:10 <mordred> the only main systemic changes have been around things like docstsring formats
16:13:11 <dtantsur> #agreed Try to support as many versions of ansible as possible with the same code
16:13:20 * dtantsur throws a lot of wet cats at gtema
16:13:22 <mordred> gtema: no
16:13:34 <mordred> all microversion support should be in the sdk
16:13:41 <gtema> it was a joke, but with small sense of truth
16:13:45 <mordred> heh
16:13:48 <sshnaidm> so, back to hosting modules - do we completely freeze existing and start new ones? Remember that people will use them from 2.10 from our repo
16:13:49 * mordred throws wet cat at gtema
16:14:00 <mordred> I *strongly* oppose starting new modules
16:14:07 <gtema> i mean if someone would like to get info about smth, what is reported only with microversion set
16:14:08 <dtantsur> mmm?
16:14:15 <Shrews> why would we *want* new ones?
16:14:17 <dtantsur> mordred: would you rather prefer a breaking change?
16:14:23 <sshnaidm> mordred, we'll need to rename them at least
16:14:26 <dtantsur> Shrews: we need 1) rename some modules, 2) fix auth in some
16:14:37 <sshnaidm> and people use them in their playbooks
16:14:38 <pabelanger> one thought I had with collection version, since it is semver. Is have 1.0.0,<2.0.0 support ansible 2.10.0 (stable-2.10), then 2.0.0,<3.0.0 support ansible 2.11.0 (stable-2.11)
16:14:45 <pabelanger> etc
16:15:02 <mordred> I think that's potentially unnecessary and hard
16:15:12 <mordred> many of these modules have been unchanged from ansible 2.0
16:15:15 <dtantsur> it depends on how different 2.11 will be from 2.10
16:15:23 <mordred> ansible itself does _not_ change that much as it relates to the module interface
16:15:24 <sshnaidm> mordred, I think current names and code should be re-thought at least
16:15:38 <odyssey4me> hmm, ok - is the scope of the collection *just* modules/libraries?
16:15:44 <dtantsur> I recall auth being mess in ironic modules (maybe all really)
16:15:46 <openstackgerrit> Andrew Karpow proposed openstack/python-openstackclient master: Use network service for Server AddFixedIP  https://review.opendev.org/698749
16:16:03 <mordred> odyssey4me: the scope of _this_ collection, yes
16:16:21 <gtema> let's talk about collection name
16:16:21 <dtantsur> what else can we have?
16:16:22 <mordred> I think this sig can have additional collections published to galaxy that contain roles and stuff
16:16:22 <odyssey4me> mordred: ok, sounds sensible - we should probbaly document that somewhere
16:16:35 <Shrews> what is the proposed new module naming structure? and why doesn't the current one work?
16:16:41 <mordred> but this, for now, is about moving the os_ modules from ansible/ansible and into a collection
16:16:55 <dtantsur> Shrews: at least s/os_ironic/baremetal/
16:16:56 <gtema> Shrews: os_ prefix is unnecessary
16:17:00 <dtantsur> actually, drop os_?
16:17:00 <mordred> Shrews: 2 potential naming things ... yeah
16:17:02 <pabelanger> is there no plugins that need to move?
16:17:07 <pabelanger> dtantsur: plese no
16:17:12 <pabelanger> that will break playbooks
16:17:16 <mordred> os_ prefix - and the service-type in the module names for "admin" modules
16:17:17 <sshnaidm> I'd leave existing with deprecation notice and start from copying and reworking them
16:17:21 <dtantsur> pabelanger: that's why we're talking about new modules
16:17:29 <mordred> but - pabelanger makes a good point WRT naming
16:17:32 <dtantsur> leave os_ironic whatever it is, develop baremetal properly
16:17:39 <mordred> this is a thing I'd like to really get a real answer on though
16:17:41 <sshnaidm> pabelanger, yeah, I wouldn't touch them at all
16:18:10 * gundalow waves
16:18:13 <sshnaidm> mordred, working on old modules doesn't give us any freedom and will most likely break existing playbooks
16:18:16 <mordred> gundalow mentioned a magical thing that would allow someone to install ansible + a set of collections to get symlinks for the old modules for compat
16:18:20 <gtema> wrt playbook change, I was still not able to get answer in Ansible
16:18:33 <mordred> if that exists, and doesn't have support for module-level symlinks, then I think renaming is very mean
16:18:35 <pabelanger> I would recommend everybody look at https://github.com/ansible-community/collection_migration, that is the tooling being written today to migrate content out of ansible/ansible to collections. So far, that has some large assumptions
16:18:43 <gtema> so for the moment it is not known, whether it is possible at all
16:18:43 <mordred> if it doesn't exist - we should rename because everyone is going to be broken anyway
16:19:04 <mordred> if it does exist AND we can provide a mapping of fully qualified names to old names, then we should rename
16:19:14 <pabelanger> gtema: which answer?
16:19:26 <mordred> I think we need an answer on what the omnibus installer looks like before we commit one way or the other to renaming anything
16:19:29 <sshnaidm> #link  https://github.com/ansible-community/collection_migration
16:19:30 <gtema> exaclty, whether it is possible to leave playbooks unaffected
16:19:37 <gtema> without introducing FQCN
16:19:39 <mordred> yah
16:19:41 <pabelanger> gtema: yes, that is possible
16:19:47 <gtema> how?
16:20:06 <pabelanger> collection loader supports relative imports
16:20:20 <mordred> can you say more words about that?
16:20:35 <pabelanger> so both cisco.ios.ios_config and ios_config are valid tasks in playbooks using collections
16:20:46 <sshnaidm> I think gundalow told about this previous time, it works like imports in python
16:20:48 <mordred> pabelanger: I thought you had to add an import statement to your playbook for that to work
16:20:48 <gundalow> mordred: there will be a  "Ansible Community Distribution" (bikeshed) which will install Ansible + the collections that hold the content that was in Ansible 2.9.
16:20:49 <pabelanger> if collection is cisco.ios
16:20:57 <gundalow> sshnaidm: correct
16:20:57 <gtema> not really, in the 2nd case you introduce import at the beginning of playbook
16:21:01 <mordred> pabelanger: right - but you have to add a collection reference into the playbook
16:21:05 <sshnaidm> mordred, when using symlink you shouldn't
16:21:10 <mordred> hang on
16:21:10 <pabelanger> mordred: no, not any more
16:21:13 <mordred> two different things
16:21:15 <mordred> ok.
16:21:25 <pabelanger> from playbooks, what I said is fine
16:21:32 <gundalow> If you are using ACD you may not need to explicitly import anything that ships in ACD, it's done automagically for you
16:21:39 <pabelanger> for module_utils, you should use fqcn (fully qualify collection name)
16:21:46 <mordred> gundalow: what's ACD?
16:22:02 <gundalow> sorry, Ansible Community Distribution
16:22:12 <mordred> is that what I get when I do "pip install ansible" ?
16:22:14 <dtantsur> do we expect a lot of people to use it?
16:22:22 <dtantsur> yeah, same question (dnf install ansible, etc)
16:22:33 <pabelanger> mordred: magic installer doesn't exist today
16:22:39 <mordred> ok. I won't be using that
16:22:40 <gtema> brew install ansible?
16:22:42 <pabelanger> so, pip install ansible / ansible-galaxy collection install foo
16:22:50 <gundalow> In an ideal word, yes, `$package_mgr install ansible` will give you ACD
16:23:09 <dtantsur> and in ours? :)
16:23:13 <mordred> gundalow: does $package_mgr include pip? (sorry to be pedantic here- just trying to make sure I understand everything)
16:23:16 <gundalow> dtantsur++
16:23:27 <gundalow> mordred: yup including pip
16:23:30 <mordred> cool
16:23:48 <mordred> gundalow: so - the magic there is done via symlinks from the botmeta file we discussed the other day right?
16:23:51 <gtema> I still do not really believe in a perfect world
16:24:12 <gundalow> Given one of the high level requirements is "don't break people" I'd really hope we can get `pip install ansible` to give you ansible + all the modules
16:24:17 <mordred> gundalow: do we know if we'll be able to specifiy in that botmeta file mappings on a per-module basis?
16:24:34 <gtema> when we release first collection we need to insure our func tests from SDK are using really collection
16:24:45 <gundalow> mordred: yes, BOTMETA supports per file, there are examples, it's just that generally we logically group by directory
16:24:48 <mordred> gtema: we should probably test both ways
16:24:56 <mordred> gundalow: cool.
16:25:04 <mordred> so - let's assume a perfect world for a sec ...
16:25:11 <pabelanger> gtema: mordred: yes, testing both is safest, that is what ansible network does now
16:25:17 * gtema falls asleep
16:25:32 <mordred> if the botmeta thing works per file and if it exists and does the symlinks and works for pip nad dnf and friends ...
16:25:36 <dtantsur> gtema: just half past 5, c'mon!
16:25:42 <mordred> then it should be safe to rename the modules in the collection
16:25:48 <sshnaidm> ok, so back to the original question, should we keep old modules fully functional as before for not breaking current users?
16:25:50 <mordred> because we can do a name mapping in botmeta
16:25:51 <gtema> sure we need to test both, but exactly here we need to "rely" on assumption it works both ways without modifying playbook
16:25:58 <mordred> people getting the modules through symlinks will not be affected
16:26:03 <dtantsur> mordred: assuming our auth changes won't end up breaking?
16:26:08 <mordred> and people using collection explicitly will use colledction paths
16:26:15 <dtantsur> (and assuming we won't need other per-module breaking changes)
16:26:27 <mordred> dtantsur: well - it's sounding like there's less implicit breaking than we thought before
16:26:33 <gtema> let's do all breaking as new modules
16:26:43 <gtema> with a fresh design
16:26:44 <mordred> so maybe we should figure out what we want to do with auth and see if we can figure out a way to do it non-breaking
16:26:47 <dtantsur> gtema: the question was whether we need new modules
16:26:59 <gtema> sure we need
16:27:02 <mordred> gtema: I don't want two different designs - we don't have enough people working on this to support that :)
16:27:11 <pabelanger> +1
16:27:12 <mordred> we *barely* have enough people to keep the ones we have going
16:27:20 <gtema> we currently do not have possibility to manage tags, and I do not really want to modify each module with tagging mess
16:27:27 <dtantsur> at the very least we need to think how to support all session AND adapter options
16:27:32 <dtantsur> I think we don't do it now
16:27:32 <mordred> yes
16:27:39 * Shrews recalls a recent twitter thread on the pitfalls of rewriting s/w from scratch
16:27:41 <mordred> well - we assume for complex options you'll use clouds.yaml
16:28:01 <mordred> dtantsur: and you can pass a full clouds.yaml yaml snippet to the cloud parameter of the module too
16:28:02 <sshnaidm> there are some modules like ironic_node that should be redesigned at all
16:28:18 <dtantsur> I'm talking simple: {auth_type: none, endpoint_override: https://bare.metal}
16:28:23 <mordred> that said- if we NEED to redesign a module and deprecate the old one - we should totally do that
16:28:31 <mordred> dtantsur: that should work by passing to cloud:
16:28:46 <dtantsur> mordred: in cloud.yaml - yes (well.. maybe)
16:28:51 <mordred> no - in the module
16:29:04 <mordred> you can pass _anything_ to cloud: that you can put in a clouds.yaml cloud entry
16:29:27 <sshnaidm> mordred, I'm afraid changes in openstack.py may require redesign in most of modules..
16:29:28 <dtantsur> I remember I had some problem. I need to check.
16:29:41 <mordred> sshnaidm: they might - and we might need to do some things
16:30:00 <mordred> I think what I'm saying is that it sounds like ansible/ansible is providing mechanisms to make this not an inhernet breaking change
16:30:08 <mordred> so our ground cover for making additional breaking changes is lower
16:30:17 <mordred> so we should at least TRY to not immediately make breaking changes
16:30:29 <sshnaidm> mordred, deprecating old modules gives you more freedom to break things, then trying to keep backward compatibility
16:30:29 <mordred> we might find something that needs to be changed and we can't figure out non-breaking
16:30:36 <mordred> and we'll just need to figure out how to not screw our users
16:30:42 <pabelanger> yes, please for users, don't break things out of gate :)
16:30:46 <mordred> sshnaidm: it does. but right now we're just supposing
16:30:53 <mordred> we don't have an actual thing that must be done that must be breakingm
16:31:14 <mordred> I agree - we can deprecate, we can copy/modiify - do lots of things
16:31:16 <mordred> let's just do those
16:31:34 <mordred> and not immediately jump to "upstream is breaking everyone anyway so we're safe"
16:31:49 <gtema> ok for me
16:31:51 <mordred> in fact ... OOH
16:31:57 <pabelanger> +100
16:32:12 <mordred> no - neverind- I thought I had a new idea
16:32:14 <mordred> :)
16:32:29 <sshnaidm> ok, so what are we agreed on currently? :)
16:32:40 <mordred> that everyone here is awesome :)
16:32:43 <gtema> not to break immediately
16:32:48 <odyssey4me> I expect we'll be wanting to deprecate the dynamic inventory, given that the plugin interface is better anyway?
16:32:51 <sshnaidm> we continue to develop modules with old names and trying not to break current users?
16:32:58 <sshnaidm> mordred, ^^ ?
16:33:11 <mordred> odyssey4me: that's already dprecated? people should be using the plugin and not the script already
16:33:25 <mordred> sshnaidm: I think ansible/ansible has a solution for name mapping
16:33:33 <gtema> sshnaidm not to break != continue with old names for new things
16:33:41 <odyssey4me> mordred: one would hope - I guess we could then remove it from ansible/ansible and not put it into the collection
16:33:41 <mordred> so I think we *can* rename
16:33:50 <mordred> we just have to put the name mapping into botmeta in ansible/ansible
16:34:08 <sshnaidm> it's akward to have same modules with different names, either I don't understand something..
16:34:16 <mordred> odyssey4me: you raise a good question ... can the inventory _plugin_ go into the collection too?
16:34:22 <pabelanger> yes
16:34:28 <mordred> sshnaidm: let me try to explain from scratch with an example
16:34:30 <sshnaidm> mordred, can you bring an example of rename?
16:34:33 <mordred> let's take os_server
16:34:36 <gtema> technically everything can go into collection
16:34:54 <pabelanger> gtema: yup!
16:35:01 <mordred> we put os_server into our collection, let's call it openstack.api for now (we need to bikeshed on that - but roll with it for a sec)
16:35:31 <mordred> so then the canonical name of the module ios openstack.api.os_server
16:35:46 <pabelanger> yes
16:35:53 <mordred> now - in the ansible/ansible repo there is a yaml file, BOTMETA.yml - and in it we put in an entry like:
16:36:00 <mordred> openstack.api.os_server: os_server
16:36:34 <mordred> this will cause ansible, when it builds its distros for pip and whatnot to grab the collection and make a symlink from os_server to openstack.api.os_server
16:36:45 <mordred> so people who aren't paying attention will have no changes happen to that
16:36:48 <sshnaidm> yeah, but where is the rename?
16:36:52 <mordred> hang on
16:37:11 <mordred> since that is the mechanism, there is then nothing stopping us from renaming the module in our collection to openstack.api.server
16:37:18 <mordred> and making the mpapping be openstack.api.server: os_server
16:37:28 <mordred> people using fully qualitied are fine
16:37:33 <mordred> people using omnibus symlinks are fine
16:37:36 <mordred> everyone is fine
16:37:54 <pabelanger> so, if I was do to ansible-galaxy collection install openstack.api I could both do openstack.api.os_server: ... and os_server: ... from playbook
16:37:57 <mordred> and eventually, in the fullness of time, maybe the synlink mapping goes away
16:38:01 <mordred> pabelanger: yah
16:38:02 <sshnaidm> mordred, that exactly what I mean, you install os_server and something new like openstack.api.server and it's the same module exactly
16:38:02 <pabelanger> without botmeta.yml
16:38:22 <mordred> pabelanger: right - but that keeps us tied to the old names
16:38:31 <mordred> botmeta lets us rename in teh collection without screwing people
16:38:33 <pabelanger> yes, agree
16:38:54 <pabelanger> so, if we did rename in collection
16:38:58 <mordred> assuming taht support exists and works - but according to gundalow it's pretty essential that it does
16:39:23 <pabelanger> actually
16:39:25 <sshnaidm> can we alert people that use os_server that it will be deprecated?
16:39:33 <sshnaidm> and not people that use openstack.api.server
16:39:50 <gtema> I guess they will need to adapt with Ansible 2.12 anyway
16:39:52 <pabelanger> okay, I need to look on our side, I am not sure how ansible-galaxy collection install reads BOTMETA
16:39:55 <pabelanger> because, today it doesn't
16:39:56 <sshnaidm> or we'll be stuck forever with the old names :)
16:40:00 <mordred> pabelanger: it doesn't
16:40:05 <pabelanger> okay
16:40:08 <mordred> this have nothing to do with ansible-galaxy
16:40:19 <mordred> this is something that is a  build-time facility for ansible itself
16:40:38 <pabelanger> okay, standing by
16:40:39 <mordred> so when they buikld the wheel for ansible - the build script will grab the collections, suck them in and make symlinks
16:40:44 <mordred> AIUI
16:41:00 <pabelanger> right, however people can do ansible-galaxy collection install out side of meta ansible package
16:41:06 <mordred> sure
16:41:17 <sshnaidm> I suggest we'll continue in ML about renaming, we're past half meeting
16:41:20 <pabelanger> in that install case, renames would break playbooks today
16:41:32 <mordred> ok. let's take this as an action
16:41:43 <gtema> let's make for safety own links inside of collection
16:41:48 <sshnaidm> #action sshnaidm to write ML to discuss renaming
16:41:50 <mordred> I'll cirlce up with gundalow and get to the point where I *completely* understand what the intent is
16:42:06 <sshnaidm> we have now openstack namespace hosted by mordred
16:42:14 <mordred> and then write up a summary for us as it relates to us, yeah?
16:42:17 <sshnaidm> do we want to put all modules in one collection?
16:42:18 <pabelanger> +1
16:42:21 <mordred> yes
16:42:23 <pabelanger> yes
16:42:27 <gtema> yes
16:42:40 <sshnaidm> what would it be? openstack.cloud ?
16:42:50 <dtantsur> bikeshedding \o/ finally!
16:42:50 <gtema> weird
16:42:53 <sshnaidm> and then openstack.cloud.os_server etc
16:43:03 <mordred> that's a good option. when we did the .well-known support we picked openstack.api
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 <pabelanger> WFM
16:45:39 <mordred> no need to be different
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 <mordred> yes?
16:46:33 <pabelanger> +1
16:46:35 <gtema> yes
16:46:35 <dtantsur> ++
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 <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:07 <sshnaidm> #endmeeting