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