21:03:08 <johnthetubaguy> #startmeeting crossproject
21:03:09 <openstack> Meeting started Tue Jul 28 21:03:08 2015 UTC and is due to finish in 60 minutes.  The chair is johnthetubaguy. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:03:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:03:12 <edleafe> fungi: +1
21:03:13 <openstack> The meeting name has been set to 'crossproject'
21:03:16 <jokke_> o/
21:03:18 <SergeyLukjanov> o/
21:03:18 <tpatil> Hi
21:03:20 <johnthetubaguy> courtesy ping for david-lyle flaper87 dims dtroyer johnthetubaguy rakhmerov
21:03:20 <johnthetubaguy> courtesy ping for smelikyan morganfainberg adrian_otto bswartz slagle
21:03:20 <johnthetubaguy> courtesy ping for adrian_otto mestery kiall jeblair thinrichs j^2 stevebaker
21:03:20 <johnthetubaguy> courtesy ping for mtreinish Daisy Piet notmyname ttx isviridov gordc SlickNik
21:03:20 <johnthetubaguy> courtesy ping for cloudnull loquacities thingee hyakuhei redrobot dirk TravT
21:03:21 <EmilienM> o/
21:03:21 <johnthetubaguy> courtesy ping for vipul emilienm SergeyLukjanov devananda boris-42 nikhil_k
21:03:21 <elmiko> heyo/
21:03:24 <dims> o/
21:03:24 <david-lyle> o/
21:03:27 <fungi> mmm hot cross projects
21:03:30 <mtreinish> o/
21:03:31 <edleafe> o/
21:03:31 <bknudson> hi
21:03:32 <johnthetubaguy> hello all
21:03:32 <stevebaker> \o
21:03:43 <thingee> o/
21:03:44 <dhellmann> o/
21:03:44 <johnthetubaguy> fungi: I am hungry now :)
21:03:48 <fungi> indeed
21:03:56 <elmiko> lol
21:03:57 <SlickNik> o/
21:03:58 <morganfainberg> Im mostly just lurking. bknudson can speak on keystone's behalf if i miss something.
21:03:59 <fungi> it's already dinner time here
21:04:00 <ttx> o/
21:04:08 <jungleboyj> o/
21:04:09 * mestery lurks while at the board meeting in person
21:04:10 <ttx> it's way past dinner time here
21:04:14 <johnthetubaguy> so looking that the agenda page
21:04:20 <johnthetubaguy> #link https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting
21:04:34 <jokke_> ttx: it's past bed time for you ;)
21:04:38 <TravT> o/
21:04:39 <johnthetubaguy> seems like we need someone for August 11th
21:04:43 <redrobot> o/
21:04:43 <johnthetubaguy> if people are keen
21:04:48 <devananda> \o
21:04:51 <johnthetubaguy> anyways, lets get cracking...
21:05:03 <johnthetubaguy> #topic Team announcements (horizontal, vertical, diagonal)
21:05:10 <ttx> On the release management side, this week is liberty-2 week
21:05:17 <ttx> So for projects that do development milestones, we'll be tagging that between today and Thursday
21:05:26 <ttx> If you haven't yet, ping dhellmann or me ASAP on #openstack-relmgr-office
21:05:42 <johnthetubaguy> #info its liberty-2 week reach out on #openstack-relmgr-office
21:05:43 <ttx> EOF
21:06:36 <dhellmann> if you're managing your own milestone, the checklist we use is:
21:06:37 <dhellmann> #link https://wiki.openstack.org/wiki/Release_Cycle_Management/Milestone_Checklist
21:06:58 * johnthetubaguy pokes the crowd for more announcements, maybe everyone is busy with liberty-2?
21:07:11 <ttx> or not
21:07:23 <fungi> for those who missed the excitement, we had a security advisory for a non-vulnerability:managed deliverable today, whose vmt basically followed the vmt's documented process. kudos to kiall (who is apparently not with us)
21:07:39 <fungi> er, whose ptl
21:08:02 <dhellmann> nice!
21:08:05 <johnthetubaguy> so on the Nova side, we are doing a non-priority feature freeze on Thursday, in case thats on interest to other project
21:08:11 <fungi> #link http://lists.openstack.org/pipermail/openstack-announce/2015-July/000482.html
21:08:28 <fungi> anyway, that's a piece of the vmt's bigtop scaling plan
21:08:42 <fungi> help project-teams help themselves
21:08:53 <johnthetubaguy> fungi: sweet, good stuff
21:09:44 <johnthetubaguy> OK, so I sense a lack of updates, lets move on then...
21:09:58 <elmiko> api-wg has four new guidelines up for review
21:09:58 <johnthetubaguy> #topic API Guidelines
21:10:04 <elmiko> lol
21:10:08 <johnthetubaguy> #link http://lists.openstack.org/pipermail/openstack-dev/2015-July/069765.html
21:10:08 <elmiko> #link http://lists.openstack.org/pipermail/openstack-dev/2015-July/069765.html
21:10:12 <elmiko> jinx!
21:10:15 <johnthetubaguy> elmiko: jinx!
21:10:19 <johnthetubaguy> damm I was too slown
21:10:19 <thingee> #undo
21:10:29 <johnthetubaguy> thingee: thanks for the fix, good call
21:10:38 <elmiko> we can each owe each other a beverage johnthetubaguy ;)
21:10:42 <fungi> (the chair has to #undo)
21:10:45 <johnthetubaguy> so yeah, any of those people want to disucss
21:10:45 <thingee> don't think it registered
21:10:47 <johnthetubaguy> #undo
21:10:47 <openstack> Removing item from minutes: <ircmeeting.items.Link object at 0xae8c1d0>
21:10:48 <thingee> fungi: heh thanks
21:10:55 <fungi> np
21:10:58 <johnthetubaguy> fungi: ah, cool
21:11:21 <elmiko> these have actually been up for 2 weeks now, but we haven't had any negative feedback yet. iirc
21:11:25 <johnthetubaguy> so yeah, anything we need to discuss on there?
21:11:38 <elmiko> although i will need to get etoews to remove the -2
21:11:45 <jokke_> elmiko: one of them had at least this afternoon couple of -1s
21:11:58 <elmiko> jokke_: ack, thank you
21:12:18 <johnthetubaguy> jokke_: is it worth talking about the -1s here?
21:12:23 <jokke_> I think it is
21:12:27 <elmiko> i think the api-wg needs to review our freeze process as well. -2 seems to be not working for us
21:12:30 <jokke_> it's the header namings
21:12:41 <bknudson> all of these seem reasonable...
21:12:48 <elmiko> #link https://review.openstack.org/#/c/186526/
21:12:49 <johnthetubaguy> #link https://review.openstack.org/#/c/186526/
21:12:50 <bknudson> note that keystone also uses the PATCH operation that has a body
21:12:53 <johnthetubaguy> #undo
21:12:54 <openstack> Removing item from minutes: <ircmeeting.items.Link object at 0xa76b910>
21:12:58 <jokke_> I think it would be nice to agree on them and move on
21:13:24 <johnthetubaguy> so missing a meeting last week was a bad slow down I guess
21:14:02 <johnthetubaguy> I like giving people time to see them I suppose, but yeah, don't want to always enforce the slow down all the time I guess
21:14:21 <elmiko> the real issue seems to come down to using project name or service name in the headers
21:15:01 <bknudson> now we need to switch to OS-Identity-Token instead.
21:15:16 <elmiko> i think we'd like to recommend project name as it provides more resolution
21:15:54 <johnthetubaguy> elmiko: you mean if two projects have a compute API, or something like that?
21:16:17 <jokke_> elmiko: ++ with big tent I think we might start seeing bit more overlapping
21:16:20 <elmiko> johnthetubaguy: right, we could recommend Nova-someheader and NotNova-someheader ..
21:17:09 <edleafe> that would be confusing for end-users
21:17:14 <johnthetubaguy> unsure if etoews is around
21:17:26 <elmiko> i think he is still on vacation
21:17:27 <edleafe> if the backend implements a different project for compute
21:17:31 <johnthetubaguy> if the API working group owned the API name list, that would help
21:17:35 <johnthetubaguy> elmiko: ah, no worries
21:17:54 <elmiko> i'm not sure we want to "own" something like that
21:18:02 <johnthetubaguy> like have a registry of API names, so the registry would help deal with clashes in the big tent
21:18:13 <johnthetubaguy> elmiko: true, maybe it goes in the projects.yaml?
21:18:25 <elmiko> i agree it would be helpful, but the main thrust of the api-wg is to provide guideance and learning on creating sensible apis
21:18:26 <johnthetubaguy> like API-service-name: XYZ
21:19:09 <jokke_> that would be nice including current version of that API
21:19:37 <johnthetubaguy> jokke_: I guess it could
21:19:44 <fungi> hoping once the theory-of-api-design discussions die down within the api-wg, we might also see more suggestions on fixing bad api user experiences we have in existing implementations
21:19:49 <elmiko> and remember this specific guidance is about adding new headers, we recommend that projects use more specific headers and to not necessarily use X-....
21:20:27 <elmiko> fungi: we have talked about creating advice for developers wishing to migrate their apis, this is something that is still very much in the design phase though.
21:20:34 <jokke_> one thing that concerns me around that proposal is consistency
21:21:05 <sigmavirus24> jokke_: the header proposal?
21:21:07 <jokke_> now we will have N APIs using X- headers and soon enough N+1 that does not
21:21:15 <thingee> fungi: +1
21:21:17 <jokke_> consistency ... that gremlin
21:21:17 <devananda> fungi: ++ on api-wg helping to improve UX
21:21:37 <thingee> fungi: Somehow things moved away from this idea.
21:21:40 <elmiko> jokke_: a valid concern, not sure we can really help more than to instruct developers on the best path out of the tangled forest ;)
21:21:52 <edleafe> jokke_: yeah, but when the standard shifts from underneath you...
21:22:08 <devananda> re: the "X-" in the header -- I'm of the mind that we should keep it there because it's an evolving thing. but either way, it should be consistent across all projects
21:22:23 <jokke_> edleafe: no-one told that the X- is not allowed it's just not the one that is insisted
21:22:26 <jroll> question: is someone actually going to go register all of these headers in the IANA message headers registry?
21:22:39 <sigmavirus24> jokke_: consistency, the thing OpenStack doesn't have
21:22:41 <elmiko> jroll: that is a good question
21:22:52 <devananda> and my counter argument to the api-wg would be: if we drop the X- from that header, should'nt we drop the X- from all the othre headers too?
21:23:04 <edleafe> jokke_: it is discouraged for new headers, but with full recognition that existing headers, well, *exist*.
21:23:06 <sigmavirus24> devananda: not existing APIs
21:23:15 <jroll> elmiko: and if nobody is going to register them, things like "Compute-API-Version" will almost certainly conflict with other things out there
21:23:18 <elmiko> devananda: if the goal is to work towards consistency, then yes. i'm not sure that is the goal at this point though.
21:23:20 <sigmavirus24> devananda: it should be dropped when authoring new versions of APIs
21:23:25 <jokke_> sigmavirus24: that's why I'm surprised that the api_wg is suggesting to break the one thing we had it even remotely ;)
21:23:42 <sigmavirus24> jokke_: we're suggesting you follow API best practices
21:23:47 <jroll> (I'm not sure if registration is a SHOULD or MUST or MAY, though)
21:23:54 <sigmavirus24> which, promotes good user experience
21:23:54 <jokke_> edleafe: ah, might be that I misunderstood the point there then, sorry
21:23:58 <elmiko> i think registering the header names, and moving towards consistency are excellent points for our forthcoming migration guidance
21:24:35 <devananda> sigmavirus24: authoring new service projects? new major versions of APIs of existing projects? or something else?
21:24:47 <sigmavirus24> jokke_: also don't get me started on which services use headers for things they absolutely shouldn't
21:24:52 <sigmavirus24> devananda: yes
21:24:57 <devananda> sigmavirus24: and would it be dropped from all headers returned in those cases, or just the "established" ones?
21:25:24 <jroll> another question: does consistency in header names actually benefit users? do people really expect to be able to look for "X-%(service_type)-Version" or whatever?
21:25:25 <jokke_> I would thing that major version is the only acceptable place to change those?
21:25:45 <edleafe> devananda: if a service has 'X-Foo-Bar', they could continue to support that, and also add 'Foo-Bar' for the future
21:26:01 <sigmavirus24> jroll: given that people don't all use the command-line clients and some are writing them from scratch, that helps users, yes
21:26:02 <devananda> edleafe: mm, indeed
21:26:02 <edleafe> devananda: and all new APIs would not use 'X-'
21:26:30 * sigmavirus24 wonders if he even needs to participate given how well edleafe is explaining this on his own
21:26:37 <elmiko> edleafe: +1
21:26:40 <bknudson> would be nice to see an example for X-Auth-Token , since that's pretty common.
21:26:41 <jroll> sigmavirus24: I don't think anyone reasonably building an application against an API would just wildly guess at header names, but that might just be me
21:27:13 <devananda> bknudson: ++
21:27:18 <sigmavirus24> jroll: so given some services use it to transmit arbitrary metadata, that's exactly how some clients work
21:27:19 <edleafe> jroll: you don't? I do that for fun all the time!  :)
21:27:23 <elmiko> agreed, bknudson +1
21:27:37 <sigmavirus24> jroll: this won't change that for existing APIs, but will improve that in the future in general
21:27:47 <elmiko> these are some great comments, would folks mind capturing some of these in the review please =)
21:27:53 <fungi> definitely in favor of having solid examples of these relevant to our current services
21:27:53 <johnthetubaguy> so I have a feeling I should call time on this
21:28:08 <johnthetubaguy> elmiko: +1 lets get these in to review comments I guess
21:28:09 <sigmavirus24> fungi: we've been trying not to do that to avoid pointing fingers or appearing to "shame"
21:28:14 <jroll> sigmavirus24: ok, just asking the question :)
21:28:14 <jokke_> johnthetubaguy: +1 move on :D
21:28:15 <elmiko> thanks johnthetubaguy
21:28:18 <fungi> there's enough shame to go around
21:28:26 <sigmavirus24> fungi: don't disagree ;)
21:28:32 <johnthetubaguy> cools
21:28:46 <johnthetubaguy> so lets assume the other ones are all good, unless someone pipes up real soon
21:28:55 <dstanek> sigmavirus24: i'd love to see keystone examples, i don't mind the finger pointing at us
21:29:16 <sigmavirus24> dstanek: hah, fair enough
21:29:23 <johnthetubaguy> #topic Cross Project Specs
21:29:39 <johnthetubaguy> so I have looked up some of the cross project specs that are up
21:29:42 <johnthetubaguy> and need a look
21:29:51 <johnthetubaguy> #link https://review.openstack.org/#/c/205629
21:29:57 <johnthetubaguy> that is about no global admin
21:30:19 <johnthetubaguy> that seems like a sound concept
21:30:32 <elmiko> yea, +1
21:30:49 <johnthetubaguy> there is one that looks like it gets replaced by the SDK work:
21:30:56 <johnthetubaguy> #link https://review.openstack.org/#/c/202586
21:31:03 <johnthetubaguy> called: Uniform public methods for clients
21:31:36 <johnthetubaguy> anyways, here is the general link if you fancy a dig into some old ones
21:31:39 <johnthetubaguy> #link https://review.openstack.org/#/q/status:open+project:openstack/openstack-specs,n,z
21:31:51 <johnthetubaguy> although you all new that, but a link can be easier
21:31:58 <dstanek> ++ to no global admin
21:32:14 <johnthetubaguy> anyways, tpatil I think you added your request-id work to the agenda?
21:32:18 <tpatil> Hi
21:32:25 <tpatil> We have analyzed return types of each of the public method from 5 different python client libraries
21:32:30 <tpatil> python-glance, python-cinder, python-nova, python-neutron, python-keystone
21:32:31 <johnthetubaguy> #topic Return request-id to caller
21:32:35 <tpatil> All information is available in the google spreadsheet and etherpad
21:32:38 <johnthetubaguy> #link https://etherpad.openstack.org/p/request-id
21:32:40 <tpatil> #link: https://docs.google.com/spreadsheets/d/1al6_XBHgKT8-N7HS7j_L2H5c4CFD0fB8xT93z6REkSk
21:32:48 <tpatil> We have identified 3 more additional return types (string,boolean,generator) compared to the ones reported earlier
21:33:01 <tpatil> Had a issue with returning request id in generator return type, Doug suggested a solution to overcome this problem by writing a new wrapper class and implementing iterator protocol
21:33:16 <tpatil> We have solutions to all issues identified so far to return request id to the caller
21:33:38 <johnthetubaguy> tpatil: I know this is a lot more work, but it seems like it is a viable solution then?
21:34:01 <tpatil> johnthetubaguy: Yes, all concerns are addressed it seems
21:34:03 <bknudson> wrapt provides a object proxy -- http://wrapt.readthedocs.org/en/latest/wrappers.html -- was just looking at this today
21:34:08 <tpatil> Another thing I would like to bring to your attention is that request id is most needed when api returns anything >= 400 error code
21:34:16 <tpatil> python-cinderclient already has a mechanism to return request id in exception
21:34:20 <tpatil> #link: https://github.com/openstack/python-cinderclient/blob/master/cinderclient/exceptions.py#L87
21:34:30 <tpatil> IMO, we should first add request id in exception class in the rest of the python client libraries before start making changes to the rest of the return types
21:34:50 <tpatil> Based on all information available to date, we will modify the specs and upload it for review by end of this week
21:34:53 <johnthetubaguy> tpatil: sounds like a very good plan to me, at least, sounds like a great place to start
21:34:55 <jokke_> sounds like reasonable place to start
21:34:56 <bknudson> is adding request_id to the exception in the spec?
21:35:29 <tpatil> bknudson: Not yet, we will modify specs and upload it soon
21:35:43 <johnthetubaguy> #action tpatil to update request id spec with latest details
21:35:52 <bknudson> thanks!
21:36:03 <johnthetubaguy> cool, sounds like we have got a good path forward here
21:36:08 <johnthetubaguy> tpatil: any more questions?
21:36:22 <tpatil> johnthetubaguy: That’s all I wanted to update you at the moment
21:36:34 <johnthetubaguy> tpatil: awesome stuff, thank you for pushing on this :)
21:36:45 <johnthetubaguy> #topic Open discussion
21:36:46 * jokke_ is happy - this topic gets shorter each time :)
21:36:51 <johnthetubaguy> jokke_: +1
21:37:10 <johnthetubaguy> hey, so time to go wild, if you are feeling that way :)
21:37:50 <jokke_> Horizon, glance, searchlight having midcycles this week ... some x-proj collaboration going on there
21:38:04 <jungleboyj> jokke_: ++
21:38:23 <johnthetubaguy> good stuff
21:38:47 <jokke_> and just if someone missed
21:38:58 <jungleboyj> Cinder's meet-up is the 8/4 to 8/6 if anyone wants to come collaborate with us in Fort Collins!
21:39:05 <jokke_> we're removing that experimental Catalog & Index service api from glance
21:39:06 <jungleboyj> Fort Collins is awesome!
21:39:17 <jokke_> as in the one that became searchlight
21:39:50 <bknudson> how was the api marked experimental?
21:40:02 <thingee> Would like to bring up that Cinder, like Nova is having issues with Glance v2 http://lists.openstack.org/pipermail/openstack-dev/2015-July/070714.html
21:41:15 <dstanek> jungleboyj: sounds like fun, but too far of a drive for me
21:41:21 <thingee> I'm not sure if there is someone from the glance team that is available actively looking at cross project integration issues?
21:42:45 <jokke_> bknudson: It's status was marked EXPERIMENTAL instead of SUPPORTED or CURRENT ... enabling it also needed ack in config that it's experimental IIRC
21:42:51 <fungi> #link https://wiki.openstack.org/wiki/CrossProjectLiaisons#Inter-project_Liaisons
21:42:53 <fungi> thingee: ^
21:42:53 <thingee> nikhil_k: ^
21:43:34 <fungi> i think that's the closest list we have to such a thing
21:44:08 <thingee> fungi: yeah johnthetubaguy just actually showed me that today. that's pretty neat. I was hoping we could discuss a cross with glance and cinder.
21:44:27 <thingee> alright, I guess I'll go to the glance meeting then.
21:44:32 <johnthetubaguy> yeah, Nova side we don't really have v2 support, but there were some bugs reported when we used v1 and users used v2, although I have not dug deep into that
21:44:42 <jokke_> thingee: Thu 1400 ... welcome
21:45:05 <johnthetubaguy> I should head over there at some point soon too
21:45:58 <jokke_> https://etherpad.openstack.org/p/glance-team-meeting-agenda
21:46:08 <johnthetubaguy> thingee: the cross project thing is only really just getting going, help getting the most out of that would be great, not sure we have great patterns yet
21:46:12 <jokke_> if you wanna add yourselves into the agenda
21:46:18 <johnthetubaguy> cool, so I think we are about done
21:46:23 <johnthetubaguy> thanks for your time all
21:46:37 <jungleboyj> johnthetubaguy: Hopefully it can gain more momentum.
21:46:40 <johnthetubaguy> markmcclain is our host next week, I believe
21:46:40 <jokke_> thanks johnthetubaguy
21:46:48 <elmiko> thanks johnthetubaguy
21:47:13 <johnthetubaguy> jungleboyj: yeah, I want to push a bit further on the Nova related ones again soon
21:47:21 <johnthetubaguy> thanks all
21:47:24 <johnthetubaguy> #endmeeting