Open Stack

Hi,

Please see in-line comments!

Catherine Diep
RefStack PTL
IBM Silicon Valley Laboratory, San Jose, California 95141
cdiep at us.ibm.com, Tel: (408) 463-4352  T/L: 543-4352
----- Forwarded by Catherine Cuong Diep/San Jose/IBM on 02/19/2016 09:57 AM
-----

From:	Alexandre Levine <alexandrelevine at gmail.com>
To:	Mark Voelker <mvoelker at vmware.com>, Chris Hoge
            <chris at openstack.org>
Cc:	"defcore-committee at lists.openstack.org"
            <defcore-committee at lists.openstack.org>
Date:	02/19/2016 12:40 AM
Subject:	Re: [OpenStack-DefCore] RefStack development related questions


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.

<catherine>  Supporting "User Management UI with list of users" for
Foundation
admin is in plan for RefStack.  But, it MAY not be available in the Mitaka
cycle.
Implementation details will be discussed in RefStack team
meetings.</catherine>


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.

<catherine> From RefStack point of view, either OpenID or email can be used
as the user identification.</catherine>

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


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/defcore-committee/attachments/20160219/aabae1a6/attachment-0001.html>