19:00:40 <catherineD> #startmeeting refstack
19:00:41 <openstack> Meeting started Mon Nov 23 19:00:40 2015 UTC and is due to finish in 60 minutes.  The chair is catherineD. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:42 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:45 <openstack> The meeting name has been set to 'refstack'
19:01:19 <catherineD> #link meeting agenda and notes, please feel free to add items https://etherpad.openstack.org/p/refstack-meeting-15-10-23
19:01:50 <catherineD> roll call
19:04:52 <hogepodge> o/
19:05:37 <alevine> o/
19:05:59 <catherineD> hello ...
19:06:47 <catherineD> alevine: welcome ...
19:06:55 <alevine> hi. thanks :)
19:07:28 <catherineD> a lot of people are on vacation this week ... so I did not put a lot of topics for today's dicussion ...
19:07:43 <catherineD> #link meeting agenda and notes, please feel free to add items https://etherpad.openstack.org/p/refstack-meeting-15-10-23
19:09:04 <catherineD> alevine:  we are glad to have you here ... pls bring up  any topics  during the open discussion section
19:09:32 <catherineD> #topic Refstack and subunit data
19:10:16 <catherineD> alevine: to recap you know that refstack only accept data in JSON format which is defined by refstack ...
19:10:49 <alevine> catherineD: ok. Maybe next time. I'm working on the promised blueprints/specs now but they are not ready yet for the start of discussion.
19:10:53 <hogepodge> is that link correct? I'm getting a blank etherpad
19:11:38 <catherineD> we try to allow uploading of subunit data format ...
19:11:48 <catherineD> hogepodge: you are right typo ...
19:11:52 <catherineD> #link meeting agenda and notes, please feel free to add items https://etherpad.openstack.org/p/refstack-meeting-15-11-23
19:12:02 <alevine> catherineD: yes I know. However for the sakes of using external test suites some of the json's will have to be upgraded a little.
19:12:52 <catherineD> alevine: sure ... pls propse any update needed
19:13:14 <catherineD> hogepodge:  alevine:  the link should be good now ...
19:13:17 <alevine> catherineD: working on it.
19:14:18 <catherineD> so one of the field we need is CPID (cloud provider id) which is originally define by this spec
19:14:30 <catherineD> #link      Original uuid spec: https://github.com/openstack/refstack/blob/master/specs/proposed/refstack-org-api-cloud-uuid.rst
19:15:59 <catherineD> during IRC meeting last week we agreed that we will use hash of keystone URL as CPID ... this is inaddition to the current method which is using keystone id
19:16:40 <catherineD> so the logic will be  1) first try to get keystone id if fail 2) get use the hash of keystone url ...
19:17:15 <catherineD> with that I kind of concern about the conisistency of the CPID value ...
19:17:49 <catherineD> the question is what is the advantage and gain we get from using keystone service id ... should we just use the hash of the URL?
19:18:34 <hogepodge> I think so.
19:19:53 <catherineD> yup .. I just don't see the value of using the keystone service id if we also allow using the hash of url ...
19:21:00 <catherineD> hogepodge: do you think we need to present this at the defcore meeting ... or do the refstack team just make the decision since we already allow using hashed url amyway ..
19:21:51 <hogepodge> I don't think defcore needs to sign off on it. It's actually a nice solution since it give foundation another way to verify results. You can notify committee of the change though
19:22:42 <catherineD> OK will do
19:25:32 <catherineD> #agreed For the Mitaka cycle RefStack will allow uploading of the subunit data format from refstack-client , hashed of keystone url will be used as CPID
19:26:49 <catherineD> that means that refstack-client will accept the subunit data format, process it to create the JSON data and then upload to RefStack server
19:27:00 <davidlenwell> o/
19:27:10 <alevine> catherineD: I'm sorry, I might be a little slow to get into the stuff so maybe I'm late. But what do we do for Amazon? The cloud doesn't have keystone.
19:27:36 <catherineD> alevine: it should have url right?
19:27:47 <alevine> catherineD: For sure.
19:27:48 <catherineD> a url toget to the cloud
19:28:21 <catherineD> that is what we will use ... and that is the change that we propose here ... may be I should re-phrase the agreement
19:28:29 <davidlenwell> openstack isn't expected to be interopable with amazon.. so refstack wouldn't test it
19:28:40 <alevine> catherineD: Yes I was scared by the "keystone" part.
19:29:44 <alevine> davidlenwell: We did talk about this during the summit and even Chris (if I don't mistake the name) wasn't against RefStack used to verify EC2. Just not as a part of certification of course.
19:30:11 <catherineD> #agreed For the Nitaka cycle, RefStack will allow uploading of the subunit data format from refstack-client hashed of the url used to access the cloud will be used as CPID
19:30:39 <catherineD> eh typo again
19:31:30 <catherineD> #agreed #agreed For the Mitaka cycle, RefStack will allow uploading of the subunit data format from refstack-client,  hashed of the url used to access the cloud will be used as CPID
19:31:44 <davidlenwell> catherineD: +1
19:32:07 <catherineD> davidlenwell:  thx
19:32:58 <catherineD> davidlenwell: I also suggest that we should no  longer using the Keystone service ID as the CPID ... only use hash of the URL
19:33:14 <davidlenwell> catherineD:  I think thats fine
19:33:48 <catherineD> great ... at least with that CPID always means the same thing ...
19:34:28 <catherineD> So one of the action item for me last week is to take a loo at  the size of the subunit data file
19:34:56 <davidlenwell> yes.. wasn't that for you catherineD?
19:34:58 <catherineD> the largest file that I have seen so far is 12 MB.
19:35:11 <catherineD> yes that is for me
19:35:59 <catherineD> the 12 MB file would have around 1200 pass tests ..
19:37:15 <catherineD> to me that is not a small file ...
19:37:30 <davidlenwell> its not too large either
19:37:57 <davidlenwell> especially if you are uploading from some lab or data center.. usually you have good bandwidth and 12mb is nothing
19:38:06 <alevine> catherineD: if we want to allow external test suites we need to define and enforce a limit for this. It can be discussed later but since you're on it right now, just wanted to mention.
19:38:07 <catherineD> yup so concurrency is the other keys that we need to worry about ...
19:39:03 <catherineD> alevine: that is perfectly alright ... this is our last topic for today ...
19:39:36 <catherineD> alevine: so the way we limit the size right now is by doing the processing of the subunit data at the client side
19:40:11 <catherineD> alevine: this is very important when testing is done at the server side (centralize testing)
19:40:37 <davidlenwell> I really think the api should be flexible .. and 12 mb isn't large enough to not add the functionality .. and like alevine says being able to accept subunit allows the api to accept data from more sources..
19:40:40 <davidlenwell> It hink its worth doing
19:40:45 <catherineD> the way the test run today is to finish all test runs store data to the subnit file and then process ...
19:40:52 <davidlenwell> thats just my humble opinion
19:41:00 <alevine> catherineD: I'm saying that there should be some rules defined so that external clients who'd want to add their own tests had a chance to verify something upfront.
19:41:41 <alevine> catherineD: But I'll have to mention it in my specs anyways.
19:41:45 <catherineD> alevine: sorry I was still on the subunit subject
19:42:32 <alevine> catherineD: I thought me too. I was referring to the 12mb of output.
19:43:42 <catherineD> alevine: in your mind where is testing done?  at the client side or server (RefStack) side?
19:44:48 <alevine> catherineD: currently client-side. With centralized testing - test-server side. Which might not be the RefStack-server side. Most probably it is not. So yes, not RefStack-server side.
19:44:54 <catherineD> if the test is run at the client size ... we can limit the data by only send the JSON file which is small because it only contains the pass test case names
19:45:47 <alevine> catherineD: Ok I see that I'm too early with this. Sorry. Let's discuss all of the implications in specs on the matter.
19:46:18 <catherineD> alevine: I think you and I are both forsee and concern about the size of subunit file can be big ...
19:46:35 <alevine> catherineD: exactly
19:48:06 <catherineD> that is why in this cycle we will allow uploading of subunit data but only from the client side .. with that the client size can process  and  reduce the data being upload
19:48:29 <catherineD> but we still need a long term solution later ..
19:49:11 <alevine> catherineD: ok. agree.
19:49:16 <catherineD> alevine: I think the next important step for you is that refstack need to enable testing of external tests with tempest plugin
19:50:06 <alevine> catherineD: yes we have the code that does it. Now we need to present it to, guys, you so that you accept it :)
19:50:23 <catherineD> that is great ...
19:53:47 <catherineD> we have a POC for refstack sometime ago could you take a look to see how close yours and  this code are:  https://review.openstack.org/#/c/214571/
19:55:09 <alevine> catherineD: we'll look
19:55:39 <catherineD> alevine: thank you ... enable plug-in is our next priority for refstack-client
19:55:55 <alevine> catherineD: perfect
19:55:58 <catherineD> #topic Open discussion
19:56:23 <catherineD> anything else ?
19:56:51 <rockyg> so, this discussion on whether a linux guest should be required....
19:57:12 <catherineD> This week is Thanksgiving Holidays in the US ... a lot of people are on vacation .. expect slow week
19:57:47 <catherineD> hi rockyg: we did not discuss that ...
19:57:51 <rockyg> Wanted the input from refstack folks
19:58:13 <catherineD> rockyg: go ahead ..yup important topic
19:58:29 <rockyg> yeah.  I think we should.  Especially imact to refstack code base.
19:58:52 <catherineD> rockyg: maybe put it on next week agenda?
19:59:01 <rockyg> sounds good.
19:59:03 <catherineD> to ensure that we discuss it
19:59:55 <rockyg> big question is how much of refstack client is shell scripts rather than python or other OS independent languages
20:00:03 <catherineD> alright  ... that is all the time we have ... Have a nice Thanksgiving Holiday!
20:00:14 <rockyg> Thanks!
20:00:28 <rockyg> Happy turkey day!
20:00:30 <catherineD> #endmeeting