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