15:01:41 <bswartz> #startmeeting manila
15:01:41 <openstack> Meeting started Thu Nov  3 15:01:41 2016 UTC and is due to finish in 60 minutes.  The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:42 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:44 <openstack> The meeting name has been set to 'manila'
15:01:52 <bswartz> hello all
15:01:53 <cknight> Hi
15:01:54 <ganso> hello
15:01:54 <gouthamr> hello o/
15:01:55 <vponomaryov> Hello
15:01:55 <tbarron> hi
15:02:03 <xyang2> hi
15:02:11 <dustins> \o
15:02:35 <toabctl> hi
15:02:45 <bswartz> hope you've all recovered from travel last week (those of you who were in BCN)
15:03:15 <markstur> hi
15:03:19 * bswartz is still fighting off a virus he got on the plane
15:03:27 <bswartz> #agenda https://wiki.openstack.org/wiki/Manila/Meetings
15:04:01 <bswartz> #topic announcements
15:04:19 <bswartz> welcome gouthamr to the manila core reviewer team!
15:04:27 <cknight> bswartz: +1
15:04:35 <ganso> gouthamr: congrats!
15:04:35 <tbarron> bswartz: +1
15:04:42 <toabctl> congrats!
15:04:47 <dustins> \o/
15:04:48 <bswartz> gouthamr: I haven't actually added you to the gerrit group, we need to talk about official procedures first
15:04:51 <xyang2> gouthamr: congrats!
15:05:17 <bswartz> mostly our agreed to rule about people from the same company not workflowing patches
15:05:20 <markstur> Congrats!
15:05:20 <gouthamr> hey, thanks everyone. I'll try doing better than what i'm doing :)
15:05:48 <bswartz> also just a reminder where we are in the release
15:05:48 <vponomaryov> gouthamr: just try? ))
15:06:00 <bswartz> #link https://releases.openstack.org/ocata/schedule.html
15:06:16 <bswartz> This is R-16, and milestone 1 is 2 weeks away
15:06:19 <xyang2> bswartz: so we have one deadline for specs instead of two?
15:06:32 <xyang2> bswartz: I thought you proposed two deadlines in the spec
15:06:50 <xyang2> but Ocata is short, so makes sense to combine them
15:07:07 <bswartz> xyang2: the spec freeze on the schedule is the "low priority" spec freeze, which is the only thing that matters for people who don't regularly attend these meetings
15:07:40 <bswartz> high priority specs will have more time, but those we will agree on and deal with as a core team
15:08:11 <xyang2> bswartz: Ocata-2?  that was on the spec
15:08:47 <bswartz> According the spec deadline spec, if we decide a spec is high priority it has until ocata-2 to merge (Dec 15)
15:08:56 <xyang2> bswartz: maybe confusing though we have a hidden spec deadline for high priority ones.  why not publish it
15:09:38 <bswartz> I didn't publish both because I didn't want to crowd the community calendar with manila dates and I didn't want to create confusion about low/high priority stuff for people who don't already know
15:10:13 <vponomaryov> bswartz: I would like to see calendar event for such major things
15:10:47 <bswartz> I can update the calendar again -- I just worry that all the project-specific stuff will get out of hand
15:10:57 <bswartz> there's already 4 deadlines the week for R-10
15:11:17 <bswartz> anyways, let's move on to actually discussing specs
15:11:30 <bswartz> #action bswartz will update community calendar with BOTH spec deadline dates
15:11:44 <bswartz> #topic Spec review & prioritization
15:12:32 <bswartz> #link https://etherpad.openstack.org/p/manila-ocata-spec-review-focus
15:12:43 <bswartz> so there are 2 decisions to make
15:13:11 <bswartz> for specs that require review attention from the whole core team, we will put them on this etherpad
15:13:31 <bswartz> we will expect the whole core team to review everyone on that list
15:14:12 <bswartz> the other decision is high priority specs, which will be designated as such in the specs repo
15:14:35 <bswartz> I'd like to go through the list of specs and get people's opinions right now
15:14:47 <bswartz> #topic manila-ipv6
15:15:22 <vponomaryov> how opinion should look like?
15:15:23 <bswartz> I don't think this needs any special treatment
15:15:44 <vponomaryov> 3 - high priority? 2 - middle? 1 - low?
15:15:53 <bswartz> if you feel a spec needs review focus (from the whole team) or should be high priority, just mention it
15:16:18 <vponomaryov> also, I need to mention that we do not have spec for high priority feature - use messages
15:16:26 <tbarron> we agreed to poll driver owners, if any drivers can't support then maybe that has to get fixed first
15:16:27 <vponomaryov> user* messages
15:16:27 <bswartz> IMO this feels medium priority and just needs buy in from drivers authors mostly
15:16:47 <vponomaryov> I would say it is low
15:16:47 <markstur> seems low-to-mid except the part about whether some drivers cant do it
15:16:49 <ganso> I personally think ipv6 needs review focus because it affects current state of drivers
15:16:52 <bswartz> vponomaryov: more than one spec is missing
15:17:14 <bswartz> I haven't written the race condition spec yet either
15:17:26 <markstur> vponomaryov: save some for next week
15:17:29 <xyang2> bswartz: any estimate on when you could submit a draft
15:17:29 <bswartz> so we should expect new specs as we go
15:17:48 <bswartz> we can only review stuff that exists however
15:18:09 <bswartz> xyang2: it's high on my personal list
15:18:26 <xyang2> bswartz: ok.  we could help with implementation as you are looking for volunteers, but want to know what is the proposal:)
15:18:28 <bswartz> however higher priority was to review existing specs for today's discussion
15:18:38 <markstur> unfortunately that means our "cut-line" could change and the lowest high pri might get bumped down
15:19:14 <bswartz> markstur: that's okay -- remember the cut line isn't a commit line, it's literally a cut line
15:20:02 <bswartz> we will ideally merge a few more specs than we actually get implemented
15:20:08 <markstur> yeah. maybe I shouldn't have said "unfortunately".
15:20:30 <bswartz> okay I heard one vote to add this one to review focus etherpad
15:20:57 <bswartz> It's small enough that I agree with this-- everyone should at least look at ipv6 spec
15:21:22 <bswartz> #topic  add-db-manage-purge
15:21:48 <bswartz> this feels low priority to me, but also pretty low risk
15:22:07 <bswartz> any concerns about this one that would suggest we need to review it in more detail?
15:22:16 <cknight> bswartz: +1, it's gonna be increasingly important in large deployments
15:22:18 <tbarron> doesn't seem urgent, low risk if it's just something all projects do it essentially the same way
15:22:38 <bswartz> tbarron: you know of any examples we should be emulating?
15:22:48 <tbarron> bswartz: haven't checked
15:22:54 <cknight> bswartz: yes, Cinder has this, and the spec mirrors that one
15:23:03 <tbarron> cknight: that's what I was hoping
15:23:10 <bswartz> k that's my main concern -- this is an area where we should attempt to conform with others and not be different
15:23:12 <markstur> storage companies prefer DBs that grow forever
15:23:23 <bswartz> markstur: +1
15:23:31 <bswartz> #topic create-share-from-snapshot-extra-spec
15:23:34 <tbarron> well, i prefer a snappy DB
15:23:52 <markstur> tbarron: patience
15:24:04 <bswartz> I'd like everyone to review this one I think
15:24:07 <tbarron> markstur: no such thing
15:24:08 <cknight> bswartz: this one is a prerequisite for the other snapshot specs (revert, mount)
15:24:09 <bswartz> it's been discussed a lot already
15:24:14 <ganso> bswartz: +1
15:24:22 <bswartz> and I doubt there are any issues, but we should make sure
15:24:27 <markstur> hi pri, I'd think
15:24:44 <cknight> bswartz: and the code is nearly ready as well
15:24:45 <bswartz> markstur: you'd want to hold up the release for this one feature?
15:24:51 <markstur> maybe medium pri
15:25:12 <bswartz> It seems low priority to me -- but it's more or less done, let's just finish it and move on
15:25:29 <bswartz> the fact that stuff depends on it may boost the priority
15:25:44 * bswartz adds it to etherpad
15:25:45 <tbarron> bswartz: does 'hi pri' actually mean 'hold the release'?  I thought it just means 'gets most resources'
15:25:59 <markstur> we can't actually hold the release
15:26:04 <bswartz> tbarron: not literally -- we never hold the release for anything
15:26:10 <tbarron> bswartz: +1
15:26:25 * tbarron isn't used to bswartz being hyperbolic
15:26:37 <ganso> I think it means it is a highly desired to be implemented feature
15:26:52 <ganso> at least in ocata release
15:27:04 <bswartz> the point of high priority is that we'd be willing to drop everything else not high priority to get it done, if it came to that
15:27:28 <vponomaryov> bswartz; then why etherpad does not contain priorities?
15:27:42 <bswartz> vponomaryov:  high priority specs will go into git
15:27:53 <bswartz> etherpad is for tracking review focus list
15:28:14 <bswartz> I know it's confusing, but I think this system will work
15:28:18 <vponomaryov> bswartz: it would be more obvious to write it in one single place
15:28:48 <bswartz> obviousness is non-goal of the new spec deadline process :-/
15:29:26 <markstur> we will weed out those that are easily confused
15:29:43 <bswartz> the goal is to say no to things earlier and to optimize our limited review time
15:29:53 <bswartz> #topic support-quota-usage-in-detail
15:30:01 <bswartz> This spec worries me
15:30:14 <bswartz> it adds a feature to an already creaky quota system
15:30:22 <bswartz> without trying to fix the problems with the existing system
15:30:41 <bswartz> tbarron led a session in austin about quotas, but no progress has been made on solving the issues
15:30:48 <markstur> and this deadline thing will get us to do more spec reviews and close them unlike last time
15:31:23 <bswartz> I'd need to be convinced that the problem this spec solves is more important than fixing the other problems we already know about
15:31:25 <cknight> bswartz: +1, quotas need an overhaul
15:31:51 <tbarron> bswartz: this isn't a big change and I wouldn't have a problem with it if they basically just copy the same thing that is done in nova today
15:32:09 <bswartz> tbarron: is this a copy/paste of work done in nova?
15:32:14 <tbarron> bswartz: but I don't think the spec is ready yet on its own terms
15:32:27 <vponomaryov> tbarron: but still, it is review-resource consuming and, hence, very low priority
15:32:40 <bswartz> okay no need to boost this spec
15:32:40 <tbarron> bswartz: my issue is that it's not yet a copy/paste, and the problem statement isn't yet right
15:32:49 <bswartz> #topic ocata-migration-improvements
15:32:59 <tbarron> vponomaryov: no argument from me
15:33:36 <bswartz> I like continually improving the migration feature
15:33:36 * vponomaryov assesses ocata-migration-improvements as medium
15:33:47 <gouthamr> yes, it doesn't seem too heavy to me
15:33:55 <cknight> bswartz: makes sense to continue incremental progress on migration
15:34:03 <bswartz> my concern is that ganso might be overcommiting his limited development time in ocata
15:34:04 <tbarron> +1 for continuous improvement on migration
15:34:19 <ganso> those are not big changes
15:34:28 <cknight> bswartz: you think the spec should be pared down?
15:34:29 <ganso> the most relevant one is transitioning to non-experimental
15:34:30 <bswartz> ganso: are you going to be able to write the code for all your specs if we merge them all?
15:34:46 <ganso> I have only 2 specs which are targeted for ocata
15:34:50 <vponomaryov> now we have one new alias in our community? )) #overcommiter in adition to #shameless ? ))
15:34:53 <bswartz> mostly I want to figure out what ganso's personal priorities are for coding this stuff
15:34:57 <tbarron> ganso: i'm concerned about non-experimental at this stage though
15:35:04 <markstur> I'd think migration continuous improvement would be OK after o1.  So that's either HI or it's bug fixes only
15:35:14 <ganso> vponomaryov: what's up with shameless?
15:35:19 <bswartz> does this need review focus?
15:35:27 <tbarron> yes
15:35:31 <cknight> yes
15:35:38 <ganso> bswartz: only data jobs table and that migration improvements
15:35:40 <bswartz> it's a core feature -- I feel like we all should at least take a look here
15:35:47 * bswartz adds it to etheroad
15:35:52 <gouthamr> #shameless, heh
15:36:02 <tbarron> the experimental/non-experimental decision (for any feature, not just migration) means we need review focus
15:36:05 <vponomaryov> ganso: ask gouthamr =)
15:36:11 <bswartz> #topic data-service-jobs-table
15:36:36 <bswartz> I really like this feature
15:36:43 * vponomaryov assesses data-service-jobs-table as medium
15:36:49 <bswartz> it feels like a large change for a small release though
15:37:11 <bswartz> ganso how much code do you think this will require?
15:37:17 <vponomaryov> it should be done before making migration API non-experimental
15:37:31 <markstur> hmmm.  something like this it'd be great to merge it early in case it has issues
15:37:31 <ganso> bswartz: depends on whether we want to address the Data Service being HA in Ocata
15:37:35 * bswartz groans
15:37:39 <markstur> which makes me want to say it's hi priority but requires the low-pri deadline
15:37:43 <cknight> bswartz: agree, is it feasible for this to fit in Ocata?
15:37:51 <ganso> bswartz: my spec does not include the produce/consume proposal we discussed in BCN
15:38:12 <ganso> bswartz: so the table itself would be "part 1"
15:38:14 <bswartz> For this one I feel like we should definitely get the review done and start testing the implementation
15:38:17 <ganso> bswartz: as proposed in the spec
15:38:27 <cknight> bswartz: perhaps we should review the spec now even though the lead time is long enough to ship in Pike
15:38:28 <bswartz> however the likelihood of actually landing still seems marginal
15:38:35 <gouthamr> cknight: +1
15:38:44 <tbarron> cknight: +1
15:38:57 <bswartz> okay so review focus yes? high priority no?
15:39:26 <xyang2> ganso: is part 1 only adding the table but not using it?
15:39:46 <ganso> xyang2: it uses the table, but it does not implement a recovery mechanism for allowing the Data Service to be Active-Active
15:40:06 <cknight> bswartz: +1
15:40:12 <bswartz> ganso: you're thinking about a phased implementation?
15:40:16 <ganso> bswartz: yes
15:40:21 <bswartz> that seems smart
15:40:30 <bswartz> added to etherpad
15:40:34 <ganso> bswartz: this will need to evolve along with the Active-Active implementation requirements for manila
15:40:40 <bswartz> #topic add-share-type-filter-to-get-pools
15:40:41 <ganso> bswartz: along with the Workers table we discussed in BCN
15:41:14 <bswartz> I read this spec and I wondered if it solves a real problem
15:41:15 <tbarron> I haven't understood this one yet
15:41:19 <ganso> bswartz: the spec at this moment only proposes adding a table to track jobs, not any advanced mechanisms to restart them
15:41:20 <markstur> low priority because if it gets in o1 great, but if it is later it should slide to the next release.   ???
15:41:20 <markstur> although it seems like if it can go in small pieces we want to keep progressing
15:41:22 <bswartz> how are people using the get pools API?
15:41:52 <bswartz> it's another thing that seems low risk and has possible utility
15:41:56 <cknight> bswartz: not sure what the use case is
15:42:00 <bswartz> however I don't see a reason to elevate it
15:42:06 <cknight> bswartz: +1
15:42:11 <tbarron> is the info it filters on already available so one could filter at another layer?
15:42:27 <ganso> IRC is lagging a lot here... I get 40 seconds of silence then 15 messages at once :(
15:42:29 <cknight> tbarron: maybe, but the scheduler is the right place to do it
15:42:35 <vponomaryov> it is low priority as desired result can be achieved by other means
15:42:36 <bswartz> cknight: if we can't figure out the use case then that's a -1 on the spec
15:42:48 <markstur> certainly wouldn't hold the release for it
15:42:56 <bswartz> however that's probably fixable and then this spec could go forward
15:43:16 <bswartz> ganso: slow internets are slow
15:43:27 <bswartz> maybe try a different server
15:43:38 <ganso> bswartz: was wondering if it was only me
15:43:49 <tbarron> yeah, I just need to understand the use case better, otherwise seems straightforward enough
15:43:57 <bswartz> no problems here, and no evidence of a netsplit
15:44:12 <bswartz> #topic manila-share-revert-to-snapshot
15:44:23 <cknight> This spec already merged in Newton, I've just moved it to Ocata with very minor edits.
15:44:50 <tbarron> seems it could be medium and still get done
15:44:56 <bswartz> yeah this seems like a slam dunk -- does it need review focus though?
15:44:58 <vponomaryov> it should land in Ocata so driver maintainers could start implementing it, medium
15:45:09 <ganso> I would like to see that one in Ocata :)
15:45:25 <cknight> There was concern about the inferior Cinder version not matching ours, but that shouldn't hold us up IMO.
15:45:31 <tbarron> i would like review focus b/c there is a review in cinder by players on both projects that is inconsistent with this oone
15:45:42 <cknight> tbarron: Thanks for pushing for consistency!
15:46:11 <tbarron> cknight: i want to make sure everyone on manila is aware of the issues and if there are good args to do it differently that they are surfaced
15:46:21 <cknight> tbarron: +1
15:46:24 <tbarron> cknight: I think the cinder spec should change myself though
15:46:24 <gouthamr> tbarron: +1
15:46:29 <markstur> sounds like needs focus
15:46:46 <bswartz> okay I'll add to etherpad -- it should be an easy review for most because we've discussed it at length already
15:46:49 <ganso> tbarron: +1 cknight's spec looks fine to me
15:47:02 <bswartz> #topic scenario-tests
15:47:13 <tbarron> hi priok, review focus
15:47:18 <tbarron> prio
15:47:21 <ganso> high priority
15:47:22 <gouthamr> +1 hi
15:47:24 <markstur> hi
15:47:36 <bswartz> I agree on high priority
15:47:47 <tbarron> and these can be added throughout the release cycle, right?
15:47:47 <bswartz> it's a QA activity though -- do we really need everyone to review it?
15:47:51 <vponomaryov> some part of this spec requires additional decisions that we haven't come to in Barcelona
15:48:02 <gouthamr> however, i don't see who's the main implementer in this case
15:48:03 <tbarron> bswartz: do we have a QA subteam?
15:48:22 <tbarron> bswartz: I think we should all learn to think end-to-end
15:48:24 <bswartz> tbarron: we have people more focused on QA and people less focused
15:48:25 <vponomaryov> tbarron, /me ?
15:48:42 <tbarron> vponomaryov: yeah, that's my point, we need to clone you
15:49:02 <vponomaryov> tbarron: why do you have thsi world so much? ))
15:49:24 <bswartz> vponomaryov: since you wrote this, do you feel you want the whole team to weigh in before this merges? or would two +2s be enough?
15:49:46 <vponomaryov> bswartz: no, no need to heavy review
15:50:02 <tbarron> i guess i'm not arguing for team review focus, rather for team implementations :)
15:50:03 <gouthamr> vponomaryov: you're talking about manage share, anything besides that?
15:50:14 <bswartz> any disagreement about leaving this off the etherpad?
15:50:21 <vponomaryov> gouthamr: 2 issues with manage share, yes
15:50:44 <bswartz> vponomaryov: please make sure we do reach closure on any dependencies by adding weekly meeting agenda items or ML posts
15:51:14 <bswartz> okay I added it to high priority list
15:51:34 <bswartz> #topic mountable_snapshots
15:51:39 <markstur> (i see that looks like I just said hello, but hi is lazy for high -- not joking around this time)
15:51:39 <markstur> i was assuming vponomaryov will make it work and we all can then make it keep getting better
15:52:17 <gouthamr> mountable snapshots has some code ready, but does not conform to the snapshot semantics that create_share_from_snapshot_support / revet_tosnapshot have
15:52:25 <gouthamr> so, i would get those developers in sync :P
15:52:42 <bswartz> gouthamr: this question is about the spec
15:52:43 <gouthamr> then we can actually get this done in ocata..
15:52:45 <ganso> gouthamr: tpsilva is updating his code and spec
15:52:45 <vponomaryov> gouthamr: not sure we really need this feature in Ocata
15:52:57 <bswartz> I say not high priority
15:53:03 <ganso> gouthamr: it should be done in Ocata, it is almost ready downstream
15:53:15 <bswartz> but review focus this as it has wide-ranging affects similar to other snapshot changes
15:53:34 <gouthamr> vponomaryov bswartz +1 not a high priority, but if the code's ready and working, we can bag these as "alternate snapshot semantics, done right"
15:53:42 <tpsilva> it's almost ready
15:53:56 <gouthamr> oh hey tpsilva
15:54:17 <tpsilva> gouthamr: :)
15:54:23 <bswartz> don't we want everyone to take one last look at the spec though so there aren't disagreements later?
15:55:20 * gouthamr experiencing same internet issues as ganso
15:55:24 <bswartz> errr
15:55:40 <bswartz> okay I'm not hearing opposition so I'll add this to etherpad and move on
15:55:57 * bswartz notes that lack of opposition could be due to IRC issues
15:56:01 <gouthamr> yes
15:56:13 <ganso> bswartz: yes should be same priority as revert-to-snapshot, they should be in sync
15:56:19 <bswartz> #topic share-network-multiple-subnets
15:56:40 <ganso> high priority
15:56:46 <bswartz> this is something that needs doing if we ever want replication to work with share servers
15:57:00 <vponomaryov> ganso: why? I would say it can wait till Pike
15:57:20 <gouthamr> okay, this is a port from newton... the work itself seems easy for me to do.. and i am committed to it
15:57:21 <ganso> vponomaryov: because we could experiment with it before transitioning Replication out of experimental API status
15:57:34 <ganso> it is highly desired to finish replication API
15:57:37 <bswartz> I'm a big fan of this feature but it doesn't feel absolutely essential
15:57:40 <gouthamr> i'm okay with you guys punting it to pike, but i will be pushing code either ways.
15:58:18 <bswartz> okay since we're out of time
15:58:37 <bswartz> we made good progress today, but there's some more specs to cover
15:58:45 <bswartz> do we need a special meeting to wrap up the list?
15:58:54 <bswartz> or can it wait until next week?
15:59:38 <ganso> all of the remaining ones I would suggest not targetting Ocata
15:59:44 <bswartz> can I propose another meeting this time tomorrow?
15:59:56 <vponomaryov> ganso: manila-share-groups should be in Ocatqa
16:00:03 <cknight> ganso: +1
16:00:18 <cknight> bswartz: none of the remaining ones are likely to make Ocata
16:00:27 <vponomaryov> cknight: share groups?
16:00:49 <bswartz> okay guys let's move to the #openstack-manila channel and keep talking
16:00:56 <bswartz> we need to vacate this room
16:01:01 <vponomaryov> share groups is everyone-influencing feature
16:01:01 <bswartz> thanks all
16:01:05 <bswartz> #endmeeting