17:00:12 <ildikov> #startmeeting cinder-nova-api-changes
17:00:13 <openstack> Meeting started Mon Dec 12 17:00:12 2016 UTC and is due to finish in 60 minutes.  The chair is ildikov. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:16 <openstack> The meeting name has been set to 'cinder_nova_api_changes'
17:00:25 <ildikov> scottda 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
17:00:35 <jgriffith> o/
17:00:36 <mriedem> o/
17:00:41 <DuncanT> o/
17:00:50 <johnthetubaguy> I am back but can't make this today again :(
17:00:57 <johnthetubaguy> but I can lurk in two meetings at once
17:01:14 <ildikov> johnthetubaguy: still welcome back :)
17:01:32 <ildikov> I updated our chaotic etherpad with some info: #link https://etherpad.openstack.org/p/cinder-nova-api-changes
17:01:49 <scottda> hi
17:02:01 <ildikov> the Cinder side spec got merged: #link https://review.openstack.org/#/c/361512/
17:02:57 <ildikov> it captures the basics, like the API calls and a few more to have a foundation to start with
17:03:26 <ildikov> code is on its way: #link https://review.openstack.org/#/q/status:open+project:openstack/cinder+branch:master+topic:attach_detach_v2
17:03:36 <hemna> morning
17:03:54 <ildikov> hemna: afternoon :)
17:03:59 <hemna> :)
17:04:47 <ildikov> anyone has anything to add to the above announcement/items?
17:05:09 <hemna> how far off are we getting the code out of WIP?
17:05:17 <jgriffith> hemna depends
17:06:00 <jgriffith> hemna need reviews (thanks ildikov by the way for the reviews over the week-end!)
17:06:25 <jgriffith> hemna I'd like to get the attachments patch merged then push a non-wip up for the rest of the cinder changes
17:06:47 <hemna> ok
17:06:48 <ildikov> jgriffith: no problem (always good to have a workaholic on the team :)
17:06:54 <hemna> I'll look at the attachments review
17:06:55 <jgriffith> :)
17:07:28 <ildikov> jgriffith: when do you think you can get to the cinderclient changes?
17:07:41 <jgriffith> hemna I'm trying to figure out again how to just use the volume backref and a join to get provider id
17:07:55 <ildikov> jgriffith: I thought to push the Nova side forward a bit, but that'll need the client to test
17:08:09 <mriedem> well, we have other things we can do on the nova side first,
17:08:12 <jgriffith> ildikov ok, I can bump that up today
17:08:15 <mriedem> i.e. nova doesn't currently support cinder v3
17:08:26 <mriedem> that could be worked independent of any of this
17:08:33 <jgriffith> mriedem well there is that minor detail :)
17:08:48 <mriedem> and we could enable nova to use cinder v3 in the placement CI job
17:08:54 <mriedem> which is where we do our bleeding edge testing
17:09:29 <ildikov> jgriffith: thanks, I'll let you know when it's worth it to reopen the Nova review
17:09:55 <ildikov> mriedem: is there any activity on this currently?
17:10:29 <ildikov> jgriffith: I like your Monday optimism re "minor detail" :)
17:10:40 <mriedem> ildikov: nope
17:10:49 <scottda> ildikov: I had put up some WIP patches to allow testing of nova -> cinder v3
17:10:50 <scottda> https://review.openstack.org/#/c/385682/
17:10:56 <mriedem> it might just be configuring nova in a job to use cinder v3
17:11:32 <scottda> all that ^^ needs unit tests and more love, but I *believe* it all basically worked with Cinder microversions on /v3 endpoint. It's been a while....
17:11:34 <ildikov> scottda: cool, tnx!
17:11:55 <scottda> mriedem: Yeah, I think nova just needs:
17:11:56 <scottda> Requires use of Cinder v3 endpoint by adding to nova.conf: [cinder] catalog_info = volumev3:cinderv3:publicURL
17:14:11 <mriedem> scottda: yeah your change is still using v2
17:14:11 <mriedem> volumev2:cinderv2:publicURL
17:14:13 <mriedem> is the default
17:14:49 <ildikov> scottda: what does 'more love' mean in your above comment? I got the unit test part :)
17:15:42 <mriedem> scott's love level was insufficient
17:15:49 <scottda> ildikov: Ha. I think the code will need some methods to get the cinder microversion for use inside Nova code.
17:16:12 <scottda> It's just a quick hack to allow testing.
17:16:26 <mriedem> note that nova also still supports cinder v1
17:16:27 <ildikov> scottda: ok, got it, thanks
17:16:32 <scottda> And I'm sure Nova folks will have a better idea of what they'd like to see.
17:16:32 <mriedem> if version == '1' and not _V1_ERROR_RAISED:
17:16:46 <mriedem> so we might want to just remove that support
17:16:54 <mriedem> i can take that on
17:18:20 <ildikov> mriedem: sounds good, tnx
17:19:00 <ildikov> scottda: I will look up the Nova priority etherpad where this new Cinder API activity is tracked and add your patch there to get more eyes on it
17:19:21 <scottda> ildikov: Well, it was a WIP and then became abandoned...
17:19:36 <scottda> ildikov: I'll re-visit the patch and put up a real patch this week.
17:19:45 <ildikov> scottda: bah, ok I didn't check the header :)
17:20:02 <ildikov> scottda: I'll do the administration once that's done
17:23:56 <ildikov> if there's nothing more to the microversions, I think last time we mainly discussed things that were in the Nova spec, like volume state changes in error scenarios, etc.
17:24:30 <ildikov> mriedem: now that johnthetubaguy I guess the next step is push forward that spec based on the comments
17:24:46 <ildikov> mriedem: is my assumption correct?
17:25:21 <mriedem> john will probably need some time to ease back in from the break, and process my deluge of comments on his spec
17:26:07 <ildikov> mriedem: :)
17:27:07 <ildikov> I think we can do the prototyping with the plain simple attach/detach flow, while the comments on the Nova spec get cleaned up
17:27:45 <ildikov> mriedem: is there anything among the comments that we should bring up here?
17:28:13 <mriedem> it was last monday when i reviewed it, so i'm fuzzy, but nova setting error state on the cinder resources (attachment) was my main complaint
17:29:06 <ildikov> mriedem: I think it's currently not covered on the Cinder side, I mean in the spec or the current version of the code
17:31:24 <ildikov> mriedem: I think we didn't have an agreement on modifying the error state part so far
17:31:39 <ildikov> mriedem: you're on the side of not doing it, right?
17:32:00 <mriedem> ildikov: correct
17:32:11 <ildikov> last time beyond the Cinder basics I think this was the main item that came up
17:32:13 <mriedem> i don't think nova, or anything, should meddle with the internal state of a resource in cinder
17:32:23 <hemna> mriedem, +1
17:32:23 <jgriffith> mriedem agreed
17:32:39 <ildikov> mriedem: +1
17:33:25 <ildikov> I can link in the meeting logs to the spec and then we can look into how to handle that part
17:34:03 <ildikov> mriedem: the other thing we talked about earlier is when Nova will create a new attachment and when it should just update it
17:34:41 <ildikov> mriedem: I think we can experiment it in the PoC patch in parallel to working on the edge cases in the spec
17:34:42 <mriedem> i wasn't clear on that from the spec, it kind of goes both ways at times it seems
17:34:56 <ildikov> mriedem: or if there's anything in anyone's mind then we can touch on that here too
17:34:58 <mriedem> i thought to mimic reserve today we'd create the empty attachment in nova-api
17:35:11 <mriedem> and then update it with host/connector details in n-cpu
17:35:20 <jgriffith> mriedem correct
17:35:24 <ildikov> yeap, that's the plan
17:35:37 <mriedem> but i thought i saw something in the nova spec about creating the attachment in n-cpu, which would be racey
17:35:43 <mriedem> but i might be confusing volume attach and BFV
17:36:13 <mriedem> today for BFV we don't reserve the volume from n-api
17:36:20 <ildikov> I guess questions come up when it comes to handling error cases like the instance will end up on another host by the end of the day-type of rebuild, etc.
17:36:24 <hemna> which is odd
17:36:39 <ildikov> mriedem: the patch for that is still on it's way :)
17:37:36 <mriedem> for rebuilds,
17:37:46 <ildikov> mriedem: in the sense of needs review, although I can remove a few more things from the code before told that it's the total wrong direction... :)
17:37:47 <mriedem> we don't retry on BFV errors today
17:38:18 <ildikov> when does Nova retry?
17:38:37 <mriedem> https://review.openstack.org/#/c/246505/
17:38:47 <mriedem> when does nova retry....well....
17:38:55 <mriedem> depends on what's handled in the compute manager
17:39:07 <mriedem> which is kind of a mess
17:40:23 <ildikov> hmm, I wonder whether we can come up with anything high level regarding how we would like to handle these if things would be less messy
17:40:38 <ildikov> or just handle this as we get there one by one
17:41:22 <ildikov> mriedem: do you think that review will be picked up? As it's currently abandoned
17:41:28 <mriedem> nova needs to eventually move the volume creation code to conductor,
17:41:31 <mriedem> like we're doing with ports
17:41:33 <mriedem> but that's a ways out
17:41:45 <mriedem> ildikov: it's up to someone to pick up i guess,
17:41:49 <mriedem> i don't think the submitter will
17:42:00 <mriedem> as it's powervc and they just carry patches internally
17:42:15 <ildikov> ok, then we keep that path in mind, but it's not a burden for now
17:42:32 <mriedem> for the new hotness, i think nova just deletes the attachment in n-cpu on failure
17:42:45 <mriedem> like nova should do for port deallocation between retries
17:42:57 <jgriffith> mriedem yes, that's what I thought we agreed upon
17:43:04 <mriedem> if you come with a volume/port, nova doesn't touch it between retries, but if nova creates it, nova should clean it up
17:44:09 <hemna> that sounds reasonable to me
17:44:12 <ildikov> mriedem: +1
17:44:27 <hemna> nova is the one who is executing the workflow
17:45:32 <ildikov> I will reread the Nova spec with this mindset to see where we are
17:46:05 <ildikov> although I guess mriedem captured all the hiccups in it already :)
17:47:34 <ildikov> anything else in connection to this?
17:48:52 <ildikov> ok, then one more regular reminder from my side
17:49:34 <ildikov> mriedem: johnthetubaguy: pretty please, sugar, whipped cream, cherry, whatever on top give this puppy a quick review: https://review.openstack.org/#/c/335358/ :)
17:50:15 <ildikov> mriedem: johnthetubaguy: or tell me who else is competent with the area enough to be interested in looking at it
17:50:36 <johnthetubaguy> thats probably me
17:51:35 <ildikov> johnthetubaguy: cool, tnx, I will add you to my 'annoy people' list then :)
17:52:19 <ildikov> anything else for today to discuss?
17:53:11 <scottda> Are we meeting next week?
17:54:02 <ildikov> scottda: I wanted to ask when to stop/resume the series, tnx for reminding :)
17:54:30 <ildikov> I'm available next week, but we can skip if we don't have enough people around
17:54:51 <scottda> I'll be around next week. I could go either way...
17:55:29 <hemna> I'm around next week
17:55:46 <ildikov> jgriffith: mriedem: johnthetubaguy: how likely will you be around next week?
17:55:54 <mriedem> i'm around
17:55:58 <jgriffith> me too
17:56:21 <ildikov> ok, cool, then let's aim for a quick one next week
17:57:00 <ildikov> and I think we can resume the meeting series on the 9th next year
17:57:23 <ildikov> but we can decide on this next week
17:57:27 <scottda> ildikov: Sounds good