Thursday, 2017-11-30

*** sdague has quit IRC00:01
*** david-lyle has quit IRC00:03
*** dklyle has joined #openstack-meeting-cp00:03
*** david-lyle has joined #openstack-meeting-cp00:07
*** dklyle has quit IRC00:08
*** edmondsw has quit IRC00:15
*** dklyle has joined #openstack-meeting-cp00:29
*** david-lyle has quit IRC00:30
*** david-lyle has joined #openstack-meeting-cp00:55
*** dklyle has quit IRC00:55
*** david-lyle has quit IRC01:01
*** edmondsw has joined #openstack-meeting-cp01:24
*** edmondsw has quit IRC01:29
*** yamahata has quit IRC02:54
*** iyamahat has quit IRC02:54
*** diablo_rojo has quit IRC03:13
*** edmondsw has joined #openstack-meeting-cp03:13
*** edmondsw has quit IRC03:17
*** aselius has quit IRC03:21
*** iyamahat has joined #openstack-meeting-cp04:10
*** nhelgeson has quit IRC04:11
*** coolsvap has joined #openstack-meeting-cp04:19
*** yamahata has joined #openstack-meeting-cp04:26
*** edmondsw has joined #openstack-meeting-cp06:49
*** edmondsw has quit IRC06:54
*** david-lyle has joined #openstack-meeting-cp07:19
*** gouthamr has quit IRC07:20
*** markvoelker has quit IRC07:37
*** yamahata has quit IRC07:38
*** edmondsw has joined #openstack-meeting-cp08:38
*** markvoelker has joined #openstack-meeting-cp08:38
*** edmondsw has quit IRC08:42
*** MarkBaker has quit IRC08:44
*** iyamahat has quit IRC08:52
*** _pewp_ has quit IRC09:39
*** _pewp_ has joined #openstack-meeting-cp09:39
*** Guest18637 has quit IRC09:41
*** kbyrne has quit IRC09:43
*** kbyrne has joined #openstack-meeting-cp09:44
*** gnarld_ has joined #openstack-meeting-cp09:44
*** david-lyle has quit IRC09:46
*** coolsvap has quit IRC09:59
*** tommylikehu has quit IRC10:09
*** tommylikehu has joined #openstack-meeting-cp10:15
*** tommylikehu has quit IRC10:15
*** tommylikehu has joined #openstack-meeting-cp10:15
*** MarkBaker has joined #openstack-meeting-cp10:47
*** sdague has joined #openstack-meeting-cp11:02
*** MarkBaker has quit IRC11:53
*** tang has joined #openstack-meeting-cp12:07
tanghello?12:07
*** coolsvap has joined #openstack-meeting-cp12:10
*** edmondsw has joined #openstack-meeting-cp12:14
tang你好啊12:14
*** tang has left #openstack-meeting-cp12:17
*** edmondsw has quit IRC12:20
*** edmondsw has joined #openstack-meeting-cp13:18
*** markvoelker has quit IRC13:23
*** markvoelker has joined #openstack-meeting-cp13:24
*** margaret has joined #openstack-meeting-cp14:03
*** coolsvap has quit IRC14:19
*** iyamahat has joined #openstack-meeting-cp15:00
*** yamahata has joined #openstack-meeting-cp15:00
*** zhipeng has joined #openstack-meeting-cp15:19
*** MarkBaker has joined #openstack-meeting-cp15:21
*** zhipeng has quit IRC15:22
*** gouthamr has joined #openstack-meeting-cp15:27
*** nikhil has joined #openstack-meeting-cp15:42
*** mriedem has joined #openstack-meeting-cp15:48
ildikov#startmeeting cinder-nova-api-changes16:00
openstackMeeting started Thu Nov 30 16:00:15 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
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.16:00
*** openstack changes topic to " (Meeting topic: cinder-nova-api-changes)"16:00
openstackThe meeting name has been set to 'cinder_nova_api_changes'16:00
ildikovjohnthetubaguy jaypipes e0ne jgriffith hemna mriedem patrickeast smcginnis diablo_rojo xyang1 raj_singh lyarwood jungleboyj stvnoyes16:00
jungleboyj@!16:00
_pewp_jungleboyj ( ^_^)/16:00
* johnthetubaguy hides at back of the room16:01
* ildikov sees johnthetubaguy :)16:01
* jungleboyj pulls johnthetubaguy to the front 16:01
jungleboyjNice spot for you here buddy.16:01
mriedemo/16:01
* johnthetubaguy doh!16:01
ildikovok, let's start16:02
* smcginnis hides behind johnthetubaguy 16:02
ildikovso we have the last bit of the new flow enablement in Nova: https://review.openstack.org/#/c/330285/16:03
ildikovI was begging for review on the Nova meeting today16:03
mriedemneed to re-run my tempest patch against that to make sure we're failing if trying to attach the same volume to the same instance16:04
mriedemtwice16:04
mriedemhttps://review.openstack.org/#/c/515426/16:04
ildikovalthough I think I need to rely on mriedem and johnthetubaguy with that or maybe I can ask jaypipes too16:04
ildikovmriedem: right, thanks for the reminder16:05
johnthetubaguyildikov: don't think there were many open questions now, trying to remember the hour or so I spent going through the patch16:05
ildikovjohnthetubaguy: we must be close now, I did some polishing on the functional tests too by now16:06
johnthetubaguyI was worried about left over attachments in a few places, but they didn't look like new bugs (missing unreserve call too)16:07
johnthetubaguyotherwise felt close I think16:07
ildikovyep, I remember that one, we can fix it in a follow up patch16:07
*** MarkBaker has quit IRC16:08
ildikovI would not want to increase the size of this one if we can avoid that16:08
ildikovwe can figure out the remaining nits on the review16:09
ildikovI have the libvirt patch for multi-attach on top of this one, we can get that landed too if we agree on a few nits as it doesn't do any harm but will help enabling multi-attach16:10
smcginnisildikov: Looks like the patch at least needs a rebase. Just waiting to see if there are any other changes?16:10
smcginnisThe flow patch, not the libvirt one.16:11
ildikovsmcginnis: we were talking about doing one more version bump once the shared_targets changes land16:11
mriedemildikov: have you run my tempest test for multiattach on your nova multiattach patch? i'm assuming that tempest test is in need of cleaning up now though.16:11
ildikovsmcginnis: this one: https://review.openstack.org/#/c/520676/16:11
ildikovand jgriffith promised a follow-up patch with the API changes and the microversion bump16:12
smcginnisildikov: Ah, OK. Maybe jungleboyj can take a look at that (hint, hint)16:12
* jungleboyj will look.16:12
ildikovmriedem: nope, the multi-attach changes need some update now to match the new flow16:12
smcginnisAlthough a couple good questions jgriffith should probably respond to first.16:12
jgriffithildikov: if/when the shared_targets implementation lands yes16:13
ildikovsmcginnis: yeah, that kept me back from begging for review again :)16:13
ildikovjgriffith: plz check the two minor comments on that one :)16:13
ildikovjgriffith: so I can annoy people to land it then16:13
jungleboyjAh, the shared targets one.  Cool.16:13
ildikovmriedem: the libvirt change only sets the 'shareable' flag, so it doesn't enable multi-attach right away16:14
ildikovmriedem: johnthetubaguy: as for multi-attach, jgriffith has a spec on the Cinder side for that: https://review.openstack.org/#/c/523608/16:15
ildikovmriedem: johnthetubaguy: plz give it a quick read so we don't miss anything critical16:16
mriedemso simply creating a volume with multiattach=True isn't good enough?16:17
ildikovjungleboyj: smcginnis: quick question, who could help us with the policy changes in Cinder?16:17
jungleboyjThe spec looked pretty good yesterday.  I will look through it again now that it is updated.16:17
jgriffithmriedem: I'd prefer not to do that if we can avoid it16:17
smcginnisildikov: Policy as far as adding a policy check for this? That's just done in the implementation now. Is that what you're asking?16:17
jgriffithmriedem: using the type and capabilities filter makes that a bit more solid16:18
jungleboyjildikov:  Good question.  Need a volunteer there.16:18
jgriffithmriedem: and it allows you to update/modify a volume after the fact16:18
* jungleboyj smiles at ildikov and jgriffith 16:18
jungleboyjjgriffith:  ++16:18
ildikovsmcginnis: I think so, I'm one of the least knowledgable people around as far as policy goes :(16:18
jgriffithmriedem: there's pros/cons to either; but using types fits a bit more with our existing workflows and requriements so I thought it was a good fit16:19
smcginnisjgriffith: Helps with scheduler ability to place it too I think.16:19
jungleboyjsmcginnis:  Right16:19
mriedemthat's fine, it's basically a flavor extra spec16:19
jungleboyjYou could then have multi-attach capable and incapable backends.16:19
smcginnisildikov: Yeah, no worries. With the policy-in-code changes, we just need to add the policy checking in the code for those operations.16:19
jgriffithsmcginnis: yes for sure; you can make the flag set the capability but that's another story :)16:19
jungleboyjThe scheduler would get the right onw.16:19
ildikovsmcginnis: oh, ok, that does not sound too bloody, but we'll see I guess :)16:20
jgriffithsmcginnis: ildikov I had just assumed that's part of the code, not sure what's being asked WRT to help on that16:21
jgriffith^^ what I mean is part of the job for whomever implements the spec/changes16:21
jungleboyjRight.16:22
*** MarkBaker has joined #openstack-meeting-cp16:22
ildikovjgriffith: if that person is me, then I'll need at least someone to ask dumb questions and still get sane answers :)16:22
smcginnisildikov: Yeah, should be enough existing examples that it won't be too bad.16:23
ildikovsmcginnis: sounds good16:23
jungleboyjildikov:  Right.  There are lots of policy examples.16:23
*** MarkBaker has quit IRC16:24
johnthetubaguyjgriffith: do you allow changing of the volume while it is attached?16:24
*** MarkBaker has joined #openstack-meeting-cp16:24
jgriffithjohnthetubaguy: so that's an interesting one..... retype does allow that sort of thing if it does not include a migration16:25
johnthetubaguyso that would be a problem on the Nova side16:25
jgriffithjohnthetubaguy: that's probably worth detailing and clearing up in the spec16:25
jgriffithjohnthetubaguy: how so?16:25
jgriffithjohnthetubaguy: I mean being a problem on the Nova side?16:26
johnthetubaguywe need to tell libvirt to stop its caching when its multi-attach16:26
johnthetubaguywe can't do that if its already attached16:26
jgriffithjohnthetubaguy: ahh, right... on *all* of the attachments right16:26
ildikovjgriffith: yes16:26
smcginnisjohnthetubaguy: No way to change that setting while attached?16:27
jgriffithjohnthetubaguy: I'll look into that; we may end up back at using a flag on create again then :(16:27
jgriffithjohnthetubaguy: where did things on the extend attached volume end up on the Nova side?16:27
johnthetubaguyits fine if you can update the flag only when there are no attachment records I guess16:27
smcginnisJust, from the Cinder side, it's very simple to just retype to enable/disable multiattach this way.16:28
jgriffithjohnthetubaguy: we could just use the same mechanism there maybe?16:28
mriedem"where did things on the extend attached volume end up on the Nova side?" not sure what that means16:28
johnthetubaguyso detach can fail, when the volume is in use, so its not easy on the Nova side16:28
johnthetubaguymriedem: I think the answer is we never merged that code?16:28
jgriffithmriedem: there was a patch a while back to allow extending an attached volume16:28
mriedemit was merged in pike16:29
jgriffithmriedem: said operation required a disconnect/reconnect on the Nova side IIRC16:29
*** MarkBaker has quit IRC16:29
mriedemhttps://review.openstack.org/#/c/454322/16:29
jgriffithmriedem: thanks16:29
*** aselius has joined #openstack-meeting-cp16:30
johnthetubaguyah...16:30
ildikovhmm, so are we saying now that a volume retype in Cinder would trigger hacking the libvirt domain xml to set the 'shareable' flag while the volume is attached?16:31
johnthetubaguywould that work?16:32
jgriffithildikov: it's an option... johnthetubaguy ildikov I don't think it's worth doing at the onset though16:33
jgriffithanother option is to put login in Cinder to check that condition and disallow it at the API layer16:33
ildikovjohnthetubaguy: I don't know, I never checked whether or not it is possible16:33
jgriffithgrrr16:33
jgriffiths/login/logic/16:34
johnthetubaguyseems a good starting point16:34
jgriffithand make that a policy as well so if we change it some day we have that ability16:34
smcginnisSo we need to block retype if a) it's attached, and 2) the retype include a multiattach capability change?16:34
jgriffithsmcginnis: correct16:34
jgriffithsmcginnis: that's what I'm thinking for now at least16:34
ildikovjgriffith: sounds like a good start to me16:34
smcginnisBleh. OK, that works.16:34
jgriffithsmcginnis: it's pretty easy to infer that on the Cinder side16:34
jgriffithsmcginnis: yeah... not great, but not the worst either16:35
smcginnisYeah, at least it won't involve a too much hackery.16:35
jungleboyjIt seems like a reasonable start.16:35
jungleboyjWould rather limit the function than hack up Nova.16:35
jungleboyjIt still gives us better all-around function.16:36
ildikovI wouldn't be comfortable with the hackery on the Nova side now, so if these restrictions would work in Cinder that made me happy for now16:36
jgriffithwe used to disallow retype of in-use volumes16:38
jgriffithanyway... I'll look at it and see what we can/can't do16:38
jgriffithif nothing else fall back to using an option on create16:38
ildikovjgriffith: sounds good, thank you16:39
johnthetubaguyoption on create that can be updated when there are no attachments?16:40
jgriffithjohnthetubaguy: no16:40
jungleboyjjgriffith:  Sounds good.16:40
jgriffithjohnthetubaguy: if it's an option on create it's static for the life of the volume16:40
jgriffithjohnthetubaguy: if you want to change then you have to do something like create-from-volume with that option16:40
johnthetubaguyOK16:41
jgriffithjohnthetubaguy: I'm saying that if restricting the retype of an in-use volume looks hacky/ugly then revisit the use of a create flag16:41
ildikovjgriffith: johnthetubaguy: we talked about changing the flag if the volume is not attached, I guess we can iterate on that later if we would fall back to the flag16:41
jgriffith?16:41
smcginnisThat's the nice thing with using volume type. It let's us switch that without forcing the user to do stupid things.16:41
*** aselius has quit IRC16:42
jgriffithildikov: well if you're going to do the same monkey trick with a create flag then there's zero point in going that route as opposed to a type16:42
*** aselius has joined #openstack-meeting-cp16:42
ildikovjgriffith: the request to change the flag or type or whatever we choose came up earlier16:43
jgriffithildikov: what?16:43
jungleboyjjgriffith:  Retyping versus having to clone a volume though, far less obvious to the end user as far as how to get the desired result.16:43
jgriffithildikov: if you're talking about using a create flag, and then saying implement something to allow that to be changed then I'm saying that's a horrible idea and I'm back to just doing type/retype16:44
ildikovjgriffith: so I think it'll come up again once we have the feature enabled, so better to figure out now what we are willing or not willing to/can or can't do16:44
jgriffithand won't consider the flag option, because you're proposing putting in the same logic checks that would need to go into retype which is an accepted/general solution to these sorts of things already16:44
ildikovjgriffith: type sounds good if we can block that for attached volumes for now16:44
jgriffithildikov: yeah16:44
ildikovjgriffith: then we're on the same page? :)16:45
jungleboyjSounds like it.16:45
ildikovjgriffith: anyway, I don't want to argue, just remember having a proposal in Cinder to update the multiattach flag a while back, so if type/retype will be the solution for that with care, I'm all supportive; if we have other ideas that would be fine with me too16:48
ildikovjgriffith: what fits into Cinder the best16:49
ildikovso to sum it up16:49
ildikovI will rebase the new attach patch in Nova and re-run the tests a couple of times to see whether the blocking to attach the same volume to the same instance works fine16:50
ildikovthen get that patch merged finally if everything works well16:50
ildikovin Cinder let's have the shared_targets patch merged and have the microversion bump in place16:51
*** MarkBaker has joined #openstack-meeting-cp16:51
ildikovupdate the Cinder spec with the type/retype restrictions we've talked about just now16:51
ildikovand that will cover a weekly work I think easily16:51
ildikovdid I miss anything?16:51
jungleboyjildikov: That sounds good to me.16:53
ildikovjungleboyj: cool :)16:54
ildikovmriedem: johnthetubaguy: jgriffith: plz let me know if I missed any critical item from the list above16:54
ildikovanything else to discuss today?16:54
jgriffithildikov: sounds like you got it16:54
ildikovjgriffith: cool, thanks16:55
ildikovok, then thanks everyone for joining today!16:57
ildikovlet's get some progress by the meeting next week!! :)16:57
ildikovhave a good rest of the day everyone!16:57
ildikovBTW, I know it's KubeCon next week16:57
ildikovwill we still have the majority of people available?16:58
jungleboyjI will be around.16:58
jungleboyjWanted to go but couldn't work it out.16:58
ildikovjohnthetubaguy: mriedem: jgriffith: smcginnis: ^^?16:58
ildikovjungleboyj: sadness, next time I guess16:58
jungleboyjildikov:  Indeed.  I am sure jgriffith  and smcginnis will be good reps.16:59
smcginnisI'll be at Kubecon, so probably won't be able to attend.16:59
*** david-lyle has joined #openstack-meeting-cp16:59
ildikovok, will chat with the Nova guys then I guess :)16:59
ildikovthanks again16:59
ildikovlet's move the further chats to the channels17:00
jungleboyjSounds good.17:00
ildikov#endmeeting17:00
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"17:00
openstackMeeting ended Thu Nov 30 17:00:14 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)17:00
openstackMinutes:        http://eavesdrop.openstack.org/meetings/cinder_nova_api_changes/2017/cinder_nova_api_changes.2017-11-30-16.00.html17:00
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/cinder_nova_api_changes/2017/cinder_nova_api_changes.2017-11-30-16.00.txt17:00
openstackLog:            http://eavesdrop.openstack.org/meetings/cinder_nova_api_changes/2017/cinder_nova_api_changes.2017-11-30-16.00.log.html17:00
*** mriedem has left #openstack-meeting-cp17:01
*** nhelgeson has joined #openstack-meeting-cp17:06
*** iyamahat has quit IRC17:07
*** yamahata has quit IRC17:08
*** kmalloc has quit IRC17:11
*** iyamahat has joined #openstack-meeting-cp17:33
*** MarkBaker has quit IRC17:36
*** yamahata has joined #openstack-meeting-cp17:51
*** nikhil has quit IRC17:51
*** diablo_rojo has joined #openstack-meeting-cp18:22
*** felipemonteiro has joined #openstack-meeting-cp19:17
*** kmalloc has joined #openstack-meeting-cp20:07
*** edmondsw has quit IRC22:24
*** edmondsw has joined #openstack-meeting-cp22:24
*** edmondsw has quit IRC22:25
*** edmondsw_ has joined #openstack-meeting-cp22:27
*** edmondsw_ has quit IRC22:31
*** felipemonteiro has quit IRC22:44
*** felipemonteiro has joined #openstack-meeting-cp23:02
*** iyamahat_ has joined #openstack-meeting-cp23:22
*** iyamahat has quit IRC23:22
*** MarkBaker has joined #openstack-meeting-cp23:32
*** felipemonteiro has quit IRC23:38
*** MarkBaker has quit IRC23:54
*** felipemonteiro has joined #openstack-meeting-cp23:56
*** felipemonteiro_ has joined #openstack-meeting-cp23:57

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!