avij / centos / centos.org

Forked from centos/centos.org 5 years ago
Clone

Blame static/minutes/2014/september/centos-devel.2014-09-15-13.01.log.txt

c3b3e1
13:01:06 <bstinson> #startmeeting
c3b3e1
13:01:06 <centbot> Meeting started Mon Sep 15 13:01:06 2014 UTC.  The chair is bstinson. Information about MeetBot at http://wiki.debian.org/MeetBot.
c3b3e1
13:01:06 <centbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
c3b3e1
13:01:27 <bstinson> #meetingname CBS-Infra-2014-09-15
c3b3e1
13:01:27 <centbot> The meeting name has been set to 'cbs-infra-2014-09-15'
c3b3e1
13:01:52 <bstinson> #chair alphacc Arrfab kbsingh bstinson MerlinTHP_
c3b3e1
13:01:52 <centbot> Current chairs: Arrfab MerlinTHP_ alphacc bstinson kbsingh
c3b3e1
13:02:45 <bstinson> #topic Is this a good time to meet?
c3b3e1
13:02:54 <MerlinTHP_> Well, it works for me :)
c3b3e1
13:03:51 <alphacc> Me too if we keep it under 30 min
c3b3e1
13:04:01 <bstinson> Good, I think we should make this a regular thing (weekly, or every-other-week) for a while until we run out of things to talk about
c3b3e1
13:04:09 * MerlinTHP_ nods.
c3b3e1
13:04:11 <bstinson> short meetings are good
c3b3e1
13:04:17 <alphacc> I think weekly is good for now.
c3b3e1
13:04:39 <MerlinTHP_> Agreed, i imagine we can find things to talk about
c3b3e1
13:04:57 <wolfy> works for me too. although I am just a lurker
c3b3e1
13:05:18 <bstinson> #agreed Weekly meetings on Monday at 13:00 UTC
c3b3e1
13:06:36 * lalatenduM is here too
c3b3e1
13:06:54 <bstinson> #topic SIG/Developer authentication
c3b3e1
13:07:39 <alphacc> so far cbs has his own CA, I don't know the status of git.c.o auth
c3b3e1
13:07:53 * MerlinTHP_ assumes it's ssh key auth
c3b3e1
13:07:59 <MerlinTHP_> Can anyone confirm?
c3b3e1
13:08:08 * kbsingh is here
c3b3e1
13:08:14 * gwd is here
c3b3e1
13:08:17 <bstinson> we also need to worry about the lookaside cache
c3b3e1
13:08:42 <MerlinTHP_> I'd be tempted to start from a default position of "what does fedora infra do?"
c3b3e1
13:09:01 <MerlinTHP_> If only that they've solved a lot of this stuff, and have existing tooling
c3b3e1
13:09:10 <bstinson> I think FAS is on the radar
c3b3e1
13:09:24 <kbsingh> i am not sure if FAS is indeed on the store for CentOS though - is it ?
c3b3e1
13:09:38 <MerlinTHP_> I've heard it mentioned, but nothing conclusive.
c3b3e1
13:09:49 <kbsingh> there certainly hasent been any movement on that front - FAS was brought up a few times, but only in line with other potential solutions as well
c3b3e1
13:09:49 <gwd> What's FAS?
c3b3e1
13:09:57 <Arrfab> alphacc: atm git.c.o uses his internal auth DB
c3b3e1
13:09:58 <kbsingh> gwd: the Fedora Accounting System
c3b3e1
13:09:59 <MerlinTHP_> Fedora Account System
c3b3e1
13:10:24 <MerlinTHP_> I'm not sure we really want to build something from scratch.
c3b3e1
13:10:33 <alphacc> Arrfab: but gitblit does support ssl cert ?
c3b3e1
13:10:45 <kbsingh> git.centos.org can more or less do anything, includiung ldap, krb, shared certs, shared ca, pub certs, internal pipe backend for auth or even static files
c3b3e1
13:10:51 <kbsingh> alphacc: yes
c3b3e1
13:10:57 <MerlinTHP_> What does g.c.o do now?
c3b3e1
13:11:13 <kbsingh> MerlinTHP_: flat file, internal auth
c3b3e1
13:11:24 <MerlinTHP_> I suppose we're at the point of not having a huge userbase to reeducate
c3b3e1
13:12:24 <kbsingh> are we talking purely in the context of git.centos.org + cbs.centos.org ? I guess having FAS like system would help if were to come up system wide for all of .centos.org - and we can move wiki + bugs + forums + other things to it as well
c3b3e1
13:12:41 <MerlinTHP_> I'd suggest that ideally the latter
c3b3e1
13:13:15 <MerlinTHP_> In addition to FAS, I'd be tempted to throw IPA into the ring as an option too.
c3b3e1
13:13:48 <MerlinTHP_> I spend a fair amount of time in $dayjob getting stuff to auth against our IPA instace.
c3b3e1
13:14:04 <Arrfab> MerlinTHP_: such discussion started too, but the scope is wider than just cbs+git which is supposed to be the "to be discussed points" today
c3b3e1
13:14:06 <alphacc> kbsingh: yes. In term of interaction between cbs/git we just need people to be able to create branches at the git level
c3b3e1
13:14:26 <MerlinTHP_> Arrfab: agreed.
c3b3e1
13:14:38 <MerlinTHP_> Seems silly to build something just for cbs & git, though
c3b3e1
13:15:34 <kbsingh> how would branches in git.c.o work - at the moment, the distro brach is locked - noone can commit to those. and I've been working to have branch name be the sig name for someone
c3b3e1
13:15:37 <alphacc> MerlinTHP_: I think it's better to test the workflow for building and defer auth for later.
c3b3e1
13:15:54 <kbsingh> eg. VirtSig people will need to work with their own branch - but wont be able to create and push to other ones, unless they had acl's for other sig's as well
c3b3e1
13:16:21 <MerlinTHP_> alphacc: I'm just a bit worried about getting people too familiar with something that we might well change later
c3b3e1
13:16:21 <Arrfab> MerlinTHP_: agreed too, but it would be good to know what are the blockers now on the git/cbs status. and if common auth is the real issue, then another meeting around centralized auth can be foreseen :-)
c3b3e1
13:17:19 <alphacc> MerlinTHP_: the koji part won't change, and educate user to access git with pass or ssh key doesn't seems an issue for our audience
c3b3e1
13:17:27 <MerlinTHP_> alphacc: fair enough
c3b3e1
13:17:40 <gwd> kbsingh: So I think we need to be able to have dev branches from which we can issue a pull request.
c3b3e1
13:17:50 <alphacc> MerlinTHP_: I would agree if it was for everybody.
c3b3e1
13:18:29 <MerlinTHP_> alphacc: I'm a bit worried that you don't scale, though ;)
c3b3e1
13:18:37 <MerlinTHP_> alphacc: you're doing all the account creation by hand atm?
c3b3e1
13:19:04 <alphacc> MerlinTHP_: correct. this is part of this week documentation effort.
c3b3e1
13:19:05 <Arrfab> MerlinTHP_: yes, but afaik less than 10 people have access through approved SIGs
c3b3e1
13:19:17 <kbsingh> in terms of forward-looking-planning, my estimate on user accounts to end of the year 2014 is 50
c3b3e1
13:19:27 <MerlinTHP_> OK
c3b3e1
13:19:27 <kbsingh> and in the next 18 momths, is to grow that to 150
c3b3e1
13:19:44 <bstinson> which is not so bad
c3b3e1
13:20:10 <kbsingh> most SIG's are only going to have a few people commiting into git.centos.org right ? I'm counting on the biggest ones having 10
c3b3e1
13:20:18 <Evolution> I still think long-term it should be automated, rather than blocking on a specific person
c3b3e1
13:20:27 <Evolution> or group of people.
c3b3e1
13:20:31 <MerlinTHP_> Mm
c3b3e1
13:20:48 <MerlinTHP_> This is one of those "FAS has already solved this issue" things, tbh
c3b3e1
13:21:04 <kbsingh> gwd: would'nt that be local though ? eg. if come of people want to do local branches ? or are you saying that people will need commit access to git.centos.org where from a 'privileged' account can merge into the production branch and issue a build req ?
c3b3e1
13:21:06 <Evolution> yeah. fas or a bit of scripting around ipa.
c3b3e1
13:21:11 <MerlinTHP_> Evolution: exactly
c3b3e1
13:21:27 <alphacc> Evolution: yes agreed
c3b3e1
13:21:36 <MerlinTHP_> TBH I personally like IPA a lot, but I'm trying not to be too biased ;)
c3b3e1
13:22:01 <kbsingh> gwd: if we want the push coming to git.centos.org - we might need to workout some sort of a convention for personal branches.
c3b3e1
13:22:18 <kbsingh> automate everything
c3b3e1
13:22:49 <gwd> kbsingh: Well it doesn't need to be on git.c.o, if that's what you mean; it could be on gitorious/github/some other public repo.  But wherever it is, we want to be able to build from it.  At least, I assume the burden of testing to make sure it builds properly should be on the person sending the pull request, not on the person potentially doing the pulling. :-)
c3b3e1
13:23:04 <kbsingh> specially, since automation is the only way to really make sure there is a 'user-exiting' cleanup process as well
c3b3e1
13:23:15 <MerlinTHP_> Just bear in mind that koji needs config for each git server you want to pull from
c3b3e1
13:23:26 <kbsingh> MerlinTHP_: it will only pull from git.centos.org
c3b3e1
13:23:27 <MerlinTHP_> I'd recommend only having koji pull from g.c.o
c3b3e1
13:23:33 <MerlinTHP_> Right.
c3b3e1
13:23:39 <alphacc> yes
c3b3e1
13:24:02 <MerlinTHP_> So anything you want to build has to end up in g.c.o, even if people are pushing to github or whatever
c3b3e1
13:24:34 <Arrfab> MerlinTHP_: yes
c3b3e1
13:24:43 <kbsingh> yeah, its a good problem domain to fix, its the classic who CI's and how does the CI queue work
c3b3e1
13:24:46 <alphacc> MerlinTHP_: There is SRPM use case, but I really didn't find any good reason.
c3b3e1
13:24:47 <gwd> MerlinTHP: Then that would imply either 1) sending pull requests from trees that haven't been tested on koji or 2) having development trees on git.c.o so that things could be tested on koji before sending a pull request
c3b3e1
13:25:06 <kbsingh> i wonder if we can have people do scratch builds, and the results be a consideation for people doing the pulls
c3b3e1
13:25:16 <alphacc> gwd: koji should not become a CI.
c3b3e1
13:25:28 <MerlinTHP_> Yeah, koji isn't great for CI
c3b3e1
13:25:37 <kbsingh> i dont think gwd is talking CI though
c3b3e1
13:25:51 <MerlinTHP_> Right.
c3b3e1
13:25:53 <kbsingh> were not testing the code, per se - its just to make sure the branch is buildable
c3b3e1
13:26:04 <kbsingh> maybe --scratch builds might be a middle ground there ?
c3b3e1
13:26:05 <alphacc> Yes just a warning, casue I have koji users :)
c3b3e1
13:26:21 <gwd> Just because it build via an SRPM doesn't mean it will build from a git tree. :-)
c3b3e1
13:26:44 <MerlinTHP_> There's not that much difference between koji building a package and mock on a user box, as long as mock is using the koji repos.
c3b3e1
13:26:54 <kbsingh> gwd: right, but koji only ever builds from a srpm - the git is just where the srpm is stored, were never building from git
c3b3e1
13:27:15 <kbsingh> when koji gets a build-this, it git checksout, make it into an srpm - then does the mock run to build rpms out of it
c3b3e1
13:27:17 <MerlinTHP_> Well, koji pulls the source from git and builds a srpm
c3b3e1
13:27:24 <alphacc> kbsingh: yes
c3b3e1
13:27:24 <MerlinTHP_> Yeah, tha
c3b3e1
13:27:25 <MerlinTHP_> t
c3b3e1
13:28:13 <bstinson> (bringing it back in a little bit) it sounds to me like we aren't quite ready to talk about long-term auth
c3b3e1
13:28:21 <kbsingh> nutshell: gwd's point is that people need to be able to propose changes, without running their own buildsystems. right ?
c3b3e1
13:28:24 * MerlinTHP_ is getting that ;)
c3b3e1
13:28:28 <MerlinTHP_> +feeling
c3b3e1
13:29:30 <bstinson> what can we do in the short term to get people access to the lookaside caches? i know that's come up a couple of times
c3b3e1
13:29:45 <MerlinTHP_> Auth with the same SSL cert they use for koji?
c3b3e1
13:30:10 <alphacc> bstinson: I think we need at least docs on the process will be handled.
c3b3e1
13:30:27 <MerlinTHP_> The upload script for fedora's lookaside is public, and can be easily adapted to our cache
c3b3e1
13:31:07 <MerlinTHP_> I can hunt that out if there's interest
c3b3e1
13:31:07 <alphacc> MerlinTHP_: can it be part of centpkg ?
c3b3e1
13:31:11 <kbsingh> are we talking about https://git.centos.org/sources/ ?
c3b3e1
13:31:26 <bstinson> kbsingh: yes
c3b3e1
13:31:27 <MerlinTHP_> Yeah
c3b3e1
13:31:35 <kbsingh> the privileged path to that store is via ssh or rsync over ssh at the moment
c3b3e1
13:31:42 <Evolution> 868963
c3b3e1
13:31:43 <MerlinTHP_> Hmm
c3b3e1
13:31:58 <kbsingh> but its a flat filesystem, so a cgi script ( like what fedora use ) might be easy to adapt, and we can protect branches at the unix level
c3b3e1
13:32:09 <Evolution> 195082
c3b3e1
13:32:16 <kbsingh> ( ie. I can make sure the buildsystem and distro branches are owned by someone else )
c3b3e1
13:32:27 <kbsingh> Evolution: move your yubi key to a different usb port
c3b3e1
13:32:32 <MerlinTHP_> Heh
c3b3e1
13:32:36 <alphacc> ah ah
c3b3e1
13:32:39 <Evolution> bah, was dialing phone.
c3b3e1
13:32:47 <kbsingh> alternatively, folks - anyone needing to break into Evolution's 2FA accounts, you ahve about 180 seconds to use those two codes
c3b3e1
13:32:48 * Evolution moves laptop
c3b3e1
13:32:50 <MerlinTHP_> No, you weren't ;)
c3b3e1
13:32:55 <bstinson> heh
c3b3e1
13:33:18 <kbsingh> i need a better keyboard, way too many typos
c3b3e1
13:33:31 <bstinson> alphacc: to answer your question, it's already built into rpkg we just need to figure out how to say if a user has upload privs or not
c3b3e1
13:33:32 <kbsingh> so, what / how would centpkg integrate with the sources / lookaside push ?
c3b3e1
13:33:47 <MerlinTHP_> centpkg has upload support
c3b3e1
13:33:57 <MerlinTHP_> It needs tweaking for centos' cache layout
c3b3e1
13:34:11 <MerlinTHP_> It does an HTTPS request with the client cert for auth
c3b3e1
13:34:42 <MerlinTHP_> sorry, rpkg has that, centpkg can override that code
c3b3e1
13:35:02 <alphacc> ok
c3b3e1
13:35:14 <kbsingh> what do we need on the server to support that push ?
c3b3e1
13:35:31 <MerlinTHP_> A CGI script on an HTTPS server with some client auth config
c3b3e1
13:35:41 <MerlinTHP_> So cgi + httpd config
c3b3e1
13:35:47 <kbsingh> what sort of auth backend can that support ?
c3b3e1
13:36:05 <kbsingh> also, upload via https.... is going to need some multipart fluffery
c3b3e1
13:36:40 <MerlinTHP_> That bit is a solved problem, afaik.  rpkg already does it
c3b3e1
13:36:57 <MerlinTHP_> The server validates the client cert against our CA
c3b3e1
13:37:14 <MerlinTHP_> Needs a CRL to be able to revoke certs.
c3b3e1
13:38:14 <kbsingh> right, so this would then share the ca with koji ?
c3b3e1
13:38:19 <MerlinTHP_> Yeah
c3b3e1
13:38:39 <kbsingh> and we'd need to have git.centos.org also then use the same CA
c3b3e1
13:38:47 <MerlinTHP_> Mm
c3b3e1
13:38:55 <MerlinTHP_> IPA getting more attractive by the second...
c3b3e1
13:38:56 <MerlinTHP_> ;)
c3b3e1
13:39:31 <alphacc> if we keep the koji CA (and use it for soemthing else) we may want to move easy_rsa + git-crypt (for scaling issue)
c3b3e1
13:39:37 <alphacc> or FreeIPA ;)
c3b3e1
13:40:36 <gwd> I'm more of a stout man myself...
c3b3e1
13:40:40 <kbsingh> gitblit can maknss calls as well if that makes life easier
c3b3e1
13:40:53 <kbsingh> can make nss
c3b3e1
13:41:22 <kbsingh> from the git.centos.org perspective, we can use pretty much anything and it will consume it .
c3b3e1
13:41:27 * MerlinTHP_ nods.
c3b3e1
13:41:49 <kbsingh> there are 2 things that we need to protect though - (1) there is always going to be a privileged path for rhel sources and buildsystem feedback - both of those can never fail
c3b3e1
13:42:09 <kbsingh> and (2) we need a way to gurantee branch names and commit access to branch names is locked down
c3b3e1
13:42:33 <bstinson> does gitblit currently give you that control?
c3b3e1
13:42:34 <kbsingh> so if the auth setup is going to happen at koji CA - that needs to provide a user:sig name mapping which can be used to map users:branch
c3b3e1
13:42:34 <MerlinTHP_> Can gitblit do that per-branch stuff?
c3b3e1
13:42:38 <kbsingh> bstinson: yes.
c3b3e1
13:42:52 <MerlinTHP_> Hrm
c3b3e1
13:43:20 <MerlinTHP_> We need more than just a CA for this
c3b3e1
13:43:30 <MerlinTHP_> CA + something with groups and things like that.
c3b3e1
13:43:33 <kbsingh> I worked with the author of gitblit ( james moger ) to work that in, and I've made some more tweaks at this end that make it work quite nicely
c3b3e1
13:43:49 <MerlinTHP_> That's cool.
c3b3e1
13:44:10 <kbsingh> for the git code itself, and the lookaside cache - the privleged path is via ssh
c3b3e1
13:44:28 <kbsingh> and gitblit does not mind that, it will happy refresh local git content cache if it finds the underlaying storage changee
c3b3e1
13:44:53 <MerlinTHP_> I'd have assumed that git+ssh was the default push method anyway
c3b3e1
13:45:06 <kbsingh> fwiw, gitolite can also consume and implement a user:branch mapping
c3b3e1
13:45:37 <kbsingh> push mode for git is over https
c3b3e1
13:45:41 <MerlinTHP_> Oh, ok
c3b3e1
13:45:54 <kbsingh> thinking there is that if we need entity verification, an EV cert will give you that
c3b3e1
13:46:31 <MerlinTHP_> Do we have a cert revocation system for the current koji CA?
c3b3e1
13:46:48 <MerlinTHP_> If I lose my laptop with koji cert now, what happens?
c3b3e1
13:47:09 <alphacc> MerlinTHP_: we can revoke access to koji
c3b3e1
13:47:23 <alphacc> MerlinTHP_: no crl right now but agreed it's needed.
c3b3e1
13:47:55 <MerlinTHP_> Is that turn off the user, or turn off the cert?
c3b3e1
13:48:05 <MerlinTHP_> ( so to speak )
c3b3e1
13:48:16 <alphacc> MerlinTHP_: user
c3b3e1
13:48:21 * MerlinTHP_ nods.
c3b3e1
13:49:02 <bstinson> ok, let's start wrapping up
c3b3e1
13:49:07 <alphacc> MerlinTHP_: user-rsa when Arrfab show me it existed. I don't want to reinvent the wheel.
c3b3e1
13:49:16 <MerlinTHP_> alphacc: *nod*
c3b3e1
13:49:23 <alphacc> MerlinTHP_: easy_rsa
c3b3e1
13:49:26 <MerlinTHP_> Being a CA is a PITA.
c3b3e1
13:49:45 <MerlinTHP_> OK, so, do we have any sort of consensus? :)
c3b3e1
13:49:54 <MerlinTHP_> Or anything to have a consensus about
c3b3e1
13:50:34 <MerlinTHP_> koji requires either SSL or KRB auth, and we're using SSL.  Trying to use that for everything we can sounds appropriate?
c3b3e1
13:50:44 <MerlinTHP_> Sounds like g.c.o can use it
c3b3e1
13:51:07 <bstinson> so (if i'm understanding correctly), we want gitblit to talk to the koji CA but we need to work out some name:sig mappings, and we want to look at having the lookaside cache use the fedora-style cgi script
c3b3e1
13:51:08 <MerlinTHP_> We need a way to store cert / user / group / sig info
c3b3e1
13:52:00 <kbsingh> yeah, if we can get some groups info in there that would rock
c3b3e1
13:52:16 <MerlinTHP_> OK
c3b3e1
13:52:16 <kbsingh> if not, we can always store user:group mappings in gitblit itself, and just have it querry the CA for auth
c3b3e1
13:52:31 <MerlinTHP_> I reckon we probably want that centrally too
c3b3e1
13:52:41 <kbsingh> and i presume the upload script can do something with the same CA as well ... if so - then we should trial it - or start trialing it at git.dev.centos.org
c3b3e1
13:52:53 <kbsingh> yeah, ideally all the info would be in one place
c3b3e1
13:53:01 <MerlinTHP_> It's the httpd config rather than the script itself, but yeah
c3b3e1
13:53:40 <kbsingh> ah i see
c3b3e1
13:53:50 <kbsingh> but will that be able to map user's to dir names ?
c3b3e1
13:53:59 <bstinson> once all that's in place we can sculpt centpkg around our setup
c3b3e1
13:54:04 <kbsingh> eg. if someone is locked to branch 'virtsig' they can only upload into <packagename>/virtsig/
c3b3e1
13:54:17 <MerlinTHP_> kbsingh: ok, that bit would need script changes :)
c3b3e1
13:54:40 <MerlinTHP_> the httpd-level stuff is authn, the authz would need to be in the script, I think
c3b3e1
13:55:28 <bstinson> Is MerlinTHP_ volunteering to look at that for the next meeting?
c3b3e1
13:55:36 <MerlinTHP_> Sure
c3b3e1
13:56:30 <bstinson> ok, great!
c3b3e1
13:56:35 <MerlinTHP_> :)
c3b3e1
13:56:47 <MerlinTHP_> Running out of meeting
c3b3e1
13:56:48 <kbsingh> when are we meeting next ?
c3b3e1
13:56:54 <MerlinTHP_> Same time next week?
c3b3e1
13:57:09 <kbsingh> ok, weekly works, but longer term we should think about making it bi-weekly
c3b3e1
13:57:13 <MerlinTHP_> Sure
c3b3e1
13:57:18 <kbsingh> maybe do ~ 6 weekly ones ?
c3b3e1
13:57:21 <bstinson> #info Next meeting: Monday 22-Sept 2014 13:00 UTC
c3b3e1
13:57:36 <bstinson> kbsingh: that's reasonable
c3b3e1
13:57:40 * MerlinTHP_ nods.
c3b3e1
13:58:12 <bstinson> #info We will be doing 6 weekly meetings, then moving to a bi-weekly schedule
c3b3e1
13:58:14 <lalatenduM> works for /Me
c3b3e1
13:58:24 <MerlinTHP_> Is there a meetbot give-merlinthp-an-action command? ;)
c3b3e1
13:58:41 * MerlinTHP_ should read the manual
c3b3e1
13:59:20 <lalatenduM> does "#action" work
c3b3e1
13:59:21 <bstinson> #action MerlinTHP_ Research lookaside cache authentication and upload permissions
c3b3e1
13:59:35 <MerlinTHP_> Ah :)
c3b3e1
13:59:42 <bstinson> i think i said that right
c3b3e1
13:59:52 <MerlinTHP_> Works for me.
c3b3e1
13:59:54 <bstinson> anything else that needs to go in the minutes?
c3b3e1
14:00:07 <kbsingh> is someone going to look at storing user:groups in the koji auth layers
c3b3e1
14:00:18 <MerlinTHP_> I'll have a think about that too
c3b3e1
14:00:19 <kbsingh> there must be something like this already - since users are limited to some tag's and targets
c3b3e1
14:00:27 <kbsingh> cant those just be the groups and sig names as well
c3b3e1
14:01:32 <alphacc> kbsingh: user are limited to the tagging action not to some target. This policy stuff need investigation. I don't think there is a group directive.
c3b3e1
14:02:54 <MerlinTHP_> OK, so we done with the meeting? :)
c3b3e1
14:02:59 <bstinson> gwd: i think that was you who sent a message to -devel with other agenda items, sorry our discussion sort of trampled over yours
c3b3e1
14:03:00 <alphacc> #action alphacc investigate koji policy for cbs.
c3b3e1
14:03:08 <bstinson> hopefully there will be time for an open-flood next week
c3b3e1
14:03:53 <bstinson> #info send agenda items for next week to the centos-devel@centos.org
c3b3e1
14:04:01 <bstinson> 1 minute warning before I close the minutes
c3b3e1
14:04:16 <MerlinTHP_> I'm good.
c3b3e1
14:04:44 <kbsingh> same here
c3b3e1
14:05:02 <kbsingh> i think were going to need some of these sessions of just open chat before we start working on and only on agenda items.
c3b3e1
14:05:04 <alphacc> ok with me.
c3b3e1
14:05:28 <bstinson> sure thing
c3b3e1
14:05:31 <bstinson> #endmeeting