15:01:37 <noonedeadpunk> #startmeeting ansible-sig
15:01:38 <openstack> Meeting started Tue Dec  3 15:01:37 2019 UTC and is due to finish in 60 minutes.  The chair is noonedeadpunk. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:40 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:42 <openstack> The meeting name has been set to 'ansible_sig'
15:01:57 <noonedeadpunk> #topic ironic modules
15:02:13 <sshnaidm> noonedeadpunk, thanks
15:02:19 <sshnaidm> I divided topics to organizational and technical parts
15:02:40 <sshnaidm> #topic Who is interested?
15:03:13 <noonedeadpunk> #chair hnaidm
15:03:14 <openstack> Warning: Nick not in channel: hnaidm
15:03:15 <openstack> Current chairs: hnaidm noonedeadpunk
15:03:18 <noonedeadpunk> #chair sshnaidm
15:03:19 <openstack> Current chairs: hnaidm noonedeadpunk sshnaidm
15:03:23 <weshay> 0/
15:03:27 <mnaser> 👋
15:03:30 <sshnaidm> #topic Who is interested?
15:03:33 <sshnaidm> yay
15:03:48 <sshnaidm> I think we have here present Ironic, Tripleo and Openstack-Ansible, anybody else is interested?
15:04:21 <mnaser> i think indirectly the ansible openstack modules as well (that currently would will likely move to a collection)
15:04:48 <noonedeadpunk> I think kolla-ansible folks should be also somewhere here
15:04:54 <sshnaidm> mnaser, yeah, so folks from openstack infra as well
15:05:14 <sshnaidm> noonedeadpunk, ack
15:05:17 <dtantsur> I'm also representing openstacksdk
15:05:48 <sshnaidm> dtantsur, is it under multiple teams?
15:05:57 <dtantsur> what exactly?
15:06:01 <sshnaidm> like each one doing its part there
15:06:05 <sshnaidm> dtantsur, openstacksdk
15:06:24 <dtantsur> openstacksdk is a team of its own
15:06:33 <dtantsur> I'm part of both teams
15:06:44 <sshnaidm> dtantsur, great
15:07:12 <sshnaidm> seems like we might have some changes in sdk too for ansible modules, so great to have people there
15:07:42 <sshnaidm> ok, let's move on
15:07:44 <dtantsur> we certainly might
15:07:52 <dtantsur> I'd actually prefer that we do most of the logic in SDK
15:08:21 <sshnaidm> dtantsur, ++
15:08:35 <sshnaidm> #topic Where to put the modules?
15:09:01 <mnaser> so mordred proposed putting them inside openstacksdk
15:09:03 <sshnaidm> we have the patch of Monty, that is not available currently
15:09:15 <sshnaidm> yeah
15:09:18 <mnaser> the issue that can present is this stuff is gpl and there's some reasoning behind why it cant live there
15:09:35 <mnaser> monty has actually commented saying "Can totally make this an ansible-sig deliverable - what do we need to do to do that? Is there a pointer somewhere?"
15:09:36 <noonedeadpunk> maybe we should put them under ansible-sig?
15:09:38 <dtantsur> could this reasoning be shared?
15:10:05 <mnaser> dtantsur: the modules are currently gpl3 code which is not compatible with openstack's licenses (apache and other osi approved licenses)
15:10:15 <mnaser> (because ansible is gpl3)
15:10:23 <dtantsur> right, but it's only a problem if we import these modules from our code
15:10:39 <mnaser> right -- but those modules would be official openstack deliverables
15:11:00 <mnaser> (im talking os_server, etc)
15:11:02 <dtantsur> do we have an official position against GPL code?
15:11:14 <mnaser> https://governance.openstack.org/tc/reference/licensing.html
15:11:18 <mnaser> In order to be considered for inclusion in the tc:approved-release, the project must be licensed under Apache License, Version 2.0 (ASLv2).
15:11:34 <dtantsur> sigh, okay
15:11:38 <mnaser> yeah, its kinda annoying.
15:12:00 <dtantsur> can we still host them on opendev?
15:12:12 <mnaser> yep, so SIG deliverables are not actaully 'affected' by this
15:12:20 <mnaser> hence my suggestion (and noonedeadpunk here too) to put it under ansible-sig
15:12:28 <dtantsur> I see a huge missed PR opportunity in not being able to say "We have official ansible modules"
15:12:52 <mnaser> yeah
15:12:52 <sshnaidm> so even if we have them in ansible-sig, we still need to deliver them somehow?
15:13:03 <dtantsur> sshnaidm: unofficially, via galaxy?
15:13:03 <mnaser> right, but ansible-sig is a sig, not an official openstack team
15:13:16 <sshnaidm> dtantsur, I don't think it will work with tripleo..
15:13:20 <dtantsur> so, no docs.openstack.org, no promotion on openstack.org, etc
15:13:30 <dtantsur> sshnaidm: well, tripleo is using packages, that's a whole different story
15:13:36 <mnaser> sigs can publish on docs.openstack.org -- im not sure about the promotion on openstack.org tho
15:13:37 <dtantsur> if we package them for RDO, we're good
15:14:04 <sshnaidm> dtantsur, well, right
15:14:07 <mnaser> so honestly if anyone wants to pursue this, we can bring this up to the legal-discuss mailing list
15:14:18 <mnaser> but expect this to add a significant latency in us merging this..
15:14:27 <dtantsur> right
15:14:33 <dtantsur> we can consider it afterwards
15:14:40 <mnaser> yep, nothing stops us from moving it later!
15:14:44 <dtantsur> exactly
15:14:52 <mnaser> gettig it into gerrit/opendev is like am illion steps ahead
15:14:52 <noonedeadpunk> Actually there will be more ansible modules moved, so I think we should know what exactly is allowed
15:15:17 <mnaser> inside a sig, its pretty much open for us to do what we like, as its not an official openstack team/approved release
15:15:24 <mnaser> anyways, so given monty's comments and he just pm'd me saying i can hijack his patch
15:15:57 <mnaser> ill update the patch to put the collections as a deliverable under ansible-sig and we can add old maintainers from ansible/ansible, tripleo-ansible interested folks, openstacksdk and OSA
15:16:10 <dtantsur> ++
15:16:19 <sshnaidm> mnaser, great
15:17:00 <sshnaidm> #action: to discuss possible builds of RPMs from these collections for RDO
15:17:23 * mordred waves to the nice humans
15:17:28 <mnaser> ohai o/
15:17:42 <sshnaidm> mordred, oh, great to have you here
15:17:51 <dtantsur> see, I just told mordred we're assigning all the work to him :D
15:18:02 <sshnaidm> mordred, do you have something to add? ^^ :)
15:18:29 <mordred> sshnaidm: nope - all the work is apparently assigned to me, so \o/ ;)
15:18:55 <sshnaidm> ok, if we're good about modules place for the near future, let's move on
15:18:58 <mnaser> i did a thing - https://review.opendev.org/#/c/684740/
15:19:07 <mnaser> so ill try to babysit/get this stuff to get into governance :)
15:19:24 <sshnaidm> mnaser ++
15:20:00 <mordred> mnaser: commit message ... I'm sure someone else will -1 for that
15:20:17 <mnaser> oops good catch
15:21:01 <mnaser> and done
15:21:10 <sshnaidm> \o/
15:21:18 <sshnaidm> let's all vote there :)
15:22:00 <sshnaidm> some organizational question:
15:22:03 <sshnaidm> #topic Do we need a regular meeting or to join some existing one?
15:22:21 <sshnaidm> I mean for all openstack ansible modules, not Ironic only
15:22:25 <dtantsur> API SIG office hours are quite empty usually, feel free to hijack them
15:22:48 <sshnaidm> dtantsur, when is it?
15:23:03 <dtantsur> 4pm UTC on Thu? lemme check
15:23:22 <dtantsur> yep
15:23:32 <sshnaidm> great, if nobody objects let's do it
15:23:45 <sshnaidm> and on which channel?
15:23:52 <dtantsur> #openstack-sdks
15:24:00 <dtantsur> we can discuss it with elmiko next Thu
15:24:04 <mordred> ++
15:24:07 <dtantsur> (he's the other API SIG chair)
15:24:25 <mordred> that sounds great to me - at least until such a time as there is a need for something more intense
15:24:25 <sshnaidm> ack, let's do it next week then
15:24:34 <dtantsur> since ansible API is sort of API, I think API SIG should be involved anyway
15:25:32 <sshnaidm> ok, let's move on if no objections
15:25:42 <sshnaidm> #topic Blueprint, trello, something else to track scope of work? And what is the scope?
15:26:01 <dtantsur> storyboard?
15:26:02 <sshnaidm> do we want to use something to track all progress about modules?
15:26:26 <dtantsur> since we're going to ship code, we're going to need a bug/feature tracker
15:26:41 <dtantsur> storyboard is the official thing, so we should start with considering it, I guess?
15:26:46 <noonedeadpunk> ++
15:26:47 <sshnaidm> dtantsur, well, bugs we can have still in LP?
15:27:08 <dtantsur> sshnaidm: but why?
15:27:09 <noonedeadpunk> But I guess they're supposed to move to storyboard anyway?
15:27:17 <mordred> storyboard has the benefit that openstacksdk is also in storyboard
15:27:25 <sshnaidm> I personally don't like storyboard, but fine with me
15:27:34 <mordred> so any issues that involve "also fix sdk" can be easily marked and tracked
15:27:40 <sshnaidm> yeah, tripleo-ansible uses storyboard too
15:27:41 <dtantsur> I'm not the biggest fan of it either, but LP is also pretty horrible
15:27:51 <mordred> sshnaidm: to be fair - I personally dont' like *any* of the bug trackers ;)
15:27:57 <dtantsur> mordred++
15:28:04 <noonedeadpunk> redmine? :p
15:28:12 * mordred hides from noonedeadpunk
15:28:23 <dtantsur> if we truly hate ourselves, we can setup a bugzilla instance somewhere
15:28:27 <sshnaidm> ok, ok, let's not go so wild :D
15:28:39 <mordred> one day someone is going to write a bug tracker which is nicer to use than "text file in vi"
15:28:42 <jrosser> what credentials do you need to report a bug on storyboard
15:28:54 <dtantsur> jrosser: ubuntu ones as well, I think
15:28:57 <jrosser> as a lot of end users will not be openstack contributors/developers
15:29:14 <sshnaidm> I think it's enough to have ubuntu one?
15:29:32 <sshnaidm> which is odd requirement by itself..
15:29:45 <noonedeadpunk> It's the same as for launchpad so no issues should raise with that
15:29:49 <dtantsur> yep
15:29:52 <jrosser> right ok, so same
15:30:07 <sshnaidm> ok, so we need to create a project there as I understand
15:30:19 <sshnaidm> any volunteers..?
15:30:34 <dtantsur> I'm not sure projects can be created by a mere mortal
15:30:53 <sshnaidm> yeah, good question btw
15:31:00 <dtantsur> I think infra provides them
15:31:03 <sshnaidm> mordred, do you know maybe? ^
15:31:36 <sshnaidm> #action sshnaidm to check how to create a project on storyboard for ansible modules
15:31:49 <sshnaidm> ok, let's move on
15:31:58 <sshnaidm> #topic List of people interested in reviews
15:32:09 <sshnaidm> just waive here if you are
15:32:29 <dtantsur> o/
15:32:30 <sshnaidm> o/
15:32:46 * dtantsur waives mordred's hand
15:32:53 <sshnaidm> mnaser, noonedeadpunk ?
15:32:55 <noonedeadpunk> o/
15:33:06 <gtema> in reviews of what? modules? overall modules or specific ones?
15:33:07 <mnaser> i can help out with reviews
15:33:14 <mnaser> for the modules
15:33:18 <sshnaidm> gtema, both
15:33:21 <jrosser> o/
15:33:52 <gtema> I would help with that, but am terribly overloaded atm
15:34:01 <sshnaidm> gtema, np
15:34:47 <sshnaidm> Ok, so I think we finished with non-technical part of agenda, is there anything I missed and you'd like to discuss? (non technical)
15:35:07 <mnaser> yeah i think my reviews will come in bursts and pings lol
15:35:46 <sshnaidm> mnaser totally fine)
15:36:08 <mordred> o/
15:36:19 <mordred> same with mnaser - mine will come in bursts and pings :)
15:36:27 <sshnaidm> great
15:36:56 <mordred> largely I would LOVE it if the sig gets rolling and I can be a vestigal complaining old man nobody is depending on for their modules :)
15:37:13 <dtantsur> to which extent can we modify the modules we're importing?
15:37:13 <mordred> so - you know - anything I can do to empower anybody else at this point
15:37:42 <sshnaidm> dtantsur, what do you mean?
15:37:44 <mordred> dtantsur: my vote is "as much as we want" - installing the collection vs. installing the in-tree modules is going to be different anyway - so it seems like a good time to fix things
15:37:54 <dtantsur> this ^^^
15:38:06 <dtantsur> yeah, I'm pretty sure e.g. authentication can use an update, etc
15:38:09 <mordred> nobody is going to get this update without a conscious decision on their part - unlike say just upgrading ansible
15:38:18 <dtantsur> we need to standardize on standalone usage
15:38:23 <dtantsur> k, great
15:38:25 <sshnaidm> so do you want to import them already modified?
15:38:26 <mordred> ++ auth has a bunch of cruft
15:38:38 <gtema> mordred: totally with you. I am angry about time it take to get the upstream module fix be delivered
15:38:44 <dtantsur> sshnaidm: I think I've actually jumped to the next topic
15:38:46 <mordred> I think we should import them as-is - then modify in place
15:38:51 <sshnaidm> dtantsur, well, yeah :)
15:38:58 <dtantsur> :)
15:38:59 <sshnaidm> #topic Using openstacksdk instead of clients
15:39:07 <sshnaidm> I'd start from second here
15:39:25 <sshnaidm> Do we agree to use openstack client instead of ironicclient, etc?
15:39:31 * dtantsur fully agrees
15:39:35 <mordred> ++
15:39:42 <dtantsur> although I assume you mean openstacksdk, not OSC
15:39:43 <sshnaidm> cool
15:39:50 <sshnaidm> dtantsur, yep, sorry
15:39:53 <mordred> the existing ansible moduiles should all already use openstacksdk yes?
15:40:00 <gtema> yes
15:40:01 <dtantsur> I think so
15:40:05 <sshnaidm> hope so
15:40:05 * mnaser agrees and yes they all do afaik
15:40:06 <mordred> but I'm guessing maybe some of the ones from openstack-ansible and/or tripleo don't?
15:40:15 <mnaser> openstack-ansible uses 100% upstream modules by now afaik
15:40:17 <sshnaidm> mordred, right
15:40:17 <dtantsur> I suspect tripleo's one don't
15:40:21 <mnaser> we got rid of our legacy ones
15:40:27 <sshnaidm> I'm working on this..
15:40:36 <mordred> cool. well - yes - definitely using sdk as a target
15:40:44 <mordred> for anything we're adopting from other sources
15:40:56 <dtantsur> there may be feature gaps to cover, I'll gladly help on ironic/ironic-inspector side
15:41:20 <sshnaidm> #topic Common part in all modules like authentication, ironic service URLs, etc
15:41:38 <sshnaidm> I think it's for all modules, not Ironic only
15:41:44 <gtema> just checked - current modules are all using SDK
15:41:53 <gtema> (ironic ones)
15:41:55 <dtantsur> I feel very strongly that we should only support standard keystoneauth stuff, nothing else, no "ironic_url" or anything
15:41:56 <mordred> oh - speaking of reworking some of the common bits ... I had an idea a little while ago for a way to make a base class we can use in each module that should reduce boilerplate and copy/pasta - I'll push up a review as soon as we've got the initial import into gerrit
15:42:01 <mordred> dtantsur: ++
15:42:40 <sshnaidm> in ansible we have now openstack.py in common/
15:42:42 <gtema> so we agree to go for collections and importing them into OpenStack?
15:42:51 <sshnaidm> that takes care about auth
15:42:54 <mnaser> +1
15:42:54 <mordred> gtema: yah
15:42:58 <mordred> sshnaidm: ++
15:42:59 <dtantsur> gtema: under ansible SIG, not under openstack official
15:42:59 <noonedeadpunk> +1
15:43:01 <gtema> wow, that's cool
15:43:23 <gtema> what I mean - where is hosted, and not how "branded"
15:43:26 <mordred> gtema: yeah - I think it's going to make it much easier to deal with
15:43:32 <gtema> definitely
15:43:37 <dtantsur> ++
15:43:40 <mnaser> tbh i will likely do a lot more reviews
15:43:42 <mnaser> than having my inbox spammed
15:43:45 <mnaser> with github emails.
15:43:47 <mordred> ++
15:43:52 <gtema> my first activity would be to replace this openstack.py from module_utils
15:44:07 <gtema> to something not causing naming conflict ;-)
15:44:09 <sshnaidm> and we'll need to remove them from ansible? just curios about namespaces conflicts
15:44:12 <mordred> gtema: yes - it needs a rewrite
15:44:31 <mordred> sshnaidm: I think the idea is that we'll remove the old ones from ansible later
15:44:40 <gtema> I did a collection for my org modules and will be able to bring changes here then
15:44:41 <mordred> with collections, we'll be installing the openstack collection into a namespace anyway
15:44:49 <mordred> so one would imagine that the module will be openstack.server instead of os_server
15:44:51 <mordred> or something
15:45:01 <gtema> totally
15:45:02 <sshnaidm> mordred, ack
15:45:35 <dtantsur> if we're not official here, are we allowed to use openstack.<whatever>?
15:45:36 <mordred> gtema: my comment earlier - if you want to ponder it - is in opnestack.py instead of the functions we've got for making the cloud objects - make a subclass of AnsibleModule that we use in the modules themselves
15:46:02 <mordred> gtema: that way we can make a self.conn, for instance, and not need to pass sdk and conn and all of that around all the time
15:46:04 <gtema> yes, sure
15:46:23 <mordred> dtantsur: I think we are official enough from the ansible community perspective
15:46:49 <mordred> like - while we might not be an official deliverable of the openstack project, we are as official as you can get of being the openstack collection for ansible
15:47:00 <gtema> and what is the "idea" with license? (sorry, got here bit late)
15:47:05 <mordred> so I think it's ok for us to squat the openstack namespace
15:47:14 <sshnaidm> ok, let's move on
15:47:20 <mordred> gtema: that's one of the reasons its'a . sig project not an openstack one
15:47:38 <sshnaidm> gtema, it's gpl vs apache
15:47:40 <mordred> because the code is all gpl at the moment, and relicensing would be almost impossible at this point
15:47:45 <gtema> yeah, but with which license header would we maintain them?
15:48:00 <gtema> ah, so leave them as is?
15:48:01 <mordred> I think just stick with gpl - since it's ansible and that's what the codebase already is
15:48:03 <mordred> yeah
15:48:09 <gtema> ok
15:48:13 <mordred> anythign else is just a ton of stress for no gain :)
15:48:36 <sshnaidm> or to write everything from scratch with apache lic
15:48:45 <sshnaidm> but I don't suggest that :D
15:48:46 <gtema> then what are we doing with what guys expressed - how are we going to "deprecate" upstream modules?
15:49:55 <sshnaidm> gtema, I think we don't know yet :)
15:50:07 <dtantsur> I think it's up to ansible to decide
15:50:16 <sshnaidm> agree
15:50:19 <dtantsur> according to their policies etc
15:50:28 <gtema> I know that we don't know. But immediately the moment we import modules we are in trouble of "sync"
15:50:32 <dtantsur> our job is to let them know when we're done with stabilizing and covering feature gaps
15:50:45 <noonedeadpunk> Let's cross that bridge when we come to it
15:51:05 <sshnaidm> gtema, we'll have own modules with openstack or whatever namespace
15:51:12 <gtema> heh? We can agree on "stopping" merging any changes upstream
15:51:16 <sshnaidm> it will be different modules
15:51:37 <sshnaidm> gtema, changes to upstream ansible modules you mean?
15:51:41 <gtema> yes
15:51:56 <jrosser> there are two different things maybe "get OSA / tripleo passing tests using the new collection" vs. "use the new collection to hack on the modules"
15:52:02 <noonedeadpunk> I think we will have collections anyway. I'm not ssure ansible folks will convert openstack modules into collections with their own
15:52:31 <sshnaidm> gtema, I think it's a point to discuss with ansible core team when we move them
15:52:32 <jrosser> from a stability point of view for end users we need to be able to test and show that this stuff works
15:52:45 <gtema> for sure not. But when we import current state of ansible modules into collections we become responsible for keeping things in sync and providing "migration" strategy
15:52:54 <mordred> so ... *we* are the ansible folks converting the openstack modules to a collection
15:53:04 <gtema> ++
15:53:05 <mordred> like, we're already the owners of the in-tree modules
15:53:28 <mordred> so what we do with those is add some deprecation notices once we have a collection people can install instead
15:53:41 <mordred> then we keep the old ones around on life-support for a bit to give people a chance to move over
15:53:54 <mordred> then eventually delete from ansible/ansible when proper deprecation time has passed
15:54:02 <gtema> agree, but would be nice to agree on "merge-freeze" between us
15:54:05 <mordred> ++
15:54:07 <mordred> yes
15:54:09 <sshnaidm> mordred, sounds as a plan
15:54:21 <mordred> luckily we only need to agree on the merge-freeze with ourselves :)
15:54:24 <sshnaidm> mordred, I think you can merge there to community OS modules, right?
15:54:33 <mordred> yup. and gtema and mnaser
15:54:59 <mordred> we can add other people to that list, if it's helpful to manage the transition
15:55:08 <sshnaidm> ok, so let's agree here :) and afaik you're all added automatically to reviewers for every patch in GitHub for os modules
15:55:19 <mordred> yah - that's right
15:56:10 <sshnaidm> so everybody is agree on merge-freeze for upstream ansible OS modules, right?
15:56:11 <gtema> zuul publishing collection - who will care about that?
15:56:32 <dtantsur> this SIG? or what do you mean?
15:56:35 <mordred> gtema: what do you mean?
15:56:48 <sshnaidm> gtema, do you mean publishing job?
15:56:53 <gtema> we need to write zuul jobs, that will publish collection to galaxy
15:57:12 <mordred> sshnaidm: yeah. although I think we shouldn't merge-freeze in-tree until there is an installable published collection that we've done all the breaking changes to that we want to do
15:57:20 <sshnaidm> do we need to publish them to galaxy?
15:57:21 <dtantsur> I suspect we might have them already for openstack-ansible, no?
15:57:29 <mordred> gtema: I can/will definitely help with that
15:57:32 <dtantsur> sshnaidm: won't hurt I guess? to have some official artifacts?
15:57:39 <sshnaidm> mordred, agree
15:57:41 <mordred> publishing collections is different than old galaxy modules
15:57:43 <gtema> oki
15:57:52 <mordred> it's more like publishing to pypi - you actually publish a tarball to a location
15:57:56 <mordred> which is great
15:57:56 <gtema> yeah, and it's really weird process
15:57:57 <dtantsur> I can help with zuuling as well, I have some experience with writing jobs
15:58:03 <mordred> cool
15:58:17 <sshnaidm> I write jobs every day, so as well.. :D
15:58:18 <mordred> also - pabelanger has been doing some stuff with zuul and modules and we might can rope him in too
15:59:02 <sshnaidm> great
15:59:31 <sshnaidm> and I'd like to jump to Naming question now
15:59:37 <sshnaidm> #topic Naming: service types vs codenames
15:59:38 <mordred> ++
15:59:39 <dtantsur> we have one minute :)
15:59:50 <dtantsur> can we just answer "service types" and call it done?
16:00:07 <sshnaidm> sure, folks feel free to drop, I'll send minutes after
16:00:14 <mordred> well - one place we might want to change is to also allow service types for "admin" objects
16:00:19 <dtantsur> should we meet on the API SIG hour this THu?
16:00:36 <dtantsur> mordred: I have big problems with the whole "admin objects use codenames" idea
16:00:45 <mordred> there was originally a policy that we do os_server but os_ironic_node as a way to indicate what things were expected for admins and what were expected for end users
16:00:48 <mordred> yeah
16:00:57 <mordred> it's ... antiquated at this point
16:01:08 <dtantsur> ++
16:01:11 <mordred> so I think we should maybe drop that part as we rename in collections
16:01:14 <sshnaidm> dtantsur, seems like we really have topics to discuss, so I'm for that
16:01:15 <dtantsur> I *highly* want to do os_baremetal
16:01:19 <mordred> similar to the dropping of OperatorCloud object
16:01:26 <mordred> dtantsur: ++
16:01:33 <gtema> ++
16:01:36 <dtantsur> great!
16:01:41 <mordred> maybe for the thu sig we should tee up a list of proposed new names for things?
16:01:47 <dtantsur> ++
16:01:53 <sshnaidm> mordred, yeah, good idea
16:01:56 <dtantsur> mordred: I did https://etherpad.openstack.org/p/ironic-ansible-modules for ironic
16:02:16 <dtantsur> it's not a straight rename though, rather a rework
16:02:28 <mordred> I think that's fine
16:02:39 <mordred> collections are different enough that I think this is the time to apply lessons learned
16:02:59 <gtema> totally
16:03:12 <mordred> sshnaidm: I have this extra crazy idea - but I think tripleo might have the use case that makes it a bad idea ...
16:03:35 <sshnaidm> mordred, which one?
16:03:57 <gtema> why have you asked :DDDD
16:04:07 <mordred> the extra crazy idea is to rework all of the modules to be action plugins so that they run on the host you're running ansible on - rather than normal modules so they run on the remote host - since installation of library depends is frequently very confusing for people
16:04:10 <sshnaidm> was it a trap? :D
16:04:27 <mordred> but - I think tripleo might make use of the remote exection nature of the exixting normal modules
16:04:48 <gtema> I am also sometimes executing things remotely,
16:04:56 <gtema> while I agree - it's a nightmare
16:05:23 <sshnaidm> I'm not sure why to limit it though..
16:05:30 <mordred> it would be neat if we could write code that would run the code as an action plugin if hosts: localhost but as a normal ansiballz module if host is remote
16:05:44 <noonedeadpunk> I think in terms of osa we're always delegating stuff to the localhost where openstack modules are used
16:05:52 * dtantsur has to jump on another meeting, still lurking though
16:05:55 <mordred> noonedeadpunk: kk.
16:06:09 <mnaser> yeah we'd pretty much always use that circuit breaker
16:06:10 <mordred> so - this is probably me overthinking and should just shelve it
16:06:16 <mnaser> fyi i think we can use action plugins to do this
16:06:22 <mordred> mnaser: oh yeah?
16:06:28 <mnaser> if we're running locally then do the code locally, if not delegate u
16:06:40 <mnaser> kinda like how the template module is right, its a hybrid of two
16:06:43 <gtema> perhaps use plugin to deploy "clouds.yaml" to ease the execution or smth like that?
16:06:51 <mordred> mnaser: cool - I'll see if I can work up a POC patch for people to look at
16:06:51 <noonedeadpunk> yeah, it was actually more to support your idea mordred :)
16:06:56 <mordred> noonedeadpunk:  :)
16:07:20 <mordred> gtema: yeah - clouds.yaml location is one of the confusing things for people, as is people trying to run a simple task with env vars
16:08:05 <gtema> yeah, and if envs are used, but remote execution is wanted - provision smth on remote
16:08:09 <mordred> so - I've got 2 POC patches to shove up for comment - one for base class AnsibleModule and one for local/remote action plugin
16:08:15 <mordred> gtema: ++
16:08:51 <sshnaidm> mordred, I'd like somebody else from tripleo to take a look at it too
16:08:57 <mordred> sshnaidm: ++
16:09:03 <sshnaidm> ok, we're out of time, do you want to continue this Thu or next week in API SIG time?
16:09:18 <mordred> I'll sketch out a half-working patch - hopefully by Thu - so we've got something to point at and mock
16:09:20 <dtantsur> I'd continue this week
16:09:24 <sshnaidm> I think it's pretty hot topic, so I'd vote for this Thu
16:09:25 <dtantsur> to avoid wasting time
16:09:56 <sshnaidm> cool, I'll send the ML then, let's continue this Thu
16:10:05 <dtantsur> ++ thanks sshnaidm
16:10:12 <sshnaidm> thanks to everyone for your participation!
16:10:22 <sshnaidm> #endmeeting