15:02:00 <tbarron> #startmeeting manila
15:02:01 <openstack> Meeting started Thu Jun 27 15:02:00 2019 UTC and is due to finish in 60 minutes.  The chair is tbarron. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:04 <openstack> The meeting name has been set to 'manila'
15:02:08 <lseki> \o/
15:02:13 <gouthamr> o/
15:02:17 <carloss> hey :)
15:02:32 <tbarron> courtesy ping: gouthamr xyang toabctl bswartz ganso erlon tpsilva vkmc amito jgrosso
15:02:35 <ganso> hello
15:02:37 <vkmc> o/
15:02:41 <dviroel> o/
15:03:32 <lseki> tbarron: this courtesy ping seems outdated...
15:04:17 <tbarron> lseki: it is editable by anyone so peoole can add themselves
15:04:30 <tbarron> but it helps
15:04:40 <tbarron> if it don't leave part of it out :)
15:04:54 <tbarron> i see the folks I dropped here though
15:04:59 <tbarron> hi all!
15:05:22 <tbarron> we have some of our folks in training today
15:05:23 <vkmc> o/
15:05:36 <tbarron> and bswartz has a conflict for part of the meeting
15:05:45 <tbarron> so let's get started
15:05:54 <tbarron> we have a pretty full agenda:
15:06:10 <tbarron> #link https://wiki.openstack.org/wiki/Manila/Meetings
15:06:24 <tbarron> #topic announcements
15:06:43 <tbarron> I just want to remind folks that the call for presentations
15:06:46 <tbarron> deadline
15:07:02 <tbarron> for the Shanghai summit is this coming Tuesday
15:07:35 <tbarron> #link http://lists.openstack.org/pipermail/openstack-discuss/2019-June/007376.html
15:08:00 <tbarron> it will be good to have manila presentations!
15:08:17 <tbarron> Any other announcements?
15:08:49 <tbarron> #topic PTG planning
15:08:58 <tbarron> As noted here:
15:09:33 <tbarron> #link http://lists.openstack.org/pipermail/openstack-discuss/2019-June/007079.html
15:10:17 <tbarron> PTG will be a bit different this time
15:10:57 <tbarron> It will overlap with Summit
15:11:24 <tbarron> and run past Summit, so won't be a separate event
15:11:35 <tbarron> so in that respect a bit like last time
15:12:02 <tbarron> but there will likely be fewer attendees from the Americas and
15:12:08 <tbarron> more from the Pacific Rim
15:12:40 <tbarron> Because we have lots of regular PTG participants from the Americas we can
15:13:06 <tbarron> expect to do more of the post-meeting followup this time.
15:13:20 <tbarron> We already had carryover items this last time.
15:13:54 <tbarron> And we can expect to do more formal and informal onboarding during the Shanghai PTG itself.
15:14:02 <tbarron> Make sense?
15:14:33 <tbarron> Are there folks who normally attend PTG who know or think they won't be in Shanghai?
15:14:38 <tbarron> Or vice versa>
15:14:52 <tbarron> s/>/?/
15:15:02 <gouthamr> yep, we'll still plan to do physical presence and bluejeans?
15:15:27 <tbarron> I'll need to respond to an upcoming query to PTLs on PTG soon.
15:15:33 <tbarron> gouthamr: I think so.
15:16:49 <tbarron> maybe it would be best if people ping me privately with their best
15:17:01 <tbarron> estimate as to whether they will be attending physically
15:17:07 <tbarron> that would be best.
15:17:08 <gouthamr> i still don't know if i will be there, but if i can't; i may be able to join the first-half sessions
15:17:31 <lseki> pretty sure that 2 or 3 netappers will be there
15:17:32 <vkmc> bluejeans might be tricky
15:17:42 <tbarron> vkmc: that's a point
15:18:04 <vkmc> us based folks won't be able to follow it live
15:18:14 <gouthamr> oh i totally forgot about that :P
15:18:15 <vkmc> well, us... americas in general
15:18:26 <tbarron> los americanos
15:18:27 <lseki> and 1 or 2 will try to attend via bluejeans, though timezone won't help ;-(
15:18:30 <vkmc> emea is better but still might be late
15:18:40 <vkmc> tbarron, 'xactly
15:18:58 <tbarron> i think vkmc is referring to firewalls as well as TZ
15:19:09 <vkmc> so we need to make sure to take good notes
15:19:15 <tbarron> maybe zoom will work across firewalls
15:19:17 <vkmc> we need a doc person in the room
15:19:28 <vkmc> tbarron, wechat
15:19:42 <tbarron> vkmc: wedo
15:19:54 <vkmc> you can do anything with wechat in china, as far as I heard
15:20:18 <tbarron> ok, lots of logistics to figure out, thanks for letting me know that we'll have
15:20:24 <tbarron> netapp physical presence
15:20:46 <tbarron> #topic our work
15:20:59 <gouthamr> we might be able to figure something out for bluejeans, if you have decent computers: https://support.bluejeans.com/s/article/Premium-Access-for-China
15:20:59 <tbarron> new drivers
15:21:27 <tbarron> #link https://review.opendev.org/#/c/636819/
15:21:34 <tbarron> INSPUR driver
15:21:58 <tbarron> I've reviewed it informally and lseki and gouthamr have given it a lot of attention
15:22:05 <tbarron> I'm inclined to merge it
15:22:29 <tbarron> anyone have issues with this?  If you want to review, put your hand up please.
15:23:14 <tbarron> INSPUR CI is working and they've responded to all outstanding review questions at this point.
15:23:34 <tbarron> But the deadline isn't for another month so if you want to review you have time.
15:23:56 <tbarron> crickets
15:24:03 <gouthamr> yeah, only weird thing is their CI is running on stable branches, where the code isn't (going to be) present..
15:24:11 <gouthamr> hope they can turn off that bit..
15:24:33 <tbarron> gouthamr: do you want to hold workflow until that's fixed?
15:25:06 <gouthamr> tbarron: not really...
15:25:09 <tbarron> it's a waste of their resources but otherwise pretty harmless, right?
15:25:18 <tbarron> kk
15:25:37 <tbarron> #link https://review.opendev.org/#/c/657775/
15:25:46 <tbarron> this is INFORTREND ^^^
15:26:03 * gouthamr ALL CAPS
15:26:09 <tbarron> some of you may not have noticed that these are *two* things :)
15:26:29 * tbarron is practicing for his tweets
15:26:33 <gouthamr> lseki: great work on the reviews!
15:26:43 <lseki> gouthamr: thanks :-)
15:26:48 <tbarron> well thanks to lseki and gouthamr again
15:27:03 <tbarron> they've been pretty responsive but there are outstanding -1s
15:27:37 <tbarron> lseki: gouthamr: seems like this one is on track as long as they keep responding to review comments?
15:27:56 <gouthamr> yes..
15:28:07 <lseki> yep
15:28:22 <gouthamr> the CI's been running too, many of the changes suggested should be easy to incorporate, or respond to
15:28:33 <tbarron> ok, let's just keep track of it
15:28:57 <tbarron> #link https://review.opendev.org/#/c/664269/
15:29:15 <tbarron> NexentaStor5 NFS driver refactor ^^^
15:29:23 * gouthamr started looking at it
15:29:30 <gouthamr> ETOOBIG
15:29:47 <tbarron> gouthamr: in the finest ntap tradition :)
15:29:55 <tbarron> from when we were there
15:30:54 <tbarron> They are adding significant new features though
15:31:11 <tbarron> HA
15:31:37 <tbarron> DHSS true it looks like
15:32:11 <tbarron> and then internally using jsonrpc instead of http to communicate with the back end
15:32:27 <tbarron> the last is pretty much their business but we need to
15:32:34 <tbarron> review the other stuff
15:32:43 <tbarron> gouthamr: thanks for starting to look at this one
15:33:47 <tbarron> let's get some more eyes on it please
15:33:50 <gouthamr> ack, should have an initial review this week
15:35:07 <tbarron> OK, let's talk about Specs
15:35:31 <tbarron> #link https://review.opendev.org/#/c/661209
15:35:46 <tbarron> this is Add update share-type API to Share Types
15:35:56 <gouthamr> There's one more big driver change
15:36:09 <tbarron> gouthamr: oh, which?
15:36:16 <gouthamr> #LINK https://review.opendev.org/#/c/663089/
15:36:34 <gouthamr> although i see it's been redone now, i initially saw a lot of LOC
15:36:49 <bswartz> .o/
15:36:56 <tbarron> i was thinking it's "just" a rebranding
15:36:59 * bswartz is trying to escape from other meeting
15:37:13 * gouthamr provides bswartz covering fire
15:37:36 <tbarron> bswartz: welcome
15:38:03 <tbarron> I think most of the LOC are a file rename
15:38:12 <tbarron> but yeah, let's review it please
15:38:30 <tbarron> Specs
15:38:51 <tbarron> I'm inclined to merge the one we talked about last week
15:39:03 <tbarron> update share-types
15:39:22 <tbarron> lseki reviewed since then
15:39:26 <tbarron> thanks lseki
15:39:45 <tbarron> and dviroel
15:40:01 <tbarron> I think all reviewers are OK with it.
15:40:36 <tbarron> Anyone want to review it ?  Just raise your hand and I'll hold off workflow.
15:41:11 <tbarron> OK, let's talk about the spec for openstackclient
15:41:30 <tbarron> #link https://review.opendev.org/#/c/644218
15:41:50 <tbarron> as you can see this one has a lot of review attention and
15:41:56 <tbarron> corresponding updates
15:42:24 <tbarron> I think good progress is being made and new issues are being
15:42:32 <tbarron> discovered and addressed along the way.
15:43:17 <tbarron> It's important stuff and I mainly just want to hightlight it for review visibility.
15:43:23 <tbarron> Now.
15:43:54 <tbarron> Let's talk about the create from snaps in another pool or back end spec
15:44:09 <dviroel> \o/
15:44:14 <tbarron> #link https://review.opendev.org/#/c/609537
15:44:31 <tbarron> dviroel has done nice work here and the review is progressing but
15:44:46 <tbarron> an issue of fairly general interest came up
15:45:06 <tbarron> gouthamr: do you want to explain your remarks about slow copies?
15:45:25 * gouthamr hasn't seen dviroel's last update
15:46:08 <gouthamr> my comments are at https://review.opendev.org/#/c/609537/7/specs/train/create-share-from-snapshot-in-another-pool.rst@309
15:46:30 <tbarron> gouthamr pointed out that these creates may take long enough time
15:46:41 <gouthamr> so, our create_share driver interface is synchronous, and we expect drivers to return quickly
15:46:44 <tbarron> that it would make sense to do them asynchronously
15:46:55 * tbarron baks off now :)
15:47:16 <dviroel> yes, for sure. In scenarios where we need move data between different pools/backends, this copy can take longer then expected...
15:47:25 <gouthamr> if they take a long time to perform some thing, it might starve a thread on our end... so i think it's time to revisit that, especially for this use case
15:48:18 <gouthamr> so i think we can allow drivers to tell us the new share isn't ready yet
15:48:34 <gouthamr> and we can check back at our default periodic interval
15:48:43 <gouthamr> kinda like what we do for migration and replication today
15:48:45 <tbarron> so the driver would tell the manager that the share is still 'creating', right?
15:49:08 <dviroel> Yes, agree
15:49:18 <tbarron> ok, you guys agree
15:49:26 <tbarron> it will require a bit of manager work
15:49:27 <gouthamr> yes, i think that's a good way to signal that
15:49:49 <gouthamr> today, drivers return export locations, which can be a string, a list of strings or a list of dictionaries
15:49:50 <tbarron> anyone have issues with this approach?
15:50:45 <tbarron> I think it's consistent with what we do in general, loosely couple services and allow operations to go into ING states
15:51:03 <tbarron> at the time of an rpc or boundary handoff
15:51:37 <tbarron> manager to driver is a library call, not a service rpc
15:51:57 <gouthamr> what needs to be considered is how the manager will track these shares
15:52:15 <tbarron> but the back ends are separate services really
15:52:18 <gouthamr> and how it will ask drivers for their status
15:52:40 <tbarron> gouthamr: the priodic check will work, right?
15:53:08 <tbarron> and we have to address all those periodic tasks with leader election or some such whe
15:53:21 <tbarron> when we do active-active share service
15:53:35 <tbarron> so this doesn't change that equation
15:54:56 <gouthamr> that's one concern
15:55:08 <dviroel> I was thinking that should work in the way it works for replication.
15:55:10 <tbarron> i would think the manager should pass a list of shares to the driver rather than one by one when querying status
15:55:19 <gouthamr> the other is how the manager can identify shares that need to be queried for
15:56:07 <gouthamr> can we expect that, even with asynchronous creation, the driver can update export locations?
15:56:42 <gouthamr> then it'll be easier for us to query for creating shares and filter them by those that have export locations
15:57:02 <gouthamr> else, we'd pick up shares that are in-flight too, to perform a status check
15:57:38 <tbarron> gouthamr: what about keeping a list of shares in the manager that are driver-creating?  persist it to DB for manager restarts but keep it in memory
15:58:04 <gouthamr> tbarron: in-memory?
15:58:12 <tbarron> for speed
15:58:30 <tbarron> or look it up every time, maybe it doesn't matter
15:58:46 <tbarron> but avoid checking all shares for state
15:59:05 <tbarron> maybe I'm doing premature optimization
15:59:12 <tbarron> and using up time
15:59:19 <gouthamr> yep, time check :)
15:59:28 <tbarron> this is a good topic, so join the discussion in the review
15:59:34 <tbarron> Thanks everyone!!
15:59:56 <dviroel> Thanks
16:00:00 <tbarron> i have one more operational concern, for #openstack-maila in a minute
16:00:06 <tbarron> #endmeeting