19:01:12 <catherineD|2> #startmeeting refstack
19:01:12 <openstack> Meeting started Mon Feb  1 19:01:12 2016 UTC and is due to finish in 60 minutes.  The chair is catherineD|2. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:01:15 <openstack> The meeting name has been set to 'refstack'
19:02:22 <pvaneck> o/
19:02:45 <alexandrelevine> o/
19:03:28 <catherineD|2> #link meeting agenda and notes, please feel free to add items https://etherpad.openstack.org/p/refstack-meeting-16-02-01
19:05:04 <alexandrelevine> Hi, everybody. FYI: thanks to Andrey, here is the RefStack with implemented Vendors (you'll have to click fake Sign-In to see all) - http://52.49.129.72:8000/#/
19:06:23 <catherineD|2> alexandrelevine: that is great... yea thx to Andrey ...
19:07:07 <catherineD|2> should foundation be listed in the vendor list?
19:07:44 <alexandrelevine> It will.
19:07:52 <catherineD|2> but should it?
19:08:00 <alexandrelevine> When it'll register Vendor OpenStack - it'll show.
19:08:04 <sslypushenko> o/
19:08:07 <alexandrelevine> Why not?
19:08:09 <catherineD|2> in fact that is one of the topic for today;s discussion ...
19:08:37 <catherineD|2> sslypushenko: #link meeting agenda and notes, please feel free to add items https://etherpad.openstack.org/p/refstack-meeting-16-02-01
19:08:42 <alexandrelevine> Isn't it a Vendor? I'd say it's the most important one. And should be proudly displayed :)
19:08:46 <sslypushenko> catherineD|2:  thx
19:09:11 <andrey-mp> I list Foundation in the list to make a link to Foundation page where user management will be.
19:09:21 <catherineD|2> #link Andrey's prototyp vendor UI http://52.49.129.72:8000/#/
19:10:10 <catherineD|2> alexandrelevine: andrey-mp: we will discuss this later ..
19:10:31 <catherineD|2> #topic Organization and product entities
19:10:45 <catherineD|2> #link     Database tables spec :  https://review.openstack.org/#/c/268922/
19:11:31 <catherineD|2> once sslypushenko: review the spec .. we should be ready to merge ...
19:11:55 <catherineD|2> next could every one review Andrey's implementation ...
19:11:56 <sslypushenko> sslypushenko: Will do it after this meeting
19:12:27 <catherineD|2> #link organizatio/product data model implementation :  https://review.openstack.org/#/c/269066/
19:12:32 <catherineD|2> sslypushenko: thx
19:13:19 <catherineD|2> next I would liketo go to topic #3 first
19:13:33 <catherineD|2> #topic Product types:
19:14:02 <catherineD|2> I suggest we use the same terms as used in the OpenStack Marketplace ...
19:14:13 <sslypushenko> catherineD|2:  +1
19:14:44 <catherineD|2> in that way the marketplace can just is a link from refstack for detail data of the certifiication ...
19:14:58 <alexandrelevine> catherineD: What do we gain? Are there any reqs motivating this?
19:15:10 <catherineD|2> so software product is actually distor
19:15:33 <alexandrelevine> "distro" is fine but I don't see what's wrong with "software"
19:16:25 <alexandrelevine> distribution - is just a subset of software products. If I create my own Hello world script, put it into my cloud and register it for myself to test - it's not a distro, right?
19:17:06 <catherineD|2> I would like to replace the link (full results) in this page https://www.openstack.org/marketplace/distros/distribution/ibm/ibm-cloud-manager-with-openstack with a link to RefStack
19:18:22 <catherineD|2> and I do not want to confuse openstack user
19:18:27 <sslypushenko> alexandrelevine:  using the same terms with openstack.org will reduce user confusing.  It is enough  reason for such naming. Don't you think so?
19:19:27 <alexandrelevine> sslypushenko: No, because it expands a number of types which will cause more problems. We'll need to define use-cases to work with those types. User will have to define it. What happens, when some private cloud becomes public. And so on.
19:19:37 <catherineD|2> if you clich "show full result link" on that page it goes to a table ... I would like that link to go to refstack
19:20:36 <alexandrelevine> catherineD: I don't see how it relates to our naming in DB. I still think terms software and cloud are the most generic, native and safe. If we decide to somehow display them by political reasons later with other names - we'll have the chance.
19:20:56 <sslypushenko> alexandrelevine:  If product type changes, we should change it in DB. Do we have other options?
19:21:00 <alexandrelevine> catherineD: And again - the software we're speaking of not only "distros"
19:21:04 <catherineD|2> alexandrelevine: on the box where you lable software you  can put (software, distro, appliances) ,,, they are the names of the entities that are privately held .. that is the main point ...
19:21:38 <alexandrelevine> sslypushenko: Exactly. Which will create even more problems. All of this should be documented, thought of and (most important) traced to requirements. Do we have such requirements for such complications?
19:22:07 <rockyg> oops.  here now.
19:22:25 <catherineD|2> rockyg: #link meeting agenda and notes, please feel free to add items https://etherpad.openstack.org/p/refstack-meeting-16-02-01
19:22:32 <alexandrelevine> catherineD: I don't see what's wrong with software as a type in DB opposing cloud. I'm against "distro"
19:23:15 <sslypushenko> alexandrelevine:  we don't have such kind of issues now and I don't get why we can not change type in if it changes...
19:23:32 <catherineD|2> andrey-mp: what are the constants that you used for product?
19:23:54 <sslypushenko> alexandrelevine:  What is your point here?
19:24:01 <andrey-mp> right now I defined two constants - software and cloud :)
19:24:21 <alexandrelevine> sslypushenko: Right now in the requirements and in the model we have just two types: software and cloud. Now 3 are suggested - software (or distro) and two kinds of cloud types. Model will change. UI will change. All of it should be described in requirements, no?
19:24:23 <sslypushenko> It looks like I missed some part of discussion)
19:24:25 <andrey-mp> because implementation doesn't need more than two
19:24:47 <alexandrelevine> sslypushenko: What do you mean what is my point? :)
19:25:09 <alexandrelevine> sslypushenko: I thought it's obvious. I don't want to have to types of clouds because it's not motivated by requirements.
19:25:20 <sslypushenko> How it is effects UI? It should be agnostic to number of product types
19:25:21 <alexandrelevine> "two types"
19:25:42 <alexandrelevine> sslypushenko: How during cloud registration we determine which type to use - public or private_host_cloud?
19:26:04 <catherineD|2> alexandrelevine: you do ...
19:26:24 <catherineD|2> vendor know what kind of product they have ...
19:26:24 <sslypushenko> Under "we" you means RefStack?
19:26:30 <alexandrelevine> catherineD: Sorry, I lost you :) What "I do"?
19:26:37 <alexandrelevine> sslypushenko: Yes
19:27:07 <alexandrelevine> catherineD: sslypushenko asked how it affects UI. Vendor will have to manually enter the type of the cloud which he doesn't have to currently.
19:27:22 <catherineD|2> RefStack won't know which kind of product ... type  is a user input
19:28:10 <sslypushenko> User will input this info. Visibility of product does not depend ob product type. So product type should not affect UI
19:28:19 <alexandrelevine> Please don't get me wrong. I'll gladly accept N types of clouds. Let's ask our stakeholder (DefCore) about related requirements. If they formulate them, like "Vendor has to specify what kind of cloud he registers - public or private" - we'll comply.
19:29:00 <catherineD|2> alexandrelevine: I will be gladly to take that to DefCore
19:29:04 <alexandrelevine> sslypushenko: How user enters this info? Where? He/she uses UI to register a Cloud. There should be a checkbox, dropdown or something for him/her to choose. That's how.
19:29:28 <alexandrelevine> catherineD: Absolutely, please do, if you think it's important and we want to have it right now.
19:30:13 <sslypushenko> alexandrelevine:  I think it can be kind of select or of product type and checkbox for private/public
19:30:39 <catherineD|2> #action Catherine will confirm with DefCore whether a vendor has to specifu what hind of product he registers -- public, private, distros,
19:31:11 <alexandrelevine> sslypushenko: I hope you don't confuse private/public cloud with our private(hidden)/public(visible to all) clouds in RefStack.
19:31:25 <catherineD|2> specifu --> specify
19:31:29 <alexandrelevine> sslypushenko: I was just saying that it should be reflected in UI.
19:31:49 <sslypushenko> alexandrelevine:  sure
19:32:00 <catherineD|2> let's move on ... we will revisit this after we check with DefCore
19:32:28 <andrey-mp> why we need checkbox public/private ? i thought it will be a switch in a cloud page
19:32:36 <sslypushenko> I just don't get why we should care about number of product types. It should be just kind of label
19:32:54 <catherineD|2> sslypushenko: +1
19:33:00 <catherineD|2> #topic Vendor REST API
19:33:01 <alexandrelevine> andrey-mp: We're talking here about different private/public - private cloud or public cloud, not visibility in RefStack.
19:33:20 <catherineD|2> #link     Vendor registation REST API spec: https://review.openstack.org/#/c/274837/
19:33:29 <sslypushenko> andrey-mp:  yeap, you are right
19:33:37 <catherineD|2> #link     Vendor registration REST API implementation:  https://review.openstack.org/#/c/272188/
19:33:53 <alexandrelevine> sslypushenko: It's one of the key properties in one of our key objects. If it's just a label - we'll put it into metadata and leave the type to differ "cloud", "software".
19:34:07 <andrey-mp> about spec. 1. why we need deletion of vendor?
19:34:58 <catherineD|2> andrey-mp: it is just incase we need to ... but this should be a low priority ...
19:35:06 <andrey-mp> ok
19:35:19 <catherineD|2> now the URL
19:35:45 <catherineD|2> since this is vendor registration ... it makes sense to be /v1/vendors
19:36:09 <catherineD|2> do we need /v1/foundations down the road ...?
19:36:12 <andrey-mp> 2. i don't understand 'Only foundation admins can create an official vendor.'. As I understood from scenario document - vendors will be created by users and foundation will approve them
19:36:24 <catherineD|2> or would /v1/organizations be a better URL
19:37:23 <alexandrelevine> catherineD: By the way, good point. I forgot several "removal" use-cases. Right now I have only one for Cloud removal. I guess I should add for Software and for Vendor, what do you think?
19:37:26 <catherineD|2> only foundation can create official vendor
19:37:59 <catherineD|2> alexandrelevine: I think so especialy for product ...
19:38:08 <sslypushenko> catherineD|2:  'approve' sounds better here
19:38:12 <rockyg> alexandrelevine, +1.  Definitely vendors can go away.
19:38:25 <andrey-mp> catherineD|2: who will be owner in this case?
19:38:40 <catherineD|2> we can talk about removal being soft or hard delete from the db ... but I think we need removal API but low priority
19:38:43 <rockyg> Removal of vendor would be owned by foundation
19:39:06 <andrey-mp> rockyg: good point
19:39:20 <catherineD|2> official vendors creation and removal both own by founation
19:39:21 <alexandrelevine> catherineD: I think, "create" and "approve" it's the same - Foundation has the final say in the matter.
19:39:26 <rockyg> removal of product, vendor or foundation.  Same with cloud
19:39:56 <catherineD|2> rockyg: I think removal of product should only own by vendor
19:40:11 <andrey-mp> rockyg: i think that product and cloud (maybe only private) can be removed by ordinary user
19:40:14 <alexandrelevine> catherineD: Right now, you can see in the site that each User can request his created Vendor to be approved by Foundation. When Foundation admin approves - it'll become official.
19:40:22 <rockyg> If vendor goes away, and foundation removes, will all the products go away with vendor removal?
19:41:02 <andrey-mp> rockyg: yes. all products should removed with dependent vendor
19:41:10 <alexandrelevine> andrey-mp: Definitely, private user clouds, software and non-approved vendors can be deleted by the User.
19:41:33 <andrey-mp> alexandelevine: i mean the same point
19:41:34 <rockyg> Then ok.  Foundation doesn't need to be able to remove sw or cloud
19:41:58 <sslypushenko> rockyg:  +1
19:41:59 <catherineD|2> we talk about this ealier about the complication of register a vendor .. need confirmation of website,email etc
19:42:17 <rockyg> Is there a way to transfer sw or cloud?  like company or product line gets sold?  Low priority
19:42:34 <sslypushenko> Foundation should have only approval role and that is all
19:42:42 <catherineD|2> DefCore decides that official_vendor will be from a list that openstack alreaidy has
19:42:49 <andrey-mp> rockyg: it can be implemented via user management and vendor editing
19:42:50 <alexandrelevine> catherineD: Yes, and all of it will be entered by User during registration, but not by email - right in our RefStack site. Then Foundation admin checks everything and if all right approves.
19:43:41 <catherineD|2> alexandrelevine: approving a vendor is not just register on RefStack ... there is legal procdedure that foundation need to do ...
19:43:46 <alexandrelevine> catherineD: This'll be in the beginning. And in any case there should be a user-friendly mechanism for entering this data, no?
19:44:13 <alexandrelevine> catherineD: Of course. Clicking "approve" button is just the last step. What's wrong with that?
19:44:22 <catherineD|2> alexandrelevine: in the future maybe ... if RefStack taking a bigger task of on boarding vendor :-)
19:44:48 <alexandrelevine> catherineD: Does Foundation have new Vendors coming all the time?
19:45:22 <catherineD|2> alexandrelevine: IMO, any implementation of approval process would not be just clicking a button .. it would involve a process and workflow .
19:45:49 <catherineD|2> that is why at this phase only foundation memebers can create official vendors ..
19:45:51 <alexandrelevine> catherineD: Of course. Ok. Let's say, I'm a representative of EMC and I want EMC to register as a Vendor. What do I do?
19:46:18 <alexandrelevine> catherineD: Of course. The will do this. I'm just suggesting convenient infrastructure for this.
19:46:20 <catherineD|2> alexandrelevine: EMC will need to go thru what ever process OpenStack require a vendor to go thru
19:47:10 <alexandrelevine> catherineD: Perfect. I suggest this process to be connected with the RefStack. I go to the RefStack panel. Enter all the information and click "apply". The information is delivered to Foundation and it handles it exactly the way it does now.
19:47:13 <catherineD|2> alexandrelevine: I support we think ahead ... I oppose to allow user to create official vendor at this phase
19:47:33 <alexandrelevine> catherineD: Who said User can CREATE official vendor?
19:47:36 <rockyg> catherineD|2,  right.  So, there might be more automation added in front of "approve" button when the foundation defines what the need.  But right now, "approve" only happens after the manual process they go through.
19:47:42 <alexandrelevine> catherineD: There is no such possibility.
19:48:03 <alexandrelevine> rockyg: Exactly.
19:48:06 <pvaneck> I think one of my main worries with foundation-only vendor creation is the foundation member having trouble adding the first user for the vendor's group.
19:48:19 <catherineD|2> alexandrelevine: how do you send infor to Foundation?
19:48:30 <pvaneck> Foundation has to procure and email to add, and that user has to have logged in to refstack once in order to have a record in refstack. This could lead to slow-down in the process.
19:48:32 <alexandrelevine> catherineD: You can see it in the existing prototype.
19:49:13 <alexandrelevine> catherineD: You can create Vendor, fill in all the fields and click "Register". That's it. Foundation admin goes to his page in the same RefStack Panel and see the new Pending Vendor.
19:49:18 <catherineD|2> alexandrelevine: I can't see what it is? you send an emai;?
19:49:44 <catherineD|2> alexandrelevine: how do foundation member know how to go to this page?
19:50:09 <alexandrelevine> catherineD: Have you signed in?
19:50:11 <catherineD|2> we do not have all of this notification infra implemeneted to suport this
19:50:16 <catherineD|2> yea
19:50:20 <alexandrelevine> catherineD: Check "my vendors" at the bottom.
19:50:39 <alexandrelevine> catherineD: You'll see "pending" vendors.
19:50:51 <catherineD|2> yes
19:51:04 <alexandrelevine> And the button "approve registration"
19:51:19 <alexandrelevine> There should be an action "decline registration", of course, as well.
19:51:42 <alexandrelevine> This section "Pending vendors" will be available to Foundation Admin only.
19:51:52 <andrey-mp> alexandrelevine: what should be in decline case?
19:51:57 <catherineD|2> yes   my concern is how do you notify the person to take action ... and how do you control if that person does not take action?
19:52:21 <alexandrelevine> andrey-mp: Information to user in "My Vendors" and status "declined"
19:52:22 <catherineD|2> I am talking about an entire notification workflow ..
19:53:07 <alexandrelevine> catherineD: That's a different story. We can trigger it by manual email or by automatic email or by periodic checking - in any case it's no worse than anything without it.
19:53:17 <rockyg> catherineD|2, good point.  An email to a list would be good on vendor completing their end of the process.  But right now, the foundation can easily lose stuff.  And does;-)
19:53:33 <alexandrelevine> catherineD: How does the entire notification workflow work now? Personal email?
19:54:05 <catherineD|2> rockyg: exactly ... that is why in this phase .. foundation has the sole responsibility to create/remove vendor
19:54:23 <catherineD|2> until we have all this infrastructure in place ...
19:54:24 <alexandrelevine> catherineD: It still does. Come on, what's the difference?
19:54:44 <rockyg> so, right now, personal email or email alias.  But it's all a manual process.  So, no reminders if the email gets buried.
19:54:52 <alexandrelevine> catherineD: Ok. How do you suggest they deliver this info into our DB now.
19:55:05 <rockyg> So, anything we automate will be better than what they currently have
19:55:15 <alexandrelevine> rockyg: Exactly.
19:55:26 <catherineD|2> alexandrelevine: at this point  official_vendor can only be created by foundation ...
19:55:31 <rockyg> Maybe we should have a "ping foundation" button for the vendors ?)
19:55:35 <alexandrelevine> catherinD: By what means?
19:55:51 <alexandrelevine> rockyg: "Register" is such a ping button.
19:56:05 <alexandrelevine> rockyg: Do you have "ping" button in OpenStack review?
19:56:27 <rockyg> alexandrelevine, by manually adding them to the website.  Probably through content management system.  Forget the name of that thing.
19:56:36 <alexandrelevine> rockyg: I can tell you how it works. We have to use email and IRC and skype to ping core teams to check our reviews, usually, right?
19:57:00 <rockyg> alexandrelevine, or you can change the commit message.  But lose all the votes
19:57:18 <catherineD|2> foundation members (like Chris) will create vendor from the RefStack UI , in addiiton RefStack will provide tools to import a vendor list in Json file ..pvaneck: is working on the import tools
19:57:38 <rockyg> Just because the devs don't make it convenient, doesn't mean we can't for the vendors and foundation
19:57:45 <alexandrelevine> catherineD: What RefStack UI should look like to create a vendor?
19:58:11 <sslypushenko> catherineD|2:  It looks overcomplication
19:58:12 <catherineD|2> all the input field as needed ...
19:58:13 <alexandrelevine> catherineD: Right now, it's exactly the Vendor creation. Just it's done by a proper person.
19:58:17 <rockyg> "Push the button, Max!"  Reference to movie Around the world in 80 Days
19:58:30 <catherineD|2> sslypushenko: what is over complication?
19:58:47 <sslypushenko> exporting vendors data
19:59:02 <catherineD|2> importing data
19:59:04 <catherineD|2> ?
19:59:06 <sslypushenko> It looks like we need more time for discussion
19:59:28 <sslypushenko> export/import workflow is overcomplication
19:59:31 <alexandrelevine> catherineD: Ok, I don't see any advantage of manual work with lists, import and such in comparison with nice input page in the panel where user fills in all the required info and Foundation admin only has to process it and approve.
19:59:44 <catherineD|2> #link please check this link https://etherpad.openstack.org/p/mitaka-refstack-ation-items
19:59:45 <alexandrelevine> sslypushenko: +1
20:00:12 * redrobot pokes head in
20:00:24 <catherineD|2> it was decided by DefCore on 20151029 that vendor will be import
20:00:26 <catherineD|2> sorry
20:00:35 <catherineD|2> qew need to end meeting
20:00:42 <catherineD|2> #endmeeting