15:00:24 <bswartz> #startmeeting manila
15:00:24 <openstack> Meeting started Thu Jan 11 15:00:24 2018 UTC and is due to finish in 60 minutes.  The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:26 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:29 <openstack> The meeting name has been set to 'manila'
15:00:35 <bswartz> hello all
15:00:40 <xyang> hi
15:00:41 <zhongjun> Hi
15:00:41 <ganso> hello
15:00:42 <tbarron> hi
15:00:48 <dustins> heya \o
15:00:51 <vkmc> o/
15:01:32 <bswartz> courtesy ping: gouthamr toabctl markstur vponomaryov cknight
15:01:56 <bswartz> #topic announcements
15:01:58 <gouthamr> hi o/
15:02:15 <bswartz> We passed feature proposal freeze on Monday
15:03:00 <bswartz> I didn't see anything come in right around the deadline, but we should keep any eye out for any new features being proposed
15:03:42 <bswartz> Features that missed the deadline get an automatic -2 unless an exception is granted, and there haven't been any requests made
15:04:02 <bswartz> We're now 2 weeks from the actual feature freeze
15:04:18 <bswartz> #link https://releases.openstack.org/queens/schedule.html
15:05:01 <bswartz> There aren't any new agenda items proposed for this week, so this might be a short meeting
15:05:14 <bswartz> Does anyone know why the gate is so slow?
15:05:43 <bswartz> tbarron: what are you debugging with your DNM change?
15:06:11 <tbarron> someone claimed gate jobs were failing so I wanted to see if there's an issue.
15:06:17 <tbarron> there isn't, not not any more
15:06:33 <tbarron> or not at the moment :D
15:06:43 <bswartz> Oh I see it reported back
15:07:01 <tbarron> I think it's the person who is doing the EMC ipv6 patch
15:07:03 <bswartz> There's a change in the queue that's been stuck there for >5 hours
15:07:11 <bswartz> But that might be something random
15:07:20 <tbarron> Yeah, the queue seems quite slow.
15:07:48 <tbarron> Also, I've noticed that if you have a Depends-on: chgid in your cmt msg and
15:08:00 <bswartz> Something to remember for anyone working on getting anything merged before the deadline -- the gate often gets really hard to deal with on the final days before a reeze
15:08:05 <bswartz> freeze even
15:08:12 <tbarron> that change has already merged, then your review doesn't run
15:08:39 <bswartz> tbarron: you have an example of that?
15:08:53 <ganso> tbarron: IIRC that has worked before, it means it is broken now, correct?
15:08:55 <bswartz> Sometimes there are more than 1 change with the same ID
15:08:55 <tbarron> not in hand, maybe I can chase it down.
15:09:14 <toabctl> hi
15:09:36 <tbarron> For now just treat my remark as an anecdote.  If your job isn't running, see if that description fits.
15:09:50 <bswartz> k
15:10:12 <tbarron> I *think* I saw that twice and removing the depends-on got the machinery going.
15:10:48 <tbarron> ganso: if zuul has a backwards compatability contract with the users :)
15:10:58 <bswartz> Well it's safe to remove the depends-on if the other change has already merged in any case
15:11:07 <tbarron> right
15:11:22 <bswartz> #topic Let's go over new bugs
15:11:35 <bswartz> dustins: do you have anything to cover today?
15:11:51 <dustins> bswartz: Yeah, a short list this week
15:12:02 <dustins> https://bugs.launchpad.net/manila/+bug/1742027
15:12:03 <openstack> Launchpad bug 1742027 in Manila " DocImpact: Add quotas per share type" [Undecided,New]
15:12:03 <bswartz> #link https://etherpad.openstack.org/p/manila-bug-triage-pad
15:12:17 <dustins> Easy "do we have docs for this?" bug
15:12:19 <bswartz> #link https://bugs.launchpad.net/manila/+bug/1742027
15:12:44 <bswartz> I thought we covered this one in a previous meeting
15:12:57 <bswartz> Or am I remembering a different but similar bug?
15:13:01 <zhongjun> Yeah, lijunbo added it
15:13:01 <tbarron> dustin there's a review up for that
15:13:13 <dustins> bswartz: Similar but different
15:13:39 <dustins> tbarron: I figured there was, just wanted to be sure that folks were aware
15:14:33 <tbarron> zhongjun: did that one already merge?  /me is having trouble tracking it down
15:14:49 <bswartz> Can we link to the docs change in the bug so we know it's dealt with?
15:15:44 <zhongjun> tbarron: It might be yes
15:16:14 <tbarron> https://review.openstack.org/#/c/530184/
15:16:19 <tbarron> ^^^ merged
15:16:57 <bswartz> I updated the bug
15:17:02 <tbarron> closes this bug though: https://bugs.launchpad.net/manila/+bug/1705540
15:17:04 <openstack> Launchpad bug 1705540 in Manila " Add quotas per share type" [Undecided,Fix released] - Assigned to junboli (junboli)
15:17:06 <bswartz> Thanks
15:17:18 <zhongjun> Thanks,
15:17:23 <bswartz> Probably just a duplicate but
15:17:26 <tbarron> ah, that was the functional code bug, not the doc-impact bug
15:17:27 <bswartz> bug
15:17:39 <bswartz> Next up?
15:18:38 <dustins> #link https://bugs.launchpad.net/manila/+bug/1742430
15:18:39 <openstack> Launchpad bug 1742430 in Manila "manila_tempest_test create_share fails because a share type not create or define in advance" [Undecided,New] - Assigned to shuaili.wang (shuaili.wang)
15:19:01 <tbarron> yeah, I don't understand this one.
15:19:04 <tbarron> Does anyone?
15:19:18 <dustins> I think this goes back to the "you need to create a default share type before doing anything" thing, yeah?
15:19:25 <tbarron> Right.
15:19:27 <bswartz> Yeah but devstack should do that
15:19:32 <tbarron> But what is the bug?
15:19:45 <bswartz> Maybe someone is running tempest on a cloud that somehow managed to not have any share types?
15:19:56 <tbarron> That may well be.
15:20:03 <tbarron> People run tempest outside devstack.
15:20:13 <bswartz> In that case, this is working as designed
15:20:18 <bswartz> The problem is most likely a bad error message
15:20:23 <tbarron> For example, we have that issue in tripleo, where the hook to create the share type got broken.
15:20:34 <tbarron> So we're fixing that there.
15:20:46 <bswartz> We could make it more obvious to the user that they really need to have a share type
15:20:57 <tbarron> But it has been proposed that tempest itself would create the default share type, maybe that's what is wanted here?
15:21:08 <bswartz> Well
15:21:20 <dustins> Or at least create a share type for it's usage
15:21:26 <bswartz> It's my opinion that tempest should create everything it needs
15:21:48 <bswartz> Tempest shouldn't make use of the default share type anywhere except tests designed to specific test how the default share type works
15:21:49 <tbarron> That would be a reasonable thing to do, if someone wants to build it.
15:22:10 <tbarron> bswartz: but that's not the way it works today, right?
15:22:15 <bswartz> So any test group that creates shares should have a share type creation in the setup
15:22:27 <bswartz> For historical reasons, no
15:23:00 <tbarron> so maybe that's what shuali wants to do, but right now there's a one line patch associated with this bug.
15:23:17 <bswartz> Creating special test-group-specific share types would eliminate a possible source of errors in testing
15:23:18 <tbarron> if the one line can achieve that goal then we really need to get this person contributing more!!!
15:23:28 <ganso> we could include it in the setup of the base class, and any test class that needs to use a special share type can override that
15:23:45 <bswartz> Well we'd have to be careful to not lose coverage of the default share type feature
15:23:56 <tbarron> Does anyone know shuali and could reach out to him / her ?
15:24:09 <bswartz> Right now default share types might only get tested by virtue of the fact that other tests happen to use them
15:25:23 <tbarron> There's a similarly motivated review here: https://review.openstack.org/#/c/519040/
15:26:00 <tbarron> In both cases the basic idea and motivation may be good but the review mechanism isn't facilitating good communication.
15:26:18 <bswartz> That seems to be aimed at a ceph specific problem
15:26:32 <bswartz> But if it can be generalized, it would be helpful to merge it
15:26:35 <tbarron> bswartz: maybe I put the wrong review in, sec
15:26:54 <tbarron> Nah, that's it.
15:27:14 <bswartz> It's unclear why ceph needs special treatment
15:27:15 <tbarron> I think it went towards ceph b/c I said "but what about other back ends and mentioned ceph"
15:27:38 <tbarron> Ac chalenge is that the default share type will have different extra specs depending on back end capabilities.
15:27:48 <tbarron> devstack plugin handles this today.
15:28:27 <tbarron> If we build the capability into tempest itself then we need to key off the capabilities/settings fed to tempest to determine what default share type extra specs will be for
15:28:31 <tbarron> any particular test run.
15:28:56 <ganso> tbarron: there is already such option
15:28:57 <bswartz> Well any changes to how the default share type is created might expose problems in tempest
15:29:00 <ganso> tbarron: LVM driver uses it
15:29:11 <ganso> tbarron: it creates the default share type with the specified capabilities
15:29:21 <bswartz> All the more reason to update tempest to create share types as needed everywhere except tests specifically around the default share type
15:29:33 <tbarron> ganso: tempest does this for lvm?
15:29:40 <ganso> tbarron: yes
15:30:00 <ganso> bswartz: yes, some stuff is coded the wrong way, like
15:30:16 <tbarron> ganso: bswartz: so it sounds like we're saying tempest should extend this capability for other back ends.
15:30:30 <ganso> bswartz: tests assume the default share type has the capability, and tries to use it. If the default share type custom extra spec option isn't used in devstack, it will fail
15:30:51 <bswartz> what I'm saying is that, for example, if tempest is testing NFS share, it should create a share type that will work for NFS, similarly CIFS or Ceph
15:30:55 <ganso> bswartz: the correct way would be that the test should create the share type with the required capability, and then use it, instead of the default share type
15:31:05 <gouthamr> wait, tempest doesn't care about backends :P
15:31:16 <tbarron> bswartz: yeah, I was talking past that point but I agree.
15:31:22 <gouthamr> ganso: where does it create one, for LVM?
15:31:23 <ganso> tbarron: no, that's not what I meant, I meant that devstack plugin sets this option for LVM driver
15:31:24 <bswartz> The default share type merely needs to exist and allow a share to be created -- tempest shouldn't care much beyond that
15:31:37 <ganso> tbarron: other job configs can set it up as needed as well
15:31:45 <gouthamr> ah, anyone can take advantage of that.. DEFAULT_SHARE_TYPE_EXTRA_SPECS is the option iirc
15:31:59 <bswartz> The real value of the default share type is for developers who are running devstack and want to create shares quickly and easily
15:32:07 <ganso> gouthamr: exactly
15:32:19 <gouthamr> s/DEFAULT_SHARE_TYPE_EXTRA_SPECS/MANILA_DEFAULT_SHARE_TYPE_EXTRA_SPECS
15:32:34 <ganso> gouthamr: that's how it is done today, but shouldn't it be done per test?
15:32:37 <gouthamr> the local.conf option ^
15:32:41 <bswartz> But actual users will never see any of that benefit, they'll rely on their distros to setup something sensible
15:33:05 <gouthamr> ganso: agree tests should never rely on the default share type
15:33:09 <ganso> bswartz: yes, having that in devstack only makes things harder when running on production clouds
15:33:42 <bswartz> okay so do we have a conclusion about this    bug?
15:34:00 <bswartz> shuaili.wang will fix it?
15:34:01 <ganso> bswartz: the conclusion isn't really a one-liner, it is a refactor...
15:34:05 <tbarron> ganso: are you saying DEFAULT_SHARE_TYPE_EXTRA_SPECS is a tempest option or a devstack option?  Just want to clarify.
15:34:13 <ganso> tbarron: devstack option
15:34:20 <tbarron> ganso: ok, that's different.
15:34:56 <ganso> tbarron: for the change you linked, it seems like that particular problem could be solved by setting the devstack option
15:35:13 <ganso> tbarron: but the person seems to be trying to implement what we are discussing here
15:35:31 <tbarron> ganso: I think the point is they want it to work w/o devstack and its default share type hooks.
15:35:54 <ganso> tbarron: yes, then the refactor is needed
15:36:04 <gouthamr> tbarron: i feel they're fixing something with their third party CI
15:36:10 <tbarron> so they are trying to build it into tempest, e.g. tempest base class.
15:36:13 <ganso> gouthamr: I got that impression too
15:36:18 <gouthamr> the fix is proposed to the tests
15:36:20 <gouthamr> #link https://review.openstack.org/#/c/532713/1/manila_tempest_tests/tests/api/base.py
15:36:43 <tbarron> right,
15:36:46 <gouthamr> so, likely this is their CI missing MANILA_DEFAULT_SHARE_TYPE_EXTRA_SPECS
15:36:59 <tbarron> put default share creation in tempest rather than in devstack
15:37:22 <bswartz> gouthamr: do you want to add some notes to the LP bug to help shuaili.wang?
15:37:23 <tbarron> dsariel asked me to look at 51940 b/c he runs tempes w/o devstack
15:37:38 <tbarron> 519040
15:37:58 <zhongjun> shualli.wang’s changing will cause another problem, we could add more commitments in this patch
15:38:13 <gouthamr> bswartz: sure, i'll ask these questions there
15:38:16 <zhongjun> Comments
15:38:43 <tbarron> zhongjun: comments without commitments are often a good idea :D
15:38:56 <ganso> tbarron: ROFL
15:39:09 <bswartz> dustins: is that the last one you want to cover today?
15:39:22 <dustins> bswartz: Yup, that's all for today
15:39:26 <bswartz> #topic open discussion
15:39:28 <zhongjun> :) type error
15:39:41 <bswartz> okay anything else for this week?
15:40:11 <tbarron> reminder on PTG etherpad?
15:40:34 <ganso> #link https://etherpad.openstack.org/p/manila-rocky-ptg
15:40:36 <bswartz> #link https://etherpad.openstack.org/p/manila-rocky-ptg
15:40:59 <tbarron> thanks
15:41:21 <ganso> zhongjun: are you going to participate in the PTG?
15:41:23 <xyang> bswartz: are the dates determined yet?
15:41:25 <tbarron> Please put down ideas there,
15:41:33 <bswartz> We're still quite a ways away from the PTG, but those who are going in person should hurry up and arrange travel
15:41:34 <zhongjun> I am not sure now
15:42:00 <bswartz> xyang: I have to confirm with the foundation about the schedule
15:42:05 <xyang> ok
15:42:10 <bswartz> I've asked for Tuesday+Friday
15:42:40 <bswartz> We have some time to get our agenda/topics sorted out, but it's never too early to start throwing ideas on the etherpad
15:42:47 <xyang> are the first couple of days still for cross-project things?
15:43:22 <bswartz> xyang: yes I think they plan to follow the pattern of Denver, but possibly with some more fine-grained scheduling of the first 2 days, to avoid having rooms that sit empty 90% of the time
15:43:42 <xyang> ok
15:44:09 <bswartz> okay that should be all for today
15:44:16 <bswartz> thanks all
15:44:27 <bswartz> #endmeeting