19:01:02 <jeblair> #startmeeting infra
19:01:03 <openstack> Meeting started Tue May 12 19:01:02 2015 UTC and is due to finish in 60 minutes.  The chair is jeblair. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:01:06 <openstack> The meeting name has been set to 'infra'
19:01:09 <ianw> o/
19:01:11 <jeblair> #link agenda https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting
19:01:11 <jeblair> #link previous meeting http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-05-05-19.03.html
19:01:11 <nibalizer> o/
19:01:12 <krtaylor> o/
19:01:29 <jeblair> #topic Announcements
19:01:33 <jeblair> #link design summit schedule http://libertydesignsummit.sched.org/type/design+summit/infrastructure#.VVJOMuSVtpg
19:01:54 <jeblair> that's what i pulled together out of the etherpad we were working on
19:02:03 <peristeri> o/
19:02:13 <jeblair> it is, as always, subject to change, especially this week
19:02:35 <krotscheck> o/
19:02:44 <jeblair> you'll note that the "work sessions" have boring titles but actual descriptions of what they entail
19:02:59 <pabelanger> o/
19:03:07 <anteaya> yay for boring titles
19:03:18 <jeblair> the intent (this is an openstack-wide thing, not an infra decision) is to keep people from just showing up because the title looks interesting
19:03:35 <jeblair> so while we might expect a little bit of an audience (though it's still not encouraged) for the fishbowl sessions
19:03:58 <jeblair> the work sessions should be much less of a 'show'
19:04:16 <jesusaurus> o/
19:04:20 <jeblair> and then the meetup has no fixed agenda or even a description attached
19:04:54 <jeblair> so while we still have things that we think we're going to hack on going in, but we can decide on our agenda on that day
19:05:14 <jeblair> any questions or comments?
19:05:18 <pleia2> there's also a translations session on *monday* that some of us should try to attend (I'm running it with Daisy), details coming together here https://etherpad.openstack.org/p/Vancouver-I18n-WG-session I expect we'll want use some time on Friday for this work too since all the right people will be together in person (and time zone!), like we did in Paris
19:05:56 <jeblair> pleia2: what's the time slot for that?
19:06:11 <pleia2> jeblair: tentatively 2:50pm - 3:30pm
19:06:37 <pleia2> the etherpad will be updated if that changes, and I'll try to let people know
19:06:50 <mordred> fyi - I will be in an ansible session monday afternoon- anyone who wants to talk about the new ansible modules is welcome to come
19:07:10 <mordred> this is part of the "associated projects get space near the summit" program
19:07:13 <anteaya> presentation or discussion?
19:07:19 <mordred> discussion
19:07:26 <anteaya> cool, I would like to attend
19:08:14 <jeblair> #topic Actions from last meeting
19:08:21 <jeblair> fungi check our cinder quota in rax-dfw
19:08:27 <jeblair> not sure if fungi is back yet
19:08:31 <jeblair> #action fungi check our cinder quota in rax-dfw
19:08:37 <jeblair> #action jeblair make the priority effort gerrit topics more visible to reduce the need to shout for reviews in this meeting
19:08:53 <jeblair> i am almost there ^
19:09:00 <jeblair> i think i'll be able to get to that this week
19:09:01 <tchaypo> mordred: is there a link to a schedule thing for that?
19:09:38 <mordred> tchaypo: nope - I'll try to get people info
19:09:47 <fungi> i am back now
19:09:54 <fungi> sorry about that
19:10:02 <pleia2> wb fungi
19:10:11 <fungi> and no, i did not get around to checking our quota ;)
19:10:21 <jeblair> excellent, action item already action itemed!
19:10:35 <fungi> your precognitive skills are beyond compare
19:10:37 <pabelanger> mordred, Ya, plan to attend the ansible stuff too.  See that the vibe is like
19:10:54 <jeblair> #topic Schedule next project renames
19:11:02 <jeblair> i don't want to do this now, does anyone else? :)
19:11:07 <anteaya> ha ha ha
19:11:12 <fungi> post summit
19:11:39 <mordred> nope
19:11:47 <jeblair> yep, let's do this next post summit
19:11:49 <jeblair> #topic Priority Efforts (Downstream Puppet)
19:11:49 <fungi> i have to catch a flight very early saturday, so er, friday afternoon would even be a bit of a stretch for me
19:12:03 <clarkb> ya and everyone is busy enough with summit prep
19:12:10 <jeblair> nibalizer: you pinged?
19:12:30 <nibalizer> yes so https://review.openstack.org/#/c/178887/ is part of a plan cooked up in -infra
19:12:38 <nibalizer> as a way to accoplish the linked spec
19:12:49 <nibalizer> so sorry for anyone who is administratively -2'd for that
19:12:59 <nibalizer> the dependent change (causing the admin -2s) has merged I think at this point though
19:13:04 <nibalizer> erp
19:13:23 <nibalizer> erp this is the review i meant https://review.openstack.org/#/c/180783/
19:13:46 <fungi> #link https://review.openstack.org/180783
19:13:55 <nibalizer> jeblair: point is, I think the only refactors I needed to do touching o_p::template and o_p::server are done
19:13:57 <jeblair> oh this is the template reorg?
19:14:03 <nibalizer> so those admin -2's are no longer needed
19:14:05 <nibalizer> jeblair: yes
19:14:19 <jeblair> nibalizer: excellent, i will remove them asap, thanks
19:14:31 <clarkb> and for those following along the -2s were on other changes to avoid conflicts
19:14:33 <nibalizer> this spec http://git.openstack.org/cgit/openstack-infra/infra-specs/tree/specs/server_base_template_refactor.rst
19:14:39 <anteaya> clarkb: thanks
19:14:48 <nibalizer> jeblair: well thats what I think... do you concur that we dont' need the -2's any more?
19:15:22 <nibalizer> better link: http://specs.openstack.org/openstack-infra/infra-specs/specs/server_base_template_refactor.html
19:15:45 <jeblair> nibalizer: they were mostly to make your life easier and avoid lots of rebases, so i'm good if you're good :)
19:16:01 <nibalizer> okay, good :)
19:16:12 <nibalizer> then they can be removed, thanks for helping with that
19:16:22 <jeblair> np
19:16:25 <nibalizer> and thats all I had from a 'downstream-puppet' place
19:16:43 <jeblair> any other priority effort topics?
19:17:09 <clarkb> oh I have one
19:17:13 <fungi> no blockers to report for the stuff i'm working on anyway
19:17:30 <clarkb> jhesketh has written a devstack plugin for os-loganalyze, which will allow us to test that with real swift
19:17:42 <clarkb> just pointing it out because its a thing and not something we have done before
19:17:57 <jeblair> that's kinda cool :)
19:18:00 <fungi> great idea
19:18:00 <clarkb> but its possible nodepool may want to do something similar
19:18:06 <mordred> well, almost - we are doing functional testing with shade against devstack too
19:18:09 <mrmartin> askbot at my side
19:18:11 <mordred> however, I do agree it's super cool
19:18:14 <clarkb> as the next step beyond the "thsi is how you nodepool + devstack"
19:18:21 <clarkb> mordred: you aren't using a plugin are you?
19:18:24 <mordred> clarkb: no need to
19:18:35 <clarkb> oh right since shade isn't a service
19:18:54 <fungi> make cloud, point shade at cloud'
19:19:07 <mordred> I fully support the use of devstack nodes to test infra uses of openstacks
19:19:12 <jeblair> #topic Priority Efforts (Swift logs)
19:19:33 <jeblair> sorry, late on the topic switch there :)
19:19:58 * mordred hands jeblair a sad looking bowl of alfalfa
19:20:12 * jeblair ruminates
19:20:32 <jeblair> mrmartin: did you want to talk about askbot?
19:20:51 <mrmartin> yeap
19:20:52 <mrmartin> just a short comment here
19:20:54 <jeblair> 19:20 < jeblair> mrmartin: did you want to talk about askbot?
19:20:57 <jeblair> #topic Priority Efforts (Askbot migration)
19:20:58 <zaro> is swift log something we can setup for review-dev as well?
19:21:07 <mrmartin> ok, I'll be quick
19:21:25 <clarkb> zaro: it should be completely independent of review-dev
19:21:33 <clarkb> zaro: it is for zuul jobs
19:21:40 <mrmartin> so we have an issue with actual ask.o.o google auth, because it is deprecated, and need to change to g+
19:21:59 <clarkb> mrmartin: specifically openid right?
19:22:00 <zaro> clarkb: we can talk about it later since topic has turned.
19:22:11 <mrmartin> clarkb: yeap
19:22:34 <mrmartin> so we the askbot-devel (which is a remote github repo independent from us) contains all of the patches now
19:23:21 <mrmartin> but as we discussed previously, we need to consume askbot-devel from this github repo directly, which requires a lot of changes in puppet-askbot module
19:23:52 <clarkb> mrmartin: the big difference being pypi release vs source install?
19:23:53 <mrmartin> and to make the story nice, I was running into different issues that was related to askbot release management and the missing Q/A
19:24:00 <mrmartin> clarkb: yes
19:25:03 <jeblair> mrmartin: would they be so kind as to make a release?
19:25:14 <fungi> sounds like our askbot dev/sandbox server is going to turn into upstream askbot qa
19:25:46 <mordred> fungi: it won't be the first project that's the case for
19:25:46 <jeblair> fungi: it won't be a first for openstack :/
19:25:49 <mordred> wow
19:25:51 <fungi> hah
19:26:13 <mrmartin> jeblair: last time we agreed to use master branch and feature / development branch to separate the testing and release branches
19:26:21 <mrmartin> so the actual puppet-askbot covers that
19:26:26 <jeblair> oh ok
19:26:28 <fungi> mrmartin: well, that was for the askbot-theme repo, right?
19:26:40 <fungi> (or whatever it's called)
19:26:48 <mrmartin> yeah, askbot-theme was the easy part
19:26:55 <mrmartin> but we are doing the same for askbot-devel (the external one)
19:27:11 <jeblair> http://git.openstack.org/cgit/openstack-infra/puppet-askbot/tree/manifests/init.pp#n59
19:27:12 <mrmartin> so we don't need to push the version numbers of pip packages for every release
19:27:27 <jeblair> right now it only installs askbot via pip
19:27:32 <mrmartin> until the package maintainer keeps that policy
19:27:33 <mrmartin> yes
19:27:59 <mrmartin> so it is a major change, and it was the reason the I commented out all the askbot related resource in the current ask.o.o manifests
19:28:15 <mrmartin> and it is a great momemnt to change from precise to trusty
19:29:02 <jeblair> i'm starting to lose the narrative thread here... is there a proposal we should be discussing?
19:29:04 <mrmartin> so first we can deploy the askbot-staging.o.o based on new manifests, and if it works well, it is easy to upgrade the ask.o.o site
19:29:15 <fungi> i'm a little worried about trying to arrange another askbot production server migration in the next few days before so many of us pack up and ship out to vancouver
19:29:24 <fungi> but staging seems doable
19:29:36 <mrmartin> I'm sure we cannot to do the prod server migration before the summit
19:29:40 <clarkb> its also worth pointing out that issues like this are why we gave up on askbot in the past
19:30:08 <clarkb> its great that we are motivated to help fix things so ++ on making stuff go
19:30:15 <mrmartin> so the question here, fungi, do you have an idea how to deliver the askbot patches with google-plus auth changes within a reasonable time?
19:31:10 <mrmartin> I vote to keep the actual workflow, and deploy askbot-staging before the summit if we can, and do the prod migration after summit
19:31:14 <fungi> i guess it depends on how we define reasonable
19:31:21 <mrmartin> :)
19:31:28 <fungi> that seems like a timeframe i can help with
19:31:35 <jeblair> okay, so let me see if i can summarize: needed patches are in the upstream askbot repo.  they refuse to make a release.  you think the current state of the askbot upstream repo is not production ready.  you want to deploy from git on the staging site.  then you want to later deploy from git (what version?  some tested hash?) on the production site.
19:31:44 <fungi> i wanted to get back to reviewing your outstanding puppet patches for teh dev server today
19:32:10 * nibalizer also has the askbot puppet patches next in the stack of things to review
19:32:41 <mrmartin> jeblair: we deploy the master branch from askbot-devel repo, and they'll deliver dev patches into a separate branch
19:33:17 <mrmartin> so we can support rolling releases this way, and we don't need to handle the specific version numbers or tags for every new production grade release
19:33:18 <fungi> so basically "master" is intended to be their stable branch upstream, sounds like
19:33:23 <mrmartin> yes
19:33:45 <jeblair> ok, fwiw, we can deploy the latest pip release too
19:34:05 <jeblair> so deploying from git is not required in order to have auto rolling upgrades
19:34:28 <jeblair> deploying from git is fine if that's what we want to do, just wanted to make sure we weren't doing it solely because we didn't want to bump version numbers
19:34:40 <mrmartin> ok, but with this suggesting we'll deploy from git for staging and pip for production?
19:34:52 <mrmartin> I support to deploy from a single source
19:35:21 <mrmartin> ok.
19:35:22 <fungi> jeblair: keep in mind they're not "our" version numbers or "our" repos or "our" packages on pypi
19:35:30 <jeblair> fungi: i understand
19:35:36 <mrmartin> I know, but the same is true for pypi
19:35:56 <jeblair> we should deploy from whatever is appropriate for the project
19:35:58 <fungi> so it sounds like we want to deploy from git to get fixes which are not in the release packages
19:35:59 <mrmartin> so it will work until the app maintainer keeps the policy of master / feature branch commit
19:36:13 <jeblair> i was specifically responding to the idea that we should use git because mrmartin did not want to bump version numbers
19:36:43 <jeblair> if "upstream git master" is actually "the maintained stable distribution of askbot", that's fine.  i have no idea.  :)
19:36:51 <fungi> oh, got it. i interpreted that as we wanted to deploy from git because evgeny doesn't want to bump version numbers
19:36:52 <mrmartin> to clarify I don't have any problem with version numbers, I have a problem with a different method of deployment of staging and prod servers
19:37:59 <jeblair> mrmartin: okay, so you want to deploy both sites from git.  do you want both to track git master?
19:38:01 <mrmartin> jeblair: yes, so it's not an openstack project, and we just have a little influence what happens there
19:38:10 <fungi> got it. so if he's at least tagging versions in git and those are versions we want to use, it's easy to use one mechanism to deploy from a tag name or a branch or a specific sha
19:38:26 <mrmartin> no, the staging will track git / feature /development branch, and prod will track the master
19:39:07 <mrmartin> but it is up to us, because the Vcsrepo gives us the freedom to select between tags or master branch
19:39:26 <jeblair> okay.  i am surprised that the outcome of a discussion around whether askbot upstream can be relied upon to make reliable stable releases is "production should continuously track upstream master", but i will take your word for it :)
19:39:47 <fungi> that seems fine to me. it's not dissimilar to how we're consuming etherpad
19:39:51 <mrmartin> I've spent the last two weeks to remove bugs from the new release and reverse engineer why some non-documented config setting was changed
19:39:55 <jeblair> and yeah, if/when it breaks, we can always pin a tag or commit
19:39:59 <mordred> ++
19:40:01 <mrmartin> yes
19:40:08 <fungi> i mean, it's certainly not an ideal development model, but we're not the upstream devs
19:40:26 <mrmartin> it is not an ideal development model, I agree, but that's we have actually
19:40:53 <jeblair> #agreed switch puppet-askbot to deploy from git
19:40:56 <jeblair> yeah? ^
19:41:05 <mrmartin> in an ideal world I like to move-in the entire project under our gating / code review system, or build-up a proper governance model for the project
19:41:07 <mrmartin> yeap
19:41:20 <fungi> also having it deployed from vcsrepo in puppet makes it marginally easier for us to switch to a fork of the project if we absolutely have to
19:41:24 <jeblair> #agreed switch askbot-staging to CD from upstream git development branch
19:41:41 <jeblair> #agreed switch askbot production to CD from upstream git master branch (some time after openstack summit)
19:41:50 <jeblair> i have all that right?
19:41:58 <mrmartin> ok, great, thanks
19:42:00 <fungi> that looks correct to me
19:42:33 <jeblair> mrmartin: thanks, i think this discussion was really helpful
19:42:44 <jeblair> anything else on askbot?
19:42:53 <mrmartin> and deploy the askbot-staging if we can before the summit :)
19:43:35 <jeblair> right; time permitting :)
19:44:07 <jeblair> #topic Priority Efforts (Upgrading Gerrit)
19:44:18 <jeblair> so, i reckon we ought to chat about this
19:44:26 <jeblair> as fungi said: "this did not work as planned"
19:44:50 * fungi sighs
19:44:59 <jeblair> from my pov, we're safely back on 2.8, and we are not under high pressure to upgrade immediately
19:45:03 <zaro> no response from mailing list yet
19:45:03 <mordred> sufferring is defined as reality not meeting pre-conceived expectations
19:45:20 <mordred> jeblair: ++
19:45:28 <clarkb> jeblair: yup, stevebaker ran into some trouble though, was hoping stevebaker would respond to the upgrade/downgrade thread with details but I didn't see that
19:45:42 <jeblair> so i think the next steps are to reproduce the problem out of production, and when that happens, we can develop/confirm a fix, then talk about trying it again.
19:45:51 <mordred> agree
19:45:52 <zaro> any aftermath() from downgrade that i don't know of?
19:45:54 <fungi> one of the nova devs mentioned to me last night that the impact was "barely noticed" so maybe we do a much better job of shielding our dev community from this sort of havoc than we think we do at least
19:46:15 <jeblair> clarkb: er, do we have _any_ details on that trouble?
19:46:17 <clarkb> zaro: stevebaker does not have a working web client
19:46:35 <clarkb> jeblair: from what I could gather late last night when logged in stevebaker's web client throws and exception and does nothing
19:46:37 <mordred> I had some ideas on some ways in which we might want to structure review-dev to accomplish this - I will write them up in a spec
19:47:04 <clarkb> jeblair: he thought it may be because he had made settings changes to his account on the 2.10 side but looking at the accounts table where that appeared to be stored I didn't see anything off
19:47:24 <jeblair> fungi: yeah, but i know that a significant number of old changes were causing complete failures, and that in turn was taking out dashboards, queries, etc; so i think our state on 2.10 was unsustainable in the long term
19:47:36 <jeblair> mordred: thanks
19:47:56 <jeblair> i'm glad that people were able to get some work done while we futzed with it though :)
19:48:07 <zaro> mordred: clarkb and i discussed putting copying data from review to review-dev.
19:48:08 <fungi> jeblair: no question there, just saying i feel a little bit better about the actual perceived impact
19:48:36 <mordred> zaro: yup. I agree with that
19:49:12 <clarkb> jeblair: maybe someone else can look at that row in the accounts table and tell me if they notice anything off?
19:49:23 <zaro> i should clarify, we planned to copy over all the data with passwords removed.
19:49:26 <clarkb> I basically compared my account to stevebaker's
19:50:31 <fungi> oh, as far as dumping production data, i did successfully script stripping out the http passwords from a mysqldump at one point. i can dig that back up
19:50:48 <fungi> if it's of potential help
19:51:04 <clarkb> fungi: I think that would help yes
19:51:13 <zaro> also might need to simulate activity on review-dev somehow.
19:51:20 <jeblair> i think a quick spec for how to reconfigure review-dev would be good -- there are things we can do in the current setup that we may not be able to with a production copy, and vice versa
19:51:35 <jeblair> so would be good to get all on the same page there
19:51:45 <zaro> ++
19:52:13 <jeblair> and sounds like that's the next step for this effort
19:52:15 <fungi> generating a lot of load is probably not hard. simulating the nature of our production load is probably not going to be feasible but hopefully also unnecessary to reproduce the error
19:52:52 <zaro> should we hold off putting review data on review-dev until spec is reviewed?
19:52:55 <jeblair> anyway, thanks to everyone that worked on the upgrade, and sorry it didn't work out
19:53:11 <clarkb> oh maybe we can diff stevebaker's account row between previous 2.8 state and current
19:53:25 <clarkb> mordred: ^ maybe you can point me at where the old copy is
19:53:31 <jeblair> zaro: if we can, or at least let's not permanently delete anything from review-dev yet
19:53:41 <fungi> zaro: i think we probably should hold off, yes, we want to make sure we don't cause any information leakage or make a nuisance out of it
19:53:59 <mordred> clarkb: it's in root's home dir
19:54:03 <clarkb> mordred: thanks
19:54:07 <zaro> roger that
19:54:11 <jeblair> #topic Open discussion
19:54:38 <ttx> jeblair: do you plan to create skeletons for all etherpadds or shall moderators create each ?
19:54:47 <ttx> (infra track session etherpads)
19:54:49 <jeblair> probably goes without saying, but just in case, i don't think we'll have an infra meeting next week :)
19:54:58 <pleia2> :)
19:55:01 <nibalizer> https://review.openstack.org/#/c/178887/ hasn't converged so everyone go weigh in on that
19:55:13 <clarkb> it sounds like most of the momentum for puppet functional testing is behind beaker. Thats fine but one of the first things we will need to solve is how to configure module repos such that puppet tests the correct stuff in the gate and on a developers laptop
19:55:20 <zaro> clarkb: so what i meant was that logs on review-dev aren't accessible from gerrit.  would like to see that work.
19:55:31 <jeblair> ttx: oh good question; moderators i think
19:55:32 <pabelanger> quick note from me, grafyaml is shaping up nice.  Have a review up for it to pull under -infra: https://review.openstack.org/#/c/182045/
19:55:40 <ttx> ok, will create mine tomorrow
19:55:41 <jeblair> ttx: is there a summit etherpad page yet?
19:55:45 <pabelanger> still need to do governance review
19:55:46 <ttx> yes
19:55:51 <clarkb> jeblair: https://review.openstack.org/#/c/181694/ is an update to zuul-cloner that I think facilitates zuul-cloners use for beaker setup. Other reviews would be great too
19:56:00 <ttx> https://wiki.openstack.org/wiki/Summit/Liberty/Etherpads
19:56:04 <clarkb> zaro: I don't understand what you mean by that
19:56:19 <clarkb> zaro: are we talking about job logs? or are we talking about logs for the gerrit service itself?
19:56:44 <jeblair> ttx, mordred, clarkb: if you have a moment to create etherpads for the fishbowl sessions and add them to https://wiki.openstack.org/wiki/Summit/Liberty/Etherpads that would be great
19:56:50 <clarkb> jeblair: can do
19:56:51 <Rockyg> query  on next steps to get refstack.org up and maintained(well, monitored) in infra.  krotscheck helped get the webserver together and it's running on refstack.net (davidlenwell's vm) right now.
19:57:40 <fungi> Rockyg: a puppet module which deploys the service would be the next step
19:57:42 <mordred> Rockyg: general steps are that we need to get the dns transferred to jbryce if it's not already, then we'll want to get the puppet modules for running the webserver info infra repos
19:57:47 <krotscheck> fungi: Already done.
19:57:52 <jeblair> Rockyg: if you could write a spec for infra-specs that would be great :)
19:57:53 <mordred> woot
19:57:56 <fungi> mordred: dns looks taken care of now (for refstack.org)
19:58:00 <mordred> fungi: awesome
19:58:14 <Rockyg> kewl.  And the foundation has the dns
19:58:20 <fungi> krotscheck: oh! awesome. i somehow missed the puppet module
19:58:35 <krotscheck> fungi: It's not a project yet. Let me go make that pull request.
19:58:42 <krotscheck> (it's in github)
19:59:08 <jeblair> Rockyg: so the steps are: infra-spec, create puppet module, then we deploy it
19:59:13 <Rockyg> Also something to think about.  We need another dns (in one of the reviews, don't know which at the moment) and we might consider coming up with a process for foundation/infra server stuff
19:59:39 <zaro> clarkb: job logs
19:59:41 <Rockyg> And will create the infras spec shortly.  Probably not ready before after summit.
20:00:23 <jeblair> Rockyg: well, we have a process for creating servers: http://ci.openstack.org/sysadmin.html#adding-a-new-server
20:00:38 <jeblair> that's kind of our existential purpose :)
20:00:51 * fungi is a machine that makes more machines
20:00:55 <mordred> I like questioning my existential purpose
20:01:05 <Rockyg> jeblair: cool.  Just thinking about when the ownership is cross infra and foundation
20:01:07 <jeblair> (it could probably use an update; i'm working on that)
20:01:18 <jeblair> Rockyg: oh, we don't think in those terms
20:01:28 <jeblair> Rockyg: the project owns its own destiny
20:01:35 <jeblair> we enable the project to run itself :)
20:01:38 <Rockyg> Oh, good.  Perhaps we can discuss more at the summit.
20:01:43 <fungi> Rockyg: the foundation doesn't have any sysadmins. they're just a foundation. they employ a couple sysadmins and donate them to the infra team
20:01:43 <mordred> jeblair: ++
20:01:56 <Rockyg> Uh, but we're only stackforge so far?
20:02:11 <mordred> Rockyg: doesn't matter - we're all one big happy family
20:02:13 <ttx> ...
20:02:20 <Rockyg> and have a ways to go to get to big tent, but we are looking at what we need to get there :-)
20:02:21 <lifeless> o/
20:02:22 <jaypipes> do we have a TC meeting now?
20:02:23 <jeblair> and we should let the projcet run its governance now :)
20:02:23 <lifeless> erm
20:02:28 <mordred> jeblair: bah
20:02:29 <jeblair> #endmeeting