16:00:14 <smcginnis> #startmeeting cinder
16:00:16 <openstack> Meeting started Wed Apr 10 16:00:14 2019 UTC and is due to finish in 60 minutes.  The chair is smcginnis. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:17 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:19 <openstack> The meeting name has been set to 'cinder'
16:00:20 <rajinir> hi
16:00:24 <geguileo> hi! o/
16:00:25 <rosmaita> o/
16:00:26 <whoami-rajat> Hi
16:00:27 <smcginnis> rosmaita: I waited. :)
16:00:38 <smcginnis> Ping jungleboyj diablo_rojo, diablo_rojo_phon, rajinir tbarron xyang xyang1 e0ne gouthamr erlon tpsilva ganso patrickeast tommylikehu eharney geguileo smcginnis lhx_ lhx__ aspiers jgriffith moshele hwalsh felipemonteiro lpetrut lseki _alastor_ whoami-rajat yikun rosmaita enriquetaso hemna _hemna
16:00:43 <smcginnis> For reals this time.
16:00:44 <e0ne> hi
16:00:47 <xyang> hi
16:00:48 <lseki> hello
16:00:51 <_alastor_> o/
16:00:52 <carloss> hi :)
16:00:53 <e0ne> smcginnis: :)
16:01:01 <smcginnis> I'm just the substitute. :)
16:01:18 <whoami-rajat> 2 cinder meetings in 1 day :)
16:01:35 <smcginnis> :)
16:01:39 <e0ne> we need the 2nd cinder release now
16:01:45 <smcginnis> #link https://etherpad.openstack.org/p/cinder-train-meetings Agenda
16:01:56 <smcginnis> #topic Announcements
16:02:25 <smcginnis> The Train PTG is coming up the Thurs-Sat after the Summit.
16:02:33 <smcginnis> Trying to collect topics here:
16:02:36 <smcginnis> #link https://etherpad.openstack.org/p/cinder-train-ptg-planning
16:02:45 <smcginnis> Please add anything that needs to be discussed.
16:02:50 <_erlon_> hey
16:03:19 <smcginnis> Jay is also trying to coordinate a dinner/outing for the team
16:03:21 <smcginnis> #link https://etherpad.openstack.org/p/cinder-train-dinner-plan
16:03:39 <smcginnis> Anyone that will be in Denver - it would be great to get us all together.
16:04:21 <smcginnis> I'm sure he will have more updates as far as location and other details.
16:04:37 <smcginnis> We aren't so far out from the city this time around, so there will probably be a lot of options.
16:05:05 <rosmaita> reminder: anyone with dietary restrictions, please put them on that etherpad
16:05:14 <smcginnis> ++
16:05:31 <smcginnis> I processed the final stein release this morning, so we are now officially on to train.
16:05:40 <rosmaita> \o/
16:05:41 <whoami-rajat> \o/
16:05:45 <smcginnis> Please take a look at the new driver patches so we can get those out of the way as soon as possible.
16:05:48 <smcginnis> #link https://review.openstack.org/#/q/topic:train-drivers+status:open
16:06:20 <smcginnis> I know one or two (RSD at least) were pretty close at the stein deadline, so it would be great if we can help those folks relax and not leave them sit out there too long.
16:07:04 <whoami-rajat> it was due to CI not running all tests IIRC ?
16:07:12 <smcginnis> And finally, we are overdue for stable/pike to enter "Extended Maintenance" phase.
16:07:25 <smcginnis> whoami-rajat: That could be for some. Hopefully they've all sorted that out by now.
16:07:43 <whoami-rajat> smcginnis: ok
16:07:50 <rosmaita> looks like we're in good shape for final stable/pike releases except for os_brick
16:07:52 <smcginnis> With EM phase, we can still choose to backport fixes, but there will no longer be official releases of that stable branch.
16:07:59 <rosmaita> some outstanding patches there
16:08:03 <smcginnis> So we need to get a final pike release out while we can.
16:08:15 <smcginnis> rosmaita: Thanks for pulling all of that together.
16:08:17 <smcginnis> #link https://tiny.cc/cinder-stable-pike
16:08:28 <smcginnis> #link https://etherpad.openstack.org/p/cinder-releases-tracking
16:08:53 <smcginnis> Stable cores, please look at open patches when you can. Other reviews welcome too of course.
16:09:14 <smcginnis> #topic Cinder/Nova Cross Project Discussion
16:09:16 <rosmaita> quick question about pythong-brick-cinderclient-ext ... no functional changes, do we want to do a final release just to have no un-merged patches?
16:09:29 <smcginnis> I was signed up for this one by Jay, so I don't have too much detail. :)
16:09:54 <smcginnis> But as usual, we will have some time with Nova at the PTG to go through cross-project things.
16:10:04 <smcginnis> #link https://etherpad.openstack.org/p/nova-ptg-train   Line 230
16:10:30 <e0ne> rosmaita, smcginnis: IMO, it's better to make a final release with current changes if some vendors uses only releases
16:10:32 <smcginnis> If anyone has topics that should be discussed that involve any kind of Cinder<>Nova interaction, please get those topics added.
16:10:41 <smcginnis> e0ne: ++ Yep, I agree.
16:10:50 <rosmaita> ok, thanks
16:11:02 <smcginnis> The extended maintenance phase is really kind of like what we did with driverfixes/*
16:11:19 <smcginnis> Just a place for fixes to be kept so everyone isn't forking their own repos to hold them.
16:11:29 <smcginnis> But actual releases are best.
16:11:40 <e0ne> smcginnis: +1
16:11:55 <whoami-rajat> smcginnis: L 249? it will change anyway.
16:12:02 <smcginnis> OK, as far as the Cinder/Nova session, I haven't seen a specific time for that.
16:12:19 <smcginnis> whoami-rajat: Yeah. Look "somewhere around that area" ;)
16:12:29 <smcginnis> Watch for more details about when that will take place.
16:12:50 <smcginnis> Typically in the past we've just joined Nova in their room since they end up with a larger room and it's just easier.
16:13:09 <smcginnis> So if anyone shows up to the PTG and the Cinder room is empty, check the nova room.
16:13:14 <smcginnis> Or the bar. :P
16:13:46 <smcginnis> Any questions about any of that?
16:14:45 <smcginnis> OK, moving on then.
16:15:39 <smcginnis> Oh, but first, please add your name/nick to the PTG etherpad so we can get an idea of who will actually be there: https://etherpad.openstack.org/p/cinder-train-ptg-planning
16:15:49 <smcginnis> Alright, now moving on...
16:16:06 <smcginnis> #topic Adding is-public arg to cinderclient
16:16:09 <smcginnis> whoami-rajat: All yours
16:16:40 <smcginnis> #link https://review.openstack.org/#/c/641698/
16:16:53 <whoami-rajat> So the patch is receiving multiple suggestions and Eric thought that we need to discuss what the exact parameter should be and where it should reside (inside the --filters or as a separate arg)
16:17:01 <whoami-rajat> eharney:  ^^
16:17:08 <eharney> well
16:17:30 <eharney> it's not at all clear why we would add a new arg for this while we are actively deprecating other similar args from the list command
16:17:38 <eharney> what is the intent or policy here?
16:17:56 <smcginnis> Generic filters were added to prevent the need to keep adding new args.
16:18:14 <eharney> which is... questionable for usability, but good for the code, i think
16:18:31 <geguileo> I like the idea of adding it as a filter
16:18:40 <whoami-rajat> so i added the new arg as it is fairly an old option for the API, and keeping in it filters would require 3.52 MV or higher
16:18:43 <eharney> i asked in the review if there was some reason it could not be done via filters
16:18:44 <e0ne> geguileo: +1
16:19:32 <geguileo> whoami-rajat: the CLI can receive it as a filter, and internally decide how to pass it to the server, right?
16:20:45 <whoami-rajat> geguileo:  need to check, but yeah it can be added in filter.
16:20:48 <eharney> what would a user pass in to use this w/ filters?
16:21:00 <eharney> because as Brian pointed out, the --is-public boolean is not exactly straightforward
16:22:08 <geguileo> eharney: yeah, rosmaita raise an important point there
16:22:25 <rosmaita> it might not be so bad with --filter, though
16:22:26 <eharney> calling "cinder list --visibility private" is way more sensible than "cinder list --filters is_public=False"
16:22:59 <eharney> which kind of makes me wonder where we were going with the idea of deprecating --bootable, --status, etc
16:23:07 <geguileo> eharney: it is indeed more sentible, but it kind of diverges from what we usually do, right?
16:23:21 <eharney> geguileo: i'm trying to figure out if what we usually/currently do is actually reasonable or not
16:23:31 <eharney> and i'm not really sure yet
16:24:20 <eharney> because replacing "--bootable true" with "--filters bootable=true" seems like something just designed to be annoying when there's no reason we couldn't just map "--bootable true" into whatever API we want
16:24:34 <rosmaita> :)
16:24:37 <smcginnis> True
16:25:20 <geguileo> eharney: I kind of prefer the filters thing  XD
16:25:28 <eharney> i... really don't
16:25:40 <eharney> but anyway, is it possible to do this with --filters currently w/o changing the client?
16:26:02 <whoami-rajat> geguileo: filters are just updated inside search_opts so yeah we can decide what to send to API.
16:26:03 <eharney> just to know where we are starting from
16:26:15 <rosmaita> i think that's the key question, because if we have to change the client, might as well make it a good usability change
16:26:43 <rosmaita> the only advantage i see to --filters is if we don't have to change the client to handle new filters
16:27:10 <smcginnis> That was the intent for how it should work.
16:27:26 <smcginnis> Then you don't need a new client release every time we add yet another thing to filter on.
16:27:34 <rosmaita> right, makes sense
16:27:45 <whoami-rajat> smcginnis: and can be backported as well?
16:27:56 <eharney> backporting is a whole separate discussion from any of this for now
16:28:05 <eharney> let's just worry about cinderclient master
16:28:37 <smcginnis> Shouldn't be a need to backport, since the mechanism just allows whatever attribute you want to filter on to be passed through.
16:28:51 <smcginnis> So older clients can work with newer servers and vice versa.
16:28:59 <smcginnis> But yeah, let's just focus on master for now.
16:29:05 <whoami-rajat> i think this option started with the discussion of backporting to stein, but yeah first concluding the master is better.
16:29:49 <eharney> worrying about stein is a huge distraction from trying to design cinderclient's interface
16:30:12 <whoami-rajat> eharney: ++
16:31:09 <smcginnis> So I'm not clear where things stand. Are we actually fine with the client as it is today with being able to use --filter?
16:31:11 <eharney> one argument against --filters is that it exposes cinder db internals to the shell interface
16:32:21 <rosmaita> also, i think what you can actually filter on isn't available in the help, right?
16:32:28 <eharney> right
16:32:46 <eharney> also, --filters doesn't work correctly, which is really an implementation bug, but maybe worth keeping in mind here:  https://bugs.launchpad.net/python-cinderclient/+bug/1696780
16:32:47 <openstack> Launchpad bug 1696780 in python-cinderclient "supplying multiple list --filters does not work correctly" [Undecided,New] - Assigned to Rajat Dhasmana (whoami-rajat)
16:32:48 <smcginnis> Didn't that include a way to query what the available filters were? I thought that was part of it.
16:33:11 <smcginnis> Because administrators could also control some of that.
16:33:31 <eharney> you can specify what fields can be filtered in the server config
16:33:46 <eharney> i don't think you can query for them..?
16:34:00 <whoami-rajat> eharney: i remember that, when multiple filters are passed it only considers the first (or last) one.
16:34:08 <eharney> oh, "cinder list-filters"
16:34:34 <whoami-rajat> eharney: that just returns the resource_filters.json right?
16:34:59 <eharney> it lists the fields for each resource
16:36:06 <smcginnis> https://specs.openstack.org/openstack/cinder-specs/specs/pike/generalized_list_filters.html
16:36:45 <smcginnis> "The list-filters component is derived from an Admin provided list of valid and enabled filters for end users to access."
16:36:46 <eharney> which is kind of interesting because now it means that things like the message table's message_level field is exposed as a string via the API, which means we couldn't ever do something like change it to an integer in the database without going through a bunch of compat issues
16:37:49 <smcginnis> It's something that can be discovered by querying, so I think it's a little more flexible that an actual API change.
16:39:36 <smcginnis> So... next steps for is_public?
16:41:07 <smcginnis> Anyone?
16:41:19 <eharney> well 1) is make sure it actually works currently w/ --filters like we think it does
16:41:45 <smcginnis> whoami-rajat: Can you take that action? ^
16:41:50 <whoami-rajat> will update the code with --filters
16:42:00 <eharney> then we can categorize the addition of a new arg to the CLI as a usability improvement instead of something needed to enable the feature
16:42:14 <smcginnis> #action whoami-rajat to test --filters works with public visibility
16:42:22 <eharney> which, i dunno, gives us time to procrastinate until we figure out how this should actually be designed?
16:42:46 <smcginnis> If this is not a topic on the PTG etherpad, might be good to add it there to make sure we follow up.
16:43:07 <whoami-rajat> smcginnis: ++
16:43:13 <eharney> the generalized filters spec has an unfortunately link to a github gist which no longer exists.  maybe all the answers were in there
16:43:18 <eharney> unfortunate link*
16:43:23 <smcginnis> whoami-rajat: I will leave that to you as well. :)
16:43:36 <whoami-rajat> smcginnis: sure, will do!
16:43:43 <smcginnis> whoami-rajat: Thanks!
16:43:57 <smcginnis> eharney: I'm sure jgriffith has all the answers. :)
16:44:10 <smcginnis> A couple more topics. Are we good to move on?
16:44:25 <whoami-rajat> yep
16:44:40 <smcginnis> #topic User messages
16:44:46 <rosmaita> i will make this quick
16:44:46 <smcginnis> rosmaita: You have the floor.
16:44:49 <smcginnis> #link https://review.openstack.org/#/c/648294/
16:44:54 <rosmaita> i was reviewing some patches that add some user messages for the messages API and wasn't quite clear on how it's supposed to work
16:44:59 <rosmaita> i dug in the code a bit, thought i had found a bug, and then realized that it probably wasn't a bug
16:45:06 <rosmaita> anyway, i updated the contrib docs on user messages (the code had been refactored in pike to add the message_field stuff but the docs were not updated)
16:45:13 <rosmaita> i also added some tests so that some dope like me doesn't come along and "fix" something that is not broken
16:45:21 <rosmaita> the reason i am bringing this up is that i've only been working on cinder a few months, so it would be good for some people with more institutional memory to double-check me on this
16:45:28 <rosmaita> btw, i added a "usage patterns" section to the contrib docs so it's easy to see how to add them
16:45:39 <rosmaita> because adding user messages seems like a useful thing that new contributors can do that also has a high end-user impact
16:45:42 <smcginnis> Thanks for making that docs better with that!
16:45:48 <rosmaita> anyway, that's it from me
16:46:23 <smcginnis> I think we could still spend some time improving our user messages. Glad to see some attention there.
16:46:55 <rosmaita> yeah, they're used in surprisingly few places
16:47:21 <smcginnis> #topic cinderlib update
16:47:28 <smcginnis> geguileo: Your turn
16:47:29 <eharney> along similar lines, the client would love some more work adding --poll to other operations to get those messages
16:47:45 <geguileo> smcginnis: thanks
16:47:46 <geguileo> This will be quick
16:47:53 <smcginnis> eharney: ++
16:47:57 <smcginnis> #link https://review.openstack.org/649552
16:48:03 <geguileo> We are just 1 patch away from being able to release cinderlib
16:48:11 <geguileo> ^ that's the last patch
16:48:19 <rosmaita> \o/
16:48:30 <geguileo> After that we'll be able to release version 0.9 as the Stein release
16:48:44 <geguileo> as we agreed in last week's meeting
16:48:59 <smcginnis> geguileo: Thanks for all your work on that. There was a lot of churn over the course of that in stein.
16:49:31 <geguileo> and thank you all that helped with the reviews and making suggestions on how to do things
16:49:46 <geguileo> like using launchpad for the time being
16:49:53 <geguileo> and doing independent releases
16:49:56 <geguileo> it helped :-)
16:50:14 <geguileo> now I'm working on a document explaining how to validate cinderlib using devstack
16:50:25 <geguileo> and how to add it to the 3rd party CI jobs
16:50:37 <smcginnis> Oh nice. That will be good. That would be for those other backends that you have not been able to work with?
16:50:38 <geguileo> aaaaaaand that was all O:-)
16:50:54 <geguileo> smcginnis: and even for those that I have been able to work
16:51:01 <geguileo> because that way they can ensure that they keep working
16:51:22 <smcginnis> Third party CI would be good. I think we have a few things to talk about with CI at the PTG that we need to make sure all of the maintainers are aware of.
16:51:35 <smcginnis> Python 3 being the other major thing.
16:51:48 <geguileo> +1
16:52:06 <smcginnis> Thanks geguileo!
16:52:28 <smcginnis> #topic Open floor
16:52:37 <smcginnis> Anyone else have anything to bring up?
16:53:17 <smcginnis> Would be great to get a good start on Train. I have it on my list to take a look through specs.
16:54:25 <smcginnis> OK, I guess we can wrap up for today. Thanks everyone!
16:54:44 <rosmaita> bye!
16:54:49 <geguileo> thanks!
16:54:54 <smcginnis> #endmeeting