Open Stack

Hi Mark,

Thanks a lot for the prompt response.
Your thoughts are very valid and reasonable, however:

1) I believe we'll expect Vendors registering with RefStack not being in 
MarketPlace. Especially the external testing or small components owners 
like EC2 API - definitely not in MarketPlace. So we can't use 
MarketPlace link during registration. We need to collect some info. 
Questions are still the same:
A) What is enough for DefCore to approve and store new Vendor's information?
B) What do we want to show about Vendor in details?

2) I understand according to your meeting minutes we still have to 
create User Management UI with list of users for Foundation admins at 
least. With some simple search obviously. Let's keep that in mind that 
such an instrument we'll have anyways, so any other UI for other ways of 
choosing users is extra development.

A) To be completely honest, I think that using openstackid as means for 
pointing to a potential admin is not a good idea.
Why I say this - several reasons:
- openstackid is a very confused entity and I doubt majority of 
vendors-to-be know theirs. I should be really ashamed of this but 
personally dealing with openstack for more than a couple of years now 
I've never ever used it explicitly before, so I tried to find my own id 
after your response. For this I went to openstackid.org and tried to log 
in. I was asked to use my openstackid to log in. That was nice but that 
was what I came for. I somehow recalled that probably I should use my 
email in login field. Problem is I tried with my smartphone and the 
email I entered automatically brought trailing space which led me to 
getting "username is of invalid format". Along with suggestion to use my 
openstackid to log in it made me quite confused. Eventually after a 
dozen of attempts and resetting my password I've figured everything out 
but it took me some time. So at least the same thing should be used here 
- email. Not the openstackid, to be in line and at least a little friendly.
- there can be a mistake in manually entering data, so we'll have to 
still show all information about User and ask about confirmation.
- considering the previous one, having access to the Vendor's user 
management interface (i.e. being an official Vendor) I'll have means to 
find user's details having his/her openstackid. And openstackid is not a 
private info - it can be easily acquired. So we're not achieving 
anything by restricting Vendors from access to lists of users.

B) It's a very good idea to display link to openstackid page, thus 
allowing user to decide what to show. However I don't see how we can 
show it user-friendly, especially in lists of other objects. Showing raw 
openstackid in a column will look awful and long. Besides that it 
contains user name in clear text. If we don't show it and show only some 
anonymous link to openstackid page, user will go there and still see the 
name in URL. Wouldn't it make sense to just show user's login or name 
instead in our info if it seems not to be such a great secret after all?
In regard to launchpad similarity - emails and names of responsible 
people are shown so that other users can contact them if required. 
Wouldn't we want to have the same for our Vendors? That's why it must be 
good to show this at least to regular users, not Guests.
And in regard to showing lists of users to Guests or regular Users - as 
I said, the reason is better be asked of the Foundation - why does it 
allow lists of attendees during the summits to be seen to everybody? 
Probably, bonding the community or not considering it secret enough 
information to hide. I feel that RefStack site is as public venue as 
OpenStack summits are. And I'd expect the same policies to apply.

Best regards,
   Alex Levine


On 2/19/16 1:59 AM, Mark Voelker wrote:
> 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