15:01:40 <tbarron> #startmeeting manila
15:01:40 * gouthamr beep beep
15:01:41 <openstack> Meeting started Thu Oct 11 15:01:40 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:43 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:45 <openstack> The meeting name has been set to 'manila'
15:01:45 <dustins> bswartz: The RH contingent is stuck in a meeting :)
15:01:50 <bswartz> .o/
15:01:52 <amito> hello \o
15:01:53 <gouthamr> o/
15:01:55 <ganso> hello
15:02:53 <vkmc> o/
15:02:57 <tbarron> hi all
15:03:25 <tbarron> Agenda:
15:03:29 <dustins> \o
15:03:33 <tbarron> #link https://wiki.openstack.org/wiki/Manila/Meetings
15:03:44 <tbarron> #topic Announcements
15:04:00 <jgrosso> hi
15:04:01 <tbarron> Let's congratulate amito for his role as a manila core!
15:04:16 <amito> Thanks! :)
15:04:18 <dustins> \o/
15:04:21 <tbarron> And pile reviews on him :)
15:04:25 <dustins> amito: Congratulations!
15:04:25 <amito> Happy to join you.
15:04:27 <ganso> amito: congrats! welcome to the core team!
15:04:28 <gouthamr> congratulations amito, welcome
15:04:30 * bswartz fires confetti cannon
15:04:36 <jgrosso> Congrats amito welcome !
15:04:47 <tbarron> Seriously amito I'm very happy to have you join this distinguished group :)
15:04:51 <amito> tbarron dustins ganso gouthamr jgrosso thank you all :)
15:04:55 <amito> bswartz: lol
15:05:45 <tbarron> The other announcment is that I sent email to the dev list with our proposed mid-cycle and Americas-time-zone bug smash days
15:05:58 <tbarron> So far no objections or counter-proposals.
15:06:25 <tbarron> We'll give it till next week and then pick the proposed days if we don't hear anything to the contrary.
15:06:43 <tbarron> Any other announcements?
15:07:20 <tbarron> moving along then ...
15:07:27 <tbarron> #topic planning our work
15:07:37 <tbarron> #link https://wiki.openstack.org/wiki/Manila/SteinCycle
15:08:14 <tbarron> #topic python3
15:08:32 <tbarron> Next task here is switching xenial jobs to bionic beaver
15:08:41 <tbarron> I saw gouthamr working on this
15:08:51 <tbarron> gouthamr: any remarks?
15:09:09 <gouthamr> tbarron: yes, i'm stuck on a couple of things wrt this
15:09:32 <bswartz> Anything you need help with?
15:09:32 <gouthamr> i don't see any evidence of the ipv6 mounting issue resolved in bionic beaver
15:09:52 <ganso> gouthamr: meaning, it is still broken?
15:10:11 <gouthamr> ganso: on the contrary, something in the doc makes me think it'll not be fixed
15:10:24 * gouthamr looks for link
15:10:25 <ganso> :O
15:10:30 <bswartz> on xenial, nfs-utils was 1.2.8, on bionic, nfs-utils is 1.3.4
15:10:35 <gouthamr> #LINK https://review.openstack.org/#/c/608761/
15:10:42 <gouthamr> #LINK http://manpages.ubuntu.com/manpages/bionic/man5/exports.5.html
15:11:15 <gouthamr> unless i'm looking in the wrong place, "IPv6 addresses must not be inside square brackets in /etc/exports lest they be  confused  with character-class wildcard matches."
15:11:30 <bswartz> http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=4663c6481c294838260840d234fec7dfd3186451
15:12:36 <tbarron> bswartz: is that included in 1.3.4 and the man page is just out of date?
15:12:50 <bswartz> http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=188354e57dd8476e66ce30d647180a106da29b88
15:12:57 <bswartz> The 1.3.4 tag was Aug 2016
15:13:05 <bswartz> And the commit adding ipv6 support was March 2014
15:13:23 <bswartz> 1.2.8 dates back to May 2013
15:13:46 <bswartz> So I think they moved a little more than 3 years forward on the master branch between xenial and bionic
15:14:21 <bswartz> Unless they're compiling with --disable-ipv6 or some such insanity
15:14:51 <bswartz> gouthamr: if you continue to have problems, I can test this for you
15:15:30 <gouthamr> bswartz: awesome.. yes, i'll focus on fixing the zuul issue with bionic, and tehn i'll ping you
15:15:32 <tbarron> bswartz: that might be helpful
15:15:35 <bswartz> I'm using Archlinux for most of my development work lately because I got too irritated with Ubuntu and Fedora and their limitations
15:15:42 <gouthamr> ++
15:15:49 <bswartz> But I can spin up a bionic VM with little effort
15:15:51 * tbarron sees gouthamr doing many many things at once
15:15:52 <gouthamr> :D build-it-myself-linux
15:16:30 * tbarron arches his eyebrows at bswartz
15:16:48 <tbarron> sounds like a plan
15:17:09 <tbarron> vkmc: anything else on python3 atm?
15:17:19 * tbarron asks the lead on that story
15:17:20 <vkmc> tbarron, not for now
15:17:24 <tbarron> vkmc: ack
15:17:28 <vkmc> tbarron++
15:17:33 <tbarron> #topic upgrade health checker
15:17:53 <tbarron> I'm waiting for some work in oslo that everyone will leverage.
15:18:02 <tbarron> Will update the wiki with a link to it.
15:18:09 <tbarron> Then I'll make a stub job
15:18:14 <tbarron> Then we can add content.
15:18:20 <tbarron> Any questions?
15:18:43 <gouthamr> nope.. but just-a-minute on the py3 stuff if you don't mind tbarron?
15:18:59 <tbarron> #topic python3 again
15:19:26 <gouthamr> i want to replace py35 jobs with py37 - i.e, unit-test with py36 and py37
15:19:29 <gouthamr> any objections?
15:19:38 <gouthamr> # LINK https://review.openstack.org/#/c/609558/
15:19:40 <gouthamr> #LINK https://review.openstack.org/#/c/609557/
15:19:41 <tbarron> not from me
15:20:10 <tbarron> my local machine doesn't have py35 any more
15:20:14 <gouthamr> someday we'll have functional tests running with py36 or py37, but not py35
15:21:02 <tbarron> gouthamr: please add that to the tasks in the python3 topic
15:21:02 <vkmc> I think it's good
15:21:13 <gouthamr> tbarron: ack, will do..
15:21:23 <tbarron> let's take silence as consent in *this* case
15:21:30 <gouthamr> deep
15:21:32 <tbarron> anything else on py3?
15:21:41 <gouthamr> nope
15:21:55 <tbarron> #topic priority for access rules
15:22:12 <tbarron> ganso: thanks for your recent review of the implementation
15:22:19 <ganso> =)
15:22:40 <tbarron> zhongjun isn't here and she recently told me that someone else will be picking up this work, though
15:22:43 <bswartz> gouthamr: I ran the test, mounting IPv6 NFS share works fine on Bionic
15:22:49 <gouthamr> w00t
15:23:00 <tbarron> she will be helping with the transition for as long as needed
15:23:19 <tbarron> So let's all try to help get this work completed since it was started in the last cycle.
15:23:27 <ganso> tbarron: we could discuss one of the comments I made
15:23:29 <gouthamr> bswartz: awesome, i'll just have to figure out the devstack issue on the gate right now then
15:23:39 <tbarron> ganso: kk
15:23:41 <ganso> tbarron: I suggested to take the discussion here
15:24:03 <ganso> so there are 2 main items I questioned
15:24:18 <ganso> 1) the update method only updates the priority field
15:24:45 <ganso> my only concern is that the naming of all functions and CLI is "update_share_access", but only the priority field is updated
15:25:03 <ganso> we have the mechanisms in place to update any field we want now
15:25:28 <ganso> I believe we should discuss this one more time and decide if we want to stick with updating only the priority field
15:25:36 <ganso> and in that case I'd suggest renaming all the methods and functions
15:25:52 <ganso> or allow updating other fields as well, in that case we could discuss which fields
15:26:17 <tbarron> ganso: are we doing feature creep relative to the approved spec?
15:27:09 <ganso> tbarron: I'm not really backtracking to the spec, what inspired me to discuss this are the method names, which I just noticed now
15:27:39 <bswartz> Is the CLI "update" or "modify"?
15:27:41 <ganso> tbarron: we've always agreed that the implementation could drift away from the spec
15:27:58 <ganso> bswartz: the CLI is update https://review.openstack.org/#/c/574633/7/manilaclient/v2/shell.py
15:28:14 <tbarron> ganso: well I'm not going to touch that general remark :)
15:28:40 <bswartz> ganso -1 for implementation not matching spec
15:29:12 <ganso> I did not look at the spec at all. I am just looking at the implementation
15:30:34 <ganso> do we intend to someday (or right now) allow access updates to change the access values, or access type as well? or just priority? I think this is the main question we need to answer here
15:31:18 <ganso> if we in the past did not consider this because it would be a lot of work, then we don't need to worry about that anymore as all that amount of work is included with the patch just to change the priority
15:31:22 <gouthamr> it needn't be to access-type or access-level, but for stuff that comes later
15:31:53 <gouthamr> i don't see a problem with "update", but restricting what can be updated
15:32:01 <gouthamr> much like share-update or snapshot-update
15:32:15 <gouthamr> or share-network-update
15:32:28 <ganso> gouthamr: so you think it makes sense for us to allow updating other fields?
15:32:55 <gouthamr> ganso: nope, right now, we should only allow updating priority, as the spec suggests
15:32:57 <tbarron> ganso: some fields are mutable and others are not with respect to any resource, right?
15:33:57 <ganso> tbarron: at this moment I don't see a problem with changing access_type, access_level and access_value. They can be validated upon each call just like when they are added
15:34:20 <tbarron> ganso: but that is not work we planned to do in this iteration, right?
15:34:44 <ganso> tbarron: it is not
15:35:11 <tbarron> so I think we can leave the verb as 'update' rather than narrowing it to 'update-priority'
15:35:33 <tbarron> but we don't have to implement updating of anything other than priority currently
15:35:49 <tbarron> s/don't have to/should not/ without further discussion
15:35:57 <ganso> ok, and later someday we could add the other parameters to the API and bump the microversion ?
15:35:58 <tbarron> ganso: agree?
15:36:14 <tbarron> ganso: if there's a use case and we agree to do so
15:36:34 <tbarron> ganso: good to think about generalization though!
15:36:44 <ganso> tbarron: ok I'm fine by that if we have agreement to
15:36:58 <ganso> nett up is item 2) the filtering
15:37:04 <ganso> s/nett/next
15:37:14 <ganso> so filtering is currently being done by share_id or priority
15:37:29 <ganso> I don't see much value in only allowing filtering by those 2
15:37:46 <ganso> I may want to filter all rules by priority #130
15:38:18 <ganso> but I may also want to filter rules by ip, access type, or even the value
15:38:44 <ganso> so again, we have all the mechanisms in place
15:39:36 <ganso> we could just also say "let's just filter by priority now and add the other later", that's fine, I just want to know if that's what we really want
15:39:44 <tbarron> ganso: are all these DB side filters?
15:39:49 <ganso> tbarron: yes
15:40:55 <tbarron> ganso: I guess I'm inclined to incrementalism even if you want to do the generalization right away in this cycle.
15:40:59 <gouthamr> ganso: +1 on adding generic filters upfront, we should address that
15:41:37 <gouthamr> this one is easier than your earlier suggestion, and more useful right away to end users given we introduced a new API in the last cycle
15:41:42 <tbarron> ganso: if it's no significan extra work (including testing and doc) to do this then that's fine
15:41:49 <tbarron> gouthamr: ^^
15:41:55 <ganso> tbarron gouthamr: yup
15:42:06 <ganso> alright cool
15:42:08 <tbarron> but we can't hold up planned work for generalizations in general
15:42:55 * tbarron said 'general' too many times, generally speaking
15:43:00 <ganso> lol
15:43:04 <tbarron> ok, anything else on this one?
15:43:11 <ganso> tbarron: nope
15:43:44 <tbarron> I'm going to skip a bit
15:43:59 <tbarron> ganso your spec's are up for review
15:44:05 <tbarron> two of them
15:44:09 <ganso> tbarron: correct
15:44:19 <tbarron> #link https://review.openstack.org/#/c/607342/
15:44:29 <tbarron> https://review.openstack.org/#/c/391805
15:44:35 <ganso> tbarron: thanks
15:44:41 <tbarron> #link https://review.openstack.org/#/c/391805
15:45:00 <tbarron> let's all take AIs to read them and circle back next week.
15:45:23 <tbarron> Unless someone has an issue w.r.t. them to bring up now
15:45:37 <tbarron> moving along
15:45:43 <tbarron> #topic Manila CSI
15:45:55 <tbarron> gouthamr: do you want to report on our meeting with CERN?
15:46:20 * tbarron will update this section in the wiki after the meeting
15:46:30 * gouthamr yep, looking for the etherpad link
15:46:37 <tbarron> gouthamr: sec
15:47:22 * tbarron fumbles
15:47:36 <gouthamr> gah
15:47:39 <gouthamr> #link: https://www.google.com/url?q=https%3A%2F%2Fetherpad.openstack.org%2Fp%2Fopenstack-manila-csi-syncup&sa=D&ust=1539026786836000&usg=AFQjCNEfw9hPrf7s10hZxLwdzTsSp622SA
15:47:42 <gouthamr> grr
15:47:53 <gouthamr> #undo
15:47:55 <gouthamr> :P
15:47:55 <bswartz> #link https://etherpad.openstack.org/p/openstack-manila-csi-syncup
15:48:04 <gouthamr> ty bswartz!
15:48:04 <tbarron> bswartz: ty
15:48:42 <gouthamr> #link: https://bluejeans.com/s/mkAb7 (this may be deleted without notice)
15:49:07 <gouthamr> so we had a pretty productive sync up with the folks working on the manila dynamic provisioner in cloud-provider-openstack
15:49:12 <gouthamr> and ceph-csi
15:49:49 <gouthamr> flaper87 (Flavio Percoco) has WIP code for manila-csi
15:50:30 <gouthamr> we took AIs to propose this PR to cloud-provider-openstack and work on it together with the contributors from CERN
15:51:28 <bswartz> Are they still pursuing the NFS-over-vsock thing?
15:51:30 <gouthamr> an interesting thing for us k8s/CSI-noobs in the room was being educated about the architecture that we'll use - a controller plugin and a node plugin - please see notes in the etherpad and the bluejeans for info
15:51:39 <bswartz> That continues to intrigue me but I haven't investigated
15:52:01 <tbarron> bswartz: not really, can come back to that in #openstack-manila post-meeting
15:52:49 <tbarron> gouthamr: are you going to speak to the protocol-specific-plugin aspect?
15:53:12 <gouthamr> i also had an AI to grab a room with bswartz (and the rest of us) to discuss an NFS node-plugin
15:53:22 <bswartz> o_O
15:53:36 <bswartz> Why would someone want a single-protocol Manila?
15:53:36 <tbarron> cause CERN has a cephfs-native node-plugin
15:53:47 <gouthamr> much like how CERN is using ceph-csi at the moment to mount/unmount CEPHFS shares
15:53:48 <tbarron> bswartz: and it wouldn't be
15:53:52 <bswartz> Because that protocol could be NFS and a bunch of backends still work with NFS?
15:54:18 <gouthamr> bswartz: the discussion arose from https://github.com/container-storage-interface/spec/issues/263#issuecomment-411471611
15:54:28 <tbarron> controller-plugin would be protocol agnostic
15:54:39 <tbarron> s/plugin/driver/
15:54:56 <tbarron> node-plugins would be protocol specific iiuc
15:55:16 <bswartz> Hmm interesting
15:55:44 <bswartz> It's a significant departure for the CSI design
15:55:54 <bswartz> Who is pushing that work?
15:56:23 <tbarron> gouthamr: have I represented/misrepresented the thinking?
15:56:28 <gouthamr> tbarron: no
15:56:36 <bswartz> I've proposed some changes to the CSI interface and been shot down
15:56:44 <gouthamr> we might have to grab that room bswartz tbarron
15:56:49 <gouthamr> time check
15:57:02 <tbarron> bswartz: well cern is sorta doing it that way now, but with dynamic external provider atm in the manila csi role
15:57:19 <tbarron> gouthamr: yup
15:57:41 <tbarron> anyone interested in this topic ping gouthamr or me and we'll
15:57:53 <tbarron> coordinate a followup with bswartz
15:57:58 <bswartz> I have meetings for the next 3 hours -- if you want to meet grab me tomorrow
15:58:11 <gouthamr> bswartz: ack, i'll coordinate a meeting
15:58:15 <gouthamr> time
15:58:24 <tbarron> gouthamr: we still have a minute
15:58:39 <tbarron> Anything else ?
15:58:47 <gouthamr> nope, nothing else on the topic
15:59:01 <tbarron> We'll rotate along the wiki rather than starting at the top
15:59:03 <tbarron> evey time.
15:59:10 <gouthamr> +1100
15:59:18 <tbarron> and hopefully get to bugs, etc.
15:59:23 <tbarron> next time
15:59:30 <tbarron> Thanks everyone!!
15:59:32 <dustins> And I've got some good ones for that when we do :D
15:59:37 * gouthamr reminds dustin i did my AIs
15:59:37 <tbarron> dustins: :)
15:59:46 <tbarron> #endmeeting