18:00:40 <gundalow> #startmeeting Ansible Community Meeting
18:00:40 <zodbot> Meeting started Wed May 12 18:00:40 2021 UTC.
18:00:40 <zodbot> This meeting is logged and archived in a public location.
18:00:40 <zodbot> The chair is gundalow. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:40 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:40 <zodbot> The meeting name has been set to 'ansible_community_meeting'
18:00:46 <gundalow> Who's here?
18:00:54 <jillr> o/
18:00:55 <tadeboro> o/
18:00:56 <gundalow> #topic Agenda https://github.com/ansible/community/issues/539
18:01:06 <acozine> o/
18:01:08 <gundalow> abadger1999 acozine andersson007_ baptistemm bcoca briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow gwmngilfen ikhan_ jillr jtanner lmodemal misc nitzmahone resmo samccann tadeboro cidrblock thaumos zbr: ping!
18:01:10 <andersson007_> o/
18:01:19 <gundalow> #info Agenda: https://github.com/ansible/community/issues/539 / Topics: https://github.com/ansible-community/community-topics
18:01:28 <abadger1999> Good day
18:01:29 <samccann> only partial.. so not furniture worthy today
18:01:36 <gundalow> samccann: ack
18:01:39 <gundalow> felixfontein: Evening
18:01:52 <gundalow> welcome everyone :)
18:01:57 <dmsimard> got something, will be late and catch up later
18:02:00 <tadeboro> I think Felix is away today.
18:02:11 <gundalow> tadeboro: more people on holiday, crazyness
18:02:12 <gundalow> #topic Updates
18:02:24 <gundalow> Please #info any updates you may have
18:02:52 <gundalow> abadger1999: release info?
18:02:56 <abadger1999> #info ansible 3.4.0, the last ansible 3 release, went out on Tuesday
18:03:11 <abadger1999> #info ansible-4.0.0rc1 was released on Tuesday
18:03:15 <acozine> \o/
18:03:19 <gundalow> #chair jillr tadeboro acozine andersson007_ dmsimard
18:03:19 <zodbot> Current chairs: acozine andersson007_ dmsimard gundalow jillr tadeboro
18:03:36 <abadger1999> #info Barring any blocker bugs, ansible-4.0.0 final will be out next Tuesday, 18, May, 2021.
18:03:47 <gundalow> nitzmahone: You around, I'm going to mention GalaxyNG in a bit
18:03:56 <nitzmahone> #/me lurks
18:04:04 <abadger1999> gundalow: Oh, You didn't chair me so my info's don't count
18:04:09 <gundalow> #chair nitzmahone abadger1999
18:04:09 <zodbot> Current chairs: abadger1999 acozine andersson007_ dmsimard gundalow jillr nitzmahone tadeboro
18:04:16 <gundalow> ah, woops
18:04:17 <abadger1999> #info ansible 3.4.0, the last ansible 3 release, went out on Tuesday
18:04:19 <abadger1999> #info ansible-4.0.0rc1 was released on Tuesday
18:04:22 <abadger1999> #info Barring any blocker bugs, ansible-4.0.0 final will be out next Tuesday, 18, May, 2021.
18:04:29 <abadger1999> Cool :-)
18:04:51 <lmodemal> o/
18:05:00 <gundalow> #chair lmodemal
18:05:00 <zodbot> Current chairs: abadger1999 acozine andersson007_ dmsimard gundalow jillr lmodemal nitzmahone tadeboro
18:06:02 <gundalow> #info Next Contributors summit is Tuesday, June 8th 0700UTC. https://hackmd.io/0lOyfyEpQ1uKimC4mD6xdw Please add topics to the agenda (Login with GItHub to be edit)
18:06:42 <gundalow> #topic Ansible Community Galaxy next steps
18:06:58 <gundalow> #info https://www.reddit.com/r/ansible/comments/na4end/ansible_community_galaxy_next_steps_help_needed/ https://github.com/ansible-community/community-topics/issues/17
18:07:13 <gundalow> #info We're updating galaxy.ansible.com to use GalaxyNG, the code that powers Ansible Automation Hub, because it is well maintained and efficient. Help us make sure your use cases are addressed in this transition!
18:08:10 <gundalow> #info If extra use-cases are identified we will add them to the list. Then we will do a survey to see what the priority is
18:08:26 <gundalow> Anyone had chance to read though this yet (I know there's a lot) any feedback so far?
18:08:41 <gundalow> Please share these links with people, it's important we get feedback
18:09:08 <abadger1999> geerlingguy: ^
18:09:53 <geerlingguy> @abadger1999 - I know I gave an initial pass at one point
18:10:08 <abadger1999> Cool, cool.
18:10:10 <nitzmahone> The doc is lengthy, but the resultant survey will likely be very short- basically we'll propose a few different potential solutions and ask folks to rank them (as well as a free-form "tell us anything else you want us to know" kind of thing)
18:10:23 <geerlingguy> There were a few hand-wavy things in there that I think will lead to some consternation if implemented as-is.
18:10:36 <geerlingguy> For my own part, I'm still far from a point where I'm comfortable moving to collections (for roles, that is)
18:11:09 <gundalow> geerlingguy: Without meaning to put words in your mouth, is your issue cost vs reward?
18:11:17 <geerlingguy> So my #1 concern is that roles still work (and can be updated) the same as today, as far as galaxy requirements.txt and ansible-galaxy cli
18:11:17 <tadeboro> I distributed the link to my team and most of them only gave me back some feedback once I explicitly asked them because no one read the thing through to the end.
18:11:24 <geerlingguy> gundalow: it's convenience
18:11:42 <tadeboro> And at the end is where the CTA is ;)
18:11:51 <geerlingguy> collections (for roles) require more effort to maintain and use
18:11:59 <geerlingguy> On top of that there's still no migration plan
18:12:21 <geerlingguy> e.g. I have geerlingguy.php role today. How do I get users to move to collection... and/or how can I create a collection called geerlingguy.php
18:12:33 <geerlingguy> (since there's already a role with that namespace.name)
18:12:53 <geerlingguy> As a maintainer those are my two main concerns
18:13:14 <tadeboro> geerlingguy: In the galaxyng, there will be no g.php role, so that is one problem "solved".
18:13:28 <zbr> geerlingguy: imho, you should use your github username as namespace, collection is likely php with role php
18:13:36 <geerlingguy> eh... wtf?
18:13:55 <geerlingguy> tadeboro: I thought that was what was said at community summit: roles as we know them will still work in GalaxyNG
18:14:22 <tadeboro> But I think the migration path is highly dependent on how moch "bare" role support galaxyng gets.
18:14:25 <nitzmahone> don't confuse cloud.redhat.com's Automation Hub with the Galaxy NG codebase
18:14:27 <abadger1999> Errr... I think gundalow's document is to establish the features related to roles necessary to implement before migrating to galaxyng..
18:14:49 <geerlingguy> abadger1999: oh... well shoot, that changes the conversation entirely
18:14:51 <gundalow> tadeboro: oh, that's good feedback, I've moved the Call to Action to the top
18:15:06 <geerlingguy> I thought a basic amount of role functionality would be tacked on to GalaxyNG for the codebase transition
18:15:11 <abadger1999> So there will be a geerlingguy.php role in galaxyng?
18:15:25 * geerlingguy is now thoroughly confused
18:15:25 <abadger1999> geerlingguy: Yeah, I'm being unclear.
18:15:26 <nitzmahone> We're not combining those two things, we're just trying to figure out how much role support needs to get added to the Galaxy NG codebase so we can migrate galaxy.ansible.com to it
18:15:31 <nitzmahone> (without breaking the world)
18:15:31 <abadger1999> That's what I think too
18:15:37 <zbr> one thing that seems to not be mentioned often enough is that collections cannot depend on standalone roles, making roles basically something I would personally avoid using because I would not be able to reuse them a building blocks.
18:15:38 <geerlingguy> nitzmahone: ah okay, that was my impression
18:16:10 <gundalow> #chair geerlingguy zbr
18:16:10 <zodbot> Current chairs: abadger1999 acozine andersson007_ dmsimard geerlingguy gundalow jillr lmodemal nitzmahone tadeboro zbr
18:16:15 <geerlingguy> zbr: I try to avoid dependencies as much as possible
18:16:42 <geerlingguy> in roles, collections, etc. Nowadays it's necessary to depend on collections if you don't want to use pip-installed Ansible of course, but that's only an issue for some
18:17:14 <zbr> geerlingguy: is not so much about *your* dependencies, but remember that consumers of your cool roles may be prevented from building a collection that makes use of your roles.
18:17:22 <nitzmahone> --^ that
18:17:25 <geerlingguy> Until 2.9 goes unsupported, my take is basically collections are a nice thing if you need them, but I'm happy to rely on module redirection for the forseeable future
18:17:31 <abadger1999> Present day: galaxyng lacks role support at all.  gundalow's document lays out features of present galaxy versus galaxyng.  Before migration: establish which of the features of present galaxy need to be implemented to  consider that galaxyng "supports roles".  Migrate: After galaxyng implementsthose features essential to hosting roles, we migrate galaxy.ansible.com to the new code base.
18:17:32 <geerlingguy> zbr: that's their problem ;)
18:17:51 <bcoca> zbr: one trivial way around that, include the role as part of your collection build process
18:18:00 <gundalow> awcrosby: We are talking about GalaxyNG
18:18:07 <zbr> geerlingguy: true, i bet they can add your role as a submodule under their collection. it may work for them to build a collection, I think.
18:19:24 <geerlingguy> trying to get a non-collection role working inside a collection can be tricky
18:19:36 <geerlingguy> though rename things properly and it should just work
18:19:55 <gundalow> #chair newswangerd[m]
18:19:55 <zodbot> Current chairs: abadger1999 acozine andersson007_ dmsimard geerlingguy gundalow jillr lmodemal newswangerd[m] nitzmahone tadeboro zbr
18:19:57 <bcoca> mostly if  role includes plugins, not really much diff if you do not
18:20:04 <gundalow> #chair bcoca
18:20:04 <zodbot> Current chairs: abadger1999 acozine andersson007_ bcoca dmsimard geerlingguy gundalow jillr lmodemal newswangerd[m] nitzmahone tadeboro zbr
18:20:32 <bcoca> another caveat, if collection includes conflicting short names
18:20:46 <geerlingguy> I still haven't decided if I want to try to figure out a way to do one insanely-massive "geerlingguy collection" with everything (and live with the consequences), or keep things split up (right now around 80 active repos).
18:20:48 <nitzmahone> bcoca: even then, if the plugins are moved to the collection, the containing collection is first in the resolution list for unqualfied names, so no changes to the role itself should be necessary for that cae
18:21:15 <geerlingguy> Split up means it's easier to keep things separated, testing is easy/simple (and fast). Putting together runs the risk of becoming unmaintainable hell (like Ansible was ;).
18:21:26 <bcoca> nitzmahone: but that is the 'migration path' he is asking for
18:21:42 <bcoca> im not saying these are hard hurdles to get around .. just existing ones
18:21:54 <nitzmahone> geerlingguy: other than grouping separate roles that manage the same "technology", no reason not to just leave them all separate
18:21:54 <geerlingguy> (just noting that none of my roles have plugins)
18:22:05 <geerlingguy> That's where I'm thinking I'll go.
18:22:18 <geerlingguy> There are a few 'bundles' (like all my php-* roles) that would make sense to mash together
18:22:23 <nitzmahone> yep
18:22:31 <bcoca> ^ since there are no plugins there is also little reason for them to migrate to collections
18:22:32 <abadger1999> I think migration of roles into collections might be off topic for this.
18:22:46 <geerlingguy> bcoca: That's my main point for past year or so
18:22:57 <geerlingguy> Collections are amazing, wonderful, cool, neat things for people doing modules/plugins
18:23:02 <nitzmahone> yeah, the original topic was about keeping things working as-is ;)
18:23:02 <bcoca> somewhat tangential, if there awas big incentive to migrate, then galaxyng would not need much support
18:23:02 <abadger1999> I think gundalow is calling for help making sure we've captured all the features that galaxyng will need to implement vis-a-vis role support.
18:23:14 <gundalow> Yup
18:23:24 <geerlingguy> anywho, the point is I think all my initial concerns were wrapped in
18:23:29 <bcoca> and i think we established, we do need full role support
18:23:30 <nitzmahone> noice
18:23:39 <geerlingguy> and main thing is (a) I don't want people's ansible-galaxy install to be broken
18:23:42 <nitzmahone> bcoca: well, "full" is a loaded word ;)
18:23:48 <gundalow> Though identifying any other potental problems is important
18:23:53 <geerlingguy> and (b) I want to still be able to do the ansible-galaxy cli command to trigger a role update
18:24:14 <nitzmahone> yep- we're pretty well committed to making that work
18:24:27 <geerlingguy> everything else is nice to have (but would also be nice to have a page for each role so all my links everywhere still work, e.g. https://galaxy.ansible.com/geerlingguy/php
18:24:41 <gundalow> geerlingguy: so for `a` I expect we will pick some of your roles as test cases
18:24:56 <bcoca> nitzmahone:  - migrate existing ones - allow adding new ones  - allow installing roles from galaxy - display role info - have them searchable  (that is min i can think of, ratings and other stuff ...)
18:24:57 <gundalow> is `b` captured on the use-case list already?
18:26:13 <geerlingguy> hmm...
18:26:29 <geerlingguy> "As an Author I can initiate a Role import from GitHub into Galaxy server (ansible-galaxy role import)"
18:26:44 <geerlingguy> 6.4
18:26:53 <gundalow> (I realise it maybe difficult to tell from a one line sentence)
18:26:56 <bcoca> i imagine that means 'create tgz that galaxy will host as it does with collections'
18:27:01 <awcrosby> i think the ability to see a role's page in the UI is in the UC list, but specifically stating that the same URL should stick around is probably worth noting
18:27:19 <bcoca> current galaxy is a 'ref to github' when it comes to roles, collections are 'full packages'
18:27:22 <nitzmahone> Yeah, "same URL" might be tricky
18:27:26 <gundalow> #chair awcrosby
18:27:26 <zodbot> Current chairs: abadger1999 acozine andersson007_ awcrosby bcoca dmsimard geerlingguy gundalow jillr lmodemal newswangerd[m] nitzmahone tadeboro zbr
18:27:52 <awcrosby> i do have to jump to another meeting shortly tho, but i will read up on the convo
18:27:59 <gundalow> What URL are we referring to here?
18:28:10 <bcoca> awcrosby: yeah, keeping existing uris working is probably something existing authors/users will want
18:28:11 <gundalow> awcrosby: thanks. Meeting is logged, I've share the discussion
18:28:17 <awcrosby> "https://galaxy.ansible.com/geerlingguy/php"
18:28:17 <nitzmahone> The current role "landing page" URL for a given role -> Galaxy NG
18:28:20 <gundalow> I'll*
18:28:45 <gundalow> nitzmahone: Why wouldn't the URL be the same?
18:29:02 <gundalow> can you have role & collection with the same name?
18:29:03 <nitzmahone> Because Galaxy NG routing is much more complex
18:29:12 <bcoca> gundalow: diff code, diff api, so either have to have redirects or add code that behaves like current
18:29:19 <gundalow> ah, thanks
18:29:29 <geerlingguy> gundalow: https://www.reddit.com/r/ansible/comments/na4end/ansible_community_galaxy_next_steps_help_needed/
18:29:35 <nitzmahone> Having a top-level path that is unconstrained is problematic
18:30:18 <gundalow> So we are talking about:
18:30:18 <gundalow> http://galaxy.ansible.com/ansible/posix
18:30:18 <gundalow> https://cloud.redhat.com/ansible/automation-hub/repo/published/ansible/posix
18:30:19 <newswangerd[m]> galaxy ng introduced repositories, so content has to belong to some repository. In other words, the url would be something like galaxy.ansible.com/repo/<reponame>/geerlinguy/php
18:30:34 <nitzmahone> Would be much easier if the current Galaxy things were like (host)/roles/(namespace)/(name), but otherwise you have the potential for collisions with namespaces and internal resource paths
18:30:47 <geerlingguy> nitzmahone: I'm party annoyed by the fact ansible (in general) has a touchy relationship with URL persistence (in docs, repositories themselves, and maybe galaxy in the future)
18:31:00 <geerlingguy> SEO is important for easy to find help / docs / references
18:31:06 <nitzmahone> s/ansible/everything else/ ;)
18:31:20 <geerlingguy> and far too many times in my life I search for something and find 404 or worse, a link to Ansible 2.2 docs or something crazy like that :P
18:31:32 <geerlingguy> Even if the URL doesn't resolve, a redirect would be nice
18:31:33 <newswangerd[m]> i would like to find a way to maintain the role urls, but doing so without collisions will be tricky
18:31:37 <nitzmahone> byproduct of organic growth ;)
18:31:44 <gundalow> geerlingguy: did you mean to post the reddit link, or something else?
18:32:23 <geerlingguy> e.g. if there is no namespace.collection "geerlingguy.php", then ideally if current Galaxy has path /geerlingguy/php then it would redirect to the role page for geerlingguy/php (wherever that is) in GalaxyNG ... something like that
18:32:39 <acozine> geerlingguy: when you hit one of those, please drop a link in hte ansible-docs channel - we do maintain redirects and will do our best with missing ones once we know about them
18:32:48 <geerlingguy> gundalow: you had asked what link I was looking at I think? In terms of 6.3/6.4 being my top two showstoppers
18:32:51 <bcoca> make it fallback? if no collection, check roles, roles go in /roles/ by default (new ones) and this also gives you way to publish collection that overrides role
18:32:55 <acozine> "one of those" == 404 or links to 2.2 docs
18:33:07 <gundalow> geerlingguy: oh, I meant the URL differnce. Sorry I wasn't clear
18:33:09 <geerlingguy> acozine: I have before, and you do good work there. I'm amazed how well the collections transition went :)
18:33:13 <nitzmahone> bcoca: that's some hairy and expensive routing though
18:33:21 <bcoca> yes
18:33:22 <nitzmahone> (potentially)
18:33:24 <geerlingguy> bcoca++ that's my thought
18:33:27 <abadger1999> newswangerd[m]: Does something else already live at that (generic) url?
18:33:36 <bcoca> nitzmahone: but l9ooking at user/author side, most ideal
18:34:00 <newswangerd[m]> the original implementation of galaxyng maintained the same routes as galaxy, but repos broke that
18:34:04 <geerlingguy> nitzmahone: it means I don't have to edit (something like) 5,000 references in books, blog posts, GitHub repos, etc. to point to new path
18:34:19 <bcoca> nitzmahone: also most of that is 'static' since you dont upload/change role/collections every 5 mins .. well, most dont
18:34:28 <geerlingguy> (times that by 50,000 other places where people don't take the time to update things and that's just a bunch of 404s and lost link pagerank)
18:34:40 <abadger1999> ie: $DOMAIN/<namespace>/<rolename>   will collide with $DOMAIN/<namespace>/<collectionname> if someone uploads a collection of the same name?
18:34:49 <nitzmahone> heh, maybe hardcode toplevel "geerlingguy" path only ;)
18:35:10 <bcoca> debops would need it too
18:35:33 <nitzmahone> abadger1999: Yes, that's also a problem, but it depends on how role support is implemented too (eg, first-class or "busted collection")
18:35:59 <geerlingguy> abadger1999: yes, but the idea is take path, if <first_param>/<second_param> matches any "namespace.collection", then don't do anything, if not, check if role exists "namespace.role", if so, redirect by adding /roles/ prefix to url path
18:36:03 <nitzmahone> Those will be part of the survey solution menu
18:36:24 <geerlingguy> not super fun and would add a db lookup but the redirects could be cached for 10 min, 1 hour, something like that
18:36:31 <bcoca> or just move everything under /collections|roles/ and have current uris redirect to 'existing'
18:36:34 <abadger1999> geerlingguy: <nod>  I'm just thinking.... that would mean that anyone who migrates their role into a collection in the future will have to allocate a new name.
18:36:39 <geerlingguy> and the cache could be cleared any time a new collection is added
18:37:06 <abadger1999> geerlingguy: or they will start off using the same name and screw their existing users.
18:37:09 <geerlingguy> abadger1999: yes and no... if we document that the new collection will take over the role name, could work (and could offer an actual migration path assuming other things fall into place
18:37:58 <geerlingguy> Just thinking out loud. Main concern is that I think a lot more people use Galaxy roles than internal data and high-touch enterprise customers suggest
18:38:08 <nitzmahone> We probably don't want to get too far down the path of trying to design this here and now- there are a TON of details around this that we're not going to be able to deal with the nuances of in this meeting
18:38:26 <geerlingguy> True, we still haven't narrowed the list of requirements ;)
18:38:47 <abadger1999> <nod> But this is a big caveat we should be clear about up front.
18:39:06 <geerlingguy> I need to run, but will check backscroll in a bit
18:39:09 <nitzmahone> It's not necessarily a caveat- one of the solutions I've proposed negates this problem, but again, it's premature
18:39:48 <abadger1999> nitzmahone: what's that solution?
18:40:09 * nitzmahone doesn't want to design Galaxy NG role support in this meeting- we can take it offline later if you want
18:40:26 <abadger1999> If it's user visible, it should get discussed here.
18:40:35 <gundalow> geerlingguy: As always, really appreciate your time and feedback
18:40:36 <abadger1999> If it's not user visible, I don't even need to think about it ;-)
18:40:59 <gundalow> Today I'm only interested in user experience
18:41:26 <gundalow> ie UX of user/creator of standalone roles/collections
18:41:46 <nitzmahone> Well, and we're not even at the step of "narrowing requirements"- the current ask is "has everything current been captured"?
18:41:51 <gundalow> We aren't at the stage of implementation details, also that's someone elses problem
18:42:00 <gundalow> yup
18:42:27 <abadger1999> <nod> So I guess there's two possible requirements here:
18:42:30 <nitzmahone> Yes, of course we will discuss publicly when we get to that step, but it's premature IMO
18:42:43 <gundalow> I know (as engineers) it's often difficult to avoid thinking about solutions
18:43:01 <abadger1999> (A) URLs of all roles remain the same in galaxyng.
18:43:38 <abadger1999> (B) URLs of all roles remain the same in galaxyng unless there's a collection which uses the same label (namespace.collectionname is the same as namespace.rolename)
18:44:22 <gundalow> When do people use those URLS, what's the use-case workflow we are thinking about?
18:44:38 <abadger1999> geerlingguy: ^
18:44:59 <newswangerd[m]> those use cases are doable. It won't be perfect. If a namespace name collides with the name of one of our other routes, it will be inaccessible
18:45:22 <newswangerd[m]> *won't be accessible
18:45:33 <abadger1999> newswangerd[m]: That sounds like they might not be doable?
18:45:46 <newswangerd[m]> we don't have very many routes that would cause collisions
18:45:56 <abadger1999> Since inaccessible would mean for practical purposes, the role url is either changed or nonexistent
18:46:29 <nitzmahone> That wasn't part of our initial commitment either- "keeping existing automation working" is the theme. This is a "nice to have" and may or may not be feasible.
18:47:07 <newswangerd[m]> it would only be inaccessible if the namespace name collides with one of our other routes such as imports/, repo/, search/, namespaces/ etc.
18:47:39 <abadger1999> newswangerd[m]: Wouldn't it also be a problem for (A) if namespace.rolename collides with namespace.collectionname ?
18:47:41 <bcoca> those should be 'reserved' namespaces
18:48:05 * bcoca registers import namespace
18:49:08 <nitzmahone> It basically already is a problem, because the paths are the same in current Galaxy
18:49:26 <newswangerd[m]> yeah, I think we block people from creating roles and collections with the same name
18:49:54 <nitzmahone> So it would somewhat depend on what we end up doing, but that's several steps past where we are now.
18:50:27 <abadger1999> newswangerd[m]: Okay, as long as that's in both current galaxy.ansible.com and in galaxyng, then ti think that would be sufficient.  But it will mean that a current role author will have a choose a new name if they migrate to role-inside-collection.
18:51:11 <acozine> could we do a 1:1 transition, with a utility that puts roles in the right "spot" and then converts what was a role into a collection containing that single role?
18:51:20 <nitzmahone> Not necessarily- it depends on how first-class roles are
18:51:22 <abadger1999> acozine: I don't think so.
18:51:42 <acozine> I figured not, but also figured it was worth asking
18:52:26 <abadger1999> I think that othr tooling makes the difference  between roles and collections isible to the end user so there's not a way to transparently switch between the two.
18:53:10 <abadger1999> (But I could be wrong)
18:54:28 <jillr> alt-cyb-clock chimes: 54 minutes into meeting, 48 minutes on "Ansible Community Galaxy next steps"
18:54:29 <abadger1999> nitzmahone: You'll have dip a little closer to implementation if you want to make that case.... Because I don't see how to reconcile "role and collection names cannot conflict" with "you do not have to choose a non-conflicting name when you migrate a role into a role-inside-of-collection".
18:54:41 <gundalow> jillr: :D
18:54:57 <nitzmahone> I will make that case, just not here and now. :)
18:55:04 <nitzmahone> (and already have with other audiences)
18:55:05 <gundalow> Today is about use-case
18:55:54 <gundalow> I have to drop off in a few minutes, is someone else able to run the rest of the meeting, and go through https://github.com/ansible-community/community-topics/issues is there is anything new since last week
18:56:10 <abadger1999> nitzmahone: What's the UX?  If I go to galaxyng.ansible.com/geerlingguy/php it will randomly decide whether to take me to the role page or the collection page?
18:56:20 <gundalow> (which I think is only What to do with inventory and vault scripts in community.general? #16)
18:56:36 <abadger1999> There's only one url so I don't see how there's a UX that reconciles those.
18:56:49 <abadger1999> and ux is definitely on the menu today.
18:57:59 <nitzmahone> #unchair nitzmahone
18:57:59 <zodbot> Current chairs: abadger1999 acozine andersson007_ awcrosby bcoca dmsimard geerlingguy gundalow jillr lmodemal newswangerd[m] tadeboro zbr
18:58:37 <acozine> I have to drop for a meeting with my boss.
18:58:44 * acozine waves
18:58:53 <acozine> #unchair acozine
18:58:53 <zodbot> Current chairs: abadger1999 andersson007_ awcrosby bcoca dmsimard geerlingguy gundalow jillr lmodemal newswangerd[m] tadeboro zbr
18:58:55 <gundalow> acozine: nitzmahone Thanks for your time
18:58:59 <samccann> delurking - can someone sprinkle some #infos on the past discussion? I don't see anything added for the meeting minutes
18:59:17 <abadger1999> newswangerd[m]: Do you know what the UX nitzmahone was talking about is?  because otherwise, I think that your evaluation is correct.... we can only have one or the other, not both.
19:01:26 <newswangerd[m]> abadger1999:  With the current routing we don't allow roles and collections with the same namespace/name combo.
19:01:48 <newswangerd[m]> I think there's a check that prevents users from uploading roles/collections that collide
19:02:07 * abadger1999 figures out what infos we can make without further information from nitzmahone...
19:02:43 <nitzmahone> Why do you need to design it right now? The meeting had a specific ask that was several steps before "design the thing"
19:02:50 <abadger1999> #info Currently we disallow uploading a role or collection whose namespace+name would conflict with another role or collection.
19:03:00 * gundalow has to drop off now.
19:03:01 <nitzmahone> (and the meeting is now over time, yeah?)
19:03:04 <gundalow> Thank you everybody
19:04:00 <abadger1999> #info So when we migrate into galaxyng, there will be no conflicting role and collection names.
19:04:13 <samccann> thanks abadger1999!
19:04:50 <abadger1999> #info geerlingguy requests that we have a requirement for continuity of URLs for roles from the current galaxy to the galaxyng implementation
19:06:20 <abadger1999> #info continuity of URLs doesn't fit easily into the galaxyng architecture but should be possible given that the code enforces non-conflicting namespace+names (as stated previously).
19:07:17 <abadger1999> geerlingguy: I'm goign to assign you an action to add the url requirement to gundalow's doc... if you don't have time, feel free to ping me and I'll try to word something and run it by you for approval
19:07:47 <abadger1999> #action geerlingguy to add the continuity of urls requirement to gundalow's roles in galaxy use case's doc
19:09:18 <lmodemal> Thanks!
19:09:32 <abadger1999> nitzmahone: The ask for this meeting was figuring out use cases.  The requirement that geerlingguy and acrosby were working towards was "Must support the urls to roles that exist in the current galaxy".  If that's not possible, then it's important that we know that it isn't possible.
19:09:58 <abadger1999> This meeting can go for two hours if there's things to cover....
19:10:07 <nitzmahone> It wasn't figuring out use cases for the conversion- it was "is the existing behavior adequately captured in the table"- that's all.
19:10:26 <nitzmahone> Figuring out use cases is going to be a LOOOONG process
19:10:36 <abadger1999> Do people want to go on and talk about https://github.com/ansible-community/community-topics/issues/16 ?
19:10:51 <abadger1999> felixfontein isn't here today, so we could also defr to next week.
19:12:02 <abadger1999> 11:08:11
19:12:02 <abadger1999> <@gundalow> #info If extra use-cases are identified we will add them to the list. Then we will do a survey to see what the priority is
19:12:02 <abadger1999> 11:08:27
19:12:02 <abadger1999> <@gundalow> Anyone had chance to read though this yet (I know there's a lot) any feedback so far?
19:12:02 <abadger1999> 11:08:42
19:12:03 <abadger1999> <@gundalow> Please share these links with people, it's important we get feedback
19:12:24 <abadger1999> Okay, no takers for issue 16, so I'll move to open floor and then close out the meeting
19:12:28 <abadger1999> #topic Open Floor
19:12:54 <abadger1999> Anyone have something not on the agenda that they want to discuss?
19:13:46 <abadger1999> If no one speaks up, I'll close the meeting in 60 seconds
19:14:59 <abadger1999> #endmeeting