18:00:24 <felixfontein> #startmeeting Ansible Community Meeting
18:00:24 <zodbot> Meeting started Wed Aug 31 18:00:24 2022 UTC.
18:00:24 <zodbot> This meeting is logged and archived in a public location.
18:00:24 <zodbot> The chair is felixfontein. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
18:00:24 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:24 <zodbot> The meeting name has been set to 'ansible_community_meeting'
18:00:24 <felixfontein> #topic Agenda https://github.com/ansible/community/issues/645
18:00:24 <felixfontein> 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:00:28 <felixfontein> #info Agenda: https://github.com/ansible/community/issues/645 / Topics: https://github.com/ansible-community/community-topics
18:00:31 <felixfontein> #topic Updates
18:00:46 <samccann> o/
18:00:49 <felixfontein> #chair samccann
18:00:49 <zodbot> Current chairs: felixfontein samccann
18:00:58 <cybette_> o/
18:01:04 <gotmax[m]> .hello gotmax23
18:01:06 <zodbot> gotmax[m]: gotmax23 'Maxwell G' <gotmax@e.email>
18:01:10 <felixfontein> #chair cybette_ gotmax[m]
18:01:10 <zodbot> Current chairs: cybette_ felixfontein gotmax[m] samccann
18:01:17 <acozine> o/
18:01:32 <felixfontein> #chair acozine
18:01:32 <zodbot> Current chairs: acozine cybette_ felixfontein gotmax[m] samccann
18:01:50 <cybette_> #info The next Ansible Contributor Summit will be on October 17, 2022! Check out the topics we have tentatively so far, comment on them and propose your own: https://hackmd.io/@ansible-community/cs202210-planning
18:02:05 <cybette_> #info The event will be hybrid, so you can join in person or online. Please register here: https://ansiblecs202210.eventbrite.com/?aff=matrix
18:02:08 <mariolenz[m]> o/
18:02:30 <felixfontein> #chair mariolenz[m]
18:02:30 <zodbot> Current chairs: acozine cybette_ felixfontein gotmax[m] mariolenz[m] samccann
18:02:32 <gotmax[m]> Tracker free link: https://ansiblecs202210.eventbrite.com/
18:02:42 * felixfontein can never remember whether he already registered or not...
18:03:16 <felixfontein> according to my mails, I already did
18:03:36 <cybette_> felixfontein: you have registered, thanks!
18:03:54 * acozine registers
18:04:15 <gotmax[m]> So far, there's been no response to https://github.com/ansible-community/community-topics/issues/131
18:04:42 <andersson007_> o/
18:04:45 <cybette_> thanks acozine !
18:04:47 <felixfontein> hmm, actually I totally missed that topic
18:04:51 <felixfontein> #chair andersson007_
18:04:51 <zodbot> Current chairs: acozine andersson007_ cybette_ felixfontein gotmax[m] mariolenz[m] samccann
18:05:38 <andersson007_> gotmax[m]: i've just prolonged the end date:)
18:06:13 <felixfontein> oh, thanks :)
18:06:20 <gotmax[m]> #info andersson007_ is collecting questions for Legal at https://github.com/ansible-community/community-topics/issues/131
18:06:38 <briantist> o/
18:06:40 <gotmax[m]> #link https://github.com/ansible-community/community-topics/issues/131
18:07:13 <gotmax[m]> The main thing is:
18:07:13 <gotmax[m]> #link https://github.com/ansible-community/community-topics/issues/126
18:07:42 <gotmax[m]> But I'm not sure the community has decided how to approach this or what exactly we want to ask
18:07:56 <andersson007_> gotmax[m]: thanks for highlighting it and reminding about it
18:08:07 <gotmax[m]> Sure :)
18:08:09 <gotmax[m]> #chair briantist
18:08:09 <zodbot> Current chairs: acozine andersson007_ briantist cybette_ felixfontein gotmax[m] mariolenz[m] samccann
18:09:12 <cybette_> gotmax (He/Him): the tracking links provide us with aggregate numbers of registrations with each source, but do not specify which individual has registered with which link. you don't have to use it of course, but it's useful to help us know which channels of communication work best for our community
18:10:08 <gotmax[m]> cybette: Thanks for clarifying how the data is used. I guess I just have tracker phobia ;).
18:10:45 <gotmax[m]> The main problem in my book is how removing the tests from collections impacts the `ansible` package
18:11:05 <acozine> I appreciated the untracked link, it's the one I've distributed to a colleague who is attending Fest this year for the first time.
18:11:28 <felixfontein> gotmax[m]: do you mean tests specifically, or as a placeholder for any other content that could be removed (like docs, CI config files, gitignores, ...)?
18:11:38 <cybette_> gotmax (He/Him): no problem, I dislike trackers in general myself, and made sure this was actually useful and not unnecessary tracking. but as said, there's no obligation to use it.
18:12:25 <felixfontein> cybette_: I wish more folks would share your view on that... at $job folks always want to track everything in full detail, even though I'm pretty sure that most of the time the data will not be used...
18:12:42 <gotmax[m]> felixfontein: From a technical perspective, I don't like removing the tests, because it makes it difficult or impossible to run {unit,sanity,integration} tests on the package as a whole.
18:13:10 <gotmax[m]> From a legal perspective, that's another question.
18:13:38 <gotmax[m]> I proposed getting the sources from the SCM repository instead of galaxy, but I'm not sure how feasible that is.
18:13:38 <felixfontein> indeed.
18:14:13 <felixfontein> maybe we should publish the tests as another PyPi package, ansible-tests (we should not use that name, but I can't think of a better one in this moment), and allow to install them with `pip install ansible[tests]`
18:14:35 <gotmax[m]> We can get the repository url from the Galaxy URL, but that won't work for irregular repository structures that have the collection in a subdirectory. And, we'd still have to code that...
18:14:45 <gotmax[m]> *Galaxy API
18:15:00 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:15:02 <felixfontein> though I wonder what kind of legal implications that would have, and also whether pip actually likes two packages installing into the same directory tree...
18:15:40 <felixfontein> fetching the sources from SCM involves a lot of trust that you can actually get the real sources of the collection build from there
18:15:59 <felixfontein> I would really like to be able to download both the built package and the source package for a collection from galaxy...
18:16:15 <cybette_> felixfontein: yeah, I have regular discussions with marketing on removing unnecessary tracking :P
18:16:21 <felixfontein> then we can in turn build a source and release version of ansible
18:16:26 <gotmax[m]> Me too
18:17:02 <gotmax[m]> Collection maintainers are supposed to tag releases, so if they don't do that, that's their problem in my view.
18:17:02 <felixfontein> cybette_: I can imagine...
18:17:29 <mariolenz[m]> I guess the problem is that there's is no guarantee that the package released on Galaxy really corresponds to the git repository.
18:17:39 <felixfontein> gotmax[m]: I'm not sure whether it's their problem from a legal point of view...
18:17:44 <felixfontein> mariolenz[m]: exactly...
18:18:01 <felixfontein> and even if they tagged something, it is not clear whether that's actually what was used to build the galaxy tarball
18:18:41 <mariolenz[m]> gotmax (He/Him): Collection maintainers are supposed to do so many things (a lot of them) don't do, and at the end of the day it's our problem.
18:18:47 <gotmax[m]> felixfontein: I don't think this is a problem. Anyone can ship "binaries" as long as they follow the license terms.
18:19:48 <gotmax[m]> FWIW, shipping, packaging, and supporting other OSS software is core to RH's business model. It's done all of the time by them and others.
18:20:03 <felixfontein> gotmax[m]: I hope you're right
18:20:33 <gotmax[m]> mariolenz: I'm not sure how much I share this view. I guess it depends on if it's affecting users.
18:23:23 <felixfontein> I wonder who's actually legally responsible for the ansible releases, in case 'we' screw something up... I guess it is RH somehow?
18:23:57 <felixfontein> (so far all ansible releases have been made by RH employees)
18:24:01 <gotmax[m]> For the collections that we package in Fedora, we download whatever is tagged in Git. If collection maintainers are tagging one thing as 1.0.2 in git and then pushing something else to Galaxy as 1.0.2, that's a bigger problem in my book.
18:25:45 <felixfontein> it definitely is... for community.* collections that should not happen, though it still can (since you can delete tags, push another commit as the same tag, but once the collection is published for a version it won't be published again - so you can change the tag after the release)
18:27:04 <felixfontein> for other namespaces, collections might be built manually, and then a lot more can happen...
18:27:04 <gotmax[m]> Yeah, that's true. I think this was one of the reasons they changed the way that Galaxy releases are handled between roles and collections.
18:27:46 <gotmax[m]> Roles are downloaded from git; collection tarballs are stored on Galaxy/AH/whatever.
18:27:49 <felixfontein> one big reason for changing it is also that you do not have this coupling between GH and Galaxy, and thus can also have AH and private galaxy_ng instances :)
18:28:23 <felixfontein> I don't know which was the main motivation behind this, but both points are high on the list I would say
18:28:40 <gotmax[m]> Yeah, I don't like that Galaxy requires Github for roles or for auth.
18:28:56 <jtanner> in addition to proper tagging, the content (including galaxy.yml) in the repo should reflect what was actualy used to build the tarball. Intermediate artifacts/files generated during release that don't end up in the repo or the tag are an antipattern imo.
18:29:35 <mariolenz[m]> felixfontein: The question who is legally responsible isn't easy to answer. You see, in the US the packager might be legally responsible, but not in the EU... or vice versa.
18:29:42 <felixfontein> jtanner: I fully agree
18:30:00 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:30:08 <felixfontein> mariolenz[m]: I know, that makes it even more... I guess a lawyer would say interesting :)
18:30:58 <jtanner> galaxy is coupled to github for content and auth, because galaxy was originally intended to be nothing more than an index of github for social purposes and growth hacking
18:31:24 <jtanner> artifact storage is a new thing with collections and breaks the mold of galaxy's original intent
18:31:34 <jtanner> so it's a mixed bag
18:31:46 <felixfontein> interesting, I wasn't aware of galaxy's origin
18:31:47 * gotmax[m] promises not to go on a rant about Github's role in the FOSS community
18:32:01 * bcoca makes no such promise
18:32:22 <felixfontein> :)
18:32:50 <bcoca> once galaxy_ng code is generalized to handle roles and takes over galaxy.ansible.com you can decouple from github quite a bit
18:33:33 <jtanner> the changes i've made to galaxy_ng for replacing galaxy are restoring github auth and github indexing of v1 roles ... i -think- we'll have a way to retain django based auth, but it's still going to be github auth primarily. This is probably off topic for this mtg though
18:33:33 * felixfontein is looking forward to that
18:33:35 <bcoca> right now both old galaxy and galaxy_ng code handle diff parts of the site, why you get some disparate behaviours
18:33:42 <mariolenz[m]> It's never a good sign if a lawyer says "interesting", sounds costly. Probably the only thing worse is if your physician says it.
18:34:09 <bcoca> jtanner: afaik that was the first step, but eentually have roles as artifacts, just like collections
18:34:21 <felixfontein> mariolenz[m]: only if the physician is using that word when talking about you.
18:34:42 <bcoca> but jtanner actually works on it, so his word should be considered more authoritative than mine
18:34:44 <mariolenz[m]> That's what I meant ;-)
18:34:53 <jtanner> at this point, v1 roles will always be an index. storing them as artifacts (the pulp way) breaks many of the role conventions, such as roles that don't have versions can't go into pulp
18:35:20 * bcoca is probably 2 chapters behind
18:35:31 <felixfontein> are there v2 roles?
18:35:34 <jtanner> no
18:35:35 <felixfontein> when you mention v1 roles
18:35:42 <jtanner> v2 is collections, which can contain roles
18:35:47 <bcoca> not v2, but v2 requriements for galaxy , would require semantic versioning
18:35:51 <gotmax[m]> So, I guess we should make a decision.
18:35:51 <gotmax[m]> 1.  Leave it as is.
18:35:51 <gotmax[m]> 2. Remove unnecessary files from the tarballs, download the sources from SCM, run ansible-galaxy build/install on them, and put them together.
18:35:51 <gotmax[m]> 3. Some other creative idea.
18:35:59 <jtanner> galaxy_ng has historically only been v3 (aka collections), but i am adding v1 for roles
18:36:29 <bcoca> now we are getting too many Vs .. i was not refering to the api
18:36:35 <felixfontein> :)
18:36:41 <jtanner> sorry, that's how i keep it straight in my head
18:36:43 <bcoca> api has v1-v3 even though they dont overlap
18:36:51 <bcoca> jtanner: dont think that is possible
18:37:07 <bcoca> so v1, v2 and v3 are compimentary not subsittutions
18:37:21 <gotmax[m]> Yeah, it's weird.
18:37:21 <bcoca> ^ explaing for those that are not familiar with galaxy
18:37:27 <felixfontein> gotmax[m]: for 2 we need approval from Legal I think
18:37:31 <bcoca> gotmax[m]: #dontgetmestarted
18:37:34 <jtanner> they're all very "unique" ... let's just leave it at that
18:38:12 <gotmax[m]> felixfontein: I guess
18:38:51 <felixfontein> jtanner: bcoca: what do you think about allowing to upload both a source and a release verison of a collection to galaxy (for one version)? I guess both the `ansible-galaxy build` CLI and Galaxy itself (more likely galaxy_ng, and maybe/probably also pulp?) would need to support that
18:38:55 <gotmax[m]> Also, note that the current way we exclude tests from `ansible` bdists uses deprecated setuptools features
18:38:58 <gotmax[m]> So we have to do something about that
18:39:15 <jtanner> hrm
18:39:30 <jtanner> so source would be like galaxy.yml and test files, but no manifests?
18:39:49 <gotmax[m]> Yes, but it'd ignore excludes
18:39:54 <felixfontein> jtanner: yes. basically what you need to build the release version, and more (basically what GPL requires you to provide as source)
18:40:24 <gotmax[m]> I like that idea better.
18:40:26 <felixfontein> (of course the collection will have to tell the build CLI which file is what...)
18:40:33 <jtanner> i believe the backend will break if it can't find a manifest. the db primary keys are also hard set to namespace,name,version ... so i'm not sure how we could differentiate src vs non-src
18:40:40 <gotmax[m]> I didn't suggest it, because I wasn't sure how feasible it'd be.
18:41:04 <felixfontein> it definitely requires some work :)
18:41:41 <felixfontein> the DB primary key could be extended to namespace,name,version,type (in search of better name for 'type'...)
18:41:51 <jtanner> i'd prefer the import process and a scheduled job validate the given src repo matches the import and fail if not
18:42:05 <felixfontein> +1 on validation
18:42:19 <felixfontein> maybe you could just upload the source, and galaxy (i.e. the importer) builds the release version itself?
18:42:34 <jtanner> i think that would be much more feasible
18:42:37 <felixfontein> that way you always know for sure that the release was really built from the source
18:43:01 <jtanner> pulp-ansible has a concept of git-synced collections and it will basically do that sort of thing
18:43:15 <jtanner> the artifact is built and linted, but not stored
18:43:44 <felixfontein> that sounds like roles v1 to me ;)
18:43:55 <jtanner> it is ... and a better system imo
18:44:16 <gotmax[m]> As long as it's clear from which directory and tag of the `repository:` the source comes from
18:44:45 <jtanner> in order for the backend to know how to get the thing, certain conventions will have to be abided by
18:45:00 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:45:03 <felixfontein> I think it makes sense to also store the built collection, that avoids changes in the collection installer
18:45:28 <felixfontein> (so you can still use Ansible 2.9 to install them)
18:45:30 <gotmax[m]> s/tag/commit/ as tags can be changed
18:45:43 <jtanner> there's no hook for that yet. the feature isn't really in use though, so maybe we can flesh all that out whenever we get around to exposing it in galaxy_ng
18:46:36 <felixfontein> does GH keeps unreferenced commits forever, or do they vanish eventually?
18:47:15 <jtanner> no idea
18:47:17 <felixfontein> i.e. if someone releases a git collection for some tag, galaxy_ng stores the commit, and then the tag is deleted - can the commit also be used in 10 years (assuming the repo's still there)?
18:47:59 <felixfontein> I guess that's already a problem for roles with Galaxy v1, if someone deletes the repo (or the tags) users probably cannot install that role anymore (or the affected versions of the role)
18:48:10 <mariolenz[m]> Even if they keep them forever at the moment, I guess they're free to change this behavior when they want to.
18:48:12 <jtanner> that is correct for roles
18:48:21 <jtanner> no repo == no install
18:48:39 <gotmax[m]> Well, aren't tagged commits usually on some branch?
18:48:45 <felixfontein> mariolenz[m]: true
18:48:50 <felixfontein> gotmax[m]: they do not need to
18:49:00 <felixfontein> (but once they are tagged they are referenced :) )
18:49:14 <gotmax[m]> That's why I said usually
18:50:09 <gotmax[m]> I think having Galaxy no longer store the artifacts would be a regression.
18:50:31 <felixfontein> yes, and I hope that will not happen
18:50:44 <jtanner> there is no actual plan for that atm
18:51:49 <briantist> IIRC unreferenced commits in GH do get culled over time, perhaps not predictably
18:52:28 <felixfontein> that's why I would expect
18:52:39 <felixfontein> storage is cheap, but not free :)
18:53:17 <briantist> it's probably less about storage and more about git performance I'd imagine, but not sure
18:54:20 <bcoca> felixfontein: a bit issue, roles never had versioning standard, collections were designed with semantic versioning as a requirement
18:54:30 * gotmax[m] thinks back to the person who tried to implement git in bash as an April Fool's thing
18:54:51 <bcoca> https://github.com/ansible/proposals/issues/23
18:55:26 <bcoca> gotmax[m]: and probably 3 did 'seriosully' and it is being used in the crop they did it for
18:56:14 <gotmax[m]> bcoca: I don't follow
18:56:54 <bcoca> someone's april fools joke is another one's 'serious project'
18:58:46 <felixfontein> ok, I guess we won't solve this today :)
18:59:04 <gotmax[m]> bcoca: I guess.
18:59:13 <gotmax[m]> felixfontein: Yeah
18:59:13 <mariolenz[m]> Since we have only a couple of minutes left, I think mellanox.onyx is unmaintained: https://github.com/ansible-community/community-topics/issues/136
18:59:13 <mariolenz[m]> Please have a look at it. If you follow my reasoning I would open an issue in the repo and announce it in Bullhorn. Thanks.
18:59:26 <gotmax[m]> bcoca: https://git.sr.ht/~sircmpwn/shit
18:59:40 <felixfontein> mariolenz[m]: let's see whether andersson007_ knows more, otherwise starting that process sounds good IMO
19:00:04 <mariolenz[m]> OK
19:00:23 <acozine> +1
19:00:57 * acozine needs to get to $NEXT_MEETING
19:01:05 <acozine> see you all next week!
19:01:10 <acozine> #unchair acozine
19:01:10 <zodbot> Current chairs: andersson007_ briantist cybette_ felixfontein gotmax[m] mariolenz[m] samccann
19:01:12 * gotmax[m] waves
19:02:45 <felixfontein> sorry, got side-trackde by our cats...
19:02:46 <felixfontein> #endmeeting