15:01:22 <tbarron> #startmeeting manila
15:01:22 <openstack> Meeting started Thu Apr  5 15:01:22 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:23 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:26 <openstack> The meeting name has been set to 'manila'
15:01:32 <xyang> hi
15:01:37 <tbarron> manila courtesy ping:  gouthamr zhongjun xyang markstur vponomaryov cknight toabctl bswartz ganso
15:01:39 <ganso> hello
15:01:41 <zhongjun_> hi
15:01:45 <markstur> hi
15:01:50 <tbarron> markstur!
15:02:02 <tbarron> Hi all!
15:02:10 <tbarron> Let's wait a couple more minutes.
15:02:12 <gouthamr> o/ \o
15:02:17 <gouthamr> :P o/
15:02:31 <vgreen> present and accounted for, sir!
15:02:44 <tbarron> #topic Announcements
15:03:15 <tbarron> Folks please welcome vgreen, vince green,  to the manila community!
15:03:28 <ganso> vgreen: welcome! =)
15:03:42 <gouthamr> welcome vgreen :)
15:03:53 <zhongjun_> vgreen: welcome!
15:03:57 <bswartz> .o/
15:04:02 <gouthamr> you'll find we're so awesome, you'll never do anything else~!
15:04:03 <tbarron> Vince is working with Dustin now as a quality engineer.
15:04:21 <bswartz> I'm on PTO, can't stay for the whole meeting
15:04:35 <tbarron> He has a background with vmware among many other things.
15:04:58 <vgreen> thanks for the welcome, looking forward to contributing!
15:05:01 <tbarron> Dustin is on PTO till Monday so we won't have our usual bug czar agenda item today.
15:05:35 <tbarron> #agenda https://wiki.openstack.org/wiki/Manila/Meetings#Next_meeting
15:06:04 <tbarron> let's do this one first since we want Ben's input
15:06:18 <tbarron> #topic stable policy changes
15:06:31 <tbarron> #link https://review.openstack.org/#/c/548916
15:06:45 <tbarron> #link https://review.openstack.org/#/c/552733/
15:07:03 <tbarron> These TC resolutions have merged.
15:07:31 <bswartz> What do we need to do here?
15:07:32 <tbarron> Please read them so we can discuss and settle - probably next week - how we want to do our stable/branch policy going forwards.
15:08:00 <tbarron> They are leaving a lot of leeway to individual projects as to how long each project wants to maintain stable branches.
15:08:09 <bswartz> It seems like an evolution on the right direction, why do we need to do anything?
15:08:15 <tbarron> And driverfixes branches will go away.
15:08:23 <bswartz> We already have effectively the same thing, unless I'm missing something
15:08:49 <tbarron> We can put other stuff than just driverfixes in the stable/branches and keep them alive longer.
15:08:54 <bswartz> But then the stable branches would just become what the driverfixes branches were, right?
15:08:55 <tbarron> We'll need to test them.
15:09:15 <tbarron> Well, driverfixes were just for *driver* fixes.
15:09:22 <tbarron> We can do other important fixes.
15:09:35 <tbarron> not just security and *critical*
15:09:52 <tbarron> but we shouldn't just gratuitously backport either
15:09:55 <bswartz> So it's even more liberal
15:09:59 <bswartz> I have no problem with that
15:10:05 <tbarron> bswartz: as I read it, yes
15:10:06 <tbarron> but we'
15:10:26 <ganso> tbarron: I am not sure I got the message that the cinder folks were going to do away with the driverfixes branch. If so, it would be more effort to maintain branches older than 18 months
15:10:27 <tbarron> we'll need to keep gate working better than we do sometimes on the stable/branches
15:11:06 <tbarron> ganso: cinder proposal for ocata/driverfixes was blocked b/c of this stuff so
15:11:16 <tbarron> perhaps there is an ongoing discussion
15:11:29 <ganso> tbarron: yes, because driverfixes/ocata would not be older than 18 months
15:11:39 <tbarron> maybe not all the dust has settled yet, but I wanted to give people a heads up
15:11:40 <ganso> tbarron: but driverfixes/newton is
15:11:53 <tbarron> ganso: right, this only goes back to ocata I think
15:12:11 <tbarron> but I think ocata can stay stable longer than 18 months going forwards
15:12:16 <gouthamr> in terms of maintenance, we've so far run tempest tests on stable branches, so we can adopt the policy of not running them when devstack/tempest breaks badly?
15:12:20 <bswartz> I think as a community we've always been willing and wanting to maintain super old branches
15:12:20 <tbarron> please check me on that, I wil re-read myself
15:12:41 <ganso> tbarron: yes, it would fall into extended maintenance. On the bits that allow individual projects to change the rules a bit, I think here we would need to make a decision
15:12:48 <bswartz> The problem in the past was community policy and what infra was willing to take care of
15:13:17 <tbarron> right, and now we have freedom with which will come some additional responsibilty
15:13:38 <tbarron> so everyone please read the resolutions and let's discuss again next week if that's OK
15:13:43 <bswartz> Sorry that wasn't clear -- the manila community is willing to maintain older branches -- the larger community has been the problem in the past
15:13:48 <gouthamr> " Some OpenStack CI testing *may* be available via `Zuul drivers` "
15:14:06 <tbarron> bswartz: that's what I understood you to be saying
15:14:34 <tbarron> #topic failing jobs in gate
15:14:49 <tbarron> #link https://review.openstack.org/#/c/557062/
15:14:59 <tbarron> horizon borked us
15:15:21 <tbarron> or if we ask horizon, we were using hacked up code to access internal interfaces
15:15:33 <tbarron> in any case we need to get manila ui fixed
15:15:48 <tbarron> vkmc is working on this one with akhihiro from horizon
15:16:33 <tbarron> But additional eyes on this review would be appreciated.
15:16:41 <tbarron> There are still some outstandiing issues.
15:17:15 <tbarron> Otherwise, I'm still looking for people who know the gluster back end so we can get the glusternfs job working again.
15:17:39 <vkmc> yeah... this is perhaps just the tip of the iceberg though... we may need to give some love to the ui
15:18:00 <tbarron> I know *some* of why it's failing, but if you know anyone using gluster with manila (like China Telecom) and they'd like to help, please introduce me.
15:18:09 <tbarron> vkmc: +1000
15:18:30 <tbarron> so django + manila-interest as well
15:19:00 <tbarron> Otherwise, we have some third party CI that always fail too :)
15:19:23 <tbarron> I want to float the idea of making a periodic nightly job that is just a null-change
15:19:36 <tbarron> in manila and in manila-ui (once the latter is fixed)
15:20:08 <gouthamr> tbarron: periodic upstream job?
15:20:09 <tbarron> So we can make reports that show which jobs are running, which are skipping, and which are failing on even null changes.
15:20:13 <tbarron> gouthamr: yes
15:20:40 <gouthamr> tbarron: awesome.. that'd be a great addition. I can help
15:20:42 <tbarron> Nova has proposed adding a LOG.warning in back ends that aren't tested or that always fail.
15:21:08 <tbarron> So think whether that would be an appropriate approach.
15:21:16 <tbarron> We don't need to decide today.
15:21:39 <tbarron> Any more on this topic?
15:22:06 <tbarron> #topic spec reviews
15:22:20 <tbarron> #link https://etherpad.openstack.org/p/manila-rocky-specs
15:22:34 <tbarron> We have three specs open and two weeks till freeze.
15:23:01 <tbarron> I'm the only core who has reviewed
15:23:07 <tbarron> #link https://review.openstack.org/#/c/553662/
15:23:32 <tbarron> I just put a +2 on it, partly to force the "backwards compatability" issue
15:24:03 <tbarron> this is a proposal to do json schema validation for manila apis the way it is done for other projects
15:24:18 <tbarron> I think it's a great idea but as you'll see in the spec we are
15:24:33 <tbarron> not returning proper responses in some circumstances today.
15:24:50 <tbarron> My POV is that in these cases we are in error and these are bugs so
15:24:59 <tbarron> there is no backwards compatability issue.
15:25:17 <tbarron> But we need other reviewers, and especially other cores to review and weigh in.
15:25:33 <tbarron> I don't want to have a last minute argument about this.
15:25:41 <gouthamr> +1, i agree with you - will complete my review today
15:26:09 <tbarron> So ganso bswartz xyang markstur toabctl please look at this one soon
15:26:12 <tbarron> gouthamr: thanks
15:26:19 <tbarron> did I forget anyone to nag :) ?
15:26:39 <tbarron> #link https://review.openstack.org/#/c/552935
15:27:12 <tbarron> bswartz had to run off to the zoo with his family but at PTL he strongly endorsed this idea and said he'd
15:27:26 <tbarron> help shepherd it through so I will nag him when he gets back :)
15:27:30 <zhongjun_> tbarron: Do you know who will going to implement this spec?
15:27:51 <tbarron> zhongjun_ good question, I take it you aren't planning on doing that this cycle?
15:28:08 <tbarron> zhongjun_: or do you mean the jquery validation?
15:28:47 <tbarron> zhongjun_: for the latter I was *assuming* the author but please do ask that in review if it doesn't explicitly state that :)
15:29:21 <zhongjun_> Oh, I mean the API Jason spec
15:29:41 <tbarron> zhongjun_: right, and you have a Primary assignee section in your spec.
15:30:04 <tbarron> zhongjun_: so it would be appropriate to ask for such a section in the jquery validation spec
15:31:47 <zhongjun_> I will implement my spec in this cycle
15:31:53 <tbarron> So my sense is that the api access rule spec is coming along pretty well.  Anyone have reservations about it at this point?
15:31:57 <tbarron> zhongjun_: :)
15:32:32 <tbarron> Of course still put remarks in review still, I'm just checking on progress.
15:32:57 <tbarron> OK, how about the metadata for access rule spec?
15:33:09 <tbarron> #link https://review.openstack.org/#/c/551106/
15:33:41 <gouthamr> I still don't believe that these would be /action APIs on the share resource
15:34:02 <gouthamr> i'll respond to zhongjun_'s responses on my last review
15:34:12 <zhongjun_> Thanks
15:34:33 <tbarron> gouthamr: please do, let's advance any serious disagreements ASAP so we're not tryinng to settle them at the last minute
15:34:41 <gouthamr> +1
15:34:44 <zhongjun_> Because we don’t have access resource
15:35:06 <tbarron> It would be great to have all serious issues resolved by this time next week so that
15:35:29 <tbarron> the final week can be mostly a matter of cleanup, word usage fixes, etc.
15:35:43 <tbarron> Anything else on specs today?
15:35:51 <gouthamr> zhongjun_: i'll make a suggestion in the review
15:36:11 <zhongjun_> gouthamr: good
15:36:34 <tbarron> #topic Open Discussion
15:36:45 <gouthamr> i've an announcement
15:36:59 <tbarron> ?
15:37:13 * gouthamr that always sounds dramatic
15:37:24 <vgreen> lol
15:37:33 <gouthamr> i've changed jobs
15:37:46 <tbarron> well, you got married
15:37:54 <ganso> lol
15:37:57 <tbarron> so now you have a new reporting relationship
15:38:09 <gouthamr> and unlike many such announcements on this channel before, this actually means I'll be doing more manila work :D
15:38:10 <markstur> been a big year for Goutham
15:38:49 <gouthamr> haha, thanks guys. you're the best to see me through this/ese big transition/s
15:39:03 <zhongjun_> lol
15:39:34 <vkmc> gouthamr, \o/
15:39:43 <gouthamr> i now work at Red Hat, and so the downside is, can't +2/+W anything tbarron +2s
15:39:48 <gouthamr> daarn
15:40:00 <tbarron> he always -1ed me anyways
15:40:02 <markstur> the upside is the fedora?
15:40:18 <tbarron> but I'm really happy that we've figured a way to keep goutham working on manila!
15:40:21 <gouthamr> hahaha yes.. :)
15:41:20 * tbarron shovels even more work his way
15:42:08 <tbarron> Anything else for today?
15:42:26 <tbarron> three
15:42:32 <gouthamr> two
15:42:38 <tbarron> you can't do that
15:42:40 <tbarron> two
15:42:46 <ganso> lol
15:42:49 <gouthamr> haha
15:42:52 <tbarron> one
15:43:02 <tbarron> OK thanks everybody!
15:43:09 <gouthamr> thank you \o
15:43:13 <tbarron> See you in #openstack-manila !!
15:43:28 <tbarron> #endmeeting