15:00:13 <bswartz> #startmeeting manila
15:00:14 <openstack> Meeting started Thu May  4 15:00:13 2017 UTC and is due to finish in 60 minutes.  The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:19 <openstack> The meeting name has been set to 'manila'
15:00:22 <bswartz> hello all
15:00:23 <cknight> Hi
15:00:24 <dustins> hey hey
15:00:25 <jprovazn> HI
15:00:26 <ganso> hello
15:00:27 <toabctl> hey
15:00:30 <zhongjun> hi
15:00:43 <tbarron> hi
15:00:48 <xyang1> Hi
15:01:09 <bswartz> markstur gouthamr: courtesy ping
15:01:23 <jungleboyj> o/
15:01:26 <markstur> hi
15:01:28 <bswartz> vponomaryov is on vacation today
15:01:43 <gouthamr> o/
15:01:44 <bswartz> #topic announcements
15:02:02 <bswartz> so I assume all of you know Boston is next week
15:02:12 <bswartz> and there are no Manila sessions planned
15:02:22 <tbarron> manila status report
15:02:37 <bswartz> Some presentations at the summit will be relevant to Manila, but we're not doing the typical developer summit stuff because we did that at PTF
15:02:39 <bswartz> PTG
15:02:43 <tbarron> kk
15:02:43 <tommylikehu> hello
15:03:09 <bswartz> tbarron: yeah I'm doing the project update -- cknight and ganso have a presentation, and I expect there will be others too
15:03:44 <gouthamr> tbarron vkmc and rraja have one too
15:04:00 <gouthamr> and arneweiback
15:04:02 <gouthamr> (sp)
15:04:15 <bswartz> anyways I was planning to hold the weekly meeting as normal next week, unless most of you won't attend
15:04:16 <xyang1> I'll be there too
15:04:47 <gouthamr> xyang1: :) ofcourse you will
15:04:49 <bswartz> My time in Boston will be limited to Tuesday/Wednesday so I'll be back home by Thursday and I can chair the meeting as usual
15:04:56 <xyang1> Most likely I won't attend
15:05:04 <tbarron> nor i, but so what
15:05:06 <bswartz> xyang1 won't even need a hotel
15:05:13 <xyang1> bswartz: :)
15:05:30 <ganso> I don't plan on attending the weekly meeting as well
15:06:02 <bswartz> anyone really want to keep the meeting next week?
15:06:20 <bswartz> if not, it sounds like we should preemptively cancel
15:06:27 <tbarron> I think next Thursday at that time Paddy Power Betfair will be talking about deploying manila with netapp backend
15:06:35 <gouthamr> +1 cancel
15:06:42 <bswartz> oh yes betfair
15:06:42 <tbarron> dunno if it will be live-streamed
15:06:47 <markstur> +1 (out-of-town)
15:07:03 <markstur> +1 cancel that is
15:07:09 <bswartz> tbarron: you can attend the session and live-tweet it
15:07:13 <bswartz> LOL
15:07:17 <tbarron> bswartz: heh
15:07:21 <xyang1> markstur: are you not in Boston?
15:07:23 <vkmc_> o/
15:07:38 <markstur> xyang1: Not Boston
15:07:42 <bswartz> okay then it's decided, no meeting next week -- I'll post a note on the wiki
15:07:46 <jungleboyj> markstur:  :-(
15:07:59 <markstur> jungleboyj: yeah
15:08:09 <xyang1> markstur: :(
15:08:12 <bswartz> #agenda https://wiki.openstack.org/wiki/Manila/Meetings
15:08:22 <bswartz> #topic Share usage monitoring
15:08:29 <bswartz> #link https://review.openstack.org/#/c/459150/
15:08:37 <bswartz> just wanted to call attention to this spec one last time
15:08:44 <bswartz> I think we're happy with it finally
15:09:05 <bswartz> but if anyone has a discussion topic or question to raise now, we can spend some time on it
15:09:59 <bswartz> okay
15:10:17 <bswartz> sounds like we can move on
15:10:22 <zhongjun> It got two +2, and waiting for another. :)
15:10:33 <bswartz> zhongjun there are 4
15:10:50 <bswartz> and vponomaryov won't vote because he's out
15:10:55 <zhongjun> oh, cool
15:11:20 <bswartz> so anyone else who wants to review please do right after the meeting and if no objections I'll workflow shortly
15:11:40 <bswartz> and that will wrap up specs for the Pike release
15:11:58 <bswartz> #topic Summit/PTG
15:12:35 <bswartz> so the other thing I wanted to discuss today is the future of our community-wide design meetings
15:12:57 <bswartz> I'm already being asked about the Denver PTG
15:13:09 <bswartz> whether we want space there or not
15:13:31 <ganso> oh it is going to be in Denver, I had heard rumors it was not going to be in the US
15:13:40 <bswartz> and I told the foundation folks I want to see how the "hacking spaces" in Boston are before I give my answer
15:13:55 <bswartz> but what you all want is more important
15:14:31 <jungleboyj> ganso:  They landed on Denver because the venue was cheaper and more compact.
15:14:31 <kaisers> O/
15:14:32 <bswartz> My bottom line is that I think 4 annual face to face meetings is unrealistic for a team as distributed as ours
15:15:16 <bswartz> ganso: they were threating to do a non-US PTG when the trump travel ban was still up being fought in the courts -- since that's been settled, I guess they feel okay about US-based venues again
15:16:47 <bswartz> anyways I know that most of us can't get budget to travel 4 times a year, so we need to figure out what kind of face to face meetings we want to have going forward and whether we want to align with PTG or summit or something else
15:17:08 <tbarron> I think we have to be able to do design w/o four global face-to-face meetings a year, agree.
15:17:42 <bswartz> the foundation's stance is clear, and I disagree with it -- they expect developers to come to all 4 annual events
15:18:05 <tbarron> And my company at least thinks it will be more cost-effective to do PTGs.
15:18:39 <jungleboyj> tbarron:  That seems to be the leaning and I think the Foundation is trying to make it that way.
15:19:12 <bswartz> anyways we don't have to decide now, but I'd like to collect feedback on the possibility of trying to do our face to face meetings at summits instead of PTGs in the future
15:19:28 <tbarron> the foundation's stance is somewhat ambiguous: they want a "sufficient number" of key developers at Forums but I think they want PTGs to be the main place developers plan with one another
15:19:38 <bswartz> because it seems that some people are able to travel to summits more easily than PTGs
15:19:56 <vkmc_> So... AFAIK PTGs were a way to formalize midcycles
15:20:10 <bswartz> tbarron: I know, it's maddening -- they want to eat their cake and still have it
15:20:31 <jungleboyj> vkmc_:  Yeah, that was the goal.
15:20:37 <ganso> going to the PTG will not stop the need of travelling 4 times... as some of us submit presentations for the summit
15:20:49 <vkmc_> But I'm afraid that we won't have so much time and room on the summits
15:21:10 <bswartz> ganso: that was my point -- whether we do anything at summit or not, many of us have to travel there anyways
15:21:16 <vkmc_> At least, compared to the past format
15:21:53 <bswartz> the other mark against the PTG format is that holding our meetings there effectively prevents meeting with other teams for cross project work
15:22:06 <bswartz> now we could work with the foundation to fix the latter problem
15:23:16 <bswartz> but another alternative is to make our official design meetings purely virtual (like the virtual midcycles we've done in the past) and to plan ad-hoc meetings for PTG and summit around whenever there aren't any conflicts
15:23:57 <bswartz> anyways I wanted to suggest some options today, and get you thinking about what we want to do as a community for Queens
15:24:10 <bswartz> we don't need to decide today, but we will need to decide after boston
15:24:50 <bswartz> I'm going to Boston with an eye towards the possibility that maybe doing face to face meetings at summits instead of PTGs could be a better way to get together, so I'll be watching the forum and the hacking spaces
15:25:44 <bswartz> that's all I had on that topic
15:25:56 <bswartz> #topic open discussion
15:26:00 <vkmc_> bswartz: +1
15:26:20 <bswartz> anything else for today?
15:26:22 <tbarron> Do we have a way today to indicate preferred export locations?
15:26:34 <tbarron> This may be a Queens spec
15:26:47 <ganso> tbarron: AFAIK, yes, I've seen a "preferred" flag for export locations
15:26:49 <gouthamr> we have "preferred"
15:26:55 <bswartz> tbarron: that's what the work on the export location metadata was about
15:27:12 <tbarron> I'd like driver to be able to choose preferred location for each server, to be more precise
15:27:20 <tbarron> for each user VM consumer
15:27:23 <bswartz> flags exposed through export location metadata need to be community standards -- we don't allow vendor-specific stuff there
15:27:40 <bswartz> tbarron: that's a separate issue
15:27:52 <bswartz> you're talking about export location locality
15:27:53 <tbarron> bswartz: right, but driver may know which would be the best export location for a particular VM
15:28:10 <tbarron> bswartz: right, any objection to us thinking about it and working on it?
15:28:19 <bswartz> Manila has zero idea where you VM is, so all we can do is tell you what we know about where the export locations are
15:28:25 <tbarron> bswartz: it's relevant to failure domains.
15:28:37 <bswartz> currently all manila knows is the AZ
15:28:48 <gouthamr> yes, we wanted to incorporate AZ info into export locations
15:28:56 <tbarron> bswartz: right, but one can ask nova and chase it that way too
15:28:57 <tbarron> I
15:29:11 <tbarron> I'm interested in more fine-grained than AZ
15:29:14 <bswartz> gouthamr: no share can have export locations in AZs other than where the share is currently
15:29:28 <gouthamr> currently, we don't have that information in the export locations API.. you can look at the share instance itself to figure out what the AZ is
15:29:31 <tbarron> Anyways, we can pursue this more, just checking if there's any prior art.
15:29:41 <bswartz> with replicas -- the AZ is on the replica
15:30:07 <bswartz> tbarron: the Hitachi SOP people really wanted that feature
15:30:37 <bswartz> but we couldn't figure out a vendor-neutral way to express locality in a way that would also make sense to a nova user
15:30:45 <tbarron> my use case is that I want the share server to be one of a set of share servers and I want to pick the share server running on the same compute node as the vm it serves
15:30:55 <tbarron> so I don't need share server HA/redundancy to avoid a meaningful SPOF
15:31:21 <tbarron> if the share server dies b/c of hardware failure then it's consumers will also have died
15:31:38 <tbarron> I'll write it up.
15:32:02 <bswartz> tbarron: for export locations that literally on the hypervisors where nova runs, it easy to see how we could provide information that's relevant to nova, but most of our drivers couldn't do that
15:33:00 <tbarron> yeah, i'll have to make it an optional thing
15:33:06 <tbarron> topic #2
15:33:08 <bswartz> that could work
15:33:24 <tbarron> do we have any way at all of supporting nova VM migration?
15:33:34 <tbarron> I think not, just checking.
15:33:46 <bswartz> tbarron: migration of the VMs or migration of the shares?
15:34:02 <tbarron> migration of VMs, ejection and start on different compute host
15:34:11 <bswartz> or are you talking about migration of shares servers with something like the generic driver
15:34:22 <tbarron> no, migration of VMs
15:34:22 <bswartz> tbarron: that should just work
15:34:31 <tbarron> with live mounts?
15:34:39 <bswartz> shares should be reachable from the whole world
15:34:55 <tbarron> but how do we quiesce and move ?
15:34:56 <bswartz> as long as nova doesn't change the IP or break the routing while the VM is moving, I see no issues
15:35:09 <tbarron> no libvirt support for that with shares, right?
15:35:18 <bswartz> I think support isn't needed
15:35:43 <tbarron> what happens if the VM is in the middle of writes?
15:35:55 <bswartz> shares are really a higher level application that relies on the network stack inside the guest OS
15:36:13 <bswartz> tbarron: same thing that happens to any application with active network traffic during a migration
15:36:32 <bswartz> as long as the network stack doesn't break, the VM shouldn't notice any problems
15:36:35 <jungleboyj> tbarron:  Isn't that really the challenge of migration. Quiescing the work on the VM?
15:36:45 <bswartz> and I'm pretty sure that nova would keep the same IP and routing
15:36:47 <jungleboyj> tbarron:  Wouldn't think that is specific to Manila.
15:36:57 <jungleboyj> bswartz:  It is supposed to.
15:37:19 <tbarron> I wonder if anyone has tested this.
15:37:30 <bswartz> tbarron: I would imagine that, worst case, you could lose some packets and the guest would need to retry those packets
15:37:44 <bswartz> both NFS over TCP and UDP can deal with packet loss though
15:37:53 <bswartz> NFS is insanely tolerant of failures
15:38:32 <bswartz> with a hard mount, your I/O will just freeze until the NFS server is reachable again
15:38:59 <bswartz> soft mounts could conceivably get I/O errors if packet loss was bad enough during the migration
15:39:01 <tbarron> So nova is smart enough to bring up the new VM with the same client IP, and locks just work, etc.?
15:39:19 <bswartz> tbarron: yes I'd say I'm pretty confident
15:39:21 * tbarron is happy
15:39:21 <jungleboyj> tbarron:  As far as I know.
15:39:28 <bswartz> but to your question, I haven't tested it personally
15:40:32 <bswartz> alright anything else today?
15:40:53 <bswartz> if not, see you guys in boston
15:41:04 <jungleboyj> Sounds good.  See you there.
15:41:08 <bswartz> for anyone who came in late, weekly IRC meeting is canceled next week
15:41:25 <tbarron> bye
15:41:38 <zhongjun> good night :)
15:41:40 <bswartz> and there are no developer meetings planned for Manila in boston, just summit presentations and random discussions
15:41:46 <bswartz> #endmeeting