19:00:30 <catherineD> #startmeeting refstack
19:00:32 <openstack> Meeting started Mon Feb  8 19:00:30 2016 UTC and is due to finish in 60 minutes.  The chair is catherineD. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:33 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:35 <openstack> The meeting name has been set to 'refstack'
19:02:22 <pvaneck> o/
19:03:59 <alexandrelevine> o/
19:05:10 <catherineD> hi pvaneck: alexandrelevine: Let's waite for a couple more mins
19:05:52 <catherineD> #link meeting agenda and notes, please feel free to add items https://etherpad.openstack.org/p/refstack-meeting-16-02-08
19:06:12 <rockyg> o/
19:06:28 <catherineD> rockyg: Hi
19:07:52 <catherineD> Let's start
19:07:53 <catherineD> #link meeting agenda and notes, please feel free to add items https://etherpad.openstack.org/p/refstack-meeting-16-02-08
19:08:15 <catherineD> #topic      Organization and product entities
19:08:23 * rockyg waves
19:08:38 <catherineD> #link Implementation :  https://review.openstack.org/#/c/269066/
19:09:00 <catherineD> I really would like us to focus on review and merge this one ...
19:09:25 <catherineD> #link     Product type vs object type.  Please see comments on line 68 https://review.openstack.org/#/c/269066/22/refstack/api/constants.py
19:10:49 <catherineD> 3 options are suggested in the comments.... is there any other options?
19:11:06 <alexandrelevine> My preference is type - product_type
19:11:21 <alexandrelevine> option 1
19:11:29 <catherineD> alexandrelevine: thx
19:11:37 <catherineD> pvaneck: rockyg: how about you?
19:11:50 <rockyg> lemme do a quick review...
19:12:32 <pvaneck> would product_type be a property or another column?
19:12:43 <rockyg> I'm having a problem with my browser...
19:13:07 <catherineD> pvaneck: an other column ..
19:13:48 <catherineD> pvaneck: is there a way to represent the property without a  column?
19:14:30 <alexandrelevine> catherineD: Yes. In the properties
19:15:38 <catherineD> that bring us to the next discussuon ... a properties columns is added to the organization column is this for the product type?  What else can be saved there?
19:15:40 <alexandrelevine> catherineD: We can store there everything of not much importance which we won't require for indexing or fast search. In fact, with our small number of expected vendors it doesn't matter much.
19:15:51 <pvaneck> do we plan on having different treatments based on product_type where quick lookups are necessary? or are product types just informational items that will be on the product page
19:16:18 <alexandrelevine> catherineD: I explained. Each vendor in the marketplace has some descriptive and other fields and properties. We need to store them.
19:16:29 <alexandrelevine> catherineD: They'll be asked during vendor registration.
19:16:33 <rockyg> vendor specific metadata
19:16:37 <catherineD> pvaneck: product type informatio will be on the product page ... and yes we may want  to filter wit hit
19:16:39 <alexandrelevine> catherineD: Reviewed and approved by the Foundation.
19:16:39 <catherineD> with it
19:17:38 <catherineD> rockyg: alexandrelevine: if it is vendor meta data and free form .. wouldn't using a meta table would be better?
19:18:13 <alexandrelevine> catherineD: I believe we discussed it. My personal preference is not to spawn many tables. json in the same table will do just fine.
19:18:34 <alexandrelevine> I even remember someone objecting against xml :)
19:19:20 <catherineD> alexandrelevine: my issue is how do we parse the information in the properties column?
19:19:32 <catherineD> but let's go back to product_type ...
19:19:36 <alexandrelevine> catherineD: We load it and parse it as any other json.
19:19:55 <catherineD> alexandrelevine: with any json it is good to have a schema
19:20:06 <pvaneck> properties json will simply be displayed on a product page catherineD
19:20:24 <alexandrelevine> catherineD: We can devise something very simple key-value-like.
19:20:43 <catherineD> pvaneck: alexandrelevine: where do we save the product_type?
19:21:02 <alexandrelevine> catherineD: If you want better modifiability in the future - in the properties.
19:21:46 <catherineD> alexandrelevine: just want to confirm ... you are saying that we save the product_type property in the properties column
19:21:55 <catherineD> as one of the element in the JSON
19:22:02 <alexandrelevine> catherineD: If you want to do paging filtered by product types in the list of Vendors on the server - column.
19:22:13 <alexandrelevine> catherineD: Yes.
19:22:45 <pvaneck> If we plan on filtering based on these specific product types, then yea, better to be its own column
19:22:46 <catherineD> alexandrelevine: we can filter vendor list request by product_type?
19:22:55 <pvaneck> but if purely informational, then properties
19:22:56 <catherineD> pvaneck: ++
19:23:09 <alexandrelevine> catherineD: We can do whatever we want :)
19:23:12 <catherineD> that if we want to filter it is better with its own column
19:23:42 <catherineD> alexandrelevine: sure that is why we discuss here on the best way to implement ...
19:23:56 <alexandrelevine> catherineD: Keep in mind that paging and filtering can be done in DB or in the code on the server. In the second case you don't need a column also.
19:24:50 <alexandrelevine> catherineD: Honestly, we're dealing with such small numbers of Vendors that I don't expect any problems whichever way we go.
19:25:03 <catherineD> OK like anything there is always many ways to approach ...
19:25:38 <alexandrelevine> catherineD: Choose the approach you like :)
19:25:43 <rockyg> I like separate column
19:26:03 <catherineD> I lkie separate column
19:26:07 <catherineD> like :-)
19:26:11 <alexandrelevine> separate column it is.
19:26:21 <rockyg> Could get messy if OpenStack gets big and people get real creative ;-)
19:26:36 <catherineD> I guess pvaneck: is OK with separate column ...
19:26:55 <pvaneck> sure
19:27:16 <catherineD> great !!
19:27:25 <catherineD> #topic Do we need the properties columns ?
19:27:34 <alexandrelevine> we do
19:28:01 <catherineD> I guess it would not hurt .. so I don't mind ... but if we store JSON .. I would like us to have a schema defined ...
19:28:03 <rockyg> yeah, I think so.
19:28:21 <pvaneck> i thought just key value pairs in json was fine
19:28:49 <alexandrelevine> See example page of one of the vendors: https://www.openstack.org/marketplace/public-clouds/cloud-and-heat-technologies/cloud-heat
19:29:01 <catherineD> #ageed To add a product_type and properties columns to the organization table
19:29:14 <alexandrelevine> It has "about", "commitment", "details" and some other stuff.
19:29:36 <catherineD> hey we are doing good today ...
19:29:50 <rockyg> ++
19:29:54 <catherineD> next product type names:
19:30:32 <rockyg> separate names for distro and appliance.  For display, we can always do an OR
19:30:34 <catherineD> should match with OpenStack Marketplace
19:31:13 <rockyg> Right now, appliances are kind of a step child.  Not many left.  But that will change as OpenStack gets more consistent
19:31:27 <alexandrelevine> We should ask DefCore. But for speed sakes we can start with "distro", "public cloud", "hosted private cloud" (maybe just private cloud?) only.
19:31:39 <catherineD> alexandrelevine: ++
19:32:06 <catherineD> alexandrelevine: I vote for hosted_private_cloud...
19:32:20 <alexandrelevine> I don't mind.
19:33:09 <catherineD> do we all agree for now product type are: distro, public_cloud, hosted_private_cloud (we can add appliance later)?
19:33:18 <alexandrelevine> ++
19:33:22 <pvaneck> +1
19:33:59 <rockyg> ++ for hosted in front.  wondering if we'll see private private cloud in future
19:34:16 <catherineD> #agreed Product type names are distro, public_cloud, hosted_private_cloud (and may add appliance later)
19:34:22 <catherineD> rockyg: +2
19:35:38 <catherineD> so would all of the agreement here .. after andrey updates https://review.openstack.org/#/c/269066/  please give it a priority for review ... it would be good if we can merge it in the next 2 days
19:35:59 <catherineD> thank you all!
19:36:08 <rockyg> yay!
19:36:22 <alexandrelevine> great
19:36:28 <catherineD> #topic     private_vendor vs pending_vendor.
19:36:58 <catherineD> alexandrelevine: private_vendor:  can be create by any user.  Do we still need the hidden vendor as described in the Ownership section on page 12 of the requiement document?
19:37:14 <alexandrelevine> Nothing to discuss here: hidden is private. The term is interchangeable. I just used it in the reqs doc to say that those are hidden vendors.
19:37:59 <alexandrelevine> Hidden in the doc meant exactly that - hidden. It's not good to use this term in the constants, though. That's why private.
19:38:01 <catherineD> alexandrelevine: since user can create vendor , I would like for us not to automatically create a vendor
19:38:29 <catherineD> we require that a vendor has to be created before a product creation ...
19:38:38 <alexandrelevine> catherineD: You'll complicate UI.
19:38:54 <catherineD> how?
19:39:05 <alexandrelevine> catherineD: Better usability wouldn't require User to create something he doesn't care about.
19:39:21 <alexandrelevine> catherineD: He doesn't need Vendor. He wants to test his Cloud, i.e. Product.
19:39:33 <catherineD> alexandrelevine: I agree with the product has its own users
19:39:54 <alexandrelevine> catherineD: I didn't understand what you just said.
19:40:06 <catherineD> now with users at the vendor level ... wouldn't it be better for him to know where to add user for his vendor?
19:40:30 <alexandrelevine> catherineD: I'm a user and I don't want to manage vendors or  other users. I want to test my Cloud.
19:41:13 <catherineD> alexandrelevine:  do you want someone else to see your result before you make it public?
19:41:37 <alexandrelevine> Use-case 4
19:42:11 <alexandrelevine> catherineD: You'll create a screenshot and send it by email.
19:42:17 <alexandrelevine> catherineD: there is no such use-case now.
19:42:36 <alexandrelevine> catherineD: It's either private, i.e. yours only, or public.
19:42:49 <catherineD> alexandrelevine: could we modify your use case ? that the user can share his/her data before making it public?
19:43:09 <alexandrelevine> catherineD: Not without several more use-cases and complications. Why?
19:44:10 <catherineD> my issue is your say private = yours only
19:44:18 <alexandrelevine> catherineD: And we shouldn't modify it because it exists. It's the most easy-to-start use-case for any user. What you ask about is one of the variations which can exist but I don't see why we need it now. And definitely not instead.
19:44:33 <alexandrelevine> catherineD: Yes. That's how it works now.
19:45:08 <alexandrelevine> catherineD: Later, much later, when we get basic functionality and process feedback from users we'll see if we want to go that route to extend.
19:45:51 <catherineD> alexandrelevine: Company ABC  registers ... so  a vendor is create of this vednor ABC... what is the type of this vendor?
19:46:10 <catherineD> private?
19:46:17 <alexandrelevine> catherineD: I didn't understand.
19:46:25 <alexandrelevine> catherineD: Company ABC registers what?
19:46:46 <catherineD> Company ABC register itself as a vendor on RefStack
19:47:15 <alexandrelevine> catherineD: When it registers a Vendor, i.e. uses the button Register, it becomes Pending.
19:47:26 <alexandrelevine> catherineD: When it was just created, yes, it was Private.
19:47:41 <alexandrelevine> catherineD: When Foundation approves it becomes Official and public.
19:48:16 <catherineD> so when a vendor object is created it is of type private?
19:48:23 <alexandrelevine> Of coures
19:48:28 <alexandrelevine> of course
19:48:52 <catherineD> how do you different this private vs the private vendor that was created automatically?
19:49:08 <alexandrelevine> Ok, you're right. Let's add one more type then - personal?
19:49:21 <rockyg> Good catch!
19:49:25 <alexandrelevine> Or really "hidden"?
19:49:26 <catherineD> alexandrelevine: yea that is what I want to say
19:49:56 <catherineD> so vendor type = offical, pending, private, personal?
19:50:18 <catherineD> official
19:50:26 <alexandrelevine> Or we can go a little different here. We can automatically create a private Vendor for User when he wants to add a Product.
19:51:16 <rockyg> I think Official/prending is separate from public/private
19:51:39 <rockyg> You might want official+private
19:51:52 <alexandrelevine> Private->Pending->Official(if accepted) or Private(if declined)
19:51:54 <catherineD> still go back to the question of how to differentiate if both automatically created vs someone created vendors if both are of type private
19:52:03 <alexandrelevine> It's notseparate
19:52:18 <alexandrelevine> We don't differentiate in this case
19:52:59 <alexandrelevine> User can create a Vendor manually or get a default automatically created one
19:53:14 <catherineD> ok so on 'my vendor' UI, do we display all vendor including automatically created privated?
19:53:23 <alexandrelevine> In this case yes
19:53:47 <alexandrelevine> It'll just have some predefined automatically generated name. Like "auto-created" or "default"
19:53:48 <catherineD> how  to go from private to pending ...
19:54:01 <alexandrelevine> Push button "register"
19:54:10 <alexandrelevine> (or "apply" - whatever we name it)
19:54:32 <catherineD> so user can register an automatically created private vendor and make it pending?
19:55:03 <catherineD> do we allow that?
19:55:04 <alexandrelevine> catherineD: We can prevent it
19:55:17 <catherineD> how to prevent?
19:55:21 <alexandrelevine> catherineD: Because we don't want Foundation to be spammed with "Default" Vendors.
19:55:34 <alexandrelevine> catherineD: Check for some meaningful name.
19:55:59 <catherineD> alexandrelevine: wouldn't it be better to give it another type then check the name?
19:56:06 <alexandrelevine> catherineD: If he cares to rename it and fill in all of the required "abouts" he can register, yes
19:56:47 <alexandrelevine> catherineD: Not really
19:57:01 <catherineD> why not?
19:57:15 <alexandrelevine> catherineD: Why do we care if it was created manually or automatically if everything was correctly prepared for registration afterwards?
19:57:29 * catherineD we only have 3 mins left ...
19:57:47 <alexandrelevine> catherineD: We'll be checking saneness of the input before registration anyways.
19:58:05 <catherineD> alexandrelevine: i don't mind if that is what we allow ... I just want us to think thru the scenario
19:58:19 <catherineD> I definitely do not want to check name
19:58:26 <alexandrelevine> catherineD: Thanks to you we just did. As far as we can now :)
19:58:50 <catherineD> if I am going to check something make it obvious for the next code reader ..
19:58:58 <alexandrelevine> catherineD: We'll have to check the name anyways. For allowed symbols and such.
19:59:09 <catherineD> we are about out of time ...
19:59:15 <alexandrelevine> catherineD: We can leave it empty, for example. So it won't pass
19:59:18 <catherineD> let's move to #refstack
19:59:23 <catherineD> #endmeeting