| *** chatter has joined #openstack-meeting-cp | 00:30 | |
| *** chatter has quit IRC | 00:32 | |
| *** tovin07 has joined #openstack-meeting-cp | 00:48 | |
| *** beekhof has joined #openstack-meeting-cp | 00:49 | |
| *** tovin07_ has joined #openstack-meeting-cp | 00:49 | |
| *** tovin07 has quit IRC | 01:04 | |
| *** beekhof has quit IRC | 01:07 | |
| *** beekhof has joined #openstack-meeting-cp | 01:07 | |
| *** tovin07 has joined #openstack-meeting-cp | 01:17 | |
| *** zhurong has joined #openstack-meeting-cp | 01:27 | |
| *** tovin07_ has quit IRC | 02:05 | |
| *** tovin07_ has joined #openstack-meeting-cp | 02:08 | |
| *** markvoelker has joined #openstack-meeting-cp | 02:31 | |
| *** zhurong has quit IRC | 02:58 | |
| *** zhurong_ has joined #openstack-meeting-cp | 02:58 | |
| *** prateek has joined #openstack-meeting-cp | 05:51 | |
| *** alij has joined #openstack-meeting-cp | 06:50 | |
| *** zhurong_ has quit IRC | 06:56 | |
| *** zhurong has joined #openstack-meeting-cp | 06:57 | |
| *** gouthamr has joined #openstack-meeting-cp | 07:44 | |
| *** alij has quit IRC | 08:15 | |
| *** alij has joined #openstack-meeting-cp | 08:49 | |
| *** alij has quit IRC | 08:59 | |
| *** alij has joined #openstack-meeting-cp | 08:59 | |
| *** alij has quit IRC | 09:18 | |
| *** alij has joined #openstack-meeting-cp | 09:19 | |
| *** alij_ has joined #openstack-meeting-cp | 09:29 | |
| *** alij has quit IRC | 09:29 | |
| *** zhurong has quit IRC | 10:02 | |
| *** gouthamr has quit IRC | 10:07 | |
| *** alij_ has quit IRC | 10:08 | |
| *** gouthamr has joined #openstack-meeting-cp | 10:09 | |
| *** gouthamr has quit IRC | 10:09 | |
| *** gouthamr has joined #openstack-meeting-cp | 10:09 | |
| *** gouthamr has quit IRC | 10:12 | |
| *** gouthamr has joined #openstack-meeting-cp | 10:12 | |
| *** alij has joined #openstack-meeting-cp | 10:15 | |
| *** topol has quit IRC | 10:18 | |
| *** stevemar has quit IRC | 10:19 | |
| *** alij_ has joined #openstack-meeting-cp | 10:22 | |
| *** alij has quit IRC | 10:22 | |
| *** tovin07_ has quit IRC | 10:50 | |
| *** gouthamr has quit IRC | 10:57 | |
| *** alij_ has quit IRC | 11:12 | |
| *** alij has joined #openstack-meeting-cp | 11:13 | |
| *** alij has quit IRC | 11:26 | |
| *** alij has joined #openstack-meeting-cp | 11:26 | |
| *** kzaitsev_ws has quit IRC | 12:10 | |
| *** alij has quit IRC | 12:16 | |
| *** alij_ has joined #openstack-meeting-cp | 12:16 | |
| *** alij has joined #openstack-meeting-cp | 12:16 | |
| *** alij_ has quit IRC | 12:20 | |
| *** alij has quit IRC | 12:28 | |
| *** prateek has quit IRC | 12:39 | |
| *** gouthamr has joined #openstack-meeting-cp | 12:44 | |
| *** stvnoyes has quit IRC | 12:56 | |
| *** lamt has quit IRC | 12:58 | |
| *** alij has joined #openstack-meeting-cp | 13:17 | |
| *** dims has quit IRC | 13:33 | |
| *** dims has joined #openstack-meeting-cp | 13:44 | |
| *** stvnoyes has joined #openstack-meeting-cp | 13:47 | |
| *** stvnoyes has left #openstack-meeting-cp | 13:54 | |
| *** lamt has joined #openstack-meeting-cp | 14:00 | |
| *** prateek has joined #openstack-meeting-cp | 14:00 | |
| *** alij has quit IRC | 14:37 | |
| *** alij has joined #openstack-meeting-cp | 14:46 | |
| *** alij has quit IRC | 15:11 | |
| *** bknudson has joined #openstack-meeting-cp | 15:23 | |
| *** dims has quit IRC | 15:36 | |
| *** dims has joined #openstack-meeting-cp | 15:41 | |
| *** prateek_ has joined #openstack-meeting-cp | 15:50 | |
| *** xyang1 has joined #openstack-meeting-cp | 15:52 | |
| *** prateek has quit IRC | 15:53 | |
| *** tovin07 has quit IRC | 16:01 | |
| *** jklare has quit IRC | 16:01 | |
| *** sheeprine has quit IRC | 16:01 | |
| *** david-lyle has quit IRC | 16:01 | |
| *** ameade has quit IRC | 16:01 | |
| *** notmyname has quit IRC | 16:01 | |
| *** cebreidian has quit IRC | 16:01 | |
| *** zigo has quit IRC | 16:01 | |
| *** zigo has joined #openstack-meeting-cp | 16:01 | |
| *** sheeprine has joined #openstack-meeting-cp | 16:01 | |
| *** tovin07_ has joined #openstack-meeting-cp | 16:02 | |
| *** jklare has joined #openstack-meeting-cp | 16:02 | |
| *** david-lyle has joined #openstack-meeting-cp | 16:02 | |
| *** notmyname has joined #openstack-meeting-cp | 16:03 | |
| *** cebreidian has joined #openstack-meeting-cp | 16:03 | |
| *** gouthamr_ has joined #openstack-meeting-cp | 16:04 | |
| *** ameade has joined #openstack-meeting-cp | 16:05 | |
| *** gouthamr has quit IRC | 16:05 | |
| *** gouthamr_ is now known as gouthamr | 16:06 | |
| *** edtubill has joined #openstack-meeting-cp | 16:17 | |
| *** lyarwood has joined #openstack-meeting-cp | 16:20 | |
| *** alij has joined #openstack-meeting-cp | 16:28 | |
| *** stvnoyes has joined #openstack-meeting-cp | 16:50 | |
| *** alij has quit IRC | 16:51 | |
| ildikov | #startmeeting cinder-nova-api-changes | 17:00 |
|---|---|---|
| openstack | Meeting started Mon Nov 28 17:00:06 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 xyang1 raj_singh lyarwood | 17:00 |
| johnthetubaguy | o/ | 17:00 |
| ildikov | johnthetubaguy: hi :) | 17:01 |
| * ildikov wonders whether we will see any US people around after the long turkey weekend... :) | 17:01 | |
| *** mriedem has joined #openstack-meeting-cp | 17:02 | |
| * johnthetubaguy makes clucking noises and waggles his elbows (in his head) | 17:02 | |
| ildikov | LOL :) | 17:02 |
| ildikov | mriedem: did you have a chance to check on the reviews last week before the long w/e? | 17:03 |
| mriedem | nope | 17:03 |
| ildikov | mriedem: what about doing it now? | 17:04 |
| ildikov | mriedem: the remove check_attach is a smaller one | 17:04 |
| johnthetubaguy | so I don't think I have had a proper look at the cinder spec either, I should do that | 17:04 |
| ildikov | mriedem: and would be a nice cleanup to get it done IMHO | 17:05 |
| ildikov | johnthetubaguy: that's a fairly short one updated by me recently, so we can chat about that too | 17:05 |
| ildikov | johnthetubaguy: regarding the Cinder spec we have a call there with the functionality of reserving a volume and creating an empty attachment and another call that can create an attachment with all the info or update an existing empty attachment | 17:07 |
| ildikov | johnthetubaguy: I think the code might check currently whether the volume is reserved or not, but I would need to double check that to be sure | 17:08 |
| jgriffith | o/ | 17:09 |
| jgriffith | johnthetubaguy: the clucking noises drew me in | 17:09 |
| johnthetubaguy | :) | 17:10 |
| * ildikov thanks johnthetubaguy for the effective noises :) | 17:10 | |
| jgriffith | johnthetubaguy: the code will in fact check to see if it's already reserved | 17:11 |
| jgriffith | johnthetubaguy: and if so raise an exception | 17:11 |
| jgriffith | johnthetubaguy: ie if you try and do a simultaneous reserve | 17:11 |
| johnthetubaguy | that sounds like it all makes sense | 17:12 |
| johnthetubaguy | just got my head in the spec | 17:12 |
| ildikov | johnthetubaguy: I added a few notes to the attachment-reserve based on the last week's discussion and also jaypipes had a comment on that one earlier regarding the name vs functionality | 17:13 |
| ildikov | johnthetubaguy: jgriffith: if we can agree on the functionality that would be pretty great | 17:13 |
| johnthetubaguy | I thought jay's comments were around shelve, which is a bit orthogonal, but maybe I forgot some of them. | 17:14 |
| ildikov | johnthetubaguy: jgriffith: we can then finalize the names and get some code merged | 17:14 |
| ildikov | johnthetubaguy: he had a few comments on the Cinder spec too, I meant those | 17:14 |
| jgriffith | johnthetubaguy: he also had some comments about if/why we would even want the reserve call | 17:14 |
| johnthetubaguy | the nova spec tried to cover why its needed, mostly around a better user experience | 17:15 |
| ildikov | I think his point was that we reserve the volume in an attachment-reserve call, which is a bit of a mismatch | 17:15 |
| jgriffith | ildikov: yeah, that too :) | 17:15 |
| ildikov | jgriffith: just sayin' :) | 17:16 |
| jgriffith | ildikov: hey.. that's my "catch phrase" :) | 17:16 |
| johnthetubaguy | well depends if you consider the volume attached to both a host and an instance I guess | 17:17 |
| jgriffith | I personally like the name just fine, it reserves an attachment for the volume | 17:17 |
| ildikov | jgriffith: oooops :) | 17:17 |
| johnthetubaguy | its not clear from the spec how this relates to REST like resources, just thinking about if we are following the API wg guidelines | 17:17 |
| jgriffith | we have sort of discussed this as a group at nauseam | 17:17 |
| johnthetubaguy | right, I would like to get it written down in a way we can all say, yes thats what we agree | 17:19 |
| jgriffith | johnthetubaguy: roger | 17:19 |
| ildikov | johnthetubaguy: do we know already what is what we all agree? | 17:19 |
| johnthetubaguy | writing it down often helps | 17:20 |
| ildikov | johnthetubaguy: I'm more than happy to write it down, or draw it or create a statue for it or whatever that keeps people satisfied... | 17:20 |
| johnthetubaguy | so the Nova spec tried to cover all the details of both sides | 17:21 |
| ildikov | johnthetubaguy: is your spec matching with what is written today in the Cinder spec? | 17:21 |
| ildikov | johnthetubaguy: more regarding functionality than the names just to try to start with smth solid | 17:21 |
| johnthetubaguy | honestly, the only difference seems to be around slightly different structure of the REST API calls, which I care much less about than the functionality | 17:22 |
| hemna | hey | 17:22 |
| ildikov | johnthetubaguy: I think last time we said something like don't always create new attachments, etc. | 17:22 |
| ildikov | johnthetubaguy: I think at least the Cinder side currently handles things more like that model, but jgriffith can correct me based on the code | 17:23 |
| ildikov | hemna: hi | 17:23 |
| hemna | still doing my morning coffee here | 17:24 |
| hemna | what are we arguing over today? :P | 17:24 |
| ildikov | hemna: we are trying to get there to agree on the API functionality regarding Cinder and have our heads around the specs on both sides | 17:24 |
| jgriffith | ildikov: I'm not completely sure, I'll have to look at the deltas johnthetubaguy 's is pointing out | 17:24 |
| johnthetubaguy | ildikov: rather than create a new attachment, just update the existing one with a empty connector, etc, yeah, that bit is missing | 17:24 |
| jgriffith | johnthetubaguy: oh... | 17:25 |
| jgriffith | johnthetubaguy: so yeah; the attachment-create fulfills that | 17:25 |
| ildikov | jgriffith: I think it's more what we discussed last week | 17:25 |
| jgriffith | ildikov: +1 | 17:25 |
| ildikov | jgriffith: I linked the meeting log to the Cinder spec | 17:25 |
| ildikov | jgriffith: but the create updates only if the volume is in "reserved" state right? | 17:26 |
| jgriffith | johnthetubaguy: ildikov I guess I'm open to changing the naming conventions there; but I personally liked the reserve/create semantics and using an existing attachment object if provided | 17:26 |
| johnthetubaguy | so if create can be called with only the volume_id and instance_uuid, and returns an attachment_id, it seems like we don't need reserved I guess? | 17:26 |
| jgriffith | johnthetubaguy: right, but we needed it for things like BFV where you don't have a connector and you need the volume | 17:26 |
| johnthetubaguy | I dunno, I just think a regular CRUD REST API would be simpler | 17:27 |
| jgriffith | johnthetubaguy: otherwise we end up back at V1 :) | 17:27 |
| hemna | jgriffith, +1 | 17:27 |
| jgriffith | johnthetubaguy: I'm open, can you ellaborate? | 17:27 |
| ildikov | BTW if in any point in time you feel the need to talk as opposed to write I can create a Hangouts link | 17:27 |
| johnthetubaguy | so where is /attachments going? is its volume/{uuid}/attachments ? | 17:28 |
| johnthetubaguy | this might be easier in text, for the REST thing | 17:28 |
| jgriffith | johnthetubaguy: it goes to attachments | 17:28 |
| ildikov | johnthetubaguy: was just a side note, you know, just in case :) | 17:28 |
| johnthetubaguy | I mean the URL, what does it look like? | 17:28 |
| jgriffith | johnthetubaguy: so the "attachment_create" is sort of different if you don't provide an Attachment UUID it creates one for you | 17:29 |
| johnthetubaguy | so you are POST ing to some URL I assume, what is the URL? | 17:29 |
| jgriffith | johnthetubaguy: sorry... | 17:31 |
| jgriffith | johnthetubaguy: so yeah; /attachments/attachment | 17:31 |
| johnthetubaguy | I am basically trying to check if the cinder spec/design conforms with what is here: https://specs.openstack.org/openstack/api-wg/guidelines/uri.html#general-advice-on-uri-design | 17:31 |
| jgriffith | that attachment body has either a volume.uuid or a attachment.uuid | 17:32 |
| johnthetubaguy | and this bit: https://specs.openstack.org/openstack/api-wg/guidelines/http.html#http-methods | 17:32 |
| jgriffith | johnthetubaguy: on the Get and Delete yes... but the attachment-create call is kinda goofy | 17:32 |
| jgriffith | johnthetubaguy: but it does conform to that POST definition | 17:33 |
| jgriffith | johnthetubaguy: ildikov if it makes things better/easier I'm happy to break that into to calls; the create and an update | 17:33 |
| jgriffith | johnthetubaguy: ildikov in which case I think it would solve the confusion and potential issues around the API guidelines (confusion==my-code-being-confusing) | 17:34 |
| ildikov | jgriffith: in addition to reserve or we drop reserve in that case? | 17:34 |
| jgriffith | ildikov: we need to keep reserve based on discussions we'v had in the past | 17:34 |
| johnthetubaguy | PUT attachement/{uuid} might do the create or update you want | 17:34 |
| johnthetubaguy | ah, but not really, you would have to pick the uuid, which is nuts | 17:34 |
| jgriffith | johnthetubaguy: yeah; the problem is the way I do it currently there's a hack to make it so you don't need the attachment UUID | 17:35 |
| jgriffith | johnthetubaguy: so yes, I'm saying I'll rework it to do what you want | 17:35 |
| jgriffith | johnthetubaguy: or, what the guides says I should do to make it more correct | 17:35 |
| johnthetubaguy | yeah, I think following that pattern would be good | 17:36 |
| ildikov | jgriffith: less arguing on naming at least | 17:36 |
| hemna | and for bare metal attaches, or non nova/ironic attaches the caller just creates a UUID to pass in and they have to track it? | 17:36 |
| johnthetubaguy | honestly the POST method to create and the update are probably calling the same code largely, so its probably not a big deal | 17:36 |
| johnthetubaguy | so I guess I was expecting to list attachments by doing GET volume/{uuid}/attachments or /attachments?volume_uuid={uuid}&host_uuid={host_uuid} etc | 17:37 |
| ildikov | hemna: I guess if create has the connector than it can do the whole magic | 17:37 |
| ildikov | hemna: and they get back the attachment_id as in the current version | 17:38 |
| jgriffith | hemna: no, there will still be an option to do that | 17:38 |
| hemna | ok | 17:38 |
| jgriffith | ildikov: +1 | 17:38 |
| johnthetubaguy | right, the create call, whatever it is, should be able to do the full operation in one shot | 17:38 |
| hemna | for example, there are other projects that are now starting to look at doing local cinder volume attaches | 17:38 |
| hemna | https://review.openstack.org/#/c/385880/ | 17:39 |
| hemna | fyi | 17:39 |
| ildikov | johnthetubaguy: do we still want to get an attachment_id back from the reserve call? | 17:39 |
| ildikov | johnthetubaguy: I mean Nova :) | 17:39 |
| jgriffith | ildikov: johnthetubaguy I'l answer *yes* | 17:39 |
| jgriffith | ildikov: johnthetubaguy it's for tracking around in Cinder | 17:39 |
| ildikov | jgriffith: just checkin' :) | 17:40 |
| johnthetubaguy | I am find with create-attachment taking only instance-uuid and volume-uuid, rather than a specific reserve call, but it seems like all the same thing | 17:40 |
| jgriffith | ildikov: johnthetubaguy removes the need for trying to guess in a multi-attach scenario and gives us an authoritative reference | 17:40 |
| johnthetubaguy | right, Nova still need to know about multi-attach, but its just a property that changes how we attach the volume, rather than something we need to code up in the API | 17:41 |
| ildikov | jgriffith: right, seems more bullet proof | 17:41 |
| jgriffith | johnthetubaguy: we need the reserve for special cases. So just to be clear; and I'll work with ildikov to update the Cinder spec | 17:41 |
| jgriffith | johnthetubaguy: ildikov we'll have: | 17:42 |
| jgriffith | 1. attachment_reserve (creates empty attachment and returns the UUID of attachment record) | 17:42 |
| jgriffith | 2. attachment_update (takes the connector and finalizes things when you're ready for it and works off of an attachment UUID only) | 17:43 |
| jgriffith | 3. Something else for folks that want an ALL in One create-attachment, and finalize | 17:43 |
| ildikov | if we are aiming for CRUD, wouldn't it be reserve and create? | 17:43 |
| jgriffith | whether item 1 or item 3 should be CREATE or both should be is another question | 17:44 |
| johnthetubaguy | seems like create could do the all in one operation | 17:44 |
| ildikov | and update for cases, when we need to update the connector as Nova has some weird use cases to keep the whole world happy? | 17:44 |
| ildikov | and others just don't use update as it does not make any sense for them I guess | 17:44 |
| jgriffith | johnthetubaguy: well it does currently, but it was pointed out that didn't follow the CRUD guidelines :) | 17:44 |
| johnthetubaguy | its more that update wasn't separate for me | 17:45 |
| johnthetubaguy | create can setup *everything* thats totally fine | 17:45 |
| jgriffith | johnthetubaguy: ahh! | 17:45 |
| jgriffith | johnthetubaguy: ok, great, we have a plan then | 17:45 |
| ildikov | johnthetubaguy: +1 | 17:45 |
| hemna | that sounds good | 17:45 |
| jgriffith | a reserve, create and update | 17:45 |
| jgriffith | I'll update that happily | 17:46 |
| johnthetubaguy | so don't shoot me, but... | 17:46 |
| jgriffith | haha | 17:46 |
| * hemna locks and loads.... | 17:46 | |
| johnthetubaguy | reserve, thats just a create with connector=None? | 17:46 |
| jgriffith | johnthetubaguy: yes | 17:47 |
| jgriffith | johnthetubaguy: that's the problem | 17:47 |
| johnthetubaguy | so we can just have create and update then (along with get and delete) | 17:47 |
| ildikov | johnthetubaguy: I would say with no connector and no attachment_id | 17:47 |
| jgriffith | johnthetubaguy: works for me | 17:47 |
| johnthetubaguy | ildikov: create never takes attachment_id right? thats update | 17:47 |
| ildikov | so create will "lock" the volume in this case? | 17:48 |
| johnthetubaguy | jgriffith: cool | 17:48 |
| johnthetubaguy | ildikov: in every case where you specify and instance_uuid on create | 17:48 |
| johnthetubaguy | ildikov: just sometimes it does everything | 17:48 |
| jgriffith | so we have attachment_create; and that can be called as a reserve, or as a "do everything for me" and returns an attachment UUID | 17:48 |
| johnthetubaguy | yeah | 17:49 |
| ildikov | johnthetubaguy: I'm just asking from Nova perspective as I guess we would call create without connector from the API and update from the compute | 17:49 |
| jgriffith | we can then have an update for those that were just a reserve to provide a connector and finish things off | 17:49 |
| johnthetubaguy | cool | 17:49 |
| hemna | +1 | 17:49 |
| ildikov | jgriffith: that's how I meant, cool :) | 17:49 |
| johnthetubaguy | also, when we reschedule a build, we can just update the connector to None when we detach? | 17:49 |
| jgriffith | ildikov: does that sound good to you? | 17:49 |
| jgriffith | ok | 17:49 |
| jgriffith | alright, let's knock this thing out this week!!! | 17:50 |
| ildikov | and that's why I asked earlier whether we really need a "reserve" :) | 17:50 |
| jgriffith | ildikov: yea, we need it for bfv and some other cases | 17:50 |
| jgriffith | ha | 17:50 |
| jgriffith | but now we just fold it into create | 17:50 |
| *** prateek_ has quit IRC | 17:50 | |
| hemna | so what is Nova going to do in the API ? call create w/o an ID and that means reserve? | 17:50 |
| johnthetubaguy | yeah | 17:50 |
| jgriffith | I'm too hung up on what it's doing as opposed to the naming | 17:50 |
| hemna | ok cool | 17:50 |
| jgriffith | hemna: johnthetubaguy I think you mean "create without a connector" | 17:51 |
| johnthetubaguy | yup | 17:51 |
| jgriffith | which internally results in a reserve | 17:51 |
| johnthetubaguy | has instance_uuid | 17:51 |
| johnthetubaguy | no connector, no host_uuid | 17:52 |
| ildikov | jgriffith: what is the next dessert on the list? :) | 17:52 |
| jgriffith | johnthetubaguy: yes | 17:52 |
| jgriffith | ildikov: LOL | 17:52 |
| jgriffith | ApplePie | 17:52 |
| hemna | ok cool yah | 17:52 |
| ildikov | jgriffith: just t not deal with the names but what we want it to do | 17:52 |
| ildikov | jgriffith: with vanilla ice cream; it works :) | 17:52 |
| hemna | French Vanilla | 17:53 |
| ildikov | hemna: only the best, I'm not negotiating on important things like this :) | 17:53 |
| johnthetubaguy | so update, there is a bit about changing the host from last week | 17:54 |
| johnthetubaguy | I think we just call with a None connector, to say we detached and are starting to trying somewhere new | 17:54 |
| johnthetubaguy | and a None host_uuid | 17:54 |
| ildikov | johnthetubaguy: changing the host as rebuild or evacuate? | 17:55 |
| johnthetubaguy | (the alternative being create a new attachment, and delete the old one) | 17:55 |
| jgriffith | johnthetubaguy: I'd prefer delete/create if it works for you | 17:55 |
| johnthetubaguy | ildikov: this is specific to reschedule after an error during the initial build | 17:55 |
| jgriffith | johnthetubaguy: but we could try and do something clever and fold it into the update | 17:55 |
| ildikov | johnthetubaguy: yeap, that would've been my third guess, tnx | 17:56 |
| johnthetubaguy | jgriffith: I think I am fine leaving that for a v2 | 17:56 |
| jgriffith | johnthetubaguy: I guess there's no reason not to allow update to take a connector and resetting things | 17:56 |
| jgriffith | johnthetubaguy: I'll look at it when I get to that code and see if it's trivial and clear without overloading the heck out of the api call | 17:56 |
| johnthetubaguy | personally I find delete/create simpler to reason about, but I think other nova folks preferred the update to do the reset | 17:56 |
| johnthetubaguy | jgriffith: sounds cool | 17:57 |
| jgriffith | johnthetubaguy: yes, I definitely prefer delete/create | 17:57 |
| jgriffith | but certainly willing to look at update if it makes everybody happy | 17:57 |
| johnthetubaguy | I think form our BDM point of view, its nice to keep the same attachment id across the "fiddling", but I know there are cases where we can't | 17:57 |
| johnthetubaguy | it feels like an optimisation we can discuss later myself | 17:57 |
| johnthetubaguy | yeah | 17:58 |
| ildikov | johnthetubaguy: from cleanup perspective update sounds fine, but I guess at this point it's purely Nova's choice how to use the Cinder API | 17:58 |
| ildikov | I mean if we have create and update separately then we can either create a new attachment or just update the existing | 17:58 |
| ildikov | does Nova return any id to the user from the API or it's fully internal? | 17:59 |
| ildikov | johnthetubaguy: ^ | 17:59 |
| johnthetubaguy | not sure actually | 18:00 |
| johnthetubaguy | I think there is something | 18:00 |
| johnthetubaguy | http://developer.openstack.org/api-ref/compute/?expanded=list-volume-attachments-for-an-instance-detail | 18:01 |
| johnthetubaguy | so you will love this... our attachment id is the volume id | 18:01 |
| jgriffith | doh | 18:01 |
| johnthetubaguy | luckily is scoped per server, so its not a big deal | 18:02 |
| johnthetubaguy | so I think we made progress there | 18:03 |
| johnthetubaguy | but we are out of time | 18:03 |
| johnthetubaguy | and I need to head off to drop my car in for a new timing belt | 18:03 |
| ildikov | johnthetubaguy: if it's the API response then I guess it's slightly ugly to update the attachment_id on a retry | 18:03 |
| johnthetubaguy | ildikov: its OK, we use the volume uuid | 18:03 |
| johnthetubaguy | ildikov: we don't currently store the attachment-id anywhere, mostly as it may not exist right now | 18:04 |
| ildikov | johnthetubaguy: but that's not the Cinder API's problem, so I approve you go and take care of the car | 18:04 |
| johnthetubaguy | I think we are good with the crud on attachments above | 18:04 |
| ildikov | johnthetubaguy: well, we ask Cinder for it every time it's used for detach | 18:04 |
| johnthetubaguy | right, it would be nice if we new which one we are detaching before that | 18:05 |
| ildikov | johnthetubaguy: the CRUD Cinder API will give the chance the Nova to use it in the right way I think | 18:05 |
| ildikov | johnthetubaguy: I'll try to get myself friends with the thought of touching the BDM... | 18:06 |
| jgriffith | ildikov: johnthetubaguy I have a patch that stuffs it in the bdm already | 18:06 |
| jgriffith | would assume we'd continue with that | 18:06 |
| jgriffith | easily solvable :) | 18:06 |
| johnthetubaguy | it should be fine | 18:07 |
| ildikov | jgriffith: you're my hero! :) | 18:07 |
| ildikov | jgriffith: I'll check it this week | 18:07 |
| johnthetubaguy | there is the migration plan for upgrades, where we update attachments via cinder manage, but thats for another day | 18:07 |
| jgriffith | LOL | 18:07 |
| ildikov | johnthetubaguy: you're the one who has to run :) | 18:07 |
| johnthetubaguy | true... | 18:08 |
| johnthetubaguy | I should go before I get too hungry really | 18:08 |
| ildikov | johnthetubaguy: I didn't want to chase you away really | 18:08 |
| ildikov | ok, let's do the spec and code updates this week | 18:09 |
| ildikov | I think we are in an agreement so far | 18:09 |
| hemna | yup | 18:10 |
| hemna | lets rock this one out finally | 18:10 |
| ildikov | you can correct me if I got it wrong but I would prefer not to :) | 18:10 |
| ildikov | hemna: +1 :) | 18:10 |
| ildikov | anything else from anyone for today? | 18:10 |
| ildikov | all right, thank you all | 18:12 |
| ildikov | have a nice rest of the day! | 18:12 |
| ildikov | #endmeeting | 18:12 |
| *** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings" | 18:12 | |
| openstack | Meeting ended Mon Nov 28 18:12:21 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 18:12 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/cinder_nova_api_changes/2016/cinder_nova_api_changes.2016-11-28-17.00.html | 18:12 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/cinder_nova_api_changes/2016/cinder_nova_api_changes.2016-11-28-17.00.txt | 18:12 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/cinder_nova_api_changes/2016/cinder_nova_api_changes.2016-11-28-17.00.log.html | 18:12 |
| *** piet has joined #openstack-meeting-cp | 18:17 | |
| *** piet has quit IRC | 18:22 | |
| *** piet has joined #openstack-meeting-cp | 18:56 | |
| *** jgriffith is now known as jgriffith_away | 19:02 | |
| *** piet has quit IRC | 20:13 | |
| *** jgriffith_away is now known as jgriffith | 20:18 | |
| *** piet has joined #openstack-meeting-cp | 20:30 | |
| *** lamt has quit IRC | 22:05 | |
| *** lamt has joined #openstack-meeting-cp | 22:10 | |
| *** mriedem has left #openstack-meeting-cp | 22:23 | |
| *** zigo has quit IRC | 22:29 | |
| *** xyang1 has quit IRC | 22:29 | |
| *** zigo has joined #openstack-meeting-cp | 22:36 | |
| *** edtubill has quit IRC | 22:42 | |
| *** gouthamr has quit IRC | 22:50 | |
| *** lamt has quit IRC | 23:18 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!