15:01:08 <tbarron> #startmeeting manila
15:01:10 <openstack> Meeting started Thu Aug  9 15:01:08 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:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:12 <bswartz> .o/
15:01:13 <openstack> The meeting name has been set to 'manila'
15:01:19 <gouthamr> \o
15:01:22 <xyang> hi
15:01:22 <dustins> \o
15:01:24 <tbarron> bswartz is here!
15:01:35 <vgreen> hi
15:01:40 <ganso> hello o/
15:02:03 <tbarron> hi folks!
15:02:18 <bswartz> Only minor technical difficulties this week
15:02:29 <tbarron> agenda: https://wiki.openstack.org/wiki/Manila/Meetings
15:02:35 <markstur> hi
15:02:40 <tbarron> the bswartz lab is back in service?
15:02:49 <tbarron> hi mark!
15:03:02 <bswartz> tbarron: not exactly -- it's jerry-rigged to run for at least a bit longer though
15:03:02 <tbarron> #topic announcements
15:03:24 <tbarron> bswartz: can we run third-party CI from it?
15:03:43 <tbarron> Any way, on to more formal announcments.
15:03:48 <gouthamr> it ain't no beef-supreme
15:03:55 <jun2222> hi
15:04:05 <tbarron> For those who live under a rock, today is the RC1 deadline.
15:04:07 <bswartz> tbarron: I used to do that, but I didn't want to be responsible in the long run
15:04:36 <tbarron> Our review to release manila rc1 and cut the stable/rocky branch is close to merge at this point.
15:05:02 <tbarron> Also one for manila-ui since horizon has released and we got our fixes in.
15:05:15 <tbarron> vkmc++ for fixing a bad bug.
15:05:25 <tbarron> who needs a create shares button anyways?
15:05:31 <gouthamr> vkmc: +1
15:06:01 <tbarron> and thanks to akihiro from the horizon team and cshort for getting some
15:06:25 <tbarron> dependency stuff cleaned up and all past traces of mox usage out of the way.
15:06:46 <tbarron> So main branch will open up for development again soon but our focus needs to
15:06:54 <vkmc> :)
15:07:01 <tbarron> be on testing and bug fixing any blockers we may discover.
15:07:06 * vgreen needs a create share button!
15:07:19 <tbarron> It's hard string freeze now.
15:07:25 <gouthamr> #createshare2020
15:07:41 <tbarron> So even if we have a blocker bug and need to cut a new rc, be careful in
15:07:46 <amotoki> I think it is more important than hard string freeze though...
15:07:47 <tbarron> reviews of any string changes.
15:07:52 <vgreen> #createsharematter
15:08:00 <tbarron> amotoki :D
15:08:16 <amotoki> it is a comment from my i18n hat.
15:08:27 <tbarron> amotoki: you get around
15:08:59 <ganso> #notmycreateshare
15:09:13 <tbarron> So at this point we've cut all our releases except for manila-tempest-client
15:09:44 <tbarron> We've never released it before and as an intermediary cycle project we have
15:09:57 <tbarron> a couple more weeks
15:10:13 <tbarron> #link https://releases.openstack.org/rocky/schedule.html#r-finalrc
15:10:41 <tbarron> We'll watch for the release of tempest itself in case they do anything at
15:10:55 <tbarron> the last minute that will require adjustments on our side.
15:11:08 <tbarron> Any questions/comments about the release stuff?
15:11:26 <bswartz> What's left to merge?
15:11:30 <bswartz> Any final fixes?
15:11:34 <tbarron> bswartz: no
15:11:46 <tbarron> and I've already posted the rc release review
15:12:00 <tbarron> bswartz: oh, you mean for manila-tempest-plugin?
15:12:24 <ganso> tbarron: https://review.openstack.org/#/c/539996 this one was trying to get through the gate
15:12:24 <tbarron> if that, maybe some scenario tests that are in progress but mostly I
15:12:32 <bswartz> I was just asking if we have any work left to do before you can push the tags
15:12:33 <tbarron> ganso: it's too late
15:12:36 <tbarron> not a blocker
15:12:41 <ganso> tbarron: ok np
15:13:01 <tbarron> bswartz: ganso in last week's meeting I announced that we'd post the reviews Wednesday this week.
15:13:13 <tbarron> I lied, did it early this morning.
15:13:28 <tbarron> No point in jamming things up for the release team.
15:14:04 <tbarron> And a couple of us did lots of review work this week trying to help steward patches through before the deadline even
15:14:16 <tbarron> though they weren't by any means release blockers.
15:14:46 <tbarron> OK, before leaving Announcements topic,
15:15:10 <tbarron> just a reminder to update the PTG planninng etherpad as you come up with
15:15:14 <tbarron> great thoughts
15:15:39 <tbarron> #link https://etherpad.openstack.org/p/manila-ptg-planning-denver-2018
15:15:57 <tbarron> Any other announcments?
15:16:23 <tbarron> #topic API wsgi service and python 3
15:16:50 <tbarron> last week we touched on the problem that our builtin eventlet based wsgi service
15:16:55 <tbarron> has problems with python3
15:17:08 <tbarron> but the MOD_WSGI service that is our alternative
15:17:20 <tbarron> has lousy to non-existent debug information.
15:17:41 <tbarron> We need a solution that works with python3 but that doesn't lose the debug info.
15:18:11 <tbarron> vkmc and gouthamr have been looking at uwsgi -- used by cinder, glance, nova in devstack
15:18:24 <tbarron> which appears to meet these requirements
15:18:40 <tbarron> vkmc: gouthamr: is this an accurate summary?
15:18:46 <gouthamr> tbarron: i'm not entirely sure what debug info is missing with the mod_wsgi deployment
15:19:31 <tbarron> gouthamr: well for one thing logging is done as part of apache/httpd, right?
15:20:03 <tbarron> gouthamr: and -- not exactly to your point -- service restart requires restart of all apache
15:20:20 <gouthamr> tbarron: yes, but there's nothing lost in translation
15:20:33 <tbarron> gouthamr: but also it seems to me looking at the apache logs there was missing info, you disagree?
15:21:00 <gouthamr> tbarron: yes, i didn't notice anything missing
15:21:06 <tbarron> bswartz: didn't you think we were missing info in the mod_apache logs?
15:21:36 <bswartz> I wasn't concerned about logs -- it was the ability to run m-api inside a pycharm debugger
15:21:38 <tbarron> gouthamr: if there's nothing missing then the simplest thing would be just to cutove rto mod_wsgi and be done wiht it.
15:21:47 <tbarron> bswartz: oh
15:21:59 <tbarron> bswartz: isn't eventlet probematic for that too?
15:22:13 <bswartz> Not anymore
15:22:15 <tbarron> bswartz: requires pycharm hacks
15:22:33 <tbarron> and old version of pycharm, at least in the cknight days :D
15:22:57 <bswartz> It's something I've done in the past, and it would be good to not lose that ability
15:23:07 <bswartz> That being said, I won't throw a fit if we do
15:23:19 <tbarron> bswartz: I misunderstood your concern; have you tried it (or asked) with uwsgi?
15:23:21 <bswartz> Modern versions of pycharm work fine with eventlet
15:23:33 <tbarron> bswartz: ack
15:24:11 <tbarron> and they won't work with mod_wsgi?  or is it just that you have to debug the whole big httpd thing?
15:24:13 <vkmc> I haven't tried that, which is the problem specifically? how can I reproduce that?
15:24:35 <bswartz> Right, mod_wsgi means the parent process is a webserver, and you can't debug like that
15:24:52 <bswartz> uwsgi might work fine -- I haven't looked closely at it
15:25:11 <vkmc> we are currently deploying manila with mod_wsgi by default on devstack
15:25:30 <tbarron> nova, glance, cinder all use uwsgi in devstack so maybe we need to find some pycharm folks from those projects and ask
15:26:33 <tbarron> OK, this is a topic for more research and likely PTG discussion but I'm glad I asked about it again.
15:26:44 <bswartz> I'm surprised you're not all pycharm folks
15:26:52 <bswartz> pycharm = win
15:26:57 <dustins> pycharm++
15:27:02 <gouthamr> wut bswartz !!
15:27:06 <tbarron> I had misunderstood the nature of the concern with dropping the eventlet
15:27:16 * tbarron thinks bswartz (eclipse) is trolling
15:27:18 * gouthamr doesn't even remember the guy now
15:27:34 <tbarron> where did mr open source go?
15:27:48 <tbarron> bswartz is probably using a mac
15:28:33 <tbarron> OK, more checking, questions, research.  Thanks to vkmc and gouthamr for the research thus far.
15:28:53 <tbarron> #topic Bugs
15:29:00 <bswartz> pycharm is open source -- at least the version I use
15:29:03 <tbarron> dustins: what do you have for us today?
15:29:36 <dustins> https://bugs.launchpad.net/manila/+bug/1786059
15:29:36 <openstack> Launchpad bug 1786059 in Manila "Cannot Connect to Share Server when Creating Share with Generic Driver (DHSS=True)" [Undecided,New]
15:29:38 <dustins> erm
15:29:40 <dustins> #link https://bugs.launchpad.net/manila/+bug/1786059
15:30:01 <ganso> etherpad link?
15:30:38 <dustins> ganso: https://etherpad.openstack.org/p/manila-bug-triage-pad
15:30:45 <ganso> dustins: thx
15:30:46 <gouthamr> there's a log formatting bug hiding the bug
15:31:01 <tbarron> #link: https://etherpad.openstack.org/p/manila-bug-triage-pad
15:31:07 <tbarron> for the minutes
15:32:15 <tbarron> gouthamr: do you see the real bug?
15:32:41 <tbarron> One thing I notice is that he's running manila-share on its own node
15:32:59 <tbarron> he's likely running l3gw on his controller node
15:33:16 <gouthamr> so manually he tried "ssh manila@10.254.0.3 with password manila
15:33:38 <gouthamr> from the same node
15:34:56 <tbarron> I see
15:36:16 <tbarron> so manila share on the same node with the same credentials can't ssh in.
15:37:21 <tbarron> Well we need someone who works on the generic driver to pursue this but
15:37:32 <tbarron> unfortunately no one is paid to do that any more.
15:37:53 <dustins> And no one like it enough to do it for free :)
15:39:34 <tbarron> We see a lot of transient issues in gate doing ssh to service VMs but this is likely consistent.
15:40:13 <gouthamr> the gate issues we see are usually timeouts
15:40:34 <tbarron> I don't myself have insight on this one.  Anyone around here a paramiko wizard?
15:41:07 <tbarron> The relevant difference seems maybe that manila-share is using paramiko as ssh client vs
15:41:10 <gouthamr> nope, but there was a similar open issue on paramiko: https://github.com/paramiko/paramiko/issues/657
15:41:17 <ganso> I remember this was a known limitation, that the controller (more specifically neutron-node) and manila-share node need to be the same for the generic driver to work
15:41:22 <tbarron> manualy him using some normal ssh client.
15:41:47 <tbarron> ganso: that's what I was thinking of but why does his manual ssh from the same node work then?
15:42:25 <tbarron> with separate nodes it's true that the L2 stitching has to be set up right to get to the L3gw, etc.
15:42:30 <ganso> tbarron: would need to inspect his network setup more closely to understand this, there are many ways to achieve connectivity to a VM inside a node
15:43:11 <ganso> tbarron: he could be using flat networking and connecting to the node via the bridge interface on the host
15:44:06 <ganso> tbarron: it seems he is using linuxbridge driver, I don't know how it handles vxlan, nor the access restrictions compared to openvswitch
15:44:17 <ganso> tbarron: it is hard to debug this unless we come up with a similar setup to debug
15:44:30 <tbarron> ganso: agree
15:44:56 <dustins> ganso: Would you mind commenting on the bug to see if we can get those details from the reporter?
15:45:01 <ganso> tbarron: since he is using linuxbridge driver and we pretty much only test with openvswitch, hows the probability of us addressing this?
15:45:53 <ganso> dustins: I'll comment there
15:46:58 <dustins> ganso: awesome, thanks!
15:47:05 <dustins> Ready for another?
15:47:23 <dustins> #link https://bugs.launchpad.net/manila/+bug/1784791
15:47:23 <openstack> Launchpad bug 1784791 in Manila "NetApp driver does not support workgroup authentication" [Undecided,New]
15:47:41 <gouthamr> interesting
15:48:09 <dustins> Looks like CIFS stuff
15:48:13 <gouthamr> manila doesn't support that security service, so this is an RFE
15:48:44 <bswartz> Yeah this is an RFE for the NetApp driver in particular
15:48:53 <dustins> Yeah, looks that way
15:49:01 <bswartz> Whether it's a bug or not depends on your perspective
15:49:09 <bswartz> But it's not something that worked in the past
15:49:16 <dustins> I'll leave the NetApp contingent to handle this as they see fit, then
15:50:00 <dustins> #link https://bugs.launchpad.net/python-manilaclient/+bug/1785297
15:50:01 <openstack> Launchpad bug 1785297 in python-manilaclient "cStringIO import invalid for Py3" [Undecided,New]
15:51:35 <dustins> I wonder if there's an equivalent library for Python 3
15:51:40 <gouthamr> seems like an easy/worthy fix
15:52:00 <gouthamr> dustins: yep "import the io module and use io.StringIO or io.BytesIO for text and data respectively."
15:52:19 <dustins> gouthamr: That is easy
15:52:49 <dustins> I can have a look at that and have a fix in today
15:53:11 * dustins assigns himself
15:53:37 <dustins> Speaking of python 3.7...
15:53:42 <dustins> #link https://bugs.launchpad.net/python-manilaclient/+bug/1785283
15:53:42 <openstack> Launchpad bug 1785283 in python-manilaclient "Py3.7 unit test failures" [Undecided,New]
15:54:14 <gouthamr> ouch man, corey's got more bionic beaver than the gate
15:54:52 <dustins> gouthamr: Does Bionic Beaver only ship with 3.7?
15:55:01 <gouthamr> we've ^ on the PTG agenda... but dustins, i can take this one
15:55:16 <bswartz> Death to py2!
15:55:31 <dustins> gouthamr: Sounds good, I'll assign you if you haven't done so already
15:56:21 <dustins> gouthamr: Uhh, actually you can do it, I only see your old email :)
15:56:27 <gouthamr> oh
15:56:29 <tbarron> hey folks, looks like my network dropped
15:56:29 <gouthamr> sure thing
15:56:31 <tbarron> I was just writing away, you guys missed some very good stuff :)
15:56:38 <dustins> bswartz: +1000
15:56:50 <dustins> tbarron: At least you didn't get banned this time
15:57:03 <tbarron> #chair bswartz
15:57:04 <openstack> Current chairs: bswartz tbarron
15:57:15 <tbarron> you can end the meeting if it happens again
15:57:39 <tbarron> where are we, bugs?
15:57:40 <bswartz> sure
15:57:43 <dustins> Got a few more, but I'll save them for later
15:57:50 <dustins> Last one for today though:
15:57:55 <dustins> #link https://bugs.launchpad.net/manila-ui/+bug/1664370
15:57:55 <openstack> Launchpad bug 1664370 in manila-ui "Manila exposes host/pool details to non-admin tenants" [Undecided,New]
15:58:16 <dustins> There's a fix released on Manila, but manila-ui the status is unknown
15:58:20 <tbarron> that's pretty bad
15:58:29 <dustins> I imagine that it's complete, but I just wanted to verify
15:58:39 <tbarron> reported in 2017
15:58:41 <dustins> And yes, that's quite bad
15:58:53 <tbarron> oh, you're guessing it's fixed
15:59:01 <tbarron> we need a good QE to verify :D
15:59:03 * dustins is roping in more Manila UI and Manila Client stuff of late
15:59:26 <dustins> vgreen you wanna dive into more Horizon wonderment?
15:59:30 <dustins> :)
15:59:43 <gouthamr> dustins: i don't see the host/pool column
15:59:45 <tbarron> dustins: well actually the bug log says it's fixed
16:00:03 <tbarron> oh, in manila, sec
16:00:06 <dustins> tbarron: Yeah, that's what makes me think that it's a bookkeeping thing
16:00:25 <vgreen> will check it later, sure
16:00:34 * dustins goes to #openstack-manila
16:00:39 <gouthamr> oh, i see where the bug was - well, by the virtue of manila not providing that info, Host is empty when you view share details
16:01:06 <gouthamr> dustins: so we can mark it low, and remove that field in the next release
16:01:15 <tbarron> we're out of time, see y'all on #openstack-manila
16:01:19 <tbarron> Thanks everyone!!
16:01:23 <tbarron> #endmeeting