| *** iyamahat has quit IRC | 00:01 | |
| *** nikhil has joined #openstack-meeting-cp | 00:46 | |
| *** edmondsw has joined #openstack-meeting-cp | 01:28 | |
| *** edmondsw has quit IRC | 01:32 | |
| *** sdague has quit IRC | 02:05 | |
| *** Rockyg has joined #openstack-meeting-cp | 02:50 | |
| *** nikhil has quit IRC | 02:55 | |
| *** edmondsw has joined #openstack-meeting-cp | 03:16 | |
| *** edmondsw has quit IRC | 03:21 | |
| *** Rockyg has quit IRC | 04:42 | |
| *** edmondsw has joined #openstack-meeting-cp | 05:04 | |
| *** edmondsw has quit IRC | 05:09 | |
| *** dfflanders has joined #openstack-meeting-cp | 05:22 | |
| *** iyamahat has joined #openstack-meeting-cp | 06:02 | |
| *** zhipeng has joined #openstack-meeting-cp | 06:08 | |
| *** iyamahat has quit IRC | 06:16 | |
| *** coolsvap has joined #openstack-meeting-cp | 06:20 | |
| *** markvoelker has quit IRC | 06:30 | |
| *** edmondsw has joined #openstack-meeting-cp | 06:52 | |
| *** edmondsw has quit IRC | 06:57 | |
| *** iyamahat has joined #openstack-meeting-cp | 07:14 | |
| *** dfflanders has quit IRC | 07:44 | |
| *** MarkBaker has joined #openstack-meeting-cp | 07:50 | |
| *** zhipeng has quit IRC | 08:10 | |
| *** iyamahat has quit IRC | 08:10 | |
| *** eglute has quit IRC | 08:14 | |
| *** eglute has joined #openstack-meeting-cp | 08:14 | |
| *** markvoelker has joined #openstack-meeting-cp | 08:31 | |
| *** yamahata has joined #openstack-meeting-cp | 08:36 | |
| *** edmondsw has joined #openstack-meeting-cp | 08:41 | |
| *** edmondsw has quit IRC | 08:45 | |
| *** yamahata has quit IRC | 08:46 | |
| *** yamahata has joined #openstack-meeting-cp | 08:47 | |
| *** markvoelker has quit IRC | 09:05 | |
| *** yamahata has quit IRC | 09:40 | |
| *** sdague has joined #openstack-meeting-cp | 09:44 | |
| *** markvoelker has joined #openstack-meeting-cp | 10:02 | |
| *** edmondsw has joined #openstack-meeting-cp | 10:29 | |
| *** edmondsw has quit IRC | 10:33 | |
| *** markvoelker has quit IRC | 10:35 | |
| *** iyamahat has joined #openstack-meeting-cp | 10:35 | |
| *** iyamahat has quit IRC | 10:36 | |
| *** iyamahat_ has joined #openstack-meeting-cp | 10:36 | |
| *** markvoelker has joined #openstack-meeting-cp | 11:32 | |
| *** markvoelker has quit IRC | 12:06 | |
| *** iyamahat_ has quit IRC | 12:06 | |
| *** markvoelker has joined #openstack-meeting-cp | 12:18 | |
| *** edmondsw has joined #openstack-meeting-cp | 12:31 | |
| *** iyamahat has joined #openstack-meeting-cp | 13:04 | |
| *** iyamahat has quit IRC | 13:05 | |
| *** iyamahat has joined #openstack-meeting-cp | 13:05 | |
| *** yamahata has joined #openstack-meeting-cp | 13:33 | |
| *** gouthamr has joined #openstack-meeting-cp | 13:35 | |
| *** iyamahat has quit IRC | 13:35 | |
| *** nikhil has joined #openstack-meeting-cp | 13:58 | |
| *** yamahata has quit IRC | 14:01 | |
| *** sdague has quit IRC | 15:07 | |
| *** xyang1 has joined #openstack-meeting-cp | 15:11 | |
| *** lamt has joined #openstack-meeting-cp | 15:16 | |
| *** edmondsw has quit IRC | 15:46 | |
| *** mriedem has joined #openstack-meeting-cp | 15:49 | |
| mriedem | stvnoyes: when did you say your vacation starts? | 15:52 |
|---|---|---|
| *** iyamahat has joined #openstack-meeting-cp | 15:52 | |
| stvnoyes | tomorrow | 15:52 |
| mriedem | ok | 15:53 |
| mriedem | going through https://review.openstack.org/#/c/463987/ now | 15:53 |
| stvnoyes | ok | 15:54 |
| ildikov | #startmeeting cinder-nova-api-changes | 16:00 |
| openstack | Meeting started Thu Sep 28 16:00:09 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 |
| ildikov | johnthetubaguy jaypipes e0ne jgriffith hemna mriedem patrickeast smcginnis diablo_rojo xyang1 raj_singh lyarwood jungleboyj stvnoyes | 16:00 |
| jgriffith | oh... ildikov is here :) | 16:00 |
| jungleboyj | @! | 16:00 |
| _pewp_ | jungleboyj (ه’́⌣’̀ه )／ | 16:00 |
| ildikov | couldn't start the meeting earlier :) | 16:00 |
| mriedem | o/ | 16:00 |
| ildikov | my availability is a bit hectic today | 16:01 |
| ildikov | who would like to co-chair? | 16:01 |
| stvnoyes | o/ | 16:01 |
| jgriffith | ildikov: happy to help out if needed | 16:01 |
| ildikov | topics are: uses_shared_connection flag, live_migrate patch if there's anything on it, figuring out how R/W and R/O works in Cinder and then agree on policies and our strategy on them | 16:02 |
| ildikov | #chair jgriffith | 16:02 |
| openstack | Current chairs: ildikov jgriffith | 16:02 |
| smcginnis | o/ | 16:02 |
| ildikov | jgriffith: floor is yours on the flag :) | 16:02 |
| jgriffith | I'll start perhaps this will be short | 16:02 |
| jgriffith | I have a Spec and a patch started for the flag.... | 16:02 |
| jgriffith | https://review.openstack.org/#/c/507670/ | 16:03 |
| jgriffith | I'm going to rework that a bit but the general idea remains the same | 16:03 |
| jungleboyj | jgriffith: Cool. I will review. Hadn't looked as I wasn't sure the status. | 16:03 |
| jgriffith | I've since proposed: https://review.openstack.org/#/c/508209/ | 16:03 |
| jgriffith | which I'll use as the foundation for updating the shared-targets flag patch | 16:03 |
| jgriffith | The gist of this is that we'll have a column that indicates shared_targets are used by a backend (defaults to true) | 16:04 |
| jgriffith | and we'll have a column that indicates a backend unique identifier (that's where the UUID column in services comes in) | 16:04 |
| jgriffith | Due to the fact that it is possible to have a single backend serving up multiple c-vol services I'll also add a config option for an admin to set that identifier if needed | 16:05 |
| jgriffith | I need to update the spec for that | 16:05 |
| jgriffith | I believe this addresses the concerns we had around the attach/detach races with shared targets | 16:06 |
| jungleboyj | Oh ... That is why we need that. | 16:06 |
| jungleboyj | I get it now. | 16:06 |
| jgriffith | well, at least it provides mechanisms to deal with it | 16:06 |
| jgriffith | jungleboyj: yeah, so refresher; The proposal was to use the backend-identifier to create a lock if needed | 16:06 |
| jungleboyj | Right. | 16:06 |
| jgriffith | kk | 16:06 |
| jgriffith | Does anybody have any questions about that? | 16:07 |
| mriedem | "indicates shared_targets are used by a backend (defaults to true)" | 16:07 |
| mriedem | why not default to None? | 16:07 |
| mriedem | defaulting to saying all backends are shared targets seems bad | 16:07 |
| jgriffith | mriedem: so default to True seemed "safest" because it won't *hurt* if a backend isn't actually using them | 16:07 |
| jgriffith | The converse however is not the case | 16:08 |
| mriedem | what sets the flag? | 16:08 |
| jgriffith | the migration sets it intially | 16:08 |
| mriedem | sure but at runtime | 16:08 |
| jgriffith | and then service startup verifies it's correct... and additionally volume-create sets it | 16:08 |
| jgriffith | it utilizes capabilitly reporting from the driver | 16:08 |
| mriedem | ok, so existing volumes might have it wrong based on their type/backend, | 16:08 |
| mriedem | but worst case is we're unnecessarily locking, yes? | 16:09 |
| jgriffith | mriedem: that's correct, but they'll have it wrong in such a way that it won't cause problems | 16:09 |
| jgriffith | just slight ineffeciencies | 16:09 |
| jgriffith | mriedem: correct | 16:09 |
| mriedem | ok, maybe point that out in the spec to note we've thought about it :) | 16:09 |
| mriedem | when we ask in a year | 16:09 |
| jgriffith | mriedem: will do, thought I did but that may have just been a comment in the code :) | 16:09 |
| jgriffith | I'll make sure it's noted in the spec and also written up in dev docs | 16:10 |
| mriedem | i haven't read any of it, so idk | 16:10 |
| jgriffith | mriedem: so you're saying there's a chance :) | 16:10 |
| jungleboyj | That all makes sense to me. | 16:10 |
| *** kbyrne has quit IRC | 16:10 | |
| jgriffith | ie that I didn't skip something | 16:10 |
| mriedem | sure | 16:10 |
| jungleboyj | And we are giving the users a way to set what they use to lock if necessary. | 16:10 |
| jgriffith | One suggestion was to use a single column, if None don't use locks, if not None use what's there | 16:11 |
| jgriffith | I didn't like that | 16:11 |
| jgriffith | seemed to obtuse | 16:11 |
| jungleboyj | ++ | 16:11 |
| jgriffith | besides, I think the UUID in the services column is something we should've had already anyway | 16:11 |
| jgriffith | useful for other things | 16:12 |
| jgriffith | So that's about all I have on that front for now | 16:12 |
| *** kbyrne has joined #openstack-meeting-cp | 16:12 | |
| jgriffith | anybody have a burning topic they want to discuss here? | 16:13 |
| jgriffith | Or questions about anything? | 16:13 |
| jgriffith | oh... ildikov has an agenda :) | 16:13 |
| jgriffith | #topic live_migrate patch | 16:13 |
| *** openstack changes topic to "live_migrate patch (Meeting topic: cinder-nova-api-changes)" | 16:13 | |
| jgriffith | stvnoyes: ? | 16:13 |
| stvnoyes | fyi - I'll be away starting tomorrow and all next week. | 16:13 |
| jgriffith | stvnoyes: Unacceptable!! | 16:14 |
| jgriffith | :) | 16:14 |
| stvnoyes | i have a rv up that mriedem is rv'ing now. hopefully I can update it (if needed) before I leave | 16:14 |
| stvnoyes | boy, when they make you chair, it really goes to your head ;-) | 16:14 |
| jgriffith | stvnoyes: you have no idea! | 16:15 |
| jgriffith | :) | 16:15 |
| jungleboyj | stvnoyes: jgriffith Doesn't believe in vacation | 16:15 |
| jgriffith | stvnoyes: mriedem anything else to talk about on live-migrate? | 16:15 |
| *** aselius has joined #openstack-meeting-cp | 16:15 | |
| mriedem | just posted some comments, | 16:15 |
| mriedem | i need to run through the test changes in this patch, | 16:16 |
| stvnoyes | ok great. i'll take a look | 16:16 |
| mriedem | and re-run the live migration patch that hits this code | 16:16 |
| stvnoyes | ...after lunch (if that's ok with john) | 16:16 |
| jgriffith | stvnoyes: I suppose :) | 16:16 |
| johnthetubaguy | I do still hope to review that soon... just sadly hasn't happened yet | 16:16 |
| jgriffith | Ok, sounds like we're moving forward still, just need review time | 16:17 |
| jgriffith | anything else on live-migrate? | 16:17 |
| jgriffith | Going once... | 16:17 |
| stvnoyes | good here | 16:17 |
| jgriffith | Going twice... | 16:17 |
| jgriffith | Cool | 16:17 |
| jgriffith | #topic handling R/O, R/W on Cinder side | 16:18 |
| *** openstack changes topic to "handling R/O, R/W on Cinder side (Meeting topic: cinder-nova-api-changes)" | 16:18 | |
| jgriffith | yeah... umm, that | 16:18 |
| jungleboyj | Yeah ... | 16:18 |
| jungleboyj | So, I have talked to smcginnis and tommylikehu a little on this. | 16:18 |
| jgriffith | jungleboyj: share your findings with us brave ambassador | 16:19 |
| jungleboyj | It seems like the default policy we were leaning towards there is that, if possible, the first attachment is R/W and subsequent ones are only allowed to be R-O . | 16:19 |
| jungleboyj | Not sure if it is possible to do that, but that, I think, is the direction we want to go. | 16:19 |
| johnthetubaguy | that sounds bad for the folks with the cluster management tools | 16:19 |
| jungleboyj | If the admin is smarter than us then he can enable multiple R/W attaches . | 16:20 |
| jungleboyj | johnthetubaguy: How so? | 16:20 |
| johnthetubaguy | they don't have any hooks to call into cinder to do the enable, they just expect two r/w volumes, as I understand it | 16:20 |
| jgriffith | johnthetubaguy: +1 | 16:20 |
| johnthetubaguy | just like moving an IP between two hosts using vrrp | 16:20 |
| johnthetubaguy | or some such | 16:20 |
| jgriffith | FWIW I don't like config as the controller for that either | 16:20 |
| jungleboyj | Well, wouldn't they just set the policy for their cloud to allow multiple R/W attaches . | 16:20 |
| jgriffith | Seems like we could bake it into the attachment request? | 16:21 |
| jgriffith | and as far as backends that don't support it, fall back to our types model like we've done in the past | 16:21 |
| johnthetubaguy | so the attachment request means we change the Nova API so you say read only vs read/write? | 16:21 |
| jgriffith | ie If user wants a multi-attach volume they need to specify that | 16:21 |
| *** iyamahat has quit IRC | 16:21 | |
| jungleboyj | jgriffith: So an option with the attach? | 16:21 |
| jgriffith | johnthetubaguy: yeah, I'm thinking something like an additional option to attach that let's one request what they want (RW or RO) | 16:22 |
| johnthetubaguy | my worry is the concept of "first" seems very racey | 16:22 |
| jungleboyj | If it is a second attach and the backend doesn't support it we fail? | 16:22 |
| smcginnis | Add additional attachment r/o, add additional attachment r/w, etc? | 16:22 |
| jgriffith | johnthetubaguy: +1 | 16:22 |
| jungleboyj | Duh, that seems so much more sensible. :-) | 16:22 |
| jungleboyj | Good thing we have smart people to think of such things. :-) | 16:22 |
| johnthetubaguy | right now, all attachments are r/w basically | 16:23 |
| smcginnis | jgriffith: That means another update to the attach api. And another MV bump, right? | 16:23 |
| jungleboyj | Right. | 16:23 |
| jgriffith | jungleboyj: well, it seems simple until we start implementing and find all the things we're not thinking of :) | 16:23 |
| * jungleboyj laughs | 16:23 | |
| jgriffith | smcginnis: yes it does | 16:23 |
| johnthetubaguy | so we could just explicitly request that for everything from Nova when it creates an attachment | 16:23 |
| jgriffith | smcginnis: or I could wrap it up in the existing bump that's in flight | 16:23 |
| smcginnis | jgriffith: ++ | 16:23 |
| johnthetubaguy | so... can't we ignore this fight for the first version? | 16:24 |
| jgriffith | johnthetubaguy: typically yes, but MV's make everybody think "oh... how do I do this without having to bump again" | 16:24 |
| johnthetubaguy | like v1 everything is r/w like we have today | 16:24 |
| johnthetubaguy | jgriffith: they were invented with the exact opposite intent | 16:24 |
| mriedem | heh yeah was going to say that | 16:25 |
| jgriffith | johnthetubaguy: I know.. but psychology and dev laziness are amazing forces | 16:25 |
| * johnthetubaguy nods | 16:25 | |
| johnthetubaguy | people forgot how bad creating extensions was | 16:25 |
| johnthetubaguy | ...anyways | 16:25 |
| jgriffith | johnthetubaguy: so I'm certainly not opposed to just treating R/O volumes as an additional feature later, independent of multi-attach | 16:25 |
| jgriffith | but I think smcginnis and others had some concerns about people corrupting all of their data | 16:26 |
| johnthetubaguy | right, it feels like we just leave the R/O stuff for next cycle, focus on multi-attach for v1 | 16:26 |
| johnthetubaguy | so some users will not want to use multi-attach till we do the whole R/O attachment thingy | 16:26 |
| jungleboyj | jgriffith: Yeah, how big a gun do we want to give people? | 16:26 |
| johnthetubaguy | but I am saying we just punt that, for now? | 16:26 |
| mriedem | didn't we say at the ptg that people can already corrupt their data today? or was that just specific to boot from volume with the wrong volume? | 16:26 |
| jgriffith | I'm EZ/PZ on this and will let others decide what's best. I can see strong arguments for either approach | 16:26 |
| jgriffith | mriedem: yeah, we may have | 16:27 |
| jungleboyj | I kind of remember that. | 16:27 |
| johnthetubaguy | so people should be able to turn off multi-attach, I think we all agree that right? | 16:27 |
| jgriffith | mriedem: BFV did come up as a special case here | 16:27 |
| mriedem | johnthetubaguy: yes | 16:27 |
| jungleboyj | johnthetubaguy: Yes | 16:27 |
| jgriffith | johnthetubaguy: def | 16:27 |
| mriedem | by policy, that could go into cinder today | 16:27 |
| johnthetubaguy | so this is really about how many folks will turn on the crazy shotgun? | 16:27 |
| johnthetubaguy | mriedem++ | 16:27 |
| johnthetubaguy | I think we add the crazy but simple thing now | 16:28 |
| jgriffith | smcginnis: jungleboyj sound ok to you? | 16:28 |
| johnthetubaguy | and we come back, with user feedback, and work out the read only thing in SYD? | 16:28 |
| smcginnis | Yep | 16:28 |
| jgriffith | honestly I'm almost 100% certain we'll revisit this before it's all said and done anyway :) | 16:28 |
| * johnthetubaguy notes he is not in SYD, and giggles a little | 16:28 | |
| stvnoyes | fyi - oracle's RAC (a clustered FS) needs multiattach R/W, but not bfv | 16:28 |
| jungleboyj | Ok, I think that sounds like a reasonable approach. | 16:29 |
| mriedem | we also said we could put a policy in nova for bfv with multiattach | 16:29 |
| johnthetubaguy | so bfv really only makes sense with RO, thats a good point | 16:29 |
| smcginnis | jgriffith: We revisit everything before it's all said and done most of the time. | 16:29 |
| johnthetubaguy | mriedem: +1 as long as we don't check it 2k times | 16:29 |
| jgriffith | stvnoyes: FYI back at you; RAC is one of the number one use cases I've been asked about for this over the years | 16:29 |
| jgriffith | just FWIW | 16:29 |
| mriedem | johnthetubaguy: this isn't listing instances so we should be fine :) | 16:29 |
| johnthetubaguy | mriedem :) | 16:29 |
| jgriffith | stvnoyes: which means I'm kinda counting on you for insight on this :) | 16:30 |
| smcginnis | Yep, same for me with RAC. | 16:30 |
| johnthetubaguy | ++ on RAC (and whatever the MS thing is called) | 16:30 |
| * jungleboyj sighs about MS . | 16:30 | |
| smcginnis | ASM, Veritas Storage Manager, MS clustering... | 16:30 |
| jgriffith | Ok, so seems like we have a concencus on strategy | 16:31 |
| johnthetubaguy | so.. policy in Nova for BFV, policy in Cinder to turn it off | 16:31 |
| stvnoyes | i'm no RAC expert (I was on oracle virt product prior to this) but I can certainly find things out about it from other people at the company | 16:31 |
| jgriffith | johnthetubaguy: not sure if we'd need that in Nova FWIW | 16:31 |
| jgriffith | johnthetubaguy: Cinder has the bootable flag and knows if it's bootable or not | 16:31 |
| jgriffith | might be cleaner to leave all of those concerns to the Cinder side | 16:31 |
| jgriffith | maybe? | 16:31 |
| johnthetubaguy | oh... even better | 16:31 |
| mriedem | check the recap notes from the ptg, we waffled on this a bit there | 16:32 |
| johnthetubaguy | although I wonder if nova sets that flag | 16:32 |
| smcginnis | Wait, we want a policy for mutliattach too, right? Not just bfv. | 16:32 |
| johnthetubaguy | we said it was needed, overlay tempfs | 16:32 |
| johnthetubaguy | smcginnis: I was meaning bfv with multi-attach | 16:32 |
| johnthetubaguy | my bad | 16:32 |
| jgriffith | ok... so for right now here's my proposal (which I kinda hate that I'm saying it) | 16:32 |
| smcginnis | johnthetubaguy: OK, just making sure it's clear. | 16:32 |
| johnthetubaguy | smcginnis++ | 16:32 |
| jgriffith | 1. Multiattach for data volumes only | 16:33 |
| jgriffith | 2. No consideration of R/O (that's a new and separate thing) | 16:33 |
| johnthetubaguy | (data = bootable=false?) | 16:33 |
| jgriffith | That means no multi-attach BFV for V1 | 16:33 |
| * johnthetubaguy nods | 16:33 | |
| mriedem | this is the recap email btw http://lists.openstack.org/pipermail/openstack-dev/2017-September/122238.html | 16:33 |
| jgriffith | unless as we go it falls nicely into place | 16:33 |
| jungleboyj | jgriffith: ++ | 16:34 |
| jgriffith | Nothings written in stone, except OV's and MV's :) | 16:34 |
| smcginnis | jgriffith: +1 | 16:34 |
| stvnoyes | jgriffith: +1 | 16:34 |
| jgriffith | mriedem: johnthetubaguy sound like a sane plan? | 16:34 |
| johnthetubaguy | I think so... should check some things | 16:34 |
| johnthetubaguy | (2) means all attachments assumed to be r/w attachments? | 16:35 |
| mriedem | might want to also float whatever policy change you're going to make by the operators and dev MLs | 16:35 |
| jgriffith | mriedem: good idea | 16:35 |
| jgriffith | johnthetubaguy: correct on (2) | 16:35 |
| johnthetubaguy | I can take this to the scientific WG meeting, or get oneswig too | 16:35 |
| johnthetubaguy | jgriffith: cool, I think I am happy then | 16:35 |
| jgriffith | johnthetubaguy: that would be great | 16:35 |
| jungleboyj | johnthetubaguy: Yeah, the more feedback we get the better. | 16:36 |
| jgriffith | and of course if folks have more feedback or thoughts we can discuss again in next weeks (or the next weeks....) meeting | 16:36 |
| johnthetubaguy | so I know people want the BFV thing, and want the read_only thing, but the idea here is to keep moving | 16:36 |
| smcginnis | Definitely a good phase II goal to add those. | 16:36 |
| ildikov | the good thing is that we can evolve on those easily | 16:37 |
| jgriffith | johnthetubaguy: yeah, I want it too; and although I'm willing to say it's out of scope here I'm not counting it out | 16:37 |
| smcginnis | But functionality that covers 80% of the needs is better than 0%. | 16:37 |
| johnthetubaguy | I think it should be phase II, like next cycle | 16:37 |
| jgriffith | What I mean is I'd like to set a goal and if we exceed it then nothing wrong with that right? | 16:37 |
| ildikov | well, easier than some other things anyway | 16:37 |
| smcginnis | johnthetubaguy: ++ | 16:37 |
| johnthetubaguy | I think this is more like 40% coverage, but I could be wrong | 16:37 |
| smcginnis | jgriffith: Agree | 16:37 |
| johnthetubaguy | but thats way better than 0% | 16:37 |
| jungleboyj | Right. Styick with the simpler cases to start with and then iterate. | 16:37 |
| jgriffith | also attach has taught me that trying to get 100% in one shot is painful :) | 16:38 |
| johnthetubaguy | so.. I am tempted to see if we can get a spec up for phase II, if someone is willing? | 16:38 |
| jgriffith | not that there was a choice there | 16:38 |
| ildikov | jgriffith: +1 :) | 16:38 |
| jgriffith | johnthetubaguy: I'm willing to draft something for the Cinder side, but honestly knowing how I am with specs and the fact that there are 2 or 3 in front of it I'm not going to promise anything in terms of timelines | 16:39 |
| johnthetubaguy | that fair enough | 16:39 |
| ildikov | jgriffith: johnthetubaguy: I can look into it too, I need to clean up mine in Nova based on the above anyway | 16:39 |
| johnthetubaguy | I guess all we need for feedback is | 16:39 |
| johnthetubaguy | phase II enables BFV multi-attach and RO multi-attach | 16:39 |
| johnthetubaguy | phase I is all R/W attachments, and no BFV | 16:40 |
| johnthetubaguy | ... so we should dig into the BFV thing | 16:40 |
| johnthetubaguy | mriedem I think nova doesn't check the bootable flag right now? | 16:40 |
| jungleboyj | johnthetubaguy: That sounds right. | 16:41 |
| mriedem | would have to look | 16:41 |
| ildikov | johnthetubaguy: in my old multi-attach patch I check whether BFV tries to boot from the multiattach volume and fail if it does | 16:41 |
| johnthetubaguy | ildikov: I think we probably want that version of the policy for now | 16:41 |
| jungleboyj | ildikov: ++ | 16:42 |
| johnthetubaguy | I would love this to be all on the cinder side, but I don't think we respect enough today to make that possible | 16:42 |
| ildikov | johnthetubaguy: I guess it only means code cosmetics by putting the logic elsewhere | 16:42 |
| jgriffith | johnthetubaguy: mriedem it does but I don't know if it's the context your'e looking for... | 16:42 |
| johnthetubaguy | jgriffith: it does? | 16:42 |
| jgriffith | https://review.openstack.org/#/c/508209/ | 16:42 |
| jgriffith | oops | 16:42 |
| jgriffith | https://github.com/openstack/nova/blob/master/nova/compute/api.py#L1034 | 16:43 |
| ildikov | johnthetubaguy: well, the BFV case it's not necessarily on the Cinder side | 16:43 |
| jgriffith | obviously there's needed modifications but the basic flow is there at least | 16:44 |
| jgriffith | and there is the concept of using and checking said flags | 16:44 |
| johnthetubaguy | that's all promising | 16:44 |
| mriedem | oh interesting, | 16:44 |
| mriedem | however, | 16:44 |
| mriedem | NOTE | 16:44 |
| mriedem | that's only when bfv from an image-defined bdm | 16:45 |
| mriedem | which is, | 16:45 |
| mriedem | a volume-backed instance snapshot image | 16:45 |
| mriedem | that has bdm info in it | 16:45 |
| johnthetubaguy | oh, rather than a bdm passed on the boot command line | 16:45 |
| mriedem | oh hold the phone | 16:46 |
| mriedem | i think it's just a really poorly named method | 16:46 |
| johnthetubaguy | actually, that looks badly named | 16:46 |
| jgriffith | mriedem: that's what I thought | 16:46 |
| jgriffith | and a confusing comment | 16:46 |
| jgriffith | re "poorly named method" | 16:46 |
| johnthetubaguy | I assume the volumes nova creates form an image correctly are marked as bootable? | 16:46 |
| jgriffith | because if you trace back to who calls it | 16:46 |
| johnthetubaguy | (not that it matters in that case) | 16:47 |
| mriedem | johnthetubaguy: doesn't say here https://github.com/openstack/nova/blob/master/nova/virt/block_device.py#L513 | 16:47 |
| johnthetubaguy | so seems like cinder policy on bootable=True could work | 16:47 |
| jgriffith | anyway... might need some tweaking of things but there's a foundation at least | 16:47 |
| mriedem | cinder must default bootable to true for a new volume | 16:48 |
| johnthetubaguy | mriedem: yeah, doesn't seem promising there, but it would also never be multi-attach, thankfully) | 16:48 |
| jgriffith | mriedem: ? | 16:48 |
| jgriffith | mriedem: negatory, unless I'm misunderstanding you. Cinder defaults volumes to bootable=False until it actually lays down an image on them | 16:49 |
| mriedem | oh, well we pass an image_id here https://github.com/openstack/nova/blob/master/nova/virt/block_device.py#L514 | 16:49 |
| johnthetubaguy | ah, so passing an image would be the difference | 16:49 |
| johnthetubaguy | phew | 16:49 |
| mriedem | how does this work then? https://github.com/openstack/nova/blob/master/nova/virt/block_device.py#L535 | 16:50 |
| * johnthetubaguy thinks this was all very educational | 16:50 | |
| mriedem | creates a blank volume | 16:50 |
| mriedem | maybe that's not the root bdm | 16:50 |
| johnthetubaguy | thats ephemerals | 16:50 |
| mriedem | ok | 16:50 |
| johnthetubaguy | no I have no clue on the API syntax for that | 16:50 |
| johnthetubaguy | anyways, sounds like phase I plan A is intact | 16:51 |
| jgriffith | Not sure if this is what you guys are looking for: https://github.com/openstack/nova/blob/master/nova/compute/api.py#L1079 | 16:51 |
| jgriffith | sorry, not completely following the dialogue | 16:51 |
| jgriffith | but anyway | 16:51 |
| johnthetubaguy | that's what I found early tracing back, its all good | 16:52 |
| jgriffith | IIRC that's the default BFV path there | 16:52 |
| jgriffith | Ok | 16:52 |
| jgriffith | Okie Dokie... anything else? | 16:53 |
| jgriffith | #topic open-discussion | 16:53 |
| *** openstack changes topic to "open-discussion (Meeting topic: cinder-nova-api-changes)" | 16:53 | |
| jgriffith | ildikov: still with us? Did we miss anything? | 16:53 |
| ildikov | I think we're good | 16:53 |
| jgriffith | smcginnis: jungleboyj ? | 16:53 |
| johnthetubaguy | spoke to a scientific working group in london | 16:53 |
| jungleboyj | I think we are good | 16:53 |
| johnthetubaguy | they seemed happy we are making progress | 16:54 |
| jungleboyj | That is good. | 16:54 |
| ildikov | johnthetubaguy: +1 | 16:54 |
| jgriffith | johnthetubaguy: cool! Our mission is to make the world happy :) | 16:54 |
| johnthetubaguy | I think I convinced them its complicated, hence the delay | 16:54 |
| jgriffith | Or at least the OpenStack world | 16:54 |
| jungleboyj | :-) | 16:54 |
| johnthetubaguy | cool, next steps is review the code and specs? | 16:55 |
| jgriffith | http://www.allmusic.com/album/give-the-people-what-they-want-mw0000196357 | 16:55 |
| jungleboyj | johnthetubaguy: I think so and then start thinking about what we do for Phase II. | 16:55 |
| ildikov | And get the flag into Cinder to get the microversion bump | 16:55 |
| * jgriffith realizes his presentation slides are sooo old he can start recycling them | 16:55 | |
| ildikov | And merge stuff :) | 16:56 |
| jungleboyj | And make people happy | 16:56 |
| johnthetubaguy | jgriffith: s/kilo/queens/ | 16:56 |
| jgriffith | johnthetubaguy: hehe... close enough :) | 16:56 |
| jgriffith | johnthetubaguy: most people haven't upgraded from Kilo yet anyway :) | 16:57 |
| jgriffith | Ok... let's wrap this up then? | 16:58 |
| * johnthetubaguy is happy he working with folks running pike clouds | 16:58 | |
| smcginnis | :) | 16:58 |
| jgriffith | johnthetubaguy: +1 | 16:58 |
| jgriffith | You're a lucky lucky man! | 16:58 |
| jungleboyj | Sounds good. | 16:59 |
| jgriffith | alrighty then, until next week. Thanks all!!! | 16:59 |
| jgriffith | #endmeeting | 16:59 |
| *** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings" | 16:59 | |
| openstack | Meeting ended Thu Sep 28 16:59:19 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:59 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/cinder_nova_api_changes/2017/cinder_nova_api_changes.2017-09-28-16.00.html | 16:59 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/cinder_nova_api_changes/2017/cinder_nova_api_changes.2017-09-28-16.00.txt | 16:59 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/cinder_nova_api_changes/2017/cinder_nova_api_changes.2017-09-28-16.00.log.html | 16:59 |
| ildikov | Thanks All!!! | 16:59 |
| jungleboyj | Thank you! | 16:59 |
| *** mriedem has left #openstack-meeting-cp | 17:10 | |
| *** nikhil has quit IRC | 17:18 | |
| *** coolsvap has quit IRC | 17:29 | |
| *** diablo_rojo has joined #openstack-meeting-cp | 17:38 | |
| *** edmondsw has joined #openstack-meeting-cp | 18:01 | |
| *** edmondsw has quit IRC | 18:04 | |
| *** edmondsw has joined #openstack-meeting-cp | 18:04 | |
| *** nikhil has joined #openstack-meeting-cp | 19:27 | |
| *** nhelgeson has joined #openstack-meeting-cp | 19:49 | |
| *** yamahata has joined #openstack-meeting-cp | 20:57 | |
| *** MarkBaker has quit IRC | 21:20 | |
| *** nikhil has quit IRC | 21:36 | |
| *** iyamahat has joined #openstack-meeting-cp | 21:53 | |
| *** gouthamr has quit IRC | 21:56 | |
| *** gouthamr has joined #openstack-meeting-cp | 22:03 | |
| *** iyamahat_ has joined #openstack-meeting-cp | 22:07 | |
| *** iyamahat has quit IRC | 22:07 | |
| *** iyamahat_ has quit IRC | 22:08 | |
| *** gouthamr has quit IRC | 22:18 | |
| *** gouthamr has joined #openstack-meeting-cp | 22:20 | |
| *** gouthamr has quit IRC | 22:23 | |
| *** iyamahat has joined #openstack-meeting-cp | 22:25 | |
| *** lbragstad has quit IRC | 22:37 | |
| *** xyang1 has quit IRC | 22:50 | |
| *** reed has quit IRC | 23:05 | |
| *** reed has joined #openstack-meeting-cp | 23:08 | |
| *** markvoelker has quit IRC | 23:37 | |
| *** iyamahat has quit IRC | 23:56 | |
| *** yamahata has quit IRC | 23:56 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!