19:00:06 <catherineD> #startmeeting refstack 19:00:07 <openstack> Meeting started Mon Dec 14 19:00:06 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:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:00:11 <openstack> The meeting name has been set to 'refstack' 19:00:26 <catherineD> #link meeting agenda and notes, please feel free to add items https://etherpad.openstack.org/p/refstack-meeting-15-12-14 19:01:29 <pvaneck> o/ 19:02:23 <catherineD> pvaneck_: Hi ... 19:02:25 <alevine> o/ 19:03:51 <catherineD> alevine: Hi .. I need to apologize that my internet maybe slow today ... I am not in the office 19:05:09 <catherineD> alevine: Thanks for all the activities from your team .. together we can make a different in RefStack 19:05:37 <pvaneck_> Do you have an agenda link 19:05:57 <catherineD> #link meeting agenda and notes, please feel free to add items https://etherpad.openstack.org/p/refstack-meeting-15-12-14 19:06:11 <catherineD> Let's start 19:07:08 <catherineD> #topic Confirm on data model ( https://goo.gl/zWYnoq) agreement and proceed to implementation 19:09:21 <sslypushenko___> o/ 19:09:52 <catherineD> I just see Mark submitted a patch today https://review.openstack.org/#/c/226902/ 19:10:33 <pvaneck_> No real objections here to the data model 19:11:15 <catherineD> sslypushenko___: we are at topic 1 on https://etherpad.openstack.org/p/refstack-meeting-15-12-14https://etherpad.openstack.org/p/refstack-meeting-15-12-14 19:11:15 <rockyg> o/ 19:11:43 <catherineD> rockyg: Hi agenda https://etherpad.openstack.org/p/refstack-meeting-15-12-14 19:11:53 <sslypushenko___> catherineD Thx! 19:12:10 <rockyg> THx! 19:12:26 <sslypushenko___> Suggested data model works for me 19:13:04 <catherineD> we also need to make sure that the model works for alevine: ... so I suggest that we do not make decision today .... so that we can review Mark's patch .. 19:13:05 <sslypushenko___> I think we can discuss details during implementation 19:13:16 <catherineD> sslypushenko___: +1 19:13:32 <alevine> catherineD: I sent my comments by email earlier today. Have you got it? 19:13:54 <catherineD> sslypushenko___: maybe I just sumit a spec and then we can make further comments... 19:14:22 <sslypushenko___> catherineD yeap, that will work 19:14:30 <catherineD> alevine: Yes ... Just see it thx a lot! I want to review and make sure that the model works for you ... 19:14:37 <alevine> catherineD: In short I don't see why do we need roles. And I don't see why do we still need meta. 19:15:40 <catherineD> alevine: 's question is why do we store openid in meta rather than in the test table ? Let us know if I do not phase your question correctly 19:15:44 <alevine> catherineD: And we'd need to add schemas table with properties: id, owner_id, version, name, json. Something like it. 19:16:22 <sslypushenko___> catherineD, Can you please forward alevine's mail to me? 19:16:30 <catherineD> the reason we put user_id in meta because sometime we have anonymous data upload ... in this case we do not have user ID 19:16:48 <alevine> catherineD: Yes, I don't see why. user_id used to run the test is one of the important properties for the test. I understand, historically you didn't want to put public_key there but now it's possible to store user_id along with cpid. 19:17:21 <alevine> catherineD: You can make it optional then. 19:18:06 <sslypushenko___> alevine We are trying to keep as much data as it possible in metadata 19:18:12 <catherineD> sslypushenko___: good idea ... I just forwarded alevine: 's email ... 19:18:32 <alevine> catherineD: It doesn't stop us at all. It's just it seems more straight and readable to me as a data model. This is a primary property, not to be buried in some meta-data key-value, I'd say. 19:19:17 <sslypushenko___> catherineD Got it, thx 19:19:56 <catherineD> alevine: another reason is originallywhen the data was uploaded it was owned by the user...but once the data is associated to a product as described in slide 4 ... it will be onwed by the product_group ... user no longer valide 19:21:02 <alevine> catherineD: As I understand the new model now from you doc - the user should be authorized to upload data for some particular vendor's product. In which case, this user should be in vendor's or product's group - not just some guest. No? 19:21:07 <catherineD> in this case the user_id field will mostly empty for the 2 case 1) anonymous upload 2) ownership change 19:22:02 <catherineD> alevine: as designe any one can upload data ... no pre-requirement that the user belong to a any vendor or product ... 19:22:02 <alevine> catherineD: I don't understand the idea of ownership change in view of groups, products and vendors. Could you please explain? 19:22:33 <alevine> catherineD: How do you guarantee then that it's a valid upload which results can be used for certification? 19:22:34 <catherineD> so if user John upload data .. at firest he owns it 19:22:56 <alevine> catherineD: Only because this user has public key? 19:23:11 <catherineD> alevine: yes 19:23:35 <catherineD> so say there is product foo 19:24:02 <alevine> catherineD: In which case I actually do not care about the uploading user. I care about the ownership. Meaning that public key was also generated for some identity, right? I'd say we should use that one in the user_id field. 19:24:06 <catherineD> and foo has a group_foo which john is a user in the group wirh role admin 19:24:33 <catherineD> he then can change the owner of the data to foo_group ... 19:25:03 <catherineD> group will allow more than one users 19:25:09 <alevine> catherineD: Or if we do not care about the owner at all, then why would we need to store user_id at all? Even in meta? Isn't cpid (product_id) enough? 19:25:15 <catherineD> incase user quit comapany or absent 19:25:46 <catherineD> we store the user_id so he can associate data to a product 19:26:07 <alevine> catherineD: What is cpid than? Isn't it the cloud_id=product_id? 19:26:14 <alevine> "then" 19:27:38 <sslypushenko___> alevine Not exactly 19:27:54 <Guest75565> once a data is associated to a product all user belongs to that product_group would admin role can manage the data 19:28:12 <alevine> sslypushenko: What's the difference? 19:28:14 <sslypushenko___> It is unique id for some cloud 19:29:06 <sslypushenko___> We can not be sure that in the wild cpid will acts like an product_id 19:29:13 <alevine> sslypushenko: If it's just a subproduct why do we need to store it in our test table? We need to convert it into product_id and store the very one. 19:29:49 <sslypushenko___> The most value from cpid it is UX 19:29:59 <alevine> sslypushenko: If we can't convert it to product_id then we have absolutely no idea what was tested. What's the point of such results? 19:30:40 <sslypushenko___> cpid contains some info about product, but it is not 1-to-1 relation 19:31:48 <Guest75565> sslypushenko__: +1 19:32:16 <sslypushenko___> We should trust users, because we don't have a choice, so we any can assume that user will provide product_id correctly 19:32:19 <Guest75565> I really want to discuss the next subject which is about CPID 19:32:21 <alevine> sslypushenko: :) I still don't quite understand. I understand the use-case - someone tested some cloud and uploads results. We need to figure out what cloud was that, right? In our new terms it's called product_id. If cpid contains some more info we can store it too, but product_id is the primary info out of it, no? 19:32:46 <sslypushenko___> We means refstack-team? 19:32:51 <Guest75565> can I suggest that I take the first pass to response to Alex's note ... we can then discuss from there? 19:33:09 <alevine> sslypushenko: Of course. 19:33:17 <sslypushenko___> product_id is the primary info out of it - you absolutely right! 19:33:18 <Guest75565> catherin is Guest75565 :-) 19:33:45 <sslypushenko___> but it is quite tricky to make it works 19:33:53 <alevine> catherineD: sure. Don't mind me. Just go ahead. 19:34:08 <sslypushenko___> Refstack try to keep things simple 19:34:22 <sslypushenko___> so we just stick to cpid for a while 19:34:37 <Guest75565> I think it is relevant could we go to the next topic to discuss CPID? 19:34:48 <alevine> sslypushenko: Yes, but we're discussing the data model. It should be transparent. Especially the relation between test and it's source. Isn't it? 19:35:00 <alevine> catherineD: yes :) 19:35:00 <sslypushenko___> Yeap) 19:35:22 <Guest75565> #topic Use cloud access URL to generate CPID. 19:35:42 <Guest75565> #link https://review.openstack.org/#/c/255607/ 19:36:46 <sslypushenko___> I'm +1 for using access URL only as a failover 19:36:56 <Guest75565> the discussion is about should we keep using keystone ID for CPID... 19:37:29 <Guest75565> one of the big thing coming up is in 19:37:35 <Guest75565> #link https://bugs.launchpad.net/refstack/+bug/1500280 19:37:35 <openstack> Launchpad bug 1500280 in refstack "RefStack client should use session based keystone auth for CPID" [Medium,Confirmed] - Assigned to Daryl Walleck (dwalleck) 19:37:59 <Guest75565> if we keep using CPID we need to upgrade as describe in the bug ... 19:38:07 <rockyg> thanks Guest75565 for identifying yourself! 19:38:14 <alevine> Guest75565: Where is possible to read about the meaning of CPID and it's purpose? Is it just a technical varchar ID which is used to identify the cloud tests were run on or something else as well? 19:38:25 <Guest75565> why take the resource to develop something that if it does not work will go to using URL 19:38:35 <sslypushenko___> We spent a lot of affords on make current code working 19:39:16 <pvaneck_> I think one of the use cases of cpid was to be able match the test runs of the same cloud together 19:39:21 <Guest75565> rockyg: sorry catherine switch to web interface so still have the other client log in 19:39:49 <alevine> pvaneck_: That's the obvious one. Anything else? 19:39:49 <sslypushenko___> pvaneck_ It will not work 19:40:04 <Guest75565> sslypushenko___: I know ... I know ... and it will demand more time to upgrade ... 19:40:23 <sslypushenko___> Every cloud have a bunch of endpoints 19:40:39 <sslypushenko___> at least one per region 19:41:48 <Guest75565> alevine: read about CPID in https://github.com/openstack/refstack/blob/master/specs/prior/implemented/refstack-org-api-cloud-uuid.rst 19:42:10 <Guest75565> #link orginal spec for CPID https://github.com/openstack/refstack/blob/master/specs/prior/implemented/refstack-org-api-cloud-uuid.rst 19:42:37 <alevine> Guest75565: Thank you 19:42:47 <Guest75565> #link current suggested spec for CPID https://review.openstack.org/#/c/255607/ 19:43:15 <sslypushenko___> from POV new CPID mechanism is not significantly better then previous one 19:43:27 <Guest75565> really I just do not see the value of using Keystone ID now that we learn more about Keystone 19:43:43 <sslypushenko___> except that it will work even for public clouds 19:44:15 <alevine> Now that we introduce vendors and products and stuff, does it still make sense to have such a strange id? Wouldn't we want to record some info (mac-address, url, ...) during product registration and use it afterwards? 19:44:17 <Guest75565> sslypushenko__: +1 both are not perfect .. but one is with less effort 19:44:32 <sslypushenko___> May we should keep it both? 19:44:48 <Guest75565> alenvine: for the case of anonymous data upload yes ... we need something 19:45:13 <alevine> Guest75565: I mean that in that old spec, it's stated that cpid is needed to 'somehow' group results together. It sounds really weird for certification cases now, doesn't it? Sorry if I'm mistaken. 19:45:21 <Guest75565> if we keep both .... do we need to upgrade to catch up with Keystone? 19:45:35 <Guest75565> I am OK to keep both if we do not spend any effort .. 19:45:51 <Guest75565> on development to keep up with Keystone 19:45:59 <alevine> Guest75565: I don't quite understand what is anonymous data upload now. What is the purpose of it? 19:46:35 <alevine> Guest75565: I mean how would we even show it? As some results for some cloud? What's the point? 19:47:20 <sslypushenko___> alevine People want just to try what RefStack is 19:47:23 <Guest75565> to encourage people to upload data or test (once we offer centralize testing ) ... this is for any user of the cloud not necessary the vendor or product onwer 19:49:07 <Guest75565> most of the community data in RefStack today is uploaded anonymously ... we do that ti encourage larger user base to use RefStack with minimum intimidation 19:49:59 <alevine> ssplypushenko___: Ok. Let's suppose I'm such a user. How would I see my results afterwards? I should be a registered user in RefStack to be able to somehow see those results. I understand that it's possible to find me by my public-key used, no? Then you'd want to allow results without registered cloud, right? 19:50:12 <Guest75565> so I guess the agreement is to keep current CPID creation but add URL generation option with no Keystone update? 19:50:44 <sslypushenko___> alevine During uploading you will get a link on your results 19:51:10 <Guest75565> time check ... 10 mins left ... I really need to get to the next topic ... wihich is do we need to have meeting for the next 2 weeks? 19:51:16 <alevine> sslypushenko: Oh, ok. 19:51:36 <sslypushenko___> So you can review uploaded results and get some UX experience from RefStack 19:52:14 <alevine> Guest75565: We're quite fine with what we have. I guess the rest can be discussed in email. 19:52:34 <Guest75565> sorry everyone ... 19:52:44 <sslypushenko___> catherineD May be we will establish meeting with alevin, if there are some questions for disscuss 19:52:48 <Guest75565> do we need to meet on 12/21/2015? 19:53:10 <Guest75565> I will be here ... just want to see everyone else's schedule ? 19:53:29 <sslypushenko___> 12/21 will work for me 19:53:56 <Guest75565> sslypushenko__: +1 to have additional meeting with SAlex 19:54:00 <alevine> Guest75565: Whatever you decide, I'm fine. 19:54:01 <Guest75565> I will schedule ... 19:54:02 <pvaneck_> Will be on vacation, but can join 19:54:21 <Guest75565> #agreed we will have meeting on 12/21/2015 19:54:27 <Guest75565> how about 12/28? 19:54:39 <sslypushenko___> will work for me too 19:55:02 <Guest75565> #agreed Caterine will call addtiional meeting with RefStack cores and Alex for futher discussion 19:55:13 <alevine> all: One last thing. I might be wrong, but it seems to me that we're changing the RefStack quite a bit so maybe it's time to rethink old use-cases like having UX experience from RefStack or just playing with it. They won't nicely fit into new world as they are, I'm afraid. 19:55:26 <Guest75565> I will be on vacation on 12/28 .. 19:55:56 <Guest75565> but can join the meeting too ... 19:56:11 <Guest75565> looks like we will have meeting on 12/28 too :-) 19:56:21 <sslypushenko___> Let decide it on next meeting) 19:56:34 <Guest75565> +1 good idea 19:56:40 <Guest75565> 4 mins left .. 19:56:57 <Guest75565> I will schedule additional meeting before net Monday 19:57:03 <sslypushenko___> But it really looks that some F2F meeting can help us to get understanding 19:57:21 <pvaneck_> +1 on reevaluating Ux 19:57:30 <Guest75565> how about web meeting and phone like we did last time .. 19:57:40 <sslypushenko___> +1 19:58:05 <alevine> sslypushenko__: If as I presume you're in the same city as we are, we can meet here and you can convey all the sacred knowledge to us much easier :) 19:58:09 <Guest75565> I will schedule .... hope your skype did not charge you last time .. 19:58:36 <sslypushenko___> alevine I'm in Ukraine) 19:58:50 <Guest75565> wow that works ... I should ask to have a mid-cycle in Moscow? :-) 19:58:51 <alevine> sslypushenko___: Ouch. My mistake :) 19:59:00 <Guest75565> oh ... 19:59:19 <Guest75565> ok I will schedule a conf call and then we will go from there ... 19:59:20 <sslypushenko___> Keiv would be better) 19:59:31 <rockyg> Would love to visit Kiev 19:59:43 <Guest75565> RefStack is a truly global team 19:59:45 <sslypushenko___> Your are welcome) 19:59:51 <Guest75565> I need to end the meeting 19:59:56 <Guest75565> thx you all ... 19:59:56 <alevine> sslypushenko___: I'd love too. Was there several times. But you know, it might be problematic :) 20:00:17 <sslypushenko___> Thx 2 all! 20:00:18 <rockyg> Grandmother is from Simferopol 20:00:25 <rockyg> Thanks! 20:00:30 <Guest75565> #endmeeting