18:59:41 <davidlenwell> #startmeeting refstack 18:59:42 <openstack> Meeting started Mon Feb 2 18:59:41 2015 UTC and is due to finish in 60 minutes. The chair is davidlenwell. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:59:43 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:59:45 <openstack> The meeting name has been set to 'refstack' 19:00:05 <Rockyg> o/ 19:00:28 <pvaneck> o/ 19:00:28 <catherineD2> 0/ 19:01:13 <hogepodge> o/ 19:01:18 <vladiskuz_> o/ 19:01:26 <davidlenwell> hello everyone! 19:02:37 <davidlenwell> agenda: uuid spec, auto deploy code, domain name, pending reviews, open discussion 19:02:46 <davidlenwell> #topic uuid spec 19:03:11 <davidlenwell> can everyone please review https://review.openstack.org/#/c/144329/11 its been almost a week since it was posted 19:04:30 <sslupushenko__> o/ 19:05:18 <davidlenwell> sslupushenko__: can you please review that spec before you go to bed? 19:05:38 <sslupushenko__> Sure, I can 19:05:45 <davidlenwell> I fear it won't get attention from cores without any other reviews 19:06:19 <sslupushenko__> but I still don't see how we will fix issue with tests generated from scenarios 19:06:33 <davidlenwell> okay .. lets move right alone.. 19:06:46 <davidlenwell> #topic auto deploy code 19:07:25 <davidlenwell> #link https://storyboard.openstack.org/#!/story/2000125 19:07:55 <davidlenwell> I am going to work on this spec in the early part of the week.. however the work vladiskuz_ and sslupushenko__ have been doing with the oslo config are important steps to making that work.. 19:09:01 <sslupushenko__> davidlenwell Pecan has suck feature. You can use it 19:09:08 <sslupushenko__> *such))) 19:09:27 <Rockyg> LOL 19:09:30 <davidlenwell> pecan has an auto reload when the underlying code changes .. 19:09:37 <sslupushenko__> or I can do it if you are to busy 19:09:40 <davidlenwell> but I don't think it will trigger the git update 19:10:02 <davidlenwell> right now I have it hosted with apache.. in production 19:10:14 <sslupushenko__> sure... git hook should be devloped 19:10:52 <davidlenwell> I'm thinkin a cron job that triggers a git pull and a db migration daily would be fine.. 19:11:09 <sslupushenko__> or we can do periodical sync with main repo 19:11:11 <davidlenwell> that we can always trigger manually if need be 19:11:26 <davidlenwell> sslupushenko__: yes.. I am thinking just nightly 19:11:49 <davidlenwell> this way nothing is dependant on my manually updating anything 19:12:37 <sslupushenko__> cron sync + autoreload looks good for me 19:12:46 <davidlenwell> great .. can you take that on please? 19:13:21 <davidlenwell> I'd also like to update the readme with the differences in deploying for production vs for development.. 19:13:48 <davidlenwell> using apache to host the pecan app as wsgi seems to be the more stable route.. 19:13:51 <Rockyg> Add the cron+sync as a task to the story, please 19:14:04 <davidlenwell> it is Rockyg https://storyboard.openstack.org/#!/story/2000125 19:14:08 <davidlenwell> we just didn't call it that 19:14:34 <vladiskuz_> Folks, I have some question about gunicorn. What do you think about openstack common service? What if use it instead gunicorn? 19:14:54 <davidlenwell> I'm all for doing that vladiskuz_ 19:15:42 <vladiskuz_> What are the advantages of the openstack common service? 19:15:55 <Rockyg> wasn't logged in. done 19:16:21 <davidlenwell> well future proofing for one vladiskuz_.. it seems to be the trend.. 19:16:34 <davidlenwell> I think we should at least explore that 19:16:48 <davidlenwell> perhaps a spike to decide if its ready for our use yet vladiskuz_ 19:16:49 <sslupushenko__> davidlenwell Ok. I'm planning to finish validation task tomorrow and I will start auto reload feature 19:17:05 <davidlenwell> sslupushenko__: great.. thank you 19:17:19 <davidlenwell> I think we can move on to the next topic.. domain name 19:17:25 <davidlenwell> #topic domain name 19:18:20 <davidlenwell> I sat on desks at piston until I got more clear answers from piston regarding the domain name.. when josh left piston he transfered a lot of those over.. they haven't all been processed .. and they are looking into it.. 19:18:53 <davidlenwell> I am going to keep on them about it.. 19:18:58 <Rockyg> k 19:19:05 <davidlenwell> in the meantime I think we are fine with proceeding with .net 19:19:28 <davidlenwell> I'm going to shoe another topic in here.. 19:19:36 <davidlenwell> #topic beta users.. 19:19:37 <catherineD2> davidlenwell: I think so for domain name.. Now that the server is up let's also allow sometime to discuss UI topic 19:20:35 <davidlenwell> I spent a few hours at piston with their q/a lead.. he was using fedora on the machine he was testing from.. the client seemed to run fine.. however he was hitting some road blocks with getting ports open to his test cluster 19:21:05 <davidlenwell> he's working out how to get his laptop to route into the clusters end points from the office network.. I am going to check back with him today.. 19:21:49 <catherineD2> are they using Icehouse? 19:21:53 <davidlenwell> yes 19:22:01 <davidlenwell> they are using icehouse 19:22:34 <catherineD2> so is clee .. 19:22:37 <davidlenwell> however im sure they'll update soon.. they try to stay a year behind the releases 19:22:51 <davidlenwell> I think a lot of production clouds are on icehouse now 19:23:14 <Rockyg> agreed. 19:23:19 <davidlenwell> hogepodge: have you reached out to any other potential beta testers? 19:23:29 <davidlenwell> I still have not heard a solid answer out of hp.. 19:24:04 <hogepodge> I'm working with our bizdev person on it. 19:24:17 <davidlenwell> great. . please keep us updated.. 19:24:40 <hogepodge> I have one set of results back from DreamHost 19:25:24 <davidlenwell> catherineD2: what was your impression from working with clee on the pain points in getting the client working? 19:25:48 <catherineD2> davidlenwell: seems to be easy for him to get the tests running ... 19:26:08 <davidlenwell> yeah .. I feel like it went pretty smoothly.. 19:26:13 <catherineD2> the hard part will be analyzing the results ... 19:26:19 <Rockyg> Zehicle is having problems with client, but it may be tepest config 19:26:28 <davidlenwell> I think we are very close to being able to open up the flood gates and get a lot more folks running it. 19:26:55 <catherineD2> even that hogepodge: upload the data to the api.refstack.net today ... we do not have an easy way to view that data .... 19:27:06 <catherineD2> we need to know the testid ... 19:27:17 <catherineD2> so I think we should discuss about UI .. 19:27:28 <Rockyg> +1 19:27:33 <catherineD2> and also may be authentication for uploading data ... 19:27:37 <davidlenwell> I'd also like to talk about that.. 19:27:50 <sslupushenko__> we can return url from refstack-client 19:27:58 <catherineD2> let discuss UI first /// 19:28:02 <davidlenwell> we should return the url from the refstack client 19:28:07 <davidlenwell> lets table ui for the moment 19:28:11 <sslupushenko__> where user can review results 19:28:30 <davidlenwell> returning the results url in the submission response is the first step 19:29:00 <catherineD2> sslupushenko__: only the one who upload will have that URL (test number)... no one else 19:29:16 <davidlenwell> thats okay catherineD2 19:29:24 <catherineD2> so every one should be able to view data ... 19:29:25 <davidlenwell> we don't want to publish results publicly just yet 19:29:50 <davidlenwell> we want the vendors to advertise their own links through there own channels 19:30:11 <catherineD2> is that so ... 19:30:17 <davidlenwell> otherwise we have to impliment the vendor authorization path 19:30:24 <sslupushenko__> If someone wants to share his own data he should do it by himself 19:30:40 <catherineD2> then at least we should have a way for vender to list all of their tests based on keystone UUID 19:30:41 <sslupushenko__> I argeed with David 19:30:42 <davidlenwell> which we'll eventually do but It hink for now its a bigger problem than we have the bandwidth to solve 19:31:14 <davidlenwell> catherineD2: lets review our use cases again and repriorities for the next steps in development 19:31:18 <catherineD2> that is incase I lost that URL ... 19:31:20 <Rockyg> catherineD2: only matching vendor should be able to view data until security in place. 19:31:36 <davidlenwell> I'll have to dig up the google doc that rob and I worked out 19:31:41 <catherineD2> Rockyg: agree+1 .. 19:31:54 <catherineD2> but what if I lost the testid and url? 19:32:02 <davidlenwell> then resubmit 19:32:05 <davidlenwell> it will give you a new one 19:32:09 <davidlenwell> no skin off our hide 19:33:09 <sslupushenko__> We can provide some workaround for now adding logs in refstack-client 19:33:26 <catherineD2> davidlenwell: interesting ... the the db can be full of repeated test results ... at which point do we clean up? 19:33:42 <sslupushenko__> Client can log retrived test-id there 19:34:03 <davidlenwell> sslupushenko__: I think thats a great idea .. and easy enough to do / document 19:34:25 <sslupushenko__> catherineD2 We can handle duplications 19:34:26 <vladiskuz_> sorry, what about personal account for vendor? Is it bad idea? 19:34:34 <catherineD2> should we not provide an API for vendoer to retrive their testid based on keystone id? 19:34:51 <davidlenwell> catherineD2: im not saying we shouldn't 19:35:09 <sslupushenko__> We difenatly should! 19:35:10 <catherineD2> davidlenwell: I think that is a good API to have .. 19:35:16 <davidlenwell> i'm saying we should stick to solving our usecases .. and I think that is a pretty big chunk to bite off without propper planning 19:35:29 <catherineD2> we will need that in the future 19:35:37 <davidlenwell> catherineD2: we should have a face to face planning session 19:35:51 <davidlenwell> I don't want to wave hands and end up with the wrong thing 19:35:58 <sslupushenko__> +1 19:36:06 <davidlenwell> I want to whiteboard and put together specs and build the right things 19:36:28 <sslupushenko__> good idea 19:36:34 <davidlenwell> catherineD2: can we get together sometime in feb for a planning session? 19:36:46 <catherineD2> davidlenwell: sure ... 19:37:00 <davidlenwell> lets start an email thread about that and get it planned before next week.. 19:37:11 <davidlenwell> we'll finalize plans at next weeks meeting 19:38:00 <catherineD2> maybe we should start an ehterpad to log the topic for the next f2f? 19:38:06 <davidlenwell> sure 19:38:19 <davidlenwell> lets move on for now tho.. we are down to 20 minutes.. 19:38:29 <davidlenwell> #topic pending reviews 19:39:17 <davidlenwell> https://review.openstack.org/#/c/151805/ and https://review.openstack.org/#/c/151731/ 19:39:43 <davidlenwell> I've gave a plus 2 last week.. we need a review from sslupushenko__ to merge.. catherineD2 shouldn't merge her own reviews 19:40:53 <vladiskuz_> what about https://review.openstack.org/#/c/149589/ patch? 19:41:16 <catherineD2> I am reviewing the new one that vladiskuz_: just upload 19:41:33 <catherineD2> vladiskuz_: thx for the update 19:41:37 <davidlenwell> was getting to that vladiskuz_.. its a big patch .. just started reviewing before the meeting 19:42:28 <davidlenwell> I think those are the only pending reviews.. 19:43:07 <davidlenwell> please make sure they get attention today.. 19:43:16 <davidlenwell> pvaneck: you should be reviewing stuff too 19:43:18 <sslupushenko__> catherineD2 davidlenwell Please add me to review for your patched. I missed these last one... 19:43:28 <pvaneck> yep 19:43:37 <catherineD2> sslupushenko__: will do 19:43:40 <davidlenwell> anyone should just add refstack-core to any reivew 19:43:44 <sslupushenko__> thx) 19:43:49 <davidlenwell> it will add catherineD2, sslupushenko__ and myself 19:45:03 <sslupushenko__> done 19:45:16 <davidlenwell> okay.. lets move into open discussion .. 19:45:18 <davidlenwell> #topic open discussion 19:46:06 <sslupushenko__> If we don;t have other topics tets dissuss test uuids for scenarios tests 19:46:15 <sslupushenko__> *lets 19:46:42 <davidlenwell> what are your thoughts on this topic sslupushenko__? 19:47:19 <sslupushenko__> It will be somewhat hard to fix 19:47:35 <davidlenwell> I don't dissagree.. Do you have thoughts on where to start? 19:48:52 <sslupushenko__> We need to investigate how scenarios tests will generated and add some code there 19:49:25 <sslupushenko__> but I don't understand how we will generete unique id 19:50:40 <sslupushenko__> no one has any other ideas? 19:51:08 <davidlenwell> lets start with a detailed problem description in an etherpad .. then we can layout some options for solutions. 19:51:14 <catherineD2> sslupushenko__: I have not looked at scenario tests... My concentration so far is on API test ... I can take a look 19:51:35 <Rockyg> haven't looked at it yet. I need to understand how the scenario test work. If you have a link to a readme, that would get me started 19:53:14 <pvaneck> by scenario tests, we are talking about the api tests with stuffff like "(flavor_name_gen_none)" in their names right? 19:53:26 <sslupushenko__> Oh, Maybe it is missunderstanding here. I meant tests autogenereted from some base test in tempest. There are a lof them in API tests 19:53:41 <sslupushenko__> pvaneck thx) 19:54:15 <pvaneck> so right now, it seems like test_flavors_negative.py is the only test file utilizing these autotests 19:54:17 <catherineD2> pvaneck: thx for keeping us on track ... 19:55:04 <sslupushenko__> I guess, I saw it in other tests too...let me check 19:55:42 <pvaneck> not sure about labeling each one with a uuid though 19:56:02 <pvaneck> at least testr has a way of distinguishing each one given by the fact you can run a single one using the full test_id 19:56:04 <pvaneck> tempest.api.compute.admin.test_flavors_negative.FlavorCreateNegativeTestJSON.test_flavor_create_negative[gate,negative](flavor_vcpus_gen_int_min) 19:56:09 <pvaneck> for example 19:57:39 <sslupushenko__> any part of test id can be changed 19:58:50 <Rockyg> Hmm. Negative tests are going to be more release specific. And they are necessary for Interop validation. 19:59:34 <davidlenwell> alright gang .. we are out of time.. lets move this discussion in channel.. 19:59:57 <davidlenwell> #endmeeting