17:00:20 <ildikov> #startmeeting cinder-nova-api-changes
17:00:20 <openstack> Meeting started Thu Mar 16 17:00:20 2017 UTC and is due to finish in 60 minutes.  The chair is ildikov. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:21 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:23 <openstack> The meeting name has been set to 'cinder_nova_api_changes'
17:00:34 <lyarwood> o/
17:00:34 <mriedem> o/
17:00:35 <ildikov> DuncanT ameade cFouts johnthetubaguy jaypipes takashin alaski e0ne jgriffith tbarron andrearosa hemna erlon mriedem gouthamr ebalduf patrickeast smcginnis diablo_rojo gsilvis  xyang1 raj_singh lyarwood breitz
17:00:48 <jungleboyj> o/
17:01:05 <johnthetubaguy> o/
17:01:07 <jgriffith> o/
17:01:18 <hemna> \o
17:01:28 <ildikov> hi All :)
17:01:34 <jungleboyj> In two meetings at the moment.  So, will do what I can.  :-)
17:01:40 <ildikov> let's start
17:01:45 <ildikov> jungleboyj: noted, tnx
17:01:54 <ildikov> so news on action items
17:02:07 <ildikov> Switch to Cinder v3 merged successfully
17:02:14 <jungleboyj> Yay!
17:02:22 <ildikov> #info Switch to Cinder v3 merged successfully in Nova
17:02:39 <ildikov> #info Cinder client 2.0.1 is released
17:02:52 <mriedem> has g-r been bumped?
17:02:59 <ildikov> #info global-requirements is bumped to use 2.0.1
17:03:14 <ildikov> mriedem: the patch was on the gate an hour ago, when I checked
17:03:15 <mriedem> no it hasn't https://github.com/openstack/requirements/blob/master/global-requirements.txt#L222
17:03:17 <mriedem> oh
17:03:18 <mriedem> ok
17:03:34 <ildikov> mriedem: so it should land any minute, but will double check after the meeting
17:03:54 <ildikov> I have the patch up to mark Cinder v2 support deprecated in Nova
17:04:02 <ildikov> small item, does not block anything
17:04:35 <ildikov> jgriffith has a patch up for version detection: https://review.openstack.org/#/c/444465/
17:04:53 <ildikov> mriedem: johnthetubaguy: lyarwood: please take a look whether the direction looks good ^^
17:05:20 <johnthetubaguy> non of these were listed in here: https://etherpad.openstack.org/p/pike-nova-priorities-tracking
17:05:21 <mriedem> we don't want the latest
17:05:24 <mriedem> i'll leave a comment
17:05:24 <johnthetubaguy> so it was hard to find
17:05:35 <johnthetubaguy> I added that one
17:05:44 <ildikov> basically we need to agree whether we are fine with the highest available microversion or not
17:06:01 <ildikov> johnthetubaguy: tnx
17:06:02 <mriedem> we do not want the latest
17:06:08 <jgriffith> mriedem ?
17:06:09 <mriedem> the client opts in to the version it knows how to understand
17:06:12 <mriedem> i'm leaving a comment
17:07:01 <ildikov> I wonder what can go wrong with the latest mv
17:07:20 <ildikov> as if it's not high enough we will fall back to the old flow anyhow
17:07:36 <mriedem> i left a comment
17:07:41 <mriedem> the client always opts in to a microversion
17:07:44 <mriedem> not the latest
17:08:06 <mriedem> because my client side code could know how to deal with a 3.26 response, but not a 3.40 response if the server changes something in 3.40
17:08:07 <jgriffith> mriedem yeah, that's fine
17:08:20 <johnthetubaguy> right I was expecting us to use either 3.0 or 3.27
17:08:24 <jgriffith> mriedem it's 3.27
17:08:27 <mriedem> johnthetubaguy: ok, yeah
17:08:33 <mriedem> right, 3.0 or 3.27
17:08:45 <mriedem> if at some point we need something higher than 3.27, we deal with that on a case by case basis
17:08:50 <jgriffith> I'll adjust the patch
17:08:54 <ildikov> mriedem: fair enough
17:08:54 <mriedem> thanks
17:09:38 <ildikov> I think that was the only question to this one
17:09:38 <jgriffith> mriedem note that that patch doesn't actually "set" any version anyway :)
17:09:48 <jungleboyj> I commented on the spec that 3.27 is the one you are looking for.
17:09:51 <jgriffith> it just gives a way to determine what's available
17:10:17 <jgriffith> The actual set/use is left for when we add "new" methods
17:10:18 <mriedem> jgriffith: it creates the cinderclient with that version though
17:10:22 <johnthetubaguy> yeah, spec is all updated now
17:10:24 <mriedem> version = _MAX_AVAILABLE_CINDER_VERSION
17:10:28 <mriedem> return cinder_client.Client(version,
17:11:10 <johnthetubaguy> so right now I assume we just hit the attribute error in the gate, so we always use v2 or somethhing?
17:11:22 <johnthetubaguy> I was expecting it to pick 2.27, then have everything break I guess
17:11:27 <johnthetubaguy> 3.27 oops
17:12:32 <jgriffith> mriedem johnthetubaguy ok.. so I think the best course is to set to 3.0 and specify requested higher mv if supported in the calls we need/want it explicity
17:12:43 <jgriffith> mriedem johnthetubaguy agree/disagree?
17:13:15 <johnthetubaguy> so lets wind forward
17:13:18 <jgriffith> mriedem johnthetubaguy my point being that we don't want 3.0 - 3.27 for every possible interaction
17:13:23 <johnthetubaguy> if the code supports both 3.27 and 3.0
17:13:40 <johnthetubaguy> we would check which code path was required, based on the cloud we were pointing at
17:13:53 <johnthetubaguy> then every call is either 3.0 or 3.27
17:14:03 <jgriffith> johnthetubaguy I don't think you want that
17:14:15 <johnthetubaguy> actually we went through this in the spec
17:14:19 <jgriffith> ok
17:14:19 <johnthetubaguy> it depends on the BDM
17:14:44 <mriedem> jgriffith: i assume the plan was to check the global and if it's >=3.27, use new volume_api methods like create_attachment, else fallback to old stuff
17:14:46 <johnthetubaguy> so yeah, each call needs to opt into the version, ideally after checking if that version is available
17:14:53 <jgriffith> mriedem that's correct
17:14:59 <johnthetubaguy> mriedem: thats what I am trying to say, and failing
17:15:00 <jungleboyj> I didn't particularly like that part of the spec, but don't have a better idea there.
17:15:18 <mriedem> jungleboyj: what's not to like?
17:15:21 <jgriffith> mriedem my intention was "use 3.0". if 3.27 use new attach and explicitly call3.27 for just those attach/detach methods
17:15:27 <mriedem> the client needs to know if it can make a certain request
17:15:46 <mriedem> jgriffith: but we still need to know if 3.27 is available, right?
17:15:58 <jgriffith> mriedem and add for additional calls as needed/desired as we go in the future
17:16:06 <jungleboyj> The fact that we can't count on all the compute nodes being able to support doing 3.27 and having to check it.
17:16:07 <jgriffith> ok... yes, I think we're on the same page then
17:16:22 <mriedem> jungleboyj: it's not the computes, it's the cinder api
17:16:27 <mriedem> jungleboyj: plus, rolling upgrades
17:16:47 <jgriffith> haven't we had this debate a couple times already?
17:16:48 <jungleboyj> mriedem:  Ok.
17:16:50 <johnthetubaguy> jgriffith: maybe rebase your detach API patch on top, that might clear this up
17:16:52 <mriedem> we don't 'count' on everything in the deployment being the latest and greatest when the code runs
17:17:03 <jgriffith> johnthetubaguy good idea
17:17:03 <mriedem> jgriffith: yes, but jungleboyj wasn't around then
17:17:13 <jgriffith> ahh.. history lesson :)
17:17:20 <mriedem> yeah so we're on the same page i think
17:17:25 <mriedem> we can move ahead
17:17:26 * jungleboyj will be quiet.
17:17:29 <jungleboyj> :-)
17:17:36 <johnthetubaguy> there is a bit we punted on in the spec
17:17:37 <jgriffith> jungleboyj nah, better to raise the questions
17:17:42 <johnthetubaguy> migrating old style BDMs to the new API
17:17:51 <jgriffith> johnthetubaguy damn you! :)
17:17:51 <mriedem> johnthetubaguy: we said we'd not handle that in pike
17:17:52 <johnthetubaguy> so right now all old attachments need to use the old API
17:17:53 <mriedem> at the PTG
17:18:07 <jgriffith> mriedem correct, and we can easily idenfity those
17:18:15 <johnthetubaguy> what I mean is, its per attachment right now for detach
17:18:20 <jgriffith> so long as our detach is compatible we're safe
17:18:22 <johnthetubaguy> based on whats in the BDM
17:18:28 <mriedem> old attachments won't have the attachment_id
17:18:29 <mriedem> right
17:18:45 <johnthetubaguy> the create attachment is where it decides if its a new server, and all the compute are upgraded, that it might use 3.27
17:18:51 <mriedem> yes
17:19:02 <ildikov> mriedem: the old detach code tries to get it from Cinder
17:19:04 <johnthetubaguy> thats the last bit of code we will write, also
17:19:27 <ildikov> mriedem: so for volumes that are not too old we can get attachment_id
17:19:53 <mriedem> ildikov: i'm not sure what you're talking about, i'm not talking about the cinder data model <havana
17:19:58 <mriedem> i'm talking about bdm.attachment_id in nova
17:20:01 <mriedem> which is >=pike
17:20:04 <johnthetubaguy> ildikov: thats not the point, old BDMs always use the old API, missing connector and all that
17:20:09 <mriedem> yes
17:20:14 <mriedem> agree with tubaman
17:20:25 * johnthetubaguy makes tuba noises
17:20:39 <ildikov> I know, sorry for the side track
17:20:48 <jungleboyj> *bum bum, bum bum"
17:20:53 <johnthetubaguy> heh
17:21:13 <ildikov> just kinda "funny" that the current detach is trying to get the attachment_id as well
17:21:22 <mriedem> is there anything new we need to cover?
17:21:26 <ildikov> anyway, will use the old flow as is, all good
17:21:27 <mriedem> b/c we talk about this same stuff every week
17:21:32 <jgriffith> mriedem :)
17:21:43 <mriedem> seriously this shouldn't be a full hour each week
17:21:50 <mriedem> what's next?
17:22:00 <jgriffith> mriedem just the discover thing (done) and the attach id changes lyarwood had up in place of my abandoned ones
17:22:01 <ildikov> mriedem: if it's all in johnthetubaguy's spec and we all agree we don't need to talk about this again :)
17:22:02 <lyarwood> the db/object changes for nova haven't landed yet
17:22:04 <johnthetubaguy> seems like next step is the BDM uuid
17:22:14 <ildikov> lyarwood: tnx, just wanted to bring that up
17:22:17 <johnthetubaguy> right, lyarwood's patches are needed next
17:22:17 <mriedem> we're taking out the bdm uuid from the series
17:22:20 <lyarwood> johnthetubaguy: so we are going to drop the uuid changes to speed this up
17:22:26 <lyarwood> yeah that's done and posted
17:22:30 <mriedem> i'll review the attachment_id changes today
17:22:34 <mriedem> mdbooth already went over them
17:22:38 <johnthetubaguy> I would also love lots more +1s on my spec, if everyone agrees with what is in there now
17:22:51 <mriedem> johnthetubaguy: yes i need to get back on it
17:22:57 <mriedem> someone was bugging me about reviewing a policy docs spec yesterday
17:23:02 <johnthetubaguy> lyarwood: so I am starting at the wrong end of the chain I guess
17:23:07 <jgriffith> mriedem lyarwood ildikov once lyarwood 's stuff merges let me know and I'll get my detach changes rebased and resubmitted
17:23:09 <ildikov> is the UUID change something we would need to depend on here at some point or that's independent?
17:23:14 <jgriffith> that's all for me :)
17:23:15 <johnthetubaguy> mriedem: yeah, that bloke is a pain
17:23:26 <mriedem> ildikov: independent
17:23:26 <lyarwood> ildikov: it's independent
17:23:35 <ildikov> mriedem: lyarwood: cool, tnx
17:23:53 <ildikov> mriedem: lyarwood: I guess we're still planning with the detach refactor though
17:23:57 <lyarwood> jgriffith: ack I will, I'm out for a week from next Thursday so I'd like to get things done by then
17:23:57 <johnthetubaguy> ah, so we start on this one now: https://review.openstack.org/#/c/437597/
17:24:07 <ildikov> lyarwood: +1
17:24:14 <lyarwood> at the latest
17:24:25 <lyarwood> johnthetubaguy: yes
17:24:52 <mriedem> yup i'll look at those today
17:24:57 <lyarwood> thanks
17:25:07 <johnthetubaguy> me to
17:25:33 <johnthetubaguy> so reivew specs, review bdms, jgriffith to add detach on top of his patch that uses lyarwood's patches to get the bdm uuid
17:25:40 <johnthetubaguy> that looks like everything for next week?
17:25:47 <mriedem> johnthetubaguy: no bdm uuid,
17:25:49 <mriedem> bdm attachment_id
17:25:52 <lyarwood> attachment_id
17:25:58 <mriedem> otherwise yes
17:26:02 <johnthetubaguy> oops, yes, that
17:26:10 <johnthetubaguy> to many ids
17:26:14 <mriedem> plus jgriffith can address comments in the discovery patch and add tests
17:26:15 <ildikov> johnthetubaguy: and jgriffith to update the client microversion patch
17:26:23 <ildikov> mriedem: +1
17:26:25 <johnthetubaguy> yep, thats that last bit
17:26:31 <mriedem> ok, sounds good
17:26:34 <mriedem> are we done here? :)
17:26:39 <johnthetubaguy> detach on top of microversion patch, so we know its good
17:26:40 <ildikov> johnthetubaguy: when do you think your spec will be ready for wider review?
17:26:48 <mriedem> ildikov: it is already
17:26:51 <johnthetubaguy> its been ready since the week after the PTG
17:26:52 <mriedem> it has been i think
17:27:09 <ildikov> johnthetubaguy: ok, then I'll move it up on the etherpad :)
17:27:10 <jungleboyj> Looked pretty good to me.
17:27:24 <jungleboyj> At least the important stuff I remembered from the PTG.
17:27:34 <johnthetubaguy> ildikov: its not moved because we (the subteam) haven't all +1ed it
17:27:46 <mriedem> and we have other stuff going on...
17:27:49 <mriedem> but beside the point
17:27:50 <mriedem> anyway
17:28:01 <mriedem> end meeting?
17:28:04 * jungleboyj gets out his rubber stamp
17:28:08 <johnthetubaguy> cool, I saw comments from lyarwood, jgriffith, jungleboyj and mdbooth recently, they seem mostly on board on the spec now
17:28:17 <ildikov> johnthetubaguy: ah ok
17:28:18 <johnthetubaguy> yup, seems we are done
17:28:42 <mriedem> ...
17:28:44 <mriedem> end it
17:28:45 <ildikov> ok, if nothing else to discuss thank you all for this short and crisp one
17:28:48 <mriedem> yay
17:28:54 <ildikov> we all have our action points
17:28:59 <ildikov> see you all next week!
17:29:01 <hemna> sweet.
17:29:02 <mriedem> ttyl
17:29:07 <ildikov> #endmeeting