16:00:02 <mhayden> #startmeeting OpenStack-Ansible
16:00:03 <openstack> Meeting started Thu Jul 28 16:00:02 2016 UTC and is due to finish in 60 minutes.  The chair is mhayden. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:06 <openstack> The meeting name has been set to 'openstack_ansible'
16:00:11 <mhayden> #topic Roll Call
16:00:11 <evrardjp> hello
16:00:17 <eil397> o/
16:00:18 <evrardjp> o?
16:00:28 <DrifterZA> hi
16:00:28 <stevelle> o/
16:00:29 <janki> o/
16:00:36 <DrifterZA> o/
16:00:47 <michaelgugino> here
16:00:50 * mhayden ( ͡° ͜ʖ ͡°)
16:00:51 <janki> HI, I am Janki. This is my first meeting here.
16:00:57 <automagically> o/
16:00:57 <mhayden> welcome, janki!
16:00:58 <odyssey4me> o/
16:01:14 <janki> mhayden: thank you
16:01:30 <adreznec> o/
16:01:50 <jmccrory> o/
16:01:56 <eil397_> welcome, janki !
16:02:15 * mhayden gives d34dh0r53 a nudge
16:02:19 <andymccr> o/
16:02:29 <alextricity25> o/
16:02:49 <evrardjp> welcome janki
16:03:01 <asettle> o/
16:03:01 <asettle> yerp
16:03:13 <janki> eil397_: evrardjp: thanks for the warm welcome :)
16:03:13 <mhayden> let's roll!
16:03:17 <mhayden> #topic Action items
16:03:32 <mhayden> first up was for automagically to update the xenial status etherpad
16:03:41 <automagically> Its been done
16:03:56 <mhayden> woot
16:04:06 <mhayden> the other was for me to test xenial in the lab
16:04:25 <mhayden> i ran into some failures there that i haven't been able to visit, but i might have gotten dinged by one of those gate blocker bugs :(
16:04:28 <odyssey4me> thanks, I need to run through the CI jobs and shift more from non-voting to voting
16:04:33 <mhayden> i'll do my best to revisit that tomorrow
16:04:37 <prometheanfire> o/
16:04:43 <mhayden> #action mhayden to continue testing xenial in the lab
16:04:52 <mhayden> odyssey4me: thanks for that!
16:05:06 <mhayden> that's it for action items
16:05:11 <mhayden> #topic OSA Mascot
16:05:15 <cloudnull> o/
16:05:22 <d34dh0r53> o/
16:05:23 * mhayden is still sad that d34dh0r53 can't be our mascot, but we have other options :)
16:05:29 <odyssey4me> righto
16:05:35 <odyssey4me> so I sent through the list to the foundation
16:06:03 <odyssey4me> they've fed back that another team has opted for a bee so the OSA bug would likely not be the best choice, and they're happy with the Cape Buffalo
16:06:07 <odyssey4me> there are no conflicts there
16:06:14 <odyssey4me> is everyone happy to go ahead with that?
16:06:27 <cloudnull> +1
16:06:29 <stevelle> +1
16:06:31 <DrifterZA> +1
16:06:32 <mhayden> https://en.wikipedia.org/wiki/Buffalo_buffalo_Buffalo_buffalo_buffalo_buffalo_Buffalo_buffalo
16:06:34 <odyssey4me> apparently they'll be dishing out stickers at the summit :)
16:06:36 <d34dh0r53> +0.5
16:06:36 <mhayden> +1 here
16:06:44 <eil397_> +1
16:06:48 <odyssey4me> lol, ok awesome I'll let them know we're all in
16:07:05 <automagically> +1
16:07:16 <evrardjp> +1
16:07:19 <mhayden> at least we don't have to bison more time to decide
16:07:21 <jmccrory> +1
16:07:27 <odyssey4me> :p
16:07:40 <d34dh0r53> uggh
16:07:42 * odyssey4me hands the mic back to mhayden
16:07:52 <evrardjp> I vote for mhayden's sentence to be our motto
16:07:55 <mhayden> haha
16:08:12 <mhayden> i'll take the mic back before odyssey4me realizes that's a bad idea :)
16:08:14 <palendae> OSA: When you need to bison time
16:08:24 <mhayden> #topic Applying for stable:follows-policy governance tag
16:08:29 <mhayden> #link https://governance.openstack.org/reference/tags/stable_follows-policy.html
16:08:40 <odyssey4me> alright, I guess that's me again :p
16:08:40 * mhayden assumes this is odyssey4me
16:08:58 <odyssey4me> We have the option of applying to apply this governance tag to the project's deliverables.
16:09:14 <odyssey4me> This would be a signal to the world that we take our stable branches seriously.
16:09:32 <evrardjp> it doesn't mean they have to
16:09:36 <odyssey4me> I honestly assumed that this was a requirement once bing an official project, but apparently not.
16:09:36 <spotz> o/
16:09:46 <stevelle> historically we have been rather free with backports, and those habits can be hard to break. Are we ready to take this step?
16:09:49 <evrardjp> oh interesting odyssey4me
16:10:03 <odyssey4me> So I'd like to suggest that we apply for the tag, and that we stick to the rules far better going forward.
16:10:17 <mhayden> #link http://docs.openstack.org/project-team-guide/stable-branches.html
16:10:19 <odyssey4me> stevelle agreed, this will take more discipline
16:10:21 <mhayden> ^^ rules
16:10:26 <evrardjp> if it's not a requirement, why would we want to apply for the tag? It seems more restrictive than its benefits
16:10:29 <automagically> Looks like we need a stable branch maint team...
16:10:29 <stevelle> Are you advocating a separate stable maint core list?
16:10:38 <odyssey4me> but we have been pretty good about applying these rules during this cycle
16:10:41 <stevelle> I know some projects use separate cores for stable
16:10:47 <evrardjp> We could have the discipline without being officially flagged as this
16:10:55 <DrifterZA> brb
16:10:58 <odyssey4me> we can, but it's not a requirement - the same core team can do stable reviews
16:11:02 <mhayden> what would the negative outcome be if we chose not to apply?
16:11:21 <odyssey4me> it affects the view of our maturity as a project
16:11:33 <palendae> odyssey4me, How would that affect upgrade work, given that that's been happening post-release?
16:11:35 <evrardjp> oh in the project navigator?
16:11:36 <stevelle> TC tags: gotta catch em all.
16:11:43 <mhayden> ah, palendae brings up a good question
16:11:45 <automagically> How do we test backward compatibility of backports? In other words, does adopting this suggest that we should have some mechanism for ensuring such backware compatibility
16:11:50 <odyssey4me> also, not having this tag does mean that we get people trying to shove features into stable branches
16:11:51 <palendae> e.g. I don't think anyone is working on Mitaka -> Newton right now
16:11:56 <odyssey4me> it becomes very hard to justify why not
16:12:37 <automagically> Given the mid-cycle is not far off, should we discuss further then, or is there a good reason to push for adoption earlier than that?
16:12:44 <odyssey4me> the cycle planning which I've been trying very hard to get us to stick to has all been around being able to discipline our development into the cycle properly
16:12:55 <odyssey4me> part of that is for us to ensure that we do the upgrade work *within* the cycle
16:13:02 <stevelle> one implication of this tag would be that we have to be careful when bumping SHAs on stable that we only bump SHAs on projects which also have that tag, no?
16:13:12 <odyssey4me> ie by the time we release Newton, we should have a working upgrade
16:13:22 <palendae> odyssey4me, I don't disagree with that approach, just pointing out we've not been able to hit that historically
16:13:23 <automagically> stevelle: Great point
16:13:48 <automagically> We could always move upgrade plays into their own repo that doesn’t carry the tag...
16:13:55 <odyssey4me> stevelle hmm, not sure about that - I could discuss that and see how that works
16:14:11 <palendae> automagically, I'm -1 to that
16:14:15 <palendae> Repo-itis is bad
16:14:24 <mhayden> #info If we apply for stable tag, what about upgrade playbooks that need to be adjusted after release?
16:14:26 <odyssey4me> automagically I think that's a terrible idea. Upgrades are essential to the success of the project's deliverables.
16:14:33 <palendae> ^
16:14:45 <evrardjp> agreed with palendae and odyssey4me
16:14:49 <odyssey4me> bear in mind that this doesn't prevent us fixing bugs once a stable branch is cut
16:14:51 <mhayden> #info If we apply for stable tag, are we limited on the projects we can do SHA bumps on in stable releases? (Do those need to have stable tag, too?)
16:14:52 <palendae> IMO, upgrades are more important than greenfield install
16:15:00 <palendae> Greenfields won't nuke existing clouds
16:15:00 <odyssey4me> it just means we don't backport large features
16:15:06 <odyssey4me> which we have been good about in this cycle
16:15:15 <automagically> I don’t disagree, I just find it hard to believe that we’ll have them done at the same time as the release
16:15:26 <odyssey4me> we have already had our releases inspected for the whole of the cycle, and have had no negative feedback\
16:15:37 <palendae> automagically, yeah, I share the skepticism. I would definitely prefer it that way
16:15:41 <odyssey4me> the only times we had a comeback, we had to bumpt the minor tag
16:15:51 <odyssey4me> (which is why that happened a few times)
16:15:59 <automagically> I’m not opposed to adoption so long as we understand what we are signing up for and legitimately believe we can hit those targets
16:15:59 <evrardjp> we need a better CI to automatically test upgrades between versions, only that will force us to care about upgrades
16:16:17 <michaelgugino> -1
16:16:28 <stevelle> I don't trust the lack of negative feedback to indicate we haven't let stuff slip by
16:16:29 <evrardjp> not better but more extensive
16:16:39 <palendae> I'm not against adding that tag. I do think shoehorning in big features needs to stop...but the tag isn't strictly necessary to stop that, either
16:16:47 <michaelgugino> I like the ability to backport features.  This project is such a moving target, it's hard to be able to implement features as upstream projects commit them.
16:16:50 <palendae> The upgrade problem is my biggest concern right now
16:16:54 <mhayden> it sounds like we have good questions/opinions here -- should we table that for the mid-cycle and have a more thorough discussion?
16:16:55 <odyssey4me> evrardjp not entirely true, but yes if we had people who would process the messages in the QA mailing list then periodic upgrade checks would have value
16:17:08 <jmccrory> i think a lot of the standard upgrade playbooks are there, just needs some reorganization and any release->release specifics, which are hard to know until the next release stablize
16:17:09 <jmccrory> s
16:17:10 <palendae> mhayden, I'd agree that midcycle would be nice
16:17:16 <odyssey4me> right now our stakeholders are implementing their own upgrade testing and feeding back - that's a fairly good start
16:17:16 <automagically> mhayden: ++ on midcycle discusssion
16:17:17 <stevelle> mhayden: I think this should go to the list before midcycle to solicit more feedback
16:17:20 <palendae> jmccrory, Yeah, that's also true
16:17:24 * mhayden is working to figure out if we can do VC at the midcycle -- fingers crossed
16:17:30 <palendae> Agreed with stevelle
16:17:31 <mhayden> stevelle: not a bad idea
16:17:32 <automagically> stevelle: also a good point
16:17:42 <palendae> Pre-meetup homework
16:17:43 <mhayden> reminds me of the "why not both?" meme
16:17:48 <palendae> I need to do some of that myself
16:17:51 <stevelle> indeed
16:17:57 <odyssey4me> mhayden please don't try and accommodate VC... we have tried and failed many times
16:18:06 <mhayden> #agreed Send something to the ML about stable:follows-policy tag, follow up with discussion at the mid-cycle
16:18:21 <mhayden> odyssey4me: okay
16:18:25 <odyssey4me> mhayden VC is a distraction at the mid cycle and generally ends up being frustrating and not contributing
16:18:30 <mhayden> who will mail the list?
16:18:41 <odyssey4me> mhayden me
16:18:55 <mhayden> #action odyssey4me to send something to the ML about stable:follows-policy tag
16:19:00 <evrardjp> it's definitely a deployer opinion to give
16:19:12 <mhayden> odyssey4me: can you update the etherpad too so it's on the agenda?
16:19:14 <michaelgugino> what is this VC business?
16:19:16 <mhayden> (for the midcycle)
16:19:21 <mhayden> michaelgugino: videoconference
16:19:25 <michaelgugino> ah
16:19:30 <odyssey4me> mhayden yep, doing it now
16:19:44 <mhayden> i'm sure we can fire up etherpads and link those pads in the channel for remote folks to jump in
16:19:48 <michaelgugino> we did VC with watcher, it worked out okay, but it was a much smaller group.
16:20:07 <palendae> Biggest hurdle last time was timezones
16:20:11 <michaelgugino> I think there are too many people going to the mid cycle for VC to work
16:20:13 <palendae> I intterupted discussions when joining
16:20:22 <stevelle> == michaelgugino
16:20:24 <mhayden> okay, are we good on this topic for now?
16:20:30 <automagically> +1
16:20:35 <automagically> next topic
16:20:46 <odyssey4me> yep
16:20:47 <mhayden> thanks for bringing it up, odyssey4me :)
16:20:57 <mhayden> #topic wsgi vs uwsgi and Apache vs nginx role consistency
16:21:07 <mhayden> stevelle / cloudnull / odyssey4me have the mic
16:21:25 * odyssey4me points at stevelle :)
16:21:35 <michaelgugino> I thought we were tabling this until the midcycle.
16:21:35 * cloudnull wants nginx+uwsgi all the things
16:21:36 <stevelle> I think we covered this last week
16:21:44 <automagically> Yeah, don’t think we have anything new on this topic
16:21:46 <mhayden> ah, it was still in the agenda
16:21:48 <odyssey4me> yep, are we stuck or anything?
16:21:56 <cloudnull> federation is an issue.
16:21:57 <cloudnull> i think
16:22:10 <mhayden> #agreed Talk more on wsgi/uwsgi/nginx/apache at the mid-cycle
16:22:15 <stevelle> It needs time, and I thought we agreed there wouldn't be enough before M3
16:22:22 <automagically> ^ That
16:22:31 <mhayden> cool beans, we can move on
16:22:36 <mhayden> #topic Mid-cycle planning
16:23:01 <mhayden> i'll be sending the list of names from the etherpad to the physical security team here to make badges and things
16:23:10 <mhayden> so be sure to get your name on there before next week
16:23:42 <mhayden> and i'll be sure to get some instructions out about where to go, where to park, etc
16:23:54 <mhayden> you'll need a Racker to escort you up to the room, we can tackle that too
16:24:04 <palendae> mhayden, Do we have actual times for stuff yet? I was going to invite the Craton team for the inventory discussions
16:24:24 <mhayden> palendae: mainly just an outline
16:24:26 <mhayden> #link https://etherpad.openstack.org/p/osa-midcycle-newton
16:24:28 <palendae> Ok
16:24:45 <odyssey4me> palendae for things that need a set time (like using a VC for a discussion) we can specifically set a time on day 2 I think
16:24:46 <mhayden> #action mhayden to email security folks with the list and email extra venue instructions to attendees
16:24:49 <janki> mhayden: possible to have meeting online. I am in India
16:25:04 <mhayden> janki: i'm hearing that it didn't work so well in the past /
16:25:11 <palendae> odyssey4me, Ok. I notice that Day 1's list is well over 8 hours :(
16:25:13 <odyssey4me> I'd suggest that we have a more strict schedule for day 2 - day 1 is for us to catch up and organise the rest of the week
16:25:26 <odyssey4me> but we can set times for day 2
16:25:29 <automagically> #link http://dolphm.com/retrospective-on-openstack-midcycles/
16:25:40 <automagically> Suggest reading that ^ for those of you attending
16:25:48 <odyssey4me> if we do any VC stuff it must be no longer than an hour and have a well organised agenda and set of outcomes
16:25:54 <odyssey4me> automagically ++
16:26:02 <mhayden> automagically: that's a good one
16:26:08 <janki> mhayden: :(
16:26:12 <palendae> Just looking at the list of topics, day 2 will be at least half discussion if we hit everyting
16:26:36 <mhayden> janki: at a minimum, we will have some etherpads and link to them in #openstack-ansible
16:26:41 <mhayden> and we'll probably have some recaps written up
16:26:48 <odyssey4me> janki trying to include other time zones is even worse and far more disruptive - this is why the mid cycle is in-person to ensure that we're all in the same TZ
16:27:37 <odyssey4me> the focal point of the mid cycle is to assess where we're at in terms of this cycle's deliverables, to identify anything that's at risk of not making it, and to address that risk
16:28:09 <mhayden> anything else on the mid-cycle for now?
16:28:19 <janki> mhayden: odyssey4me: understand. Will keep tracking etherpads :)
16:28:39 <odyssey4me> anything that's idea orientated or not specifically on this cycle's list can be discussed briefly and needs to take limited time and should only be for the purpose of seeding discussion to be had at the next summit
16:29:23 <mhayden> next topic?
16:29:32 <automagically> mhayden: ++
16:29:32 <odyssey4me> +!
16:29:36 <odyssey4me> :1
16:29:37 <mhayden> hah
16:29:38 <odyssey4me> bah
16:29:42 <mhayden> +3.14
16:29:51 <mhayden> #topic Release Planning & Decisions
16:29:58 <evrardjp> +$1
16:30:07 <mhayden> looks like 13.3.0 and 12.2.0 are on deck?
16:30:08 <evrardjp> $!
16:30:33 <odyssey4me> yeah, I've had feedback from RPC that the recent changes have broken some of the requirements
16:30:55 <odyssey4me> or more accurately, now that the requirements are being properly calculated, it's broken the builds
16:31:00 <automagically> Ruh roh
16:31:03 <evrardjp> :p
16:31:11 <odyssey4me> what that means is that I may have to revert a patch or two
16:31:31 <evrardjp> if we do things the right way now, why would you want to revert?
16:31:34 <odyssey4me> more testing is being done right now
16:31:36 <automagically> Is it not possible for RPC to adapt
16:31:57 <odyssey4me> yeah, we worked on that today but it seems that our requirements processing isn't working the way it's supposed to either
16:32:10 <automagically> Ah, so a melange of bugs
16:32:11 <odyssey4me> so we fixed one thing, but it's exposed another issue
16:32:21 <automagically> yaks as far as the eye can see ;)
16:32:24 <odyssey4me> yeah - so we're testing a bit more
16:32:35 <odyssey4me> I'll hold back the release requests until tomorrow.
16:32:44 <michaelgugino> that's why we have stable releases.  I think if more things are broken, we commit forward, not backward
16:33:00 <odyssey4me> it's likely that RPC will simply not do a SHA bump
16:33:24 <odyssey4me> OSA's build is right, but we need to also take care of our downstream consumers
16:33:39 <automagically> No disagreement there
16:33:52 <michaelgugino> if you broke a stable branch, sure.  But we still need to be able to implement features during a cycle
16:33:59 <automagically> So, we should expect to see some bugs show up in Launchpad with the result of the RPC testing?
16:35:08 <odyssey4me> automagically maybe, not sure right now - we're still at the stage of confirming that there is a bug
16:35:12 <automagically> k
16:35:24 <odyssey4me> anyway
16:35:30 <odyssey4me> on another note - I did the N2 rleease request
16:35:35 <odyssey4me> it does work
16:35:39 <mhayden> hooray!
16:35:55 <odyssey4me> I got the sweet spot between all the broken shenanigans. :)
16:36:08 <eil397_> : )
16:36:15 <odyssey4me> the last few weeks have been a bit rough and really exposed our need for cross-repo testing, which I'm working on.
16:37:14 <eil397_> integration testing it is infinite thing
16:37:21 <automagically> Happy to help out on getting more/better testing
16:37:22 <eil397_> recursive : - )
16:37:34 <mhayden> alrighty, open discussion time?
16:37:42 <evrardjp> fine for me
16:37:43 <mhayden> #topic Open Discussion
16:38:17 <eil397_> do we have etherpad to track centos support ?  I would like to work in it
16:38:18 <michaelgugino> I propose we add a requirements.yml to each role repository, so each role is a little more self-contained
16:38:28 <odyssey4me> I'd appreciate some eyes on https://review.openstack.org/347930 - it's python, and it's cloudnull... so I really don't understand what it's doing. :)
16:38:34 <odyssey4me> I can vouch only for the outcome.
16:38:41 <michaelgugino> I have written a script to do the work for us, so we can run the script each time we tag the commits on the osa repo
16:38:48 <mhayden> eil397_: not sure on that one
16:38:51 <michaelgugino> https://gist.github.com/michaelgugino/fc3fe3d635396f0c15df401fb087c0c4
16:39:14 <cloudnull> ^ awesome!
16:39:18 <michaelgugino> this will allow people that want to utilize just one of our roles an easy way to install the dependencies
16:39:18 <odyssey4me> michaelgugino what do you hope to achieve with this?
16:39:37 <automagically> michaelgugino: Cool
16:39:48 <odyssey4me> oh I see - for the role requirements
16:40:08 <odyssey4me> that's nifty and should probably go in the openstack-ansible-ops repo for now
16:40:13 <michaelgugino> say someone wants to just use our swift play or something.  This lets us put those requirements in each role, based on the role's meta, and the ansible-role-requirements.yml in the osa repo
16:40:26 <odyssey4me> I'd really rather not duplicate more stuff across all repositories
16:40:27 <automagically> eil397_ You can start one modeled on https://etherpad.openstack.org/p/openstack-ansible-newton-ubuntu16-04
16:40:55 <odyssey4me> I haven't done the tests repo.
16:41:06 <eil397_> automagically: thanks. will do
16:41:08 <odyssey4me> #action odyssey4me to request the creation of the tests repository
16:41:25 <DrifterZA> Tend to aggree with odyssey4me, ansible-ops repo seems the best way to do specific builds
16:41:37 <michaelgugino> currently, there isn't an easy way to install the requirements if you just want to use one or two roles.  You have to dig through the meta, and then check the role requirements file from osa, and manually install each requirement or build a requirements.yml yourself.
16:41:55 <mhayden> speaking of openstack-ansible-ops -- i could use another look at my improvements for osa-differ -> https://review.openstack.org/344866
16:42:16 <odyssey4me> michaelgugino does it resolve the requirements recursively?
16:42:44 <michaelgugino> no, I don't believe so
16:43:01 <michaelgugino> I could make it do that, I suppose
16:43:15 <odyssey4me> it's kinda rebuilding ansible-galaxy
16:43:48 <evrardjp> I agree odyssey4me
16:43:55 <evrardjp> we should fix our usage then
16:44:04 <odyssey4me> hmm, ok I think this is best suited as a tool in the ops repo for now
16:44:32 <odyssey4me> it could perhaps be useful to have an ansible-role-requirements.yml file in each repo which contains the bits it needs
16:44:44 <michaelgugino> yeah, that's why I wrote the script
16:44:48 <odyssey4me> that tool could possibly used to do the initial generation
16:45:02 <jmccrory> is there a plan to publish osa roles to galaxy?
16:45:05 <odyssey4me> ok, that should be fine
16:45:06 <evrardjp> that's if we don't care about the meta
16:45:21 <odyssey4me> jmccrory yes, but it's still in discussion between infra and ansible
16:45:22 <evrardjp> jmccrory's question is valid
16:45:31 <jmccrory> ah ok
16:45:31 <evrardjp> because that's the limiting factor
16:45:33 <odyssey4me> there are some things that can't be automated right now, which infra want to automate
16:45:45 <michaelgugino> it uses the meta of each role to determine which roles from osa to include in requirements.yml
16:45:49 <automagically> Versioning of the roles with semver will be desirable then
16:46:20 <odyssey4me> michaelgugino unfortunately that is not enough, because roles depended on also depend on roles
16:46:40 <evrardjp> automagically: galaxy doesn't enforce semver versioning. it just wants tags
16:46:41 <odyssey4me> right now the role requirements can largely be derived from the test requirements and the meta
16:47:13 <michaelgugino> yes, but I'm using osa + meta to generate them because osa has the specific sha's we want.
16:47:37 <odyssey4me> for a role requirements file in each role we would not want SHA's
16:47:40 <michaelgugino> so, you update sha's in osa, commit, then run this script, then update each role's masters
16:47:45 <odyssey4me> ansible will fetch the latest tag by default
16:48:04 <michaelgugino> that won't work for tagged releases, like mitaka, we depending on specific versions for each role
16:48:11 <odyssey4me> I'm definitely not keen to create another place to manage SHA's
16:48:19 <evrardjp> could we discuss this usage on the mid-cycle? it's a use case of osa, it's interesting
16:48:28 <automagically> evrardjp: ++
16:49:02 <palendae> Does it need to wait?
16:49:07 <odyssey4me> michaelgugino FYI the tags are applied to all repositories simultaneously
16:49:10 <palendae> I'm concerned the mid cycle is already bulging with topics
16:49:20 <evrardjp> not that I require more topics there, but it would help understand to meet irl
16:49:23 <odyssey4me> palendae yep, we will likely have to prune the list
16:49:35 <mhayden> evrardjp gets one point for using irl
16:50:03 <palendae> Point taken, but lots of stuff we discuss on IRC could also be done IRL, yet we carry forward :)
16:50:26 <automagically> haha
16:51:09 <odyssey4me> michaelgugino for now I suggest putting the tool in the ops repo so that people can use it
16:51:16 <mhayden> ICW to meet IRL ASAP at the HQ
16:51:17 <michaelgugino> ok, sounds good to me
16:51:20 <odyssey4me> submit a basic description of what it's for and how to use it
16:51:37 <michaelgugino> but, it just generates requirements.yml files for each role, so not of particular use to people outside of us
16:51:41 <michaelgugino> ok
16:51:45 <mhayden> okay, we're reaching the end of the hour -- anyhting else?
16:52:43 <mhayden> ...
16:52:51 <mhayden> thanks everyone! :)
16:52:56 <cloudnull> everything is awesome!
16:53:00 <cloudnull> :)
16:53:00 <andymccr> cloudnull: +2
16:53:03 <mhayden> #endmeeting