19:08:57 <jillr> #startmeeting ansible core irc public meeting 19:08:57 <zodbot> Meeting started Tue Feb 18 19:08:57 2020 UTC. 19:08:57 <zodbot> This meeting is logged and archived in a public location. 19:08:57 <zodbot> The chair is jillr. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:08:57 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:08:57 <zodbot> The meeting name has been set to 'ansible_core_irc_public_meeting' 19:09:02 <sdoran> o/ 19:09:21 <jillr> looks like the agenda is clear 19:09:32 <zodbot> jillr: Error: Can't start another meeting, one is in progress. 19:09:39 <jillr> erm :) 19:09:41 <jillr> #topic open floor 19:10:00 * sdoran dances 19:11:58 <cyberpear> What will the standard be for collections to be included in ACD? 19:12:35 <cyberpear> And what will be the mechanism? 19:12:55 <cyberpear> git submodules? 19:13:50 <sdoran> I don't think it will be submodules. It will be a build artifact, not an single repository of repsitories. 19:15:04 <sdoran> As far as criteria for inclusion, I'm not sure that has been enumerated. 19:15:37 <sdoran> Or how long ACD will be a thing. 19:15:58 <jillr> my understanding has been generally something along the lines of whatever ships today 19:16:03 <sdoran> It's evolving. 19:16:52 <sdoran> It's meant to be a short term solution to ease the transition to collections. 19:17:59 <sdoran> Ideally, the shift to using collections will happen naturally since modules in collections will have updates that will be release faster than ACD. 19:18:31 <sdoran> s/release/released 19:19:10 <cyberpear> I fear folks will be forced into something akin to RPython, with missing useful modules like ini_file... especially if the collections don't end up packaged as RPMs 19:20:25 <sdoran> There are a lot of concerns. Change is not easy. 19:20:27 <cyberpear> (Which is why ACD is critical to have, given kicking out the community modules) 19:22:32 <cyberpear> Hopefully we can answer these questions before releasing a 2.10 without community modules 19:23:38 <sdoran> Is your primary concern being able to have the modules distributed in an rpm? 19:24:39 <cyberpear> I'm concerned about fragmentation, and having my roles work everywhere even offline networks 19:25:39 <cyberpear> Ideally, I'd like to see a process of getting a module added to core, such as supporting diff_mode, check_mode, and having unit and integration tests for all of the module's features. 19:26:22 <jillr> there will be ways to get collections into offline networks, that's going to be a common scenario 19:29:04 <cyberpear> Just don't want to force lots of extra steps, and RPMs are well understood, with virtualenv's being possible but less desirable 19:29:28 <sdoran> How do you distribute roles today? 19:29:48 <sdoran> Collections aren't much different. A folder full of folders and files. 19:32:05 <cyberpear> git or RPMs, depending on the stage 19:34:25 <sdoran> I understand your concern, but don't think distributing collections will be that much more difficult that roles. 19:34:29 <sdoran> That's the goal, anyway. 19:34:57 <sdoran> I want to look at making installation from a requirements file with both roles and collections work in one go. 19:35:14 <sdoran> It's a bit fragmented today, though you can have a single requirements file. 19:35:34 <sdoran> I imagine it will be much harder to solve than I think, like most things in software. :) 19:35:54 <cyberpear> Doesn't work with git now, either... 19:37:33 <agaffney> cyberpear: it's trivial to create custom RPMs with extra stuff with a tool like FPM 19:38:58 <sdoran> Hmmm, I bet there is a good reason for that. Collections seem to be very artifact-based. 19:39:11 <sdoran> Would be nice to be able to install from a git repo, though. 19:44:38 <jillr> There's going to be an adjustment period to work all those things out, so we have ACD for that transitionary period. 19:44:59 <jillr> Anything else for today? 19:47:25 <jillr> ok, thanks folks for dropping by o/ 19:47:29 <jillr> #endmeeting