19:04:59 <jeblair> #startmeeting ci
19:05:00 <openstack> Meeting started Tue Dec 11 19:04:59 2012 UTC.  The chair is jeblair. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:05:01 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:05:04 <openstack> The meeting name has been set to 'ci'
19:05:57 <jeblair> let's make an agenda now -- who has topics?
19:06:10 <fungi> cla stuff, git-review...
19:06:11 <clarkb> nova testr, weekend project moves
19:06:40 <fungi> looks agendafied enough to me
19:06:57 <jeblair> ttx wants updates on stuff later in the meeting
19:07:14 <jeblair> so in order of least to most interest to ttx:
19:07:34 <jeblair> #topic git-review
19:07:41 <fungi> yep
19:08:09 <fungi> so clarkb has put together a skeleton for a test suite: #link https://review.openstack.org/17552
19:08:59 <fungi> i've started playing with that some, want to see what we can plug in from #link https://etherpad.openstack.org/Exy0u2IYpO
19:09:13 <clarkb> I am not entirely sure that it is worth much, but it was an itch I had to scratch
19:09:28 <fungi> also, i've started conversing with marcin on #link https://review.openstack.org/14953
19:09:32 <clarkb> at the very least it should help point out some of the difficulties in testing git-review with unit test like tests
19:09:48 <fungi> yes, very promising
19:10:11 <fungi> as for 14953, i'm interested in feedback from the group on the direction there. he raises some excellent points
19:10:32 <clarkb> ok, if I manage to do one thing today I will make sure that looking at that change is the one thing
19:11:03 <fungi> particularly in respect to being able to define discrete error codes to enable easier feedback to gerrit admins from less-experienced users
19:11:40 <fungi> that exhausts what i have on git-review for the moment. anybody else have anything for that topic?
19:12:16 <clarkb> for testing, it would be a whole lot easier if git-review became an importable python script
19:12:42 <clarkb> so that may be something we want to look at doing if automated testing becomes important
19:12:47 <fungi> yes, which could be as simple as wrapping in main(): and checking the calling namespace at the end of teh script
19:12:51 <jeblair> clarkb: that sounds very reasonable
19:13:30 <clarkb> thats all I had
19:13:40 <jeblair> #topic nova testr
19:14:14 <clarkb> nova testr is really picking up steam. mordred's DB fixture change was merged, and all of my test bug fixes have been merged
19:14:54 <clarkb> mordred thinks we really need to continue having html test result output, so the next thing that I will be working on is making a subunit consumer that spits out html
19:15:35 <clarkb> other than that run_tests needs to be ported (I feel like we will lose the battle if that doesn't happen) and run-tox.sh will need to be updated to hande nose and testr results
19:15:42 <jeblair> yeah, i think that will be really helpful
19:16:04 * fungi agrees
19:16:08 <jeblair> the html output will be helpful
19:16:28 <jeblair> clarkb: i'd like to see run_tests.sh do less over time...
19:16:44 <jeblair> to sort of head toward being a thinner and thinner wrapper around tox, at least for the important bits
19:16:57 <fungi> i'd like to see run_tests.sh be documentation of how ci invokes the testsuite, and nothing more
19:17:02 <jeblair> to try to address the "tests are run two ways" problem
19:17:06 <clarkb> ++
19:17:25 <jeblair> fungi: yeah
19:17:37 <jeblair> clarkb: so i mean, not suggesting you solve all those problems right at first...
19:17:59 <clarkb> that is a good idea. It should be straightforward to push fungi's suggestion to run_tests.sh and see what reviewers say
19:18:00 <jeblair> clarkb: but maybe that can influence your direction as you hack on run_tests,
19:18:39 <fungi> run_tests.sh does have the benefit of being immediately obvious, easy to find, and something lots of people already know to run
19:18:50 <clarkb> lifeless has been super helpful and we have added features to fixtures and testrepository to help make this happen
19:18:53 <fungi> as opposed to burying invocation instructions in a HACKING file
19:19:18 <jeblair> clarkb: lifeless said that you and mordred wanted to get rid of tox.  i'm assuming he was remembering the wrong word.
19:19:29 <fungi> npse?
19:19:32 <fungi> er, nose?
19:19:42 <mordred> nose
19:19:46 <mordred> we want to get rid of nose
19:20:01 <clarkb> mordred: I think you did mention how sourcing the tox venv and run testr run --failing
19:20:06 <jeblair> good.  glad we're on the same page. :)
19:20:17 <clarkb> is useful. that doesn't get rid of tox just changes the workflow in places
19:20:17 <mordred> clarkb: yes. I mean, people should learn how to use testr
19:21:07 <fungi> mordred also enjoys herding cats in his spare time
19:21:27 <clarkb> tox will be sticking around I think.
19:21:34 <clarkb> any other questions comments concerns about testr?
19:22:09 <jeblair> #topic project moves / zuul server move
19:22:31 <jeblair> mordred: your changes for the ci->infra rename ready?
19:22:45 <mordred> jeblair: they can be by this weekend - they need a re-base
19:22:56 <mordred> (a new project got added)
19:23:13 <jeblair> i need to propose my zuul puppet changes this week.  let's assume i can get that proposed by the end of tomorrow
19:23:38 <jeblair> then we sholud be ready to do both of those at once
19:23:52 <jeblair> mordred: 9am PST sunday good for you?  or should we do 10am?
19:24:20 <mordred> jeblair: 9 is great
19:24:26 <fungi> so 1700z
19:24:30 <jeblair> ttx: ping
19:24:53 <jeblair> okay, i'll send out an email announcement today or tomorrow
19:25:14 <fungi> jeblair: i'm assuming we want to block off ~3 hours given the list of changes
19:25:29 <jeblair> fungi: yeah, a little more time is probably a good idea for this one.
19:25:36 <fungi> wfm
19:25:59 <clarkb> and as a reminder I probably won't be able to participate
19:26:08 <clarkb> as  Iwill have spent saturday in leavenworth
19:26:35 <jeblair> clarkb: cool.  fungi: will you be around?  it's not necessary, but just wondering.
19:26:46 <fungi> yes, wouldn't miss it
19:26:57 <fungi> happy to help
19:27:13 <jeblair> cool, anything else about sunday's outage?
19:28:04 <fungi> sounds like no
19:28:15 <jeblair> #topic CLA project
19:28:29 <fungi> ttx may or may not care about this one
19:28:48 <jeblair> yeah, i think he does.  hopefully he'll show up soon.
19:28:52 <fungi> i've got proposed documentation updates tracked at #link https://etherpad.openstack.org/cla-maintenance-2012
19:28:59 <fungi> review/input appreciated
19:29:16 <fungi> proposed announcement draft there too, but with a made-up date for now
19:29:49 <fungi> still working on the sphinx patch, since there's several places which need touching
19:30:12 <fungi> also putting together a proposed mechanism to do group management within jeepyb/puppet, but no patch uploaded yet
19:30:47 <fungi> was looking for some direction there... would we want to do group management for projects within puppet rather than directly through the gerrit webui?
19:31:00 <jeblair> fungi: no, i think we just need bootstrapping in puppet
19:31:02 <fungi> or just initial members to bootstrap new project groups?
19:31:10 <fungi> okay, i'll go that route then
19:31:26 <fungi> had one other question too, which may be more for foundation people...
19:31:34 <jeblair> fungi: and then the core/drivers groups should be self-owned in gerrit
19:31:41 <fungi> what's the plan with the ccla and the usgcla?
19:31:51 <fungi> leave those processes as-is for now?
19:31:54 <clarkb> the self ownership change is simple (change the flag on the create group call)
19:32:07 <jeblair> fungi: but having said that.. maybe we sholud consider management in gerrit -- it would mean code review for adding new people, which is cool.  but i'm not sure it's necessary.
19:32:27 <jeblair> fungi: i still lean toward self-management in gerrit.  but if someone feels strongly the other way, speak up.  :)
19:32:29 <fungi> jeblair: i can go either way. there are obvious benefits to either solution
19:32:52 <jeblair> fungi: yes, i think we stay out of the ccla and usgcla...
19:33:04 <jeblair> fungi: _because_ everyone, even those, still need to agree to the individual one
19:33:18 <jeblair> fungi: which basically means that's all we care (or even can care) about
19:33:49 <clarkb> for self managed, the -drivers of -core group(s) would have permissions to add and remove people on their own?
19:33:54 <clarkb> if so then I think that is the way to go
19:34:00 <jeblair> clarkb: yep
19:34:07 <fungi> jeblair: okay. so that said, the usgcla instructions claim that the individual should *not* sign an icla. do we do group-cla for that then?
19:34:34 <jeblair> fungi: oh how weird.  i guess if it comes up, sure.  :)
19:34:48 <fungi> maybe that's something which is not implemented
19:34:54 <ttx> pong
19:34:57 <fungi> okay. cool enough with me
19:35:02 <fungi> ttx!
19:35:04 <jeblair> fungi: yeah, if we need it, we can just add it to the table real quick.
19:35:31 <jeblair> ttx: we're talking about cla stuff
19:35:39 <ttx> catching up
19:36:08 <fungi> mordred: toddmorey: any updates on the foundation integration?
19:36:13 <jeblair> toddmorey: want to let people know about your efforts
19:36:31 <toddmorey> sure, sorry… colliding meetings
19:38:08 <toddmorey> ok, so the site has a live endpoint that returns the status code for a member and logs that transaction. I believe Stef thought that was enough to store.\
19:38:30 <toddmorey> I'm bouncing back to this after the election nomination process, so I'm working to pull up my notes.
19:39:03 <fungi> to add, we have review-dev pointed at that contact store url as of a couple weeks
19:39:13 <ttx> fungi: nice work on documentation
19:39:24 <fungi> ttx: still in progress, of course
19:39:41 <jeblair> fungi, toddmorey: is that the production or a dev site?
19:40:03 <toddmorey> well, the endpoint that hits the member database is production.
19:40:08 <fungi> jeblair: the url looks production to me, and i gather we're testing it with non-live appsec and gpg key
19:40:42 <fungi> and we'll add a new appsec key and gpg keypair in hiera when we roll out the production change
19:40:50 <jeblair> are there issues with combined dev and prod data?
19:40:54 <jeblair> as in -- toddmorey do you need to clear out any data, and do we need to at some point stop pointing the dev gerrit at it?
19:41:18 <toddmorey> I'd like to know a clear cut-over so I can indicate it in the logs as such.
19:41:52 <jeblair> okay, if it's just a matter of knowing the timestamp, that should be easy, i don't think it'll require special planning
19:42:13 <toddmorey> but they could be also manually reviewed if required. there's nothing destructive about the presence of the data, it would just pollute any reports…. but if I mark it, then we'll be good.
19:42:15 <jeblair> we'll have a definite cutover time when we reconfigure the production gerrit to do this
19:42:26 <toddmorey> minor coordination effort required, but easy to do
19:42:56 <fungi> will there be a dev system we want to repoint review-dev at then?
19:44:12 <clarkb> having one would be nice as a way to work through potential problems (especially since this will be new)
19:44:12 <toddmorey> yeah, let me deploy that to staging and keep it stable for dev purposes
19:44:41 <fungi> also, i think we want some foundationy people to go over #link https://review-dev.openstack.org/static/cla.html (if they haven't already)
19:44:45 <jeblair> toddmorey: cool -- one of the things we'll definitely want to do is test new versions of gerrit on review-dev, so making sure the cla integration still works against a staging server will be important
19:44:55 <toddmorey> That will be the first external interaction with the staging environment, so might need to figure out what happens if staging is down or maybe have another environment specifically for this purpose.
19:45:45 <ttx> fungi: want a sanity-check that it's not different from the original ? Or are there any change we need to validate ?
19:45:46 <toddmorey> right, for sure. that makes sense. if it's okay for it to be occasionally in flux (for minutes, usually) then we can use the existing staging environment.
19:46:11 <toddmorey> jeblair and I plan to talk more about how to bring the www into the ci processes, too, so they'll be more closely coupled.
19:46:46 <ttx> toddmorey: that should simplify a few updates where we are forced to put you in the loop
19:46:52 <jeblair> oh, so i heard that the organization mentioned in the cla needs to change
19:46:59 <jeblair> fungi: so my best info is that is currently wrong
19:47:18 <jeblair> #action jeblair ask jbryce for the real official new CLA text
19:47:33 <clarkb> ++ to www being more ci like
19:47:50 <fungi> to propose changes which might be needed before production
19:47:50 <fungi> it was ripped from the wiki version, but some reformatting was necessary
19:47:51 <fungi> since it's legalese, i don't want to do stuff without oversight
19:47:51 <fungi> changes can be proposed against #link https://github.com/openstack/openstack-ci-puppet/blob/master/modules/openstack_project/files/gerrit/cla.html
19:47:59 <toddmorey> it will. we're eager, too. excited about being an official participant.
19:48:18 <fungi> yikes. i think i just lagged heavily
19:48:23 <jeblair> toddmorey: yeah, we're getting pretty good at adding new projects, so it should be pretty easy once the code is ready for public consumption
19:48:26 <ttx> toddmorey: at least your contributions will be recognized as such :)
19:48:57 <jeblair> yeah, i keep seeing 12 second lags :(
19:49:26 <fungi> mine was, like, a minute or two
19:49:49 <jeblair> cool, so it sounds like we have my action item...
19:49:50 <toddmorey> sorry… lag time in the chat? Or hitting the www? what's lagging (besides my feeble mind)?
19:50:01 <fungi> irc lag, sorry
19:50:12 <jeblair> then getting review of some of the docs and other changes fungi linked to...
19:50:34 <jeblair> and then we're more or less _technically_ ready to make the change?
19:50:35 <toddmorey> gotcha. the word 'lag' just makes me jumpy. The pagers in my head go off.
19:50:56 <jeblair> (which will obviously involve planning/scheduling/notification, etc)
19:50:56 <toddmorey> right, with just a quick ping to me to let me know when we cross over.
19:51:07 <fungi> jeblair: toddmorey: works for me
19:51:41 <jeblair> cool.  also toddmorey and i will chat with jbryce today and make sure we're all on the same page
19:51:54 <jeblair> fungi: do you want to continue planning for the change?
19:52:08 <fungi> also please clarify what's going to happen with the contributors page in the wiki (i assume it will be abandoned?)
19:52:15 <jeblair> fungi: yes
19:52:18 <fungi> jeblair: yeah, i can continue planning, sounds like
19:52:35 <jeblair> #action fungi plan CLA cutover
19:52:39 <fungi> yay for movement~
19:52:42 <fungi> !
19:52:49 <jeblair> #topic ttx all-request 6 minutes
19:52:53 <ttx> yay
19:53:05 <ttx> First thing is the wiki transition
19:53:11 <jeblair> (i'm hoping "cla" was a big part of ttx's agenda)
19:53:19 <ttx> There are a few pages that grew organigally on wiki.openstack.org website
19:53:37 <ttx> including http://wiki.openstack.org/releasestatus/
19:53:50 <ttx> I think we should move that off-wiki to another alias
19:54:13 <jeblair> ttx: can you research and make a list of such pages?
19:54:36 <fungi> www seems like a good place to me for that sort of stuff... as a user that's where i'd expect it at least
19:54:37 <ttx> jeblair: the only other is http://wiki.openstack.org/bugstats
19:55:06 <jeblair> ttx: what generates those?
19:55:07 <ttx> I'm currently rewriting it so that it's actually more resuable and puppetable
19:55:14 <clarkb> is there harm in that data moving to mediawiki then being transitioned to more permanent homes? or are we tring to get this done before we migrate?
19:55:14 <jeblair> ttx: is that a CGI, or a cron, or...?
19:55:16 <toddmorey> wait, one other thing that comes to mind was the secure store of the keypair on a CI server (as I'm storing pieces of the data encrypted). Monty, do you remember talking that part out?
19:55:20 <ttx> releasestatus is generated on a cron
19:55:25 <jeblair> clarkb: i think these are not wiki pages
19:55:25 <ttx> takes a few minutes to generate
19:55:31 <ttx> those are not wiki pages
19:55:42 <ttx> they just abuse apache conf. sorry about that
19:55:49 <clarkb> oh I see
19:55:50 <fungi> toddmorey: we have the contact store keys securely stored in hiera on our puppet master server, if that's what you're asking
19:55:54 <jeblair> toddmorey: i think we were going t
19:56:01 <jeblair> ack.  what fungi said.
19:56:18 <toddmorey> right, that's exactly what I was (trying) to talk about. Thx.
19:56:22 <ttx> so the idea would be to add a new host alias to the machine that currenbtly has wiki, so that we can advertise new url
19:56:28 <toddmorey> just wanted to ensure the data was usable later. :)
19:56:31 <ttx> and then we can move to do it correctly
19:56:33 * fungi nods
19:56:53 <jeblair> ttx: good plan
19:57:01 <ttx> status.openstack.org could host both
19:57:11 <jeblair> ttx: toddmorey may have thoughts about adding to to www.o.o... or
19:57:16 <ttx> No idea how to make that happen though
19:57:17 <jeblair> ttx: we can do that^
19:57:34 <jeblair> ttx: we have a general purpose host for static content called static.o.o
19:57:44 <ttx> hmm
19:57:51 <jeblair> ttx: we could make status.openstack.org a vhost on that, and add your scripts in via puppet
19:58:11 <jeblair> ttx: (not suggesting your url be static.o.o, that's just the real hostname for reference)
19:58:16 <ttx> jeblair: sure, that sounds like the long-term solution
19:58:36 <ttx> in the mean time I don't want to lose the pages when we move the wiki
19:58:39 <jeblair> #action jeblair register status.openstack.org in dns pointing to current wiki ip
19:58:57 <ttx> like I said, I'm actually rewriting the releasestatus code
19:59:04 <jeblair> #action ttx pack up status scripts for installation on static.o.o via puppet
19:59:10 <ttx> it's on bzr, will be on github when I'm done
19:59:25 <clarkb> and someone will need to add a redirect on new wiki.o.o to status.o.o for those two pages
19:59:56 <ttx> clarkb: maybe yes
20:00:01 <jeblair> yeah, the wiki cutover is coming up soon, so i think you're right clarkb
20:00:14 <clarkb> I can edit the vhost for new wiki.o.o
20:00:19 <ttx> not a big deal as long as the new pages are linked from the wiki
20:00:40 <ttx> we are off-time, I'll complain more next week
20:00:40 <clarkb> #action clarkb setup redirect from new wiki to status.o.o for bustats and releasestatus
20:00:41 <jeblair> #action clarkb add redirects to status.o.o on new wiki host
20:01:15 <jeblair> ttx: thanks! it has been very helpful.
20:01:15 <clarkb> ttx: feel free to complain at us in -infra too :)
20:01:18 <jeblair> #endmeeting