| *** lbragstad has joined #openstack-meeting-cp | 00:37 | |
| *** lbragstad has quit IRC | 01:42 | |
| *** diablo_rojo has quit IRC | 01:46 | |
| *** diablo_rojo has joined #openstack-meeting-cp | 02:19 | |
| *** Rockyg has joined #openstack-meeting-cp | 02:37 | |
| *** Rockyg has quit IRC | 02:37 | |
| *** edmondsw has joined #openstack-meeting-cp | 02:55 | |
| *** edmondsw has quit IRC | 02:59 | |
| *** gagehugo has left #openstack-meeting-cp | 03:02 | |
| *** aselius has quit IRC | 04:32 | |
| *** diablo_rojo has quit IRC | 05:34 | |
| *** MarkBaker has joined #openstack-meeting-cp | 08:55 | |
| *** sdague has joined #openstack-meeting-cp | 10:11 | |
| *** MarkBaker has quit IRC | 10:20 | |
| *** markvoelker has quit IRC | 10:27 | |
| *** markvoelker has joined #openstack-meeting-cp | 10:27 | |
| *** edmondsw has joined #openstack-meeting-cp | 11:40 | |
| *** jroll has left #openstack-meeting-cp | 12:47 | |
| *** MarkBaker has joined #openstack-meeting-cp | 13:23 | |
| *** lbragstad has joined #openstack-meeting-cp | 14:14 | |
| *** felipemonteiro_ has joined #openstack-meeting-cp | 14:18 | |
| *** diablo_rojo has joined #openstack-meeting-cp | 14:27 | |
| *** felipemonteiro__ has joined #openstack-meeting-cp | 14:30 | |
| *** felipemonteiro_ has quit IRC | 14:34 | |
| *** aselius has joined #openstack-meeting-cp | 14:46 | |
| *** ashishb has quit IRC | 15:04 | |
| *** MarkBaker has quit IRC | 15:06 | |
| *** lbragstad has quit IRC | 15:08 | |
| *** MarkBaker has joined #openstack-meeting-cp | 15:18 | |
| *** MarkBaker has quit IRC | 15:31 | |
| *** jgriffith_ is now known as jgriffith | 15:36 | |
| *** MarkBaker has joined #openstack-meeting-cp | 15:46 | |
| *** mriedem has joined #openstack-meeting-cp | 15:56 | |
| *** lbragstad has joined #openstack-meeting-cp | 15:57 | |
| ildikov | #startmeeting cinder-nova-api-changes | 16:00 |
|---|---|---|
| openstack | Meeting started Thu Jun 8 16:00:06 2017 UTC and is due to finish in 60 minutes. The chair is ildikov. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:00 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:00 |
| *** openstack changes topic to " (Meeting topic: cinder-nova-api-changes)" | 16:00 | |
| openstack | The meeting name has been set to 'cinder_nova_api_changes' | 16:00 |
| mriedem | o/ | 16:00 |
| 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 jungleboyj | 16:00 |
| stvnoyes | o/ | 16:00 |
| pewp | hemna (=ﾟωﾟ)ﾉ | 16:00 |
| johnthetubaguy | o/ | 16:00 |
| ildikov | hi :) | 16:01 |
| jgriffith | o/ | 16:01 |
| ildikov | ok, let's start | 16:01 |
| mriedem | you don't have stvnoyes in your list | 16:02 |
| mriedem | and should probably remove alaski :) | 16:02 |
| ildikov | mriedem: will update, tnx :) | 16:02 |
| ildikov | so the open reviews are looking good: https://review.openstack.org/#/q/topic:bp/cinder-new-attach-apis | 16:03 |
| ildikov | we have two patches on the gate to handle the microversion discovery, tnx to mriedem and all the reviewers | 16:03 |
| ildikov | the attach PoC is under continuous updates | 16:04 |
| mriedem | stvnoyes: i think we can abandon https://review.openstack.org/#/c/471142/ | 16:04 |
| ildikov | stvnoyes: were you be able to test live_migrate at all with that one? | 16:04 |
| stvnoyes | agreed | 16:04 |
| mriedem | changing course on the live migration stuff, | 16:05 |
| mriedem | going to try the LiveMigrateData object to stash the old volume attachment ids | 16:05 |
| mriedem | during the live migration | 16:05 |
| stvnoyes | i am testing migrate now with the new approach of having the old attach info in the migrate_data. that seems to be working ok with one small problem that i'm tracking down now | 16:05 |
| stvnoyes | some strange problem with os-brick. i haven't confirmed this, but it doesn't seem to like having the 'serial' value in connection_info | 16:06 |
| hemna | have any logs ? | 16:06 |
| stvnoyes | during connect | 16:06 |
| ildikov | stvnoyes: isn't it another cast issue? | 16:07 |
| stvnoyes | well, I am doing connects right now with and with that and when I seem to get a pattern I'll let you know | 16:07 |
| hemna | ok, let me know if I can fix something | 16:07 |
| stvnoyes | no, no exceptions, the volume is just not seen from within the vm | 16:07 |
| stvnoyes | ^ with and withOUT that... | 16:07 |
| hemna | maybe pastebin some logs at the time os-brick is called and returns | 16:07 |
| stvnoyes | ok | 16:08 |
| stvnoyes | just hit this within the last hour | 16:08 |
| hemna | with debug logging on, you should be able to see what os-brick returns from connect_volume back to nova | 16:08 |
| stvnoyes | ok | 16:09 |
| hemna | ping me if you any help. | 16:09 |
| johnthetubaguy | in the new flow, I guess we call os-brick more often? like when you create the second attachment? | 16:09 |
| johnthetubaguy | ignore more, I should re-read that | 16:09 |
| stvnoyes | I think it's the same # of times calling, this is during pre-live_migration where you connect to the vol on the dest | 16:10 |
| johnthetubaguy | ignore me that was meant to say | 16:10 |
| johnthetubaguy | yeah, I forgot about the stashed connect_info's | 16:10 |
| stvnoyes | btw, what is the purpose of 'serial'? | 16:10 |
| stvnoyes | it has the volume_id in it | 16:11 |
| mriedem | not sure, i've wondered that over time too | 16:11 |
| hemna | I'm unfamiliar with that | 16:11 |
| jgriffith | stvnoyes that's an *excellent* question :) | 16:11 |
| stvnoyes | ;-) I guess I'm not alone | 16:11 |
| ildikov | mriedem: haven't we all... | 16:11 |
| jgriffith | stvnoyes I've never figured out why that's there as an additional volume_id arg | 16:12 |
| mriedem | it's a libvirt thing | 16:12 |
| mriedem | set in LibvirtConfigGuestDisk | 16:12 |
| hemna | the cryptsetup stuff uses it for some reason | 16:13 |
| johnthetubaguy | its the thing we connect the VM to, I guess? | 16:13 |
| hemna | https://github.com/openstack/os-brick/blob/master/os_brick/encryptors/cryptsetup.py#L51 | 16:13 |
| stvnoyes | anyways, I think i'm very close to getting this migrate work up for review. the unit tests are done... Just one last thing... :-) | 16:13 |
| mriedem | hemna: probably just b/c it knows it's the volume id | 16:13 |
| hemna | only place it's accessed afaik | 16:13 |
| mriedem | no it's also used in the libvirt driver | 16:14 |
| mriedem | during snapshot | 16:14 |
| mriedem | _volume_snapshot_create | 16:14 |
| ildikov | stvnoyes: never say 'just one last thing' out loud! :) | 16:14 |
| mriedem | for the glusterfs stuff | 16:14 |
| hemna | ah ok, I wasn't looking in the nova code | 16:14 |
| mriedem | which we've removed now, but... | 16:14 |
| stvnoyes | let me work on this more. it's too early to dive too deep on this yet | 16:14 |
| stvnoyes | ildikov- that's why the smile is there... | 16:15 |
| stvnoyes | :-) | 16:15 |
| mriedem | "If present, this specify serial number of virtual hard drive. For example, it may look like <serial>WD-WMAP9A966149</serial>. Not supported for scsi-block devices, that is those using disk type 'block' using device 'lun' on bus 'scsi'. Since 0.7.1" | 16:15 |
| ildikov | stvnoyes: last time I hit iscsiadm issues in my test env for instance, so there's always something that's odd at least in my env with attach... | 16:15 |
| mriedem | https://libvirt.org/formatdomain.html#elementsDisks | 16:16 |
| ildikov | stvnoyes: it's still a pretty thin line :) | 16:16 |
| stvnoyes | thanks mriedem - this makes sense - serial - If present, this specify serial number of virtual hard drive. | 16:17 |
| mriedem | i don't think nova makes any distinction for "Not supported for scsi-block devices, that is those using disk type 'block' using device 'lun' on bus 'scsi'." though | 16:17 |
| mriedem | nova just always sets it i think | 16:17 |
| jgriffith | mriedem it does, and uses the cinder volume-id in the case of block type | 16:18 |
| stvnoyes | with John's new attach patch, it's not set during attach (which works ok). | 16:18 |
| stvnoyes | though I am not suing John's latest | 16:19 |
| stvnoyes | using | 16:19 |
| mriedem | i can ask some libvirt/kvm people about serial | 16:19 |
| jgriffith | I mean "it does not distinguish" | 16:19 |
| stvnoyes | it's OK, let me verify i's the problem first. | 16:19 |
| jgriffith | stvnoyes I will look and see if the latest has any more *missing* translations of that | 16:19 |
| jgriffith | stvnoyes during attach I explicitly check if that exists and if it doesn't, set it to volume-id | 16:20 |
| johnthetubaguy | I think serial is just a thing the virtual device exposes to the guest, right? | 16:20 |
| stvnoyes | let's move on since I think it's still too early in my debugging of this. | 16:22 |
| mriedem | anyway | 16:22 |
| mriedem | i've asked kashyap who will probably ask qemu devs | 16:23 |
| mriedem | has there been any movement on the swap volume questions on the cinder side? | 16:23 |
| mriedem | or is that no longer a question/issue? | 16:23 |
| ildikov | stvnoyes: do you see this issue only with live_migrate? | 16:23 |
| ildikov | mriedem: the idea now is to re-write swap for the new flow | 16:23 |
| ildikov | on both sides | 16:23 |
| ildikov | we just wanted to make attach work before doing that | 16:24 |
| mriedem | ildikov: that's kind of a chicken and egg though, | 16:24 |
| ildikov | so we can test what we're doing | 16:24 |
| ildikov | mriedem: you mean from merging perspective? | 16:24 |
| mriedem | i thought we were going to do swap before the attach change at the very end | 16:24 |
| mriedem | swap keys off if the volume that is attached, and being swapped from, was attached with the new api flow | 16:25 |
| mriedem | https://review.openstack.org/#/c/456971/6/nova/compute/api.py | 16:25 |
| ildikov | that's an old review | 16:27 |
| mriedem | well, | 16:27 |
| mriedem | it's the only review | 16:27 |
| mriedem | for swap | 16:27 |
| ildikov | I mean since then we realized that the migration_completion stuff on the Cinder side will not work either so we need to re-think this | 16:27 |
| mriedem | so now we're talking about a new cinder api microversion for swap? | 16:27 |
| mriedem | right, so i'm asking, has it been re-thought :) | 16:27 |
| ildikov | we will look into this with jgriffith soon I think | 16:27 |
| ildikov | as attach is operational enough for testing now, except a few cleanups | 16:28 |
| mriedem | today is p-2 so if there needs to be a new cinder api, it's getting late for pike | 16:28 |
| johnthetubaguy | this is blocking us turning on the new API right? | 16:28 |
| mriedem | yes | 16:28 |
| jgriffith | I don't think there's a need for a new API to simplify that | 16:28 |
| mriedem | because swap won't handle new style attachments othrewise | 16:28 |
| johnthetubaguy | right, ideally the new and old volumes each have a separate attachment during the swap, because nova has two attachments | 16:28 |
| ildikov | mriedem: +1 | 16:29 |
| * jgriffith will look at it again today | 16:29 | |
| jgriffith | I think there's some confusion also because there's two types of swap | 16:29 |
| jgriffith | Literally swap a-->b using libvirts copy function | 16:29 |
| johnthetubaguy | cinder started and Nova API started with a different volume | 16:29 |
| jgriffith | and the swap associated with migration | 16:29 |
| jgriffith | they're two very different things | 16:29 |
| johnthetubaguy | right, we are talking about the first one right? | 16:30 |
| johnthetubaguy | the Nova swap_volume API? | 16:30 |
| mriedem | they both result in the libvirt driver doing the blockRebase though right? | 16:30 |
| jgriffith | so that's easy | 16:30 |
| jgriffith | mriedem yes | 16:30 |
| mriedem | who initiates them is what impacts the migration_completion callback to cinder | 16:30 |
| mriedem | and i believe is the pickle | 16:30 |
| johnthetubaguy | ah, so its the same two things I am thinking about, just different names | 16:30 |
| mriedem | today if cinder didn't initiate, it just ignores the migration_completion callback i think | 16:30 |
| jgriffith | mriedem yes, but in the first case the callback is a noop anyway so can just go away | 16:31 |
| jgriffith | the second case is a mess, and I honestly haven't come up with an answer for it as of yet | 16:31 |
| johnthetubaguy | I thought the only difference is the result volume-uuid for the thing thats left attached at the end? | 16:31 |
| jgriffith | johnthetubaguy yes, the second case does a swap of the volume-uuid to make it an "invisible" thing | 16:31 |
| mriedem | jgriffith: sure, it can't go away on the nova side w/o us knowing if we should call it or not though, is our problem | 16:31 |
| jgriffith | which is stupid IMO | 16:31 |
| jgriffith | mriedem but Nova already has all of the control on that | 16:32 |
| jgriffith | (in the first case) | 16:32 |
| johnthetubaguy | we don't right? | 16:32 |
| jgriffith | I'm agreeing that the second case is different | 16:32 |
| mriedem | we don't know who called the swap volume REST API | 16:32 |
| johnthetubaguy | we don't know if its a user calling us or cinder after the user called cinder right? | 16:32 |
| mriedem | if it was cinder or an admin | 16:32 |
| jgriffith | johnthetubaguy yes, it's not written that way due to call-backs etc but the call-backs don't actually *do* anything on the Cinder side | 16:33 |
| mriedem | jgriffith: in the case of a non-volume migrate initiated swap, right? | 16:33 |
| johnthetubaguy | no, no, we are saying the REST API calls on the Nova side, and Nova state is identical in both cases | 16:33 |
| jgriffith | mriedem correct | 16:33 |
| mriedem | in the case of volume migration, i thought they completed the migration on the cinder side | 16:33 |
| mriedem | i think we all know what we're saying, we're just saying different things :) | 16:33 |
| jgriffith | haha.. perhaps | 16:34 |
| johnthetubaguy | mriedem: +1 | 16:34 |
| mriedem | the issue is what migrate_completion does on the cinder side for new-style attachments for a volume-migrate initiated swap | 16:34 |
| jgriffith | regardless there are problems there that aren't trivial | 16:34 |
| jgriffith | IMHO that code should all be reverted :) | 16:34 |
| johnthetubaguy | if there was a new swap API, that took two attachment_ids, and was the one cinder called, and for that one we made a new callback to a new API that took the same two attachment_ids... we would be in a more sane place? | 16:35 |
| ildikov | jgriffith: that might not be an option :) | 16:35 |
| jgriffith | bummer | 16:35 |
| johnthetubaguy | actually... thats missing too much context | 16:35 |
| johnthetubaguy | to be clear, this is now blocking multi-attach, and us moving to the new API | 16:36 |
| ildikov | it pretty much does | 16:36 |
| johnthetubaguy | for me, if we passed attachment_ids around, instead of volume-ids, for cinder and nova APIs, wouldn't we have all the state we needed? | 16:37 |
| hemna | especially in the case of multi-attach that makes sense | 16:37 |
| jgriffith | johnthetubaguy yes, that was kinda the whole idea of the attachment-object | 16:38 |
| johnthetubaguy | that means passing Nova an attachment we would update from os-brick, then attach to the instance, and the other attachment would have to be already attached, etc | 16:38 |
| ildikov | johnthetubaguy: how would that help with the we don't know who called the swap-volume API problem? | 16:38 |
| johnthetubaguy | ildikov: it doesn't fix that, but we would be telling you what the attchement was, so cinder should know if thats a migration attachment or not | 16:39 |
| hemna | attaching the attached attachment. | 16:39 |
| johnthetubaguy | it helps a bit in that we care less if the volume-uuid changes, because the attachment-uuid is the same | 16:39 |
| ildikov | johnthetubaguy: ah ok, got it | 16:40 |
| johnthetubaguy | hemna: whos doing what now? | 16:40 |
| hemna | :P | 16:40 |
| hemna | ignore me | 16:40 |
| johnthetubaguy | heh | 16:40 |
| johnthetubaguy | it seems like a new cinder API to be added, and a new Nova API that cinder calls into? | 16:41 |
| johnthetubaguy | thats one approach, I guess the question is, is there a simpler option available? | 16:41 |
| jgriffith | johnthetubaguy that honestly might be the safest and most expedient answer | 16:41 |
| johnthetubaguy | yeah, its the safest explcit one I think | 16:42 |
| ildikov | johnthetubaguy: jgriffith: +1 | 16:42 |
| jgriffith | but that means we need to come up with something and agree on both sides in like 24 hours :) | 16:42 |
| ildikov | jgriffith: I don't see the issue :) | 16:42 |
| johnthetubaguy | well... ideally three months ago, but either way could work | 16:42 |
| jgriffith | ha! | 16:43 |
| * jgriffith fires up his way-back machine | 16:43 | |
| mriedem | i'm not totally following here, you're suggesting a new cinder api where nova passes in the newly attached attachment uuid for the attachment we swapped *to*? | 16:43 |
| mriedem | to complete the migratoin? | 16:43 |
| johnthetubaguy | a new nova API to pass the existing and new attachment id | 16:43 |
| mriedem | and if swap was initiated by a user, not cinder, then it's ignored like today? | 16:44 |
| jgriffith | mriedem I *think* a new cinder/nova interaction for the volume-migration call from Cinder | 16:44 |
| johnthetubaguy | then a new cinder API it calls back to, passing both the attachments | 16:44 |
| mriedem | new nova api? | 16:44 |
| johnthetubaguy | yeah, I think its a new nova api too really | 16:44 |
| jgriffith | johnthetubaguy +1 | 16:44 |
| mriedem | umm | 16:44 |
| johnthetubaguy | so the cinder started one, calls a new API that gets attachments | 16:44 |
| johnthetubaguy | we can try and stop regular using using that this time, for real | 16:45 |
| mriedem | can we not do more special case service-specific APIs please | 16:45 |
| mriedem | you can't stop regular users from using it | 16:45 |
| johnthetubaguy | well, I mean good default RBAC really | 16:45 |
| mriedem | default rbac on swap is already admin only | 16:45 |
| johnthetubaguy | its user safe, if they create attachments | 16:45 |
| jgriffith | ok, I'll look again later today and see if there's a way to fix the mess we already have | 16:45 |
| johnthetubaguy | yeah, admin only isn't good enough, but thats a different debate | 16:45 |
| mriedem | anyway - my fear is, if swap depends on the new attach flow, and now we can't do swap w/o this new api interaction, which is a microversion newer than the new attach api, things start to get super f'ed | 16:46 |
| johnthetubaguy | so.. if we ignore multi attach, I am surpized why the cinder side can't just be "fixed up", are we missing something there? | 16:46 |
| johnthetubaguy | mriedem: yeah, we would have to raise to this new API when checking if we can use the new flow | 16:47 |
| mriedem | maybe we don't design this here, | 16:47 |
| mriedem | i don't understand the issues on the cinder side, | 16:47 |
| mriedem | but can the problem be stated in the ML? | 16:47 |
| johnthetubaguy | thats my previous question really, whats the issue cinder side, if we keep the API the same | 16:48 |
| mriedem | and then we, and hopefully others, can sort it out where/when we have time to digest the actual problem? | 16:48 |
| johnthetubaguy | yeah, some written down form would be good | 16:48 |
| johnthetubaguy | it seems clear we can't move forward here and now without that | 16:48 |
| mriedem | i can live with new cinder apis if we have to, because then the deps are still one direction, | 16:49 |
| mriedem | but if we're doing new apis on both sides, which is a circular dependency, then we start to get into crazy land | 16:49 |
| johnthetubaguy | so proposal 1: re-write the lot to be attachment aware, propsal 2: just fail if any attachment is multi-attach and use the old APIs, question: what does proposal 2 not work for cinder? | 16:49 |
| ildikov | mriedem: there are old attach/detach snippets in the call-bak on the Cinder side, which should not hit in the simple case though | 16:49 |
| mriedem | i'm not really sure why we're talking about multi-attach at this point | 16:50 |
| mriedem | "swapping multi-attached volumes is not supported, fin" | 16:50 |
| mriedem | at least in v1 | 16:50 |
| ildikov | mriedem: +1 | 16:50 |
| mriedem | we do'nt support multiattach today in nova anyway | 16:50 |
| mriedem | and likely won't in pike | 16:50 |
| johnthetubaguy | well, we should include swapping a volume that has multiple attachments | 16:50 |
| johnthetubaguy | i.e. half way through a live-migration | 16:51 |
| mriedem | that's not the same operatoin though | 16:51 |
| mriedem | there is no migrate_completion callback during nova live migratoin | 16:51 |
| johnthetubaguy | Nova will just reject those API calls anyways, so no change there | 16:51 |
| mriedem | the migration_completion cinder api is the issue | 16:51 |
| mriedem | as far as i understand | 16:51 |
| mriedem | and that's *only* for swap volume | 16:51 |
| mriedem | on the nova side | 16:51 |
| ildikov | mriedem: correct | 16:51 |
| johnthetubaguy | yes, I am talking about when you call swap volume | 16:51 |
| johnthetubaguy | what is the state of the system | 16:51 |
| johnthetubaguy | if we have a volume attached on two hosts, its "complicated" on the cinder side, as there are two attachments | 16:52 |
| johnthetubaguy | but Nova doesn't care about that case | 16:52 |
| mriedem | johnthetubaguy: yo'ure talking about swapping a multiattach volume though right? | 16:52 |
| johnthetubaguy | no | 16:52 |
| johnthetubaguy | multi-attach=false | 16:52 |
| *** MarkBaker has quit IRC | 16:52 | |
| johnthetubaguy | two attachments | 16:53 |
| *** mgiles has joined #openstack-meeting-cp | 16:53 | |
| johnthetubaguy | source host and destination host | 16:53 |
| mriedem | how is the same volume attached to two hosts during swap volume? | 16:53 |
| mriedem | if not multiattach? | 16:53 |
| mriedem | swap volume is literally 2 separate volumes | 16:53 |
| mriedem | 1 attachment each | 16:53 |
| johnthetubaguy | on the cinder side you can call migrate at any time | 16:53 |
| johnthetubaguy | the VM could be in the live-migrating state | 16:53 |
| johnthetubaguy | Nova fails the API call | 16:53 |
| johnthetubaguy | but theoretically, you can have two attachments in the Cinder DB | 16:54 |
| johnthetubaguy | same volume | 16:54 |
| mriedem | can you swap volumes on an instance being migrated? | 16:54 |
| johnthetubaguy | same instance | 16:54 |
| johnthetubaguy | so if you call that, I think you get a Nova API error | 16:54 |
| johnthetubaguy | but its a case on the cinder side | 16:54 |
| mriedem | you can't swap volumes on an instance that's undergoing a task state change i don't think | 16:54 |
| mriedem | we're either talking past each other, | 16:54 |
| johnthetubaguy | I am trying to say cinder can ignore that case | 16:54 |
| mriedem | or i'm just totally not understanding what you're saying | 16:54 |
| johnthetubaguy | so... yeah, that | 16:54 |
| mriedem | with 5 minutes left, and i need lunch, let's table this and move it to the ML, | 16:55 |
| johnthetubaguy | probably a hangout thing, after its all written down | 16:55 |
| johnthetubaguy | +1 | 16:55 |
| mriedem | but i'd really just like jgriffith or someone from cinder to describe the problem we have today with non-multiattach volumes and the migration_callback in cinder | 16:55 |
| mriedem | with the new flow | 16:55 |
| ildikov | mriedem: johnthetubaguy: we will get it written down with jgriffith and then we can figure out whether it's an ML thread a Hangouts call or both or what else | 16:55 |
| mriedem | i really need writing to digest it | 16:56 |
| johnthetubaguy | jgriffith: do you understand the question we are asking? | 16:56 |
| jgriffith | johnthetubaguy partially, but frankly you are all over the board :) | 16:56 |
| mriedem | jgriffith: "i'd really just like jgriffith or someone from cinder to describe the problem we have today with non-multiattach volumes and the migration_callback in cinder" | 16:56 |
| jgriffith | So I'll put a write up together on the two cases | 16:56 |
| mriedem | that's step 1 | 16:56 |
| jgriffith | and what the challenges are problems etc | 16:56 |
| johnthetubaguy | basically, if we keep all the APIs the same, whats broken in the new world? | 16:56 |
| johnthetubaguy | perfect | 16:56 |
| ildikov | johnthetubaguy: your last scenario is unclear to me but we will get to the base case and let's take it from there | 16:57 |
| johnthetubaguy | I think I am making option 2 possible, but yeah, lets get the basics written down | 16:57 |
| ildikov | johnthetubaguy: I think we will get a better view with some written material first | 16:58 |
| johnthetubaguy | cool, seems like we are done, and just waiting for that write up? | 16:58 |
| ildikov | johnthetubaguy: yes | 16:58 |
| stvnoyes | jgriffith: can you stick around here after the mtg? I have a couple of questions for you about the attach POC operation | 16:59 |
| mriedem | stvnoyes: could move to nova or cinder channels | 17:00 |
| jgriffith | stvnoyes sure | 17:00 |
| ildikov | ok, let's end the meeting and move to the Cinder channel with further chats | 17:00 |
| jgriffith | stvnoyes mriedem yeah... I'll catch you cinder | 17:00 |
| ildikov | or the Nova one :) | 17:00 |
| stvnoyes | ok see on the cinder irc | 17:00 |
| ildikov | thank you all! | 17:00 |
| ildikov | will catch up later on swap | 17:00 |
| *** mriedem has left #openstack-meeting-cp | 17:00 | |
| ildikov | #endmeeting | 17:00 |
| *** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings" | 17:00 | |
| openstack | Meeting ended Thu Jun 8 17:00:45 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 17:00 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/cinder_nova_api_changes/2017/cinder_nova_api_changes.2017-06-08-16.00.html | 17:00 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/cinder_nova_api_changes/2017/cinder_nova_api_changes.2017-06-08-16.00.txt | 17:00 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/cinder_nova_api_changes/2017/cinder_nova_api_changes.2017-06-08-16.00.log.html | 17:00 |
| *** mgiles has quit IRC | 17:03 | |
| *** MarkBaker has joined #openstack-meeting-cp | 17:04 | |
| *** pewp has quit IRC | 18:10 | |
| *** pewp has joined #openstack-meeting-cp | 18:12 | |
| *** diablo_rojo has quit IRC | 18:38 | |
| *** MarkBaker has quit IRC | 18:54 | |
| *** diablo_rojo has joined #openstack-meeting-cp | 19:05 | |
| *** MarkBaker has joined #openstack-meeting-cp | 19:06 | |
| *** pewp has quit IRC | 19:13 | |
| *** pewp has joined #openstack-meeting-cp | 19:17 | |
| *** harlowja has quit IRC | 20:08 | |
| *** kbyrne has quit IRC | 20:48 | |
| *** kbyrne has joined #openstack-meeting-cp | 20:50 | |
| *** MarkBaker has quit IRC | 21:17 | |
| *** edmondsw has quit IRC | 22:02 | |
| *** reed has quit IRC | 22:02 | |
| *** reed has joined #openstack-meeting-cp | 22:03 | |
| *** diablo_rojo has quit IRC | 22:51 | |
| *** felipemonteiro__ has quit IRC | 23:05 | |
| *** sdague has quit IRC | 23:08 | |
| *** knangia_ has joined #openstack-meeting-cp | 23:18 | |
| *** pewp has quit IRC | 23:21 | |
| *** pewp has joined #openstack-meeting-cp | 23:22 | |
| *** markvoelker has quit IRC | 23:34 | |
| *** harlowja has joined #openstack-meeting-cp | 23:57 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!