15:01:19 <bswartz> #startmeeting manila
15:01:19 <openstack> Meeting started Thu Mar 16 15:01:19 2017 UTC and is due to finish in 60 minutes.  The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:23 <openstack> The meeting name has been set to 'manila'
15:01:29 <bswartz> hello all
15:01:30 <gouthamr> hello o/
15:01:31 <ganso> hello
15:01:32 <vponomaryov> Hello
15:01:34 <tbarron> hi
15:01:37 <cknight> Hi
15:01:37 <dustins> heya! \o
15:01:38 <tommylikehu_> hey
15:01:38 <zhongjun_> hi
15:01:47 <xyang1> hi
15:02:03 <bswartz> wow good attendance!
15:02:07 <toabctl> hi
15:02:16 <bswartz> courtesy ping: markstur
15:02:32 <markstur_> hi
15:02:44 <bswartz> #topic announcements
15:03:13 <bswartz> err, no announcements this week
15:03:27 <bswartz> just a reminder that P-1 is 4 week from now
15:03:35 <bswartz> #agenda https://wiki.openstack.org/wiki/Manila/Meetings
15:03:47 <bswartz> #topic Specs
15:04:01 <bswartz> #link https://review.openstack.org/#/q/status:open+project:openstack/manila-specs
15:04:19 <bswartz> only a few specs proposed this cycle
15:04:21 <jungleboyj> o/
15:04:56 <tommylikehu_> more are under their way here
15:04:57 <bswartz> are there any specs being worked on that aren't in gerrit yet?
15:05:13 <zhongjun_> I have one
15:05:16 <bswartz> tommylikehu_: can you give us an idea of which ones?
15:05:17 <tommylikehu_> some from zhongjun
15:05:33 <bswartz> tommylikehu_: you should re-propose the IPv6 spec for pike
15:05:39 <zhongjun_> infinite share
15:05:40 <tommylikehu_> bswartz: yes
15:05:41 <bswartz> in gerrit it would just be a file move
15:06:04 <tommylikehu_> bswartz: thanks for reminder
15:07:18 <bswartz> also while high priority specs will not have a different deadline during Pike, we still need to designate them as high priority to make sure reviewers prioritize those reviews if we care about any in particular
15:07:39 <bswartz> I want to re-designate the ipv6 spec high priority after it's proposed in gerrit again
15:08:07 <bswartz> if anyone wants to nominate some others this is the place to do it
15:08:17 <bswartz> oh I just remembered, we had an etherpad for ocata specs
15:08:23 <bswartz> I should make one for pike
15:08:42 <bswartz> #action bswartz will make pike specs etherpad
15:08:43 <zhongjun_> I want to nominate "ensure share" spec
15:09:04 <bswartz> zhongjun_: is that ready for review now or is it WIP?
15:09:28 * bswartz is reading it
15:09:32 <zhongjun_> Now, the code is not start.
15:09:33 <bswartz> #link https://review.openstack.org/#/c/446494/1/specs/pike/ensure-share.rst
15:09:56 <zhongjun_> But we have simple spec
15:10:09 <bswartz> I'm not sure about this CLI command
15:10:44 <bswartz> the intention of the proposal was mostly to get the driver interface corrected -- my hope was that most of the cleanup activities would occur automatically on driver startup
15:11:05 <tommylikehu_> zhongjun_ 'ensure' may not be a valid sub command
15:11:19 <bswartz> yes and if we do add a new CLI, I wouldn't name it ensure
15:11:22 * vkmc sneaks in
15:11:24 <vkmc> o/
15:11:27 <bswartz> that's a secondary concern though
15:11:33 <zhongjun_> I just want to add new cli to update our resources(such as share), and remove ensure share interface
15:11:35 * bswartz marks vkmc tardy
15:11:40 <bswartz> lol
15:11:52 <vkmc> *sad panda*
15:11:53 <zhongjun_> yes
15:12:04 <zhongjun_> We will change the name
15:12:14 <markstur> what would make ensure high priority or regular priority?
15:12:34 <markstur> Seems high-ish, but I'm asking how we determine
15:12:36 <vponomaryov> markstur: our votes ))
15:12:39 <gouthamr> vkmc: zorrilla, no pandas here.
15:12:39 <bswartz> zhongjun_: I don't know how closely you followed the PTG discussion, but the main point of it was to create a mechanism for drivers to fix things during version upgrades or other configuration changes
15:12:54 <tommylikehu_> vote for high pri
15:12:58 <bswartz> gouthamr: did you ever post the videos you took?
15:13:07 <markstur> vponomaryov: Just regular democracy popularity contest with no concern for the ramifications?
15:13:08 <gouthamr> bswartz: no :( never got around to that
15:13:24 <bswartz> gouthamr: if you don't do it soon then they're not valuable
15:13:38 <gouthamr> bswartz: +1 will get them online asap
15:13:46 <gouthamr> thanks for the reminder
15:13:52 <bswartz> markstur: I think of high priority as "we should drop everything else to get this done"
15:14:22 <xyang1> bswartz: there are a few specs from ganso.  Is he still working on them?
15:14:24 <bswartz> ensure share *is* an important feature, but if it somehow didn't get into pike while other stuff did I think that would be okay
15:14:31 <ganso> xyang1: no, I am not :(
15:14:42 <xyang1> ganso: :(
15:15:26 <vponomaryov> ganso: why? you have so much personal time )))
15:15:41 <ganso> vponomaryov: at the moment I have almost zero time...
15:16:16 <bswartz> yeah until we hear better news about ganso's situation I think we should find new owners for the stuff he was working on or we should move it to the back burner
15:16:58 <markstur> Yeah. If we hi-pri is  like a must, hold-the-release thing then ensure isn't that high. But we could vote to put more attention on it if that helps.
15:17:06 <ganso> bswartz: +1
15:17:11 <bswartz> ganso: a while ago we talked about marking the migration feature non-experimental -- there's no reason to not still do that right?
15:17:47 <ganso> bswartz: yes
15:18:01 <bswartz> ganso: do you have time even to do that?
15:18:14 <bswartz> or should we find someone else to do that microversion bump?
15:18:26 <ganso> bswartz: currently I don't, sorry
15:18:30 <bswartz> k
15:19:04 <zhongjun_> bswartz: if "ensure share" didn't get into pike,  we still have some problem, We need to restart our service when drivers wants to fix things  during other configuration changes
15:19:05 <bswartz> somebody please hire ganso to work on manila again!
15:19:11 <gouthamr> +1000
15:19:13 <ganso> bswartz: +100000000000000000
15:19:22 <vkmc> +++++
15:19:43 <vponomaryov> ganso: I thought you are still employed
15:19:43 <tommylikehu_> lol
15:19:45 <bswartz> getting back to ensure share
15:19:57 <bswartz> vponomaryov: yes but to do non-manila stuff
15:20:09 <zhongjun_> lol
15:20:12 <ganso> vponomaryov: exactly
15:20:16 <vponomaryov> ok
15:20:18 <bswartz> #topic ensure share
15:20:26 <zhongjun_> thanks
15:20:29 <bswartz> the main challenge is how this feature scales
15:20:55 <bswartz> it's not reasonable to do background polling of all the shares constantly
15:21:10 <bswartz> and it's not reasonable to update all shares on every share manager restart
15:21:24 <bswartz> however there are times when every share will need to be updated
15:21:48 <bswartz> so the challenge is how to detect those times and invoke the driver logic at only those times
15:22:06 <vponomaryov> new api
15:22:19 <vponomaryov> call-on-demand
15:22:20 <ganso> bswartz: IIRC, last time we discussed this, somebody mentioned flagging shares as "needing repair" or something like that
15:22:22 <bswartz> vponomaryov: that requires an admin to do the right thing
15:22:27 <zhongjun_> so we just add new CLI command,  Manual update
15:22:39 <bswartz> there are 2 problem with that approach:
15:22:45 <vponomaryov> bswartz: just poke the triger
15:22:47 <bswartz> 1) admins forget sometimes
15:23:00 <bswartz> 2) once the share manager is up and running it might be too late
15:23:09 <dustins> ganso: I was thinking of something like a "dirty bit" would be a halfway decent idea for this
15:23:37 <vkmc> dustin++
15:23:49 <tommylikehu_> bswartz: 1) no one could prevent that from happening
15:23:55 <zhongjun_> ganso: we can specify the share when we use new cli command
15:23:56 <bswartz> I'm particularly concerned about a case where the driver expects some value to be present after a code upgrade, when there are existing shares from before the upgrade that don't have that value
15:24:01 <vkmc> I'd rather don't need to depend on the good judgment of admins
15:24:14 <dustins> vkmc: Agreed
15:24:32 <zhongjun_> bswartz: admins could write a script to update
15:24:36 <bswartz> tommylikehu_: if the share manager can detect that a code upgrade has occured, it could automate the process of fixing share before the driver init completes
15:25:02 <ganso> bswartz: main complexity is the "detect" part
15:25:14 <bswartz> or alternatively we could hook into the existing commands that get run when code upgrades occur (like the db-sync)
15:25:31 <zhongjun_> admins could write a script to regularly update
15:25:37 <vkmc> the idea of a dirty bit and some sort of trigger when amount of shares are in need of an update in the control plane makes sense for me
15:25:49 <tommylikehu_> bswartz:  do it in a automatical way is always prefect. but we should considering weather we could do it perfectly, without that depends on administrator is a necessary step
15:26:01 <dustins> And then having that trigger amount be configurable
15:26:16 <vkmc> yup
15:26:38 <bswartz> tommylikehu_: there's more than one use case for this feature -- some of them require perfect accuracy, in other cases a "best effort" approach might be sufficient
15:26:50 <vponomaryov> ok, how we will detect "reconfiguration"?
15:26:59 <bswartz> for the "best effort" cases an admin API/CLI might be fine
15:27:00 <dustins> I feel like we should be avoiding anything that involves running on a restart of a service, since I imagine we're not restarting these services often
15:27:36 <bswartz> dustins: you should read https://lwn.net/Articles/191059/
15:28:41 <bswartz> vponomaryov: we would need to store some piece of state per-share
15:28:49 * dustins adds to reading list
15:29:11 <bswartz> vponomaryov: perhaps a "dirty bit" or perhaps a generation number, or even one of those horrifying alembic hashes
15:29:17 <vponomaryov> bswartz: easier to have API
15:29:34 <zhongjun_> I think so
15:30:24 <bswartz> I'll reply to this spec, but I think we need to enumerate several use cases for this feature and make sure the proposal addresses them all satisfactorily
15:30:41 <tommylikehu_> bswartz: great
15:30:57 <zhongjun_> of course, I will add these use cases
15:31:10 <bswartz> I know that an admin API would fix some things, but I'm fairly certain there are things it would not work for -- and those are the reasons that stuff like ensure_volume() exists in cinder
15:32:38 <bswartz> well if not a high priority spec this should should be a review focus spec because it seems that we all have opinions
15:32:48 <bswartz> please review this spec and others
15:33:02 <bswartz> I'd like to get some specs merged earlier than the day of the deadline >_<
15:33:19 <vponomaryov> just some? ))
15:33:27 <vponomaryov> not all of them? )
15:33:41 <bswartz> vponomaryov: anything else would be asking too much I'm afraid
15:33:47 <tbarron> I favor a very small number of high prio specs and more resources on getting what we've started done and working reliably.
15:34:03 <tbarron> ipv6, multiple subnets on share nets, race conditions, ...
15:34:15 <vponomaryov> share groups )
15:34:20 <tbarron> vponomaryov: ack
15:34:22 <bswartz> tbarron: yes, we have to focus our limited resources
15:34:39 <tbarron> looks like tooz backend is finally making some progress
15:34:58 <bswartz> #topic open discussion
15:35:09 <bswartz> so the agenda was short today
15:35:23 <bswartz> anyone want to discuss something else?
15:35:24 <tbarron> (real momentum for using etcd v3 as well or instead of zookeeeper, with devstack support)
15:35:45 <bswartz> tbarron: who is working on that?
15:36:06 <tbarron> bswartz: lemme chase down the thread, just a minute
15:37:21 <tbarron> bswartz: dims and others, eg jd
15:37:28 <tbarron> http://lists.openstack.org/pipermail/openstack-dev/2017-March/113885.html
15:37:34 <bswartz> tbarron: ty
15:37:52 <bswartz> looks like we're done
15:37:58 <bswartz> thanks all
15:38:04 <jungleboyj> Thank you.
15:38:05 <tommylikehu_> thanks
15:38:08 <bswartz> #endmeeting