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