15:02:33 <sshnaidm> #startmeeting ansible-sig
15:02:34 <openstack> Meeting started Tue Mar 17 15:02:33 2020 UTC and is due to finish in 60 minutes.  The chair is sshnaidm. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:36 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:38 <openstack> The meeting name has been set to 'ansible_sig'
15:03:06 <sshnaidm> who is available today?
15:03:47 <sshnaidm> mordred, dtantsur|brb tremble cloudnull
15:03:59 <mordred> o/
15:04:04 <sshnaidm> hope all are safe an healthy and can join today
15:04:15 <sshnaidm> and I hope I didn't mess up with timezones and dst
15:04:15 <mordred> sshnaidm: dtantsur|brb is looking at the yellow dot in the key for a minute
15:04:26 <mordred> sshnaidm: if you did I did too :)
15:04:45 <sshnaidm> seems like good job to do in a lockdown :)
15:04:50 <mordred> :)
15:05:08 <sshnaidm> ok, so while people are coming...
15:05:18 <sshnaidm> mordred, let's take the renaming topic?
15:05:33 <sshnaidm> mordred, just did today a few tests with various ansible versions
15:06:14 <sshnaidm> and seems like 2.9 users should rename modules if they want to use collection over 2.9 built-in modules
15:06:25 <sshnaidm> the question is how is that important and critical
15:06:50 <sshnaidm> and if so, can it be workarounded with symlinks or kind of..?
15:07:45 <mordred> sshnaidm: so - I'm going to make a different argument there - which is that i do not think we should support pre-2.10 users in any way
15:07:49 <noonedeadpunk> o/
15:08:01 <sshnaidm> mordred, why?
15:08:02 <mordred> collections is how we deliver these modules to >=2.10
15:08:13 <mordred> if you're using 2.9, you are getting the modules from ansible
15:08:25 <mordred> and we're already supporting you there
15:08:42 <sshnaidm> mordred, well, usually yes, but there are no chances to use new features or merge fixes to 2.8/2.9
15:08:49 <mordred> gundalow: ^^ this might be a topic you have thoughts or feelings on
15:09:16 <mordred> sshnaidm: that's right - but this has been true for all of ansible - we're fixing it with collections - but it's a new feature of 2.10
15:09:32 <sshnaidm> mordred, collections are in use from 2.8 including
15:09:45 <mordred> oh?
15:09:51 <sshnaidm> mordred, and in general there are no limitations to use them from 2.8
15:09:52 <mordred> ok - maybe I'm wrong here then
15:10:19 <sshnaidm> mordred, yeah, you can easily use them, just configuring openstack.cloud.os_server etc
15:10:22 <mordred> so people with ansible 2.8 can do ansible-galaxy collection install openstack and then put openstack.cloud.blah in their playbook and it all works?
15:10:24 <mordred> cool
15:10:28 <sshnaidm> mordred, yep
15:10:36 <mordred> ok - then I agree - we should test 2.8 and 2.9 too :)
15:10:38 <sshnaidm> mordred, that's why I do these 2.8 2.9 jobs :)
15:10:53 <mordred> kk. I understand and agree now then :)
15:10:58 <sshnaidm> mordred, great
15:11:13 <mordred> (I still disagree on the mechanism - but that's just code-review :) )
15:11:18 <sshnaidm> mordred, so back to renaming though, and how it affects (if does)
15:11:26 <mordred> yeah ... so - here's my thing
15:11:32 <mordred> (and I might be wrong on this too obvs)
15:11:34 <sshnaidm> mordred, yeah, I'm mostly trying there, would be glad for ideas in jobs
15:12:13 <mordred> if you're installing collection yourself, you already need to add openstack.cloud into the name in your playbook - so it's no different to do openstack.cloud.server vs openstack.cloud.os_server
15:12:23 <mordred> it's a change either way
15:12:46 <mordred> for people using just os_server via ACD - the routing.yml is the thing that's making that work
15:13:07 <mordred> and since that lets us point os_server -> openstack.cloud.server - I see no reason for us to keep the os_ prefix on our module names
15:13:13 <mordred> is there something else we should be worried about?
15:13:55 <mordred> https://github.com/ansible/ansible/pull/68215/files <-- change to the routing.yml in ansible/ansible FTR
15:14:24 <sshnaidm> mordred, first thing that I didn't like, first case in http://paste.openstack.org/show/790784/
15:14:39 <sshnaidm> mordred, when you set up collection in playbook level
15:14:49 <sshnaidm> mordred, then you override system modules by collection one
15:14:57 <mordred> ah - nod.
15:15:04 <mordred> so - I mean - maybe don't do that? :)
15:15:05 <sshnaidm> and instead of system "user" we run actually os_user
15:15:30 <sshnaidm> mordred, well, yeah.. but interesting how many people will yell :)
15:16:10 <mordred> I mean - I guess it's maybe just me - but it seems to be a real shame to introduce namespacing and then still pretend it's not there and keep the modules in the namespace behaving as if there is a single global namespace
15:17:09 <mordred> a user is also really unlikely to have a single play where they are making a local os level user and an openstack user too ... and if they had one of those, doing collection: openstack.cloud on that play seems like a bad practice?
15:17:20 <mordred> but - I mean - I hear you ... so I think this is a good one to get other input
15:17:31 <sshnaidm> mordred, I'm just not comfortable with such a ambiguity, what module will run
15:17:47 <mordred> I'm still in favor of renaming and warning people - but I won't revolt if everyone else thinks it's too much
15:17:49 <sshnaidm> and I suspect users can surprise us
15:18:22 <sshnaidm> mordred, maybe we can rename modules but prevent names overlapping with core modules?
15:18:23 <mordred> I mean - it's _not_ abiguous. the user said "collection: openstack.cloud" - they get openstack.cloud.user
15:18:28 <mordred> hrm
15:18:41 <mordred> that's maybe a good compromise
15:18:51 <mordred> is it anything other than user that's an issue?
15:19:03 <sshnaidm> mordred, yeah, and I don't think we have a lot of such.. can't think now about others
15:19:16 <sshnaidm> maybe it's only user
15:19:42 <mordred> so - we could call that one keystone_user and still be within the scope of sanity
15:19:52 <mordred> (it's mostly an admin thing to use anyway)
15:19:56 <sshnaidm> mordred, and "group"
15:20:14 <sshnaidm> mordred, yeah, seems like a plan
15:20:31 <sshnaidm> mordred, also it's more explaining, like which user exactly
15:21:12 <mordred> yeah. same - keystone_group - maybe we should name project keystone_project too - just for consistency for people doing a lot of keystone things?
15:21:24 <sshnaidm> mordred, yep
15:21:34 <sshnaidm> also coming back to best naming of modules
15:21:43 <sshnaidm> mordred, not only removing os_
15:22:02 <sshnaidm> but have them "service" based?
15:22:10 <mordred> well - I think we should mostly avoid that
15:22:12 <sshnaidm> I think we talked with dtantsur|brb about that
15:22:26 <mordred> (except for when something like keystone makes it make more sense)
15:22:38 <mordred> biggest example of why is floating_ip
15:23:11 <sshnaidm> mordred, it may make sense if there is only one service responsible for that
15:23:11 <mordred> it started life as a nova resource and is now a neutron resources - the end user doesn't care either way and our module works with both
15:23:23 <sshnaidm> yeah, agree
15:23:50 <mordred> so - in general - the service name doesn't tend to add much value
15:23:55 <mordred> but - there's definitely times when it's better
15:24:25 <sshnaidm> I think we wanted to rename ironic to "baremetal"?
15:24:27 <mordred> we might just have to make group judgement calls :)
15:24:35 <mordred> ah - yeah
15:24:36 <sshnaidm> mordred, yeah, totally
15:24:37 <mordred> hrm
15:24:47 <mordred> should we do identity_user instead of keystone user?
15:25:15 <sshnaidm> I don't know if there are other services manage identities
15:25:23 <sshnaidm> could be such?
15:26:10 <sshnaidm> if yes, then maybe identity_user is better
15:26:31 <sshnaidm> or project_user
15:26:59 <mordred> well, project_user wouldn't be quite right - because you need to map a user to a project with a role
15:27:11 <sshnaidm> well, naming stuff may take the whole day, I'd propose to get more people involved in your review and decide there
15:27:37 <mordred> yeah. and I agree - we can make comments on individual renames and get specific ones (like user) migrated to what we want it to be
15:27:45 <mordred> and then I'll update that ansible PR once we're happy
15:28:03 <sshnaidm> if we are good with 2.9/2.8 users to be more careful, I'm fine with renaming
15:28:16 <sshnaidm> mordred, yeah, agree
15:28:51 <sshnaidm> mordred, and more careful I mean the third case: http://paste.openstack.org/show/790784/
15:29:11 <sshnaidm> when you set openstack.cloud in playbook level but still use "os_user"
15:29:25 <sshnaidm> you'll get your old 2.9 module, not from collection
15:29:45 <sshnaidm> but this seems to me like a pure misconfiguration issue
15:29:47 <mordred> yeah - that one I think is on them
15:29:49 <mordred> yup
15:30:02 <mordred> you opted in to the new thing - you took action - and then you did it wrong
15:30:19 <mordred> (also - the old os_usr will probably still work anyway :) )
15:30:33 <sshnaidm> yeah, mostly
15:30:36 <mordred> so it would only be an issue if they're trying to get a new feature - so they'd hopefully figure it out
15:30:47 <sshnaidm> mordred, yep, agree
15:30:56 <sshnaidm> ok, so we're cool with that I think
15:31:08 <sshnaidm> moving on
15:31:19 <sshnaidm> jobs matrix that I'm working on it currently
15:31:40 <mordred> yeah- so - I'll update my most recent comments there based on this
15:31:47 <sshnaidm> are any objection to support 2.8, 2.9, devel on openstacksdk from rocky?
15:31:54 <sshnaidm> mordred, cool
15:32:14 <sshnaidm> mordred, I'll take a look at siblings, wasn't familiar with it
15:32:15 <mordred> well - one facet
15:32:35 <mordred> sshnaidm: it's the magic that handles "I want to install this dependency from source"
15:32:46 <mordred> just requires the project in question be in required-projects
15:33:17 <mordred> sshnaidm: I pushed up https://review.opendev.org/#/c/713461/ as a stab at reworking what we have now a little bit - it might be a good example to build your matrix on
15:33:19 <sshnaidm> great, it's what I was looking for..
15:33:30 <sshnaidm> mordred, ack
15:33:31 <mordred> sshnaidm: so - one thing on the matrix
15:34:00 <mordred> nah - nevermind. let's see how it goes :)
15:34:06 <sshnaidm> mordred, btw, about 2.8 - we need 2.9 minimum to build and install the connection, you can't do it with 2.8 but you can USE collection with 2.8
15:34:20 <sshnaidm> mordred, so 2.8 is kinda special case
15:34:24 <mordred> JEEZ
15:34:29 <sshnaidm> nice, ah
15:34:33 <mordred> so - maybe ...
15:34:56 <mordred> maybe it's not super important to test with 2.8 directly - we're not really doing things where ansible internals changes should impact us at all
15:35:18 <mordred> so maybe just testing that our collection works with 2.9 is good enough to test that the concept of pre-2.10 is working
15:35:47 <mordred> broadly we also need to test sdk against 2.8 and 2.9 - because that's a combo that users will hit - but that's not a collections thing
15:36:02 <sshnaidm> mordred, maybe, but we use it heavily in tripleo, especially in train, and I wanted to be covered there in case we'll want to use collections in train
15:36:12 <sshnaidm> mordred, I mean 2.8
15:36:36 <sshnaidm> mordred, I will add job for each stable branch in openstacksdk when they're ready
15:36:40 <mordred> nod. ok. well - it'll be "fun" to get that built
15:36:44 <mordred> oh - you know what?
15:36:53 <mordred> this is actually going to be easy :)
15:37:11 <mordred> the tox -ebuild command builds the collection - but it's something called in the ci setup script
15:37:16 <mordred> it knows nothing about siblings
15:37:44 <mordred> (because it's not the zuul role invoking tox)
15:37:53 <mordred> so it'll build even for 2.8
15:38:00 <mordred> using latest ansible release - which is good
15:38:10 <sshnaidm> mordred, it installs requirements from test-requirements.txt
15:38:17 <sshnaidm> and we have ansible there
15:38:35 <mordred> yup
15:38:35 <sshnaidm> mordred, but wouldn't this "ansible" in test-requirements.txt conflict with "siblings"?
15:38:38 <mordred> nopt
15:38:44 <mordred> it's a completely different virtualenv
15:38:51 <mordred> it's actually just going to DTRT
15:39:21 <sshnaidm> great, then it will be easier
15:39:31 <mordred> oh - so - the siblings code needs ansible to be in test-requirements - it doesn't install _everything_ in required-projects - only things that the project's tox would have installed naturally without siblings
15:39:42 <sshnaidm> mordred, because ansible-test for linting is also available from 2.9 at least
15:39:48 <mordred> the idea is that you acn have a tox setup that expresses real release depends
15:40:15 <mordred> but then have zuul jobs that test that against source checkouts too
15:40:44 <mordred> yeah - I think we can just do linting with latest - it'll be the most comprehensive
15:41:19 <mordred> so you don't need the stable-2.9 in those jobs
15:41:20 <sshnaidm> mordred, so, should I add "openstack" to test-requirements.txt as well?
15:41:24 <mordred> openstacksdk
15:41:27 <mordred> yes - but I did that in mine
15:42:08 <mordred> sshnaidm: I'll go back through and re-review your patch and try to point out some better/easier ways to accomplish what you're trying to do
15:42:22 <mordred> now that I fully understand :)
15:42:34 <sshnaidm> cool, thanks a lot
15:43:02 <sshnaidm> also need to reduce duplications with jobs parenting, but this I know to do :)
15:43:27 <sshnaidm> great, so we're good on this too
15:43:41 <sshnaidm> any other issues, questions, topics
15:43:46 <mordred> woot! omg - a useful meeting
15:43:49 <mordred> that almost never happens :)
15:44:00 <sshnaidm> yeah!
15:44:11 <sshnaidm> that's how meetings should be done :)
15:44:32 <sshnaidm> point to think about it in a virtual summit :)
15:45:14 <mordred> yeah. ugh
15:45:17 <sshnaidm> ok, so if no topics, we are fine
15:45:20 <mordred> stupid virus
15:45:22 <sshnaidm> #endmeeting