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