| *** markvoelker_ has quit IRC | 00:03 | |
| *** markvoelker has joined #openstack-meeting-cp | 00:09 | |
| *** markvoelker has quit IRC | 00:13 | |
| *** markvoelker has joined #openstack-meeting-cp | 00:18 | |
| *** gouthamr has joined #openstack-meeting-cp | 00:19 | |
| *** markvoelker has quit IRC | 00:22 | |
| *** markvoelker has joined #openstack-meeting-cp | 00:27 | |
| *** markvoelker has quit IRC | 00:32 | |
| *** markvoelker has joined #openstack-meeting-cp | 00:54 | |
| *** markvoelker has quit IRC | 00:59 | |
| *** markvoelker has joined #openstack-meeting-cp | 01:12 | |
| *** markvoelker has quit IRC | 01:47 | |
| *** markvoelker has joined #openstack-meeting-cp | 02:00 | |
| *** yamahata has quit IRC | 02:02 | |
| *** iyamahat has quit IRC | 02:03 | |
| *** markvoelker has quit IRC | 02:05 | |
| *** markvoelker has joined #openstack-meeting-cp | 02:10 | |
| *** markvoelker has quit IRC | 02:14 | |
| *** markvoelker has joined #openstack-meeting-cp | 02:19 | |
| *** markvoelker has quit IRC | 02:23 | |
| *** markvoelker has joined #openstack-meeting-cp | 02:28 | |
| *** markvoelker has quit IRC | 02:33 | |
| *** markvoelker has joined #openstack-meeting-cp | 02:46 | |
| *** nhelgeson has quit IRC | 02:53 | |
| *** gouthamr has quit IRC | 02:57 | |
| *** kbyrne has quit IRC | 03:12 | |
| *** kbyrne has joined #openstack-meeting-cp | 03:13 | |
| *** nikhil has quit IRC | 03:20 | |
| *** markvoelker has quit IRC | 03:20 | |
| *** markvoelker has joined #openstack-meeting-cp | 03:25 | |
| *** markvoelker has quit IRC | 03:30 | |
| *** aselius has joined #openstack-meeting-cp | 03:32 | |
| *** markvoelker has joined #openstack-meeting-cp | 03:34 | |
| *** jgriffith has quit IRC | 03:34 | |
| *** jgriffith has joined #openstack-meeting-cp | 03:38 | |
| *** markvoelker has quit IRC | 03:39 | |
| *** markvoelker has joined #openstack-meeting-cp | 03:43 | |
| *** jgriffith_ has joined #openstack-meeting-cp | 03:44 | |
| *** jgriffith has quit IRC | 03:46 | |
| *** jgriffith_ is now known as jgriffith | 03:47 | |
| *** markvoelker has quit IRC | 03:48 | |
| *** yamahata has joined #openstack-meeting-cp | 03:49 | |
| *** markvoelker has joined #openstack-meeting-cp | 03:52 | |
| *** markvoelker has quit IRC | 03:57 | |
| *** markvoelker has joined #openstack-meeting-cp | 04:02 | |
| *** markvoelker has quit IRC | 04:06 | |
| *** markvoelker has joined #openstack-meeting-cp | 04:10 | |
| *** markvoelker has quit IRC | 04:15 | |
| *** markvoelker has joined #openstack-meeting-cp | 04:20 | |
| *** markvoelker has quit IRC | 04:54 | |
| *** markvoelker has joined #openstack-meeting-cp | 05:08 | |
| *** markvoelker has quit IRC | 05:12 | |
| *** markvoelker has joined #openstack-meeting-cp | 05:17 | |
| *** markvoelker has quit IRC | 05:22 | |
| *** markvoelker has joined #openstack-meeting-cp | 05:26 | |
| *** markvoelker has quit IRC | 05:29 | |
| *** markvoelker has joined #openstack-meeting-cp | 05:29 | |
| *** markvoelker has quit IRC | 05:42 | |
| *** markvoelker has joined #openstack-meeting-cp | 05:42 | |
| *** markvoelker has quit IRC | 05:42 | |
| *** aselius has quit IRC | 06:12 | |
| *** markvoelker has joined #openstack-meeting-cp | 06:49 | |
| *** markvoelker has quit IRC | 08:01 | |
| *** MarkBaker has joined #openstack-meeting-cp | 08:29 | |
| *** diablo_rojo has joined #openstack-meeting-cp | 09:04 | |
| *** MarkBaker_ has joined #openstack-meeting-cp | 09:14 | |
| *** MarkBaker has quit IRC | 09:17 | |
| *** MarkBaker_ has quit IRC | 09:19 | |
| *** sdague has joined #openstack-meeting-cp | 09:38 | |
| *** diablo_rojo has quit IRC | 09:49 | |
| *** MarkBaker has joined #openstack-meeting-cp | 10:09 | |
| *** MarkBaker has quit IRC | 10:21 | |
| *** MarkBaker has joined #openstack-meeting-cp | 10:21 | |
| *** iyamahat has joined #openstack-meeting-cp | 10:26 | |
| *** yamahata has quit IRC | 10:28 | |
| *** iyamahat has quit IRC | 10:32 | |
| *** zhipeng has joined #openstack-meeting-cp | 11:23 | |
| *** markvoelker has joined #openstack-meeting-cp | 11:27 | |
| *** edmondsw has joined #openstack-meeting-cp | 11:51 | |
| *** rmcall has joined #openstack-meeting-cp | 13:26 | |
| *** zhipeng has quit IRC | 13:42 | |
| *** felipemonteiro has joined #openstack-meeting-cp | 13:44 | |
| *** felipemonteiro__ has joined #openstack-meeting-cp | 13:45 | |
| *** felipemonteiro has quit IRC | 13:49 | |
| *** xyang1 has joined #openstack-meeting-cp | 13:54 | |
| *** lbragstad has joined #openstack-meeting-cp | 14:04 | |
| *** zhipeng has joined #openstack-meeting-cp | 14:11 | |
| *** zhipeng has quit IRC | 14:16 | |
| *** gouthamr has joined #openstack-meeting-cp | 14:20 | |
| *** rmcall has quit IRC | 14:37 | |
| *** iyamahat has joined #openstack-meeting-cp | 14:38 | |
| *** iyamahat has quit IRC | 14:45 | |
| *** nikhil has joined #openstack-meeting-cp | 14:50 | |
| *** zhipeng has joined #openstack-meeting-cp | 14:51 | |
| *** zhipeng has quit IRC | 14:52 | |
| *** iyamahat has joined #openstack-meeting-cp | 14:59 | |
| *** iyamahat has quit IRC | 15:05 | |
| *** iyamahat has joined #openstack-meeting-cp | 15:07 | |
| *** markvoelker has quit IRC | 15:12 | |
| *** markvoelker has joined #openstack-meeting-cp | 15:13 | |
| *** markvoelker has quit IRC | 15:17 | |
| *** mriedem has joined #openstack-meeting-cp | 16:00 | |
| ildikov | #startmeeting cinder-nova-api-changes | 16:02 |
|---|---|---|
| openstack | Meeting started Thu Oct 19 16:02:19 2017 UTC and is due to finish in 60 minutes. The chair is ildikov. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:02 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:02 |
| *** openstack changes topic to " (Meeting topic: cinder-nova-api-changes)" | 16:02 | |
| openstack | The meeting name has been set to 'cinder_nova_api_changes' | 16:02 |
| ildikov | johnthetubaguy jaypipes e0ne jgriffith hemna mriedem patrickeast smcginnis diablo_rojo xyang1 raj_singh lyarwood jungleboyj stvnoyes | 16:02 |
| mriedem | o/ | 16:02 |
| jgriffith | derp | 16:02 |
| * johnthetubaguy wonders in and waves | 16:02 | |
| *** aselius has joined #openstack-meeting-cp | 16:03 | |
| *** jgriffith is now known as groot | 16:03 | |
| groot | I am groot | 16:04 |
| ildikov | sorry for being late | 16:04 |
| * smcginnis is still glaring at zuul | 16:04 | |
| *** groot is now known as jgriffith | 16:04 | |
| ildikov | we have a new version of the multi-attach spec: https://review.openstack.org/499777 | 16:04 |
| ildikov | thanks to jgriffith | 16:04 |
| *** jgriffith is now known as groot | 16:05 | |
| mriedem | reading the diff now | 16:05 |
| ildikov | I need to read through it quickly, but if anyone has concerns with either of the bits in it feel free to raise it | 16:05 |
| johnthetubaguy | we say Active/Active is out of scope? I thought that was largely the point of it | 16:06 |
| groot | and if you want me to walk through it now would be a good time :) | 16:06 |
| groot | johnthetubaguy I just copied what was already said | 16:06 |
| groot | put it back in if you want... but that's what was there | 16:07 |
| groot | I only wanted to update the process/flow stuff | 16:07 |
| mriedem | this is news to me, | 16:07 |
| mriedem | "NOTE: multi-attach checks are all done at attachment-create time, there is no longer a requirement to create a volume with multi-attach flags." | 16:07 |
| groot | mriedem yeah, that's what I added | 16:07 |
| johnthetubaguy | :S | 16:07 |
| mriedem | so nova-api will call attachment-create and if it's not a multiattach volume, the volume has to be 'available' for that to work, | 16:08 |
| groot | nope | 16:08 |
| groot | oh... | 16:08 |
| groot | mriedem YES | 16:08 |
| groot | sorry | 16:08 |
| *** iyamahat has quit IRC | 16:08 | |
| groot | mriedem it goes through those 4 checks that I listed | 16:08 |
| mriedem | if it's a multiattach volume, attachment-create will work even if the volume is in-use | 16:08 |
| groot | mriedem yes, IFF the requirements are met | 16:08 |
| mriedem | "The backend providing the volume supports it" | 16:08 |
| ildikov | and multi-attach is defined at the first attachment-create | 16:09 |
| mriedem | is that going to be an rpc call from cinder api to the backend? | 16:09 |
| mriedem | or something set on the volume in the db? | 16:09 |
| groot | mriedem we have that in the backend-capabilities already | 16:09 |
| mriedem | like a capability of hte type | 16:09 |
| mriedem | ok | 16:09 |
| groot | I don't want to use types for this EXCEPT for the case of a user explicitly saying they want that capability | 16:09 |
| mriedem | side question, but is cinder going to then deprecate the multiattach flag in the volume API? | 16:09 |
| groot | YES!!!!!! | 16:10 |
| mriedem | if it's not actually used anywhere | 16:10 |
| mriedem | ok | 16:10 |
| groot | I'd like to just delete it straight away and wash it from my memory forever | 16:10 |
| groot | If I could go back in time it would've never merged into the code | 16:10 |
| *** nhelgeson has joined #openstack-meeting-cp | 16:11 | |
| mriedem | so in cinder channel you said, "The idea being that in the end the main thing we need on the Nova side is just to check the multiattach property in the attachment record and use it for libvirt if Nova supports/allows it and that's it" | 16:11 |
| mriedem | so there is going to be a multiattach flag on the attachment record now? | 16:11 |
| groot | mriedem yes | 16:11 |
| johnthetubaguy | hang on... | 16:11 |
| mriedem | but it's the volume that's multi-attachable, not the attachment record, right? | 16:12 |
| groot | no | 16:12 |
| mriedem | the attachment is only for 1 volume + 1 instance | 16:12 |
| johnthetubaguy | the first attachment needs to be multi-attach = true, how does that work? its a volume thing | 16:12 |
| mriedem | the volume can be attached to multiple instances, which are multiple attachments | 16:12 |
| groot | the attachment is the source of all info regarding how to and if you can attach | 16:12 |
| mriedem | but that attachment is only per volume/instance combo | 16:12 |
| groot | mriedem the point was raised that libvirt MUST set shared on every one of those | 16:12 |
| ildikov | it's based on how you attached the first attachment that moved the volume from 'available' to 'in-use' | 16:13 |
| groot | groot so the easiest way to track that is the attachment record | 16:13 |
| johnthetubaguy | how does cinder know there might be multiple attachments then? | 16:13 |
| johnthetubaguy | for the first attachment, in particular | 16:13 |
| groot | because even if the volume is "mulit-attach" that doesn't matter | 16:13 |
| groot | johnthetubaguy we have a database | 16:13 |
| johnthetubaguy | but isn't it a user preference? | 16:13 |
| johnthetubaguy | I am asking where the data came from, not where it is stored | 16:14 |
| groot | johnthetubaguy and that's why there's an option to attachment-create | 16:14 |
| groot | attachment-create --multiattach | 16:14 |
| johnthetubaguy | but thats a Nova call, and nova doesn't have an API for that | 16:14 |
| groot | ??? | 16:14 |
| groot | johnthetubaguy attachment-create? | 16:15 |
| johnthetubaguy | that doesn't take that flag today | 16:15 |
| mriedem | nova does'nt know if it should pass a multiattach flag | 16:15 |
| johnthetubaguy | this was all build assuming it was passed by a user when they create the volume | 16:15 |
| ildikov | groot: Nova only has the volume-attach call with no extra parameters and the multiattach flag decided what to do | 16:15 |
| groot | why wouldn't nova add it as part of this spec? | 16:15 |
| groot | the other option then if you want.... | 16:16 |
| johnthetubaguy | so the nova flow is horrid this way... its not just us being a stick in the mood | 16:16 |
| johnthetubaguy | mud | 16:16 |
| ildikov | is there any concern on who's allowed to set 'multiattach'? | 16:16 |
| groot | if Cinder supports it we ALWAYS send the parameter back as true | 16:16 |
| groot | we just auto-set it | 16:16 |
| johnthetubaguy | thats worse for volume performance | 16:16 |
| johnthetubaguy | we don't want to disable the cache when we don't have to | 16:16 |
| johnthetubaguy | user needs to opt into that | 16:17 |
| johnthetubaguy | somehow | 16:17 |
| groot | Ok | 16:17 |
| groot | -2 | 16:17 |
| johnthetubaguy | so if it goes in Nova, here is the flow | 16:17 |
| groot | I'm fine with that | 16:17 |
| johnthetubaguy | user attaches volume, passed multi-attach | 16:17 |
| johnthetubaguy | user attaches same volume elsewhere, forgets to pass multi-attach, we fail saying you should have said multi-attach = true here | 16:17 |
| johnthetubaguy | that seems nuts | 16:17 |
| groot | johnthetubaguy just let me say for the record, the flag on the volume at creation is going to be problematic in the future | 16:18 |
| groot | johnthetubaguy did you read the spec? | 16:18 |
| groot | I realize it was just put up | 16:18 |
| johnthetubaguy | not got that far down I guess | 16:18 |
| groot | the spec points out that if it was already attached somewhere using multiattach then cinder will auto-set that flag on all subsequent attach calls | 16:19 |
| johnthetubaguy | OK | 16:19 |
| *** markvoelker has joined #openstack-meeting-cp | 16:20 | |
| ildikov | it might be inconvenient as you need to know when you're attaching the first attachment to set it | 16:20 |
| groot | ildikov not as inconvenient as knowing to set it at volume-create!!! | 16:20 |
| ildikov | like checking whether the volume has attachment or not | 16:20 |
| johnthetubaguy | so you are wanting a flow where you create a volume, fill it up, detach it, then flip it to multi-attach, so you don't need to create a snapshot then create a new volume? | 16:21 |
| groot | "inconvenient" is sort of a a funny thing to throw out considering the alternative :) | 16:21 |
| groot | johnthetubaguy yup, that's one use case | 16:21 |
| ildikov | well, the other is not flexible however seems straightforward | 16:22 |
| groot | johnthetubaguy also my opinion is that the changes I proposed actually work and are easier to mangae/track things | 16:22 |
| groot | ildikov I'd argue that it is NOT straight forward at all | 16:22 |
| groot | but that's just me :) | 16:22 |
| johnthetubaguy | I think the problem is we are not all thinking through the same set of use cases / flows here | 16:23 |
| ildikov | I didn't say not at all, just found that part a little inconvenient :) | 16:23 |
| johnthetubaguy | if I think about the data creation, I like the the on-attachment idea. What I hate is its gonna take an age to iron out the Nova API changes, there are many of them implied there. | 16:24 |
| *** markvoelker has quit IRC | 16:24 | |
| groot | johnthetubaguy well then I guess it won't work :( | 16:24 |
| groot | bummer | 16:24 |
| groot | I don't know why it's so hard though | 16:25 |
| groot | "nova volume-attach --multiattach <instance> <volume>" | 16:25 |
| groot | What's so difficult there? | 16:25 |
| johnthetubaguy | nova boot needs changing too | 16:25 |
| johnthetubaguy | BDM v2 needs updates | 16:25 |
| groot | Yeah? | 16:25 |
| groot | it does in either case | 16:26 |
| ildikov | if we like the flexibility of this better, than it would be better to do it now than implementing the whole thing with the current flag | 16:26 |
| johnthetubaguy | the old way there are zero changes to the microversion of the API | 16:26 |
| ildikov | johnthetubaguy: we would've bumped it anyway as multiattach is a new functionality | 16:26 |
| groot | and a train wreck in the cinder code :( | 16:27 |
| groot | anyway, I guess it's too hard to do | 16:27 |
| johnthetubaguy | not sure about too hard | 16:27 |
| ildikov | me neither | 16:27 |
| johnthetubaguy | just its harder (Nova side), need to be worth it, seems like it could be | 16:28 |
| johnthetubaguy | mriedem: I am curious what you think about an extra multi-attach flag for all volume attachments | 16:28 |
| groot | well let's think through it a bit and decide if it "is" worth it I guess | 16:28 |
| mriedem | just put my comments in the spec, | 16:28 |
| mriedem | i don't see why the multiattach flag makes sense on the attachment record, like i said, the attachment record is per volume/instance, and can't be shared with another instance | 16:29 |
| mriedem | so it's not multiattachable | 16:29 |
| mriedem | the volume is multiattachable | 16:29 |
| mriedem | i think the flag should be modeled on the volume as it always has been | 16:29 |
| mriedem | if the backend doesn't support multiattach when the volume is created, cinder should fail the volume create | 16:29 |
| johnthetubaguy | so how does the data get into the volume, I think that is the consideration here | 16:29 |
| mriedem | that leaves it to the user if they are doing multiattach at volume create time rather than when attaching the volume to an instance, which they might only do once | 16:30 |
| groot | mriedem attachment record on the cinder side is per-volume | 16:30 |
| * smcginnis is glad to not have to be the PTL on stage stating yet again "We've made progress towards supporting mutliattach, but there's more work we're hoping to get done in $RELEASE+1" | 16:30 | |
| *** iyamahat has joined #openstack-meeting-cp | 16:30 | |
| groot | smcginnis nahh... I'll withdraw my suggestions | 16:30 |
| groot | I don't want to argue about it or derail anything | 16:31 |
| mriedem | groot: the volume has multiple attachments sure | 16:31 |
| smcginnis | Not saying that. We should get the right design. | 16:31 |
| groot | smcginnis I'm not sure anything will be *right* :) | 16:31 |
| mriedem | honestly i'm just really surprised that this is coming up now | 16:31 |
| mriedem | like, this seems really left field to me | 16:31 |
| groot | mriedem that's apparantly my fault | 16:32 |
| ildikov | mriedem: groot: can we say that it gets set at attachment-create if the back end supports it, but it will be added to the volume as opposed to the attachment? | 16:32 |
| groot | for some reason I thought I had communicated this all along | 16:32 |
| ildikov | kind of the way between? | 16:32 |
| groot | but obviously that's not the case | 16:32 |
| groot | :( | 16:32 |
| mriedem | ildikov: but like johnthetubaguy said, what if the user doesn't want the volume to be attached to multiple instances? | 16:32 |
| mriedem | it seems like something the user should be opting into when creating the volume | 16:32 |
| ildikov | mriedem: do you mean that someone else is using the volume than who created? | 16:33 |
| mriedem | sure, volumes are not owned by a user right? they are owned by the project | 16:33 |
| groot | mriedem why does creation instead of attach? | 16:33 |
| ildikov | mriedem: as if it's the same user than don't call attachment-create with --multiattach | 16:33 |
| mriedem | a user in the same project could attach the volume to another instance in the same project | 16:33 |
| groot | I'd argue that attach time makes WAY more sense | 16:33 |
| groot | and honestly you could create a type that says explicitly "dont multiattach" if you really wanted to for some odd reason | 16:34 |
| groot | honestly it'd make more sense IMO to have a "forbid-multi-attach create-volume option than the other" | 16:34 |
| *** iyamahat has quit IRC | 16:34 | |
| mriedem | ^ is a tihng in the type? | 16:35 |
| mriedem | so what happens today if i try to create a volume with multiattach=true, will it fail if the type capability (via the backend) doesn't support multiattach? | 16:35 |
| groot | mriedem correct | 16:36 |
| groot | which actually none of that code relating to that flag is actually *finished* so it doesn't really do anything today at all | 16:36 |
| groot | it shouldn't even be considered/discussed except possibly as an example of a flag | 16:37 |
| smcginnis | I can see the use where a volume is created not thinking of multiattach, gets some useful data, then a user decides they could use that ReadOnly on multiple hosts. | 16:37 |
| mriedem | snapshot the volume and create a new multiattach=true volume from the snapshot? | 16:38 |
| johnthetubaguy | smcginnis: +1 that is what I was saying earlier, but they can snapshot that, and create a multi-attach form the snapshot? | 16:38 |
| ildikov | smcginnis: there was a Cinder blueprint earlier to make that flag changeable after creation | 16:38 |
| johnthetubaguy | ildikov: actually that is a better option, if no attachments, allow users to tweak it | 16:38 |
| groot | well there ya go then. problem solved | 16:38 |
| ildikov | johnthetubaguy: yep, that works too | 16:39 |
| groot | ildikov sorry for messing up your spec :) | 16:39 |
| ildikov | smcginnis: groot: would that work from your perspective? ^^ | 16:39 |
| ildikov | groot: would've been a too easy day otherwise... :) | 16:40 |
| groot | and Nova owns figuring out BFV etc | 16:40 |
| mriedem | changing the multiattach flag on the volume is not something we need to worry about today, | 16:40 |
| mriedem | or for this nova spec | 16:40 |
| mriedem | it's a later enhancement | 16:40 |
| smcginnis | ildikov: Yeah, makes sense. | 16:40 |
| mriedem | for now you can snapshot and recreate if needed | 16:40 |
| groot | mriedem well wait | 16:40 |
| groot | bah | 16:40 |
| groot | ok | 16:40 |
| ildikov | I just wanted to check on whether it's considered doable | 16:40 |
| groot | fine | 16:40 |
| groot | I give up | 16:40 |
| ildikov | don't want to add it now | 16:40 |
| johnthetubaguy | who is gonna recap to see where we have landed? | 16:41 |
| groot | not me | 16:41 |
| mriedem | it sounds like we're back to previous understanding of how things would work | 16:41 |
| johnthetubaguy | no read_only, no bfv, bootable=false and mutliattach=true dissallowed by cinder for the moment | 16:41 |
| groot | :) | 16:41 |
| johnthetubaguy | volume sets multi-attach = true/false | 16:41 |
| mriedem | i thought we were going to have bfv? | 16:41 |
| johnthetubaguy | oh, I thought we said no a few weeks back :S | 16:42 |
| ildikov | johnthetubaguy: the bootable + multiattach is questionable | 16:42 |
| johnthetubaguy | because of no read-only mode | 16:42 |
| mriedem | ok i haven't really followed the r/o / r/w stuff | 16:43 |
| mriedem | totally confused about policy and all that | 16:43 |
| johnthetubaguy | so the way I looked at it was this... | 16:43 |
| ildikov | mriedem: we said at a certain point that we wouldn't want to boot multiple instances from a R/W volume | 16:43 |
| johnthetubaguy | do the "simple" use case, r/w multi-attach as a first version | 16:43 |
| johnthetubaguy | i.e. target the cluster whatnot people | 16:44 |
| johnthetubaguy | so policy is on or off in Cinder, i.e. are you allowed to set multi-attach=true or not, period | 16:44 |
| johnthetubaguy | if multi-attach=true, do not allow bootable=true, (for now) | 16:44 |
| johnthetubaguy | that gives us something we could do in queens | 16:44 |
| johnthetubaguy | possibly | 16:44 |
| johnthetubaguy | and hits the 80% use case people seem to be asking about | 16:45 |
| johnthetubaguy | ... then next time | 16:45 |
| * smcginnis needs to AFK for a bit, be back later | 16:45 | |
| johnthetubaguy | we add read-only multi-attach volumes as an option, and allow bootable=true for that combo | 16:45 |
| johnthetubaguy | I say we, that is purely a Cinder change at that point | 16:45 |
| johnthetubaguy | all of this is enforced by cinder | 16:45 |
| groot | sigh | 16:46 |
| johnthetubaguy | so over the last few weeks that seems to be where we landed, totally open to other ideas | 16:46 |
| *** iyamahat has joined #openstack-meeting-cp | 16:46 | |
| johnthetubaguy | the idea is we allow one use case, and come back next cycle to see how we can do better | 16:46 |
| mriedem | oh i see from the spec, | 16:47 |
| mriedem | "In the first iteration we will have Read/Write volumes and will not control that through policies. Due to this aspect we will not enable to multi-attach a bootable volume for which the check will be on the Cinder side. " | 16:47 |
| johnthetubaguy | rather than be really permissive and regret it later | 16:47 |
| *** iyamahat_ has joined #openstack-meeting-cp | 16:47 | |
| groot | johnthetubaguy you can toggle a volume from non-bootable to bootable | 16:47 |
| mriedem | that sentence totally confused me in PS5 | 16:47 |
| johnthetubaguy | groot: the policy check should be applied to all those changes, thats fine | 16:47 |
| mriedem | but means, you can't have bootable=true and multiattach=true in cinder, | 16:47 |
| mriedem | and it's not a policy thing, it's hard-coded | 16:47 |
| mriedem | right? | 16:47 |
| johnthetubaguy | yeah | 16:47 |
| ildikov | mriedem: I wasn't 100% sure what we agreed on regarding to that one, so kept it high level... | 16:48 |
| ildikov | mriedem: basically whatever we come up with for the BFV case will be hard coded | 16:48 |
| johnthetubaguy | so the problem was we couldn't agree how read-only works, but we though best to only allow BFV for the read-only multi-attach volumes | 16:49 |
| mriedem | not sure why nova wouldn't check that honestly, but i do'nt know the details | 16:49 |
| johnthetubaguy | nova doesn't | 16:49 |
| johnthetubaguy | nova just checkes bootable=true on the volume, cinder enforces the checks | 16:49 |
| *** yamahata has joined #openstack-meeting-cp | 16:49 | |
| ildikov | there are multiple options, the current code proposal says not allow to boot from a multi-attach volume | 16:49 |
| ildikov | you can identify when Nova tries to boot from a volume and add actions there | 16:50 |
| mriedem | so...during bfv in nova, if bootable=true and the volume is r/w and has > 0 attachments, fail | 16:50 |
| ildikov | or we play with the flags in Cinder | 16:50 |
| mriedem | isn't that what we want? | 16:50 |
| johnthetubaguy | so nova only allows bfv is the volume says bootable=true | 16:50 |
| mriedem | so you could bfv with a r/w volume once | 16:50 |
| johnthetubaguy | cinder can just disallow bootable=true for the cases it thinks that is bad | 16:50 |
| ildikov | mriedem: that would be y understanding | 16:50 |
| ildikov | *my | 16:51 |
| mriedem | i'm thinking longer term interop wise, if cinder is hard-coding this stuff, at what point it starts to allow things and how is that discoverable by a user? | 16:51 |
| ildikov | johnthetubaguy: that's another thing, we either say not to boot from multi-attach volume or not to multi-attach a bootable volume | 16:51 |
| groot | mriedem eventually you end up back at my proposal FWIW | 16:51 |
| ildikov | johnthetubaguy: we need to pick one regardless of any flags or anything | 16:52 |
| mriedem | looking at https://developer.openstack.org/api-ref/block-storage/v3/#show-a-volume-s-details | 16:53 |
| johnthetubaguy | ildikov: those sound like the same question, I am missing something | 16:53 |
| mriedem | the r/w thing is not actually an attribute on the volume itself, it's on the attachment right? | 16:53 |
| ildikov | groot: if we do it your way but store the multiattach info on volume level, I'm good :) | 16:53 |
| johnthetubaguy | mriedem: that is why I said we ignore that for this cycle | 16:53 |
| ildikov | johnthetubaguy: in one case you can boot from the volume in the other you can multi-attach it, but not both | 16:54 |
| mriedem | https://developer.openstack.org/api-ref/block-storage/v3/#show-attachment-details | 16:54 |
| mriedem | attach_mode | 16:54 |
| ildikov | johnthetubaguy: that's not the same for me | 16:54 |
| johnthetubaguy | ildikov: but cinder doesn't know what nova has done with the volume, in terms of booting it vs not booting it, Nova would be racey on any checks I believe | 16:55 |
| johnthetubaguy | is talking going to make this easier? i.e. a hangout? | 16:56 |
| mriedem | just looking at the nova vol attach code, nova always attaches in rw mode unless the connection_info on the attachment says otherwise | 16:56 |
| ildikov | johnthetubaguy: never mind, I might've misread one of your lines, so just skip my last comments | 16:57 |
| ildikov | johnthetubaguy: hangout would be good | 16:57 |
| johnthetubaguy | https://hangouts.google.com/call/kefPGVo77ipoUkuKTMzzAAEI | 16:57 |
| ildikov | we switched to the Hangouts ^^ | 17:02 |
| ildikov | closing this meeting for now as our slot ran out | 17:03 |
| ildikov | #endmeeting | 17:03 |
| *** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings" | 17:03 | |
| openstack | Meeting ended Thu Oct 19 17:03:15 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 17:03 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/cinder_nova_api_changes/2017/cinder_nova_api_changes.2017-10-19-16.02.html | 17:03 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/cinder_nova_api_changes/2017/cinder_nova_api_changes.2017-10-19-16.02.txt | 17:03 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/cinder_nova_api_changes/2017/cinder_nova_api_changes.2017-10-19-16.02.log.html | 17:03 |
| *** felipemonteiro__ has quit IRC | 17:05 | |
| *** mriedem has left #openstack-meeting-cp | 17:05 | |
| *** iyamahat_ has quit IRC | 17:09 | |
| *** MarkBaker has quit IRC | 17:16 | |
| *** lbragstad has quit IRC | 17:35 | |
| *** groot is now known as jgriffith | 17:38 | |
| *** lbragstad has joined #openstack-meeting-cp | 17:39 | |
| *** felipemonteiro has joined #openstack-meeting-cp | 18:06 | |
| *** felipemonteiro__ has joined #openstack-meeting-cp | 18:07 | |
| *** felipemonteiro has quit IRC | 18:11 | |
| *** iyamahat has quit IRC | 20:02 | |
| *** iyamahat_ has joined #openstack-meeting-cp | 20:02 | |
| *** felipemonteiro__ has quit IRC | 20:54 | |
| *** felipemonteiro has joined #openstack-meeting-cp | 21:04 | |
| *** felipemonteiro has quit IRC | 21:09 | |
| *** iyamahat_ has quit IRC | 21:10 | |
| *** iyamahat__ has joined #openstack-meeting-cp | 21:10 | |
| *** aselius has quit IRC | 21:12 | |
| *** markvoelker has joined #openstack-meeting-cp | 21:13 | |
| *** gouthamr has quit IRC | 21:15 | |
| *** aselius has joined #openstack-meeting-cp | 21:31 | |
| *** iyamahat__ has quit IRC | 21:34 | |
| *** iyamahat__ has joined #openstack-meeting-cp | 21:34 | |
| *** xyang1 has quit IRC | 21:47 | |
| *** markvoelker has quit IRC | 21:48 | |
| *** MarkBaker has joined #openstack-meeting-cp | 21:59 | |
| *** markvoelker has joined #openstack-meeting-cp | 22:02 | |
| *** markvoelker has quit IRC | 22:06 | |
| *** markvoelker has joined #openstack-meeting-cp | 22:11 | |
| *** MarkBaker has quit IRC | 22:15 | |
| *** markvoelker has quit IRC | 22:16 | |
| *** markvoelker has joined #openstack-meeting-cp | 22:20 | |
| *** markvoelker has quit IRC | 22:25 | |
| *** markvoelker has joined #openstack-meeting-cp | 22:29 | |
| *** sdague has quit IRC | 22:34 | |
| *** markvoelker has quit IRC | 22:34 | |
| *** markvoelker has joined #openstack-meeting-cp | 22:39 | |
| *** markvoelker has quit IRC | 22:43 | |
| *** markvoelker has joined #openstack-meeting-cp | 22:47 | |
| *** markvoelker has quit IRC | 23:22 | |
| *** markvoelker has joined #openstack-meeting-cp | 23:36 | |
| *** markvoelker has quit IRC | 23:40 | |
| *** markvoelker has joined #openstack-meeting-cp | 23:45 | |
| *** markvoelker has quit IRC | 23:49 | |
| *** markvoelker has joined #openstack-meeting-cp | 23:54 | |
| *** markvoelker has quit IRC | 23:59 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!