16:57:18 #startmeeting refstack 16:57:18 Meeting started Thu May 29 16:57:18 2014 UTC and is due to finish in 60 minutes. The chair is davidlenwell. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:57:19 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:57:22 The meeting name has been set to 'refstack' 16:57:47 Roll call 16:59:49 roll call? 16:59:55 o/ 16:59:59 o/ 17:00:04 o/ 17:00:18 Do we have catherine|2? 17:00:31 yes 17:00:37 excelent 17:00:38 agenda: storyboard, specs, f2f, open discussion 17:00:45 #topic storyboard 17:01:07 So I spent some time in the last week getting to know storyboard. 17:01:09 could we also talk about Havana vs Icehouse tempest? 17:01:13 sure 17:01:25 we do that before specs 17:01:28 so next 17:02:01 while storyboard is an incomplete product.. I feel its as usable as launchpad.. and the storyboard team is very open to our feedback. 17:02:10 +1 17:02:15 I'll probably even commit some code it to my self. 17:02:26 would like to have names instead of IDs in the URL, FWIW 17:02:35 yep 17:02:41 I filed a story for that on friday 17:02:46 they want it to 17:02:48 too 17:03:28 So make sure when you are writing specs and making commits to reference your storyboard link. 17:03:57 good point. 17:04:07 for those of you who didn't catch my emails to fits .. storyboard is at storyboard.openstack.org 17:04:22 are all the blueprints migrated to storyboard at this pont? 17:04:24 if you have not already .. go sign in for the first time so I can assign you work ;) 17:04:24 will you update restack.org to include that link? 17:04:33 zehicle_at_dell: yes 17:04:43 i've filed the story and will file spec later today 17:04:46 fcarpenter: yes.. I will do that today.. there is actually a story that includes that task 17:05:50 okay .. so thats that .. everyone on board with storyboard? 17:06:04 any objections will need to be voiced now ;) 17:06:06 yes 17:06:17 awesome.. moving right along.. 17:06:23 +1 17:06:30 #topic icehouse vs havana tempest 17:06:40 It looks good 17:06:42 so this should be short 17:06:52 use trunk tempest always .. moving along 17:07:11 +1 but want to talk about timing 17:07:12 branchless tempest is what we want.. when do we want it? now 17:07:29 since I know that we have to update TCUP 17:07:34 I was actually surprised not to see a commit updating the version of tempest the tester is using 17:07:44 but I guess I can do that since I wrote that 17:08:21 zehicle_at_dell: I'll update that as soon as I finish writing my specs 17:08:27 thanks 17:08:28 which I plan to have done in the next 24 hours 17:08:42 if we can get it running outside of tcyup that would be a good gate 17:08:51 before I work on making it work inside of it 17:08:51 there are about 600 testcase in for API in Havana... In Icehouse this number is about 2000+ ... 17:09:05 catherine|2: yes .. is that a problem? 17:09:38 no except for test time and extra configuration needed 17:10:22 I am trying to use master Tempest to test my Havana clouds ... 17:10:25 catherine|2: yes .. thats an issue.. but its an issue we have to solve refardless 17:10:36 are the test IDs the same? 17:10:59 it would be a problem for defcor if not 17:11:02 test IDs --> full test case name ? 17:11:08 since we need havana results for havana clouds 17:11:09 yy 17:11:38 yes I think it is more a problem for DefCore .. 17:12:08 it should be OK unless the test really changes funciton but keeps the same name 17:12:15 I am trying to take a inventory to see whether 1) full test name are retain ..2) what additional 17:12:19 which I think would have much more serious implications 17:12:34 catherine|2: good thinking 17:12:46 I don't think so but I am trying to verify with Havana cloud before going to Icehouse cloud .. 17:13:06 So there is no icehouse tempest .. just to be clear 17:13:23 after havana its branchless 17:13:23 davidlenwell, I think moving to trunk tempest is the right thing but it's a bit of scope creep for Havana 17:13:38 just using the sme master tempest for both Havana and Icehouse cloud ... 17:13:40 totally able to justify, we just need to be transparent 17:13:54 of course 17:14:02 * zehicle_at_dell is thinking about impact on reports and happy to have single tempest 17:14:07 since I have lots of data from testing havana tempest with havana cloud 17:14:08 I don't want to keep focusing on havana tempest 17:14:17 I can make tht comparison .. 17:14:19 davidlenwell, +1 17:14:31 It seems to me that we 17:14:37 are ok as long as the IDs are consistent 17:14:48 since that's the ultimate handle we're using, not the source 17:14:49 even if they are not .. we have to find a way to migrate 17:15:10 branched tempest is a thing of the past 17:15:11 if they are not, then it's even more urgent to move to the consinstent one 17:15:18 +1 17:15:25 okay .. moving on 17:15:29 kk 17:15:30 #topic specs 17:15:51 I am more concern about the consistency of test name/ID for core and capability test list 17:16:06 so specs are rolling in.. catherine|2 I started to review the one you posted last night but my eyes didn't want to read anymore.. so I'll review it this morning. 17:16:21 zehicle_at_dell: what is the status of your specs? 17:16:41 I'm working on the designs for both 17:16:49 making some progress on layout and approach 17:17:03 Do you have an eta? 17:17:08 I'd be happy to upload partials if people want to see the problem statement 17:17:10 tomorrow 17:17:24 I think partials would be informative 17:17:26 I think I've cracked the design for the comparison one 17:17:29 I'd always like to see partials if you are into feedback 17:17:35 happy to do that 17:17:40 will upload by EOD for them 17:17:45 excelent 17:17:52 what about your specs rockyg 17:17:54 ? 17:18:08 Matrix will be in today. 17:18:18 yay! 17:18:23 Looks like you got the example unit test cooking? 17:18:26 and catherine|2 has one more riht ? 17:18:30 I had a question about catherine|2 spec https://review.openstack.org/#/c/96311/ 17:18:32 rockyg: I did 17:18:35 yes working on it 17:18:45 it looks like it overlaps w/ the other API upload spec 17:18:59 I called that out in review, but figured we could talk here if that helps 17:19:03 davidlenwell: great on example unit test 17:19:22 ha ha test_nothing is a good start 17:20:03 Dow we need a spec on breaking out the config into the three sections? If so, we should do it cross project with storyboard. 17:20:21 rockyg: not yet 17:20:37 Can storyboard do cross project? 17:20:42 for our imidiate porposes we are going to consider config a blackbox 17:20:47 rockyg: yes it can 17:20:54 kewl x2 17:21:01 one of the items I 17:21:13 noticed in review was that we may want to have a client library for the API 17:21:23 so that we could use it from multiple places in the same way 17:21:26 zehicle_at_dell: indeed 17:21:35 sounds right 17:21:42 lets add a story for that 17:22:02 assign it to me .. made the first task write a spec 17:22:17 +1 17:22:44 next topic 17:22:48 #topic f2f 17:22:49 wait 17:23:05 yes catherine|2? 17:23:35 zehicle_at_dell:suggest we should merge the api--api-sync with an API upload spec? 17:24:03 I am open for that .. 17:24:08 catherine|2, there are parts of it that overlap 17:24:16 but I think you also have use-cases that are different 17:24:28 I'd suggest that we pull the API spec out and use the current one 17:24:40 but leave in the refstack to refstack synch part 17:24:54 because that was distinct. 17:25:01 davidlenwell: I avouid the sync word ... 17:25:09 +1 17:25:27 could we call it "private refstack to public refstack push" ? 17:25:29 because I don't think we sync the data because both sides do not have identical data 17:25:35 I think that's the primary use case 17:25:47 zehicle_at_dell: +1 17:25:56 good point. push sounds good to me. 17:26:10 +1 17:26:23 "private refstack to public refstack push" seems like a better title 17:26:27 that would make it easier for me to review. I'll save additional comments for the revision 17:26:40 let's put "push" first now that I'm reading it back 17:26:44 so we change the story? 17:26:51 story title 17:26:53 yep 17:26:57 +1 17:26:59 okay.. so moving on to face to face 17:27:54 zehicle_at_dell: will be in town in june for a few days.. thought we should take the time and have a f2f 17:28:16 yup 17:28:22 +1 17:28:28 zehicle_at_dell: are your dates final ? 17:29:10 I have some flex if needed 17:29:16 but they are getting pretty locked 17:29:29 so I think the original plan was for us to get together at the piston office on the 11th 17:29:34 yy 17:29:38 or am I off base? 17:29:47 that's right. defcore f2f is 12th 17:30:07 I was planning to be at CF summit on 10th 17:30:26 excelent .. fcarpenter can you reserve us a conf room that can hold 7 people comfortably? 17:30:48 on 6/11? 17:30:51 yes 17:30:56 time of day,? 17:31:05 I'd say noon to 6pm 17:31:41 yes I can probably get panama 17:31:42 you'll send out new address for us? 17:31:52 126 Post St 5th Floor San Francisco CA 94108 17:31:56 but we'll send it out, too 17:32:05 yeah .. we'll email fits with the info 17:32:12 panama would be great 17:32:14 do you want an etherpad for an agenda? 17:32:20 zehicle_at_dell: yes 17:32:34 * zehicle_at_dell making pad 17:32:57 okay.. so im going to sneak in another topic here 17:33:05 #topic swagger 17:33:14 #link https://helloreverb.com/developers/swagger 17:33:28 #link https://etherpad.openstack.org/p/refstack.2014-06-11 17:33:32 this is swagger.. I won't go into describing it because .. well they have done a good job of that 17:34:35 it does do client generation .. but not currently in python.. however I'm told that is in the works. 17:35:25 interesting.... 17:35:34 yes it is 17:36:03 So I'm going to put some serious thought into if and how we can use it.. will probably update the v1 api spec to include it if I think we need to use it 17:36:36 if it does what it says, it is tes cool. 17:36:43 indeed 17:36:48 we shall see 17:36:52 tres 17:36:56 so moving along.. one more sneak in topic 17:37:06 #topic py26 gate is no more 17:37:07 I've got some parking lots.... 17:37:59 anyone who submitted a patch to refstack and payed attention to its testing might have noticed that I took py26 testing out of the gate. 17:38:08 as I said I would a few months ago 17:38:40 I've noticed that we're faiing patches because we have no tests 17:38:43 how does this work with havana refstack, or will the advisory status of H refstack suffice to let us do away with it? 17:39:06 zehicle_at_dell: that is no longer true 17:39:07 rockyg, yes. that's a general hall pass 17:39:15 davidlenwell, cool! 17:39:28 I posted an empty test yesterday .. if you rebase your patch it will make it through 17:39:37 I did send you a message on skype saying this 17:39:44 * zehicle_at_dell ok, will do 17:39:54 yes, I saw and did rebase 17:40:03 I know that praveen had the same issue 17:40:14 yes .. its because infra made a change on the 9th 17:40:26 0 tests is no longer acceptable 17:40:34 so now we have 1 tests 17:40:36 teset 17:40:37 test 17:40:43 typing is hard 17:41:05 especially when low on caffeine 17:41:12 #topic open discussion 17:41:27 I've got a pending change to the coretest.json file 17:41:43 based on DefCore discussion, it needed some more info 17:41:52 specifically, the criteria description 17:41:54 right. 17:42:04 About the spec that only send passing data 17:42:04 also needed to open it up a little so we could add scores 17:42:19 yes catherine|2 17:42:20 ? 17:42:23 we need to enable people to post changes to single test criteria via gerrit for review 17:42:26 davidlenwell: is that just for TCUP . 17:42:26 does that make sense? 17:42:35 catherine|2: no 17:42:37 I mean for data collection to determine core 17:42:45 catherine|2, I think that we want the public refstack to only take pass results 17:42:49 catherine|2: that is for everything 17:43:16 we may want private refstacks to also have fail tests 17:43:18 which is why it includes an option for not scrubbing the data ..so you can use it inhouse without only submitting pass. 17:43:35 davidlenwell, +1 17:43:41 All test info needs to get scrubbed before sent to/added to refstack.org 17:43:50 I did include that in the spec.. thanks to zehicle_at_dell and rockyg feedback 17:44:17 so from refstack.org point of view we only save passing dta no logs or raw data for debug ... 17:44:25 catherine|2: so you will also need to add that to your api-api sync 17:44:27 rockyg, if someone does send the wrong data, then I suspect we should scrub it again just in case 17:44:28 but local copies not officially on refstack.org can have everything 17:44:49 yes 17:44:59 perhaps we should 500 on uploads that have non-pass info 17:45:09 IMHO, that data could be toxic 17:45:24 so the scrub data ill be in a format that refstack define? It is no longer a subunit defined format? 17:45:28 Right. So, scrubbed in remote refstack and tcup before upload then verified/rescrubbed on arrival at refstack.org 17:45:55 catherine|2: we should be able to keep it in subunit format 17:46:01 I think it's still subunit, but no tests left that fail or are skipped. 17:46:05 I'm backing away from rescrubbed. I'd think to just bounce it 17:46:16 zehicle_at_dell: I agree 17:46:25 we don't want that information hanging out on public servers anywhere 17:46:25 the client submitting it will have the tools to scrub 17:46:28 agreed. 17:46:31 we don't want to liability 17:46:50 davidlenwell: that would be a big job ... essentially we are writing a different version ofr subunit output data ... 17:46:55 last thing I want is storys of how someones cloud was comprimised only after submitting data to refstack 17:46:56 but it still means we need to verify it's prescrubbed. 17:47:13 rockyg: thats easy enough 17:47:20 cool 17:47:21 if it includes a fail .. its not scrubbed 17:47:30 or skipped 17:47:43 skip == fail from our perspective 17:47:44 +1 17:48:12 can we insert a tag or some metadata in the subunit that will indicate the file has passed through our scrubber? 17:48:13 catherine|2: lets discuss that offline 17:48:20 yup 17:48:40 different topic > does anyone have a preference for wireframe tools? 17:48:48 balsamiq 17:48:54 kk, will check that you. 17:50:12 So everyone.. re: storyboard.. 17:50:33 as you are using it and you percieve an limitation .. please discuss it with them.. they are very open 17:50:42 either file a story .. or chat with them in #storyboard 17:50:51 we are an early adoptor 17:50:58 and our feedback is very valuable to them 17:50:58 ping me 17:51:05 VERY valuable 17:51:09 I love feedback. 17:51:18 hi krotscheck 17:51:22 Also, we JUST got our second +2, so things should move faster now. 17:51:31 awesome news! 17:51:45 let the patches flow! 17:51:54 kk. You know me, I'm not shy;-) you'll hear frim me. 17:51:54 …that sounds like a sewage metaphor. 17:52:06 krotscheck: it did didn't it 17:52:20 davidlenwell: It really did. 17:52:34 I'll be careful with that in the future 17:53:00 anything else for open discussion? 17:53:12 I got nuthin 17:53:15 we've got some backlog 17:53:18 of patches 17:53:32 zehicle_at_dell: ping me in an hour or so and we'll sift through them 17:53:41 now that patches can land .. 17:53:42 ok 17:53:50 reasonable 17:53:59 * sarob_ lurking still 17:54:13 them I'm good 17:54:15 sarob_: can you remind me of your real name? 17:54:26 sean roberts 17:54:32 Sean Roberts 17:54:36 oh thanks .. thats right 17:54:57 sarob_: did you have any more thoughts on tempest config that we didn't already talk about at the summit? 17:55:12 Not yet 17:55:24 okay .. well don't be shy when youd o 17:55:31 I've got too much plate 17:55:46 Or small plate 17:55:50 sarob_: understood .. thanks for paying attention 17:55:51 Either one 17:55:54 is the meetup in SV tonight? 17:55:59 Yup 17:56:06 meetup? 17:56:08 Ill be there. 17:56:11 Bldg e training room 8 17:56:15 Cool 17:56:27 OpenStack "hackathon" 17:56:35 recruiting tool 17:56:40 I run the sfbay Openstack user group 17:56:47 oh cool 17:57:02 is there a link to more info? 17:57:21 I can email you the reminder.... 17:57:23 #link meetup.com/Openstack 17:57:31 awesome .. thanks 17:57:31 better 17:57:33 That works too 17:57:50 okay everyone.. good meeting .. thanks for showing up and participating :) 17:58:04 very productive today. 17:58:10 #link http://meetup.com/Openstack 17:58:11 +1 17:58:14 ttfn 17:58:16 Thx 17:58:20 #endmeeting