19:23:56 #startmeeting refstack 19:23:56 Meeting started Mon Sep 8 19:23:56 2014 UTC and is due to finish in 60 minutes. The chair is juliashapovalov2. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:23:58 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:24:01 The meeting name has been set to 'refstack' 19:24:35 #meeting refstack 19:25:02 Thankyou juliashpovalov2 19:25:14 Rollcall 19:25:21 here 19:25:21 o/ 19:25:42 here 19:26:21 #topic status 19:26:48 (juliashapovalov2 needs to do all commands) 19:28:10 refstack.org site is down ... 19:28:17 #topic status 19:28:30 So, where are we? what needs core review? Please put up the links to the reviews that need core. 19:29:41 David just join ... 19:30:32 o/ 19:30:41 not sure why this one fail gate .. https://review.openstack.org/#/c/117651/ 19:31:50 zehicle: were you on the same flight as davidlenwell? 19:32:03 I am here 19:32:10 Any waiting for core review? 19:32:14 give me a minute to catch up 19:32:20 zehicle: was on a call that ran long 19:32:24 I was in the air 19:33:40 nothing to catch up on, yet;-) 19:35:35 I've got a review for the designated sections shema 19:37:59 I need to review that. 19:38:42 zehicle: question: should the definitive havana defcore json files live under OpenStack governance? 19:39:03 Once settled, it should be owned by the board, right? 19:39:29 yes 19:39:58 there's no other place for files like these that also have gerrit voting 19:40:05 (sorry I'm late) 19:40:52 That would mean that all the files in refstack should be generated from the governance files, such as capabilities.json 19:41:11 zehicle : so the tests for havana will be from tempest-stable-havana and not from the current tempest master right? 19:41:38 question regarding the havanacore: shouldn't this file correspond to tests in Tempest master? i mean if tests will be changed or deprecated these changes should be reflected in json also 19:43:03 Remember: tests for Havana are against the Havana *release*, not against the current state of OpenStack projects. 19:43:37 it would be inconsistent to support one OpenStack version only from separate branch 19:43:59 juliashapovalov2, we do want the tests to be from trunk tempest 19:44:12 davidlenwell, did we make progress on getting UUIDs for tests? 19:44:15 that would be needed 19:44:22 fyi: #link https://review.openstack.org/#/q/status:open+project:+stackforge/refstack,n,z 19:44:23 Link to open reviews 19:44:33 rockyg, so we need to have a way to know which tests were there for each release 19:44:47 I'm multithreaded, sorry about the lags 19:44:51 not yet .. I'll have answers this week 19:45:14 juliashapovalov2, +1. I think we agreed in ATL that we'd be from trunk for all releases including havana 19:45:57 davidlenwell and zehicle: woudl adding uuid to test be a good topic for design session on Paris? 19:46:11 I Want to solve it long before paris 19:46:17 Zehicle: so we are from trunk, but are we taking tests fro HEAD, or from when the release was cut? 19:47:17 tests may be released much later then official OpenStack version// 19:47:26 the data still doesn't mean anything over time without the uuid's 19:47:28 rockyg, the later - from when the release was cut 19:47:44 we cant have tests that shows up in Icehouse be part of the havana critieria 19:48:06 we're limited to the tests that were there at the release 19:48:13 otherwise it's a moving target 19:48:23 besides, for core, we're talking about stable features only 19:48:35 so if it is from release the refstack-client need to be able to test at release level ... 19:48:39 so there should not be a lot of new tests that change the functionality 19:49:08 catherine_d, we'd test all the tests and then apply a "which release does this pass filter" 19:49:12 the problem is not for the new test ... but for the tests that are relocated 19:49:35 it would be interesting if we tested icehouse and could say it passed core for havana & icehouse. frankly, it should be able to do that 19:49:46 catherine_d, yes. that's why we need IDs 19:50:08 yes ... so without UUID .. are we stuck now? 19:50:22 what format of UUID's do you expect? 19:50:35 I 19:50:36 I 19:50:51 we can mock them for now, i beleive 19:50:51 I'd like to have a workaround, but I do think we'll need UUIDs to complete the cycle 19:51:11 agree ... 19:51:12 we could also have a lookup table 19:51:32 I think it will take sometime for uuid feature to be implemented 19:51:58 also, zehicle, does DefCore have a repository in governance yet? 19:52:55 rockyg, no 19:53:16 did not realize that there was a dedicated repo for that - is that what the TC is using? 19:53:24 if so, we can move the /defcore items to that 19:53:33 woa! uh, what just happened? Flood o' messages 19:54:17 ah, ok. #link https://github.com/openstack/governance 19:54:25 I'd be happy to move the defcore stuff to that 19:54:46 but want to make sure that we've got the right Core reviewers. Who manages that repo? 19:56:46 That one looks like TC. Lemme do some more looking, though. 19:59:41 the question to me is, does it help refstack to have those outside of the repo? I don't really care where they reside 20:00:31 I really think the changes, once official, need to be owned by the foundation, not by the implementers of the certification software 20:01:53 * redrobot is ready to chair barbican meeting 20:01:57 Can we end meeting and move to Refstack? Barbican has this now? 20:02:19 sure 20:02:30 I think Juliashapovalov2 needs to 3endmeeting 20:02:36 #endmeeting that is... 20:02:41 #endmeeting