14:00:18 <rosmaita> #startmeeting cinder
14:00:19 <LiangFang> o/
14:00:20 <openstack> Meeting started Wed Mar  4 14:00:18 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:21 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:23 <openstack> The meeting name has been set to 'cinder'
14:00:28 <rosmaita> #topic roll call
14:00:32 <eharney> hi
14:00:33 <whoami-rajat> Hi
14:00:36 <e0ne> hi
14:01:09 <rosmaita> good turnout!
14:01:14 <jungleboyj> Good morning.
14:01:23 <rosmaita> (there were some high-fives before the meeting officially started)
14:01:26 <rosmaita> #link https://etherpad.openstack.org/p/cinder-ussuri-meetings
14:01:40 <rosmaita> pretty light agenda today
14:01:56 <rosmaita> #topic updates
14:02:17 <rosmaita> ok, first thing is that the final releases from rocky are out
14:02:41 <rosmaita> there were some release tooling problems that smcginnis had to fix that delayed them a bit
14:02:46 <jungleboyj> Thank you for getting those taken care of!
14:03:00 <rosmaita> so rocky will be tagged as -em shortly
14:03:22 <rosmaita> as a reminder, we can backport bugfixes, but there will be no more rocky releases
14:03:28 <rosmaita> other news
14:03:46 <rosmaita> you may have seen this on the ML (pretty sure I sent it out last week)
14:03:57 <rosmaita> the second session of the virtual mid-cycle is scheduled
14:04:06 <rosmaita> Monday 16 March 12:00-14:00 UTC
14:04:10 <smcginnis> .o.
14:04:27 <rosmaita> #link https://etherpad.openstack.org/p/cinder-ussuri-mid-cycle-planning
14:04:35 <jungleboyj> Cool.
14:04:36 <rosmaita> ^^ for proposing topics
14:04:53 <rosmaita> the feedback from last time was that we needed a few more reminders
14:05:13 <rosmaita> so i'll send another to the ML early next week
14:05:23 <rosmaita> and i guess, tell everyone you know about it!
14:05:37 <rosmaita> another awareness item
14:05:52 <rosmaita> there's been a update to the vulnerability:managed policy
14:06:03 <rosmaita> #link http://lists.openstack.org/pipermail/openstack-discuss/2020-February/012721.html
14:06:34 <rosmaita> primary change is that the security embargo that keeps a security bug non-public will be lifted after 90 days
14:06:39 <rosmaita> even if there's been no action
14:07:02 <rosmaita> just a reminder about working on a security bug
14:07:26 <rosmaita> you may be able to see it if you're a member of cinder-core-sec, or filed it yourself, or were asked to look at it
14:07:42 <rosmaita> when you submit a patch, you have to do it by attaching the patch to the bug in Launchpad
14:07:49 <rosmaita> do *not* submit a gerrit review
14:07:54 <rosmaita> (because those are public)
14:08:23 <rosmaita> #topic update - community goals
14:08:45 <rosmaita> goa1 #1 was removing py2 support
14:09:11 <rosmaita> i got confirmation from gmann yesterday (he's driving the goal) that cinder has completed it
14:09:23 <rosmaita> goal #2 is updating the contributor docs
14:09:29 <rosmaita> i have that underway
14:09:56 <rosmaita> what i've decided to do is to have a primary page in the cinder docs that cover the required stuff
14:10:09 <rosmaita> and then link to it from all the other cinder projects
14:10:35 <rosmaita> this is what i mean
14:10:42 <rosmaita> here's the WIP patch for cinder: https://review.opendev.org/711006
14:11:05 <rosmaita> and here's the one for os-brick: https://review.opendev.org/711011
14:11:26 <rosmaita> anyway, feel free to look at those, although the URLs are of course broken
14:11:48 <rosmaita> remaining for cinder is the list of core contributors and the list of PTL duties
14:11:57 <rosmaita> which reminds me
14:12:10 <rosmaita> we get some latitude about what info we supply about the cinder-core
14:12:23 <rosmaita> the bare-bones would be a link to the gerrit group
14:12:40 <rosmaita> https://review.opendev.org/#/admin/groups/83,members
14:12:48 <jungleboyj> rosmaita:  Thanks for tackling the contrib docs goal.  Wanted to chat with you about that.  I will look at the patches.
14:13:07 <rosmaita> but the goal champions suggest more info, like irc nick, timezone, etc
14:13:19 <rosmaita> my thought is to put that up as a wiki page
14:13:28 <rosmaita> and then each person can control how much info is displayed
14:13:45 <smcginnis> My concern with irc nick and timezone information is that is something that requires ongoing updates and maintenance.
14:13:46 <jungleboyj> rosmaita:  I like that idea.  I would encourage the cores to share more than less.
14:13:51 <tosky> the os-brick thing may be seen as non-compliant with the text of the goal, but I personally think it makes sense
14:13:58 <smcginnis> In other words, highly likely to get out of sync and have stale info.
14:14:15 <tosky> smcginnis, rosmaita : I usually get those details from stackalytics
14:14:17 <jungleboyj> smcginnis:  How often are our cores changing though.  :-)
14:14:24 <smcginnis> Though also true our cores haven't been changing much, so maybe ok.
14:14:26 <smcginnis> jungleboyj: Yeah.
14:14:33 <tosky> our big brother which tracks everyone and shows the hours when anyone is active
14:14:42 <smcginnis> But I would still prefer like tosky says and link to some other source of truth for those things.
14:14:45 <rosmaita> does stackalytics show time zones?
14:14:57 <tosky> rosmaita: it shows when you are active, which is even more relevant
14:15:07 <smcginnis> Honestly, I don't think people should have to know that much detail about cores.
14:15:30 <rosmaita> i'm inclined to agree with smcginnis here
14:15:45 <rosmaita> ok, we can start out small and enhance if the people demand it
14:15:59 <jungleboyj> Ok.
14:16:08 <rosmaita> i'll just put a link to the gerrit group and stackalytics
14:16:18 <smcginnis> ++
14:16:37 <rosmaita> related to this, though, i've been wondering about timezone.io
14:16:42 <rosmaita> has anyone used it?
14:16:59 <rosmaita> it would be helpful to me anyway to see the TZs of cores
14:17:20 <smcginnis> For your purposes, I'm good with that.
14:17:22 <rosmaita> problem is, you have to log into it to add yourself to the cinder team
14:17:54 <tosky> do you think it is needed even if you can check through stackalytics?
14:18:07 <jungleboyj> Hmm, I haven't used that but that is a good tool to know about.
14:18:25 <rosmaita> tosky: what i'd like to see is what time it is now in each person's timezone
14:18:31 <rosmaita> with a groovy picture
14:18:50 <rosmaita> and for people like hemna who switch TZs, they can "easily" update it
14:19:18 <rosmaita> i'll send invites to the core team ... don't feel obligated to do it if you think it's stupid
14:19:35 <rosmaita> if enough people participate, we can open it up to any active contributor
14:19:51 <rosmaita> becuase it would be nice to see who's available to review stuff, not just cores
14:19:58 <whoami-rajat> rosmaita, ++
14:19:58 <jungleboyj> ++
14:20:05 <e0ne> +1
14:20:06 <rosmaita> it doesn't help non-members, but would be useful for us maybe
14:20:28 <rosmaita> #action rosmaita timezone.io invites to cinder-core
14:20:46 <rosmaita> ok, last announcement
14:21:02 <rosmaita> #topic announcements - follow-up on action item
14:21:20 <rosmaita> i am being very inconsistent about the topic changes
14:21:30 <rosmaita> they "orgainze" the minutes
14:21:33 <rosmaita> anyway
14:21:46 <rosmaita> i only got around to my action item this morning
14:21:56 <rosmaita> it was to email the QA team about taking over some devstack plugins
14:22:19 <rosmaita> so i figured i could put a draft on an etherpad for anyone who is interested in this
14:22:28 <rosmaita> to make sure i covered the concerns correctly
14:22:40 <rosmaita> #link https://etherpad.openstack.org/p/Z0rk9QPpOY
14:23:00 <rosmaita> please take a look if you can, feel free to make revisions or bring up stuff i forgot
14:23:33 <rosmaita> i'll send it out around 2pm my time, which i think is 1900 UTC
14:23:45 <rosmaita> ok, that's it for announcements
14:23:59 <rosmaita> #topic policy change proposal questions
14:24:12 <rosmaita> i added this because we didn't have any topics earlier this morning
14:24:35 <rosmaita> anyway, we may already have a policy about this that i'm ignorant of
14:24:38 <e0ne> rosmaita: feel free to remove my one :)
14:24:38 <rosmaita> #link https://review.opendev.org/#/c/678799/
14:24:53 <rosmaita> e0ne: no, i am looking forward to yours!
14:25:08 <rosmaita> so, the proposal is to make a policy more fine grained
14:25:16 <rosmaita> so instead of just MANAGE
14:25:24 <rosmaita> have MANAGE_CREATE
14:25:28 <rosmaita> MANAGE_UPDATE
14:25:31 <rosmaita> MANAGE_DELETE
14:25:34 <rosmaita> something like that
14:26:02 <rosmaita> so that part i'm ok with, though the naming scheme isn't quite in line with the other policies in that file
14:26:04 <e0ne> it sounds reasonable
14:26:08 <rosmaita> my question is
14:26:09 <eharney> i seem to recall a similar change for a different policy item, we should look at the last one for consistency/concerns... but generally i think this works
14:26:26 <rosmaita> they propose to just remove MANAGE (the current policy that covers all CRUD)
14:26:39 <rosmaita> but that would break anyone who's already configured that policy
14:26:53 <rosmaita> becuase now only the default values for the new ones will work
14:27:10 <rosmaita> so my question is (for real this time)
14:27:17 <rosmaita> how do we handle this?
14:27:44 <rosmaita> since the default is whatever the admin-api default is, i'm not worried about security
14:27:54 <rosmaita> but it could be annoying
14:28:10 <eharney> i'm not sure of the significance of the 'path' changes
14:28:21 <rosmaita> is a release note enough, or do we need something in the code to handle both during a deprecation period?
14:28:40 <rosmaita> eharney: yeah, i didn't look closely at that, i think that's only used for generating the sample file
14:29:00 <rosmaita> as a documentation thing
14:29:43 <rosmaita> well, we don't have to settle this now
14:29:59 <rosmaita> just wanted to bring it up in case we already had an answer somewhere
14:30:37 <rosmaita> that's all from me
14:30:46 <eharney> one sec
14:30:51 <eharney> https://review.opendev.org/#/c/571563/ was the last one
14:30:56 <rosmaita> thanks
14:31:01 <eharney> maybe we learned something there
14:31:14 <eharney> (that's all)
14:31:55 <rosmaita> thanks, that is helpful -- looks like some of these points came up on the review
14:32:35 <rosmaita> i'll look it over and revisit next week if there are still open questions
14:32:57 <rosmaita> #topic changes for backup configuration
14:33:01 <rosmaita> e0ne: that's you!
14:35:11 <e0ne> thanks, rosmaita
14:35:38 <e0ne> I'm hitting with volume drivers configuration for a generic backups
14:36:14 <e0ne> probably, this will require a new spec or update an old one, but I would like to have some feedback sooner
14:36:42 <e0ne> my idea is to decouple backup-specific configuration from the [DEFAULT] section
14:37:13 <e0ne> so we can implement 2 solutions:
14:37:24 <e0ne> 1) just add a [backup] section
14:37:56 <e0ne> 2) allow volume drivers confit to have 'is_backup' flag and add 'enabled_backup_backends' section
14:38:25 <e0ne> #2 will be a less complex to implement
14:38:31 <eharney> why is the 'is_backup' flag needed if the backend is listed in enabled_backup_backends?
14:38:48 <e0ne> eharney: you're right, we don't need it
14:39:19 * e0ne didn't recovered from the vacation yet:(
14:39:32 <jungleboyj> e0ne:  That is a good problem to have.
14:39:35 <rosmaita> hope that means you had a good vacation!
14:39:47 <e0ne> so #2 is to add `enabled_backup_backends` config option
14:40:07 <e0ne> I prefer to follow this way with enabled_backup_backends
14:40:14 <jungleboyj> So, enabled_backup_backends would be just like enabled_drivers right.  Just for backups?
14:40:15 <e0ne> rosmaita: I did:)
14:40:20 <e0ne> jungleboyj: yes
14:40:23 <eharney> do we support something like volume multi-backend for backups?
14:40:51 <jungleboyj> Would it use the same [volume] config section?
14:40:56 <e0ne> eharney: technically, we support it now, but we can't schedule backups to the specific host/backend
14:41:03 <jungleboyj> Or would a separate one need to be created for backup?
14:41:34 <eharney> it would be a new section to create another instance of the volume driver (as a backup driver), i think
14:41:48 <e0ne> jungleboyj: sorry, didn't get your question
14:42:48 <jungleboyj> If the section to configured the driver for backup would need to be a new section in the file.
14:43:14 <e0ne> jungleboyj: yes, it will be a new section in a cinder.conf
14:43:38 <jungleboyj> Ok.
14:43:39 <e0ne> and I do understand that we need to care about backward-compatibility
14:44:08 <jungleboyj> I think that that approach makes sense.
14:45:08 <e0ne> do I need to propose a spec for this?
14:45:23 <smcginnis> That would probably be good.
14:45:26 <eharney> yes
14:45:34 <smcginnis> Seems like there are enough details that we need to capture and understand.
14:45:41 <rosmaita> it will make the documentation easier later, too
14:46:03 <jungleboyj> Yeah.
14:46:13 <rosmaita> it sounds reasonable, though
14:47:00 <e0ne> ok, I'll come back with a spec and some code before the next meeting
14:47:20 <rosmaita> great!
14:47:39 <jungleboyj> ++
14:47:52 <rosmaita> #topic open discussion
14:48:06 <LiangFang> hi team, I have two questions about plugin. 1) who would create the repo devstack-plugin-open-cas please? me or cinder cores? 2) This plugin would be called by CI, right? Where can I find the code of CI, so I can make sure devstack-plugin-open-cas works correctly with CI. Thanks.
14:48:24 <e0ne> thanks for the feedback!
14:48:46 <smcginnis> LiangFang: Infra would need to create any repos.
14:49:13 <rosmaita> yeah, i guess the first thing would be to request the repo
14:49:31 <rosmaita> as far as creation goes, it would be you, mostly
14:49:44 <smcginnis> LiangFang: You would need to test locally to make sure it works with devstack. Then create a zuul job that uses it to run tempest (or whatever other kind of testing).
14:50:33 <LiangFang> ok, so I need to contact infra team, right?
14:50:47 <rosmaita> i guess the devstack-ceph-plugin and the stuff in devstack/lib/cinder/plugins would be good examples of how to wire it together
14:51:20 <rosmaita> LiangFang: yes, i think there's a doc page explaining this, i will look while we are talking
14:51:48 <LiangFang> thanks, I will take a look of doc
14:52:08 <rosmaita> i think this is it:
14:52:12 <rosmaita> #link https://docs.openstack.org/infra/manual/creators.html
14:52:20 <LiangFang> thanks
14:52:28 <rosmaita> there's probably stuff in there that you won't need to do
14:52:42 <rosmaita> LiangFang: ping me if you need help on getting this set up
14:52:51 <LiangFang> I will study how to create a zuul job from some doc
14:52:57 <LiangFang> rosmaita: thanks
14:53:18 <rosmaita> LiangFang: btw, the name of the software is "open-cas", not "opencas" -- is that right?
14:53:32 <eharney> i can maybe look at how i did this for devstack-plugin-nfs, but that was years ago
14:53:58 <LiangFang> I see the name is: OpenCAS or open-cas
14:54:13 <LiangFang> eharney: thanks
14:54:13 <rosmaita> ok, we can keep the hyphen
14:54:20 <LiangFang> ok
14:54:29 <rosmaita> just want to be sure ... it's always really hard to rename anything
14:55:02 <rosmaita> so 'devstack-plugin-open-cas' seems good
14:55:37 <LiangFang> https://open-cas.github.io/getting_started_open_cas_linux.html
14:55:51 <LiangFang> they are using open-cas
14:56:08 <rosmaita> great, that settles it
14:56:51 <rosmaita> just a few minutes left ... anyone have anything they'd like to bring up?
14:57:58 <LiangFang> do you know how to publish a white paper in openstack website?
14:58:30 <rosmaita> LiangFang: no, maybe contact jimmy mcarthur? anyone know?
14:58:40 <smcginnis> LiangFang: Yeah, you can ask Jimmy.
14:58:58 <smcginnis> Either a superuser article, or on a blog that would get picked up by plant.o.o.
14:59:13 <rosmaita> Jimmy McArthur <jimmy@openstack.org>
14:59:22 <LiangFang> thanks:)
14:59:25 <jungleboyj> Yeah, I would start with Jimmy.
14:59:45 <rosmaita> ok, i guess that's it for today ... thanks everyone!
14:59:51 <jungleboyj> Thank you!
15:00:00 <rosmaita> #endmeeting