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