[OpenStack-DefCore] RefStack development related questions

Mark Voelker mvoelker at vmware.com
Thu Feb 18 22:59:54 UTC 2016


Hi Alex,

Thanks for writing this up!  Some thoughts inline...

> On Feb 18, 2016, at 9:59 AM, Alexandre Levine <alexandrelevine at gmail.com> wrote:
> 
> Hi,
> 
> After several recent DevCore meetings some of the questions regarding development decisions for RefStack were answered however some still remain. And during yesterday's meeting some more had arisen.
> Catherine suggested to write to this list in order to speed up the process and not wait for the next DefCore meeting so here it is:
> 
> 1. Vendors registration information
> 
> There was a decision made that Vendor registration will be implemented in RefStack with subsequent approval by Foundation admins in corresponding admin interface in RefStack.
> During this registration new Vendor-to-be will have to enter some information related to his/her Organization. In the OpenStack Marketplace (example: https://www.openstack.org/marketplace/hosted-private-clouds/unitedstack/uos-managed-private-cloud) we can see that each Vendor besides the name has at least "about" and "commitment" filled in. I think some other hidden fields might be of interest for DefCore as well.
> 
> Hence a couple of questions:
> A) Would it be possible that RefStack will be used as a source or one of the sources for new Vendors who want to register?
> B) What information about Vendor should RefStack show on Vendor details page?
> 
> Options:
> A) The first question (if the answer is potentially yes) means that we'll have to collect all of the required information for DefCore in regard to new registering Vendor. We'll need to know what is it then.

I think in an ideal world it would be nice to not have information duplicated between the MarketPlace and RefStack (so conceivably the answer is yes).  But given that today information about vendors is housed in the MarketPlace, might we have the opposite situation where a vendor registers with the Marketplace and RefStack uses that data, rather than the reverse?  I’m not sure how realistic that is today—Chris Hoge might know better or at least be able to point to the right folks on the Marketplace team, so I’ll leave him to comment.

> If the answer is no then see the second question.
> 
> B) The second one - we'll have to show something besides the name and I think information might as well correspond to what's in Marketplace because we speak about the same Vendors here. What is it exactly (which fields) and where to get them - ask user during registration I guess?

Here again, it feels like we want to not duplicate information when possible…if we can get the MarketPlace data, great.  If not, maybe just a link to the vendor’s MarketPlace entry would suffice.

> 
> 2. Visibility of users registered in RefStack
> 
> We understand that the idea is to limit exposure of information.
> However, there is a couple of use-cases which we'll have to implement:
> 
> Questions:
> A) Vendor admin wants to add another admin for the Vendor. How do we allow him/her to find who to add?
> B) Various data we show (Vendors, Clouds, Software, test resuts... etc) have owners and admins, people responsible for it. The question is how do we show it if we do?
> 
> Options:
> A) We've got users in various roles in this regard: Guest, regular User, officially registered Vendor admin, Foundation admin.
> Usual way of choosing something you need to select is to show list with ability to search through it. That's what I suggest here, obviously.

At the risk of turning this into a UX discussion: I wonder if searching and pick lists are actually necessary?  E.g. if I go off the assumptions (please shout if you think these aren’t valid) that:

1.)  A vendor admin and another employee of the company who wants to become a vendor admin presumably have an easy way to exchange information outside of RefStack (phone, email, face-to-face in some cases, etc) and likely regularly do so anyway as part of normal company operations.  They could easily exchange, for example, OpenStackID’s. 

2.)  Entering one or more OpenStackID’s into a text field wouldn’t be prohibitively difficult.  I could see this being a bit of a pain if we expected a single vendor to have hundreds of vendor admins or if new vendor admins needed to be added en masse very frequently, but I think that’s unlikely to be the case in reality.

If these are true, then I wonder if the simplest thing to do is simply give the vendor admin a text field into which he/she can type one or more OpenStackID’s rather than needing to search/find other users.  Thinking about how I’d use this feature with my vendor hat on, this seems like it would be fast and easy to me and it’s something I do with other tools anyway.  By way of example: if I want to add Bill to my organization on GitHub I phone/email/IM him to get his GitHub ID and type it into a text box in the GitHub UI.  I’m no UI designer though, so feel free to take that as just another opinion. =)


> Who to show it to?
> Possibility of adding other users as admins to Vendors is open for official Vendors admins only (for now). So we can limit access to lists of all users and search to official Vendors admins and to Foundation admins.
> 
> However, there might be another reason to allow showing registered users even to Guests. The same one which caused showing OpenStack summit attendees to anyone in the OpenStack site. At least the login name is displayed, however user can allow more information to be shown.
> I'm not sure what reason was there to disclose this information but I think it can be as good for RefStack. In which case lists of users should be available to even Guests. Or we can limit it to regular Users.

We discussed disclosure at the DefCore meeting this week and the general agreement was to err on the side of keeping information private unless there’s a good reason not to, as you alluded to earlier.  So with that in mind: is there a use case for anonymous Guests to be able to see this information?

> 
> B) Information about the team managing particular project in launchpad, or about people responsible for something in OpenStack is usually open and available. I believe we might want to display something of the kind for our data, especially official stuff - Vendors, Clouds, Software. What should it be? What can be shown? Wouldn't it make not listing users to anyone useless if we show it?

I’d probably invoke the mantra of “what information is actually useful” again here as a general rule, and then tackle individual use cases.  For example: if I’m looking at a test result, it’s useful for me to see what vendor and product it belongs to.  If I’m looking at information that involves and individual, most systems (including OpenStackID and Launchpad) allow users to restrict what information is shown about them, so I would think linking to OpenStackID pages (e.g. https://openstackid.org/mark.voelker for example, or pulling data from OpenStackID and displaying it) would be a valid way of presenting that which allows users to a degree of control over information disclosure.  Make sense?

> Hope the above is clear enough for discussion and getting some answers as soon as possible.
> 
> Best regards,
>  Alex Levine

Thanks again Alex!

At Your Service,

Mark T. Voelker


> 
> 
> 
> 
> 
> _______________________________________________
> Defcore-committee mailing list
> Defcore-committee at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee



More information about the Defcore-committee mailing list