15:02:13 <bswartz> #startmeeting manila
15:02:14 <openstack> Meeting started Thu Dec 15 15:02:13 2016 UTC and is due to finish in 60 minutes.  The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:17 <openstack> The meeting name has been set to 'manila'
15:02:21 <bswartz> hello all
15:02:24 <ganso> hello
15:02:25 <markstur> hi
15:02:25 <vponomaryov> hello
15:02:29 <xyang1> hi
15:02:31 <tommylikehu_> hi
15:02:35 <tbarron> hi
15:02:43 <toabctl> hi
15:02:49 <gouthamr> hello o/
15:03:03 <bswartz> hmm looks like we don't have an agenda for today
15:03:09 <bswartz> >_<
15:03:31 <vkmc> o/
15:03:44 <tommylikehu_> open discuss
15:03:51 <bswartz> I'll just use the remaining topics from last week
15:04:06 <bswartz> first thing though
15:04:10 <bswartz> #topic announcements
15:04:15 <bswartz> O-2 is today
15:04:29 <bswartz> high priority spec freeze is today
15:04:37 <tommylikehu_> today?
15:04:45 <bswartz> yes
15:05:28 <bswartz> we still have 3 unmerged specs
15:05:55 <bswartz> unless we're ready to merge them now, we'll have to kick stuff out of the release
15:06:30 <tommylikehu_> I think we still have a day for them
15:06:39 <tommylikehu_> I am working on it
15:06:42 <bswartz> I should also point out that due to how short Ocata is, unlessimplementation is far along on these specs, they still probably don't stand a chance of landing in Ocata
15:07:07 <bswartz> so let's start with discussion of remaining specs
15:07:11 <bswartz> #topic race conditions
15:07:22 <tbarron> ready to merge after you fix typo in commit msg
15:07:27 <bswartz> #link https://review.openstack.org/#/c/396255/
15:07:45 <vponomaryov> bswartz: small update required, should be fast one
15:07:53 <vponomaryov> bswartz: can fit deadline
15:08:03 <bswartz> changed
15:08:26 <bswartz> can we merge this one or is more work required?
15:08:28 <vponomaryov> actually not ))
15:08:29 <vponomaryov> https://review.openstack.org/#/c/396255/13..14/specs/ocata/eliminate-race-conditions.rst
15:08:37 <ganso> bswartz: needs to address vponomaryov 's concern
15:09:00 <tbarron> I have design questions about access-list fixes spec
15:09:16 <tbarron> but I think we should work on this in ocata
15:09:23 <bswartz> vponomaryov's comment is about testing
15:09:28 <tbarron> fundamental approach seems right
15:09:44 <tbarron> but design issues are more than just work it out in code review
15:09:52 <bswartz> My stance is that the only required testing is regression testing -- things should not get worse
15:10:07 <bswartz> yes there are more tests we can add but those are out of scope
15:10:42 <gouthamr> i'm back today, so i will take a look at tbarron's concerns
15:10:57 <tbarron> gouthamr: and I could just be confused :D
15:11:02 <bswartz> tbarron: I want to voer that topic next
15:11:14 <bswartz> wb gouthamr
15:11:20 <tbarron> bswartz: sorry, thought you'd moved to it
15:11:31 <bswartz> I want to close on race conitions
15:11:37 <gouthamr> thanks bswartz... tbarron: nope, i did have what you suggest in code, but my statements on the spec may be misleading..
15:11:49 <bswartz> if more work is needed I can do it today but if not I'd like to just merge it
15:12:00 * dustins skids into meeting
15:12:09 <bswartz> I think all the cores have read it
15:12:17 * bswartz marks dustins tardy
15:12:52 <ganso> bswartz: I think there is an overall confusion about the spec's purpose, and I agree with vponomaryov
15:13:00 <ganso> bswartz: your spec title is "Eliminate race conditions"
15:13:19 <ganso> bswartz: but there are a few use cases listed, and we need rally and other tests to capture other race conditions and fix them
15:13:29 <tbarron> ganso: are you concerned about when the work would be Done?
15:13:34 <ganso> bswartz: so, it should be in fact titled "Mechanism for elimination of race conditions"
15:13:43 <bswartz> ganso: are you suggesting a change to the title? to the problem statment?
15:13:48 <ganso> bswartz: as they will still exist once what's in the scope of the spec is implemented
15:14:32 <ganso> bswartz: I initially assumed that testing, enumerating the race conditions etc were going to be in scope
15:14:36 <ganso> bswartz: but you stated that they are not
15:14:39 <tbarron> fwiw, it's more of an "architecture" or "high level design" or "specification for eliminating" than a "mechanism"
15:14:46 <bswartz> I see
15:14:48 <tbarron> and I'm fine with that
15:14:57 <bswartz> well we want to do all of that but we have to face the reality of time
15:15:02 <ganso> I am fine too, but I think it is good to address the confusion
15:15:05 <bswartz> and ask what is achieveable in ocata
15:15:15 <tbarron> mechanism should be switchable in a good architecture
15:15:29 <vponomaryov> bswartz: then spec should say what we will do, so, I agree with ganso
15:15:43 <bswartz> tbarron: I'd argue that the mechanism is the architecture
15:16:01 <tbarron> if we have to scope what will get done we won't start
15:16:04 <bswartz> okay please put some more -1 on that spec and I'll push another draft after the meeting
15:16:13 <ganso> bswartz: ok
15:16:17 <tbarron> bswartz: I won't dig in on that but I disagree :)
15:16:23 <bswartz> nobody go to sleep without reviewing PS15
15:16:30 <bswartz> :-/
15:16:37 <bswartz> alright moving on
15:17:09 * bswartz curses gerrit
15:17:18 <bswartz> #topic access rules
15:17:39 <gouthamr> #link https://review.openstack.org/#/c/399049/
15:17:47 * tbarron already spoke out of turn
15:18:21 <bswartz> #link https://review.openstack.org/#/c/399049/
15:19:03 <bswartz> Looks like I forgot to put my vote on here
15:19:30 <tbarron> so i think denies can race with allows here and it's OK if we re-read the DB before calling into the driver, but
15:19:39 <tbarron> the state machine may need a little revision
15:19:56 <tbarron> that's a design issue, not just a coding issue
15:20:04 <bswartz> tbarron: have you discussed that with gouthamr
15:20:10 <tbarron> but the fundamental approach is good and we should proceed
15:20:10 <bswartz> I thought that case was addessed
15:20:20 <tbarron> i brought this stuff up while he was on vacation
15:20:27 <bswartz> I can reread that part of the sepc
15:20:56 <bswartz> gouthamr?
15:21:01 <tbarron> it may just be a matter of wording and my understanding, but e.g. I think we need a 'new'->'denyiing' transition
15:21:11 <gouthamr> tbarron: you do have that..
15:21:17 <bswartz> tbarron: +1
15:21:22 <tbarron> nothing we can't work out
15:21:26 <tbarron> gouthamr: I didn't see it
15:21:34 <tbarron> so this may just be my misreading
15:21:50 <gouthamr> tbarron: let me take a look and update it.
15:22:08 <bswartz> I see applying to denying
15:22:40 <tbarron> gouthamr: why don't you add that there will be a state-machine diagram like what bswartz is providing in the devref, where it is kept up to date as implementation is done
15:22:51 <tbarron> i asked bswartz for same in his spec
15:22:56 <gouthamr> tbarron: yep, good idea
15:23:05 <tbarron> reality is that these need to be up-to-date as manila evolves
15:23:11 <bswartz> tbarron: you mean the diagram will be moved to the devref and maintained there right?
15:23:15 <gouthamr> tbarron: i meant to add that to the devref anyway after the implementation
15:23:16 <tbarron> yes
15:23:20 <bswartz> ok
15:23:24 <bswartz> any other issues with this spec?
15:23:33 <gouthamr> yeah, tooz
15:23:35 <gouthamr> :P
15:23:41 <bswartz> what about it
15:23:59 <gouthamr> it's not gotten a lot of review attention
15:24:11 <bswartz> how does that afect the spec
15:24:17 <tbarron> gouthamr: working top down with other stuff to do too :D
15:24:42 <bswartz> we'll get the implementation reviews done
15:24:57 <gouthamr> bswartz: sure, it's a dependency in both the specs we discussed so far..
15:25:11 <bswartz> I'm asking about the spec now
15:25:20 <bswartz> can it be merged or does it need another patchset?
15:25:42 <vponomaryov> no -1 - no concerns ))
15:25:45 <gouthamr> needs another patchset
15:25:52 <bswartz> it's getting late for some core reviewers and we have a deadline today
15:26:09 <tbarron> i can work my issues out w/ gouthamr today
15:26:16 <bswartz> okay
15:26:44 <bswartz> remember that vponomaryov, toabctl, and ganso are all someone further east of us
15:26:54 <bswartz> not to mention gouthamr who is on the other side of the planet
15:27:00 <gouthamr> :P
15:27:04 <ganso> lol
15:27:06 <gouthamr> i'm on the same side as you are now
15:27:07 <vponomaryov> aand on vacation )
15:27:11 <bswartz> oh you got back?
15:27:26 <bswartz> okay hope you're not too jetlagged gouthamr
15:27:28 <gouthamr> yes, this morning :)
15:27:34 <vponomaryov> vponomaryov will be able to review specs in about 4-5 hours
15:27:40 <bswartz> okay
15:27:43 <bswartz> let's move on then
15:27:46 <bswartz> #topic ipv6
15:27:56 <tommylikehu_> how do you think of this vponomaryov
15:28:06 <bswartz> #link https://review.openstack.org/#/c/362786/
15:28:32 <vponomaryov> vponomaryov: could have been updated according to comments, for the moment it mixes two different goals under the one spec
15:28:43 <vponomaryov> details can be seen in manila chat
15:29:09 <vponomaryov> it should become simpler that it is now
15:29:19 <vponomaryov> separating part of logic to different spec
15:29:24 <vponomaryov> that will be in pike+
15:29:31 <vponomaryov> if will be in general
15:29:41 <vponomaryov> s/that/than/
15:29:43 <tbarron> vponomaryov: i think those two goals - assuming they are two - came from bswartz asking how to support use of  v6 and v4 at the same time
15:30:04 <tbarron> so if tommylikehu_ does what you suggest, the question is whether bswartz will -1 it
15:30:16 <bswartz> yeah I though this was covered last night but I don't see the spec updated acordingly
15:30:36 <tbarron> bswartz: another conversation this morning provides different guidance
15:30:47 <vponomaryov> let's have about 6 hours before we close the doors
15:30:50 <bswartz> the key here is that our mechanism for supporting v6 in network plugins is to make network plugins aware of both v4 and v6
15:31:06 <bswartz> sorry I haven't read the scrollback in manila channel
15:31:19 * bswartz reads
15:31:45 <bswartz> is it just a matter of the word support vs enabled?
15:31:54 <tommylikehu_> no
15:32:09 <vponomaryov> bswartz: it is matter of supporting multiple networks/subnets "at once"
15:32:33 <bswartz> vponomaryov: can't a subnet have v4+v6 together?
15:32:41 <vponomaryov> bswartz: no
15:32:43 <bswartz> or do I misunderstand neutron
15:32:49 <cknight> bswartz: IMO, it's not OK to to do v4 or v6, but not both.
15:32:51 <tommylikehu_> bswartz:  you asked the question I did
15:32:56 <vponomaryov> bswartz: neutron subnet has only one Ip version
15:33:02 * bswartz curses
15:33:19 <tbarron> use case of exporting both ipv4 & ipv6 and having compute instances choose either to do mount is not suported.
15:33:23 <vponomaryov> on eneutron network canhave two subnets, each for each Ip versions
15:33:30 <bswartz> I see
15:33:43 <bswartz> vponomaryov can a "port" have 2 subnets?
15:33:51 <tbarron> to support it we'd have to have multiple subnets/gateways per share network
15:33:56 <markstur> the spec shouldn't need to include making the network plug-ins support both 4 and 6. Similar to the drivers it should just be a good enough spec that we can add support once this framework is in place.
15:34:01 <vponomaryov> bswartz: yes, it can be related to several subnets
15:34:15 <vponomaryov> bswartz: we use that feature of port in generic driver
15:34:36 <bswartz> okay
15:34:50 <vponomaryov> markstur: but it covers case to support IPv6 in network plugins
15:34:52 <bswartz> I think I understand what the neutron guys were thinking then
15:35:02 <tbarron> i can use same port from compute instance to mount via ipv4 or mount via ipv6, manually setting up exports
15:35:33 <bswartz> okay so we have to make a decision
15:35:45 <bswartz> it seems like we're not ready to deal with the issues around network plugins and v4+v6
15:35:53 <markstur> it covers ipv6 for drivers, but that doesn't mean all the work will be done to enhance the drivers
15:35:57 <tbarron> vponomaryov: it's the "subnets" that are IPv4 or IPv6 specific, not the neutron "networks"
15:36:04 <bswartz> so do we leave that unspecified, or do we specify some limiteed behavior that we know we can implement?
15:36:24 <ganso> bswartz: I think we can go with "limited" for now
15:36:44 <bswartz> ganso: what should that lmited behavior be?
15:36:49 <cknight> bswartz: we need to understand the endgame, even if there is an intermediate step
15:37:13 <vponomaryov> bswartz: still support only one network-subnet per network plugin
15:37:21 <ganso> bswartz: if we know we can achieve v4+v6 network plugin in the future, we can proceed supporting only one for now
15:37:24 <bswartz> cknight: I think we've missed that boat -- as we don't understand, and we're out of time
15:37:26 <vponomaryov> bswartz: but allow it to be either IPv6 or IPv4
15:37:30 <ganso> bswartz: in other words, not both at the same time
15:37:48 <cknight> bswartz: then the spec should wait
15:38:01 <bswartz> I don't think it's a good idea to punt the whole spec -- ipv6 is valuable and important
15:38:21 <vponomaryov> bswartz: that is why I am saying to exclude part of it
15:38:22 <markstur> what about just doing dhss=false ipv6 -- does that make sense?
15:38:25 <bswartz> okay let's keep working on it then and try to understand the correct solution now
15:38:31 <gouthamr> markstur: +1
15:38:33 <tbarron> cknight: if the end game means supporting ipv4 and ipv6 export locations from the same share to compute instances who can choose either at will then we have to redo our plugin arch before allowing any ipv6 access by that standard
15:38:58 <ganso> dhss=False will not touch plugin, that will further reduce the scope
15:39:06 <ganso> s/plugin/plugins
15:39:08 <bswartz> yeah I think we know that eventually there must be a way to create share servers with v4+v6
15:39:11 <cknight> bswartz, tbarron: yes, ipv6 is valuable, but I'm hesitant to plunge forward in the dark if we don't know where we're going.
15:39:15 <gouthamr> ganso: +1 i think this is a saner approach
15:39:23 <markstur> even if we have only ipv4 network plugins for dhss=true (I was hoping we'd at lease know how we want to do that though)
15:39:26 <bswartz> it's not clear if that should be done w/ multiple plugins or with smarter plugins that understand both
15:39:52 <bswartz> cknight: I'm willing to use the rest of the meeting to reach the answer
15:39:59 <tbarron> restrict to DHSS=False for now?
15:40:16 <bswartz> tbarron: you mean make share servers limited to ipv4/
15:40:34 <gouthamr> yes, don't claim support for ipv6 with share servers now
15:40:38 <tbarron> yes, it's an option
15:40:52 <bswartz> gouthamr technically share servers already do support ipv6
15:40:59 <vponomaryov> right
15:41:03 <bswartz> at least the standlone network plugin has v6 support
15:41:09 <vponomaryov> but not tested
15:41:12 <gouthamr> bswartz: technically, yes, but not our neutron network plugins
15:41:13 <tbarron> but not v4 at the same time
15:41:19 <gouthamr> so, we can work on that
15:41:29 <bswartz> lets decide how we will eventually support both
15:41:34 <bswartz> the options seem to be:
15:41:45 <tbarron> and cannot have v6 at the same time without plugin re-architecture
15:41:47 <bswartz> 1) separate network plugins, one for v4 and one for v6
15:42:12 <bswartz> 2) modify network plugins to handle 2 subnets where necessary for v4+v6
15:42:38 <markstur> The drivers need to know if the configured plug-in will support 4 or 6 or both
15:42:47 <vponomaryov> (2) requires rearchitecture of getting network info, that is out of scope for adding general IPv6 support
15:43:04 <bswartz> markstur: that's a driver interface issue which is technically independent of the network plugin interface
15:43:20 <bswartz> vponomaryov: we can decide it's what we want to do, but postpone that work until pike
15:43:23 <ganso> vponomaryov: but that is related to DHSS=True in general, for all drivers, that could be done in pike, if we consider it to be necessary to achieve what we want
15:43:24 <tbarron> Is there a downside to #2 other than that it may be a lot of work?
15:43:34 <bswartz> what we don't want is to leave it undecided
15:43:45 <tommylikehu_> markstur: it's already descibed in spec
15:44:30 <bswartz> tbarron: good point
15:44:42 <markstur> We don't have a final spec for #2
15:44:48 <bswartz> I was leaning towards a different flavor of (2) where neutron simply did v4+v6 in one subnet
15:45:06 <bswartz> but since that's not possible it seems like we could still do it, albeit with more effort
15:45:07 <vponomaryov> tbarron: it is a LOT of work
15:45:21 * tbarron thanks vponomaryov for signing up
15:45:30 <ganso> lol
15:45:31 <markstur> can we just push that part to pike and do the easy stuff in ocata?
15:45:35 <cknight> bswartz: Let's consider the user experience.  A user should know from a share type that a share will be available on v4, v6, or both.  And a share of that type should report corresponding export locations.  We should reject any option that doesn't eventually get us there.
15:45:42 <tbarron> vponomaryov: so we should maybe not decide immediately ...
15:45:59 <bswartz> cknight: both options on the table allow us to do that
15:46:04 <tbarron> vponomaryov: I am interested in this issue though and don't want to just dismiss #2 without investigation
15:46:06 <bswartz> I think the user-facing part of the design is clear
15:46:27 <bswartz> what's unclear is what the admin will need to put in the conf file to get DHSS=true+v4+v6
15:46:44 <cknight> bswartz: Having separate network plugins can do that?
15:46:51 <vponomaryov> cknight: yes
15:46:55 <tbarron> cknight: so does that imply share network will have both ipv4 and ipv6 subnets if both familiies are in use?
15:46:56 <bswartz> cknight: that's option (1)
15:47:29 <ganso> gouthamr: does #2 tie in any way with your spec for supporting multiple subnets in share networks?
15:47:31 <vponomaryov> bswartz: both options about supporting multiple subnets
15:47:38 <vponomaryov> bswartz: there should be other options
15:47:50 <bswartz> vponomaryov: what do you propose?
15:47:58 <vponomaryov> bswartz: support any IP version for single network
15:47:59 <tbarron> option #1 may be more expedient but having to configure 4 plugins (2*user, 2*admin) could be a pain and potentially confusing
15:48:21 <bswartz> no matter what we'll end up with 2 or more subnets thanks to neutron's design
15:48:37 <vponomaryov> bswartz: so, we "fix" existing network plugns to be able to work with "single" network-subnet of any Ip versions if we have issues with it
15:49:03 <bswartz> vponomaryov and when we want both together how to we modify the archirecture?
15:49:10 <vponomaryov> and allow access rules be of any IP version that is related to used network
15:49:37 <vponomaryov> bswartz: share-network interface, config-interface, share-manager logic
15:49:42 <bswartz> vponomaryov: that doesn't satisfy the contract of the API
15:49:53 <vponomaryov> bswartz: all of above for supporting multiple network-subnets
15:50:06 <bswartz> users will expect dual v4+v6 access to shares
15:50:19 <vponomaryov> it is separate goal
15:50:27 <vponomaryov> not general support of IPv6
15:50:40 <bswartz> yes but we're making a decision on that now to unblock the spec
15:50:41 <vponomaryov> which can be the only type of networks
15:50:59 <bswartz> we can explcitly not implement it
15:51:04 <bswartz> but we will specify what we plan to do
15:51:33 <bswartz> let's talk about downsides
15:51:48 <bswartz> (1) has the downside that it's ugly from a config perspective
15:52:00 <tbarron> +1
15:52:03 <bswartz> we already have 2 plugins -- one for users and one for admin export loations
15:52:16 <bswartz> (1) would mean having 3 or 4 plugins per backend
15:52:42 <bswartz> on the plus side (1) gives you a ridiculous amount of flexibility
15:52:55 <tommylikehu_> :)
15:52:56 <tbarron> and confusion about plugins is already a disincentive for deployers to do DHSS=True
15:53:00 <bswartz> you could use standalone plugin for v4 and neturon plugin for v6 (possibly)
15:53:12 <gouthamr> ganso: i need a rehash at all the discussions that have been happening around this - i might need to update the mutiple subnets spec with the feedback here - currently, the spec proposes multiple subnets with a tie-in to AZs
15:53:27 <bswartz> the downsides to (2) seem to be that it's more work and less flexible
15:53:40 <bswartz> however (2) might lead to better experience for admin
15:53:47 <tbarron> and support
15:54:09 <vponomaryov> bswartz: or we can have both approaches ))
15:54:19 <tommylikehu_> how ?
15:54:21 <vponomaryov> bswartz: so deployer choose one of them to use )
15:54:31 <bswartz> taking away choices leads to happier customers -- apple teaches us this
15:54:44 <tbarron> vponomaryov wants to drive me out of the support maniila in openstack business :D
15:54:50 <vponomaryov> bswartz: you call deployer a user?
15:55:12 <tbarron> they are the kind of user who buys openstack support
15:55:21 <bswartz> vponomaryov: we care about experiences of both end users and deployers/admin users
15:55:46 <bswartz> although when the 2 are in conflict we prioritize the end user
15:55:49 <vponomaryov> bswartz: it is an option anyway
15:55:55 <vponomaryov> I do not say I am for it
15:56:26 <bswartz> I'm in favor of (2) still
15:56:42 <tbarron> but we don't know how much work that is, right?
15:57:02 <tbarron> we have reason from vponomaryov to believe it's not at all trivial
15:57:06 <vponomaryov> bswartz: it is end-goal, current spec is intermediate goal
15:57:10 <bswartz> keep a single plugin, and make plugins handle both -- however declare that in the short term it doesn't work
15:57:22 <bswartz> nothing will be trivial
15:57:25 <tommylikehu_> how much time do we left for this code job?
15:57:35 <bswartz> 5 weeks minus holidays
15:58:00 <tommylikehu_> We do not have holidays in china
15:58:07 <vponomaryov> wow ))
15:58:10 <bswartz> err 6 weeks minus holidays
15:58:12 <vponomaryov> sounds great
15:58:21 <tommylikehu_> :(..
15:58:25 <xyang1> tommylikehu_: what about chinese new year?:)
15:58:51 <tbarron> vponomaryov: you review up to ukranian xmas and we'll pick it up afterwards :D
15:58:54 <tommylikehu_> let me check
15:58:57 <bswartz> it 's 6 weeks to feature freeze, but proposal freeze is in 4 weeks
15:59:14 <bswartz> okay we're out of time
15:59:27 <bswartz> tommylikehu: I think we're going to stick with what we talked about last night
15:59:47 <tommylikehu_> #2
15:59:51 <bswartz> please update the spec to say that plugins should be able to support either or both v4 and v6
15:59:59 <tommylikehu_> ok
16:00:09 <vponomaryov> bswartz: does it mean to support any amount of subnets?
16:00:12 <bswartz> but it's acceptable for plugins to simply fail to support both
16:00:19 <bswartz> vponomaryov: just 2 I think
16:00:43 <bswartz> we'll leaev the improvements to neutron plugins out of scope
16:00:45 <markstur> but having 2 subnets is not in O?
16:00:52 <bswartz> markstur: correct
16:00:57 <bswartz> okay I'm going to end the meeting
16:01:06 <bswartz> everyone review the high priority specs until they merge
16:01:07 <markstur> thankyou
16:01:17 <bswartz> anything not merged today is out
16:01:26 <bswartz> #endmeeting