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