15:00:26 <bswartz> #startmeeting manila
15:00:27 <openstack> Meeting started Thu Feb 18 15:00:26 2016 UTC and is due to finish in 60 minutes.  The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:29 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:29 <bswartz> hello all
15:00:30 <cknight> Hi
15:00:31 <openstack> The meeting name has been set to 'manila'
15:00:34 <rraja> hi
15:00:34 <tbarron> hi
15:00:36 <tpsilva> hello
15:00:37 <vponomaryov> hi
15:00:37 <xyang2> hi
15:00:43 <ganso> hello
15:00:54 <csaba> hi
15:01:03 <bswartz> #agenda https://wiki.openstack.org/wiki/Manila/Meetings
15:01:12 <bswartz> sorry I didn't have time to look over the agenda before the meeting
15:01:59 <bswartz> looks like we have an extremely light agenda
15:01:59 <toabctl> hi
15:02:09 <dustins> \o
15:02:11 <bswartz> #topic feature proposal freeze
15:02:24 <bswartz> so feature freeze is 2 weeks away
15:02:46 <markstur_> hi
15:02:48 <bswartz> and as usual, we're freeze new feature submissions 2 weeks early to give ourselves time to get everything reviewed/merged
15:03:12 <bswartz> so any new feature patches submitted after midnight UTC tonight should get automatic -2
15:03:27 <bswartz> new bugfixes are okay, doc changes are okay
15:04:21 <bswartz> between here and feature freeze we should focus on merging the current payload of feature patches
15:04:52 <bswartz> regarding the exact timing of feature freeze
15:05:03 <bswartz> our goal is to cut the milestone on March 1st
15:05:16 <bswartz> absolute latest we can cut it is March 3rd
15:05:31 <bswartz> which brings up another topic
15:05:37 <bswartz> #topic gate tests
15:06:24 <bswartz> so at the start of Mitaka, we planned to replace the generic driver for our gate tests with 2 new drivers: LVM for no-share-server and LXD for share-server
15:06:55 <bswartz> a lot of progress has been made on the LXD driver, but it's not ready to become our driver for gate testing
15:07:31 <bswartz> so expect a lot of rechecking as the generic driver continues to have stability issues and timeout issues
15:08:01 <bswartz> because the gate is going to get slammed towards the end of the month, we have a better chance of merging things earlier rather than later
15:08:26 <bswartz> hopefully for Newton, the LXD driver will have a record of stability and we can switch to it
15:08:56 <bswartz> #topic open discussion
15:09:05 <bswartz> that's all I have for today
15:09:08 <bswartz> any other topics?
15:09:43 <bswartz> has anyone found out about potential travel to Germany for summer midcycle?
15:09:49 <cknight> bswartz: I have a topic.
15:09:51 <bswartz> any definite yeses or nos?
15:11:27 <bswartz> alright cknight, you're up
15:11:40 <cknight> #topic Export location metadata
15:11:47 <cknight> We recently added export location metadata, whereby drivers may add more info about each share export path.
15:11:57 <cknight> There is only one standard export location attribute now, is_admin_only, which identifies paths that are only available to manila admins on the control plane for things like migrations.
15:12:11 <cknight> I'd like to propose another standard attribute, preferred, which would identify paths that are most efficient and should be tried first.
15:12:20 <cknight> This would not require a database schema change.  It only needs a microversion bump.
15:12:28 <cknight> Thoughts?
15:12:48 <gouthamr> cknight: metadata is not being returned at this point i thought
15:13:03 <gouthamr> cknight: through the REST api
15:13:10 <vponomaryov> gouthamr: this is the poitn of microversion bump
15:13:12 <cknight> gouthamr: Any non-standard values are kept in the DB but not exposed via REST.
15:13:33 <vponomaryov> gouthamr: each metadata k-v pair can be added to API view
15:13:48 <vponomaryov> gouthamr: as model attr
15:13:55 <bswartz> I don't like the idea of storing something that's not exposed
15:14:02 <cknight> vponomaryov: it's a separate question whether *all* k-v pairs should be added to the view.
15:14:07 <bswartz> if it's not on the approved list of keys, we shouldn't even store it
15:14:10 <cknight> vponomaryov: I was surprised they were not.
15:14:20 <jcsp> cknight: is "preferred" meant to be a bool?  doesn't sound very generic, as some systems would have location-dependent preferences (i.e. rather say what datacenter I'm in and let clients decide which they prefer)
15:14:38 <vponomaryov> bswartz: right, that is why cknight proposes one
15:14:44 <gouthamr> vponomaryov: yes, right now, in your export_locations_metadata patch, i remember you removing them from the API return
15:14:53 <cknight> jcsp: Yes, it just says that some paths are direct to the controller that owns the disks, and some are indirect.
15:15:08 <gouthamr> vponomaryov cknight: so we need a bump if we're returning export_location_metadata
15:15:09 <cknight> jcsp: Preferred is used in ALUA, I think in a similar way.
15:15:40 <vponomaryov> gouthamr: not whole metadata, pair, agreed one
15:15:51 <vponomaryov> gouthamr: and th eone is being proposed
15:16:14 <jcsp> cknight: ALUA is a pretty hardware-ish thing to bring into a shared filesystem abstraction imho
15:16:26 <cknight> jcsp: it's just an illustration.
15:16:39 <gouthamr> vponomaryov: ah; i also feel admin_export_location is also a metadata key, i dunno the reason why we have is_admin_only on all the export_locations..
15:16:42 <jcsp> I'm not saying it's not useful, I'm just not sure it's really generic -- maybe we should admit that all of these types of things are special cases?
15:16:46 <cknight> jcsp: and "what datacenter I'm in" sounds a lot more lilke an AZ than what I'm proposing
15:17:10 <gouthamr> vponomaryov: afterthoughts, really :)
15:17:23 <bswartz> jcsp: we talked about the idea of a locality type of metadata key, but we couldn't agree on what format that should take
15:17:36 <vponomaryov> gouthamr: "is_admin_only" influences API logic
15:17:41 <bswartz> we have AZs as one level of locality
15:17:51 <vponomaryov> gouthamr: hiding/whowing ELs
15:17:55 <bswartz> anything more specific might be revealing implementation details which manila should not expose
15:18:04 <vponomaryov> gouthamr: s/whowing/showing/
15:19:30 <cknight> Any further discussion?
15:19:32 <tbarron> would it make sense to have a preference rank (ordinal) instead of a bool?  could always start with just 0 and 1.
15:19:55 <cknight> tbarron:  Can you offer a use case?
15:20:26 <bswartz> tbarron: that implies more than 2 tiers of preferred-ness, which I've never seen in the real world
15:20:37 <tbarron> not sure, just wondering whether direct/indirect is the only case down the road
15:21:19 <bswartz> I don't want to rush towards complexity because of vague possibilities
15:21:23 <tbarron> sure
15:21:32 <bswartz> we can always add another key on top of preferred, if we develop a 3rd tier
15:21:36 <cknight> jcsp: FWIW, my use case for preferred is "hardware-ish", although it needed be presented that way.
15:22:29 <cknight> jcsp: In a storage cluster where the disks are owned by exactly one controller but the I/O can come into any node, it's valuable to know the direct path.
15:22:51 <bswartz> so cknight are you proposing anything other than just adding "preferred" to the view returned by the API and bumping the microversion?
15:22:58 <cknight> jcsp: The tenant doesn't need to know the details, just which one to try first.
15:23:01 <jcsp> yep, familiar with the problem, but better not to encode that kind of assumption into manila.  In general (software) case we could have N priorities depending on e.g. network configuration
15:23:13 <jcsp> at very least it should be an integer rather than a boolean
15:23:14 <cknight> bswartz: nope that's it for now.
15:23:47 <cknight> jcsp: of course, but such things aren't visible to manila.  this one is.
15:24:33 <jcsp> I don't see a difference between a dual ported SAS case (not visible to manila) and an N-ported ethernet switch case (also not visible to manila).  I think it's simpler to say "order than priority" than to say "order by priority where there may only be two priorities"
15:24:44 <jcsp> *order by priority
15:25:12 <cknight> jcsp: are you arguing for Tom's suggestion?  an ordinal?
15:25:18 <bswartz> jcsp: I just worry it's harder to document and harder for clients to understand, when in practice you'll only ever have 2 values
15:25:39 <bswartz> preferred=true/false is hard to misunderstand
15:26:18 <bswartz> preference=0,1,2... is slightly trickier
15:26:24 <vponomaryov> +1 for boolean as integers do not say which way has better priority
15:26:45 <vponomaryov> better/bigger
15:27:17 <bswartz> some will assume 0 is better than 2 and others will assume 2 is better than 0
15:27:22 <bswartz> and we no nobody reads the docs
15:28:03 * gouthamr wonders if he shouldn't write the docs for DR then
15:28:09 <bswartz> also, adding preferred=true/false does not prevent us from also adding preference=0,1,2... in the future if we need it
15:28:22 <bswartz> gouthamr: lol nice try!
15:28:26 <gouthamr> haha
15:28:33 <jcsp> since it's the SAS controllers that want the feature I guess it doesn't make much difference.  It just itches to introduce something like that as a global generic thing but build in limitations based on hardware knowledge.
15:28:40 <vponomaryov> gouthamr: bswartz just said that nobody read it ))
15:28:45 <cknight> bswartz: OK, this would be a really small change.  Not sure if it'll be up today, but I'll pursue it and we can discuss further in the review.
15:29:10 <bswartz> cknight: I can push a patch if you don't have time
15:29:13 <gouthamr> vponomaryov: gerrit reviewers will :)
15:29:15 <bswartz> the deadline is today
15:29:24 <vponomaryov> gouthamr: yeah, right ))
15:29:40 <cknight> bswartz: ok, we can discuss offline, then.  thanks, everyone.
15:30:07 <bswartz> anything else?
15:30:20 <bswartz> jcsp: I'm going to respond to your email
15:30:28 <bswartz> we can discuss it on IRC if you'd prefer though
15:30:39 <ganso> I have a question
15:30:41 <jcsp> bswartz: I have time now
15:30:42 <bswartz> (after the meeting)
15:31:01 <bswartz> ganso: for all of us or just for me?
15:31:01 <ganso> is LVM job going to be changed to voting still in Mitaka, prior to March 3rd?
15:31:07 <bswartz> ah
15:31:24 <bswartz> I would like it to be, if it has a more stable record
15:31:47 <bswartz> initially we saw some random failure with LVM too
15:31:56 <bswartz> could be a bug in the driver
15:32:01 <ganso> I have seen some random failures lately
15:32:08 <vponomaryov> no one considers ZFs be voting?
15:32:11 <bswartz> I'd rather fix those before making it voting
15:32:22 <bswartz> vponomaryov: it can't vote if it's not merged
15:32:31 <vponomaryov> after it is merged
15:32:33 <vponomaryov> ))
15:32:57 <bswartz> I would prefer to wait until newton to make it voting, if we agree it should vote at all
15:33:37 <bswartz> I have no objections to making it vote in newton if it can be demonstrated to be stable and if it can give us better test coverage than LVM or generic for no-share-servers mode
15:34:12 <bswartz> okay I think we're done
15:34:15 <bswartz> thanks all
15:34:27 <bswartz> #endmeeting