| *** sdake has quit IRC | 00:28 | |
| *** gouthamr_ has quit IRC | 01:05 | |
| *** david-lyle has joined #openstack-meeting-cp | 01:27 | |
| *** david-lyle has quit IRC | 01:31 | |
| *** gouthamr has joined #openstack-meeting-cp | 01:43 | |
| *** beekhof has joined #openstack-meeting-cp | 01:53 | |
| *** coolsvap has joined #openstack-meeting-cp | 02:01 | |
| *** uxdanielle has joined #openstack-meeting-cp | 02:18 | |
| *** uxdanielle has quit IRC | 02:18 | |
| *** markvoelker has joined #openstack-meeting-cp | 03:25 | |
| *** gouthamr has quit IRC | 03:52 | |
| *** prateek_ has joined #openstack-meeting-cp | 05:31 | |
| *** coolsvap is now known as _coolsvap_ | 07:13 | |
| *** pilgrimstack has joined #openstack-meeting-cp | 08:03 | |
| *** pilgrimstack has quit IRC | 08:11 | |
| *** pilgrimstack has joined #openstack-meeting-cp | 08:11 | |
| *** kencjohnston has quit IRC | 08:13 | |
| *** clarkb has quit IRC | 08:13 | |
| *** kencjohnston has joined #openstack-meeting-cp | 08:14 | |
| *** clarkb has joined #openstack-meeting-cp | 08:15 | |
| *** gema has left #openstack-meeting-cp | 08:57 | |
| *** sdague has joined #openstack-meeting-cp | 10:51 | |
| *** _sigmavirus24 is now known as sigmavirus | 11:06 | |
| *** sigmavirus has joined #openstack-meeting-cp | 11:06 | |
| *** sdake has joined #openstack-meeting-cp | 11:49 | |
| *** markvoelker has quit IRC | 11:51 | |
| *** sdake has quit IRC | 12:13 | |
| *** sdake has joined #openstack-meeting-cp | 12:14 | |
| *** markvoelker has joined #openstack-meeting-cp | 12:22 | |
| *** david-lyle has joined #openstack-meeting-cp | 12:38 | |
| *** david-lyle has quit IRC | 12:43 | |
| *** xyang1 has joined #openstack-meeting-cp | 12:58 | |
| *** prateek_ has quit IRC | 13:08 | |
| *** gouthamr has joined #openstack-meeting-cp | 13:09 | |
| *** tongli has joined #openstack-meeting-cp | 14:16 | |
| *** piet has joined #openstack-meeting-cp | 14:29 | |
| *** david-lyle has joined #openstack-meeting-cp | 14:40 | |
| *** david-lyle has quit IRC | 14:45 | |
| *** hemnafk is now known as hemna | 15:19 | |
| *** hpe-hj has joined #openstack-meeting-cp | 15:20 | |
| *** hj-hpe has quit IRC | 15:22 | |
| *** david-lyle has joined #openstack-meeting-cp | 15:32 | |
| *** aimeeu__ has joined #openstack-meeting-cp | 15:57 | |
| *** tyr_ has joined #openstack-meeting-cp | 15:59 | |
| *** tyr_ has quit IRC | 16:17 | |
| *** tyr_ has joined #openstack-meeting-cp | 16:25 | |
| *** raj_singh has joined #openstack-meeting-cp | 16:26 | |
| *** tyr__ has joined #openstack-meeting-cp | 16:26 | |
| *** tyr_ has quit IRC | 16:30 | |
| *** tyr__ has quit IRC | 16:31 | |
| *** diablo_rojo_phon has joined #openstack-meeting-cp | 16:58 | |
| *** diablo_rojo has joined #openstack-meeting-cp | 16:59 | |
| ildikov | #startmeeting cinder-nova-api-changes | 17:00 |
|---|---|---|
| openstack | Meeting started Mon Sep 19 17:00:09 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 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 17:00 |
| *** openstack changes topic to " (Meeting topic: cinder-nova-api-changes)" | 17:00 | |
| openstack | The meeting name has been set to 'cinder_nova_api_changes' | 17:00 |
| ildikov | scottda ildikov DuncanT ameade cFouts johnthetubaguy jaypipes takashin alaski e0ne jgriffith tbarron andrearosa hemna erlon mriedem gouthamr ebalduf patrickeast smcginnis diablo_rojo gsilvis | 17:00 |
| scottda | hi | 17:01 |
| *** mriedem has joined #openstack-meeting-cp | 17:02 | |
| mriedem | o/ | 17:03 |
| ildikov | hi all, finally no RC1 or holidays so we can have the series and activities going :) | 17:04 |
| ildikov | as a reminder here's our etherpad: https://etherpad.openstack.org/p/cinder-nova-api-changes | 17:04 |
| ildikov | I added the links to open reviews so that we can have a better picture on what we started already | 17:04 |
| * johnthetubaguy is lurking, just finishing another call | 17:04 | |
| ildikov | jgriffith: do you have any updates regarding the spec you planned to write up? | 17:05 |
| johnthetubaguy | +1 on that question | 17:07 |
| ildikov | while we have jgriffith to arrive, I would also like to discuss what we need to be prepared for the Design Summit and the upcoming short cycle | 17:07 |
| ildikov | it would be great to identify a high level roadmap and discuss more specifics in person I think | 17:08 |
| scottda | In the past we've had a cinder-nova cross project session. I'm not sure if we need one for Barcelona? | 17:08 |
| mriedem | i assumed there would be a nova/cinder design summit session, but i wasn't sure | 17:09 |
| ildikov | I also saw on the Nova retrospective etherpad that it's not clear for everyone what we are working on, so I would also like to know what we could do to clarify it to people? | 17:09 |
| johnthetubaguy | so I would love to get cinder and neutron on the same page about live-migrate and APIs | 17:09 |
| scottda | Regarding the O cycle, Cinder is leaning towards a "stability" cycle, with emphasis on bug-fixing and testing. | 17:09 |
| scottda | johnthetubaguy: +1 to that. | 17:09 |
| mriedem | nova isn't | 17:12 |
| scottda | johnthetubaguy: I think you have Nova specs up for API changes, don't you? Could you put links in the cinder-nova-api-changes etherpad? | 17:12 |
| johnthetubaguy | not good ones | 17:12 |
| johnthetubaguy | I need to refine them (this week) | 17:12 |
| ildikov | scottda: does this mean that the api work jgriffith started is not in scope for Ocata in Cinder? | 17:13 |
| scottda | johnthetubaguy: OK, well even the starting point would be nice to link it. At some point, we'll need to start pointing more people to what we are doing to give context for discussions. | 17:13 |
| ildikov | mriedem: +1 one on the session, I hoped to have one | 17:13 |
| scottda | ildikov: I'm not sure. And this was just a campaign promise by smcginnis, who probaly has zero chance of getting re-elected PTL anyway :) | 17:14 |
| hemna | hey | 17:14 |
| hemna | sorry was in another meeting | 17:14 |
| ildikov | scottda: haha, thanks for the insights :) | 17:15 |
| hemna | I still think we need to have a cross project working group for nova-cinder until we iron out the new cinder API and it's ramifications in nova | 17:15 |
| scottda | ildikov: I'd bet we can move this forward in Ocata. But we might not get as much done as we'd like. | 17:15 |
| ildikov | so I hope we can move on to have that experimental API in Cinder, especially that there's already code up for it and mriedem started to get the gate working as well | 17:16 |
| hemna | I'd like to see jgriffith's patch land early in O and get a nova patch in gerrit to test against | 17:16 |
| johnthetubaguy | scottda: yeah, let me find that, one sec, out of other meeting now | 17:16 |
| ildikov | hemna: +1 | 17:16 |
| hemna | ildikov, one of the things we spoke about in the cinder mid cycle was doing a feature branch | 17:16 |
| hemna | in cinder for this instead of an experimental api | 17:16 |
| johnthetubaguy | so this is my mega spec on neutorn changes, it will die very soon and split into many little specs: https://review.openstack.org/#/c/353982/ | 17:16 |
| hemna | as experimental api's still make it into the wild | 17:17 |
| johnthetubaguy | this is the existing spec around the neutron api changes: https://review.openstack.org/#/c/309416 | 17:17 |
| mriedem | i've never worked on a feature branch so i'm not sure how much trouble that is wrt the infra for running ci and chaining changes together | 17:17 |
| johnthetubaguy | my worry is about getting from the feature branch back into master | 17:18 |
| scottda | hemna: I don't recall the outcome of presenting options (experimental API vs. feature vs. ?) to Nova, but I do remember there were strong opinions about one option... | 17:18 |
| hemna | merge conflicts, etc? | 17:18 |
| hemna | so yah, this is something we should talk about in BCN and see what makes the most sense | 17:19 |
| ildikov | hemna: I thought we dropped the feature branch idea there as a conclusion | 17:19 |
| hemna | we need some bake time in with the cinder api changes and see how it works with nova | 17:19 |
| scottda | Line#103 https://etherpad.openstack.org/p/newton-cinder-midcycle-day2 for notes on that.. | 17:20 |
| hemna | ildikov, we might have, I just forgot what we decided | 17:20 |
| *** rhedlind has joined #openstack-meeting-cp | 17:20 | |
| scottda | Looks like nothing marked as Resolved on the issue of experimental APi vs. Feature at the mid-cycle. | 17:21 |
| *** Rockyg has joined #openstack-meeting-cp | 17:21 | |
| ildikov | I would rather go to the experimental direction, as it is a new API it should not do that much harm, but it is just my view | 17:21 |
| hemna | ildikov, so the one argument against that is that the API still gets released to the wild | 17:21 |
| hemna | and folks start to use it.... | 17:21 |
| johnthetubaguy | so we have being doing the placement API in tree in Nova, not get enough data on that yet I guess | 17:21 |
| hemna | and then complain that it goes away | 17:21 |
| johnthetubaguy | although thats a bit of a different case I guess | 17:21 |
| scottda | ildikov: I'm ok with experimental direction. And I could do the code. We'd want to figure this out before the summit, to discuss with Cinder (we've discussed this one in Tokyo, mid-cyle, ...) | 17:22 |
| hemna | honestly, this is why we have branches in git | 17:22 |
| ildikov | hemna: as jgriffith already has code, can we figure out until the Summit how likely that will go away? | 17:23 |
| hemna | go away? | 17:23 |
| *** tyr_ has joined #openstack-meeting-cp | 17:23 | |
| ildikov | hemna: I think the Cinder API design should be on one hand simple and on the other hand good for Cinder's use cases | 17:23 |
| hemna | so, I had planned on putting a patch together in the python-brick-cinderclient-ext to use the new API that john has | 17:24 |
| ildikov | hemna: you had the argument against the experimental that people will start to use it and then it'll go away | 17:24 |
| hemna | this will allow us to test against direct attaching inside a vm or a bare metal node | 17:24 |
| hemna | without nova | 17:24 |
| scottda | hemna: Cool, that will be good. We still need to figure how to POC and test with Nova. | 17:25 |
| hemna | ildikov, so I don't think his patch will go away, but I think the api may/will change as we start to implement against it in nova and cinderclient | 17:25 |
| hemna | either way, we need to get that code to land somewhere and start using it | 17:25 |
| mriedem | to be fair john has nova patches using it today | 17:26 |
| mriedem | via cinderclient | 17:26 |
| ildikov | hemna: I think the nest thing as they way forward to keep things simple and remove workarounds in Nova, so I hope a basic attach/detach API in Cinder does not get changed that much because of the interactions with Nova | 17:26 |
| hemna | it's hard to tell until we start using it | 17:27 |
| scottda | Yes, perhaps we're just being paranoid about the flexibility to change the API... | 17:28 |
| hemna | and introducing live migration, shelve, etc into the mix | 17:28 |
| hemna | and we should think about how it fits into multi-attach as well | 17:28 |
| scottda | I say this as someone who is in favor of experimental APIs. But there are many who oppose it, so might be tough to get consensus. | 17:28 |
| hemna | and what we want to do there | 17:28 |
| ildikov | hemna: if we end up overcomplicating the Cinder API because of those use cases then we might do something wrong, but that's just my 2 cents, I can move on :) | 17:29 |
| hemna | well, that's kinda how we got here. | 17:29 |
| hemna | is that we have a complicated API to account for those cases | 17:29 |
| ildikov | we have a let's use the ugly word legacy API, that we're I hope ready to change now | 17:30 |
| scottda | ildikov: +1. That is how we got here. I'd rather see a separate API for corner cases like shelve offload, etc. That will hopefully prevent the coding errors we seen. | 17:30 |
| *** harlowja has joined #openstack-meeting-cp | 17:30 | |
| ildikov | if we expect that things will not need to be changed and cleaned up Nova for instance, then it's not the best direction we can go to IMHO, I would like to avoid that | 17:31 |
| ildikov | *in Nova | 17:31 |
| johnthetubaguy | the way I like to think about this, is we need to stop telling each other lies, and be more explicit about things | 17:31 |
| scottda | johnthetubaguy: Agreed. | 17:31 |
| mriedem | unless that was a lie | 17:31 |
| * johnthetubaguy head goes boom | 17:32 | |
| scottda | But, my opinion is that one reason for the lies is that Cinder keeps attach state, which is of use to Nova, but not necessarily important for Cinder. | 17:32 |
| hemna | liars! | 17:32 |
| ildikov | johnthetubaguy: +1 | 17:32 |
| scottda | And Nova is the only entity that really knows if a volume is attached. | 17:32 |
| hemna | scottda, well but it is important for cinder too | 17:32 |
| ildikov | scottda: we are removing that from Nova | 17:32 |
| hemna | ildikov, +1 | 17:32 |
| hemna | nova shouldn't care, it should just ask cinder to do something | 17:33 |
| hemna | and cinder can say, ok, or no. | 17:33 |
| scottda | Yeah, I wont' go down this path again. I think Cinder shouldn't care, it should just provide an export and say "do with it as you please" | 17:33 |
| ildikov | scottda: the whole point of removing check_attach from Nova is to stop it from following a state that it should not use for any internal decisions really | 17:33 |
| hemna | it's cinder's job to keep track of it's volumes and what's allowed or not | 17:33 |
| scottda | And be nice, and tell us when you are done | 17:33 |
| scottda | But then we're vulnerable to lies | 17:34 |
| hemna | the problem is Cinder can be doing things to the volume that should prevent nova from attaching it at the time.....think migration or retyping, etc. | 17:34 |
| scottda | (if cinder keeps track of volumes, and what's allowed or not) | 17:34 |
| johnthetubaguy | hemna: right I think thats the problem, Nova needs explicit (and exclusive) permission for what it wants to do | 17:35 |
| scottda | yeah, OK. We're painted in the corner on those cases. | 17:35 |
| hemna | johnthetubaguy, yah it does and it will with the new api, just behind the scenes in Cinder | 17:35 |
| johnthetubaguy | hemna: +1 | 17:36 |
| hemna | nova just asks, and it gets a yes or no answer | 17:36 |
| scottda | Anyway, we can solve the problem of having to lie for special cases by having a separate API for the unusual Nova cases. | 17:36 |
| scottda | i.e detach, shelve_offload_detach, live_migration_detach, or something like that. | 17:36 |
| scottda | Keep things explicit, to avoid coding errors. | 17:36 |
| hemna | https://review.openstack.org/#/c/327408/ | 17:36 |
| hemna | just FYI, the new API patch | 17:36 |
| ildikov | hemna: it's what reserve_volume does currently as well, right? | 17:36 |
| hemna | ildikov, yah | 17:37 |
| ildikov | hemna: I mean letting Nova know it can use the volume or not | 17:37 |
| hemna | yup | 17:37 |
| hemna | it's far simpler and much less racy as well | 17:37 |
| ildikov | scottda: I think jgriffith also mentioned a safe_to_detach call on the API or smth like as one way to handle corner cases | 17:37 |
| hemna | dulko was even asking about making that patch experimental | 17:38 |
| scottda | ildikov: Yes, that sound about right, but there is still a need to do things for migration like "detach the volume, but don't change the state in the Cinder DB" | 17:38 |
| ildikov | hemna: scottda: yup, I think wherever we do this tracking that should be at one place and not in both | 17:38 |
| ildikov | hemna: scottda: I lean towards what hemna says and what reserve_volume does today | 17:38 |
| ildikov | we can have a separate meeting/chat about this topic if it's still an open question in Cinder | 17:39 |
| ildikov | I think it's very important to address and agree on | 17:39 |
| scottda | Well, it will come up when we move past just attach/detach | 17:39 |
| ildikov | scottda: right, we need to think about additional cases as well, I agree, I only wanted to mention an example for now | 17:39 |
| johnthetubaguy | I would like live-migration to be two attachments, to the same instance, but on a different host | 17:40 |
| johnthetubaguy | largely as that seems to be the way neutron is going with port bindings | 17:40 |
| hemna | johnthetubaguy, yup that's exactly what it is | 17:40 |
| johnthetubaguy | hemna: good stuff | 17:41 |
| hemna | nova currently just bypasses the official end to end attach process for the 2nd attachment. | 17:41 |
| scottda | johnthetubaguy: That's fine. But we will not be able to use new_attach api, we'll need a separate one. | 17:41 |
| hemna | is there any way to change the order at all? | 17:41 |
| hemna | so there is only 1 attach at a time ? | 17:41 |
| hemna | I know, that's crazy talk | 17:41 |
| johnthetubaguy | depends | 17:42 |
| johnthetubaguy | ah, so no | 17:42 |
| scottda | live_migration_attach. Which does the same as now regarding attaching to both, but doesn't fail on Cinder DB state. | 17:42 |
| hemna | I guess the problem is we can't tear down the source before we bring the destination n-cpu instance up | 17:42 |
| johnthetubaguy | basically, live-migrate involves one VM being fully connected to all ports and volumes, on two different hosts | 17:42 |
| ildikov | I don't know whether we should go down the rabbit hole of using flags | 17:42 |
| scottda | And tricky for Boot from Volume, I believe | 17:42 |
| ildikov | most probably not | 17:42 |
| johnthetubaguy | hemna: yeah, spot in | 17:42 |
| ildikov | johnthetubaguy: is this planned out for Neutron already? | 17:43 |
| ildikov | johnthetubaguy: I mean the migration use case for ports | 17:43 |
| scottda | ildikov: -1 to flags. I think people get confused and write buggy code when we re-use the API for too much. | 17:43 |
| hemna | scottda, +1 | 17:43 |
| johnthetubaguy | ildikov: possibly, may only get the neutorn side done, but hopefully make progress on both | 17:43 |
| ildikov | scottda: +1, I had the same thought, just wanted to be sure we all agree | 17:44 |
| johnthetubaguy | so an attachement is always for a specific host and specific device(instance uuid) | 17:44 |
| johnthetubaguy | it seem we can just have two of those now, but how we want to show that in the API is a different thing | 17:44 |
| ildikov | johnthetubaguy: I was wondering more about the direction you picked there to try to use the same/similar concept if possible | 17:44 |
| johnthetubaguy | multi-attach is two instance uuids, and live-migrate is two host uuids | 17:45 |
| hemna | the new API doesn't have host | 17:45 |
| hemna | it's just instance_uuid | 17:45 |
| johnthetubaguy | ildikov: so neutron is looking at port binding, were we can have two of them at once, and we tell neutron which is the active one | 17:45 |
| hemna | the host is inside the connector | 17:45 |
| johnthetubaguy | I thought host was going to be required to get sent from Nova | 17:46 |
| scottda | hemna: That's why we need live_migration_second_attach(instance_id, host1, host2,..) or something like that. | 17:46 |
| johnthetubaguy | so we can do connection tracking for the multi-attache cases | 17:46 |
| hemna | create_attachment(self, context, volume_ref, connector, instance_uuid, mountpoint, no_connect=False): | 17:46 |
| ildikov | johnthetubaguy: ok, I see | 17:46 |
| hemna | so technically the host is in there, just inside the connector dict | 17:46 |
| hemna | it's just not explicit | 17:46 |
| scottda | plus live_migration_detach_old_host(blah, blah) | 17:46 |
| *** diablo_rojo has quit IRC | 17:46 | |
| johnthetubaguy | that seems odd, its a property of the attachement | 17:46 |
| hemna | yah | 17:47 |
| hemna | I'd like to see it called out separately as well | 17:47 |
| hemna | which also makes sense for bare metal attaches | 17:47 |
| johnthetubaguy | I mean, how its stored in the DB doesn't matter to me, I am just thinking conceptually | 17:47 |
| scottda | Well, we're changing the API, so call it out separately if we want | 17:47 |
| hemna | nova can just pull it out of the connector prior to calling the api | 17:47 |
| ildikov | johnthetubaguy: I thought Cinder will keep the connector info from now on and use the data in it | 17:47 |
| ildikov | or smth similar :) | 17:47 |
| hemna | ildikov, it should be saved in the attachment table. | 17:47 |
| *** tyr_ has quit IRC | 17:48 | |
| hemna | when the new api is called it should save the connector | 17:48 |
| hemna | which also solves a lot of our shelve and force detach issues | 17:48 |
| johnthetubaguy | right, for each (volume_uuid, host_uuid) you need to store a connector info, I would have thought? | 17:48 |
| hemna | johnthetubaguy, +1 | 17:48 |
| hemna | yah that should be part of this | 17:48 |
| scottda | hemna: I believe jgriffith 's patches do save the connector... | 17:48 |
| hemna | I haven't spent a lot of time reviewing the patch | 17:49 |
| hemna | but it should save the connector. | 17:49 |
| ildikov | hemna: right, this is what I had in mind | 17:49 |
| johnthetubaguy | I think the connector is saved | 17:49 |
| johnthetubaguy | I just worry live-migrate will wonder in an break things, unless its per volume_uuid and host_uuid | 17:50 |
| johnthetubaguy | I am thinking about a multi-attached volume that is doing a live-migrate, so it gets three attachements | 17:50 |
| ildikov | hemna: as Cinder currently does not store the info and Nova has the reoccurring initialize_connection calls that we want to remove as well IIRC | 17:50 |
| hemna | ok so, I'll go through the patch and see if I can track down the connector | 17:51 |
| hemna | I'm not sure it's saving it actually | 17:51 |
| hemna | https://review.openstack.org/#/c/327408/13/cinder/volume/manager.py | 17:51 |
| hemna | I don't see it getting saved | 17:51 |
| scottda | hemna: Yeah, I'm scanning now and don't see it save either | 17:51 |
| hemna | anyway, that can be changed | 17:51 |
| hemna | so, I think we'll have to add a new DB column in the volume_attachment table | 17:52 |
| hemna | to store the connector. | 17:52 |
| johnthetubaguy | sounds like we are converging on the concepts at least | 17:52 |
| ildikov | johnthetubaguy: +1 :) | 17:52 |
| hemna | http://paste.openstack.org/show/581172/ | 17:52 |
| hemna | that's all that the attachment entry has right now | 17:53 |
| johnthetubaguy | seems like we need the writing up ahead of the summit, so we can agree the details at the summit? | 17:53 |
| hemna | johnthetubaguy, not a bad idea | 17:53 |
| ildikov | johnthetubaguy: exactly my thought as well | 17:53 |
| ildikov | I will add the main topics we touched today to the top of our etherpad and we can go through them before the Summit to prepare, if that sounds good | 17:54 |
| ildikov | I would like to keep this meeting series too and use as preparation because it seems we still have a lot to agree on | 17:55 |
| hemna | yup | 17:55 |
| hemna | I think there will be lots of iron out once we get the cinder api in place. I think the changes in Nova are going to be complex. | 17:55 |
| scottda | +1 keep meeting | 17:55 |
| ildikov | does it sound ok to everyone as next step(s)? | 17:55 |
| hemna | as Nova will have to maintain compatibility with the old API for a while. | 17:55 |
| ildikov | hemna: +1 | 17:55 |
| hemna | ildikov, +! | 17:55 |
| hemna | +1 even | 17:55 |
| ildikov | although I hope we can simplify things in Nova too, or at least "clarify" and have less hacky things | 17:56 |
| scottda | +1 | 17:56 |
| hemna | johnthetubaguy, one of the changes involved is that the new Cinder API will take a while to complete | 17:56 |
| hemna | and Nova currently calls reserve_volume way early in the process (nova api) before it continues. | 17:57 |
| hemna | so, if the nova api changes to call the new cinder api, that might take a while | 17:57 |
| johnthetubaguy | ah, so reserve_volume is changing quite a lot? | 17:57 |
| hemna | as cinder will go all the way to the backend (c-vol -> driver) and back before it responds. | 17:57 |
| johnthetubaguy | ah... | 17:57 |
| scottda | johnthetubaguy: reserve_volume goes away... | 17:58 |
| scottda | johnthetubaguy: And all the attach calls merge into 1 call | 17:58 |
| johnthetubaguy | hmm, I had missed that being suggested | 17:58 |
| hemna | well, the new API internalls calls reserve_volume, but then also does an RPC to the c-vol service to call initialize_Connection, which calls the cinder backend. | 17:58 |
| *** diablo_rojo has joined #openstack-meeting-cp | 17:58 | |
| ildikov | it does? I wasn't sure we decided that reserve_volume goes away too | 17:58 |
| hemna | well reserve_volume exists | 17:58 |
| mriedem | i wasn't sure that reserve goes away either | 17:58 |
| hemna | but nova isn't supposed to call it | 17:58 |
| johnthetubaguy | so just as a heads up, that does make Nova's API experience a bit worse | 17:58 |
| hemna | all it does is call create_Attachment | 17:58 |
| mriedem | i thought nova-api was going to call reserve as it does today | 17:58 |
| scottda | nova doesn't call it. | 17:58 |
| johnthetubaguy | but honestly, I am OK with that | 17:59 |
| hemna | no, it just calls create_attachment | 17:59 |
| mriedem | and i thought initialize/attach were 1 api that n-cpu would call | 17:59 |
| hemna | https://review.openstack.org/#/c/327408/ | 17:59 |
| hemna | read the commit message | 17:59 |
| johnthetubaguy | so in the API we want to error early if there are issues, but most of the time there will be no issues, so maybe its OK | 17:59 |
| ildikov | hmm, I thought we keep reserve_volume there to ensure Nova gets the green/red light early on and then let the heavier flow complete later | 17:59 |
| hemna | it replaces 1. 2. 3 with create_attachment() | 17:59 |
| mriedem | hemna: https://review.openstack.org/#/c/330285/6/nova/compute/api.py | 17:59 |
| johnthetubaguy | ildikov: right, thats where I was with that | 17:59 |
| mriedem | that's not what the nova patch does today | 17:59 |
| hemna | johnthetubaguy, so if the volume is in a state where it can't attach, it will still error early | 17:59 |
| mriedem | it still calls reserve | 17:59 |
| ildikov | hemna: I think jgriffith said at a certain point that reserve_volume might stay, but he didn't update the commit message | 18:00 |
| jgriffith | sorry... just got back to desk | 18:00 |
| johnthetubaguy | hemna: its about the API returning really quickly always | 18:00 |
| johnthetubaguy | so we can call it in the API | 18:00 |
| hemna | the issue comes up when the volume can be attached, then c-api RPC's to c-vol to initialize_connection and then calls the cinder backend | 18:00 |
| jgriffith | so quick backscroll... :) | 18:00 |
| jgriffith | Yes, I save the connector info | 18:00 |
| ildikov | jgriffith: right in time, we ran out of the meeting time :) | 18:00 |
| hemna | I just wanted to raise that issue | 18:00 |
| hemna | as it's a change | 18:00 |
| jgriffith | Yes, plan to keep reserve | 18:00 |
| jgriffith | those thing are in the patch sets that are up | 18:00 |
| johnthetubaguy | cool, keeping that as a quick operation would really help us | 18:00 |
| johnthetubaguy | jgriffith: did you get that spec written up :) | 18:01 |
| ildikov | let's switch to the Cinder channel | 18:01 |
| jgriffith | Also, now that Ocata is open for biz I'm working on updates to finish those patches | 18:01 |
| ildikov | and see you next week for the meeting here! | 18:01 |
| scottda | Is there another meeting here | 18:01 |
| scottda | ? | 18:01 |
| hemna | jgriffith, ok cool. | 18:01 |
| jgriffith | sorry.. ok, cya in Cinder | 18:01 |
| scottda | We might not get booted out of this room... | 18:01 |
| johnthetubaguy | right, I was thinking someone would have told us off already | 18:01 |
| ildikov | scottda: I'm not sure, i don't have the calendar/meeting page open | 18:01 |
| johnthetubaguy | so I have to go cook my dinner really soon | 18:02 |
| scottda | ok, john already moved. | 18:02 |
| scottda | Don't forget to #endmeeting | 18:02 |
| johnthetubaguy | mostly because I am getting hungry... | 18:02 |
| scottda | ildikov: ^^^ | 18:03 |
| ildikov | johnthetubaguy: I have a plane to catch... :) | 18:03 |
| johnthetubaguy | ildikov: that totally wins | 18:03 |
| johnthetubaguy | (just) | 18:03 |
| ildikov | scottda: will do it now as the guys are chatting on the Cinder channel now, thanks for reminding! :) | 18:04 |
| ildikov | johnthetubaguy: :) | 18:04 |
| ildikov | #endmeeting | 18:04 |
| *** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings" | 18:04 | |
| openstack | Meeting ended Mon Sep 19 18:04:12 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 18:04 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/cinder_nova_api_changes/2016/cinder_nova_api_changes.2016-09-19-17.00.html | 18:04 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/cinder_nova_api_changes/2016/cinder_nova_api_changes.2016-09-19-17.00.txt | 18:04 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/cinder_nova_api_changes/2016/cinder_nova_api_changes.2016-09-19-17.00.log.html | 18:04 |
| *** diablo_rojo has quit IRC | 18:07 | |
| *** sdake_ has joined #openstack-meeting-cp | 18:23 | |
| *** sdake has quit IRC | 18:25 | |
| *** prateek_ has joined #openstack-meeting-cp | 18:27 | |
| *** tyr_ has joined #openstack-meeting-cp | 18:42 | |
| *** tyr_ has quit IRC | 18:45 | |
| *** piet has quit IRC | 19:11 | |
| *** piet has joined #openstack-meeting-cp | 19:17 | |
| *** prateek_ has quit IRC | 19:38 | |
| *** gouthamr has quit IRC | 19:41 | |
| *** _coolsvap_ has quit IRC | 19:42 | |
| *** sdake has joined #openstack-meeting-cp | 19:49 | |
| *** sdake_ has quit IRC | 19:52 | |
| *** diablo_rojo_phon has quit IRC | 20:25 | |
| *** diablo_rojo has joined #openstack-meeting-cp | 20:47 | |
| *** sdague has quit IRC | 20:57 | |
| *** rocky_g has joined #openstack-meeting-cp | 21:04 | |
| *** diablo_rojo has quit IRC | 21:06 | |
| *** sdague has joined #openstack-meeting-cp | 21:11 | |
| *** piet has quit IRC | 21:36 | |
| *** harlowja has quit IRC | 21:51 | |
| *** kencjohnston has quit IRC | 21:51 | |
| *** scottda has quit IRC | 21:51 | |
| *** kencjohnston has joined #openstack-meeting-cp | 21:51 | |
| *** scottda has joined #openstack-meeting-cp | 21:53 | |
| *** harlowja has joined #openstack-meeting-cp | 21:55 | |
| *** xyang1 has quit IRC | 22:03 | |
| *** rocky_g has quit IRC | 22:05 | |
| *** markvoelker has quit IRC | 22:36 | |
| *** mriedem has quit IRC | 22:41 | |
| *** hemna is now known as hemnafk | 23:00 | |
| *** kei has joined #openstack-meeting-cp | 23:03 | |
| *** kei__ has joined #openstack-meeting-cp | 23:04 | |
| *** kei_ has quit IRC | 23:04 | |
| *** kei has quit IRC | 23:07 | |
| *** kei__ has quit IRC | 23:28 | |
| *** kei has joined #openstack-meeting-cp | 23:29 | |
| *** sdague has quit IRC | 23:32 | |
| *** rhedlind has quit IRC | 23:43 | |
| *** rhedlind has joined #openstack-meeting-cp | 23:44 | |
| *** kei_ has joined #openstack-meeting-cp | 23:45 | |
| *** kei has quit IRC | 23:47 | |
| *** markvoelker has joined #openstack-meeting-cp | 23:48 | |
| *** markvoelker has quit IRC | 23:53 | |
| *** hogepodge has quit IRC | 23:53 | |
| *** hogepodge has joined #openstack-meeting-cp | 23:56 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!