14:00:31 <rosmaita> #startmeeting cinder
14:00:32 <openstack> Meeting started Wed May  6 14:00:31 2020 UTC and is due to finish in 60 minutes.  The chair is rosmaita. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:33 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:35 <openstack> The meeting name has been set to 'cinder'
14:00:42 <rosmaita> #link https://etherpad.openstack.org/p/cinder-ussuri-meetings
14:00:42 <rosmaita> #topic roll call
14:00:49 <eharney> hi
14:00:50 <rajinir> hi
14:00:51 <LiangFang> hi
14:00:52 <smcginnis> o/
14:01:01 <lseki> hi
14:01:07 <walshh_> hi
14:01:07 <jungleboyj> O/
14:01:08 <sfernand> hi
14:01:44 <whoami-rajat> Hi
14:02:06 <rosmaita> looks like a good turnout
14:02:14 <e0ne> hi
14:02:30 <enriquetaso> o/
14:02:38 <rosmaita> before we get started, i want to say that I hope everyone and their loved ones are healthy and doing well in these stressful times
14:02:50 <rosmaita> and even your non-loved ones, i guess
14:02:56 <rosmaita> #topic updates
14:03:09 <rosmaita> ok, RC-2 was released on monday
14:03:16 <rosmaita> http://lists.openstack.org/pipermail/openstack-discuss/2020-May/014623.html
14:03:36 <rosmaita> that should be our final RC, i haven't seen anyone post any release critical bugs
14:03:48 <rosmaita> and we are running out of time to fix them anyway
14:04:20 <rosmaita> next item: no meeting next week, you can attend the "community meeting" instead
14:04:47 <rosmaita> the next cinder meeting on May 20 will be the first meeting of the Victoria cycle
14:05:00 <rosmaita> so, as is our tradition, there will be a new agenda etherpad:
14:05:09 <rosmaita> #link https://etherpad.opendev.org/p/cinder-victoria-meetings
14:05:18 <rosmaita> it's empty now because i just thought of it
14:05:31 <rosmaita> but i'll fill it with the boilerplate stuff after today's meeting
14:05:45 <rosmaita> oops i skipped an item
14:05:52 <rosmaita> PTG registration is open
14:06:02 <rosmaita> #link https://virtualptgjune2020.eventbrite.com/
14:06:20 <rosmaita> it's free, but the foundation would like to keep track of who's planning to attend
14:06:35 <rosmaita> will also get you on the mailing list about communication methods
14:06:47 <rosmaita> (which i don't think have been decided yet)
14:07:01 <rosmaita> so please register
14:07:27 <rosmaita> and on that note, we could use some topics on the Cinder PTG etherpad
14:07:37 <rosmaita> #link https://etherpad.openstack.org/p/cinder-victoria-ptg-planning
14:08:11 <rosmaita> the times for the cinder meetings are on that etherpad ^^
14:08:25 <rosmaita> any questions about the PTG?
14:09:27 <rosmaita> ok, there's always open discussion later if you think of something
14:09:33 <rosmaita> final announcement
14:09:56 <rosmaita> yesterday or this morning, depending on where you are, we merged a change related to eventlet and monkey patching
14:10:05 <rosmaita> #link https://review.opendev.org/#/c/724754/
14:10:14 <rosmaita> if you want the background:
14:10:22 <jungleboyj> Thanks for putting the Timezones in there.
14:10:23 <rosmaita> #link https://github.com/eventlet/eventlet/issues/592
14:10:46 <rosmaita> this is just awareness, in case anything weird starts happening ... because you never know
14:11:02 <smcginnis> Especially with eventlet.
14:11:10 <smcginnis> "You never know" ^
14:11:11 <rosmaita> :)
14:11:21 <rosmaita> ok, that's all the announcements
14:11:37 <rosmaita> #topic  coordination with barbican(-tempest-plugin) people on volume tests
14:12:00 <rosmaita> so, we have an interesting situation
14:12:12 <rosmaita> our encrypted volume tests need access to barbican
14:12:30 <rosmaita> and the easiest way to do that is to have them live in the barbican-tempest-plugin
14:12:47 <rosmaita> something about circular dependencies, tosky can explain if you are interested
14:12:58 <rosmaita> anyway, i think that's why he put it on the agenda
14:13:02 <rosmaita> tosky: you're up
14:13:12 <enriquetaso> ++
14:13:37 <tosky> we may benefit from an increased amount of cinder tests that use barbican
14:13:43 <rosmaita> i poked around a bit, there is no barbican-tempest-plugin core group
14:13:49 <rosmaita> it's just barbican-core
14:14:01 <rosmaita> do we want to propose to help maintain that plugin
14:14:02 <tosky> now, the barbican tempest client is defined inside barbican-tempest-plugin and they also have a few tests there
14:14:27 <tosky> some of them mirror the corresponding basic encryption tests from tempest.git, but with a barbican flavor
14:14:31 <rosmaita> or could we propose re-architecting it so that we can use the stuff we need in the cinder-tempest-plugin?
14:14:44 <rosmaita> (sorry, tosky i should let you talk)
14:15:15 <tosky> I would say it may be easier to see if they could agree with having some of us voting on those patches, with the agreement of not approving non-volume tests (or waiting anyway for other approvals)
14:15:22 <tosky> I took the liberty of raising this point at yesterday's barbican meeting, but as I haven't discussed about it here before, I didn't go in details
14:15:37 <tosky> http://eavesdrop.openstack.org/meetings/barbican/2020/barbican.2020-05-05-13.01.log.html
14:16:43 <rosmaita> well, looks like they didn't tell you to go boil your head
14:16:57 <jungleboyj> :-)
14:17:09 <rosmaita> i can propose something on the ML like we did for ceph and nfs devstack plugins
14:17:25 <rosmaita> and will stress the gentleperson's agreement not to approve anything non-volume related
14:17:41 <tosky> yes, that could help, maybe we can define this before the PTG, and then use that time to refine and/or implement it properly
14:17:55 <enriquetaso> One question: should I move the retype encrypt test to barbican-tempest-plugin then? https://review.opendev.org/#/c/715566/
14:18:30 <rosmaita> enriquetaso: good question, i was wondering about that myself
14:18:39 <eharney> since that retype test doesn't need to interact with barbican directly (and in theory could work with other key managers as well), i think not
14:18:51 <eharney> it's purely a cinder functionality test
14:19:06 <tosky> right: if it does not use the barbican client, it can stay there
14:19:16 <enriquetaso> ++
14:19:18 <enriquetaso> thanks
14:20:25 <tosky> I don't have anything else to add about this right now; the direction is "discuss and find an agreement"
14:20:27 <tosky> IMHO
14:21:14 <rosmaita> ok, i'll put up something to the ML to get this moving and we can follow up as necessary
14:21:23 <tosky> thanks!
14:21:32 <rosmaita> #action rosmaita email about cooperation with barbican-tempest-plugin
14:21:38 <rosmaita> ok, thanks tosky
14:22:04 <rosmaita> #topic security-related issue  when an attached volume exposes host information to non-admins
14:22:09 <rosmaita> whoami-rajat: that's you
14:22:16 <whoami-rajat> So we discussed a security issue during cinder mid-cycle PTG, the summary of the issue is, an attached volume could expose the nova host details via the volume show API and attachments API
14:22:46 <whoami-rajat> the general consensus on lauchpad was to change the policy of the attachment API to admin only
14:23:07 <whoami-rajat> but this might have affect on the consumer projects such as nova and glance
14:24:08 <eharney> that policy being, to only how the host to admins?
14:24:10 <eharney> only show*
14:24:25 <whoami-rajat> yes
14:24:49 <whoami-rajat> in volume show API, show host to only admins and in attachments API only show connection_info to admins
14:25:35 <rosmaita> but in volume-show, don't you get the same stuff as attachments api as far as connection_info ?
14:26:20 <whoami-rajat> rosmaita, i'm not sure, the bug is only reported against the HOST field
14:26:28 <whoami-rajat> i will check that as well
14:26:30 <rosmaita> also, we should probably be clear about what "host" we are talking about
14:26:43 <rosmaita> this is the attatched_host ?
14:26:55 <whoami-rajat> IIUC it's the nova host
14:27:05 <whoami-rajat> where the volume is attached
14:27:21 <rosmaita> ok
14:28:06 <rosmaita> yeah, nova does not like to expose the VM host to users
14:28:09 <whoami-rajat> i just posted this topic here for a general discussion and gather opinions on the path on which we should move ahead
14:28:47 <whoami-rajat> i think nova also has some policy rules for not exposing the host info to non-admins
14:29:05 <rosmaita> i think the issue is that nova does not like this being available as a backdoor for a user to discover the host info
14:29:27 <whoami-rajat> yep
14:29:36 <smcginnis> It is a concern for leaking out underlying infrastructure information.
14:30:16 <jungleboyj> Right.
14:30:19 <rosmaita> i don't know if this makes sense, but
14:30:33 <rosmaita> if we keep the volume-show and attachments api the way they are now
14:30:37 <rosmaita> admin or owner
14:30:56 <rosmaita> and only hide the attached_host, how does that affect usefulness of the response
14:30:58 <rosmaita> ?
14:31:58 <smcginnis> I wouldn't think anyone (person or system) should be relying on that information for anything.
14:32:18 <rosmaita> yeah, my intuition is that the person making the connection knows who they are already
14:32:20 <eharney> that's kind of my gut feeling too
14:32:37 <jungleboyj> That would be my thought.
14:33:12 <rosmaita> so i guess whoami-rajat's next question is, do we need a policy on that single field? or do we just do an internal "is_admin" check and display or not?
14:33:20 <rosmaita> or maybe just never display?
14:33:26 <smcginnis> Might be worth calling it out on the ML that responses will be changing and why. That way if for some reason someone actually is paying attention to that information in this response, they have a warning not to do so anymore.
14:33:45 <rosmaita> smcginnis: ++
14:33:59 <smcginnis> I would vote never display. Unless maybe is_admin, since an admin may be able to use that information to troubleshoot or something.
14:34:20 <rosmaita> since this is a security issue, i don't think we need to worry about microversioning this change?
14:34:27 <whoami-rajat> also JFYI from the raw response of attachment API, non-admins can get this all info https://bugs.launchpad.net/cinder/+bug/1736773/comments/1
14:34:27 <openstack> Launchpad bug 1736773 in Cinder "attachment-show is including `connection_info` for non-admin callers, it shouldn't" [High,Triaged] - Assigned to John Griffith (john-griffith)
14:34:29 <smcginnis> rosmaita: Agree
14:34:48 <jungleboyj> Agreed.
14:34:49 <eharney> shouldn't need microversioning since this field can already be blank etc now
14:34:51 <smcginnis> whoami-rajat: Hmm, that's a concern too.
14:35:59 <whoami-rajat> it contains auth_password which i'm not sure how important but a password shouldn't show up in an API response i guess
14:36:46 <eharney> depends, is that api used to connect to volumes?
14:37:22 <eharney> i guess this is after it's already attached/connected
14:37:40 <whoami-rajat> hmm, i think nova uses initialize_connection to connect and attachment_update to get the connection_info later
14:37:53 <whoami-rajat> but i'm not sure if they use attachment_get for any purpose
14:38:04 <whoami-rajat> refresh*
14:40:29 <rosmaita> ok, looks like we may need some research here
14:42:18 <rosmaita> ok, so to summarize: (1) should not populate the host_name in the volume-show response (except to admins); propose to rely on the admin context to decide whether to show or not; since no change to response, no need to microversion this
14:42:43 <rosmaita> (2) need to verify that connection_info is not required for non-admin users in the attachment-show response
14:43:25 <rosmaita> and depending on the outcome of (2), will either hide the connection_info or just depopulate the attached_host (or whatever it's called in that response)
14:43:47 <whoami-rajat> changing the attachments api to admin only would require nova changes so i think this needs discussion with the nova team as well
14:43:59 <whoami-rajat> rosmaita, that sounds like a good plan to me
14:44:22 <rosmaita> whoami-rajat: do you want to continue to pursue this and we can also discuss (2) at ptg?
14:44:42 <whoami-rajat> rosmaita, sure
14:44:49 <rosmaita> i can send an email out about (1) since i think that won't affect anyone really
14:45:16 <whoami-rajat> i think i can also work on this i parts since only 2 is the concern
14:45:20 <rosmaita> and it's ok to discuss on the ML because this bug has been public since at least the cinder midcycle
14:45:22 <whoami-rajat> rosmaita, that would be great
14:45:36 <rosmaita> #action rosmaita (see above)
14:45:40 <rosmaita> ok, thanks whoami-rajat
14:45:49 <whoami-rajat> thanks everyone
14:45:58 <rosmaita> #topic priorities for victoria milestone-1
14:46:30 <rosmaita> i lost my tab, but M-1 is like 2 weeks after the ptg
14:46:41 <rosmaita> anyway, the cinder team priorities are:
14:46:50 <rosmaita> (1) volume local cache, and
14:46:57 <rosmaita> (2) nfs encryption
14:47:12 <rosmaita> LiangFang is working on 1, enriquetaso is working on 2
14:47:20 <rosmaita> #topic volume local cache
14:47:24 <rosmaita> LiangFang: that's you
14:47:29 <LiangFang> thanks rosmaita
14:47:40 <LiangFang> should I add this topic in PTG?
14:48:01 <LiangFang> one thing in cinder patch is:
14:48:13 <rosmaita> yes, if things aren't moving along well, or if some things come up that require discussion
14:48:33 <LiangFang> volume type extra-spec without prefix "capabilities:" will be treated as filter. See: https://github.com/openstack/cinder/blob/master/cinder/scheduler/filters/capabilities_filter.py#L62
14:48:44 <LiangFang> I just copied from patch comment
14:48:55 <LiangFang> So extra-spec "cacheable" will be treated as filter. As discussed in spec, some backends like nfs and rbd will not be supported. So I'm trying to enable the supported backends explicitly. Any backends not marked "cacheable=True" will not be supported by default. It is like white list mode. We may can go through backends drivers and add more drivers as supported later in a following patch.
14:49:22 <eharney> i need to study up on this again, but i (still) think it's not correct to put this as a flag in the LVM driver
14:49:43 <LiangFang> ok
14:49:50 <eharney> as far as i can tell, it isn't a driver attribute, it's a protocol attribute
14:49:59 <eharney> your suggestion is currently: enable this flag in every iscsi/fc driver (i think)
14:50:19 <eharney> we should just have the manager apply it to iscsi/fc etc as appropriate without requiring driver changes, unless we think there are driver-specific reasons that caching won't work
14:51:42 <LiangFang> if we add like: capabilities:cacheable
14:51:58 <LiangFang> then it is not act as filter
14:52:13 <LiangFang> but how to prevent nfs and rbd
14:52:54 <eharney> i think the point about "capabilities:" is correct but i haven't yet figured out why that means we need to do this inside the driver
14:53:40 <LiangFang> if we don't add capabilities:
14:54:27 <LiangFang> then cacheable will be treat as a filter, that means if the driver is not marked as "cacheable", it will not be scheduled
14:55:05 <LiangFang> at last, will pop up like "can not find a valid backend"
14:55:15 <eharney> i'll do some research into how that works, but i think the point remains that "cacheable" isn't actually a property of the driver -- so it should be set somewhere else
14:55:25 <eharney> i don't know enough of the details to get to the bottom of it right now
14:56:02 <LiangFang> eharney: thanks, may can see: https://github.com/openstack/cinder/blob/master/cinder/scheduler/filters/capabilities_filter.py#L62
14:56:49 <LiangFang> another thing is about testing
14:57:08 <LiangFang> I find I cannot finish tempest test at this point
14:57:42 <LiangFang> because tempest test requires the patches ready first
14:58:03 <LiangFang> there're 3 patches, cinder, os-brick, nova
14:58:06 <rosmaita> so is the issue that: 'cacheable' is a property of the volume-type, but the way it is expressed now prevents some drivers from being scheduled at all?
14:58:30 <LiangFang> rosmaita: yes
14:58:46 <rosmaita> sorry, we are almost out of time ... looks like we need to continue to discuss this at next meeting and PTG
14:58:57 <LiangFang> cacheable in type will schedule no backends
14:59:05 <eharney> you can still apply it for all relevant drivers, for them to be scheduled, in the manager rather than in the driver code
14:59:14 <LiangFang> rosmaita: Ok, thanks
14:59:42 <LiangFang> eharney: maybe I need to study how to add in manager
14:59:53 <enriquetaso> One quick thing About (2) I re based the patch this week because of merge conflicts, but know it's ready for reviews https://review.opendev.org/#/c/597148/ . Please feel free to add comments
14:59:53 <rosmaita> sounds like something to look at
14:59:57 <LiangFang> eharney: may be you are right
15:00:04 <rosmaita> enriquetaso: thanks !
15:00:23 <rosmaita> ok, thanks everyone, we need to get out of the way for Horizon
15:00:28 <rosmaita> #endmeeting