15:01:38 <tbarron> #startmeeting manila
15:01:38 <openstack> Meeting started Thu Nov 29 15:01:38 2018 UTC and is due to finish in 60 minutes.  The chair is tbarron. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:39 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:42 <openstack> The meeting name has been set to 'manila'
15:01:55 <tbarron> ping gouthamr
15:01:59 <xyang> hi
15:02:00 <tbarron> ping zhongjun
15:02:00 <ganso> hello
15:02:06 <vkmc> O/
15:02:08 <tbarron> ping markstur
15:02:16 <tbarron> ping bswartz
15:02:23 <tbarron> but bswartz is travelling today
15:02:29 <tbarron> ping erlon
15:02:33 <tbarron> ping tpsilva
15:02:38 <tbarron> ping amito
15:02:46 <tbarron> but amito is in another meeting
15:03:00 <tbarron> that's the ping list minus the folks I already sss here
15:03:10 <tbarron> Hi xyang ganso vkmc
15:03:15 <tbarron> let's wait a bit
15:03:35 <xyang> tbarron: I have joined
15:03:54 <xyang> can you see my msg?
15:03:58 <tbarron> the end of daylight savings time in our part of the world may be throwing people off a bit.
15:04:07 <tbarron> xyang: yes!  greetings!
15:04:13 <xyang> Hi!
15:04:47 <xyang> I got logged out automatically a lot  these days.  Just want to make sure:)
15:05:12 <gouthamr> o/
15:06:26 <tbarron> OK, let's get started
15:06:36 <tbarron> #topic Announcements
15:07:05 <tbarron> Ben is traveling today but has voted on the specs so we can still cover that today, a little later
15:07:25 <tbarron> Today is out (extended) spec deadline.
15:07:47 <tbarron> Anyone have any other announcments?
15:08:22 <tbarron> Oh yeah, Dustin has moved on so if you are interested in the bug czar role let me know :)
15:08:39 <tbarron> #topic Berlin Summit Summary
15:08:58 <tbarron> vkmc: amito ganso and I were at the Berlin Summit
15:09:36 <tbarron> Overall the shift from traditional OpenStack to OpenInfrastructure is well underway.
15:10:00 <tbarron> The foundation is renaming everythihng to Open Infrastructure
15:10:34 <tbarron> Lot's of emphasis on bare metal, container orchestrator integration, the distributed edge.
15:10:43 <tbarron> Not nova VM centric anymore.
15:11:18 <tbarron> *Our* message is that manila has always been loosely coupled with nova and other OpenStack components.
15:11:34 <tbarron> We serve up storage over the network rather than via a hypervisor.
15:11:49 <tbarron> This may have been a weakness in traditional OpenStack but
15:12:04 <tbarron> it is a strength in the new Open Infra world order :)
15:13:06 <tbarron> Also: you can now have open infra end to end with production quality deployment of purely software defined manila back ends, even with NFS instead of just CephFS native
15:13:25 <tbarron> our *work* is focused on making manila easier to consume
15:13:40 <tbarron> * openstack client and sdk support
15:13:52 <tbarron> * CSI support for container orchestrators
15:14:07 <tbarron> * Horizon catch-up with our newer API features
15:14:25 <tbarron> * AZ and capabilty discovery, scheduler use of these
15:14:55 <tbarron> There were seven summit sessions explicitly tagged with "manila"
15:15:11 <tbarron> #link https://www.openstack.org/summit/berlin-2018/summit-schedule/global-search?t=manila
15:15:30 <tbarron> And on Monday we had Ceph day, with a manila preso:
15:15:45 <tbarron> https://ceph.com/cephdays/ceph-day-berlin/
15:16:07 <tbarron> #link https://www.slideshare.net/Inktank_Ceph/ceph-day-berlin-practical-cephfs-and-nfs-using-openstack-manila
15:16:28 <tbarron> project update slies are posted
15:16:42 <tbarron> #link https://docs.google.com/presentation/d/1txafXiYBA4pusgSVOmAAqOOr5BsigAqEk2NvqG9_tKw/edit#slide=id.g45dbfa8aec_0_116
15:16:58 <tbarron> vkmc ran a great onboarding session
15:17:14 <tbarron> #link https://www.slideshare.net/TomBarron/manila-project-onboarding-openstackberlinsummit2018-124161981
15:17:54 <tbarron> CERN gave a great preso on how they are using manila with container orchestrators
15:18:09 <tbarron> #link https://www.openstack.org/assets/presentation-media/presentation4.pdf
15:18:11 <ganso> tbarron: You need permission. Your request for access has been sent.
15:18:21 <ganso> tbarron: ^ for the project update slides
15:18:40 <tbarron> ganso: ok, i'll open it up and grant perm right after
15:18:45 <ganso> tbarron: thanks
15:18:45 <tbarron> ganso: thanks
15:19:21 <tbarron> At the sig-k8s session there was a topic on manila CSI driver and
15:19:43 <tbarron> Robert Vasek from CERN and some of us presented a plan for
15:19:50 <tbarron> manila CSI going forwards
15:20:07 <tbarron> It's summarized in a followup email to openstack-discuss
15:20:31 <tbarron> #link http://lists.openstack.org/pipermail/openstack-dev/2018-November/136557.html
15:21:06 <tbarron> Overall, I think it was a successful summit and manila is well positioned going forwards.
15:21:25 <tbarron> Anyone else have comments?  Thoughts? auestios? w.r.t. summit?
15:21:49 <tbarron> oh yeah, next summit combined with design sessions (what was PTG) in Denver.
15:21:59 <tbarron> Then after that somewhere in mainland china.
15:22:01 <tbarron> :)
15:22:22 <gouthamr> No, this was a great summary for those of us who couldn't attend. Thanks Tom!
15:22:55 <tbarron> #topic Specs
15:23:24 <tbarron> This is the deadline.  We've had quite a bit of review activity in the last couple of weeks.
15:23:46 <tbarron> And I think we know what we want to merge.
15:23:54 <tbarron> Let's go through the specs.
15:24:07 <tbarron> * Manage/Unmanage Share Servers
15:24:21 <tbarron> #link https://review.openstack.org/#/c/607342
15:24:53 <tbarron> gouthamr: you have a -1 but no fundamental objectiion, right?
15:25:29 <gouthamr> tbarron: yeah, no.. we can resolve this issue in code review
15:26:02 <tbarron> OK
15:26:12 <gouthamr> i know ganso's written some code with his driver that works with his existing proposal - but still doesn't make sense with the known workflow of share servers in my head
15:26:33 <tbarron> ganso: please ping me after you and gouthamr get rid of his -1 and he puts his +2 on there :)
15:26:47 <tbarron> he can point to issues that need to be resolved in code review
15:26:57 <ganso> gouthamr: perhaps we should schedule another meeting to go over this again
15:27:03 <tbarron> Ben has already +2-ed this one a couple times.
15:27:24 <tbarron> ganso: gouthamr - resolve today and push remaining stuf to code review!
15:27:43 <tbarron> Anyone else have any objections to merging this spec?
15:28:07 <tbarron> ok,
15:28:20 <tbarron> * share servers span subnets *
15:29:05 <tbarron> We were ready to move ahead on phase one of this but needed a design for phase two
15:29:13 <ganso> #link https://review.openstack.org/#/c/619925
15:29:17 <ganso> design of phase two ^
15:29:20 <tbarron> phase two will add support for multi-address servers
15:29:24 <gouthamr> +2 - haven't looked at multiple subnets per AZ too deeply
15:29:47 <gouthamr> but we don't need that to merge right away, correct?
15:30:11 <tbarron> Ben & ganso & I thhink that 619925 is good enough to defer to Train and work on details then
15:30:12 <gouthamr> multi-address = multiple subnets
15:30:41 <tbarron> that is, we're convinced that we won't paint ourselves into a corner doing phase 1 and approving the specs for phase 1
15:30:44 <tbarron> namely
15:30:57 <tbarron> #link https://review.openstack.org/#/c/391805/
15:31:02 <tbarron> and
15:31:13 <tbarron> #link https://review.openstack.org/#/c/615947/
15:31:50 <tbarron> So -- anyone object to approving these two specs and taking up 619925 in Train?
15:33:11 <tbarron> OK, I hear no objection so we'll merge 391805 and 615947  -- note that 391805 was already approved in Newton :)
15:33:17 <tbarron> next
15:33:25 <gouthamr> nope
15:33:39 <tbarron> * Create share from snapshots in another pool or back end
15:33:50 <tbarron> We had lots of meetings on this one.
15:34:04 <tbarron> ganso has done a great job of framing a real problem and of
15:34:24 <tbarron> bringing several worthwhile ideas to the fore about how
15:34:31 <tbarron> we might address the problem.
15:34:53 <tbarron> But at this point we don't have any consensus on the right solution.
15:35:22 <tbarron> I don't even have a clear consenus between tbarron1 and tbarron2 on this!
15:35:34 <tbarron> similarl sentiments expressed by bswartz.
15:35:49 <tbarron> So we decided that this one will not merge today.
15:36:38 <tbarron> If ganso comes up with a compelling solution he can bring it to everyone's attention as soon as he has it -- no need to wait till Train to talk about it.
15:37:13 <tbarron> Indeed, there's no reason to stop thinking/working on stuff just because we don't make a cycle deadline!
15:37:30 <tbarron> Anything else on this one today?
15:38:21 <tbarron> ganso: you are going to have lots of work with the other approved specs anyways :)
15:38:27 <tbarron> ok next
15:38:30 <ganso> tbarron: yup =)
15:38:38 <tbarron> * Storage AZ improvements
15:38:51 <tbarron> #link https://review.openstack.org/#/c/616123/
15:39:11 <tbarron> ganso you have a -1 on this
15:39:20 <bswartz> Did I forget to +2 anything that's ready?
15:39:24 <ganso> tbarron: yes
15:39:26 <tbarron> but iiuc it's not a fundamental objection
15:40:05 <ganso> bswartz: manage/unmanage (https://review.openstack.org/#/c/607342), but we acknowledge your past +2
15:40:05 <tbarron> ganso: gouthamr - can you come to enough agreement on the overall spec that we can approve it today and
15:40:26 <ganso> tbarron: unfortunately I couldn't be at the meeting where you discussed this, and I still don't understand why this has changed
15:40:41 <tbarron> write in the review comments any issue that needs to be pushed to the code reviews?
15:41:05 <tbarron> bswartz: we have some -1s to get out of the way then you and I have to re-apply our +2s :)
15:41:15 <tbarron> bswartz: nice surprise that you are here!
15:41:15 <gouthamr> tbarron: no this one is a design issue that ganso's bringing up
15:41:32 <tbarron> gouthamr: ganso: ok, let's talk this through then.
15:42:18 <tbarron> ganso: are you saying we should show users export locations that are not active and that therefore won't actually work?
15:42:37 <bswartz> As long as the changes are not significant you can consider my +2s to be sticky
15:42:39 <gouthamr> ganso would prefer if we left all export locations in the share export locations API and added another indication to call out "readonly" nature (for readable replication)
15:42:50 <bswartz> I'm just making sure I didn't forget anyting
15:42:56 <ganso> tbarron: they work, but they are read-only. Currently we show all of them and we don't tell the user 2 things: 1) their AZ and 2) that they are read-only
15:43:18 <ganso> tbarron: the original proposal was going to tag the AZ, but continue to show all of them without distinction
15:43:42 <ganso> tbarron: the current proposal is changed to don't show the full list anymore, and don't show their AZ anymore (which IMO was valuable)
15:43:59 <ganso> tbarron: I believe that this is a UI problem
15:44:24 <ganso> tbarron: we are failing to communicate to users which export locations are writable and which are read-only
15:44:25 <gouthamr> ganso: you're not really losing the information - as the spec says, the share export locations API is meant to give you export locations of the "active" share
15:44:30 <tbarron> ganso: let's focus on API, it has to work without making people use UI instead
15:45:00 <ganso> tbarron: by UI I mean any means of interacting with the user, not just CLI or GUI
15:45:36 <ganso> tbarron: as a user I would be confused if I list the export locations and I don't them
15:45:58 <ganso> tbarron: when I invoked that API I want to see export locations, regardless if they are replica ones or not
15:46:17 <gouthamr> umm.. why?
15:46:30 <ganso> tbarron: it feels to me that something is wrong if the API is omitting information
15:46:32 <ganso> gouthamr: ^
15:46:37 <gouthamr> i mean, replica information is already hidden when you invoke the share APIs
15:46:42 <tbarron> ganso: I thnk it's a bug to provide an export location that won't work (for r/w when the share is writable)
15:47:11 <ganso> gouthamr: if I have a replica I have to call another API to find out if the export locations are there
15:47:39 <tbarron> and the proposal is to make that info available under a separate api so that no one will think it is usable
15:47:50 <ganso> gouthamr: I would need to call 3 APIs to find my export locations: export locations, share replica list, and then share-replica-export-locations
15:48:09 <ganso> gouthamr: the replica export locations are not hidden today
15:48:19 <gouthamr> ganso: yes, think of the extra information that is required to provide the distinction - replica_id, az, replica_state
15:48:29 <ganso> tbarron: they are usable, but read-only. That is different than unusable
15:48:54 <tbarron> ganso: a writable share has an export location that isn't writable
15:49:11 <gouthamr> ganso: clients would have to be implementing conditionals to extract the correct share export locations if we provided all these
15:49:24 <gouthamr> tbarron: i think he means "accessible"
15:49:37 <ganso> tbarron: yes, but not all exports need to be writable. My latest suggestion was to separate those under another field in the view
15:49:45 <ganso> tbarron: so no conditionals would need to be written
15:50:06 <tbarron> ok, time check
15:50:09 <ganso> tbarron: if you want the export locations, look at the "export_locations" field, if you want read-only export locations, look at "read_only_export_locations_field
15:50:30 <ganso> tbarron: no need to write a bunch of code and checks to separate that information
15:50:32 <tbarron> gouthamr: bswartz what do you think about this ^^?
15:50:35 <ganso> tbarron: and call several APIs
15:51:16 <bswartz> Feel like a significant API change
15:51:21 <bswartz> I'd need to think about it
15:51:32 <bswartz> My instinct say it's the wrong thing to do
15:52:15 <tbarron> Shall  we give another week to resolve this one?
15:52:17 <gouthamr> calling several APIs isn't typically a problem - my intent was to simplify this for manilaclient and UI users anyway
15:52:24 <ganso> bswartz: which proposal is a significant API change and the wrong thing to do? to add a separate API or to add a separate field?
15:52:56 <tbarron> ok, we're going to do that, I think we're very close to agreeement on this and the issue at hand,
15:52:59 <ganso> gouthamr: honestly this doesn't look like a simplification to me
15:53:03 <tbarron> though important,
15:53:08 <tbarron> isn't central to the spec
15:53:24 <tbarron> We need to resolve it though, not push it to code review
15:53:35 <tbarron> So let's get it resolved by this time next week
15:53:41 <tbarron> Final spec,
15:54:07 <tbarron> * Share back end capabilities improvements
15:54:21 <tbarron> #link https://review.openstack.org/#/c/616383/
15:54:41 <ganso> I only have a small problem with this one ^: with the way the share_shrink_support column is handled w.r.t. existing shares
15:54:54 <gouthamr> not a small problem, lol :P
15:55:03 <tbarron> ganso: right, can that issue be resolved in code review?
15:55:05 <ganso> 1) I suggested using null instead of "legacy", seems like a very small change
15:55:14 <tbarron> Again this is not central to the proposal.
15:55:26 <gouthamr> ganso: sure - that part is..
15:55:33 <ganso> 2) document the steps to reset the field
15:55:44 <gouthamr> ?
15:55:55 <gouthamr> didn't see that comment
15:56:09 <ganso> tbarron: yea this is just minor, I don't oppose anything on the spec, this is just a suggestion
15:56:45 <tbarron> OK, gouthamr - see if you and ganso can come to agreement today on this.
15:56:51 <gouthamr> ack
15:56:52 <tbarron> ping us when it is ready.
15:57:16 <tbarron> Anyone else have objections on this one?
15:57:41 <tbarron> OK, more generally, we know which ones we want to merge and have
15:57:51 <tbarron> only extended one of them for another week.
15:58:14 <tbarron> So spec owners get anyone who has a -1 to remove it
15:58:28 <tbarron> Putting any remaining concerns for code review on record.
15:58:31 <tbarron> And ping me.
15:58:51 <tbarron> I'll take care of rounding up +2s from there ang getting them merged today or tomorrow.
15:59:05 <tbarron> Thanks everyone!
15:59:32 <tbarron> We're out of time today, but see you on #openstack-manila !
15:59:39 <tbarron> #endmeeting