21:03:23 <SlickNik> #startmeeting crossproject
21:03:24 <ttx> jeblair: next time, bait them to write it in the first place, like I tricked the VMT to do
21:03:24 <openstack> Meeting started Tue Jun 23 21:03:23 2015 UTC and is due to finish in 60 minutes.  The chair is SlickNik. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:03:26 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:03:28 <SergeyLukjanov> o/
21:03:28 <openstack> The meeting name has been set to 'crossproject'
21:03:29 <notmyname> hellow
21:03:32 <tpatil> o/
21:03:33 <dhellmann> o/
21:03:33 <jokke_> o/
21:03:37 <docaedo> o/
21:03:38 <bknudson> hi
21:03:40 <ttx> o/
21:03:41 <johnthetubaguy> o/
21:03:43 <elmiko> o/
21:03:47 <ttx> SlickNik: thx for chairing !
21:03:50 <SlickNik> courtesy ping for david-lyle flaper87 dims ttx johnthetubaguy rakhmerov
21:03:50 <SlickNik> courtesy ping for smelikyan morganfainberg bswartz slagle adrian_otto mestery
21:03:51 <SlickNik> courtesy ping for kiall jeblair thinrichs j^2 stevebaker mtreinish Daisy
21:03:51 <SlickNik> courtesy ping for notmyname dtroyer isviridov gordc SlickNik cloudnull
21:03:51 <SlickNik> courtesy ping for loquacities thingee hyakuhei redrobot TravT emilienm
21:03:52 <SlickNik> courtesy ping for SergeyLukjanov devananda boris-42 nikhil_k
21:03:56 <dtroyer> o/
21:03:56 <Rockyg> o/
21:04:00 <david-lyle> o/
21:04:03 <SergeyLukjanov> o/
21:04:04 <j^2> o/
21:04:13 <ttx> Volunteers welcome @ https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting#Chair_rotation
21:04:21 <devananda> \o
21:04:33 <stevebaker> \o
21:05:03 <SlickNik> Pretty packed agenda, so let's get started
21:05:06 <SlickNik> #topic Team announcements (horizontal, vertical, diagonal)
21:05:27 <dims> o/
21:05:47 <dhellmann> milestone tagging is going well this week
21:05:58 <dims> #info bunch of oslo releases today, timber!
21:06:18 <dhellmann> we still need to talk to stevebaker and kiall about heat and designate
21:06:26 <SlickNik> #info this is the liberty-1 milestone week — tagging is going well.
21:06:38 <ttx> dhelmmann and myself synced today with everyone but Heat (stevebaker) and Designate (Kiall)
21:06:40 <ttx> And we already tagged sahara, ceilometer, glance, cinder, trove and keystone
21:06:47 <ttx> We should cover the remaining ones in the next two days
21:07:00 <fungi> the oslo.db release switches the default mysql backend to pymysql, so i can go remove the temporary overrides everywhere for opportunistic detection to prefer pymysql
21:07:09 <dhellmann> fungi: ++
21:07:24 <SlickNik> nice, fungi
21:07:32 <dims> fungi: yay
21:07:44 <fungi> i think that was basically our last step on that switch? or we maybe still need grenade with the happymaking
21:07:57 <fungi> anyway, the end is in sight
21:08:33 * dhellmann does not use grenades for happy making
21:08:33 <fungi> whittling away at the neutron tests which broke on pymysql is likely longer tail
21:09:20 <SlickNik> Any other announcements before we move on to the next topic?
21:09:42 <SlickNik> .
21:10:08 <SlickNik> #topic Return request-id to caller (use thread local to store request-id)
21:10:14 <SlickNik> tpatil: around?
21:10:16 <tpatil> #link: https://etherpad.openstack.org/p/request-id
21:10:28 <tpatil> I have put my thoughts in this etherpad url
21:10:51 <tpatil> in the last glance meeting, Nikhil suggested us to talk with the cross project team about this topic.
21:11:33 <tpatil> Our users wants request id from python-*client so that they can approach to service provider to address their issues quickly
21:11:34 <hogepodge> o/
21:11:55 <dhellmann> tpatil: before you go making a bunch of changes to the client libs, I would like to understand how osprofiler is already doing this, because boris-42 has shown lots of demos of tracing a request through the entire system
21:12:10 <lifeless> There's a nuance here
21:12:16 <dhellmann> tpatil: the point of asking you to talk to them was to avoid having 2 ways of passing request ids around
21:12:26 <lifeless> this concern is 'how can users identify the problem request to the helpdesk'
21:12:49 <lifeless> the osprofiler one is 'how can devs/ops see what happened internally to the cluster' - a distributed call graph
21:13:00 <jokke_> ++
21:13:02 <lifeless> I think alignment and careful dot-joining is important
21:13:11 <dhellmann> lifeless: yes, right, that's what I'm asking for
21:13:16 <morganfainberg> lifeless: ++
21:13:18 <lifeless> but we should remember they are two use cases with very different security etc concerns
21:13:32 <dhellmann> we may in fact need 2 separate things, but I would hate to build 2 of the *same* thing
21:13:42 <lifeless> so - for my part, I'd like to see boris weigh in on this proposal
21:13:51 <jokke_> also listening ops, it sounds like they are not likely running osprofiler on their production environments, so I think it's bad idea to rely on osprofiler for request IDs
21:14:12 <Rockyg> jokke_: +1
21:14:28 <lifeless> jokke_: I don't see why - if you don't enable a component, you don't get what it does.
21:14:28 <morganfainberg> jokke_: the request Id part could be split out / made default even if osprofiler is off
21:14:40 <morganfainberg> If that is a real concern.
21:14:57 <morganfainberg> But I tend to agree with lifeless here.
21:15:03 <lifeless> jokke_: but - I haven't proposed relying on osprofiler, just saying, lets not throw it out without having the flk behind it in the room
21:15:03 <dhellmann> yeah, we could split it, but let's get someone to actually do the technical analysis of what both teams need and understand where the cross-over is before we start worrying about what the final implementation details are
21:15:12 <tpatil> Restful API return x-openstack-request-id so why not return it from client as well?
21:15:20 <johnthetubaguy> so right now, we give our users request-ids, its part of the REST API already right, in most cases at least, the client work is just returning it to users of the client right?
21:15:22 <dims> on oslo-incubator there was at least one review merged that saves last request id as part of this bug - https://bugs.launchpad.net/heat/+bug/1342922
21:15:23 <openstack> Launchpad bug 1342922 in heat "request id not captured" [Medium,Triaged]
21:15:38 <dims> https://review.openstack.org/#/c/117493/ - but no one is using that
21:15:42 <johnthetubaguy> tpatil: so thats what I was just thinking here
21:15:43 <lifeless> johnthetubaguy: that makes the scope nice and small and I entirely support showing that to users.
21:15:47 <SlickNik> dhellmann: I agree. Seems like some discovery / analysis is required here.
21:15:57 <dhellmann> johnthetubaguy: so we're already returning this data?
21:16:08 <johnthetubaguy> nova certainly is, as I understand it
21:16:10 <morganfainberg> This could also mostly be rolled into session object and just displaying the details on the request like johnthetubaguy indicated.
21:16:11 <lifeless> dhellmann: not everywhere AIUI, but many places
21:16:18 <johnthetubaguy> the REST API already returns request-ids
21:16:31 <johnthetubaguy> lifeless: right, not everyone is yet
21:16:46 * lifeless thinks
21:16:48 <dhellmann> johnthetubaguy: cool, so then maybe part one of the work is just a matter of agreeing on the API for the clients to return that to callers that want it
21:16:49 <morganfainberg> As long as the api returns the id, it's easy.
21:17:13 <jokke_> dhellmann: I like the idea of analyzing, but the situation seems to be that tpatil and guys are pretty much trying to implement something now. And I don't blame them looking how long this bikeshedding has been going on
21:17:14 <lifeless> osprofiler is server side. Insofar as the changes are just client side, I see no reason to force a discussion. Its noddy.
21:17:14 <dhellmann> and file bugs for the APIs that aren't, and implement the return the same way everywhere
21:17:35 <dhellmann> jokke_: I hardly think this is bikeshedding.
21:17:38 <johnthetubaguy> so previous discussions hit a road block when the services start requesting the callers request-id, thats the bit thats new
21:17:45 <Rockyg> dhellmann: lifeless: +1
21:17:49 <dims> have we standardized the rest api header?
21:17:53 <lifeless> Insofar as there's a defacto standard amongst some N existing APIs, I think propogating that across all openstack APIs is also sane
21:18:02 <lifeless> but the API WG is where we should have that discussion.
21:18:13 <tpatil> python-openstacksdk team agreed to add this support
21:18:13 <morganfainberg> lifeless: +
21:18:16 <tpatil> #link: #link: https://bugs.launchpad.net/python-openstacksdk/+bug/1465817
21:18:17 <openstack> Launchpad bug 1465817 in OpenStack SDK "Provide method to get latest request id" [Medium,Confirmed]
21:18:21 <johnthetubaguy> +1 for an API WG spec on the header
21:18:22 <dhellmann> lifeless: I agree, though I'm ok with going ahead with a defacto standard in the mean time
21:18:42 <dims> 'x-openstack-request-id' is what's in the oslo-incubator review above
21:19:07 <lifeless> dhellmann: me too, but I don't want to diminish the WG's momentum
21:19:11 <bknudson> http://git.openstack.org/cgit/openstack/oslo.middleware/tree/oslo_middleware/request_id.py#n23
21:19:17 <dhellmann> lifeless: ok
21:19:20 <bknudson> oslo.middleware uses x-openstack-request-id
21:19:22 <morganfainberg> dims: i only request we drop "x-" based on the Rfc recommendation to not "x-<header>" anymore
21:19:34 <morganfainberg> If we can easily change that.
21:19:35 <elmiko> morganfainberg: +1
21:19:37 <dims> morganfainberg: works for me
21:19:44 <morganfainberg> If it isn't easy to change then keep it x-
21:19:46 <SlickNik> #link http://git.openstack.org/cgit/openstack/oslo.middleware/tree/oslo_middleware/request_id.py#n23
21:19:56 <lifeless> morganfainberg: we already have the x- in lots of use
21:20:02 <lifeless> morganfainberg: a transition should be discussed separately IMO
21:20:16 <johnthetubaguy> I think the ship has sailed though, given we have users relying on these headers where they exist already, but thats something for a different conversation
21:20:19 <morganfainberg> lifeless: we do. If we are adding a new things we should do new thing right. Was my point.
21:20:26 <morganfainberg> If it already is there don't change it.
21:20:26 <dhellmann> ok, so I think we're agreeing that part 1 of updating clients to return the value is safe, and that we want all services to use the same header, and the API WG should be involved in setting that but since we have a pretty strong standard already we would expect them to codify it?
21:20:50 <lifeless> they could codify it and also design the transition logic at the same time, for instance.
21:20:50 <morganfainberg> Not worth a headache. But if it isn't used/in place we can do it "right"
21:20:51 <dhellmann> the step 2 from the etherpad is more where I'm concerned with osprofiler cross-over
21:21:07 <dhellmann> lifeless: that would be fine
21:21:31 <lifeless> so tpatil whats step 2 about
21:21:37 <lifeless> tpatil: like, whats the goal
21:21:51 <tpatil> first we want to achieve step 1
21:22:01 <Rockyg> pretty much a linked list of ids I think
21:22:08 <tpatil> Step 2, We are ok to work how osprofiler fits in here.
21:22:11 <lifeless> ok
21:22:15 <dhellmann> ok
21:22:17 <lifeless> so lets put a pin in step 2 and defer it
21:22:23 <tpatil> Is it possible to link trace_id with x-openstack-request-id?
21:22:29 <johnthetubaguy> so the step 2 is the bit I really want to see, when wearing my large operator hat, log messages that link the requests as they flow between projects
21:22:32 <tpatil> lifeless: ok
21:22:36 <lifeless> when you've had time to discuss with boris we can come back to it
21:22:44 <lifeless> johnthetubaguy: have you tried osprofiler?
21:22:47 <johnthetubaguy> (and ideally notifications along with the logs)
21:22:50 <lifeless> johnthetubaguy: since it does that ...
21:23:13 <johnthetubaguy> lifeless: no, mostly due the perceived overhead for running it in production
21:23:14 <Rockyg> johnthetubaguy: +1 on notifications
21:23:34 <dhellmann> yeah, osprofiler I think does a lot of that, but it may do some things we *don't* want so we may want to break that up into pieces to let them be consumed separately
21:23:38 <lifeless> johnthetubaguy: ok - so I think we need to do a deep dive on that with boris.
21:23:41 <jroll> lifeless: it's not recommended to run osprofiler on every request. only a small subset.
21:23:46 <johnthetubaguy> lifeless: now thats not a good answer, but its the truthful one
21:23:57 <lifeless> johnthetubaguy: hah :)
21:24:00 <Rockyg> Yeah.  No ops guy wants to run something named *profiler in production
21:24:06 <lifeless> jroll: thats from production experience?
21:24:15 <jroll> lifeless: that's boris' intended use case
21:24:18 <morganfainberg> Rockyg: yes.
21:24:21 <lifeless> Rockyg: we can rename it if thats the thing, but we're about to rathole.
21:24:32 <johnthetubaguy> so back to requirements
21:24:33 <SlickNik> #info Step 1 in https://etherpad.openstack.org/p/request-id seems reasonable - don't tackle step 2 without more information about osprofiler / communication with boris
21:24:37 <lifeless> Rockyg: very big clouds (Google scale) run nearly the exact same thing all the time
21:24:37 <dhellmann> it sends notifications right? so we would want to split that off from the thing that handles the request ids
21:24:42 <dhellmann> SlickNik: ++
21:24:47 <dhellmann> before we move on...
21:24:47 <Rockyg> The key is that the RId has to be low impact process
21:24:55 <dhellmann> let's talk process, because I want to raise the issue that the cross-project spec was rejected but the team went off and submitted specs to individual projects. I'm not sure I like the bypass that appears to be.
21:25:00 <johnthetubaguy> when my nova boot fails due to a cinder volume create issue, I want to find the cinder logs from the nova request id my user knows about, and I find in my Nova API logs
21:25:24 <johnthetubaguy> s/when my nova/when my customers nova/
21:25:25 <dhellmann> johnthetubaguy: the request chaining that osprofiler provides should allow that, if we push the request id chain down to the logs
21:25:37 <morganfainberg> dhellmann: some of those specs predated cross project specs.
21:25:40 <jroll> lifeless: I told boris I want something to collect metrics on every request, he said I sohuld not do that :)
21:25:41 <morganfainberg> dhellmann: FYI
21:25:56 <lifeless> jroll: ok, I think boris is perhaps boris' worst enemy.
21:26:02 <dhellmann> morganfainberg: ok, still.
21:26:08 <SlickNik> dhellmann: That's interesting — do we have a process in such a case?
21:26:15 <jroll> lifeless: you realize it puts hundreds of messages on the rabbit bus for each request?
21:26:26 <johnthetubaguy> dhellmann: agreed, I was just trying to state the use case I care about, (and its perceived that profiler is too heavy weight to do that for all requests, which is what I need here)
21:26:35 <dhellmann> SlickNik: no, that's why I raised the point. There was a good faith expectation that the cross-project spec would take precedence, since the discussion was already going on there.
21:26:40 <lifeless> jroll: its also modular enough to change that fairly easily.
21:26:46 <dhellmann> johnthetubaguy: yep, we'll solve that
21:26:58 <lifeless> jroll: I want to take 'internals of osprofiler' offline from this meeting.
21:27:03 <tpatil> dhellmann: Based on inputs we received from different teams, we took the decision to create bp in the individual python-*client projects.
21:27:03 <jroll> lifeless: fair
21:27:26 <Rockyg> tpatil: did you reference it in the spec?
21:27:29 <dhellmann> tpatil: yes, that's what I'm objecting to. What would you have done if those teams had decided independently that they wanted different things?
21:27:30 <morganfainberg> tpatil: this just to display back to the user, right?
21:27:31 <SlickNik> dhellmann: usually I'd expect the vertical teams to push the spec back to the cross-project repo / meeting since it does have a wider impact, but I'm not sure if we have any other process here.
21:27:35 <jokke_> dhellmann: SlickNik: Specially as IIRC when the x-project specs were started it was agreement that we move this discussion from the individual specs to the x-project one
21:27:43 <tpatil> dhellmann: Not yet, but we will do that
21:28:08 <morganfainberg> jokke_: ++
21:28:09 <dhellmann> tpatil: I'm not sure how to interpret that as an answer to my question, were you replying to Rockyg ?
21:28:16 <morganfainberg> jokke_: that was my understanding.
21:28:31 <dhellmann> SlickNik: yes, but I don't necessarily expect the foo-drivers to be aware of the cross-project specs
21:28:55 <fungi> though it would be really great if they were
21:29:00 <dhellmann> tpatil: my question was, "What would you have done if those teams had decided independently that they wanted different things?"
21:29:10 <dhellmann> fungi: yes, I would love that world
21:29:26 <Rockyg> dhellmann: that's the issue in a nutshell.  xproject doesn't have the visibility it needs
21:29:35 <dhellmann> tpatil: I'm raising the issue to make sure we all understand the process, not to point fingers at you for doing something wrong.
21:29:37 <thingee> dhellmann: the ptl or liaison should be aware of cross project spec to raise it in individual project specs. It has happened many times in cinder.
21:29:58 <tpatil> dhellmann: May be we have interpreted differently from different groups. Please let us know what is required to fix these issues. we will follow on that path.
21:30:04 <dhellmann> thingee: agreed; did that happen, or were these specs approved in the projects?
21:30:16 * thingee apologizes for late response. Cell service is bad
21:30:58 <Rockyg> thingee: +1 all ptls of projets concerned with a xproject spec should be on the review list
21:30:59 <dhellmann> tpatil: My preference would be for you to wait for the cross-project spec to be resolved before proceeding with working on code, or specs within the projects, to avoid different implementations from being out of sync.
21:31:28 <thingee> dhellmann: assuming you're talking about cinder and the request id spec, I think I've already raised this needs to be approved cross project first already.
21:31:50 <dhellmann> thingee: I wasn't actually talking about any project in particular, but that's good to hear.
21:31:52 <tpatil> dhellmann: ok
21:32:04 <bknudson> a single keystoneclient API call could cause multiple requests, e.g., if you have to refresh the token. So I'm not sure how to return "the" request id.
21:32:08 <dhellmann> really, I'm not complaining about *this* spec, I'm trying to make sure we have a common understanding of the process in general
21:32:21 <jokke_> I also said on the Glance meeting last week that we should resolve the x-project one before starting to implement anything in the project
21:32:29 <dhellmann> bknudson: great point, maybe it should be a list
21:32:34 <dhellmann> jokke_: ok, good
21:32:47 <thingee> dhellmann: is there a particular example of this happening you're talking about?
21:32:49 <dhellmann> maybe my concern is unfounded, and this is proceeding as expected -- I thought these other specs were approved
21:33:10 <Rockyg> So, question is:  should the client side be in same xproject spec or can it be a link to another xproject spec?
21:33:23 <jokke_> but I don't know how many driver actually cross checks specs proposed to other projects/x-project specs
21:33:49 <johnthetubaguy> dhellmann: bknudson: I am confused, the caller just returns a unique id for that specific API call, inside it it knows the other related request ids right,, and logs them and sends notifications, I didn't think they got returned to the end user too?
21:34:10 <Rockyg> If they can be accomplished independently, I would think link and sub spec could be approved independent of master?
21:34:21 <SlickNik> Okay, we need to call time on this and move on to the next item.
21:34:23 <bknudson> johnthetubaguy: this is step 1 of https://etherpad.openstack.org/p/request-id -- changing the client libs to return the request id.
21:34:26 <dhellmann> johnthetubaguy: I think bknudson means if you have a long-lived keystone client it might end up making multiple requests as you use it
21:34:43 <SlickNik> tpatil: It looks we have concrete next steps here of driving this through the x-project specs?
21:35:00 <SlickNik> to standardize on the approach
21:35:02 <johnthetubaguy> dhellmann: ah, good point, now I get you both
21:35:36 <tpatil> SlickNik: I will wait for cross specs to be approved
21:35:39 <Rockyg> tpatil: just consider yourselves the guinea pig that will help all that follow behind ;-)
21:35:41 <bknudson> I could do keystoneclient.list_users(), and it calls keystone to get a token and then calls keystone to get the user list.
21:35:51 <dhellmann> SlickNik, tpatil : do we need a new version of the cross-project spec so we can formally approve that? or is the current draft up to date with the plan we've agreed to here today?
21:36:04 <dhellmann> bknudson: good point
21:36:33 <dhellmann> bknudson: if this is meant to be used for debugging failures, maybe we only care about the last request made, still?
21:36:35 <tpatil> dhellman: I think we need a new version here.
21:36:46 <lifeless> query bknudson https://review.openstack.org/#/c/186635/ <- done the edits asked for
21:36:48 <dhellmann> if the token request fails, we'll have that id and if the list call fails we'll have that id
21:36:51 <SlickNik> #topic New API Guidelines ready for cross project review
21:36:53 <morganfainberg> dhellmann / bknudson: or not the auth request.
21:37:19 <bknudson> dhellmann: y, that makes sense... maybe a simple function just gets the last call and another function returns all calls
21:37:20 <dhellmann> tpatil: ok, I'll watch for the update
21:37:25 <lifeless> so there's design work on how to expose that in the client
21:37:36 <lifeless> the sdk and the python apis on the clients should all be the same here
21:37:45 <tpatil> dhellman: sure, we will update it soon.
21:37:47 <lifeless> I think - I want to see that in an actual cross project spec
21:37:51 <elmiko> not sure if etoews is around, but we have the 3 guidelines posted in the agenda for reference https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting#Proposed_agenda
21:37:57 <SlickNik> Looks like this topic is primarily for cross-project visibility
21:38:03 <elmiko> yea
21:38:05 <etoews> o/
21:38:35 <elmiko> etoews, did you have anything specific to add about the guidelines up for freeze?
21:38:40 <SlickNik> etoews: anything you'd like to add here?
21:38:53 <SlickNik> #link https://review.openstack.org/#/c/177468/
21:38:54 <etoews> nope. just getting these in front of the CPLs.
21:39:02 <SlickNik> #link https://review.openstack.org/#/c/181931/
21:39:19 <SlickNik> #link https://review.openstack.org/#/c/183599/
21:39:25 <elmiko> thanks SlickNik
21:39:33 <etoews> they'll also been added as individual reviews on the guidelines too. the more viz the better.
21:39:43 <etoews> s/reviews/reviewers/
21:39:50 <lifeless> jaypipes: https://review.openstack.org/#/c/183599/ is internally inconsistent
21:39:55 <lifeless> jaypipes: I've comemnted on it
21:40:27 <etoews> thx lifeless
21:40:33 * nikhil_k back from appt
21:40:36 <SlickNik> Sounds good. etoews jaypipes et al.: Thanks for putting this together!
21:40:49 <etoews> this will be a weekly thing. ;)
21:41:10 <SlickNik> #topic Add requirements management specification.
21:41:14 <thingee> ameade: ^
21:41:22 <SlickNik> #link https://review.openstack.org/#/c/186635/
21:41:48 <lifeless> ^ I want +A's plox :)
21:42:17 <lifeless> its been discussed here for visibilty a couple weeks ago and only cosemtic change requests received
21:43:58 <morganfainberg> lifeless: sorry I can only +1 so hard. :P
21:44:15 <jokke_> lifeless: I do not have powar for +a, but ye got my +1 ;)
21:44:20 <SlickNik> lifeless morganfainberg: ++
21:44:39 <dhellmann> if we get enough +1 on record we can put it on the tc meeting agenda for next week
21:45:24 <dhellmann> PTLs or liaisons should read that carefully, though, to understand how big of a change it is going to be
21:45:44 <SlickNik> Any more questions on this?
21:46:04 <Rockyg> yeah.  The devil is in the details here.
21:46:09 <SlickNik> .
21:46:11 <jokke_> lifeless: we will haunt ye really bad if that does not solve the issue 'thoug :P
21:46:13 <hogepodge> who manages upgrading pins?
21:46:23 <SlickNik> #topic Open Discussion
21:46:37 <Rockyg> o/
21:46:39 <lifeless> hogepodge: we all do
21:46:48 <nikhil_k> Also, should the security related upgrade pins be handled separately ?
21:47:03 <dhellmann> nikhil_k: how separately?
21:47:08 <hogepodge> lifeless: from personal experience, it's painful. More painful than world breaking? Don't know
21:47:09 * ttx reapplies vote
21:47:29 <hogepodge> clarkb: has good views on that, and has be waffling on the idea fwiw
21:47:38 <Rockyg> Need to ad a repository for use cases managed by Product_wg, and dhellmann suggested a new file in the governance repository, but I was thinking perhaps a file to encompass all wgs rather than just Product?
21:47:41 * SlickNik is back after a network hiccup
21:47:49 <nikhil_k> dhellmann: dedicated team that involves laisons from all concerned projects
21:48:10 <hogepodge> Related to my api topic from last week, there's a really good mailing list thread about glance v1/v2 upgrade on defcore mailing list
21:48:11 <hogepodge> http://lists.openstack.org/pipermail/defcore-committee/2015-June/000823.html
21:48:17 <hogepodge> #link http://lists.openstack.org/pipermail/defcore-committee/2015-June/000823.html
21:48:21 <dhellmann> Rockyg: we already have some other working groups with their own files, so maybe start with a new one for your repo and then a second patch to merge those together into one file? that way we can address the 2 questions separately
21:48:22 <fungi> hogepodge: i think long-term we want a periodic job which spots new releases of things and tries to run tests with the cap bumped
21:48:30 <lifeless> hogepodge: there's a cron job to propose pin changes
21:48:34 <hogepodge> fungi: ++
21:48:37 <lifeless> hogepodge: we just need to +2 +A it
21:48:44 <nikhil_k> but that still is a bit unworthy if the libs that need upgrades are not in openstack control (transient)
21:48:45 <Rockyg> thanks, dhellmann.  wfm
21:49:07 <lifeless> fungi: we hve that job
21:49:11 <fungi> nikhil_k: the idea is that we add them all to the new requirements list, transitive or no
21:49:16 <lifeless> fungi: its in the spec, and its in infra puppet already
21:49:29 <fungi> lifeless: true, that's the constraints job
21:49:42 <lifeless> fungi: we don't need transitive things in requirements. constraints will pick them up automatically.
21:49:43 <hogepodge> lifeless: I loved working with maven and pinning dependencies in a previous life when I did Java. I also had to schedule time into my milestones for upgrades.
21:49:57 <lifeless> hogepodge: sure
21:50:17 <lifeless> hogepodge: we've 1000 folk hacking on openstack, doing it randomly with no testing is just unconsiconable
21:50:17 <SlickNik> hogepodge: yes, it's difficult to eat your cake and have it too :)
21:50:24 <jokke_> hogepodge: """* use glance v2 (only just released, not really deployed anywhere)""" is interesting statement :P
21:50:30 <nikhil_k> fungi: yeah, I worried about convergence speed vs. security risk more subjectively so, not pushing hard. it's a food for thought :)
21:50:31 <ttx> hogepodge: you used "love" and "maven" in the same sentence there
21:50:52 <lifeless> https://review.openstack.org/#/q/status:open+project:openstack/requirements+branch:master+owner:lifeless,n,z <-
21:51:01 <lifeless> thats the top of the implementation stack if you're interested
21:51:03 <hogepodge> ttx: I feel no shame. I also migrated to clojure and life was amazing
21:51:11 * ttx closes eyes
21:51:11 <morganfainberg> ttx: where is hogepodge and what happens to him. No one can say love and maven and mean it.
21:51:47 <Rockyg> hogepodge may be a lost soul ;-)
21:52:16 <Rockyg> But, back to the glance discussion hogepodge brought up?
21:52:21 <ttx> someone must have overtaken his IRC account
21:52:56 * ttx likes to disrupt this meeting, but only when he is not chairing it :)
21:52:57 <hogepodge> ttx I upgraded my password from 'password123' to my dog's name, so I don't know how that could have happened
21:52:58 <SlickNik> Any other items for Open Discussion?
21:53:35 <Rockyg> #link http://lists.openstack.org/pipermail/defcore-committee/2015-June/000823.html
21:53:36 <SlickNik> If not we can call this a meeting and figure out a way to get hogepodge back. :)
21:53:43 <Rockyg> the glance/defcore issue
21:53:53 <hogepodge> srsly, the defcore mailing list item is a good read, and I think I may cross post it to dev
21:54:02 * nikhil_k will respond
21:54:04 <johnthetubaguy> so this was mostly me ranting about image uploads
21:54:21 <ttx> hogepodge: I think it's relevant there, at least a summary of it
21:54:24 <johnthetubaguy> nikhil_k: I cced you in there, would love feedback on accuracy of my statements
21:54:32 <nikhil_k> aye
21:54:48 <johnthetubaguy> basically, I don't see nova supporting glance v2 as a blocker to devcore doing what it wants
21:54:59 <ttx> johnthetubaguy: not just you. I heard mordred there too
21:55:26 <johnthetubaguy> nova has a v1 image API, because we had to, and glance v1 wasn't designed to be exposed to end users
21:55:35 <Rockyg> ttx: but mordred was moaning about glane and *so* much more
21:55:38 <hogepodge> In my perfect world, nova supports both and it's a complete non-issue. I want to help move that forward.
21:55:43 <johnthetubaguy> we would love to delete that, but know thats now almost impossible
21:55:52 <johnthetubaguy> its used to much
21:56:13 <johnthetubaguy> hogepodge: so I don't think thats at all relevant, but as I said, I might be missing something
21:56:32 <jokke_> hogepodge: you're probably flaper87's new best friend with that statement
21:56:38 <johnthetubaguy> now its something we have wanted in Nova for a long time, but the work has just not been completed yet
21:56:51 <johnthetubaguy> the bigger question is
21:57:05 <hogepodge> johnthetubaguy: we test the nova proxy to glance, as glance isn't directly a required component
21:57:08 <fungi> so the concern, as i recall it, was that to test the cloud tempest first wants to be able to upload an image into it and then boot from that. so i guess the suggestion is to upload via glance v2 if present, then try v1 if not?
21:57:10 <johnthetubaguy> we need a single API to list images and upload and download images
21:57:16 <jokke_> johnthetubaguy: just quick correction. Image API v2 has been around for couple of years, the work for nova to consume it, is quite recent
21:57:35 <johnthetubaguy> hogepodge: the proxy will only ever support v1, but I don't see how that blocks people
21:57:49 <hogepodge> a way forward may be to just require glance capabilities, then allow switching between v1 and v2'
21:58:01 <dhellmann> why does nova need to consume glance v2 for it to be present and useful in the cloud for testing?
21:58:05 <johnthetubaguy> jokke_:agreed its been around, I was told it only got released as such in kilo, which surprised me
21:58:09 <hogepodge> johnthetubaguy: if we're ok with vendors having to implement v1, even if only privately for nova
21:58:14 <dhellmann> hogepodge: can't we just say "expose glance v2, that's the public API"?
21:58:14 <johnthetubaguy> dhellmann: thats my point
21:58:28 <nikhil_k> v2 work in nova isn't recent, fyi
21:58:40 <hogepodge> dhellmann: see proxy and capabilities clause. right now, nova api is required for images for defcore
21:58:43 <nikhil_k> it's complicated (can be)
21:58:54 <hogepodge> dhellmann: that can be changed, though.
21:59:00 <dhellmann> hogepodge: yes, I think that's exactly what we're saying: glance has 2 APIs, one is private one is public, you need both
21:59:02 <hogepodge> with enough input
21:59:03 <jokke_> johnthetubaguy: oh :P ... I think that's someone taking the fact bit wrong that _both_ of the API's were marked current and we changed v1 to Supported only in kilo after realizing that
21:59:04 <nikhil_k> and can you have openstack w/o glance, huh
21:59:08 <dhellmann> I mean, it's the same API process, right?
21:59:09 <mtreinish> hogepodge: which honestly is something that never made sense to me
21:59:26 <hogepodge> mtreinish: we had to start somewhere
21:59:40 <SlickNik> Okay, we're at the hour — so we'll have to continue the conversation after the meeting.
21:59:49 <hogepodge> mtreinish: One of my bigger concerns is the disconnect between tests and endpoints.
21:59:59 <SlickNik> But that's it for today's cross project meeting.
22:00:05 <dhellmann> hogepodge: yes, I think we should encourage defcore to not use nova's proxy APIs for anything where there is a public API in another project. So that wasn't the case before, but now it is, so...
22:00:21 <SlickNik> #endmeeting