15:00:26 <tbarron> #startmeeting manila
15:00:27 <openstack> Meeting started Thu Nov 15 15:00:26 2018 UTC and is due to finish in 60 minutes.  The chair is tbarron. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:30 <openstack> The meeting name has been set to 'manila'
15:00:41 <tbarron> ping ganso
15:00:45 <tbarron> ping gouthamr
15:00:45 <dustins> \o
15:00:53 <tbarron> yo dustins
15:01:00 <tbarron> ping bswartz
15:01:03 <bswartz> .o/
15:01:04 <tbarron> ping vkmc
15:01:13 <vkmc> o/
15:01:26 <tbarron> ping amito
15:01:53 <tbarron> he's probably doing his friend's bachelor party :)
15:02:40 <tbarron> ping erlon
15:02:42 <tbarron> ping xyang
15:02:56 <tbarron> ping tpsilva
15:03:01 <tbarron> I think that's all ....
15:03:13 <tbarron> Hi all!
15:03:20 <tbarron> Hello from Berlin.
15:03:29 <tbarron> #topic announcements
15:04:05 <tbarron> Congratulations to our own vkmc - contributor award winner: mentor of mentors!
15:04:44 <dustins> \o/
15:05:20 <gouthamr> o/ Congratulations!!
15:05:53 <tbarron> We touched on this last week but shall we cancel next week's meeting?  I don't think we'll have a quorum given the Thanksgiving holiday in the US.
15:06:24 <tbarron> Anyone have a problem with us cancelling?
15:06:42 <tbarron> ok
15:06:58 <bswartz> +1 cancel
15:07:10 <tbarron> #agreed we will skip meeting 22 November, next meeting will be 29 November.
15:07:37 <tbarron> 29 November is also our extended deadline for specs that have already been submitted.
15:07:49 <tbarron> Any other announcements?
15:08:18 * amito sneaks in
15:08:18 <dustins> Yeah, I've got one
15:08:24 <tbarron> :(
15:08:29 <tbarron> :)
15:08:41 <amito> Just got home
15:08:50 <dustins> So I'm taking a position outside of Red Hat and will be stepping away from OpenStack and Manila
15:09:00 <tbarron> amito: wow!  and you're still sober :)
15:09:14 <tbarron> dustins: boooh :)
15:09:26 <bswartz> dustins: :-(
15:09:30 <dustins> I want to thank everyone that I've worked with over the years in Manila from my NetApp days to now, you've all been fantastic and I'm so thankful to have met most of you in person
15:09:34 <amito> dustins: good luck! sad to see you go :(
15:09:56 <tbarron> dustins: seriously, I hope it's a great new situation for you of course.
15:10:13 <dustins> Manila is a fantastic project and we're doing good stuff, and I'll be checking in on occasion to see how awesome :D
15:10:25 <dustins> amito: Thank you!
15:10:37 <dustins> tbarron: I think it is, but I'm biased :P
15:10:40 <tbarron> And I hope to see you back here in a few weeks trying to get your new employer's back end driver merged in manila!
15:10:59 <dustins> tbarron: A little insider help never hurt :D
15:11:15 * dustins is gonna be "the manila guy" at his new employer, he just knows it
15:11:18 <dustins> hahaha
15:11:26 <amito> tbarron: still sober as I literally just got off the taxi and opened the door to my apartment :D
15:11:33 <gouthamr> hehe, don't say goodbye then dustins
15:11:53 <tbarron> Any other announcements?
15:12:01 <dustins> gouthamr: Heh, I guess not :D
15:12:22 <tbarron> #topic Spec Reviews
15:12:49 <tbarron> #link https://review.openstack.org/#/c/607342
15:13:00 <tbarron> This is manage/unmanage share servers ^^^
15:13:11 <tbarron> I see gouthamr did a recent review.
15:13:41 <tbarron> gouthamr: Are you OK with the basic direction on this one and just need your latest points addressed?
15:14:09 <gouthamr> tbarron: was going to respond to your feedback, mostly okay with it
15:14:22 <tbarron> gouthamr: that's what I thought.
15:14:25 <gouthamr> tbarron ganso was going to remove that driver interface
15:14:49 <tbarron> This one seems to be making good progress. And yeah, if we can remove that altogether it will be simpler.
15:15:07 <gouthamr> tbarron: i dunno if he had an afterthought - then i'd like to discuss it a bit more
15:16:08 <tbarron> Well ganso may be on duty here in Berlin, don't see him here, so check with him offline.
15:16:38 <tbarron> I think if he agrees that that driver interface is not needed then we're ready to go except for some wording changes, etc.
15:16:44 * bswartz summons ganso to the meeting
15:17:25 <tbarron> #link https://review.openstack.org/#/c/615947/
15:17:34 <tbarron> This is share networks span subnets.
15:18:08 <tbarron> bswartz: I've seen you busy with CSI PRs this week but have you had a chance to look at the latest version of this?
15:18:38 <tbarron> I'm going to rely on bswartz and gouthamr for expertise on whether the
15:18:50 <bswartz> This is the one that I wanted to see in conjunction with the rest of the design
15:19:04 <tbarron> design for handing multi-address family stuff over and above the
15:19:16 <bswartz> I think it's important to have a complete picture of where we wish to go with share networks
15:19:18 <tbarron> already-approved idea that gouthamr wrote up back in newton
15:19:20 <tbarron> is OK.
15:19:44 <bswartz> I'm neutral on the formatting in 2 specs vs 1 giant spec
15:20:04 <bswartz> And I'm also okay with phasing the delivery
15:20:16 <tbarron> Well we have it in two and that makes the original authorship and provenance clear, so I like that :)
15:20:25 <tbarron> kk
15:20:34 <tbarron> But is the design right?
15:20:47 <gouthamr> the updates on https://review.openstack.org/#/c/615947/2/specs/stein/share-network-multiple-subnet.rst are minor
15:20:59 <bswartz> Authorship isn't really relevant, these documents are team efforts
15:20:59 <gouthamr> i.e, no design changes, some clarifications
15:21:18 * bswartz goes to dig up other spec
15:21:52 <tbarron> They are minor, are they sufficient?
15:22:02 <gouthamr> exactly, i don't think so
15:22:03 <gouthamr> :)
15:22:13 <gouthamr> i think the "multiple subnets per AZ" design notes can be added right there
15:22:15 <bswartz> Wait I can't find the other one
15:22:30 <gouthamr> bswartz: https://review.openstack.org/#/c/391805/
15:23:01 <bswartz> Okay I'm confused now
15:23:22 <bswartz> The one I'm interested in has definite driver impact
15:23:47 <bswartz> Because, for example, dual ipv4/ipv6 for each share server requires a driver interface change
15:24:43 <tbarron> so maybe we have another spec on the way?
15:24:57 <bswartz> Well if we had ganso here we could
15:25:00 <tbarron> Cause what we have IMO doesn't address this issue yet
15:25:01 <bswartz> we could ask*
15:25:29 <bswartz> Yeah I suspect he's postponing that work until T (train?)
15:26:01 <bswartz> In any case, I'm -1 on any changes to share networks until that spec is sorted out
15:26:08 <tbarron> bswartz: I thought the consensus was that the implementaiton could wait till T for that phase but that we wouldn't ...
15:26:13 <tbarron> Yeah, what you just said.
15:26:29 <bswartz> I understand the work may be split across releases
15:26:40 <bswartz> But I still want to have the whole plan written down before we start the work
15:26:41 <tbarron> I'll do some strong-arm^H^H^H^H^H^^H^ clarification in person
15:27:14 <bswartz> My big worry is implementing ourselves into a corner we can't get out of
15:27:25 <tbarron> in a few minutes.  Then if ganso wants this to advance in this cycle he needs to ping bswartz and gouthamr for reviews on that part in the next two weeks
15:27:32 <tbarron> +1
15:27:33 <bswartz> We've done it before with some rather poor decisions around share access
15:28:04 <tbarron> I want to get consensus on the end game, not just on the intermediate steps.
15:28:06 <gouthamr> ack
15:28:31 <tbarron> #link https://review.openstack.org/#/c/609537/
15:28:51 <tbarron> ^^^ Create share from snaps in another pool/back end
15:28:59 <gouthamr> okay, this one i've some problems with
15:29:02 <bswartz> And share-networks themselves have proven to be rather poorly-thought-out from the beginning
15:29:12 <bswartz> So if we're going to fix them finally, let's do it right
15:29:19 <tbarron> bswartz: +1
15:29:20 <gouthamr> bswartz: +1
15:29:50 <tbarron> gouthamr: seems like we don't have a consistent view of *what* problem this spec is trying to solve?
15:30:15 <bswartz> I disagree
15:30:20 <bswartz> The problem here is clear
15:30:26 <bswartz> The solution is less clear
15:30:30 <gouthamr> tbarron: no, i understand the problem - i was speaking to the user ganso's trying to help out
15:31:08 <gouthamr> i took bswartz's stance on this, since the proposal seemed quite complicated..
15:31:11 <tbarron> bswartz: gouthamr k, you guys are OK with the problem statement in the spec then, not just with your own knowledge of a user and her use case?
15:31:38 <bswartz> For others here in the meeting, I'll summarize my issue
15:31:43 <tbarron> I *thought* I understood it but now I'm not so sure.
15:32:34 <bswartz> The problematic use case we face is when a user of Manila decides that creating shares from snapshots should be the primary mode of share creation, rather than the normal share creation process
15:32:54 <bswartz> That subverts the scheduler and causes major problems on the deployer side
15:33:18 <amito> bswartz: I guess that can be a use case for backup software
15:33:42 <amito> bswartz: not sure though
15:34:09 <bswartz> So at a minimum, we need a mechanism for creating shares on different pools than the snapshots
15:34:34 <bswartz> The problem is knowing when to invoke that mechanism
15:34:45 <tbarron> so that the shares get spread rather than packed ...
15:35:08 <bswartz> End users don't really care where their shares get created, as long as creation is fast
15:35:28 <gouthamr> bswartz: Yes, i wanted to propose a two phase solution, please see my last comment on the spec
15:35:35 <bswartz> Deployers care about balance placement (for a variety of reasons) but also care about storage efficiency
15:36:20 <bswartz> Some of the possible cures are worse than the disease, so we need to be careful which cure we pick
15:36:31 <tbarron> twist: end users may care about locality and want to direct to an AZ (that's also in this spec)
15:36:31 <gouthamr> bswartz: for now, i think we should fail the user request unless they are okay with us mirroring/moving some data for them and creating the new share..
15:36:34 <bswartz> gouthamr: ack
15:37:15 <gouthamr> bswartz: (second part of that sentence deserves major abstraction - no sausage making display)
15:37:45 <tbarron> gouthamr: bswartz: so end users don't get to say I want the fastest COWish way, they just get whatever the cloud can give them, iiuc
15:38:01 <bswartz> My intuition is that the scheduler should have primacy
15:38:30 <gouthamr> ++
15:38:43 <bswartz> But the scheduler needs to be able to take into account the costs/benefits the pool choice
15:39:02 <bswartz> *of the pool choice
15:39:34 <gouthamr> amito: the user in question here had the exact workflow - they would recreate all their workloads periodically with snapshots
15:39:50 <gouthamr> amito: you could consider that "backup"
15:39:59 * tbarron moves to a new financial institution
15:40:15 <tbarron> cough
15:40:22 <amito> gouthamr: ok
15:41:00 <gouthamr> tbarron: something definitely PCI compliant this time :D
15:41:30 <bswartz> tbarron: we may need some more high-bandwidth meetings between the stakeholders to reach closure on this spec and the other one
15:41:45 <tbarron> bswartz: gouthamr: so you suggest running copy from snap through the scheduler?
15:41:52 <bswartz> tbarron: absolutely
15:41:59 <tbarron> I agree
15:42:00 <bswartz> I think it was an error to not do that
15:42:12 <bswartz> We did it because cinder did it that way and it seemed pretty harmless at the time
15:42:24 <tbarron> I'd like to see configurable policy for the scheduler then.
15:42:39 <gouthamr> tbarron : yep
15:42:46 <tbarron> spread vs pack, weighting of the candidate pools
15:42:47 <gouthamr> tbarron: no :(
15:42:48 <bswartz> Yeah it should be possible for the admin to tell the scheduler "always choose the same pool" and get the same behavior we have today
15:43:25 <tbarron> configurable by cloud admiin, not the user
15:43:30 <gouthamr> we can discuss this some more - i believe we should do a two-phased implementation
15:43:34 <bswartz> But there need to be alternatives too, and this spec lays the ground work
15:44:09 <tbarron> ok, I'll send out an email today asking for intereseted parties on this one so that anyone
15:44:25 <tbarron> who wants can attend a high-bandwidth synchronous meeting
15:45:17 <tbarron> I'm not confidernt that we'll settle this one by the 29th, but let's try.
15:45:22 <tbarron> confident
15:45:35 <bswartz> I think it's enough time
15:45:48 <tbarron> that's the attitude :)
15:45:53 <bswartz> As long as there isn't some Brazillian holiday that lasts 5 days between now and then
15:46:19 <tbarron> ok, anything else on this one now?
15:46:41 <tbarron> #link https://review.openstack.org/#/c/616123/
15:46:47 <tbarron> ^^ AZ improvments
15:46:53 <tbarron> looks unreviewed still
15:47:09 * bswartz hides
15:47:10 <tbarron> gouthamr: do you want to summarize the basic ideas here?
15:47:17 <gouthamr> tbarron: sure
15:47:23 <bswartz> I still owe a review to gouthamr
15:47:56 <gouthamr> so this one proposes two things to AZs -> allow them to be configured per-backend and allow the administrator to scope share types to specific AZs
15:48:40 <gouthamr> and also covers two tech-debt items -> Allowing users to discover Export Locations per AZ and allowing administrators to "reset" AZs with manila-manage
15:49:25 <gouthamr> so, no overhaul of existing design, just a bunch of #TODOs that I had for a while, written out
15:49:45 <bswartz> gouthamr: under what circumstances would a share span AZs?
15:49:53 <gouthamr> bswartz: only replication
15:49:53 <tbarron> gouthamr: please explain what fulfilling these TODOs gets us :)
15:50:02 <bswartz> Oh right
15:50:14 <bswartz> So the share instances still have exactly 1 AZ
15:50:27 <bswartz> But the share has multiple instances
15:51:05 <gouthamr> tbarron: export-locations discovery is important for us right away because it is a problem right now that users don't know what is the "optimal" export to use (or if something even works to connect to from a specific AZ)
15:51:19 <tbarron> +1
15:52:44 <gouthamr> manila-manage issue was just a usability concern because we don't want the admin conducting a painful 'database surgery' (likes those words)
15:53:01 <gouthamr> if they change their AZs
15:54:58 <tbarron> and configure AZ per back end combined with share types scoped to AZs lets users ask for stroage where it is consumed
15:55:06 <gouthamr> "administrator to scope share types to specific AZs" -> this allows us to present meaningful errors right in the API if a user attempts to use a share type that isn't supported in an AZ
15:55:18 <gouthamr> tbarron: that too
15:55:41 <tbarron> like at a particular edge :)
15:56:17 <tbarron> so I haven't reviewed this one for writing, etc. but I'm on board with the ideas behind it
15:56:20 <gouthamr> ++, edge is the motivation for this spec
15:56:50 <tbarron> bswartz: please check and see if you have any fundamaental issues and if not, let's work to get the spec finished and merged
15:56:55 * gouthamr is happy to tell bswartz about his learning at the Denver PTG wrt how manila's AZ design is pretty awesome
15:57:30 <bswartz> cool
15:57:34 <tbarron> ok, we're pretty much out of time, gouthamr is there anything you want to say to prep reviews of
15:57:41 <gouthamr> yes
15:57:45 <gouthamr> one more spec
15:57:48 <tbarron> #link https://review.openstack.org/#/c/616383/
15:57:59 <gouthamr> ty tbarron
15:58:12 <gouthamr> so this one imo is also tech debt
15:58:44 <gouthamr> after tenant-visible-extra-specs became a thing in liberty/mitaka, we've been wanting to go back and change "shrink" into a capability
15:58:57 <bswartz> I will be reviewing this one too
15:59:05 <tbarron> bswartz: ty
15:59:29 <gouthamr> and storage protocol support will be similar to AZs
15:59:35 <gouthamr> that's all :)
16:00:02 <tbarron> OK, thanks everyone!  Let's review!!
16:00:08 <tbarron> #endmeeting