15:00:17 <bswartz> #startmeeting manila
15:00:18 <openstack> Meeting started Thu Jun  1 15:00:17 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:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:22 <openstack> The meeting name has been set to 'manila'
15:00:26 <bswartz> hello all
15:00:27 <cknight> Hi
15:00:30 <markstur> hi
15:00:31 <vponomaryov> hello
15:00:31 <ganso> hello
15:00:32 <tbarron> hi
15:00:49 <bswartz> welcome back tbarron
15:00:54 <tbarron> thanks
15:00:58 <zhongjun> hi
15:00:58 <bswartz> #topic announcements
15:01:07 <bswartz> The Pike-2 milestone is NEXT WEEK
15:01:14 <vkmc> o/
15:01:24 <xyang2> hi
15:01:46 <tbarron> https://releases.openstack.org/pike/schedule.html#p-manila-nddeadline
15:01:52 <bswartz> Also the new driver submission deadline is next week
15:01:58 <jungleboyj> o/
15:02:21 <bswartz> new drivers must be in by Monday
15:02:38 <bswartz> the milestone will probably get cut wednesday or thursday
15:02:41 <vponomaryov> with CI?
15:02:51 <bswartz> yes
15:02:52 <tbarron> "New drivers must be substantially complete, with unit tests, and passing 3rd party CI by this date. Drivers do not need to be merged until the feature freeze date, but drivers that don’t meet this deadline will not be considered at all for Pike."
15:03:03 <bswartz> passing 3rd party CI by Monday 23:59 UTC
15:03:24 <xyang2> bswartz: is there an etherpad that lists all the new drivers
15:03:31 <zhongjun> A keeping stable success CI?
15:03:32 <tbarron> let's hope there's not another setuptools breakage ...
15:03:44 <bswartz> xyang2: I'm not keeping a list
15:04:22 <bswartz> after the deadline we will want to track the new driver submissions that met the deadline to make sure they get review attention
15:04:54 <bswartz> zhongjun: the longer the record of success the better
15:05:11 <bswartz> however the main requirement is that it passed once before the deadlnie
15:05:34 <zhongjun> bswartz: ok, get it
15:05:38 <bswartz> #agenda https://wiki.openstack.org/wiki/Manila/Meetings
15:06:02 <bswartz> there's only one topic today, one I added
15:06:08 <bswartz> #topic Share groups + UI
15:06:29 <bswartz> I wanted to call attention to this feature that vponomaryov has been working on and I've been reviewing
15:06:34 <vponomaryov> #link https://review.openstack.org/#/c/468899
15:07:14 <bswartz> some of the UI patches that the share groups work depends on look like they're VERY LARGE but they're actually not
15:07:30 <bswartz> most of the changed lines are due to file renames or splitting up files
15:07:39 <bswartz> I would encourage reviewers to download the patches and try them out
15:07:43 <gouthamr> late o/
15:07:48 <bswartz> (the UI patches that is)
15:07:59 * bswartz marks gouthamr tardy
15:08:02 <gouthamr> :P
15:08:07 <zhongjun> bswartz: I will
15:08:57 <bswartz> so there's nothing in particular to discuss about this feature other than that I'd like to get it in before Pike-2
15:09:28 <bswartz> I've been reviewing all of the patches, just need to add my votes
15:09:38 <bswartz> #topic open discussion
15:10:03 <bswartz> does anyone else have something we need to discuss?
15:10:07 <gouthamr> i've one: https://review.openstack.org/#/c/369749
15:10:13 <bswartz> oh I just remembered something
15:10:17 <gouthamr> "Add Queens goal split out tempest plugins"
15:10:31 <gouthamr> some of us have reviewed that goal
15:10:49 <bswartz> yeah they were discussing in the ML that they might drop that goal in favor of a goal that actually benefited end users
15:11:05 <gouthamr> and bswartz has the only -1 on that patch.. when/what is our strategy to talking that
15:11:05 <gouthamr> oh
15:11:19 <bswartz> either way the plugin split will happen eventually
15:11:31 <tbarron> agree
15:11:38 <bswartz> I'm decidedly lukewarm about it
15:11:50 <gouthamr> but my point was something else though.. i wanted to bring up the split to tackle the other problem of pinning tempest
15:12:01 <gouthamr> i'd like to unpin
15:12:04 <gouthamr> (gosh)
15:12:18 <bswartz> well IMO the big benefit of the split will be to make packager's lives less annoying
15:12:49 <vponomaryov> gouthamr: why then you started with link to split plugins out of project repos when your question is about manila-specific thing?
15:12:53 <bswartz> IDK if there's alraedy a manila-tempest-plugin.rpm file out there
15:13:26 <vponomaryov> gouthamr: and we did agree on criteria that should be satisfied before doing unpin
15:13:34 <gouthamr> vponomaryov: because if we wanted to make progress on that, our tempest plugin would not be branched, and we'd have to work with tempest at head
15:13:37 <tbarron> in our distro we already split manila-tempest from other manila packages fwiw
15:13:57 <bswartz> tbarron: where is the rpmspec for that? do you have a link handy?
15:14:09 <tbarron> bswartz: i can chase it down for you
15:14:12 <bswartz> ty
15:14:38 <gouthamr> it's been a while since we were broken with tempest changes... and these days, we're more likely to break because some other plugin in the environment depended on code from tempest at master
15:14:38 <bswartz> okay let me jump back to the topic I remembered
15:15:06 <zhongjun> tbarron: Do you mean manila-tempest-test dir in manila project?
15:15:30 <bswartz> I noticed in the share groups UI, several places in the existing and the new tables we just display UUID for objects, even if they have names
15:15:35 <tbarron> zhongjun: no, we were talking about rpms in downstream distros i think
15:16:00 <tbarron> zhongjun: like in RDO for example
15:16:11 <zhongjun> tbarron: ok, nice to see your link
15:16:18 <bswartz> IMO in a GUI it's always better to show the name instead of the UUID if it exists -- unfortunately many of our REST APIs don't supply the names unless you do individual API calls for each object
15:16:39 <gouthamr> tbarron: ah, so pinning tempest doesn't matter to you/
15:16:56 <tbarron> bswartz: name and uuid to handle duplicate names?
15:17:13 <bswartz> so I'd like to propose an effort to go add names everywhere in the API so the UI can display them efficiently
15:17:29 <tbarron> gouthamr: on the contrary, it's a pain for any distro b/c it will ship with tempest at latest at the time of shipping.
15:17:32 <bswartz> tbarron: the hyperlinks would always be UUID-based, but the display string should be the name only IMO
15:17:46 <raissa> gouthamr: it matters and we're looking forward to unpinning
15:17:51 <tbarron> gouthamr: not with whatever manila was pinned to
15:17:59 <tbarron> raissa++
15:18:04 <gouthamr> tbarron: sure.. that's why i'd like to unpin ourselves right away
15:18:11 <raissa> our rpm is python-manila-tests
15:18:31 <bswartz> raissa: have a link to the rpmspec for it?
15:18:57 <tbarron> everyone meet raissa, an excellent QA/QE now working in manila!
15:19:05 <gouthamr> hey raissa
15:19:09 <bswartz> welcome raissa!
15:19:43 <ganso> raissa: welcome!
15:19:47 <raissa> hi, thanks :)
15:20:00 <raissa> I'm new to manila, so getting the hang of it, let me try to find it
15:20:05 <gouthamr> i think we'd make raissa's work .0001% easy if we stopped relying on tempest off a particular commit..
15:20:06 <zhongjun> raissa: welcome!
15:20:21 <gouthamr> i particularly hated having to qualify manila at liberty
15:20:30 <bswartz> tbarron: do we need to discuss anything related to the ensure_share access rules stuff we were discussion here with the larger group?
15:21:05 <raissa> https://github.com/rdo-packages/manila-distgit/blob/41e84c8cffe4286457718b828d9fe3882a6945be/openstack-manila.spec
15:21:06 <tbarron> bswartz: I think we had general agreement that ensure share should provide a way to push a refresh of access rules to the backend
15:21:23 <tbarron> bswartz: and (1) it should be triggered only by explicit backend signal
15:21:58 <tbarron> (2) exact mechanisms can be worked out in the review of the ensure access stuff - zhongjun has started posting them now
15:22:12 * bswartz head explodes
15:22:23 <bswartz> that's a lot of code in that spec file
15:22:39 <bswartz> I'll have to take a closer look later on
15:22:41 <tbarron> bswartz: fwiw I don't want to plan on that as main solution for our backend failover, but that's evolving
15:22:57 <bswartz> tbarron: okay
15:24:09 <bswartz> alright anything else for today?
15:24:23 <tbarron> zhongjun:
15:24:41 <zhongjun> tbarron:?
15:24:41 <bswartz> I think that's it
15:24:50 <tbarron> zhongjun: would you explain what you are proposing with uwsgi comaparing with what vponomaryov did?
15:24:52 <bswartz> unless tbarron has something
15:25:20 <vponomaryov> tbarron: it is support of 2 different web servers
15:25:25 <zhongjun> that is government requriment
15:25:35 <zhongjun> requirement
15:25:51 <vponomaryov> tbarron: I did only Apache + mod_wsgi support
15:26:10 <zhongjun> tbarron: yes, we need to support both of them
15:26:20 <bswartz> this? https://review.openstack.org/#/c/469389/
15:26:30 <vponomaryov> yes
15:26:40 <tbarron> zhongjun: with yours do we also have the issue that (1) sytemctl commands don't work for api service, and (2)
15:26:54 <tbarron> the old journalctl commands don't work for api service?
15:27:30 <tbarron> vponomaryov: those issues aren't manila specific, they are for all projects that move to apache run api service ...
15:27:53 <bswartz> I see some abuse of the trueorfalse function in this patch
15:28:25 * tbarron doesn't like it that operators are goiing to do 'systemctl restart httpd' and hit all api services and horizon at once.
15:28:28 <zhongjun> tbarron: It is work for api service.
15:28:46 <vponomaryov> tbarron: no one forces you to use web servers
15:28:50 <tbarron> They can send a signal to *one* of the apache processes instead, but there will be mistakes.
15:29:06 <tbarron> vponomaryov: agree, and this isn't a complaint about your work in any way.
15:29:24 <zhongjun> baswartz: this patch still need to update again
15:29:31 <vponomaryov> tbarron: I didn't resist, I meant that old approach is not dropped, why worry?
15:29:34 <bswartz> yeah
15:29:37 <tbarron> I'm just curious whether the alternate web server solution zhongjun is setting up has the same issue.
15:30:00 <tbarron> vponomaryov: I worry b/c I support end users :)
15:30:20 <vponomaryov> tbarron: it is not users problem, it is cloud admin problem )
15:30:31 <bswartz> tbarron: I thought the TC was driving this goal on behalf of real users who wanted to do it with apache/nginx
15:30:37 <tbarron> vponomaryov: I support cloud admins :)
15:30:44 <vponomaryov> ok )
15:31:32 <vponomaryov> tbarron: but don't you have HA for API services?
15:31:35 <tbarron> bswartz: yeah, my worry is that it's driven in large part by a developer goal (which I share) to avoid eventlet
15:32:07 <tbarron> but that cloud operators may be surprised.  If they are the ones asking for this, then great.
15:32:42 <tbarron> vponomaryov: having HA and wanting to exercise it by surprise are different things :)
15:32:52 <bswartz> the justifications I heard were to avoid having 15 different ports open for the different APIs
15:32:55 <tbarron> ok, I'll try out the other web server.
15:33:14 <bswartz> and the improved performance of a real webserver instead of a bunch of different python httpd implementations
15:33:33 <bswartz> I didn't realize that avoidable of eventlet was possible with this scheme but that makes me like it even more
15:33:44 <bswartz> s/avoidable/avoidance/
15:33:59 <tbarron> bswartz: yeah, as a developer I like it.
15:34:34 <tbarron> it's just a pain to have to use different commands to restart services and look at logs for the  api services
15:35:03 <bswartz> tbarron: systemd should make the log handling very easy
15:35:14 * tbarron expressed himself ...
15:35:59 <bswartz> systemd has its detractors but it's the future
15:36:16 * bswartz channels Dr Strangelove
15:36:21 <bswartz> okay now we're really done
15:36:25 <bswartz> thanks all
15:36:28 * jungleboyj is still trying to figure out how to make good use of it.
15:36:34 <bswartz> #endmeeting