19:00:27 <catherineD> #startmeeting refstack
19:00:27 <openstack> Meeting started Mon Feb 22 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:02:16 <pvaneck> o/
19:04:06 <andrey-mp> o/
19:04:17 <rockyg> o/
19:04:36 <catherineD> andrey-mp: rockyg: hello
19:04:52 <andrey-mp> hi
19:04:53 <catherineD> #link meeting agenda and notes, please feel free to add items https://etherpad.openstack.org/p/refstack-meeting-16-02-22
19:04:56 <rockyg> Hi
19:06:31 <catherineD> #topic Infra team suggests additions to our release model
19:06:48 <catherineD> andrey-mp: pvaneck: thank you for working on the topic
19:06:54 <andrey-mp> ^)
19:06:56 <andrey-mp> :)
19:07:43 <catherineD> #link Add pypi publish jobs to RefStack  https://review.openstack.org/#/c/281720/
19:07:44 <pvaneck> yea,  i believe the puppet-refstack change should be good to go
19:07:48 <andrey-mp> I check that current model works - last changes doesn't go to production
19:08:06 <pvaneck> though maybe we should wait for a new version release before having it merged
19:08:18 <catherineD> #link     Make puppet pull releases from Pypi  https://review.openstack.org/#/c/281737/
19:08:44 <andrey-mp> pvaneck: we can add tag 1.0.1 for checking
19:09:12 <catherineD> andrey-mp: yup that is good ...  however, I do think that we should target for small increments release so it is easier to manage bugs
19:09:35 <pvaneck> sure, now that openstackci handles releasing to pypi now
19:09:45 <catherineD> andrey-mp: ++ for 1.0.1 for checking once  https://review.openstack.org/#/c/281737/  is merged?
19:10:02 <pvaneck> make tag first
19:10:06 <andrey-mp> catherineD: I agree
19:10:30 <andrey-mp> yeah, tag is needed first
19:10:34 <catherineD> ok yea I think we have a couple merged since 1.0.0 so we can test
19:11:02 <catherineD> #action Catherine to create tag 1.0.1
19:11:19 <catherineD> so we will use 1.0.1 and not 1.1.0?
19:11:27 <catherineD> first 1 = mitaka
19:12:02 <catherineD> not sure how we want  to differentiate the second and third digits
19:12:17 <andrey-mp> pvaneck: what do you want to do with your review?
19:13:15 <pvaneck> andrey-mp: i think it should be good to go based on my testing. I'll release the -2 wip
19:13:17 <rockyg> third is bugfixes/maintenance
19:13:22 <pvaneck> once the tag is made
19:13:35 <andrey-mp> ok
19:13:37 <catherineD> rockyg: good suggestion
19:13:50 <rockyg> second is compatible feature additions or enhancements
19:14:34 <catherineD> if we use what rockyg: suggest .. the next release will be 1.0.1
19:14:55 <catherineD> rockyg: thanks
19:15:06 <catherineD> moving on ?
19:15:13 <andrey-mp> yes
19:15:20 <catherineD> #topic Vendor user management
19:15:38 <catherineD> we got the guideline from DefCore.
19:16:10 <catherineD> # https://review.openstack.org/#/c/277313/  Vendor user management
19:16:45 <catherineD> please review ...
19:16:49 <andrey-mp> cetherineD: i didn't see email from Alex to DefCore and answers - was it same answers?
19:17:05 <catherineD> oh ... let me forward the email
19:17:25 <rockyg> there were a couple of replies...
19:17:43 <catherineD> catherineD: do you mean response to Alex's latest email?
19:17:51 <catherineD> if so no response yet
19:18:47 <andrey-mp> but I don't have comments for this patch. it doesn't describe finding of users and listing all users.
19:18:56 <andrey-mp> catherineD: yes
19:18:58 <rockyg> dont know if latest. sorry.  was in England last week
19:19:08 <catherineD> rockyg: nice :-)
19:19:27 <andrey-mp> i mean Alex's latest email
19:20:12 <catherineD> andrey-mp: I guess we need to wait for response ...
19:20:26 <catherineD> let's move on then ...
19:20:42 <andrey-mp> catherineD: ok. I thought that you already have answer
19:20:53 <rockyg> not so nice.  ops and product wg midcycles.  lots of work, not much play.
19:21:24 <catherineD> andrey-mp: no we did not have answer to Alex's latest email
19:22:08 <catherineD> andrey-mp: I understanding of the reponse so far is only foundation member should be able to list users in RefStack
19:22:54 <catherineD> To add a user to a vendor, the vendor admin has to get the information (email, openid ) from the user
19:23:36 <andrey-mp> it is not so user-friendly for me
19:23:57 <andrey-mp> like gerrit - it allows to search for users by email or name
19:24:46 <rockyg> yeah. to add user, vendor admin should just need email address from company domain.
19:25:30 <catherineD> rockyg: agree .. email would be much more friendlier
19:26:01 <andrey-mp> but vendor admin should enter full and exact email
19:26:01 <rockyg> send email to added user for verification.  they log onto openid to accept.
19:26:12 <catherineD> andrey-mp: The UI can ask for email ... and then search for OpenID in RefStack db based on email
19:26:38 <andrey-mp> catherineD: rockyg: this is different views :)
19:26:55 <catherineD> rockyg: that would be ideal but notification most likely will not be implemented for Mitaka
19:27:26 <rockyg> andrey-mp, full email entered and let system verify and provide opendid to refstack server from openid server.
19:28:06 <catherineD> I do not mind the REST API to use email of OpenID
19:28:13 <andrey-mp> rockyg: but does OpenID protocol has such ability? I thought that is only authentication service.
19:28:17 <rockyg> Like you said., but with extra check/verification.  If email not in system, no openid email to user and error to admin
19:28:37 <catherineD> right now the spec use OpenID but I do not mind to change if we decide to use email ...
19:28:53 <andrey-mp> rockyg: in this case it's better to return error to vendor admin - user is absent in our DB
19:29:15 <rockyg> if email in system, then mail recipient can say yes, this is correct or you got the wrong email address.
19:29:24 <catherineD> andrey-mp: yea checking will  be against RefStack user DB
19:29:28 <andrey-mp> OpenID is better because it is an unique identifier
19:30:12 <andrey-mp> but email is not unique and it is not and identifier in terms of OpenID protocol
19:30:22 <rockyg> can we tie refstack to openid check the same way gerrit is tied to it?
19:30:34 <rockyg> or rather review.openstack.org
19:31:03 <catherineD> rockyg: we are not right now
19:31:48 <catherineD> the problem to solve is what can we do now to get our goal of vendor registratio nin Mitaka)
19:31:54 <rockyg> review.openstack.org relies on the tuple to guarantee uniqueness.  User must login to openstackid to be recognized.
19:32:11 <rockyg> Ah.  Short time. I get it.
19:32:16 <catherineD> the simplest way is to check against RefStack user db base on input (email or OpenID)
19:32:25 <catherineD> rockyg: yea short time for now
19:32:42 <catherineD> we can improve later
19:33:09 <catherineD> what implementing now should be something that is easy for us to upgrade later
19:33:24 <catherineD> anything else on user management?
19:33:42 <catherineD> #topic Vendor REST APIs
19:34:09 <catherineD> #link Vendor management REST API spec  https://review.openstack.org/#/c/274837/
19:35:38 <catherineD> The biggest decision is filtering of response data base on requester's role ( anonymous , foundation ad min, vendor admin ...)
19:36:54 <andrey-mp> catherineD: could you decsribe what problems do you see here?
19:37:32 <catherineD> on https://review.openstack.org/#/c/274837/8/specs/mitaka/approved/vendor-registration-api.rst
19:38:31 <catherineD> the different in response data on line 143 - 156 for anonymous users and 162- 178 for foundation and vendor admins
19:38:49 <andrey-mp> and, btw, Alex promised to desribe paging/sorting mechanism for our REST api...
19:39:14 <catherineD> andrey-mp: that is great
19:39:43 <andrey-mp> yeah, that's great but we don't have this :)
19:40:06 <catherineD> andrey-mp: we do not need to have everything on the first installation
19:40:13 <rockyg> ++
19:40:15 <catherineD> we can document it
19:40:26 <andrey-mp> do we really need created_at/updated_at fields in response?
19:40:46 <catherineD> we have to demonstrate that we consider all design aspects but not necessary implement all at start
19:41:19 <catherineD> andrey-mp: for an anonymous user no ...
19:41:23 <andrey-mp> for me it is not so hard to implement it but hard to describe :)
19:41:24 <catherineD> for foundation maybe
19:41:46 <andrey-mp> i asked about foundation...
19:42:33 <andrey-mp> because there is no description in this response (list)
19:42:38 <catherineD> For foundation members, they may want to see the date that the vendor was created ... for sorting
19:43:23 <catherineD> or filtering to know the number of vendor created in the last quarter for example
19:43:37 <catherineD> I can put in description
19:43:52 <catherineD> if that helps
19:44:22 <andrey-mp> description can help in list
19:44:27 <catherineD> ok
19:44:44 <andrey-mp> but anyway we will have same problem in 'get_one'
19:44:50 <rockyg> foundation also might want statistics on things like user churn, size of vendor approved users, etc
19:44:50 <catherineD> pls add a comment on ....
19:45:01 <catherineD> rockyg: ++
19:45:34 <andrey-mp> rockyg: I think this is additional info on 'vednor info page'
19:45:37 <catherineD> andrey-mp: yes we have the same problem ... and the spec also show filtering response
19:46:24 <catherineD> andrey-mp: but think about I just want to have a quick look of the vendor resgisterd for the last quarter ..
19:46:53 <catherineD> The vendor UI page should be able to display that ... just like the date range filter we have for the results
19:47:18 <rockyg> ++
19:48:04 <catherineD> everyone please review https://review.openstack.org/#/c/274837/
19:48:12 <andrey-mp> catherineD: yeah, it can help but this functionality is too wide to describe/implement it mitaka, or no?
19:48:42 <catherineD> andrey-mp: I do no mind if we do not implement it in Mitaka
19:49:10 <andrey-mp> catherineD: I'll ping Alex to describe paging/sorting that he want to see
19:49:32 <catherineD> for the spec, we want to demonstrate that we have consider all important aspect ... we can put a note in which one will be implemented later
19:50:04 <catherineD> andrey-mp: yea thx .. pls keep in mind that we do not have to implement every thing at start
19:50:20 <catherineD> for response filtering
19:50:21 <andrey-mp> yeah, but i want to document it now :)
19:50:48 <catherineD> andrey-mp: yea I agree that we need to document now
19:51:25 <catherineD> for response filtering ... we can start by provide limited data (with the created_date for example ..)
19:51:30 <catherineD> then add later
19:51:31 <andrey-mp> your spec has 'page' param and I think that we all should agree with it or use something else...
19:52:34 <catherineD> andrey-mp: if it helps to merge the spec faster ... I will just mention page and use that as example ..
19:52:37 <andrey-mp> catherineD: yes, it can be a way - provide data that users can see and then add specific cases
19:53:09 <catherineD> andrey-mp: and the start is to provide limited data ... then add on
19:53:17 <catherineD> not with more data and the reduce later
19:53:38 <andrey-mp> i agree
19:53:48 <catherineD> therefore thinking about the data privacy at this time will help us to know what should be provided now and what shoudl be added later
19:54:04 <catherineD> great ... let move on to the next topic
19:54:34 <catherineD> The spec does not memtion about update to type ... because it need more consideration
19:54:39 <catherineD> #topic Vendor "type" update
19:54:49 <andrey-mp> 3.3.1 - yes
19:56:01 <catherineD> how about 3,3.2 ... that means we can not use the normal update REST API for type ... as you and Alex commented earlier
19:56:05 <andrey-mp> 3.3.2 - this is best way to use additional methods instead of changing type in PUT request
19:56:22 <catherineD> andrey-mp: agreed
19:56:43 <catherineD> now 3.3.3
19:56:55 <andrey-mp> agree
19:57:06 <catherineD> 3.3.4
19:57:47 <andrey-mp> "official -> private/pending" - i think no. I can't image such scenarios
19:57:58 <pvaneck> isnt pending -> private what happens when a vendor is rejected?
19:58:11 <pvaneck> or not approved
19:58:19 <andrey-mp> but "pending -> private" is a 'decline' scenario
19:58:25 * catherineD 3 mins left could we continue for 15 mins at #refstack after this
19:58:45 <andrey-mp> foundation admin can decline registraion with entering a reason
19:59:13 <andrey-mp> (you can try it all on test server - http://52.49.129.72:8000/#/)
19:59:27 <catherineD> let got to #refstack
19:59:45 <catherineD> let's go to #refstack ...:-)
19:59:52 <andrey-mp> ok
19:59:52 <catherineD> #endmeeting