15:01:08 <bswartz> #startmeeting manila
15:01:09 <openstack> Meeting started Thu Dec  1 15:01:08 2016 UTC and is due to finish in 60 minutes.  The chair is bswartz. 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:13 <openstack> The meeting name has been set to 'manila'
15:01:18 <bswartz> hello all
15:01:22 <vponomaryov> hello
15:01:22 <ganso> hello
15:01:32 <gouthamr> hello  o/
15:02:04 <bswartz> hmm only 4 people today?
15:02:06 <tbarron> hi
15:02:12 <ganso> 5
15:02:17 <tbarron> 4.5
15:02:23 <bswartz> that's quorum at least
15:02:28 <dustins> \o
15:02:40 * bswartz wonders if there's a holiday somewhere he doesn't know about
15:02:45 <ganso> tbarron: lol who's half a person?
15:03:04 <vkmc> o/
15:03:09 <tbarron> ganso: me
15:03:09 <vkmc> 6
15:03:11 <tbarron> today
15:03:26 <bswartz> let's get started though we have a lot to discuss
15:03:32 <bswartz> no announcements today
15:03:36 <panatl> o/
15:03:39 <bswartz> #agenda https://wiki.openstack.org/wiki/Manila/Meetings
15:03:45 <bswartz> #topic Discussion about driver docs in devref
15:04:06 <markstur> hi
15:04:10 <bswartz> ganso: I think you wanted to cover this 2 weeks ago and we didn't get to it
15:04:16 <ganso> bswartz: yes
15:04:25 <ganso> the discussion about this started regarding this: https://review.openstack.org/375647
15:04:39 <ganso> several drivers have configuration parameters and instructions in the devref
15:05:00 <gouthamr> from the incubation days
15:05:01 <gouthamr> :P
15:05:28 <ganso> in the past we had agreed that we could use the devref for this kind of information before moving to openstack-manuals or somewhere else
15:05:28 <bswartz> so we discussed this in juno IIRC
15:05:45 <ganso> bswartz: I recall a more recent discussion
15:05:55 <bswartz> errr kilo sorry
15:06:01 <bswartz> it was more than a year ago
15:06:03 <bswartz> everything was moved to openstack-manuals long ago though
15:06:08 <gouthamr> yeah, when we were merging the documenting instuctions for documentation patch
15:06:16 <bswartz> the cleanup of the devref is what didn't happen
15:06:26 <ganso> bswartz: that had the argument that we could use this repo to review documents with the manila team, which would be a more technical review
15:06:57 <bswartz> ganso: what kind of technical review are you looking for of your driver config info?
15:07:05 <vponomaryov> agree, manila team will not review docs from other repo in most cases
15:07:32 <ganso> bswartz: I am really not looking for much... as most of the information that is there is related to the driver or the vendor
15:07:33 <bswartz> HDS people would understand the driver best -- I'm not sure the manila team can add much value when it comes to reviewing a driver config reference
15:07:39 <tbarron> bswartz: ganso vponomaryov that's my only concern, we need to somehow look at those doc reviews
15:07:50 <ganso> tbarron: +1
15:07:52 <ganso> vponomaryov: +1
15:08:18 <bswartz> I'm still not understanding why we care
15:08:22 <ganso> I remember having this exact discussion in the past, that we, the manila team, prefer to look at the document, and we could use the devref for that
15:08:39 <bswartz> the point of config references for drivers is to be consume by deployers, not develoeprs
15:09:12 <vponomaryov> bswartz: developers will control technical details
15:09:18 <tbarron> bswartz: true but won't it come back to us if it's garbage?
15:09:27 <bswartz> tbarron: I don't see how
15:09:29 <markstur> part of it is automatically generated from the code.  That doesnt' need doc review. Just code review.
15:09:31 <gouthamr> configuration reference is release versioned.. devref isn't.. i agree we shouldn't merge things in the devref
15:09:59 <ganso> I understand that, in the past, the devref was used for your "documentation box" and we would put everything in there, and when we look at it that it should contain only info for developers, not admins, or operators, or users, we actually find out that it contains a lot of stuff not targeted specifically to developers
15:10:02 <tbarron> bswartz: at least for first party drivers?
15:10:25 <tbarron> we get questions all the time in channel from people who can't deploy after reading the doc
15:10:27 <bswartz> tbarron: that's a better point, but we still owe it to end users to document those driers in the proper place
15:10:49 <bswartz> and if we're going to have documentation in the config ref where it belongs, then why duplicate it in the devref?
15:11:30 <tbarron> I agree with that point, duplicating isn't probably the best way to get the config doc correct and reviewed, but removiing the duplication leaves a gap.
15:11:49 <ganso> bswartz: so the manila team could look at it, I believe that otherwise the doc patch proposed wouldn't have manila review suggestions to improve
15:12:01 <bswartz> to address the issue of reviews, I think it may be possible (in the future if not today) to actually host portion of the config ref, api ref, etc in our own repo, even though it gets published as part of those guides
15:12:10 <gouthamr> ganso: why not add "manila-core" to the review/
15:12:35 <ganso> gouthamr: that is an alternative that we could agree to. I am hoping we reach an agreement about this
15:12:52 <bswartz> honestly I don't really care what repo it's in, or even who reviews it -- what matters is how it's published and what version control exists
15:13:12 <gouthamr> imo, when new users google things and end up in the devref, that would be pretty bad
15:13:22 <gouthamr> the devref isn't versioned, except on github
15:13:47 <bswartz> users need to be able to find this stuff where they expect it, and it needs to be properly versioned so as drivers evolve over time correct documentation can exist for every version
15:14:27 <tbarron> +1
15:14:32 <bswartz> right now the only way to achieve that is to put these docs in the config ref part of openstack manuals
15:14:50 <bswartz> if we're having problems getting reviews done that's a separate issue we can tackle
15:15:59 <ganso> if we are not going to have this kind of documents in the devref, then it should be cleaned up, else it defeats the purpose of the devref and other repos... it will be duplicated and one will be outdated. The way I see, as I have reviewed other driver docs in the devref, no driver doc should be in the devref
15:16:17 <bswartz> so I know about the effort to move the source code of the API ref into the various projects
15:16:20 <ganso> every driver doc that currently is in the devref is usage / configuration instructions
15:16:32 <bswartz> gouthamr: do you know if a similar movement exists with config refs?
15:16:56 <bswartz> ganso: I wholeheartedly agree about cleaning up the devref
15:17:07 <bswartz> ganso: are you volunteering to push a patch?
15:17:18 <ganso> bswartz: I can push a patch to wipe them out
15:17:29 <bswartz> ganso: thank you
15:17:30 <gouthamr> bswartz: i know they want to move the user guide, not sure about the config ref
15:17:57 <tbarron> do we know that everything currently in the devref is already in config, user guide, deployment guide, etc?
15:18:02 <gouthamr> ganso bswartz: can we audit what's there.. maybe some of the instructions have devstack related documentation?
15:18:05 <bswartz> gouthamr: it makes sense to me to use a plugin architecture for docs
15:18:05 <vkmc> devref is more for developers to know how to contribute to the project, this seems more close to the configuration ref
15:18:11 <ganso> bswartz: but if anybody says anything about "let's not wipe out the ones that not in other refs yet", then we should decide about this now
15:18:43 <tbarron> ganso: yeah, don't we want to make sure that info isn't just obliterated?
15:18:49 <bswartz> ganso: what shoudl really be audited is the config ref itself -- if any drivers don't have complete config refs then that's a problem
15:19:14 <ganso> tbarron, bswartz: that is most likely the case
15:19:14 <bswartz> deletion of files from the devref doesn't really destroy information -- it's there in the history for people to move it to config ref
15:19:37 <gouthamr> do we want to retain first party driver information here though? that's mighty helpful for new developers
15:19:46 <bswartz> tbarron: with git nothing is ever obliterated
15:20:12 <ganso> gouthamr: shouldn't there be config refs for the first party drivers?
15:20:22 <tbarron> bswartz: true, so for third party drivers I guess we can say that it'
15:20:29 <bswartz> gouthamr: the devref should include info on how to setup the first party drivers, and it should refer to the config refs for those drivers where apropriate
15:20:31 <tbarron> it's vendor responsibility
15:20:42 <tbarron> to ensure that end users experience doesn't suck
15:21:19 <bswartz> tbarron: +1
15:21:29 <tbarron> bswartz: gouthamr glusterfs, cephfs are really open source community drivers, not vendor drivers
15:21:42 <ganso> bswartz: referring is ok, hosting in the devref should not be ok
15:21:53 <gouthamr> tbarron: yes.. i'd love to see instructions on how to set them up on devstack :)
15:22:02 <bswartz> the manila community has enough to worry about without adding quality of 3rd party driver documentation to the list
15:22:07 <tbarron> gouthamr: +1, will work on it
15:22:23 <bswartz> tbarron: yes for first party drivers the community owns the documentation
15:22:41 <gouthamr> tbarron: thank you..
15:22:55 <tbarron> gouthamr: it's just like generic, with one more plugin :)
15:22:57 <bswartz> ganso: sounds like we're all in agreement here about the path forward
15:23:04 <ganso> bswartz: ok
15:23:05 <bswartz> can we move on?
15:23:11 <ganso> bswartz: will have the patch up today
15:23:25 <ganso> bswartz: yes
15:23:25 <gouthamr> ^ chief obliterator
15:23:30 <ganso> gouthamr: lol
15:23:38 <bswartz> #agreed driver config ref docs should not be in the devref anymore and will be deleted -- they belong in the config ref
15:23:47 <vkmc> +1
15:23:48 <bswartz> #topic Specs implementation status
15:24:00 <bswartz> #link https://github.com/openstack/manila-specs/tree/master/specs/ocata
15:24:24 <bswartz> we've got 9 merged specs for ocata (I'll get to the unmerged ones later)
15:24:52 <bswartz> I'd like to quickly review these and make sure implementation is coming along
15:25:08 <bswartz> so not everything lands at the last minute
15:25:26 <bswartz> first up is create-share-from-snapshot-extra-spec
15:25:32 <bswartz> cknight: ping
15:25:36 <gouthamr> the patch's ready for review
15:25:40 <cknight> bswartz: pong
15:25:45 <gouthamr> a dependent patch merged today
15:25:54 <cknight> bswartz: This one has been ready for a while.
15:26:11 <bswartz> so we just need 2 reviewers to take a look at this patch and merge it
15:26:17 <gouthamr> #link https://review.openstack.org/#/c/356682/
15:26:28 <bswartz> do I need to create an etherpad to get reviewers to sign u?
15:26:34 <cknight> gouthamr: thanks for rebasing it
15:26:37 <bswartz> s/u/up/
15:26:45 <cknight> bswartz: that worked well last time, IMO
15:27:22 <ganso> cknight, gouthamr: I see some CIs not green on that patch
15:27:25 <bswartz> cknight I think you mentioned that vponomaryov should be one of the reviewers on this due to his past experience with the feature
15:27:40 <cknight> bswartz: ideally, yes
15:27:42 <bswartz> ganso: are those CIs normally green?
15:27:54 <vponomaryov> ganso: don't worry, it is normal situation )
15:28:09 <bswartz> some CIs are just red due to their own issues
15:28:10 <ganso> bswartz: they have been green in some of the latest patches
15:28:19 <vponomaryov> ganco: coincedence
15:28:19 <bswartz> ganso: it's worth investigated how they failed then
15:28:34 <bswartz> but like vponomaryov says it's probably just random
15:28:48 <bswartz> okay next up is manila-share-revert-to-snapshot
15:28:55 <bswartz> cknight: is this one mergeable too?
15:28:56 <ganso> bswartz: yes, I do believe it is worth considering the change and the amount of red CIs
15:29:02 <cknight> ganso: It's possible vendor CIs will need an adjustment
15:29:12 <cknight> ganso: due to the new extra spec
15:29:16 <gouthamr> hopefully not
15:29:22 <tbarron> +1 on the etherpad, focuses the mind
15:29:22 <gouthamr> if yes, then we messed up something
15:29:25 <cknight> ganso: but I can't fix that in the patch
15:29:29 <ganso> cknight: if that is the case, I suppose that should be included in the patch, correct?
15:29:35 <vponomaryov> ganso: we should just know what can be affected by patch and what cannot
15:29:51 <cknight> ganso: no, vendor CI configs aren't in the patch
15:30:02 <cknight> ganso: I fixed the 1st party ones in the patch
15:30:17 <bswartz> #link https://etherpad.openstack.org/p/manila-ocata-code-review-focus
15:31:21 <cknight> bswartz: regarding revert-to-snapshot, it's close, just needs a rebase, but I'd rather focus on create-share-from-snapshot first.
15:31:35 <vponomaryov> +1
15:32:34 <bswartz> okay what about mountable-snapshots
15:32:55 <bswartz> tpsilva: is the patch for this ready?
15:32:57 <ganso> bswartz, cknight, vponomaryov: regarding a change breaking third-party CIs, is this going to be ok to break 3rd party CIs for share groups as well?
15:33:25 <bswartz> ganso: I'm a bit confused why the CI should break
15:33:35 <tpsilva> tpsilva: it'll probably be ready next week
15:33:45 <tpsilva> bswartz: ^
15:34:14 <bswartz> it seems to me that we should be able to make changes without breaking CIs
15:34:17 <ganso> bswartz: I don't know the reason, but if it does, then it is fair to assume something needs to be done
15:34:38 <ganso> bswartz: in order to not break the CIs
15:34:40 <bswartz> if new tests are added they should default to skipping until the 3rd party CI can pass them
15:34:46 <tpsilva> I'm also testing/reviewing gouthamr/cknight patch
15:34:52 <bswartz> if existing tests are passing we should not break them
15:35:33 <bswartz> i haven't seen any of the huawei folks yet today
15:36:01 <bswartz> tommylikehu? zhongjun?
15:37:09 <bswartz> okay next up should be share-groups
15:37:32 <bswartz> vponomaryov: where is the implementation on this?
15:37:40 <vponomaryov> bswartz: where it was
15:38:18 <bswartz> is part of it ready for review ?
15:39:09 <vponomaryov> bswartz: I haven't uploaded any changes yet
15:39:21 <bswartz> okay so not ready for review yet
15:39:35 <bswartz> ocata-migration-improvements
15:39:49 <ganso> code is almost ready
15:39:49 <bswartz> ganso: how is this patch coming?
15:40:05 <ganso> it has got that spec-update thingy we talked about
15:40:11 <bswartz> ganso: like you expect to be done next week?
15:40:20 <bswartz> or later
15:40:20 <ganso> bswartz: yes
15:40:28 <ganso> bswartz: up to next week
15:41:15 <bswartz> stochastic-weighing-scheduler
15:41:19 <bswartz> ^ this one is me
15:41:31 <bswartz> I'm going to port the code over from cinder at some point
15:41:39 <bswartz> it should be a pretty easy copy/paste
15:41:48 <bswartz> but I consider it a low priority
15:41:52 <gouthamr> yeah, just strip out taskflow
15:41:59 <bswartz> :-x
15:42:00 * gouthamr kidding
15:42:27 <ganso> gouthamr: burn it with fire?
15:42:37 <bswartz> can anyone speak about the 3 specs from the huawei team?
15:42:49 <bswartz> add-db-manage-purge add-share-type-filter-to-get-pools support-quota-usage-in-detail
15:43:07 <gouthamr> ganso: :D i just like the reaction when that's mentioned
15:43:34 <tpsilva> and ipv6 as well, right?
15:43:40 <gouthamr> i've been reviewing those three patches - looks like they're coming along well
15:43:41 <vponomaryov> tpsilva: ipv6 is not merged
15:44:02 <tpsilva> vponomaryov: right
15:44:05 <bswartz> tpsilva: unmerged specs next
15:44:10 <tpsilva> k
15:44:30 <bswartz> #link https://review.openstack.org/#/q/status:open+project:openstack/manila-specs
15:44:40 <gouthamr> iirc tommylikehu was looking for some help regarding db-purge
15:44:49 <bswartz> fix-and-improve-access-rules
15:44:55 <bswartz> gouthamr: this is you
15:45:17 <bswartz> we're still reviewing this spec (its high priority/review focus)
15:45:29 <gouthamr> bswartz: the spec needs reviews. i've been coding in multiple patches
15:46:03 <bswartz> gouthamr: what about implementation
15:46:41 <gouthamr> bswartz: it's coming along - the first patch should be ready for review this week
15:46:45 <gouthamr> bswartz: it'll probably be 4-5 manageable patches as the spec suggests
15:46:50 <bswartz> if someone can add the links to the gerrit reviews for the implementation of the merges specs to the etherpad that would be great
15:47:16 <bswartz> scenario-tests
15:47:42 <bswartz> vponomaryov:  I'm guessing the implementation is not ready here?
15:48:02 <vponomaryov> bswartz: one new scenario is on review
15:48:18 <vponomaryov> #link https://review.openstack.org/400758
15:48:30 <bswartz> the plan is to add each test separately?
15:48:37 <vponomaryov> this one discovered bugs in LVM, Generic and ZFSonLinux drivers
15:48:51 <tpsilva> is this patch ready?
15:48:51 <vponomaryov> bswartz: yes, fixing bugs they discover
15:48:55 <vponomaryov> patch ready
15:48:59 <vponomaryov> driver fixes not
15:49:01 <tpsilva> it'll be useful for the mountable snapshots tests
15:49:27 <vponomaryov> so, scenario job fails there because of driver bug
15:50:02 <tbarron> bswartz: vponomaryov these patches can come in after feature freeze b/c they are tests, right?
15:50:11 <vponomaryov> tbarron: yes
15:50:12 <bswartz> tbarron: I suppose so, yes
15:50:15 <tbarron> so an incremental approach makes sense
15:50:30 <bswartz> just because they have a deadline doesn't mean we should deprioritize them though
15:50:36 <bswartz> have a different* deadline
15:50:56 <bswartz> I agree an incremental approach makes sense in any case
15:51:01 <bswartz> manila-ipv6
15:51:06 <tbarron> I like  prioriy and continuous improvement
15:51:10 <tbarron> priority
15:51:29 <bswartz> again nobody from huawei around to discuss this
15:51:29 <tbarron> on manila-ipv6
15:51:41 <bswartz> there's feedback on the spec and no updates...
15:51:48 <tbarron> I think tommylikehu is trying to coordinate irc convo with you
15:52:07 <bswartz> tbarron: I'll look up his email and try to reach him directly
15:52:28 <bswartz> probably just need to schedule a meeting early in my morning
15:52:28 <tbarron> bswartz: if I see him (I get up early sometimes) I'll try to facilitate.
15:52:40 <tbarron> bswartz: I'd really like to get this one done this cycle.
15:52:45 <bswartz> me too!
15:53:30 <bswartz> eliminate-race-conditions
15:53:47 <bswartz> this spec is also not ready
15:53:51 * bswartz sighs
15:53:58 <bswartz> and there's no implementation yet
15:54:05 <gouthamr> #link: https://review.openstack.org/#/c/318336/
15:54:14 <gouthamr> ^ this is likely part of that effort
15:54:18 <gouthamr> and it's ready for review
15:54:28 <bswartz> oh good point gouthamr
15:54:47 <tbarron> can we make incremental progress (adding ING states where appropriate) no matter what?
15:54:57 <tbarron> I am going to review the tooz patch again too.
15:55:10 <bswartz> tbarron yes
15:55:36 <tbarron> bswartz: good, we keep getting into all or nothing in a cycle scenarios
15:55:42 <bswartz> honestly the tooz work is the most essential, as we discovered in BCN
15:56:12 <bswartz> okay that took longer than expected
15:56:26 <bswartz> I plan to keep revsiting this list of specs each week to drive reviews to the ones that are ready
15:56:34 <bswartz> it should go faster in the future now that we have an etherpad
15:56:43 <bswartz> #topic open discussion
15:56:50 <bswartz> any last things to cover today?
15:57:04 <ganso> are we having a FPF or are we allowing patches that implement specs to popup at the last day?
15:57:23 <bswartz> ganso: yes we'll do FPF as always
15:57:42 <gouthamr> bswartz: you meant to send a deadline email
15:57:43 <ganso> bswartz: I was confused last time we discussed this. Is it Dec 19th?
15:57:56 <bswartz> however I imagine exceptions would be easier to grant for stuff that has a merged spec and/or is considered high priority
15:58:03 <bswartz> gouthamr: I think I did...
15:58:23 <gouthamr> oh.. probably didn't see it. nvm :)
15:58:28 <bswartz> it's possible I sent that mail when I was inside the spam blackhole
15:58:44 <bswartz> long story....
15:59:10 * tbarron no longer has to look in his spam folder for bswartz :)
15:59:16 <bswartz> ganso: https://releases.openstack.org/ocata/schedule.html
15:59:56 <ganso> bswartz: cool, it has been added to the official schedule
16:00:10 <ganso> bswartz: Dec 22th then
16:00:11 <bswartz> yes tbarron I emerged from the spam black hole a few weeks ago thanks to the help of erlon-airlong and a lot of DNS hacking
16:00:45 <bswartz> ganso: that freeze is for drivers
16:01:27 <bswartz> ganso: FPF isn't on that schedule but it should be Jan 9
16:01:38 <bswartz> okay we've past our time
16:01:49 <bswartz> any other questions about deadlines please ping me in the channel
16:01:51 <bswartz> #endmeeting