15:02:57 <Shrews> #startmeeting Ansible Core Public IRC Meeting
15:02:57 <zodbot> Meeting started Thu May 27 15:02:57 2021 UTC.
15:02:57 <zodbot> This meeting is logged and archived in a public location.
15:02:57 <zodbot> The chair is Shrews. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:57 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:02:57 <zodbot> The meeting name has been set to 'ansible_core_public_irc_meeting'
15:03:07 <cyberpear> o/
15:03:11 <Shrews> #info agenda https://github.com/ansible/community/issues/606
15:03:37 <Shrews> I see nothing new on the agena (a few references, but no actual topics)
15:03:43 * shertel waves
15:03:52 <Shrews> #topic Open floor
15:03:54 <sivel> ompragash wanted to talk about https://github.com/ansible/ansible/issues/74684
15:04:01 <sivel> not sure if they are here or not
15:04:31 <dericcrago> I'm here (and would also like to chat about that) if ompragash isn't around
15:04:52 <Shrews> let's do that then
15:05:10 <Shrews> #topic issue  https://github.com/ansible/ansible/issues/74684
15:05:50 <dericcrago> we had a couple of different approaches in mind for that
15:05:59 <dericcrago> cookiecutter has already solved this problem
15:06:14 <dericcrago> option 1 - use / depend on cookiecutter
15:06:19 <felixfontein> oh, a meeting :)
15:06:29 <dericcrago> option 2 - reinvent the cookiecutter wheel
15:06:30 <sivel> I can't see us accepting #1
15:07:28 <bcoca> 2 is not reinventing, its just doing same we already do for roles and allow for 'custom' and alternative init templates
15:07:47 <dericcrago> option 3 - make something really specific to our use case which is specific to community which implies using something --community-skeleton and maybe hardcoding how it would work so it wouldn't need to be as comprehensive as cookiecutter is
15:07:58 <sivel> We already allow for some jinja2 templating do we not?
15:08:46 <dericcrago> yeah, the reinventing part is handling urls and figuring out if it's a git repo or a zip file or whatever and then handling that appropriately
15:09:21 <sivel> I'm also unsure if we want to accept anything other than local paths either
15:09:31 <sivel> so we would need to debate that as well
15:09:41 <bcoca> ^ roles only use local paths, i also am reticent to allow more than that
15:09:42 <dericcrago> cookiecutter regex for the arg - https://github.com/cookiecutter/cookiecutter/blob/master/cookiecutter/repository.py#L9-L18
15:11:49 <dericcrago> the end goal would be to have something in the community docs like `ansible-galaxy collection init --collection-skeleton https://github.com/ansible-collections/collection_template` or the like functionality
15:13:11 <sivel> the amount of work to add functionality like clone from git is not trivial, and I question the return on investment for spending time implementing it, when it is however trivial to just clone the repo and point `--collection-skeleton` at it
15:14:13 <sivel> if we did, we wouldn't extend past git, since we don't support other scms for collections
15:14:55 <dericcrago> I agree with the amount of work involved, that's why I wanted to use cookiecutter :)
15:15:22 <shertel> I'd rather not add a new dep
15:15:23 <sivel> we are very strict on adding new deps
15:15:42 <felixfontein> (which is good!)
15:16:31 <bcoca> if we had a 'developer tool' we would be more lax with deps, but since asnible is meant to be a system tool, deps are evil
15:18:08 <cyberpear> right; if we explode deps we'll end up w/ an ansible-core-core without the extra features
15:18:23 <abadger1999> <nod> which is why it seemed good to ask about whether adding a dep for ansible-galaxy would be acceptable or not (the last dep on resolvelibwas added for ansible-galaxy as well)
15:18:26 <felixfontein> ansible-atomic :)
15:18:41 <dericcrago> ok, so if we put cookiecutter aside, would we want to still pursue it generically with git + maybe tarball / zip or maybe specifically with --community-skeleton ?
15:18:48 <sivel> So my preference would be to keep `--collection-skeleton` hitting a local path, and have basic templating functionality via jinja2/Templar like we do for roles
15:19:50 <Shrews> ^ that sounds reasonable to me as well
15:20:10 <abadger1999> That sounds irreconcilable with the needed feature, though.
15:20:33 <shertel> what's preventing downloading the template first?
15:20:51 <gundalow> AFAIK `ansible-galaxy collection init ` already uses Jinja2 templates
15:21:06 <cyberpear> seems we should be able to re-use existing git or tarball download capability, then reference from the on-disk location?
15:21:12 <bcoca> and we already have 'optional skeeleton' for roles, we can just make both features the same
15:21:24 <dericcrago> correct, if the user does a 2 step process and clones the repo first to a local directory that would work
15:21:47 <dericcrago> the proposed idea would skip the git clone first step
15:22:10 <abadger1999> shertel I think if ansible is installed into a system path and you're a user, you don't have proper permissions to add a new template.  (Unless that searches a list of paths rather than a single path?)
15:22:52 <felixfontein> you could download the template to somewhere in your $HOME and use it from there
15:23:07 <bcoca> abadger1999: already solved on role side, you can poitn to a path
15:23:36 <bcoca> we have 'built in' templates + same ability can use 'arbitrary path as template'
15:23:50 <dericcrago> yes, git clone https://github.com/ansible-collections/collection_template; ansible-galaxy collection init --collection-skeleton collection_template; works today as is
15:24:06 <abadger1999> <nod>
15:24:20 <abadger1999> Okay :-)
15:24:48 <dericcrago> the proposal was to skip the clone and handle that for the user
15:27:23 <Shrews> So are we mostly agreed to the process of a manual clone and --collection-skeleton using only a local path?
15:27:37 <abadger1999> N....
15:27:56 <abadger1999> Sorry, we're in our team meeting and gundalow and dericcrago just came up to report.
15:28:31 <abadger1999> I'll try to fill in but I only got read into this  yesterday.
15:28:32 <shertel> I don't really see the problem with manual cloning. I'm not strongly opposed to 2, but it seems like it could be a lot of overhead. I guess it would depend on the implementation.
15:28:56 <sivel> the process trying to be automated seems like a relatively infrequent operation
15:29:04 <felixfontein> there's already code in ansible-core for cloning git repos, right? for installing collections from git repos? is there a way that can be re-used?
15:29:26 <sivel> which was my comment about added complexity and investment time, for something needed pretty infrequently
15:29:26 <felixfontein> (I haven't looked at it for a long time so no idea how easy it is to re-use)
15:29:57 <Shrews> that's a good question
15:30:04 <abadger1999> The things that gundalow was trying to do were (1) remove a bit of friction for the collection authors (2) allow the collection authors to get changes to the templates easily.
15:30:17 <bcoca> implementing the local path still leaves for other improvements later
15:30:36 <bcoca> i say we do one step at a time
15:30:49 * abadger1999 is getting pulled into team meeting now.... sorry....
15:30:52 <felixfontein> implementing the local path is definitely a first good step!
15:31:02 <felixfontein> (no matter whether it is also the last one or not ;) )
15:31:54 <abadger1999> I think dericcrago is saying that local path already works.
15:31:56 <bcoca> i also suggest unifying the features with roles, otherwise we would already have this feature
15:32:02 <dericcrago> define local path... that already works, right?
15:32:12 <bcoca> /path/tomyskel ?
15:32:21 <bcoca> i thought it only worked for roles
15:32:32 <dericcrago> that works for collections too
15:34:24 <Shrews> we have a --role-skeleton and --collection-skeleton options, it would seem. i thought we needed the 2nd, but I guess not
15:35:00 <bcoca> i would just add --skeleton  alias so you dont need to repeat
15:35:17 <bcoca> ansible collection init --colleciton-skeleton ... we already know we are in that object
15:35:27 <bcoca> <= lzy typis
15:37:59 <dericcrago> `ansible-galaxy collection init --collection-skeleton collection_template` works today, the question around the feature is whether or not we want to allow `ansible-galaxy collection init --collection-skeleton https://github.com/ansible-collections/collection_template` as well
15:38:33 <dericcrago> or maybe even https://github.com/ansible-collections/collection_template/archive/refs/heads/main.zip to simplify it
15:39:45 <bcoca> well, ticket was bout creating and shipping new skeleton for collections
15:39:58 <bcoca> the url handling is not the feature idea prposed
15:40:05 <shertel> ^ sounds like option 3
15:41:04 <bcoca> and im fine with shipping it, i was just under assumption that /random/path wasn't working for collections and thought we should extend that too
15:41:39 <abadger1999> Well... the original proposal was to replace the current collection template with the community collection template..  The next proposal is probably to add the community collection template as an additional one.
15:41:46 <bcoca> also it seems we are mixing 'creating new collection' with 'creating community collection git repo'
15:42:06 <abadger1999> (which then probably means being able to specify the collection skeleton via a short symbolic name (folder inside of the skeleton dir?)
15:42:16 <bcoca> yes, after we talked with gundalow the first time we went from substitution to additional
15:42:31 <bcoca> abadger1999: that should already work
15:42:47 <bcoca> since pathing works and both were featuers of roles (see galaxy roles init template)
15:42:58 <abadger1999> bcoca: well.... it won't because ansible-core doesn't ship it.
15:43:07 <abadger1999> that's part of proposal 2
15:43:31 <bcoca> ^ which i already said im fine with, my only opposition was to make it the default, since it doesnt really create full skel either
15:44:18 <bcoca> the default creates a 'mostly' full skeleton, the community creates mostly files for comunity git repo + meta/ and galaxy.yml
15:45:05 <abadger1999> proposal 3 from dericcrago is to make it more generic and pull from a url.
15:46:31 <ompragash> Hi everyone, for https://github.com/ansible/ansible/issues/74684 idea here is to let users to directly pass their git repo URL to `--collection-skeleton` argument (instead of manually cloning it and passing the local cloned path) and ansible-galaxy will create a new collection based on the remote repo. Also, we are not planning to include new dep to implement this feature but maybe use git commands in the code to achieve this.
15:47:03 <dericcrago> bcoca - it did seem like we should keep the default skeleton and the collection skeleton separate, are you proposing an additional directory for the community skeleton bundled in ansible-core ?
15:47:13 <bcoca> yes
15:47:28 <bcoca> then --skeleton community-collection woudl populate using that
15:47:34 <bcoca> same thing we did for roles for networking and galaxy
15:47:38 <bcoca> aka 'container'
15:48:11 <bcoca> just add tempalte to lib/ansible/galaxy/data/<tempaltedir> and it can be used that way
15:48:42 <Shrews> would that not then open the door for others to ask to include their templates in core? when would we say "no" vs. "yes"?
15:48:50 <cyberpear> ship it also as a collection, so `ansible-galaxy collection install skeleton.community` would make it available :P
15:49:06 <bcoca> Shrews: that was said with roles when we added container, only got 'network' after that
15:49:52 <bcoca> cyberpear: that would require skeleton code to pull from collection, not impossible, but we need to add 'arbitrary file ref' for collection
15:50:00 <bcoca> and we have been remiss on doing that
15:52:05 <bcoca> so optoins we have a) do nothing, people can download template and use from path b) incorporate and ship template in core c) add url handling to allow arbitrary tempalte location in web d) do c but with cookiecutter
15:52:17 <bcoca> also doing one option today does not mean other options cannot be considered in future
15:52:28 <bcoca> or b and c are 'compatible options' we can do both
15:52:53 <bcoca> i think most of core is opposed to d) due to extra dep it adds
15:53:09 <dericcrago> bcoca - those options sound accurate to me
15:53:16 <Shrews> yes, (d) is a no-go for me
15:53:39 <bcoca> im fine with a or b, c i might consider if we generalize url handling and hook this in a way we dont redo it every time in every system we add
15:54:11 <bcoca> ah, forgot e) make community template default (but core alredy voted this out)
15:56:17 <dericcrago> ok, in that case, I think we can work on (b) in the short term and maybe pursue (c) longer term based on future demand
15:56:26 <Shrews> ok, we are running short on time so let's decide on a course of action (even if it's continue discussing at the next meeting). my preference is for (b), at least initially.
15:57:09 <bcoca> +1 to dericcrago's prposal
15:58:20 <bcoca> hmm, also might need a --list-skeletons facility if this grows more (think AH/private AH and galaxy collection)
15:58:26 <felixfontein> b now, c maybe later sounds good to me
15:58:50 <felixfontein> --browse-skeletons which starts a HTTP server and opens a browser so it has a nicer UI? :P
15:59:03 * bcoca slaps felixfontein with week old trout
15:59:09 <Shrews> ok, with two minutes left, and no one else chiming in on the proposal, we'll assume quiet agreement on (b)
15:59:27 <dericcrago> thanks everyone
15:59:30 <bcoca> adn we can revise c) as we see future demand
15:59:44 <Shrews> #agreed incorporate c-g template into core and ship templates, maybe handle git urls later
15:59:48 <Shrews> #topic open floor
16:00:05 <Shrews> just want to note that next meeting (Tuesday) will be on libera
16:00:07 <bcoca> one issue also with c) . is incompatibility across versions, the good thing about 'shipped' is that you at least know it will work with that version
16:00:36 <bcoca> lib e RA! ... avoid kickbot search terms!
16:01:00 <Shrews> no other announcements, i believe, so we'll just end the meeting. thx everyone
16:01:06 <Shrews> #endmeeting