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