19:00:27 <catherineD> #startmeeting refstack
19:00:27 <openstack> Meeting started Mon Mar 14 19:00:27 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:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:31 <openstack> The meeting name has been set to 'refstack'
19:01:17 <pvaneck> o/
19:05:26 <catherineD> pvaneck: guess only you and I today
19:05:43 <catherineD> shoudl we wait for a bit?
19:05:58 <pvaneck> perhaps
19:06:06 <pvaneck> do you have an agenda link?
19:06:25 <catherineD> #link meeting agenda and notes, please feel free to add items https://etherpad.openstack.org/p/refstack-meeting-16-03-14
19:07:20 <alexandrelevine> o/
19:07:45 <catherineD> alexandrelevine: hi ... do you ge the meeting agenda link?
19:07:54 <alexandrelevine> nope
19:08:13 <pvaneck> for item #1, still waiting on the final +2. Will bother people about it this week
19:08:18 <catherineD> https://etherpad.openstack.org/p/refstack-meeting-16-03-14
19:08:20 <alexandrelevine> thank you
19:08:30 <catherineD> let's start
19:08:49 <catherineD> #topic Make puppet pull releases from Pypi
19:09:14 <catherineD> #link Make puppet pull releases from Pypi    https://review.openstack.org/#/c/281737/
19:09:46 <catherineD> pvaneck: I guess we need to add our topic to the infra IRC meeting to raise awareness?
19:10:35 <pvaneck> will just ask for reviews from infra first
19:10:48 <catherineD> ok
19:10:55 <catherineD> moving on
19:11:13 <catherineD> #topic Vendor user management implementation
19:11:34 <catherineD> #link Vendor user management implementation   https://review.openstack.org/#/c/285714/
19:12:46 <catherineD> with the DefCore feedback so far ... are we ready to move on with this patch?
19:13:26 <alexandrelevine> I don't have any objections
19:14:12 <catherineD> I believe we need Andrey to submit a new patch  ...
19:14:25 <sslypushenko> Hi, all! o/
19:14:33 <catherineD> sslypushenko: Hi
19:14:49 <catherineD> agenda https://etherpad.openstack.org/p/refstack-meeting-16-03-14
19:15:10 <catherineD> we are on topic 2
19:15:39 <sslypushenko> Thx!
19:16:03 <alexandrelevine> Andrey is not here. Yes he'll submit  a new one
19:16:13 <catherineD> alexandrelevine: thx !!
19:16:26 <catherineD> #topic Vendor registration
19:16:46 <catherineD> #link Spec: https://review.openstack.org/#/c/274837/
19:17:37 <catherineD> I believe Andrey has the code already ...
19:18:18 <catherineD> we will just wait for his patch
19:18:45 <catherineD> any other discussion before we move to the next topic?
19:19:14 <alexandrelevine> I'm fine with the spec.
19:19:26 <catherineD> moving on
19:19:28 <alexandrelevine> I'm not sure if Andrey has all of the code but most probably he does.
19:19:32 <catherineD> #topic Product registration
19:19:57 <catherineD> This is a new spec and I believe we will have a lot of discussion ..
19:20:13 <catherineD> #link     Spec:  https://review.openstack.org/#/q/openstack/refstack,n,z
19:21:22 <catherineD> please see the comment about id vs product_id on https://review.openstack.org/#/c/292526/1/specs/mitaka/approved/product-registration-api.rst
19:22:56 <catherineD> for the REST API to get detail information of a product ... by convention it would be v1/products/{product_id}  or we can use v1/products/{id}
19:23:15 <alexandrelevine> I just replied
19:23:33 <alexandrelevine> Yes, v1/products/{id} is good
19:23:53 <catherineD> :-)
19:24:45 <sslypushenko> {id} is good enough
19:24:56 <catherineD> alexandrelevine: I typed usibg { id} that before seeing your reply  :-)
19:25:05 <alexandrelevine> I know :)
19:25:11 <catherineD> ok ...we can do that ..
19:25:39 <catherineD> will the API user be confused of which id is that?
19:25:49 <alexandrelevine> No, I don't think so
19:25:57 <catherineD> or by convension it should be the id of the products
19:26:03 <catherineD> ok I am good with it
19:26:16 <alexandrelevine> And in any case it won't be fatal for the API user
19:27:08 <catherineD> that is all the topics I have in mind for today ...
19:27:26 <catherineD> #topic Open discussuion
19:28:05 <alexandrelevine> I suggest discussing the troubling matter - adding admins to vendors
19:28:19 <alexandrelevine> I'd like to understand how the UI will be organized.
19:28:19 <catherineD> ok
19:28:42 <catherineD> yup let discuss that ...
19:28:58 <alexandrelevine> And I'm against asking users to enter something like https://openstackid.org/alexandre.levine.1
19:29:06 <alexandrelevine> I explained reasons in the mailing list
19:29:32 <alexandrelevine> (enter it in an input field of a text box I mean)
19:30:09 <alexandrelevine> As I stated in the doc I see two friendly ways: 1. Choosing from list. 2. Entering email with subsequent showing of user's details and confirmation
19:30:16 <catherineD> alexandrelevine:  I am thinking of on the UI ... we will have text box to enter emal
19:30:43 <alexandrelevine> Ok. When email is entered we have to verify that there was no mistake. What do we do for this?
19:31:04 <alexandrelevine> I'd expect showing user's details - name, login and openstackid at least.
19:31:30 <alexandrelevine> openstackid clickable with possibility to go to the page of openstackid.
19:31:57 <catherineD> once the email is enter ... internal to refstack (without showing to the requester) refstack will get the fullname, openid from the email
19:32:23 <catherineD> if there is more than one record returned then return error
19:32:41 <alexandrelevine> We can't avoid confirmation. Otherwise I'll skip one char in email and I'll add a different person.
19:32:47 <alexandrelevine> We definitely wouldn't want it.
19:32:49 <sslypushenko> alexandrelevine:  your suggestion No. 2 sounds good
19:33:07 <alexandrelevine> What is suggestion N2?
19:33:22 <sslypushenko> 2. Entering email with subsequent
19:33:36 <alexandrelevine> What info do we show for confirmation?
19:33:57 <sslypushenko> name and email
19:34:08 <sslypushenko> as usuall
19:34:25 <alexandrelevine> And link to openstackid page, I believe?
19:34:31 <sslypushenko> sure
19:34:47 <sslypushenko> clickable link on openstackid profile
19:34:48 <catherineD> that is return full name, email, openstack id
19:34:50 <alexandrelevine> Ok, cool. How do we achieve getting this info for regular user? By which API call?
19:35:32 <alexandrelevine> By saying "for regular user" I mean't both: current admin and the user he's trying to add.
19:36:00 <alexandrelevine> "meant"
19:36:40 <sslypushenko> we can introduce some thing like lookup call or add filtering in to list user call
19:36:50 <catherineD> the only API we have speced so far is URI: v1/vendors/{vendor_id}/users/{encoded_openid}  in https://github.com/openstack/refstack/blob/master/specs/mitaka/approved/vendor-user-management-api.rst
19:37:13 <alexandrelevine> We'll definitely have filtering, however, it'll be filtering by email, right?
19:37:21 <alexandrelevine> returning this particular info
19:38:47 * rockyg sneaks into the back of the room
19:38:55 <catherineD> Hi rockyg:
19:38:59 <sslypushenko> we can go call like GET on v1/vendors/{vendor_id}/users with filter by email
19:39:22 <alexandrelevine> catherineD: Do you agree with sslypushenko's proposal?
19:39:50 <alexandrelevine> sslypushenko: Not {vendor_id} though. v1/users/ with filter by email
19:39:59 <alexandrelevine> We haven't added nobody yet
19:40:06 <catherineD> sslypushenko: the v1/vendors/{vendor_id}/users only get the users that have already added to the vendor
19:40:10 <sslypushenko> alexandrelevine:  yeap
19:40:26 <catherineD> we are discussing about adding vendor...
19:40:34 <catherineD> adding user to vendor
19:40:51 <catherineD> can I present my thinking ... I will mark when I am done
19:40:55 <alexandrelevine> catherineD: So you agree with v1/users/?email= ?
19:41:01 <alexandrelevine> perfect, please do.
19:42:12 <catherineD> If we do not like openid .... we can change to something like POST v1/vendors/{vendors_id}/users/{user_email}
19:43:04 <catherineD> once that REST API landed at the API server ... internally at refstack .. refstack will use the email to look up for user record ...
19:43:19 <catherineD> if more than one record return ... fail the API...
19:43:35 <catherineD> if only one record in RefStack .... add the user to  vendor
19:43:37 <catherineD> done
19:44:01 <alexandrelevine> catherineD: No won't work. As I said before, I'll enter valid email with one missing char and you'll add wrong admin
19:44:45 <alexandrelevine> we need show details and ask for confirmation unless user was selected from list with details.
19:44:52 <sslypushenko> alexandrelevine:  +1
19:45:56 <catherineD> alexandrelevine: I see your point ...
19:46:04 <pvaneck> catherineD: are you against exposing these user details?
19:46:09 <sslypushenko> catherineD:  alexandrelevine  just proposed the workflow which is using by lots od online services
19:47:01 <catherineD> pvaneck: yea  for the reason I stated in the email ...
19:47:20 <alexandrelevine> catherineD: So what do you suggest we do?
19:47:33 <sslypushenko> for example review.openstack.org works the same
19:48:10 <catherineD> however, if the input is email ... that means that you already have private info from the user .... I guess I am OK with /v1/users/{email}  but not v1/users
19:48:11 <sslypushenko> we can not hide user's openid and we should not
19:48:43 <sslypushenko> we can not use /v1/users/{email}
19:48:56 <catherineD> sslypushenko: as my response from the email .. refstack does not get info from review.openstack.org
19:48:58 <sslypushenko> because of REST architecture
19:49:07 <alexandrelevine> catherineD: So do I understand that you're or with /v1/users/?filter=email?
19:49:15 <alexandrelevine> "ok with"
19:49:27 <catherineD> sslypushenko: I do not mean it that fashion just mean that email as input
19:50:31 <sslypushenko> so, we don't have a point of disagreement here?
19:50:41 <catherineD> alexandrelevine: yes I am OK to provide user info in refstack which is currently (fullname (public), email (private), openid (not sure what this is).... if the input is email ... I am ok with it
19:50:43 <alexandrelevine> catherineD: Great. Now, in terms of security it doesn't help much if we don't return list of all users with those three fields (email, name, openstackid) because I'll be able to find this info by checking various emails
19:51:44 <alexandrelevine> catherineD: What I'm saying is that it's the same level of security. So we can avoid complicating things for us and just provide regular users with access to listing other users and the output will contain this 3 fields.
19:51:58 <sslypushenko> catherineD:  I'm supporting alexandrelevine  in his opinion here
19:52:27 <sslypushenko> It has no sense to try to keep security here
19:53:12 <catherineD> sslypushenko: alexandrelevine: I am not comforatable of voluntee the data that we got (by trust ) fron openstackid.org
19:53:38 <sslypushenko> we just manipulating with openid
19:53:41 <alexandrelevine> catherineD: We're speaking of security. We agreed that we'll expose this info anyways.
19:53:44 <sslypushenko> and nothing more
19:54:33 <alexandrelevine> catherineD: I don't understand what we gain by prohibiting list call in API without filtering by email. Definitely not security gain
19:54:38 <sslypushenko> it the way how things work. openid is a shared key and your password is a secret
19:54:43 <catherineD> if there is any security exposure that means that our proposal of /v1/users/{email} is not good enough
19:55:07 <alexandrelevine> catherineD: It is good enough.
19:55:14 <sslypushenko> +1
19:55:29 <sslypushenko> we are not touching user's data
19:55:30 <alexandrelevine> catherineD: But it makes senseless prohibiting list call without filtering.
19:55:45 <alexandrelevine> catherineD: We'll allow only those 3 fields to be listed.
19:55:59 <rockyg> catherineD, we can get someone from the security project to review it.  But for now, let's just go with it and ask for a review on the first cycle of the patch.
19:56:05 <alexandrelevine> catherineD: And official vendors and foundation admins will get more according to their access rights.
19:56:12 <catherineD> of the 3 field only email is listed as private info
19:56:23 <sslypushenko> rockyg:  Excellent idea!
19:56:44 <catherineD> rockyg: do you have a name?
19:56:58 <alexandrelevine> catherineD: So bottomline. My suggestion is to allow listing users to all regular users.
19:57:22 <sslypushenko> alexandrelevine:  I agreed  with you
19:57:24 <rockyg> there are a few names, but we can ask fungi to either do it or provide a name.  He's on the team.
19:58:16 <catherineD> alexandrelevine: sslypushenko: I am OK if security and DefCore confirm that that is what they want
19:58:45 <alexandrelevine> catherineD: Let's let them confirm.
19:58:46 <catherineD> once information is exposed ... you can not get it back
19:58:49 <sslypushenko> catherineD:  Maybe we can ask hogepodge  for review?
19:58:58 <hogepodge> o/
19:58:59 <catherineD> sslypushenko: we send the email
19:59:24 <fungi> i'm not really a security reviewer, i'm a vulnerability manager
19:59:33 <alexandrelevine> Guys, if it was such a secret why all of this lists and info is completely exposed during summits publicly?
20:00:02 <catherineD> alexandrelevine: the issues is we get this list from somewhere
20:00:03 * elmiko see ossp mention
20:00:14 <fungi> but the security project does have people who tend to do security-focused audits and design/code reviewing
20:00:15 <alexandrelevine> catherineD: What does it mean?
20:00:20 <catherineD> and we should respect the policy of the source
20:00:34 <alexandrelevine> catherineD: Those are exactly the same people which participate in summits
20:00:45 <alexandrelevine> catherineD: Coming with the same reasons
20:01:11 <elmiko> pretty ossp would be happy to help with any code-review/audit stuff =)
20:01:16 * redrobot pokes head in
20:01:18 <elmiko> *pretty sure...
20:02:12 <catherineD> we need to end this meeting
20:02:21 <catherineD> #endmeeting