15:01:19 #startmeeting manila 15:01:19 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:23 The meeting name has been set to 'manila' 15:01:29 hello all 15:01:30 hello o/ 15:01:31 hello 15:01:32 Hello 15:01:34 hi 15:01:37 Hi 15:01:37 heya! \o 15:01:38 hey 15:01:38 hi 15:01:47 hi 15:02:03 wow good attendance! 15:02:07 hi 15:02:16 courtesy ping: markstur 15:02:32 hi 15:02:44 #topic announcements 15:03:13 err, no announcements this week 15:03:27 just a reminder that P-1 is 4 week from now 15:03:35 #agenda https://wiki.openstack.org/wiki/Manila/Meetings 15:03:47 #topic Specs 15:04:01 #link https://review.openstack.org/#/q/status:open+project:openstack/manila-specs 15:04:19 only a few specs proposed this cycle 15:04:21 o/ 15:04:56 more are under their way here 15:04:57 are there any specs being worked on that aren't in gerrit yet? 15:05:13 I have one 15:05:16 tommylikehu_: can you give us an idea of which ones? 15:05:17 some from zhongjun 15:05:33 tommylikehu_: you should re-propose the IPv6 spec for pike 15:05:39 infinite share 15:05:40 bswartz: yes 15:05:41 in gerrit it would just be a file move 15:06:04 bswartz: thanks for reminder 15:07:18 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 I want to re-designate the ipv6 spec high priority after it's proposed in gerrit again 15:08:07 if anyone wants to nominate some others this is the place to do it 15:08:17 oh I just remembered, we had an etherpad for ocata specs 15:08:23 I should make one for pike 15:08:42 #action bswartz will make pike specs etherpad 15:08:43 I want to nominate "ensure share" spec 15:09:04 zhongjun_: is that ready for review now or is it WIP? 15:09:28 * bswartz is reading it 15:09:32 Now, the code is not start. 15:09:33 #link https://review.openstack.org/#/c/446494/1/specs/pike/ensure-share.rst 15:09:56 But we have simple spec 15:10:09 I'm not sure about this CLI command 15:10:44 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 zhongjun_ 'ensure' may not be a valid sub command 15:11:19 yes and if we do add a new CLI, I wouldn't name it ensure 15:11:22 * vkmc sneaks in 15:11:24 o/ 15:11:27 that's a secondary concern though 15:11:33 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 lol 15:11:52 *sad panda* 15:11:53 yes 15:12:04 We will change the name 15:12:14 what would make ensure high priority or regular priority? 15:12:34 Seems high-ish, but I'm asking how we determine 15:12:36 markstur: our votes )) 15:12:39 vkmc: zorrilla, no pandas here. 15:12:39 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 vote for high pri 15:12:58 gouthamr: did you ever post the videos you took? 15:13:07 vponomaryov: Just regular democracy popularity contest with no concern for the ramifications? 15:13:08 bswartz: no :( never got around to that 15:13:24 gouthamr: if you don't do it soon then they're not valuable 15:13:38 bswartz: +1 will get them online asap 15:13:46 thanks for the reminder 15:13:52 markstur: I think of high priority as "we should drop everything else to get this done" 15:14:22 bswartz: there are a few specs from ganso. Is he still working on them? 15:14:24 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 xyang1: no, I am not :( 15:14:42 ganso: :( 15:15:26 ganso: why? you have so much personal time ))) 15:15:41 vponomaryov: at the moment I have almost zero time... 15:16:16 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 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 bswartz: +1 15:17:11 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 bswartz: yes 15:18:01 ganso: do you have time even to do that? 15:18:14 or should we find someone else to do that microversion bump? 15:18:26 bswartz: currently I don't, sorry 15:18:30 k 15:19:04 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 somebody please hire ganso to work on manila again! 15:19:11 +1000 15:19:13 bswartz: +100000000000000000 15:19:22 +++++ 15:19:43 ganso: I thought you are still employed 15:19:43 lol 15:19:45 getting back to ensure share 15:19:57 vponomaryov: yes but to do non-manila stuff 15:20:09 lol 15:20:12 vponomaryov: exactly 15:20:16 ok 15:20:18 #topic ensure share 15:20:26 thanks 15:20:29 the main challenge is how this feature scales 15:20:55 it's not reasonable to do background polling of all the shares constantly 15:21:10 and it's not reasonable to update all shares on every share manager restart 15:21:24 however there are times when every share will need to be updated 15:21:48 so the challenge is how to detect those times and invoke the driver logic at only those times 15:22:06 new api 15:22:19 call-on-demand 15:22:20 bswartz: IIRC, last time we discussed this, somebody mentioned flagging shares as "needing repair" or something like that 15:22:22 vponomaryov: that requires an admin to do the right thing 15:22:27 so we just add new CLI command, Manual update 15:22:39 there are 2 problem with that approach: 15:22:45 bswartz: just poke the triger 15:22:47 1) admins forget sometimes 15:23:00 2) once the share manager is up and running it might be too late 15:23:09 ganso: I was thinking of something like a "dirty bit" would be a halfway decent idea for this 15:23:37 dustin++ 15:23:49 bswartz: 1) no one could prevent that from happening 15:23:55 ganso: we can specify the share when we use new cli command 15:23:56 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 I'd rather don't need to depend on the good judgment of admins 15:24:14 vkmc: Agreed 15:24:32 bswartz: admins could write a script to update 15:24:36 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 bswartz: main complexity is the "detect" part 15:25:14 or alternatively we could hook into the existing commands that get run when code upgrades occur (like the db-sync) 15:25:31 admins could write a script to regularly update 15:25:37 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 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 And then having that trigger amount be configurable 15:26:16 yup 15:26:38 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 ok, how we will detect "reconfiguration"? 15:26:59 for the "best effort" cases an admin API/CLI might be fine 15:27:00 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 dustins: you should read https://lwn.net/Articles/191059/ 15:28:41 vponomaryov: we would need to store some piece of state per-share 15:28:49 * dustins adds to reading list 15:29:11 vponomaryov: perhaps a "dirty bit" or perhaps a generation number, or even one of those horrifying alembic hashes 15:29:17 bswartz: easier to have API 15:29:34 I think so 15:30:24 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 bswartz: great 15:30:57 of course, I will add these use cases 15:31:10 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 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 please review this spec and others 15:33:02 I'd like to get some specs merged earlier than the day of the deadline >_< 15:33:19 just some? )) 15:33:27 not all of them? ) 15:33:41 vponomaryov: anything else would be asking too much I'm afraid 15:33:47 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 ipv6, multiple subnets on share nets, race conditions, ... 15:34:15 share groups ) 15:34:20 vponomaryov: ack 15:34:22 tbarron: yes, we have to focus our limited resources 15:34:39 looks like tooz backend is finally making some progress 15:34:58 #topic open discussion 15:35:09 so the agenda was short today 15:35:23 anyone want to discuss something else? 15:35:24 (real momentum for using etcd v3 as well or instead of zookeeeper, with devstack support) 15:35:45 tbarron: who is working on that? 15:36:06 bswartz: lemme chase down the thread, just a minute 15:37:21 bswartz: dims and others, eg jd 15:37:28 http://lists.openstack.org/pipermail/openstack-dev/2017-March/113885.html 15:37:34 tbarron: ty 15:37:52 looks like we're done 15:37:58 thanks all 15:38:04 Thank you. 15:38:05 thanks 15:38:08 #endmeeting