21:02:22 #startmeeting refstack 21:02:23 Meeting started Thu Mar 27 21:02:22 2014 UTC and is due to finish in 60 minutes. The chair is rockyg. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:02:25 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:02:28 The meeting name has been set to 'refstack' 21:02:45 Who's here? 21:02:54 I'm here 21:03:04 agenda: code reviews, py26 gate, tomorrows f2f, tcup methods 21:03:25 Open discussion.... 21:03:37 CatherineD? 21:03:45 Waiman? 21:03:46 zehicle: ? 21:03:51 o/ 21:04:08 Hi Rocky, I am here 21:04:29 * zehicle running late 21:05:02 also on the agenda but we can push it to tomorrows f2f .. docs 21:05:21 Okay, since zehicle is running late, let's talk #topic py26 21:05:40 #topic py26 21:05:51 okay .. so I'm planning to remove py26 from the gate all together 21:05:58 What do we need to do to get it working? 21:06:02 a lot 21:06:02 project stats for lot, 90 days 21:06:52 rockyg: so far nobody has expressed interest in running our code in a py26 env .. and a lot of our code does things that didn't exist in py26 21:07:19 plus .. for those who want centos and rehl .. they can still run py27 21:07:26 But, tthe first pass is for Havana. and I though RHEL was py2.6? 21:07:37 Ah. 21:07:49 rockyg: so it doesn't matter what env we are testing .. it matters what the test is running from 21:08:06 Maybe we get a redhat contributor to help/work on 2.6? 21:08:06 the thing running refstack.org right now needs to be py.27 or py3 21:08:26 rockyg: maybe .. but right now having py2.6 in the gate slows down our merges 21:08:45 py 26 is old .. we're hanging on to the past 21:08:45 True. 21:09:15 With time being precious, let's deal with 2.6 after we have working 2.7 21:09:16 So unless we have any objection I am going to remove py26 from the gate 21:09:27 o/ 21:09:41 rockyg: im not sure I'll ever care about py26 . but we can bring it back into discussion at a later time 21:09:44 I don't think we want to gate on py3 yet, either. 21:10:03 rockyg: I don't agree with you there 21:10:12 esp since we pass py33 tests now 21:10:53 how about we vote to not bother with 2.6 until someone shows a need for it? 21:11:11 I vote we vote on it later 21:11:20 and put it out of our heads 21:11:44 #action table 2.6 discussion for sometime in the future, by request 21:11:54 thank you 21:11:59 next topic .. code reviews 21:12:14 Now that zehicle is here, let's go back to reviews 21:12:23 #topic code reviews 21:12:45 So several things got merged today including teds change for discovery of config options 21:12:54 I made some minor dock changes.. 21:13:02 zehicle has a few reviews that need some work 21:13:24 I've got the pep8 fixes in 21:13:45 zehicle: I don't see the review yet 21:14:10 cannot upload from the office.... in a hour or so 21:14:15 it doesn't exist until there is a review ;) 21:14:42 I've been working on https://review.openstack.org/#/c/81402/ .. will push it later today 21:15:09 #link https://review.openstack.org/#/c/81402/ 21:15:54 I think that covers the open reviews for now unless anyone else has anything? 21:15:55 I've got similar network issues... can be on corporate network and get emails, or on guest net and get work done. 21:16:15 Anything major besides zehicle's stuff still out there? 21:16:19 I will need some support on the last step of TCUP 21:16:25 because the execute test is not working for me yet 21:16:31 zehicle: I can make time for you this afternoon 21:16:33 thanks 21:16:58 rockyg: I merged all the other open reviews today .. I think we're abandoning joshua's reviews from last week in favor of zehicle 21:16:58 Do we want to do tcup next or f2f? 21:16:58 have you been able to try the stuff to prep the environment? 21:17:18 I was pushing tcup for last because it could drag on 21:17:28 zehicle: yes .. I have 21:17:43 +1 21:18:06 I passed CatherineD's instructions on to our infra guy. Haven't heard back from him yet weher he could make it work. 21:18:25 rockyg: all of that will simplify 21:18:36 we'll work out the details tomorro w 21:18:46 Thought it would, but wanted to get him started. 21:18:55 So, on to f2f? 21:19:08 sure 21:19:18 #topic F2F 21:19:31 so I have the room booked from 1-3:30 21:20:01 (And that 3:30 is a hard stop) 21:20:20 I'm working on getting sphinx to generate docs. Some of it is working. 21:21:05 the agenda for the f2f is mostly centered around our docs 21:21:30 Is the f2f strictly for doc? Have room for code discussion? 21:21:44 We'll do handoff of davidlenwell's verbiage and drawings tomorrow. and yes, code is also happening tomorrow. 21:21:57 yeah.. we'll cover both .. 21:22:12 but my primary objective is to make sense of our docs . 21:22:19 we can have some stuff happening in parallel 21:22:37 Do you have a drwing/graphics package to recommend I have preloaded? 21:22:57 I use a cloud based one 21:23:09 gliffy 21:23:26 I've used that before, but it was part of Confluence. 21:23:47 I'll check it out after this meeting. 21:23:52 sure .. 21:24:01 okay.. so on to tcup.. 21:24:06 So, code and docs tomorrow. Plus the Defcore meeting. 21:24:19 #topic tcup 21:24:22 wait .. when is the defcore meeting ? 21:24:39 zehicle? 21:24:51 Maybe it's today? 21:24:57 * zehicle checking 21:25:38 #link https://etherpad.openstack.org/p/DefCoreElephant.7 21:25:45 It's on 4/1 at 2pm 21:26:04 Ah. Not today *or* tomorrow. Good. 21:26:13 this is good 21:26:16 its monday 21:26:18 oh, there is something tomorrow too 21:26:23 an Interlock w/ the TC 21:26:28 monday == tuesday 21:26:38 Oh, right. I knew there was something. 21:26:42 #link https://etherpad.openstack.org/p/openstack-designated-sections 21:26:49 Friday 3/28 @ 8pm UTC 21:27:13 'which is 1pm PDT 21:27:22 yes 21:27:32 so we'll be here at piston durring that 21:27:54 So, first hour tomorrow we'll be at least listening in while working 21:28:09 it's all about designated sections 21:28:23 OK, that' means we should be on time. 21:28:25 does that immidiately effect us .. because we do have limited time 21:28:30 so, it's not likely to hit RefStack stuff just yet 21:28:50 as fcarpenter said the 330 end is a hard stop 21:29:07 we'll be kicked out of that room and will have to go to the local bar to keep talking 21:29:34 * zehicle buying tx to join in RefStack happy hour 21:29:47 Which is your favorite work bar? 21:30:05 back to tcup. 21:30:06 rockyg: as I am new here I don't have one yet .. 21:30:24 yes .. so we've had some discussion in the past about what is the right way to run things in docker 21:30:28 Thirsty Bear is a bit far, but really good;-) 21:30:31 zehicle: do you want to state your position 21:31:19 so, I've been working to make TCUP into something that runs RefStack 21:31:32 basically, it puts all of into a container and then kicks off the test 21:31:47 so it should be the same to use it from the dev setup, production infratructure or TCUP 21:32:03 that makes it really really light for people to use 21:32:16 basicially, it's just run one py file 21:32:26 and it gets the container and runs the tests inside it 21:32:34 I also want to discuss the generating the docker file from a template vs env variables 21:33:02 I like the template idea. 21:33:07 the template approach is a non-starter for me 21:33:10 rockyg: there is a reason it won't work 21:33:13 I have some issues with it 21:33:25 zehicle: can you spell those out please 21:33:27 1st, it makes the code more complex for generating it 21:33:42 2nd, it means that the container is unique each time instead of standard 21:33:54 #2 is actually what I am hung up on 21:33:59 #2 is my biggest issue 21:34:08 No the container is not unique for each run 21:34:17 IMHO, the goal is that we have a standard environement that everyone uses 21:34:25 and we pass in the unique stuff as env variables 21:34:32 very easy to repeat and troubleshoot 21:34:44 if we have custom templates then it's hard to troubleshoot 21:35:01 and we can't upload the standard template for everyone to use in a single shot 21:35:27 so it sounds to me like maybe we have a slight communication problem about what the template is used for and wather or not it caches or makes every container unuiqe 21:35:49 Question: lots of people are expressing a desire to "run [api|acceptance|custom|etc] tests against their cloud" Mostly ops guys. How does this play in the two options? 21:35:51 if you look at the way we build the container, we push the most stable variables up front. This will allow docker to cache .. and at the same time will rebuild image when it detected changes .. 21:36:25 the tcup script I've been working on does exactly that - you put in the differents as environement variables 21:36:37 I can send out the log files after the meeting you will see the evident of caching 21:37:00 catherineD: please do .. 21:37:11 that said .. 21:37:32 Evironment variables only work in the case of local docker container .... we plan for it to work with gearman remotely 21:37:45 will send dthe logs ... 21:37:49 catherineD: the gearman remote thing won't use docker at all 21:37:57 it will run the scripts that docker runs 21:38:02 +1 21:38:03 doesn't need docker 21:38:14 the scripts should work anywhere 21:38:23 and refstack.org CANNOT have docker as a dependancy 21:38:46 I'm trying to keep the docker stuff as a wrapper, not an internal dependency 21:38:51 The scripts will work anywhere but will paring with RefStack 21:38:53 +1 21:39:31 so for remote execution from the gui.. refstack should be able to be configured to use docker .. but in those instances I think that running them locally will be fine 21:40:00 env variables are a more secure way of passing in creds .. and also keeps the container more of a container and less of a one off gererated thing for this one test 21:40:24 then docker doesn't have to genreate anything at all and all of it is cached 21:40:34 +1 21:40:37 +1 for security .. 21:40:54 and rockyg as far as ops people using it to run there own tests .. nobody is stopping them from modifying things in the tcup thing for their own build 21:40:54 I've been pretty happy w/ using env variables for this 21:41:02 (it was not my original approach) 21:41:16 one of the improvement that we will be doing is to improve security now that the code are merged 21:41:19 how about passing in as arg? the current execute_test.py takes them as command line arg. 21:41:24 so catherineD I'd like to see us transition from the template generated docker into one that uses env variables 21:41:34 effectively, the env variables ARE passed as args 21:41:44 waiman: ^^ that 21:41:45 the code sets them when the container is started 21:41:58 we need to discuss who will set the ENV 21:42:01 so the thing that calls the script from the command line can just pass them in 21:42:20 catherineD: we can whiteboard tomorrow if that will help 21:42:34 When you actually run the tests you will realized that some on need to pass in variables ... 21:42:34 my code (and Josh's code) both build a set of input parameters to the container that set the env variables needed to run thetests 21:42:43 yes let's discuss stomorrow 21:42:51 Whiteboard sounds good. 21:43:13 okay then .. I think we can move to open discussion 21:43:35 #topic Open Discussion 21:43:56 oh, one minor note: Docker 0.8 has a bug that makes the Dockerbuild files return EOF 21:44:06 I had to upgrade to 0.9.1 21:44:18 zehicle: thats one reason I was so hesitant to use docker at all 21:44:20 just so you don't have to repeat my learning exprience 21:44:25 its in a super early alpha stage 21:44:34 riddled with bugs and a moving target 21:44:34 I understand the concern 21:44:58 thats why I will continue to support the need for it .. but refstack.org won't be dependant on it 21:45:20 and in our docs we have to be clear that it is just one of many options 21:45:34 what would be an alternative for the remote runs? 21:45:58 a vm running the py scripts that run the tests and clean up afterwards .. probably triggered from gearman 21:46:19 rockyg: its essentially the same thing .. just not in a throw away container 21:46:32 my goals are to make us hostable by infra long term 21:46:35 I figured everything but the gearman part. Would gearman be a requirement, though? 21:46:37 they aren't going to play with docker 21:46:59 gearman would be a requirement if you chose that option .. just like docker would be if you wanted to use that 21:47:12 gearman is also a lot more mature and in heavy use by the infra team now 21:47:40 OK. I'll need to document options for remote execution. In case others don't want to use docker. 21:47:41 realistically, we should also be able to clone and run the code too! 21:47:43 so refstack.org will use gearman to queue tests 21:48:07 thats what local tests are for 21:48:24 Question on tests: are we cloning them fro the Havana branch? 21:48:26 so far the three options for triggering tests are : local, tcup, and remote (gearman) 21:48:50 rockyg: we abslutely should be 21:49:34 damnit my spelling .. absolutely 21:49:45 davidlenwell: 3 options from refstack web ui, right? 21:49:51 waiman: yes 21:49:56 I think we need a way to advertise the branch the tests are cloned from in the test log and the UI. 21:50:00 3 options for the refstack ui 21:50:19 rockyg: file a blueprint 21:50:27 Will do. 21:50:30 is the documentation for running the UI up to date? 21:50:33 we are selecting the version at the time of making the tests 21:50:34 davidlenwell: i have one related to that 21:51:04 thats right .. you ahve one for displaying the results 21:51:13 we talk about allowing users to pick version. each version will be mapped to a tempest url. 21:51:20 it should say what version .. so rockyg just add to the whiteboard of the existing blueprint 21:51:43 OK. 21:51:47 we also talked about allowing them to specify a url of a specific tempest branch they want to run 21:52:04 #link https://blueprints.launchpad.net/refstack/+spec/support-different-tempest-versions 21:52:33 davidlenwell: yes. i am working on this. 21:52:41 excelent 21:53:06 okay .. I think we all have lots of things to do .. lets all this meeting ajourned 21:53:06 I think my homework before tomorrow is to review all the BPs. 21:53:15 Hi,this is praveen from Dell,Ireland,working for Rob on Refstack project 21:53:16 rockyg: good plan 21:53:21 Call to end... 21:53:22 hi Praveen-dell 21:53:31 Hi David 21:53:37 Praveen-dell is from my team here 21:53:48 He's time zone disadvantaged (in the UK) 21:53:49 Are you in Ireland? 21:53:51 Praveen-dell: we're just wrapping up here .. wanna jump over to #refstack and introduce your self 21:54:04 sure 21:54:05 will do 21:54:06 thanks 21:54:18 OK, then time to move back to our "home" 21:54:20 can we have a short topic about potentially changing time? 21:54:33 Here? Now? 21:54:43 #topic meeting time 21:54:47 zehicle: what time did you want to change to ? 21:54:49 if we're going to change it for next week 21:54:55 thursdays at 2 was your idea 21:55:08 I'm fine with keeping it how it is 21:55:10 true, did not have anyone from Europe at the time 21:55:15 ahh 21:55:26 how much time is Praveen-dell going to have for refstack ? 21:55:34 Yeah. It's likely at least midnight start for Praveen 21:55:52 GMT 5pm or 6pm should be fine for me 21:56:21 So, 11am or noon PDT 21:56:26 so I'd like to keep meetings as static as we can .. if we keep moving it we're just going to loose poeple . 21:57:00 +1 21:57:06 Sorry. 10am or 11am 21:57:16 10am is fine for me 21:57:20 11 is a nogo 21:57:43 10am works for me. 21:57:50 any objections to changing the meeting time to 10am pst on thursdays? 21:58:02 that's pDt 21:58:13 I can make that work 21:58:27 whats the diff between pdt and pst ? 21:58:33 good for us 21:58:48 Standard vs Daylight savings 21:58:49 I'd like to agree that we'll follow daylight time 21:58:55 sorry, follow the changes 21:59:14 I'm good with it .. zehicle wanna change the meeting time on the wiki thing ? 21:59:19 +1 will do 21:59:20 thanks 21:59:29 Thursdays @ 10 am Pacific 21:59:29 yes, thanks. 21:59:37 thanks for the time change 21:59:42 likely to stay on this channel 21:59:52 just update the email list 22:00:05 Yeah. I know QA alternates between this time and the new time on the meeting channel. 22:00:42 Time! 22:00:46 last call. 22:01:05 #endmeeting