Thursday, 2019-12-12

*** slaweq has joined #openstack-sdks00:03
*** slaweq has quit IRC00:08
*** senrique__ has joined #openstack-sdks00:09
*** slaweq has joined #openstack-sdks00:11
*** mriedem has quit IRC00:11
*** senrique_ has quit IRC00:12
*** jangutter has quit IRC00:13
*** jangutter has joined #openstack-sdks00:13
*** slaweq has quit IRC00:16
*** senrique__ has quit IRC00:23
*** ricolin has joined #openstack-sdks00:48
*** gtema has joined #openstack-sdks00:50
*** enriquetaso has joined #openstack-sdks00:54
*** gtema has quit IRC00:56
*** gtema has joined #openstack-sdks00:57
*** mriedem has joined #openstack-sdks01:01
*** mriedem has joined #openstack-sdks01:01
*** enriquetaso has quit IRC01:10
*** gtema has quit IRC01:11
*** gtema has joined #openstack-sdks01:17
*** gtema has quit IRC01:22
*** gtema has joined #openstack-sdks01:25
*** gtema has quit IRC01:33
*** mriedem has quit IRC01:40
*** gtema has joined #openstack-sdks01:42
*** gtema has quit IRC01:54
*** ricolin_ has joined #openstack-sdks02:05
*** ricolin has quit IRC02:07
*** iokiwi has joined #openstack-sdks02:53
*** Dinesh_Bhor has joined #openstack-sdks02:58
*** gtema has joined #openstack-sdks04:45
*** gtema has quit IRC04:49
*** gtema has joined #openstack-sdks05:26
*** gtema has quit IRC05:31
*** gtema has joined #openstack-sdks06:41
*** gtema has quit IRC06:45
*** gtema has joined #openstack-sdks06:54
*** gtema has quit IRC06:59
*** gkadam has joined #openstack-sdks07:13
*** gkadam has quit IRC07:13
*** gtema has joined #openstack-sdks07:26
*** gtema has quit IRC07:54
*** gtema has joined #openstack-sdks07:57
*** gtema_ has joined #openstack-sdks07:58
*** gtema has quit IRC08:01
*** jpena|off is now known as jpena08:01
*** jpich has joined #openstack-sdks08:14
*** slaweq has joined #openstack-sdks08:15
*** tosky has joined #openstack-sdks08:27
*** slaweq has quit IRC08:36
*** corvus has quit IRC08:40
*** ralonsoh has joined #openstack-sdks08:46
*** tonyb has quit IRC08:56
*** tonyb has joined #openstack-sdks08:56
*** slaweq has joined #openstack-sdks08:58
*** corvus has joined #openstack-sdks08:59
*** goldyfruit_ has quit IRC09:29
*** dtantsur|afk is now known as dtantsur09:52
*** gtema_ has quit IRC10:04
*** gtema has joined #openstack-sdks10:05
*** goldyfruit_ has joined #openstack-sdks10:50
*** dtantsur is now known as dtantsur|brb11:09
*** goldyfruit_ has quit IRC11:13
*** sshnaidm|afk is now known as sshnaidm11:32
*** enriquetaso has joined #openstack-sdks11:41
*** jpena is now known as jpena|lunch12:04
*** mgariepy has joined #openstack-sdks12:14
*** jpich has quit IRC12:19
*** jpich has joined #openstack-sdks12:19
*** sshnaidm has quit IRC12:37
*** sshnaidm has joined #openstack-sdks12:38
*** dtantsur|brb is now known as dtantsur12:58
*** enriquetaso has quit IRC13:01
*** enriquetaso has joined #openstack-sdks13:01
*** enriquetaso has quit IRC13:07
*** jpena|lunch is now known as jpena13:15
*** sshnaidm has quit IRC13:18
*** sshnaidm has joined #openstack-sdks13:19
*** mriedem has joined #openstack-sdks13:23
*** jangutter has quit IRC13:51
*** enriquetaso has joined #openstack-sdks13:51
*** senrique_ has joined #openstack-sdks13:54
*** enriquetaso has quit IRC13:56
*** sshnaidm has quit IRC14:04
*** jangutter has joined #openstack-sdks14:05
*** sshnaidm has joined #openstack-sdks14:49
*** ricolin_ is now known as ricolin14:57
*** lbragstad has joined #openstack-sdks15:04
*** KeithMnemonic has joined #openstack-sdks15:07
*** dtantsur is now known as dtantsur|brb15:10
*** jangutter has quit IRC15:15
*** dave-mccowan has joined #openstack-sdks15:33
*** dtantsur|brb is now known as dtantsur15:52
sshnaidmhello everyone15:59
dtantsurwe're about to hijack this slot again \o/15:59
* dtantsur wonders when elmiko starts throwing us out of the door :D15:59
sshnaidmetherpad is here:
sshnaidmplease add topic for discussions there16:00
sshnaidmdtantsur, can you run the bot please?16:00
dtantsur#startmeeting api-sig16:00
openstackMeeting 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
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.16:00
*** openstack changes topic to " (Meeting topic: api-sig)"16:00
openstackThe meeting name has been set to 'api_sig'16:00
dtantsur#chair sshnaidm elmiko16:00
openstackCurrent chairs: dtantsur elmiko sshnaidm16:01
sshnaidmdtantsur, thanks!16:01
dtantsur#link agenda16:01
dtantsuranyone else here? :)16:01
dtantsura nice private party :)16:02
gtemaas usual16:03
sshnaidmmnaser, mordred, odyssey4me16:03
gtemalast week was weird - too much people :D16:03
sshnaidmjust calling people from etherpad :)16:03
sshnaidmholidays I assume16:03
* odyssey4me is in two meetings, but will try to participate16:03
gtemait's tooooooo early for holidays, who will do the work16:03
sshnaidmso I've sent a mail to legal-discussion:
sshnaidmit's the only thread there16:04
sshnaidmgot responses that we'd better to keep developing in ansible sig repo under GPL16:04
sshnaidmany other opinions about that? ^16:05
odyssey4mehmm, is that an OK thing for openstack repositories?16:05
gtemawell, reading inside I would say there are no answers (mordred doesn't count)16:06
sshnaidmodyssey4me, well, it's not really openstack repository16:06
sshnaidmgtema, yeah, responses were from people of this meeting actually :)16:06
mordredyeah - 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 ok16:07
dtantsurit seems that we can host GPL code, just not make it official openstack delivarables16:07
odyssey4meis that a problem?16:07
sshnaidmI'd like to know what it blocks for us16:07
mordrednope. should be fine. this is an effort of a sig16:07
*** jpena is now known as jpena|off16:07
*** dave-mccowan has quit IRC16:07
mordredI don't thnk it's blocks anything. ansible is already GPL16:08
dtantsurnothing blocking. just a bit unfortunate that we cannot proudly call these modules official16:08
sshnaidmwhat is consequences of not having this as deliverable?16:08
odyssey4mewe have imports both ways, right - the module imports ansible (GPL) stuff, and also imports openstack (Apache) stuff16:08
mordredso anything that would use these modules must by definition be ok consuming gpl software16:08
dtantsursshnaidm: no promotion on
mordredI don't think it's a matter of not being able to call these modules official16:08
dtantsurone things that I think is important re licensing:16:08
sshnaidmmordred, this won't change anyway, we don't relicense them16:08
mordredit's that they can't be part of an OpenStack release16:08
mordredwhich they wouldn't be anyway, since that makes no sense16:09
dtantsurif we write something that looks like logic independent of ansible, we should better put it somewhere else16:09
dtantsurotherwise we won't be able to easily reuse it in other parts of openstack16:09
mordreddtantsur: right. and that's stuff we tend to put in sdk16:09
dtantsure.g. it will be troublesome to put it to sdk16:09
pabelangerright, this should be the ansible community openstack collection16:09
dtantsurlast time I proposed that any logic goes to sdk16:09
mordred(which is one of the reasons we have sdk and are so adamant about butting things in there)16:09
odyssey4meyep, the thinner the module is as a layer - the better16:09
mordredthe modules should be thin glue code between the ansible module structure and logic entities in sdk16:09
mordredthis will be easier to accomplish with the modules in gerrit now16:10
dtantsur#agreed Try to put most of the logic into openstacksdk, keep the ansible modules as thin glue16:10
sshnaidmhaving lite modules with sdk logic is totally fine for me too, but here comes question of compatibility between versions16:10
mordredthe sdk supports all versions of openstack16:10
*** dave-mccowan has joined #openstack-sdks16:10
mordredso that direction is fine16:10
dtantsursshnaidm: any logic code is anyway tied to openstack, not to ansible16:10
sshnaidmdtantsur, right, agree16:11
Shrewsyes, there is no reason to not continue that abstraction/separation. also, hi!16:11
mordredthe 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 that16:11
dtantsurwow, I wild Shrews appears :)16:11
dtantsur* a wild16:11
Shrewsi'm tame now16:11
* mordred hands Shrews a bunny16:11
gtemaatm collection does not define dependency to Ansible (requires version)16:11
gtemaso assume this should not happen in near future16:12
dtantsurgundalow: ^^^?16:12
mordredyah. so hopefully we can have our modules support all extant versions of ansible too16:12
sshnaidmI hope won't happen at all16:12
mordred(even if the modules have to have some if logic in them to do so)16:12
mordredbut the module interface has been *VERY* stable for the past several years16:12
odyssey4meI 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
gtemadon't kill me: should we introduce support for microversions in Ansible?16:13
mordredthe only main systemic changes have been around things like docstsring formats16:13
dtantsur#agreed Try to support as many versions of ansible as possible with the same code16:13
* dtantsur throws a lot of wet cats at gtema16:13
mordredgtema: no16:13
mordredall microversion support should be in the sdk16:13
gtemait was a joke, but with small sense of truth16:13
sshnaidmso, back to hosting modules - do we completely freeze existing and start new ones? Remember that people will use them from 2.10 from our repo16:13
* mordred throws wet cat at gtema16:13
mordredI *strongly* oppose starting new modules16:14
gtemai mean if someone would like to get info about smth, what is reported only with microversion set16:14
Shrewswhy would we *want* new ones?16:14
dtantsurmordred: would you rather prefer a breaking change?16:14
sshnaidmmordred, we'll need to rename them at least16:14
dtantsurShrews: we need 1) rename some modules, 2) fix auth in some16:14
sshnaidmand people use them in their playbooks16:14
pabelangerone 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
*** irclogbot_3 has quit IRC16:14
*** irclogbot_1 has quit IRC16:14
mordredI think that's potentially unnecessary and hard16:15
mordredmany of these modules have been unchanged from ansible 2.016:15
dtantsurit depends on how different 2.11 will be from 2.1016:15
mordredansible itself does _not_ change that much as it relates to the module interface16:15
sshnaidmmordred, I think current names and code should be re-thought at least16:15
odyssey4mehmm, ok - is the scope of the collection *just* modules/libraries?16:15
dtantsurI recall auth being mess in ironic modules (maybe all really)16:15
openstackgerritAndrew Karpow proposed openstack/python-openstackclient master: Use network service for Server AddFixedIP
mordredodyssey4me: the scope of _this_ collection, yes16:16
*** irclogbot_2 has joined #openstack-sdks16:16
gtemalet's talk about collection name16:16
dtantsurwhat else can we have?16:16
mordredI think this sig can have additional collections published to galaxy that contain roles and stuff16:16
odyssey4memordred: ok, sounds sensible - we should probbaly document that somewhere16:16
*** lbragstad has quit IRC16:16
Shrewswhat is the proposed new module naming structure? and why doesn't the current one work?16:16
mordredbut this, for now, is about moving the os_ modules from ansible/ansible and into a collection16:16
dtantsurShrews: at least s/os_ironic/baremetal/16:16
gtemaShrews: os_ prefix is unnecessary16:16
dtantsuractually, drop os_?16:17
mordredShrews: 2 potential naming things ... yeah16:17
pabelangeris there no plugins that need to move?16:17
pabelangerdtantsur: plese no16:17
pabelangerthat will break playbooks16:17
mordredos_ prefix - and the service-type in the module names for "admin" modules16:17
sshnaidmI'd leave existing with deprecation notice and start from copying and reworking them16:17
dtantsurpabelanger: that's why we're talking about new modules16:17
mordredbut - pabelanger makes a good point WRT naming16:17
dtantsurleave os_ironic whatever it is, develop baremetal properly16:17
mordredthis is a thing I'd like to really get a real answer on though16:17
sshnaidmpabelanger, yeah, I wouldn't touch them at all16:17
* gundalow waves16:18
sshnaidmmordred, working on old modules doesn't give us any freedom and will most likely break existing playbooks16:18
mordredgundalow mentioned a magical thing that would allow someone to install ansible + a set of collections to get symlinks for the old modules for compat16:18
gtemawrt playbook change, I was still not able to get answer in Ansible16:18
mordredif that exists, and doesn't have support for module-level symlinks, then I think renaming is very mean16:18
pabelangerI would recommend everybody look at, that is the tooling being written today to migrate content out of ansible/ansible to collections. So far, that has some large assumptions16:18
gtemaso for the moment it is not known, whether it is possible at all16:18
mordredif it doesn't exist - we should rename because everyone is going to be broken anyway16:18
mordredif it does exist AND we can provide a mapping of fully qualified names to old names, then we should rename16:19
pabelangergtema: which answer?16:19
mordredI think we need an answer on what the omnibus installer looks like before we commit one way or the other to renaming anything16:19
gtemaexaclty, whether it is possible to leave playbooks unaffected16:19
gtemawithout introducing FQCN16:19
pabelangergtema: yes, that is possible16:19
pabelangercollection loader supports relative imports16:20
mordredcan you say more words about that?16:20
pabelangerso both cisco.ios.ios_config and ios_config are valid tasks in playbooks using collections16:20
sshnaidmI think gundalow told about this previous time, it works like imports in python16:20
mordredpabelanger: I thought you had to add an import statement to your playbook for that to work16:20
gundalowmordred: 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
pabelangerif collection is cisco.ios16:20
gundalowsshnaidm: correct16:20
gtemanot really, in the 2nd case you introduce import at the beginning of playbook16:20
mordredpabelanger: right - but you have to add a collection reference into the playbook16:21
sshnaidmmordred, when using symlink you shouldn't16:21
mordredhang on16:21
pabelangermordred: no, not any more16:21
mordredtwo different things16:21
pabelangerfrom playbooks, what I said is fine16:21
gundalowIf you are using ACD you may not need to explicitly import anything that ships in ACD, it's done automagically for you16:21
pabelangerfor module_utils, you should use fqcn (fully qualify collection name)16:21
mordredgundalow: what's ACD?16:21
gundalowsorry, Ansible Community Distribution16:22
mordredis that what I get when I do "pip install ansible" ?16:22
dtantsurdo we expect a lot of people to use it?16:22
dtantsuryeah, same question (dnf install ansible, etc)16:22
pabelangermordred: magic installer doesn't exist today16:22
mordredok. I won't be using that16:22
gtemabrew install ansible?16:22
pabelangerso, pip install ansible / ansible-galaxy collection install foo16:22
gundalowIn an ideal word, yes, `$package_mgr install ansible` will give you ACD16:22
dtantsurand in ours? :)16:23
mordredgundalow: does $package_mgr include pip? (sorry to be pedantic here- just trying to make sure I understand everything)16:23
gundalowmordred: yup including pip16:23
mordredgundalow: so - the magic there is done via symlinks from the botmeta file we discussed the other day right?16:23
gtemaI still do not really believe in a perfect world16:23
gundalowGiven 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 modules16:24
mordredgundalow: do we know if we'll be able to specifiy in that botmeta file mappings on a per-module basis?16:24
gtemawhen we release first collection we need to insure our func tests from SDK are using really collection16:24
gundalowmordred: yes, BOTMETA supports per file, there are examples, it's just that generally we logically group by directory16:24
mordredgtema: we should probably test both ways16:24
mordredgundalow: cool.16:24
mordredso - let's assume a perfect world for a sec ...16:25
pabelangergtema: mordred: yes, testing both is safest, that is what ansible network does now16:25
* gtema falls asleep16:25
mordredif the botmeta thing works per file and if it exists and does the symlinks and works for pip nad dnf and friends ...16:25
dtantsurgtema: just half past 5, c'mon!16:25
mordredthen it should be safe to rename the modules in the collection16:25
sshnaidmok, so back to the original question, should we keep old modules fully functional as before for not breaking current users?16:25
mordredbecause we can do a name mapping in botmeta16:25
gtemasure we need to test both, but exactly here we need to "rely" on assumption it works both ways without modifying playbook16:25
mordredpeople getting the modules through symlinks will not be affected16:25
dtantsurmordred: assuming our auth changes won't end up breaking?16:26
mordredand people using collection explicitly will use colledction paths16:26
dtantsur(and assuming we won't need other per-module breaking changes)16:26
mordreddtantsur: well - it's sounding like there's less implicit breaking than we thought before16:26
gtemalet's do all breaking as new modules16:26
gtemawith a fresh design16:26
mordredso 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-breaking16:26
dtantsurgtema: the question was whether we need new modules16:26
gtemasure we need16:26
mordredgtema: I don't want two different designs - we don't have enough people working on this to support that :)16:27
mordredwe *barely* have enough people to keep the ones we have going16:27
gtemawe currently do not have possibility to manage tags, and I do not really want to modify each module with tagging mess16:27
dtantsurat the very least we need to think how to support all session AND adapter options16:27
dtantsurI think we don't do it now16:27
* Shrews recalls a recent twitter thread on the pitfalls of rewriting s/w from scratch16:27
mordredwell - we assume for complex options you'll use clouds.yaml16:27
mordreddtantsur: and you can pass a full clouds.yaml yaml snippet to the cloud parameter of the module too16:28
sshnaidmthere are some modules like ironic_node that should be redesigned at all16:28
dtantsurI'm talking simple: {auth_type: none, endpoint_override: https://bare.metal}16:28
mordredthat said- if we NEED to redesign a module and deprecate the old one - we should totally do that16:28
mordreddtantsur: that should work by passing to cloud:16:28
dtantsurmordred: in cloud.yaml - yes (well.. maybe)16:28
mordredno - in the module16:28
mordredyou can pass _anything_ to cloud: that you can put in a clouds.yaml cloud entry16:29
sshnaidmmordred, I'm afraid changes in may require redesign in most of modules..16:29
dtantsurI remember I had some problem. I need to check.16:29
mordredsshnaidm: they might - and we might need to do some things16:29
mordredI think what I'm saying is that it sounds like ansible/ansible is providing mechanisms to make this not an inhernet breaking change16:30
mordredso our ground cover for making additional breaking changes is lower16:30
mordredso we should at least TRY to not immediately make breaking changes16:30
sshnaidmmordred, deprecating old modules gives you more freedom to break things, then trying to keep backward compatibility16:30
mordredwe might find something that needs to be changed and we can't figure out non-breaking16:30
mordredand we'll just need to figure out how to not screw our users16:30
pabelangeryes, please for users, don't break things out of gate :)16:30
mordredsshnaidm: it does. but right now we're just supposing16:30
mordredwe don't have an actual thing that must be done that must be breakingm16:30
mordredI agree - we can deprecate, we can copy/modiify - do lots of things16:31
mordredlet's just do those16:31
mordredand not immediately jump to "upstream is breaking everyone anyway so we're safe"16:31
gtemaok for me16:31
mordredin fact ... OOH16:31
mordredno - neverind- I thought I had a new idea16:32
sshnaidmok, so what are we agreed on currently? :)16:32
mordredthat everyone here is awesome :)16:32
gtemanot to break immediately16:32
odyssey4meI expect we'll be wanting to deprecate the dynamic inventory, given that the plugin interface is better anyway?16:32
sshnaidmwe continue to develop modules with old names and trying not to break current users?16:32
sshnaidmmordred, ^^ ?16:32
mordredodyssey4me: that's already dprecated? people should be using the plugin and not the script already16:33
mordredsshnaidm: I think ansible/ansible has a solution for name mapping16:33
gtemasshnaidm not to break != continue with old names for new things16:33
odyssey4memordred: one would hope - I guess we could then remove it from ansible/ansible and not put it into the collection16:33
mordredso I think we *can* rename16:33
mordredwe just have to put the name mapping into botmeta in ansible/ansible16:33
sshnaidmit's akward to have same modules with different names, either I don't understand something..16:34
mordredodyssey4me: you raise a good question ... can the inventory _plugin_ go into the collection too?16:34
mordredsshnaidm: let me try to explain from scratch with an example16:34
sshnaidmmordred, can you bring an example of rename?16:34
mordredlet's take os_server16:34
gtematechnically everything can go into collection16:34
pabelangergtema: yup!16:34
*** lbragstad has joined #openstack-sdks16:34
mordredwe 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
mordredso then the canonical name of the module ios openstack.api.os_server16:35
mordrednow - in the ansible/ansible repo there is a yaml file, BOTMETA.yml - and in it we put in an entry like:16:35
mordredopenstack.api.os_server: os_server16:36
mordredthis 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_server16:36
mordredso people who aren't paying attention will have no changes happen to that16:36
sshnaidmyeah, but where is the rename?16:36
mordredhang on16:36
mordredsince that is the mechanism, there is then nothing stopping us from renaming the module in our collection to openstack.api.server16:37
mordredand making the mpapping be openstack.api.server: os_server16:37
mordredpeople using fully qualitied are fine16:37
mordredpeople using omnibus symlinks are fine16:37
mordredeveryone is fine16:37
pabelangerso, if I was do to ansible-galaxy collection install openstack.api I could both do openstack.api.os_server: ... and os_server: ... from playbook16:37
mordredand eventually, in the fullness of time, maybe the synlink mapping goes away16:37
mordredpabelanger: yah16:38
sshnaidmmordred, that exactly what I mean, you install os_server and something new like openstack.api.server and it's the same module exactly16:38
pabelangerwithout botmeta.yml16:38
mordredpabelanger: right - but that keeps us tied to the old names16:38
mordredbotmeta lets us rename in teh collection without screwing people16:38
pabelangeryes, agree16:38
pabelangerso, if we did rename in collection16:38
mordredassuming taht support exists and works - but according to gundalow it's pretty essential that it does16:38
sshnaidmcan we alert people that use os_server that it will be deprecated?16:39
sshnaidmand not people that use openstack.api.server16:39
gtemaI guess they will need to adapt with Ansible 2.12 anyway16:39
pabelangerokay, I need to look on our side, I am not sure how ansible-galaxy collection install reads BOTMETA16:39
pabelangerbecause, today it doesn't16:39
sshnaidmor we'll be stuck forever with the old names :)16:39
mordredpabelanger: it doesn't16:40
mordredthis have nothing to do with ansible-galaxy16:40
mordredthis is something that is a  build-time facility for ansible itself16:40
pabelangerokay, standing by16:40
mordredso when they buikld the wheel for ansible - the build script will grab the collections, suck them in and make symlinks16:40
pabelangerright, however people can do ansible-galaxy collection install out side of meta ansible package16:41
sshnaidmI suggest we'll continue in ML about renaming, we're past half meeting16:41
pabelangerin that install case, renames would break playbooks today16:41
mordredok. let's take this as an action16:41
gtemalet's make for safety own links inside of collection16:41
sshnaidm#action sshnaidm to write ML to discuss renaming16:41
mordredI'll cirlce up with gundalow and get to the point where I *completely* understand what the intent is16:41
sshnaidmwe have now openstack namespace hosted by mordred16:42
mordredand then write up a summary for us as it relates to us, yeah?16:42
sshnaidmdo we want to put all modules in one collection?16:42
sshnaidmwhat would it be? ?16:42
dtantsurbikeshedding \o/ finally!16:42
sshnaidmand then etc16:42
mordredthat's a good option. when we did the .well-known support we picked openstack.api16:43
dtantsurI don't dislike openstack.cloud16:43
gtemapabelanger: what is the name for networking?16:43
sshnaidmopenstack.ansible ?16:43
sshnaidmI have a lot of ideas :D16:43
mordredI like both cloud and api - I do not like ansible :)16:44
sshnaidmapi sounds weird for me16:44
mordredbut - let's make a quick distinction on something16:44
pabelangergtema: we don't have a meta collection, so we have things like cisco.ios / cisco.iosxr / junpernetwork.junos16:44
gtemaah, ok16:44
pabelangerI am trying to see what aws and google did16:44
pabelangerthey might be and cloud.aws16:44
mordredno _ I think it's google.cloud16:44
mordred(other way - they have namespaces?)16:45
pabelangeryes, google.cloud16:45
mordredso let's just do openstackcloud16:45
mordredso let's just do openstack.cloud16:45
gtemaok for me16:45
mordredno need to be different16:45
mordredso - earlier the question was "do we put all of the modules in one collection"16:45
mordredI think the answer is "yes" - as long as we're talking about modules that interact with teh openstack api16:46
sshnaidm#agreed to have one collection as openstack.cloud16:46
sshnaidmok? ^16:46
mordredif there is, say, an openstack-ansible or tripleo module that does things like manipulates nova databases or somethingm16:46
mordredthen I think that can go into a different collection16:46
sshnaidmadmins to namespace16:46
mordred(in fact, I would expect us to be able to have collections for tripleo/openstack-ansible roles and plugins and stuff)16:46
sshnaidmdo we need admins? should it be a zuul?16:47
mordredfor 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 jobs16:47
sshnaidmzuul needs to post updated code to collection afaiu16:47
mordredwe'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
odyssey4meAs 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
mordredwe can write a publication job for that - or reallky just steal the ones pabelanger has already written16:48
sshnaidmmordred, are there admins for specific collections?16:48
sshnaidmpabelanger, gundalow ^^16:48
mordredodyssey4me: you can totally unit test modules16:48
pabelangeryes, I have a job for that in zuul16:48
pabelangerunit tests is via ansible-test16:48
mordredyeah. it's pretty col16:48
odyssey4memordred: hooray! I'll have to look into that16:48
Shrewsthe current openstacksdk tests should likely move to the new project16:48
sshnaidmodyssey4me, yeah, there are examples in ansible repo16:49
mordredsshnaidm: no - to my knowledge it's a namepsace level16:49
Shrewss/tests/module tests/16:49
mordredShrews: ++16:49
pabelangerhowever, I would love to build some sort of stestr ansible-playbook things, to work with any playbook16:49
odyssey4methanks - good to know that I have some homework to do :)16:49
sshnaidmI've already have a patch to migrate the job to this repo16:49
sshnaidmok, let's move on16:49
sshnaidmversioning and branching16:49
sshnaidmwe want to keep modules up to date, right?16:50
sshnaidmnot as they were in ansible rpeo16:50
gtemano, what for16:50
mordredI don't understand the question?16:50
sshnaidmwill we have manual releases as some openstack repos do? or it will be continuous delivery16:51
mordredah - that's a _great_ question16:51
sshnaidmand should we be tied to openstack releases?16:51
mordredthat is a for sure no16:51
odyssey4meno tie to openstack releases IMO, and CD would be great IMO16:51
mordredbut for the other - I think the intent is for collections to be versioned with semver right?16:51
gtemait's more likely to tie somehow to SDK version16:51
Shrewsyeah, ansible users do not want to wait for an openstack release to get a bug fix/feature16:52
mordredyeah - a version of the collection will have a minimum sdk version16:52
mordredbut neither of those need to be tied to an openstack release16:52
pabelangerand depend on ansible engine (stdlib / minimal)16:52
mordredso - maybe we start with "tag releases as needed?"16:52
elmikodtantsur: no worries, i actually missed the start here =(16:52
sshnaidmwe won't have branches like ussuri, train, etc, right?16:52
pabelangermordred: I'd love to see us upload pre-release versions to galaxy16:52
dtantsurelmiko: :)16:52
mordredthat's been working pretty will for sdk16:52
pabelangerthen tag when want to support it16:52
mordredpabelanger: 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
pabelangeras, collections are artifacts, not git repos now16:53
pabelangeryou need to build the collection, to install16:53
sshnaidmmordred, I'd prefer CD, but with good CI tests for it :)16:53
elmikodtantsur: fwiw, i say keep using this slot as long as it is useful and productive for the group =)16:53
dtantsurelmiko: cool! I would expect some more times before we settle down on everything16:53
mordredyeah. 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
sshnaidmmordred, all the time - how often?16:54
Shrewswhen requested  :)16:54
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
mordredyeah- we can cut 3 sdk releases in a week if we need to16:54
sshnaidmit's almost CD :)16:54
gtemawe can do daily, aren't we?16:55
sshnaidmwhat is the advantage?16:55
sshnaidmthen why not every patch16:55
mordredbecause we have to tag to make a release16:55
pabelangerfor 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 install16:55
mordredand that goes through openstack-release16:55
elmikodtantsur: yeah, it's all good. the sig office hour is slow, so i think the multiplexing is fine ;)16:55
odyssey4mewe 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 patch16:55
sshnaidmmordred, I'm just curios if it has some advantages over CD16:55
mordredpabelanger: sure ... I guess what I'm sayuing is - why woudln't we just cut a real release?16:55
Shrewssshnaidm: we have to submit a separate review to release a new version. not quite CD16:56
pabelangermordred: Yup, that works too. A pre-release just avoids the need for asking16:56
mordredyeah. and some people don't want actual constant upgrades16:56
sshnaidmShrews, it seems like more maintenance16:56
mordredso we try to just use judgement16:56
mordredit's not a burden on us sdk side16:56
pabelangerodyssey4me:, how we do it today for network16:57
mordredit's been really easy to work with16:57
Shrewssshnaidm: it is the openstack process we've agreed to as an openstack project16:57
mordredI mostly think we shouldn't overcomplicate this until we need to16:57
sshnaidmand not overcomplicating is..?16:57
sshnaidmmanual releasing?16:58
mordredwe 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 that16:58
mordredso we all have a common basis of understanding of the problem we're trying to solve16:58
mordredwe can also, similar to openstack, produce master artifacts probably16:58
sshnaidmI'm not against releases, just trying to get the point where it helps16:58
mordredfor people who do want to consume CD16:58
pabelangeryes, building the collection isn't difficult16:59
mordredsshnaidm: 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 it16:59
sshnaidmok, so anybody objects to manual releases and want CD only?17:00
sshnaidm#agreed on having manual releases as much as we need17:00
gtemanot me17:00
dtantsursounds good17:00
sshnaidmwell, we're out of time17:00
dtantsuryay, thanks all!17:00
pabelangermordred: 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 now17:00
*** openstack changes topic to "Bug tracker for SDK and OSC is now at"17:01
openstackMeeting ended Thu Dec 12 17:01:07 2019 UTC.  Information about MeetBot at . (v 0.1.4)17:01
openstackMinutes (text):
mordredpabelanger: I want buildset-galaxy the instant we can have it17:01
gtemadtantsur, can I sleep now?17:01
dtantsurgtema: I shall permit that17:02
sshnaidmmordred, I think I'll get my CI job patch on top of yours with modules17:02
sshnaidmmordred, to have it ready for running basic tests for them17:02
pabelangersshnaidm: how do you plan to run unit tests?17:03
sshnaidmpabelanger, we don't have these afaik17:03
sshnaidmpabelanger, with tox?17:03
pabelangersshnaidm: this is unit tests?17:03
sshnaidmpabelanger, we have a job that runs functional tests and was running on ansible patches before17:04
sshnaidmpabelanger, I convert it to run on sig repo now17:04
pabelangeryah, that is devstack right?17:04
sshnaidmpabelanger, yep17:04
sshnaidmpabelanger, I didn't see unittests, lemme check in ansible repo..17:05
pabelangerk, so should be able to just build collection and install, and ansible dev find it17:05
pabelangerusing ansible-galaxy17:05
Shrewsthere were no unit tests, only functional tests17:05
Shrewsi wouldn't even know how to unit test an ansible module17:05
pabelangeryah, it is a little messy IMO17:06
sshnaidmyeah, no unit tests17:07
sshnaidmthere is a guide in ansible docs17:07
Shrewsand the current functional tests are woefully inadequate and hopefully will be improved uon17:07
sshnaidmdidn't try it yet17:07
Shrewsyeah, i know it's possible, i've never had interest to learn how though17:08
gtemamordred: what can you say about
pabelangerno, I wouldn't use ansible-test for unit tests. I would much rather do something like stestr for it17:08
pabelangeransible-test is very opionioned in that case17:08
*** efried is now known as efried_afk17:08
sshnaidmpabelanger, is it usable for something?17:09
sshnaidmansible-test I mean17:09
sshnaidmit has a lot of sanity checks I saw17:09
pabelangerwe use it for integration testing, in network17:09
pabelangerit works, but is also slow in some cases17:09
sshnaidmpabelanger, can you drop a link please?17:09
pabelangerbut not for unit tests for sanity17:09
sshnaidmI'm curios if we can use molecule for tests17:10
mordredShrews, sshnaidm, pabelanger: perhaps once we're structured a bit more like this: it'll be easier to write "normal" unit tests?17:10
pabelangermolecule uses pytest17:10
mordredor maybe it won't be - who know17:11
pabelangersshnaidm: is a integration test for network and collections17:11
pabelangerbasically, we have a parent job for build-ansible-collection, which creates the artifacts and passed is back into swift (soon galaxy)17:12
pabelangerthen ansible-test jobs, fetch collections and ansible-galaxy collection install it17:12
pabelangerto then run ansible-test17:12
sshnaidmmordred, yeah, need to try..17:12
pabelangerI'm not sure I'd try to use molecule... personally, I haven't see much work on ansible side to update it for collections17:13
mordredthat's how we unittest modules in zuul-jobs17:13
mordredpabelanger: 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 here17:14
pabelangermordred: yah, it would be great to some how loop that into a test runner, for both zuul and local17:14
mordredpabelanger: I think we can do that pretty easily17:14
mordredif you run stestr in zuul-jobs it'll run those unit tests17:14
pabelangeroh, today?17:14
pabelangerthat is what I want to do for network17:14
mordredit'll need to be slightly adapter - but it should be mostly cargo-cultable17:15
pabelangerthen, even add support for ansible-playbook and inventory file, like we did with zuul functional testing17:15
mordredtests/ is what drives finding the tests to run17:15
*** sshnaidm has quit IRC17:18
*** jpena|off is now known as jpena17:27
*** gtema has quit IRC17:27
*** KeithMnemonic has quit IRC17:36
*** dtantsur is now known as dtantsur|afk17:37
*** jpich has quit IRC17:37
*** lbragstad has quit IRC17:52
*** ralonsoh has quit IRC18:24
*** ricolin has quit IRC18:24
*** jpena is now known as jpena|off18:36
*** gmann is now known as gmann_afk18:53
*** mgariepy has quit IRC19:08
*** sshnaidm has joined #openstack-sdks19:09
*** tosky has quit IRC19:21
*** efried_afk is now known as efried19:38
*** KeithMnemonic has joined #openstack-sdks20:09
*** gmann_afk is now known as gmann22:29
*** mriedem is now known as mriedem_away23:01
*** dmellado has quit IRC23:09
*** mriedem_away has quit IRC23:10
*** mriedem has joined #openstack-sdks23:11
*** irclogbot_2 has quit IRC23:11
*** sshnaidm is now known as sshnaidm|off23:11
*** dmellado has joined #openstack-sdks23:11
*** irclogbot_0 has joined #openstack-sdks23:12
*** slaweq has quit IRC23:30
*** slaweq has joined #openstack-sdks23:34

Generated by 2.15.3 by Marius Gedminas - find it at!