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