21:01:49 <markmcclain> #startmeeting crossproject
21:01:50 <openstack> Meeting started Tue Aug  4 21:01:49 2015 UTC and is due to finish in 60 minutes.  The chair is markmcclain. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:01:51 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:01:53 <morganfainberg> o/
21:01:54 <openstack> The meeting name has been set to 'crossproject'
21:01:55 <mtreinish> o/
21:01:56 <stevebaker> \o
21:01:58 <johnthetubaguy> o/
21:01:59 <elmiko> o/
21:02:00 * morganfainberg lurks mostly though.
21:02:05 <jokke_> o/
21:02:10 <flaper87> morganfainberg: :P
21:02:13 <bknudson> hi
21:02:13 <markmcclain> #link https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting
21:02:17 <tpatil> Hi
21:02:19 <NobodyCam> o/
21:02:20 <mtreinish> morganfainberg: that's all I normally do too :)
21:02:27 <markmcclain> Light agenda for this week
21:02:35 <markmcclain> #info Meeting chairs needed for next week (August 11th) and three remaining open
21:02:36 <markmcclain> dates.
21:02:47 * Rockyg is still lurking (mostly)
21:03:06 * edleafe is still lurking too
21:03:11 * geoffarnold ditto
21:03:20 * jokke_ will look the dates
21:03:22 <ttx> I can't take it next week
21:03:26 <markmcclain> anyone available for next week?
21:03:29 <dhellmann> o/
21:03:32 * bknudson lurks
21:03:44 <mestery> o/
21:03:57 <jokke_> dhellmann: seems to have just volunteered ;)
21:04:04 <elmiko> hehe
21:04:10 <edleafe> jokke_: +1!
21:04:14 <dhellmann> jokke_: no, no, no
21:04:25 <jokke_> :P
21:04:30 <edleafe> dhellmann: aw, don't be shy!
21:04:31 <mestery> I can do it next week markmcclain
21:04:37 <markmcclain> mestery: thanks!
21:04:44 <mestery> markmcclain: yw :)
21:05:22 <Rockyg> dhellmann, you dodged a bullet!
21:05:29 <markmcclain> haha... moving on
21:05:31 <ttx> that one was close
21:05:36 <markmcclain> #topic Horizontal Team Announcements
21:05:46 <ttx> On the release management side, not a lot of things this week
21:05:53 <ttx> We've been starting to discuss how to actually implement continuous releasing of stable point releases, in two -dev threads:
21:05:58 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2015-August/071188.html
21:06:01 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2015-August/071189.html
21:06:01 <dhellmann> edleafe: I've had my turn.
21:06:05 <ttx> Chime on those if you have an opinion on the topic
21:06:33 <ttx> taking a week off starting now so don't expect me to follow those threads closely!
21:06:40 <fungi> yes, i worry we don't ever get much input from downstream package maintainers and operators/deployers on topics like this until we enact them
21:07:10 <fungi> and then end up with a small-scale revolt on our hands because we changed something they depended on in their workflow
21:07:28 <Rockyg> maybe post contents or summary to the operator's list with a request to discuss?
21:08:12 <fungi> i'd love to just stop having stable point releases at all in liberty and beyond, which was the original proposal, but what little feedback we got from downstream consumers was that they didn't want to lose whatever nonexistent signaling they actually thought they were getting from those
21:08:15 <jokke_> we should get shout of discussions like these advertised on the every Friday spam ;)
21:08:34 <jokke_> fungi: ++
21:08:51 <fungi> jokke_: yep, i passed those threads along to the person writing the weekly newletter earlier today
21:08:59 <jokke_> gr8
21:09:04 <fungi> so that might help raise visibility some
21:09:45 <edleafe> ttx: enjoy!
21:10:02 <markmcclain> Any other horizontal announcements?
21:10:33 <johnthetubaguy> ttx: I quite like that increment on every commit, its simple
21:11:28 <Rockyg> johnthetubaguy, ++
21:11:35 <jokke_> johnthetubaguy: and easily automated
21:12:11 <ttx> clarkb was arguing it would pollute the ref space
21:12:14 <fungi> (i don't know about "easily")
21:12:24 <johnthetubaguy> also agreed with fungi about the need to get the package maintainers involved
21:12:38 <jokke_> fungi: well easier than the other models
21:12:57 <fungi> mostly just don't want to waste time implementing something complex they don't need/won't use anyway
21:13:16 <johnthetubaguy> hmm, clarkb has a point, maybe I am not sure about the tag for each commit, if that would work well enough without that (shrugs)
21:13:21 <bknudson> it is kind of strange to have a tag on every commit
21:13:51 <morganfainberg> isn't a commit... effectively a tag?
21:13:58 <jokke_> the good point pro that in the ml discussion was that it's easy to find out if you have the fix for X which is A.B.C included C+7, yes it is
21:14:37 * morganfainberg doesn't really have a horse in this race but things it's silly to tag every commit... but ... meh?
21:14:48 <jokke_> morganfainberg: it's not easy for human (nor computer) to tell by commit id alone if it was before or after another random commit id
21:14:48 <morganfainberg> thinks*
21:15:02 <fungi> morganfainberg: commits don't imply a sequence, nut anyway these are points better made on th ml
21:15:21 <ttx> indeed. Follow up on ML if you care. Next topic!
21:15:21 <fungi> where i also type gooder
21:15:49 <johnthetubaguy> yeah, to the ML on this one
21:16:13 <markmcclain> cool.. moving on
21:16:27 <markmcclain> #topic Return request ID to caller
21:16:28 <markmcclain> #link https://review.openstack.org/#/c/156508/
21:16:34 <tpatil> I want to discuss about 3 review comments given by Brant on the specs
21:16:44 <tpatil> First concern: Every method should return an object which contains request_id attribute, so that it’s consistent. This also applies to Tuple return type
21:17:05 <tpatil> IMO, we cannot change Tuple response as it would affect Openstack services. Tuple contains ‘X-Openstack-Request-Id’ in the response header of Response object. So I don’t think there is a need to add request_id attribute here. But I agree it’s not consistent with other types though
21:17:35 <tpatil> We are going to add a new method ‘get_request_id” in client which would return request_id (String) depending on the type of the response to the caller
21:17:50 <tpatil> All logic to interpret different response type will be contained in this new method so user don’t have to worry about it
21:18:11 <tpatil> Any comments?
21:18:17 <johnthetubaguy> yeah, that sounds like the compromise I remember us heading towards
21:18:42 <tpatil> johnthetubaguy: Right
21:19:00 <tpatil> Second concern: We were thinking of adding all base class (ListWithMeta, DictWithMeta) in oslo.incubator, but Brant pointed some serious concerns of using oslo.incubator library in keystoneclient
21:19:39 <tpatil> It's possible to add all these new classes in individual clients but it would be repetitive code
21:19:40 <bknudson> having oslo-incubator (unstable code) in keystoneclient (stable code) has been a real pain
21:20:16 <bknudson> I'd be fine if it was obvious that oslo-incubator code was private (prefixed with _)
21:20:33 <dhellmann> where would these classes end up after they left the incubator?
21:20:33 <bknudson> but that's not how apiclient was implemented
21:20:46 <morganfainberg> if the oslo-incubator code isn't marked as private, I'm going to go out on a limb and say I will reject it for keystoneclient
21:21:25 <morganfainberg> i don't want external projects grabbing the incubator code from keystoneclient as though it was a stable interface of keystoneclient
21:21:40 <dhellmann> tpatil: I don't understand why subclassing tuple so methods that return tuples behave the same as the other methods is going to break anything?
21:21:47 <johnthetubaguy> I am curious actually, what issues were you seeing with the incubator stuff? oh... thats nasty, I see
21:22:02 <dhellmann> morganfainberg: yeah, the incubated code should clearly be private. Maybe we should change foo/openstack to foo/_openstack
21:22:15 <morganfainberg> dhellmann: that would solve my major concern :)
21:22:28 <bknudson> dhellmann: that would be great
21:22:34 <dhellmann> although I'm not certain why this needs to be incubated at all, so I would like to understand that and where it will live later on
21:22:48 <tpatil> dhellmann: we haven't change anything related to Tuple
21:22:48 <dhellmann> because maybe it can just go there now and skip the incubation step
21:23:15 <morganfainberg> dhellmann: i'd also be ok with that
21:23:29 <Rockyg> the less that has to migrate through the incubator, the better.
21:23:30 <dhellmann> tpatil, bknudson : can one of you explain the concern about tuples? maybe I'm misunderstanding, but it sounded like you thought there was a reason not to change methods that return tuples?
21:23:49 <morganfainberg> Rockyg: ++
21:23:50 <fungi> yeah, i thought oslo-incubator was for code extracted from one or more existing projects, not for entirely new works
21:24:01 <dhellmann> tpatil: you say in a comment on line 111: "But we cannot change Tuple response since it will break OpenStack services consuming it."
21:24:11 * morganfainberg is against incubator code in general, especially *new* incubator code
21:24:43 <Rockyg> morganfainberg, me, too
21:24:44 <bknudson> dhellmann: methods that return dict, dict is wrapped so you can do .request_id, whereas with tuple it's not wrapped so you can't do .request_id on the returned value
21:25:05 <tpatil> dhellman: first of all ,we cannot subclass tuple and add request_id attribute
21:25:07 <bknudson> dhellmann: so my concern was that I'd like it to be consistent where everything that's returned you can do .request_id on it.
21:25:10 <dhellmann> fungi: it is for code where we expect the API to have to evolve in a way that will break things. In the past the predominant source of that code has been other projects, but there's no hard rule for that.
21:25:21 <tpatil> dhellman, so we want to keep the same behavior
21:25:28 <dhellmann> tpatil: why can't you subclass tuple?
21:25:43 <tpatil> dhellman: immutable
21:26:02 <tpatil> dhellman: we tried to override __new__ method but that doesn't help too
21:26:23 <dhellmann> tpatil: it seems to work fine for me: http://paste.openstack.org/show/406994/
21:26:44 <fungi> dhellmann: interesting that there aren't better ways to avoid people thinking you have stable interfaces in a library besides avoiding making a library at all
21:27:04 <morganfainberg> fungi: issues with python :(
21:27:12 <fungi> but i guess that's verging off topic
21:27:23 <bknudson> let's switch to java
21:27:30 <dhellmann> tpatil: a longer example: http://paste.openstack.org/show/406995/
21:27:43 <Rockyg> heretic!
21:28:20 <dhellmann> fungi: well the point is that sometimes there aren't stable interfaces and rather than supporting something crummy for a long time we evolve it using static linking instead
21:28:24 <tpatil> dhellman: Ok, so with this, user can access request_id attribute
21:28:28 <dhellmann> right
21:28:49 <tpatil> dhellman: We will confirm this if it works and incorporate it in the specs. Thanks.
21:29:00 <tpatil> Third concern: In case ListWithMeta, request_id is of type list and other places it is not. why?
21:29:09 <tpatil> ListWithMeta type is returned mostly for various list (volumes/snapshots etc) methods.
21:29:17 <tpatil> So it may contain one or more request_ids depending on 'limit' and 'page_size' parameters passed in the request
21:29:26 <bknudson> so these comments were about making the interface consistent
21:29:26 <tpatil> Whereas in all other cases, there will be only one request_id
21:29:34 <bknudson> so that the same code could be used to process it.
21:29:39 <tpatil> bknudson: right
21:29:44 <dhellmann> bknudson: do we need a list everywhere, then?
21:29:46 <tpatil> But if we want request_id attribute to be consistent for all types, then we will change it list type
21:29:54 <bknudson> a list everywhere would be consistent
21:30:10 <dhellmann> ok, so then request_ids instead of request_id
21:30:11 <bknudson> and also more resilient in case other methods required making multiple calls
21:30:26 <tpatil> dhellman: sure
21:30:32 <johnthetubaguy> yeah, that seems good, makes it simpler
21:30:58 <tpatil> That's address all my concerns, anyone has anything else to add
21:31:15 <tpatil> s/address/addresses
21:31:29 <Rockyg> sounds like one more revision might jsut do it.  Great work, tpatil
21:31:41 <markmcclain> thanks for working on this the last few weeks
21:31:44 <tpatil> Rockyg: Thanks
21:31:56 <markmcclain> #topic Vertical Team Announcements
21:32:08 <markmcclain> Any vertical team announcements?
21:32:54 <markmcclain> #topic Open discussion
21:33:15 <markmcclain> #info Travel Support Program Deadline is August 10th
21:33:19 <markmcclain> #link https://wiki.openstack.org/wiki/Travel_Support_Program
21:33:44 <elmiko> 2 new api guidelines up for group review, #link http://lists.openstack.org/pipermail/openstack-dev/2015-August/071345.html
21:34:15 <markmcclain> elmiko: apologies... I missed those otherwise would have added to agenda
21:34:37 <elmiko> markmcclain,  no worries, it's more informational. i don't think there is much to discuss.
21:34:42 <markmcclain> ok
21:35:00 <elmiko> although, i say that now, it really blew up last time lol
21:35:39 <markmcclain> yeah.. funny how that happens
21:35:48 <markmcclain> any other open items?
21:35:57 <elmiko> also, i did add them to the agenda wiki. is there a better place for future reference?
21:36:22 <markmcclain> elmiko: that's the right place.. I had not refreshed my browser from this morning when I sent the email
21:36:32 <elmiko> gotcha, thanks =)
21:36:53 <markmcclain> #info mestery to chair next week
21:37:20 <mestery> markmcclain: Thanks ... I think. o_O
21:37:23 <mestery> :)
21:37:34 <markmcclain> Thanks for volunteering
21:37:41 <markmcclain> Have a great week everyone.
21:37:43 <markmcclain> #endmeeting