19:00:39 <catherineD> #startmeeting refstack 19:00:41 <openstack> Meeting started Mon Feb 15 19:00:39 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:43 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:00:45 <openstack> The meeting name has been set to 'refstack' 19:01:14 <pvaneck> o/ 19:01:21 <alexandrelevine> o/ 19:01:36 <catherineD> #chair sslypushenko: 19:01:36 <openstack> Warning: Nick not in channel: sslypushenko: 19:01:38 <openstack> Current chairs: catherineD sslypushenko: 19:02:43 <catherineD> I have a hard stop at 19:30 UTC sslypushenko: will run the meeting after that ... 19:03:02 <catherineD> #link meeting agenda and notes, please feel free to add items https://etherpad.openstack.org/p/refstack-meeting-16-02-15 19:03:46 <catherineD> #topic RefStack Speaker Session 19:04:04 <andrey-mp> o/ 19:04:11 <catherineD> #link Please vote for RefStack speaker sesson: https://www.openstack.org/summit/austin-2016/vote-for-speakers/Presentation/7575 19:04:35 <catherineD> andrey-mp: did you get th agenda link? 19:05:06 <andrey-mp> yeah 19:05:29 <andrey-mp> I agree with part 2 :) 19:05:58 <catherineD> could you please vote for th speaker session 19:06:11 <andrey-mp> 2.1 just create branch when it needs and cherry pick patches into 19:06:19 <catherineD> #topic RefStack tag release 19:06:21 <andrey-mp> i already voted last week 19:06:27 <catherineD> andrey-mp: thx 19:06:57 <catherineD> if we go with tag release 19:07:04 <catherineD> how do we handle bug fix 19:07:10 <catherineD> ? 19:07:32 <hogepodge> o/ 19:07:46 <catherineD> hogepodge: hi 19:08:13 <catherineD> andrey-mp: alexandrelevine: my concern about tag release is a process for us to handle bug fix 19:08:20 <andrey-mp> 1. create branch on tag commit 2. cherry-pick patch onto this branch 3. test all. 4. commit something else 5. create new tag 6. move tag in puppet-refstack 19:09:03 <andrey-mp> we will branch creation only once at each N.x.x tag 19:09:05 <catherineD> andrey-mp: do we have any other project that hosted by infra and update with tab? 19:09:08 <alexandrelevine> catherineD: Did andrey-mp give the answer you're looking for? 19:09:20 <catherineD> I thought they are all master 19:09:57 <andrey-mp> yes 19:10:12 <andrey-mp> gerrit have release process 19:10:58 <andrey-mp> nodepool for example - https://github.com/openstack-infra/nodepool/releases 19:11:03 <andrey-mp> has 4 releases 19:11:13 <catherineD> andrey-mp: great ... 19:11:17 <andrey-mp> this is a common process 19:11:42 <catherineD> #topic RefStack tag release convention 19:11:57 <andrey-mp> all of them have different tag names but they have tags 19:12:21 <catherineD> please take a look at https://etherpad.openstack.org/p/refstack-meeting-16-02-15 section 2.2 ... Let me know how you think of the convention ... 19:13:05 <alexandrelevine> I have no objections 19:13:11 <andrey-mp> I agree with it 19:13:25 <alexandrelevine> We might separate our releases from OpenStack, though. 19:13:28 <andrey-mp> most of infra projects have the same 19:13:35 <alexandrelevine> We're not bound to others releases at all. 19:13:46 <alexandrelevine> But in any case 1.0, 2.0 is totally fine by me :) 19:13:51 <andrey-mp> yeah, it shouldn't be hard-linked with OpenStack 19:14:00 <catherineD> alexandrelevine: agree .. I do not think so 19:14:14 <catherineD> we can define our own convention 19:14:26 <catherineD> #topic Privacy data iin RefStack (private vs public) 19:14:39 <catherineD> alexandrelevine: DefCore did not have meeting last week 19:15:12 <alexandrelevine> catherineD: Now that we can commit more easily I guess it won't stop us, right? We can narrow down our response later. 19:15:14 <catherineD> so I ask the privacy question in IRC ... I will ask DefCore again on this week's meeting 19:15:45 <andrey-mp> catherineD: so now you can create a tag on refstack repository today-tomorrow ? 19:16:02 <catherineD> alexandrelevine: I think we still should be careful with our code ... after all this is not PoC 19:16:04 <alexandrelevine> catherineD: I suggest we start with full response visibility and later change it if required. 19:16:34 <alexandrelevine> catherineD: We are. I don't think a couple of properties in our non-production code without any registered real-life vendor is a problem. 19:16:40 <catherineD> I would rather we start with limited info and add more 19:17:07 <alexandrelevine> catherineD: It's more complicated and extra-development. I'd rather moved from simple to complicated if motivated. 19:17:19 <catherineD> alexandrelevine: it will be in production in 6 weeks right? before the sumit ... at least for the vendor registration part 19:17:46 <alexandrelevine> catherineD: I hope 6 weeks is enough to contact DefCore with this question and for us to update. 19:17:53 <catherineD> alexandrelevine: I agree with simple if less data 19:18:09 <alexandrelevine> catherineD: It's not simple then :) 19:18:50 <alexandrelevine> catherineD: What do you want to limit? Do we have a list of the properties for vendor registration at all now? I guess not. 19:18:51 <catherineD> so for th privacy data ... let's wait until Wed 19:19:00 <alexandrelevine> ok 19:19:34 <catherineD> I want us to think about the private vs public data of the 2.2.1, 2.2.2, 2.2.3 19:19:46 <catherineD> sorry 19:19:55 <catherineD> not 2.2x ... :-( 19:20:10 <catherineD> 3.1 , 3.2, 3.3 19:20:23 <alexandrelevine> For me everything listed is totally public. 19:20:29 <alexandrelevine> No reason to hide it. 19:20:39 <andrey-mp> +1 19:20:42 <alexandrelevine> It's general information available in other places. 19:20:54 <catherineD> obviously I disagree but let's wait for Wed 19:21:01 <catherineD> moving on 19:21:11 <alexandrelevine> In any case it's not for us to discuss even if there is a hint of doubt. 19:21:16 <catherineD> #topic Vendor user management 19:22:16 <catherineD> For me, the only thing that stop me for these patches is th displayment of OpenID ... again I will check with DefCore on Wed 19:22:36 <alexandrelevine> By the way, if you want we have a suggestion about naming and grouping of UI. You can take a look here: http://52.49.129.72:8000/#/ 19:22:36 <sslypushenko> o/ Hi, all! Sorry for the late 19:23:03 <catherineD> Hi sslypushenko: I will be leaving the meeting in 8 mins ... 19:23:06 <alexandrelevine> Namely, we suggest to group Vendors, Clouds and Software to Catalog and My Catalog so that we have enough place for everything. 19:23:18 <catherineD> sslypushenko: ypu will be the chair 19:23:26 <pvaneck> liking the drop down in the menu 19:23:29 <sslypushenko> hmm) ok 19:23:30 <catherineD> we are at item 4 in https://etherpad.openstack.org/p/refstack-meeting-16-02-15 19:24:59 <catherineD> alexandrelevine: thx for the link ... I can also see andrey-mp: code in my private server .. 19:27:03 <catherineD> #topic Vendor REST APIs 19:27:09 <sslypushenko> looks like RefStacks need some kind of UX expert) 19:27:26 <catherineD> sslypushenko: agreed ... 19:27:42 <catherineD> as our UI becomes richer ... Usability becomes important 19:28:01 <catherineD> I need to leave in 2 mins ... 19:28:20 <catherineD> my today is ... make sure to get answer from DefCore on private vs public data 19:28:26 <andrey-mp> this is also related to release process - we can implement something and change UI in parallel :) 19:28:58 <catherineD> sorry got to go now ... will check the log later 19:29:13 <sslypushenko> catherineD: np 19:29:15 <catherineD> sslypushenko: pls remember to end the meeting 19:29:23 <sslypushenko> sure 19:30:26 <andrey-mp> will we discuss now item 4 before talking with Defcore? 19:31:14 <alexandrelevine> andrey-mp: We just did as I understand. CatherineD went checking with DefCore 19:31:36 <pvaneck> I don't really see the issue with using openid 19:31:53 <alexandrelevine> pvaneck: CatherineD apparently does. 19:31:54 <andrey-mp> pvaneck: me too 19:32:41 <pvaneck> feel like it's synonymous with a username 19:33:15 <pvaneck> hogepoge: you are leaning towards openid should be kept private? 19:33:29 <pvaneck> just based on the agenda tidbit 19:34:19 <andrey-mp> if we make OpenID private we will need another unique identifier for the REST api (because we don't have it) 19:34:56 <andrey-mp> let's move to another comments? 19:34:58 <sslypushenko> I also think that there is no reason to hide openID 19:36:26 <andrey-mp> first comment is about usefulness 'name' in get request 19:36:56 <andrey-mp> and second is about ecnoding OpenID in pu/delete requests 19:37:58 <andrey-mp> my third comment - we need some method like 'find_user(pattern)' but it doesn't related this doc... 19:40:32 <sslypushenko> it looks that we again dig to deep into details 19:40:47 <sslypushenko> I'm talking about encoding now 19:41:41 <andrey-mp> ok, we can move this details into implementation and forget it in the spec 19:42:27 <sslypushenko> any data can be put into url... so any kind of encodinf will work here 19:42:46 <andrey-mp> I thought that it is a significant detail 19:43:37 <andrey-mp> but it will not be a real OpenID 19:44:03 <sslypushenko> In python there is a default url safe encoding/decoding - lets use it and that is all 19:44:22 <alexandrelevine> sslypushenko: Honestly speaking, it seems that we're a little too much into specs now. Especially when we write them on top of implementation. Maybe it'll be faster to present code and a site as a prototype and agree upon result with necessary tweaking without duplicating it in specs? What do you think? 19:45:21 <sslypushenko> alexandrelevine: yeap you are right. It is mainly because catherineD wants to control the process 19:45:38 <alexandrelevine> sslypushenko: Specs as a means for initial design and planning are good for distributed development and complicated stuff to agree upon something beforehand. But it's not the case here with us at the moment. 19:46:12 <sslypushenko> you are right again) but... 19:46:16 <alexandrelevine> sslypushenko: It's as easy to control with code reviews. She has the final say. 19:46:43 <alexandrelevine> sslypushenko: Maybe we can talk about it next time? I think we're just loosing time with it at the current stage. 19:47:10 <sslypushenko> It would be easy if catherineD was an developer)) 19:47:16 <pvaneck> in regards to name in the vendor users request, I feel that sure we can have it, but it may not be entirely useful for the beginning phases when vendors don't really have many users. 19:47:34 <sslypushenko> alexandrelevine: Just don't take spec writing process to close 19:47:45 <alexandrelevine> sslypushenko: Nobody's taking the control and nobody wants to. But specs were introduced in nova initially and they were designed to be used only to help, when really needed. Not for every single step. 19:48:10 <sslypushenko> spec can be adjusted to prototype if it is working for all 19:48:41 <alexandrelevine> sslypushenko: Whatever for? What's the point of it if it's not used as a pre-implementation design agreement instrument? 19:48:48 <andrey-mp> pvaneck: I agree. it may be useful later. 19:49:18 <alexandrelevine> andrey-mp: What name are you talking about, sorry? 19:49:19 <sslypushenko> In our case - spec it is kind of documentation 19:49:31 <andrey-mp> first comment is about usefulness 'name' in get request 19:49:34 <alexandrelevine> sslypushenko: :) Come on. 19:49:53 <sslypushenko> alexandrelevine: Really) 19:50:11 <andrey-mp> sslypushenko: and we can write it after implementation? :) 19:50:52 <sslypushenko> So just move as fast as you can in implementation and if it is working for all - we can just specs later 19:51:12 <alexandrelevine> sslypushenko: Ok :) 19:51:20 <andrey-mp> ok :) 19:51:31 <sslypushenko> it is not about writing 19:51:37 <sslypushenko> it more about details 19:51:42 <alexandrelevine> sslypushenko: Though this is idea of specs turned upside down. 19:52:29 <sslypushenko> yeap 19:52:35 <sslypushenko> It is opensource))) 19:53:03 <alexandrelevine> About the name. I'm totally against it. 19:53:14 <sslypushenko> alexandrelevine: agreed 19:53:16 <alexandrelevine> It can be OpenID as an identifier but not name. 19:53:52 <andrey-mp> alexandrelevine: in such case it doesn't needed at all 19:53:53 <alexandrelevine> If we want to filter by something we should allow for expansion of this place so we should create "filter" and then put "name" and whatever else into it. 19:53:57 <sslypushenko> hmmm , are you talking about list endpoint? 19:54:22 <andrey-mp> why we need filter by vendor_id and openID if it can work only by openID? 19:54:28 <alexandrelevine> Otherwise we'll end up by adding more and more fields into the request to provide different filters. 19:54:31 <sslypushenko> I think we should introduce filtering in some other way 19:54:33 <alexandrelevine> sslypushenko: yes 19:54:49 <alexandrelevine> sslypushenko: Agree. When we need it. Not in first round. 19:54:51 <sslypushenko> in some more general way, I can say 19:54:57 <alexandrelevine> sslypushenko: ++ 19:54:59 <andrey-mp> so, filtering doesn't needed at all in this request 19:55:19 <alexandrelevine> sslypushenko: Right now filtering can be done on client-side throughout our puny 100 Vendors. 19:55:21 <sslypushenko> for the time being - definately 19:55:33 <alexandrelevine> sslypushenko: So no "name" in list. 19:55:38 <sslypushenko> yeap 19:55:43 <pvaneck> agree, no need for filtering users in vendors now 19:56:15 <sslypushenko> #agree, no need for filtering users in vendors now 19:56:24 <sslypushenko> hope this will worl)) 19:56:26 <andrey-mp> let's move to item 5 or to refstack channel? ) 19:56:28 <sslypushenko> *work 19:56:56 <sslypushenko> yeap 19:57:06 <sslypushenko> I have 10-15 mins 19:57:15 <sslypushenko> so #endmeeting 19:57:41 <sslypushenko> Thx to all for attending) 19:57:56 <pvaneck> i think #endmeeting in own line 19:58:08 <sslypushenko> #endmeeting 19:58:16 <sslypushenko> hmmm) 19:58:23 <alexandrelevine> :))) 19:58:27 <redrobot> sslypushenko no space before #endmeeting 19:58:35 <alexandrelevine> we're doomed 19:58:38 <sslypushenko> #endmeeting 19:58:44 <sslypushenko> oops) 19:59:01 <redrobot> sslypushenko I think you broke it 19:59:06 <redrobot> :-P 19:59:27 <sslypushenko> one more time 19:59:28 <sslypushenko> #endmeeting 19:59:35 <sslypushenko> nope( 20:00:04 <pvaneck> #endmeeting 20:00:16 <openstack> redrobot: Error: Can't start another meeting, one is in progress. Use #endmeeting first. 20:00:22 <redrobot> #endmeeting 20:00:57 <catherineD> #endmeeting