19:05:53 <davidlenwell> #startmeeting refstack 19:05:54 <openstack> Meeting started Mon Mar 2 19:05:53 2015 UTC and is due to finish in 60 minutes. The chair is davidlenwell. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:05:55 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:05:58 <openstack> The meeting name has been set to 'refstack' 19:06:09 <davidlenwell> I was catching up on code reviews and lost track of time 19:07:13 <davidlenwell> I am a little dissorginized because I was camping all weekend for my birthday.. and I am still recovering 19:08:49 <Rockyg> o/ 19:09:06 <davidlenwell> I'd like to start out by talking about this review.. https://review.openstack.org/#/c/156569/ 19:10:01 <slypushenko__> We disscussed it with Vlad 19:10:38 <davidlenwell> it has the plus twos it needs to merge .. I'm of the opinion that we should be doing all tests and produciton design for mysql 19:11:38 <slypushenko__> We decided leave db_setup_wrapper as a single script 19:11:43 <davidlenwell> okay 19:11:55 <catherineD> davidlenwell: I gave a +2 because I think it is good for Local Test. But I think we should not have that as "gate" 19:12:21 <davidlenwell> I can get on board with that 19:12:31 <davidlenwell> this is why I didn't just merge .. I wanted to talk it though 19:12:37 <slypushenko__> catherineD Why? 19:12:40 <catherineD> I think MySQL is one implementation .. there may be other backend db implemtation for future 19:12:54 <davidlenwell> iike what catherineD? 19:13:25 <catherineD> DB2? 19:13:26 <davidlenwell> ibm db2 ? ;) 19:13:26 <Rockyg> postgres 19:13:35 <catherineD> Rockyg: +1 19:13:36 <Rockyg> ;-) 19:13:47 <davidlenwell> see I don't think we need to come out of the gate supporting all those databases 19:13:54 <catherineD> All I am saying is keep the option open .. 19:14:02 <vladiskuz_> Sorry, but this patch have a bug with migration. I find it just now 19:14:39 <slypushenko__> We should be sure, that upload works fine. 19:15:26 <davidlenwell> So we need to manually test.. 19:15:35 <davidlenwell> vladiskuz_: go ahead and fix what you just found 19:15:35 <slypushenko__> It is a main idea to have functional test in gate 19:15:52 <zehicle> o/ sorry I was late 19:15:53 <slypushenko__> manual test is not an option 19:15:55 <vladiskuz_> we can have different gates to different database in the future 19:16:07 <davidlenwell> vladiskuz_: ++ 19:16:23 <davidlenwell> I do think we should gate on mysql .. ,because thats what we use in production 19:16:30 <davidlenwell> we need to know if something breaks 19:16:44 <slypushenko__> +1 19:17:41 <davidlenwell> okay .. lets move on .. I think thats enough time on this topic .. vlad go ahead and fix the bug you saw .. I want this in the gate 19:17:53 <davidlenwell> lets get an update on uuid progress.. 19:17:58 <davidlenwell> #topic uuid 19:18:53 <davidlenwell> hogepodge: can you give us an update please 19:19:16 <hogepodge> The initial work and tagging has been merged. 19:19:33 <hogepodge> Clean up tasks to be done involve documentation 19:19:40 <catherineD> I look at the new test list with uuid ... and seems like the dynamically created test cases are not covered .. 19:20:01 <hogepodge> catherineD: yes, that's also work that needs to be done 19:20:44 <davidlenwell> so what are the work items that need to be completed before refstack can move from the release its using into trunk tempest? 19:24:03 <hogepodge> catherineD: do dynamically created tests fall under api? 19:24:26 <catherineD> no 19:24:44 <hogepodge> davidlenwell: I don't think there are any more uuid work items then 19:24:45 <catherineD> but they are mostly negative test ... 19:24:54 <mtreinish> catherineD: they're only for 2 classes of tests, negative api tests and 1 scenario tests 19:25:11 <davidlenwell> none of those tests are listed in the defcore capabilites list are they ? 19:25:28 <catherineD> mtreinish: yes 19:25:29 <mtreinish> the uuid decorator is not used on the negative auto generated tests, this was a known quantity going into that work 19:25:41 <Rockyg> not for havana, but negative api tests should be in the future 19:26:25 <davidlenwell> we'll need to hash this out and figure some way of identifying them for the future .. for now lets discuss a change in refstack client to use the uuid's 19:28:10 <slypushenko__> It can be done easily 19:28:27 <catherineD> davidlenwell: I will take a look and provide recommendation 19:28:29 <davidlenwell> yes .. I know its an easy change 19:28:49 <davidlenwell> catherineD: that is what I am looking for .. please make a new story in story board for the change and track it 19:29:08 <slypushenko__> I can do it tomorrow. 19:29:13 <catherineD> For me more important is how the tests section of the core tests should be defnine ... Today it is tests:[test1, test2 ...] 19:30:14 <catherineD> defined 19:30:46 <davidlenwell> catherine .. go ahead and put your thoughts into a story in storyboard and assign the work to slypushenko__ 19:30:55 <catherineD> Yes I will ... 19:30:58 <hogepodge> catherineD: feels like parse and generation tools is what's needed. Similar to whats happening with capabilities files. 19:30:58 <davidlenwell> thank you 19:32:21 <catherineD> since we have mtreinish: here ... should we discuss about the issues refstack faces on testing ... https://docs.google.com/document/d/12GUhUphBSzPuQqp7WreZ-DXaINnUWSrYAYb4CyPmpAw/edit# 19:32:39 <catherineD> do we need to open bug in Tempest ? 19:33:47 <mtreinish> catherineD: for the unicode one that's definitely a bug 19:33:59 <mtreinish> there are open bps that will address some of the others as part of them 19:34:04 <mtreinish> like test-accounts part 2 19:34:16 <mtreinish> and improved ssh validation 19:34:49 <mtreinish> and the last one seems like a nova bug 19:34:51 <catherineD> mtreinish: I looked at the ssh validation .. mostly they are fro scenario tests ... 19:35:20 <catherineD> maybe it will apply to API tests ... I will take a closer look ... 19:35:28 <Rockyg> gotta run. will catch up on my return 19:35:42 <mtreinish> catherineD: http://specs.openstack.org/openstack/qa-specs/specs/ssh-auth-strategy.html 19:37:00 <catherineD> mtreinish: thx.. 19:37:18 <davidlenwell> okay .. lets move on .. 19:37:41 <davidlenwell> catherineD has started workign on creating wireframes for some of the upcomming ui work.. 19:37:53 <davidlenwell> catherineD: I will review those today 19:38:44 <slypushenko__> Can it be share with team? 19:39:02 <davidlenwell> sure 19:39:16 <davidlenwell> its still early .. but I see no reason that it can't be done in the open 19:39:25 <davidlenwell> catherineD: would you share the link you sent me before? 19:40:03 <catherineD> First pass mockup https://drive.google.com/file/d/0BxvL0emVRKoUVW13TW5BWXg0MXM/view?usp=sharing 19:40:50 <catherineD> On this first pass, I concentrate more on the type of data that we need to fetch (for API definition) not look and feel 19:40:51 <davidlenwell> remember these are a first pass 19:41:10 <davidlenwell> look and feel comes later .. lets keep it to pure functionality in the early mockups 19:41:12 <slypushenko__> ok, thx 19:42:42 <davidlenwell> okay .. lets move onto open discussion 19:42:47 <davidlenwell> #topic open discussion 19:43:21 <zehicle> we're going to start moving some of the defcore items out of the refstack repos 19:43:38 <zehicle> just a heads up, no action required here 19:44:09 <zehicle> at some point, I'd like to talk about how the UUIDs will change the JSON files 19:44:18 <davidlenwell> great 19:44:39 <davidlenwell> im sure the moves will have coorasponding commits deleting the files from refstacks repo? 19:45:23 <catherineD> zehicle: how UUID changes the JSON files is what refstack-client needs for update .... have we decided on how? 19:45:26 <slypushenko__> zehicle I think we just should replace test names with uuids 19:46:01 <catherineD> slypushenko__: I think the long test id should still be there for description purposes .. 19:46:11 <slypushenko__> and update capabilities.html page 19:46:53 <slypushenko__> catherineD No. we can easily resolve uuid to test name using github repo 19:47:12 <hogepodge> catherineD: +1 on the long name 19:47:23 <zehicle> catherineD, I was assuming we'd just change them 19:47:27 <zehicle> we'll need a xreference too 19:47:32 <hogepodge> catherineD: slypushenko__: uuid should be only source of truth. 19:47:42 <zehicle> I was thinking the xref file would have extra info 19:47:47 <zehicle> like links to the tests 19:47:50 <catherineD> I can see some thing like uuid: [testid1, testid2 ..] 19:48:04 <slypushenko__> If we keep long names we should care about its consistency 19:48:24 <hogepodge> slypushenko__: if we tag tempest hash at top of file that becomes an anchor 19:48:43 <catherineD> test1, test2 is accomodated the path relocation ... 19:48:53 <hogepodge> the assumption is that the only source of truth in test identification should be uuid, but we need a human readable component. 19:49:17 <zehicle> remember, Tempest may not be the only test source 19:49:27 <zehicle> esp when tests move out of Tempest 19:49:36 <slypushenko__> if we have tempest tag and uuid we can resovle long names automaticaly... So we don't need to keep it 19:50:36 <catherineD> slypushenko__: that is good for display not for subunit results ... 19:51:16 <catherineD> subunit results are still parsing the test_id and then UUID ... 19:51:18 <davidlenwell> zehicle: if tests move out of tempest they will still have uuid 19:51:30 <zehicle> yes. that's what I expect 19:51:40 <zehicle> we're "coding" that into the process 19:51:43 <davidlenwell> at least thats how we wrote it in the spec 19:51:57 <zehicle> tests must have UUID & be part of OpenStack community process 19:52:19 <hogepodge> zehicle: as a defcore action item for Wednesday we should define a v2 schema for capabilities. 19:52:35 <catherineD> hogepodge: +1 19:52:41 <hogepodge> (heck, maybe every defcore release will require a schema revisit) 19:52:54 <davidlenwell> true sotry 19:52:55 <catherineD> once that is defined it would be easier for refstack-client to make the change 19:53:15 <zehicle> hogepodge, Egle and I were not planning to meet on Wed 19:53:24 <zehicle> you can keep the meeting if you'd like and work on that 19:53:36 <hogepodge> zehicle: ok, good to know. 19:53:48 <hogepodge> zehicle: I keep signing myself up for writing bluebrints. :-P 19:54:41 <catherineD> hogepodge: zehicle: before we run out of time ... I would like to make a comment about someone's suggestion on docker image for tests ... 19:54:43 <zehicle> if you think there's enough people, go ahead and hold the meeting. there's plenty to do 19:54:49 <zehicle> ok 19:55:53 <catherineD> IMOP, refstack-client is pretty easy to install so having a docker image does not help much ... the hard part is the tempest.conf which docker image won't be able to solve 19:56:34 <zehicle> catherineD, yes. that's been our experience 19:57:46 <hogepodge> I'm open to new attempts. Maybe they know something we don't. 19:58:04 <hogepodge> But yes, it's a problem. (hence the [interop] tag idea I've been bouncing around) 19:58:15 <catherineD> hogepodge: agree just want to point out the painpoint 19:58:17 <hogepodge> (which would aim to solve the tempest.conf problem) 19:58:36 <zehicle> that's where I'd be interested in seeing if they help. 19:58:47 <hogepodge> catherineD: thanks. total pain point (see the backlog from #openstack-qa over the last hour) 19:58:49 <zehicle> having a container can reduce troubleshooting 19:59:10 <zehicle> I think it would be really really good to have a known working config 19:59:14 <hogepodge> zehicle: a web service would too. :-D 19:59:16 <zehicle> even if most of the tests are not passing 19:59:23 <zehicle> or disabled 19:59:30 <zehicle> so that people can check their install 19:59:30 <hogepodge> interopallthethings.org 19:59:34 <davidlenwell> okay .. we're out of time again .. but I like this disucssion .. lets move it to #refstack 20:00:12 <zehicle> :) 20:01:15 <davidlenwell> #endmeeting