17:12:24 #startmeeting refstack 17:12:24 Meeting started Thu Apr 17 17:12:24 2014 UTC and is due to finish in 60 minutes. The chair is davidlenwell. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:12:25 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:12:27 The meeting name has been set to 'refstack' 17:12:32 roll call? 17:12:39 Here 17:12:45 here 17:12:57 morning 17:13:05 morning everyone 17:13:08 good evening 17:13:24 #topic summit session 17:13:57 catherineD: will you be able to attend the openstack summit? 17:14:16 Last I check the session is pre-accepted? 17:14:30 yes .. I think it will go through 17:14:35 we can only travel if it is accepted .. 17:14:46 okay .. so we'll know soon enough 17:15:39 yes .. only then we can make travel request 17:16:03 costs more that way.. I personally live in hope that it will be .. 17:16:07 but I was going to the summit anyways 17:16:31 good good, I think Rocky is too .. 17:16:38 okay moving right along 17:16:52 i would like to attend the summit 17:17:34 praveen_dell: tell rob you must attend ;) 17:17:45 #topic execute_test madness 17:18:28 So I was hoping for either more pushback on what I did in execute_test or a working tcup build from rob.. I guess he's going to work on it tomorrow 17:19:13 Last status is Ted waits waiting for davidlenwell: before making more change to execute_test? 17:19:40 catherineD: I posted a review of it and asked you gusy to review it durring the last meeitng 17:19:51 you understand what I mean :-) 17:20:23 since it was blocking rob from his work I merged the code 17:20:45 tedchang: did you get a chance to review it .. it was your code I started off with 17:21:07 They did 17:21:15 he didn't 17:21:27 both me and ray left comments on it 17:22:18 only on docker_buildfile.template not in the execute_test code it self 17:22:29 that actually is a good point .. 17:22:48 the docker_buildfile.template pulls the script from refstack .. that is one thing i want to change .. 17:22:53 ok so the code is merged .. 17:23:08 execute_test I looked but I have to try to really make sure it will work 17:23:14 I'd like for it to get the script from git rather than from an http call .. for one .. an http call is very insecure 17:23:40 to wget a file from a url then execute it leaves us open for man in the middle attacks 17:24:28 I don't forsee execute_test changing much in the future once its working .. so I don't want to keep this model .. 17:25:12 if you look at what I did I started to make execute_test an installable package with tempest as a dependancy 17:25:53 what I would love to do is get it into its own repo called "refstack-tester" or something and get it into pypy so that it can just be pip installed on testing nodes 17:26:38 what do you guys think about that ? 17:27:53 Here is Raymond last comment "The main purpose of using the get-script api is to make sure the script and the dockerfile are of the same version. Getting the script from github cannot guarantee they are of the same release." 17:28:38 that is a valid argument 17:28:50 but the api needs to be version locked moving forward anyways 17:29:18 so that the live copy of refstack.org gets api/v1 api/v2 and so forth .. 17:29:40 because refstack.org's api needs to be able to accept data from any version of the tester 17:30:25 I understand thats hard to do when things are changing rapidly .. but things can't keep shifting as much as they will int he beginings of a project 17:31:12 I have no problem with that ..... We need to focus ... at this point the most important thing is to collect data .. agree? 17:31:20 agreed 17:32:18 so what we have so far .. we are able to collect some data ... how do we enable others to collect data? are they willing to just run what we have that is working ? 17:32:24 Is this the Neutron group-policy meeting? 17:32:34 s3wong: no 17:32:36 s3wong: no this is refstack 17:32:37 alt 17:33:16 s3wong: we are at the meeting-alt channel 17:33:23 banix: Thanks 17:33:32 catherineD: so what we have so far doesn't allow that currently .. if rob can finish what he is working on we'll be able to collect data from anyone 17:34:12 We have been collecting data via Refstack path .. 17:34:34 catherineD: but that data is not going back to refstack.org's central database 17:34:52 the that is what we need to work on ... 17:34:54 we're missing the publish results part of the story 17:35:11 make sure that data can be sent back to centrol Refstack 17:35:35 should we concentrated on the send back center Refstack ? 17:35:45 possibly .. 17:36:03 Raymond had a TCUP version that is working ... 17:36:17 it may not be the final version .. we all understand that ... 17:36:32 are you reffering to the shell scripts ? 17:37:21 I refer to this one https://review.openstack.org/#/c/84320/ 17:37:45 yeah .. that one 17:37:51 this is a very quick thing that we put together just for data collection ... understand that it may no be final .. 17:38:05 i have tested existing tcup,it only builds the docker container and exports openstack properties on to docker container 17:38:16 I really want to see some other data ... 17:38:56 catherineD: so do I .. 17:39:16 we can focus on the send back data ... I have data that I collect from Havana (all in one) env that I can pulbish 17:39:30 so rob tells me he'll have time tomorrow to finish what he was working on .. the tcup.py aproach 17:40:24 that is .. sourcing an openstack.rc file that a user gets from the cloud they want tested 17:40:34 np .. just that we need data ... I found that there are more configuration in tempest.config that we need to consider ... that is why I would like to see more data from other env 17:40:45 then kicking off a script that grabs the already built container and runs it with the env variables 17:40:59 source openstack.rc is definitetly not enough .. 17:41:12 it should be able to auto discover the rest 17:41:16 one example ... network .. 17:41:56 upstream tempest is close to having the networking auto discovery built .. 17:42:05 if you env has more than one network and your network name is not named "private" or "public" so need to confgure those parameters ... 17:42:26 not sure how long it will take for that code to make it into havana stable 17:42:38 discovery is also a problem .. let say I discover 10 networks then which one should I use? 17:42:51 that is going to require some thought .. 17:43:06 lets get back to a network / config discussion offline 17:43:12 we're low on time 17:43:19 yes .. a lot more configuration needed as I start to collect data 17:43:27 okay . we're running low on time so I am going to move to another topic 17:43:46 sure 17:43:47 #topic #infra testing 17:44:19 So while at pycon over the weekend I had a chance to chat face to face with jim blair 17:44:32 he's ptl of infra .. the group we want to host this thing long term 17:44:58 and he sorta shattered some of my dreams about how I wanted to trigger tests using pure openstack things.. 17:45:06 praveen_dell: may be take a look at this one for some idea https://review.openstack.org/#/c/84320/ of how we run test ... Let's move to the next subject 17:45:19 but then explained a workable solution that might be a better idea anyways 17:45:36 @catherineD sure 17:45:59 that is essentially to just use the infra system to run tests 17:46:50 davidlenwell: that is refstack will be hosted on infra system? 17:46:51 without explaining in detail how infra works .. 17:47:02 catherineD: yes .. it will 17:47:12 but even before it is .. they can host the testing env 17:47:24 they have a thing called nodepool 17:47:28 and another thing called zuul 17:47:57 nodepool just makes a bunch of ready to run .. one time use vm's for running tests .. their config is passed to them with a yaml file 17:48:27 when they boot up they ask zuul for jobs.. zuul gives them a job and then keeps track of its progress 17:48:39 So we can piggy back on that 17:48:52 create our own node type for nodepool 17:49:22 and im paraphrasing here .. but essentially it will keep an army of ready to run single use vm's at our disposal 17:49:40 that we can then trigger and let run and report home with results 17:52:37 anyways .. long story short .. my original gearman spec is close to what we'll end up with but not exactly .. and I'll amend the spec to more closely match that 17:52:53 cool 17:53:30 #topic open discussion 17:54:10 is there anything anyone needs to talk about ? 17:54:52 so we will work on the send data back to code so we can collect data .... agree? 17:54:54 catherineD: I feel like the networking discussion isn't going to be an easy solution .. perhaps we'll need to make this user entered feilds to start with 17:55:08 yes exactly ... 17:55:23 that is why it is important to have more people test to discover more ... 17:55:43 catherineD: since refstack.org already has a public method for accepting data .. we just need to make a call out to api thing on the local refstack that can send things to it 17:55:56 i have the same thinking as yours that we may need more user data enter than we would like to ... 17:56:19 ok will do that to call the pulbikc methoid .... 17:56:41 catherineD: can you write a spec before writing any code please ? 17:56:42 At this time data is what we need ... 17:57:07 the public method might have to be change .. the database might need some alteration 17:57:13 and I just want it to be thought through 17:57:32 we will but we do not see writing any more code before discussion with the team ... 17:57:36 the questions in the spec template are designed to take out the guessing on the impact of changes 17:58:07 ic 17:58:11 will do 17:59:21 okay .. I look forward to seeing that .. I'll be back at piston hq full time next week .. So my hours will be more regular and we'll see more commits out of me 18:00:07 great! maybe we need an other f-2-r 18:00:12 f2f 18:00:20 yeah .. im open to that 18:00:41 we should plan for after the 1st of the month tho .. piston is moving offices right now 18:00:51 #endmeeting