16:00:04 <smcginnis> #startmeeting Cinder
16:00:07 <openstack> Meeting started Wed Jan 11 16:00:04 2017 UTC and is due to finish in 60 minutes.  The chair is smcginnis. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:08 <smcginnis> ping dulek duncant eharney geguileo winston-d e0ne jungleboyj jgriffith thingee smcginnis hemna xyang1 tbarron scottda erlon rhedlind jbernard _alastor_ bluex patrickeast dongwenjuan JaniceLee cFouts Thelo vivekd adrianofr mtanino yuriy_n17 karlamrhein diablo_rojo jay.xu jgregor baumann rajinir wilson-l reduxio wanghao thrawn01 chris_morrell stevemar watanabe.isao,tommylikehu mdovgal ildikov
16:00:09 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:11 <openstack> The meeting name has been set to 'cinder'
16:00:14 <smcginnis> wxy viks ketonne
16:00:18 <e0ne> hi
16:00:21 <smcginnis> #topic Announcements
16:00:21 <xyang1> hi
16:00:22 <mdovgal> hi
16:00:25 <rarora> hi
16:00:28 <jgriffith> o/
16:00:31 <DuncanT> Hi
16:00:31 <_alastor_> o/
16:00:33 <wxy|> hello
16:00:33 <smcginnis> Obligatory:
16:00:34 <smcginnis> #link https://etherpad.openstack.org/p/cinder-spec-review-tracking Review focus
16:00:38 <bswartz> .o/
16:00:39 <guyr-infinidat> hi
16:00:40 <scottda> hola
16:00:50 <smcginnis> PTG is coming up!
16:00:50 <smcginnis> #info Need to register for the PTG if you have not already done so.
16:00:52 <geguileo> hi!
16:00:54 <adrianofr_> hi
16:00:57 <smcginnis> #link http://www.openstack.org/ptg PTG info and registration
16:01:11 <smcginnis> #link https://www.starwoodmeeting.com/events/start.action?id=1609140999&key=381BF4AA PTG Hotel reservations
16:01:12 <diablo_rojo> Hello :)
16:01:21 <ildikov> o/
16:01:29 <smcginnis> Just wanted to note for everyone that registering for the PTG hotel through the link helps.
16:01:49 <smcginnis> As part of holding the event there, there is some obligation to fill some of the rooms.
16:01:56 <smcginnis> And there's free breakfast!
16:02:05 <diablo_rojo> Yes please make sure you book through our reserved hotels :)
16:02:13 <smcginnis> #info Need to start planning for the PTG
16:02:14 <diablo_rojo> Yay breakfast!
16:02:21 <jungleboyj> Hello.
16:02:22 <smcginnis> #link https://etherpad.openstack.org/p/ATL-cinder-ptg-planning PTG topic planning etherpad
16:02:34 <jungleboyj> Breakfast?  Did I miss something?
16:02:41 <smcginnis> Breakfast? :)
16:02:49 <jungleboyj> smcginnis: True story.
16:03:01 <smcginnis> #info Summit call for presentations is open
16:03:13 <smcginnis> Let's get some good storage sessions for the Summit.
16:03:19 <smcginnis> #link https://www.openstack.org/summit/boston-2017/call-for-presentations/ Summit CFP
16:03:25 <kaisers_> Hi
16:03:41 <smcginnis> If you have ideas for anything you would like to talk about that would be beneficial, please submit a proposal.
16:04:00 <smcginnis> It may or may not make it, but it definitely won't if you don't submit it. ;)
16:04:59 <jgriffith> smcginnis I would like to discuss climate change
16:05:04 <e0ne> :)
16:05:08 <smcginnis> And this one might actually be its own topic, but just to make sure driver maintainers know, we would like CG support migrated to generic groups by P-1 if possible.
16:05:17 <smcginnis> jgriffith: How Cinder is destroying the climate!
16:05:20 <jungleboyj> jgriffith: You can do that after you solve the problem.
16:05:26 <smcginnis> jgriffith: Good chance of getting in. ;)
16:05:28 <jgriffith> smcginnis yes!  It's all our fault
16:05:33 <xyang1> just want to make sure driver maintainers see the email about migrating CGs to groups
16:05:35 <smcginnis> And vendors. :D
16:05:42 <smcginnis> #link http://lists.openstack.org/pipermail/openstack-dev/2017-January/109899.html Migrate CGs to Generic Volume Groups update
16:06:03 <smcginnis> #topic New Cinder Attach/Detach API
16:06:10 <smcginnis> ildikov and jgriffith: All yours.
16:06:23 <ildikov> smcginnis: tnx :)
16:06:52 <ildikov> so the topic is not new I think most of you already know that new Attach/Detach API is on it's way b jgriffith
16:07:06 <ildikov> we desperately need code review and attention from the team at this point
16:07:19 <ildikov> Cinder patch: #link https://review.openstack.org/#/c/414632/
16:07:35 <ildikov> client patch: #link https://review.openstack.org/#/c/387716/
16:07:42 <jgriffith> and I'm working on updating the client patch this morning
16:07:49 <jgriffith> it's out of date with some of the changes just FYI
16:07:53 <smcginnis> Not sure the bot picks it up inless it starts with the #
16:07:56 <smcginnis> #link https://review.openstack.org/#/c/414632/ Cinder patch
16:08:04 <smcginnis> #link https://review.openstack.org/#/c/387716/ Client patch
16:08:36 * dulek signs in for cinder patch.
16:08:38 <hemna> sweet
16:08:39 <smcginnis> jgriffith: The service side is up to date though, correct? Or changes coming on that.
16:08:43 <ildikov> if there's any questions regarding to this that we should discuss here, please  let us know
16:09:11 <ildikov> we also started to investigate to enable Cinder v3 in Nova, scottda has a patch up for it
16:09:26 <ildikov> #link https://review.openstack.org/#/c/385682/
16:09:45 <ildikov> that's hitting EndpointNotFound error for seemingly no good reason
16:09:53 <scottda> Yeah, I'm not sure mriedem was on board with making that the default for Nova yet...
16:10:06 <scottda> nor am I sure we are ready. We need it running in some Nova jobs first.
16:10:14 <mriedem> cinder v3?
16:10:18 <scottda> yup
16:10:22 <mriedem> not without the damn thing actually working :)
16:10:31 <smcginnis> mriedem: You're so picky.
16:10:34 <scottda> YOu are picky
16:10:37 <scottda> jinx
16:10:37 <ildikov> scottda: just at least investigating why the config option does not work as expected
16:10:38 <mriedem> i'd like to enable cinder v3 in the placement job for nova, where our other bleeding edge stuff goes
16:10:40 <smcginnis> hah
16:10:43 <hemna> it's the openstack way.
16:10:47 <hemna> use it before it works.
16:10:50 <jungleboyj> mriedem: Details, details!
16:11:08 <mriedem> the problem is passing a config through from the project-config to devstack-gate to devstack to configure nova,
16:11:12 <smcginnis> Yeah, working out the issues and making sure it _can_ work is a good first step.
16:11:17 <scottda> OK, well it's getting starved out in my queue...I haven't even looked lately
16:11:19 <mriedem> when we don't have post-config working yet for that plumbing
16:11:33 <smcginnis> Then by Pike we will have had v3 out for 2 releases and it should be safer considering it for the default.
16:11:35 <ildikov> smcginnis: the service side patch has a few comments, but I would still encourage everyone to look into it earlier rather than later
16:11:36 <scottda> I've gotten it to work manually, so it's a config/infra thing I believe
16:11:37 <mriedem> well, ^ infra job plumbing is the 2nd issue
16:11:41 <mriedem> making it work is the first
16:11:42 <smcginnis> ildikov: +1
16:12:35 <ildikov> smcginnis: BTW, what is the deadline to get this landed?
16:12:45 <ildikov> smcginnis: in Ocata I mean :)
16:13:20 <smcginnis> ildikov: I think if we aren't extrememly close by O-3, we better wait until Pike.
16:13:26 <smcginnis> ildikov: Ideally before O-3.
16:13:42 <ildikov> dulek: tnx for signing in :)
16:13:45 <smcginnis> ildikov: But jgriffith likes to land large features at code freeze, so we'll see. :P
16:14:01 * jgriffith looks away
16:14:04 <smcginnis> hehe
16:14:22 * jungleboyj remembers jgriffith scolding me for that in the past.  ;-)
16:14:30 <ildikov> smcginnis: LOL, if it's shoehorned in Ocata still I think I'm fine :)
16:14:38 <bswartz> do as I say not as I do!
16:14:44 <jgriffith> We can wait til Pike, no worries
16:14:47 <smcginnis> So everyone please review the patches if you can.
16:14:47 <jungleboyj> bswartz: :-)
16:14:54 <jgriffith> TBF the patches have been up for 4 months now
16:15:13 <smcginnis> jgriffith: Yeah, we can. Would be great if we can get it in O though so there's a chance Nova may use it in P.
16:15:15 <ildikov> smcginnis: would make it better to move forward with the Nova parts to have the initials in Cinder as soon as we can
16:15:26 <scottda> yeah, I think we merge things late because we review and test late...
16:15:27 <smcginnis> ildikov: Totally agree.
16:15:28 <jungleboyj> ildikov: ++
16:15:37 <smcginnis> scottda: That's a fair statement too.
16:15:41 <ildikov> smcginnis: :)
16:15:45 <jungleboyj> This is one of those things that will just drag out forever.
16:15:51 <smcginnis> jungleboyj: Shsuh
16:15:53 <smcginnis> *shush
16:16:06 <jgriffith> So what's strange about all this is this is what I thought the glorious almighty micro-versioning madness was supposed to buy us
16:16:10 <ildikov> smcginnis: +1 :)
16:16:17 <smcginnis> jgriffith: Rebases?
16:16:27 <jgriffith> smcginnis haha!  Well it's certainly GREAT for that
16:16:34 <scottda> microversion just lets you add the new API, and NOva can see it's there and use it.
16:16:40 <jungleboyj> smcginnis: Shsuh?
16:16:45 <smcginnis> jungleboyj: sdjalksdghvailuga
16:16:59 <jungleboyj> smcginnis: a;dsfjadslfjal;sdjfa;ldsfkja
16:17:02 <jgriffith> scottda we're not doing anything differently than we ever have :(
16:17:11 <jgriffith> we're just making it *harder*
16:17:36 <jgriffith> and it's madness that we've added 23 versions to the API in the last 4 months
16:17:51 <scottda> Well, it's really just semver...
16:17:56 <mdovgal> jungleboyj, is it elfin language? :)
16:17:58 <scottda> Add a new api, bump the minor version.
16:18:01 <smcginnis> jgriffith: This is part of the reason I would prefer to batch changes and only bump on release. We're just constantly stepping on each other's toes.
16:18:01 <jgriffith> usability is going to suck
16:18:10 <jgriffith> smcginnis YES PLEASE!!!!
16:18:18 <smcginnis> Then you would know O is 3.12, P is 3.13, etc.
16:18:31 <jungleboyj> mdovgal: Must be.
16:18:32 <e0ne> smcginnis: +1
16:18:43 <diablo_rojo> smcginnis, +1
16:18:44 <jgriffith> smcginnis I'd even take it further... have an 'N' release every each release
16:18:46 <scottda> As long as you don't deploy from Master...
16:18:46 <ildikov> smcginnis: that would be a good compromise I think, had the same thought a while back
16:18:47 <hemna> the current model makes sense if you are using master for deployment though.
16:18:49 <winston-1> smcginnis: +1
16:19:00 <jgriffith> smcginnis ie when we open Pike we bump the number to V4
16:19:03 <e0ne> hemna: good point
16:19:06 <jgriffith> everything new goes in V4
16:19:11 <scottda> We support deploying from master..but if we want to stop that, OK.
16:19:22 <jgriffith> when we open Q we go to V5
16:19:24 <jgriffith> etc
16:19:28 <hemna> otherwise you'd have lots of changes going into the API during the release cycle and no version change.  :(
16:19:35 <jgriffith> scottda you can still deploy from master that way
16:19:36 <jungleboyj> jgriffith: Isn't that what we used to do ... Oh you mean always bump it with the release.
16:19:39 <smcginnis> scottda: I still would like to see justification why we absolutely need to support CD. Our contract should just be on official release boundaries, as far as I'm concerned.
16:19:44 <jgriffith> scottda and sorry, but that whole thing is a farce anyway
16:20:01 <jgriffith> people can barely deploy from release without heroic efforts from distros
16:20:03 <scottda> I don't care one way or another. It's just he model that exists.
16:20:12 <scottda> s/he/the
16:20:22 <jgriffith> scottda I know.. and it's also being pushed by the cross-project thing
16:20:27 <jgriffith> but I think it sucks
16:20:34 <scottda> And Cinder can go it's own way, but the rest of openstack thinks differently...
16:20:35 <jgriffith> and I'm not afraid to voice my opinion
16:20:43 <smcginnis> Is it actually stated somewhere in writing that we must support continuous deployment?
16:20:44 <hemna> also, if you don't bump the micro version on the API change, then we are back to basically the old model, which was also broken.
16:20:46 <hemna> :(
16:20:53 <hemna> bleh, whatevs
16:21:33 <scottda> Yeah, we've had releases of the client that have features that might or might not be in the server...how do you know?
16:21:34 <jgriffith> hemna I've never understood what exactly was *broken*
16:21:41 <smcginnis> hemna: I'm fine having a bunch of API changes in one microversion. You just need to know what given release corresponds to what microversion for the feature you want.
16:21:43 <jgriffith> other than lack of process and documentation
16:21:54 <jgriffith> smcginnis +1
16:22:02 <hemna> smcginnis, who coordinates doing the version bump in 5 different people doing patches?
16:22:04 <jgriffith> I suppose this is a PTG discussion
16:22:11 <hemna> this will be a nightmare IMHO.
16:22:19 <jgriffith> and will have significant ramifications from the overlords in other OS projects
16:22:23 <smcginnis> hemna: You just do it once when the new cycle starts, then you wait and do it again when the next one does.
16:22:29 <jgriffith> hemna why?
16:22:46 * jungleboyj loves how the PTG agendas develop before a meeting.  :-)
16:22:49 <hemna> you bump the version with no real changes at the start of the cycle?
16:22:54 <hemna> smh
16:23:02 <smcginnis> And in the mean time, if you specify a microversion and the api is not there - stop running off of master.
16:23:10 <hemna> makes absolutely no sense to me.
16:23:16 <jgriffith> hemna IMHO what we're doing now is a nightmare, and the VERY FEW customers I have that are newer than Kilo at this point have been asking how the hell the versiioning stuff works
16:23:20 <smcginnis> hemna: You will have changes in the cycle though.
16:23:29 <smcginnis> And until the cycle is released, who cares?
16:23:29 <jungleboyj> hemna:  Why?  Concerned that there will be no changes for the new version?
16:23:38 <jgriffith> hemna yep, because it's a new release of the prject/software
16:23:46 <scottda> So, people might not like semver, but it's a bit of a standard. Breaking changes, you up the major version. non-breaking change you up the minor version
16:23:50 <jungleboyj> I guess that could happen, but unlikely.
16:23:51 <jgriffith> hemna god forbid we version our software
16:24:00 <hemna> ok if you say so.  it makes no sense to me.  uber complicated that nobody will understand.
16:24:17 <smcginnis> Seems much less complicated, but I guess that's just me.
16:24:23 <jungleboyj> Isn't what we do more complicated.
16:24:23 <hemna> anyway, I'll shut up since I'm in the minority.
16:24:24 <jgriffith> hemna fair enough
16:24:25 <hemna> never mind.
16:24:36 <jungleboyj> You have to specify a special version to get a function?
16:24:49 <smcginnis> jungleboyj: A microversion.
16:24:50 <jungleboyj> smcginnis: I hear you.
16:24:54 <jgriffith> hemna different perspectives I guess, I see the micro madness as uber complex and confusing and the alternate super easy :)
16:25:01 <smcginnis> jungleboyj: Right now it is for each and every API change.
16:25:03 <hemna> how is versioning each API change complicated?   I seriously don't get that.
16:25:13 <hemna> you changed something, it's a new version.
16:25:15 <jungleboyj> smcginnis: I know, that is confusing to me.  :-)
16:25:22 <jgriffith> hemna have you tried using it?
16:25:28 <hemna> now we'll have random versions for something that never happened or didn't change anything, just because....
16:25:42 <scottda> It'd be nice to know what users think...
16:25:45 <smcginnis> hemna: I doubt we would have a release with no API changes.
16:26:03 <hemna> smcginnis, you just suggested changing the API version at the start of a release.
16:26:04 <smcginnis> hemna: But fair enough, then we bump the microversion with the first patch that actually does change it.
16:26:10 <hemna> nm.
16:26:11 <jgriffith> hemna oh.. that explains the confusion sorry
16:26:16 <DuncanT> jgriffith: I have tried using it. Literally the only thing I find a problem is there's no 'just use the max version' for show commands where I want to see everything that the server can tell me
16:26:19 <smcginnis> hemna: Because I know we never have a release without an API change.
16:26:31 <hemna> I have to bail to take my kid to school.  l8rs
16:26:33 <jgriffith> hemna we should chat later and I'll try and explain what I meant.  I don't think it's what your envisioning
16:26:40 <jungleboyj> smcginnis: That could work.
16:26:49 <smcginnis> It's a DuncanT!
16:26:52 <bswartz> DuncanT: that's by design
16:26:56 <jgriffith> DuncanT yeah.. but you're "Duncan" :)
16:27:18 <smcginnis> OK, I think we've gone down a rabbit hole. Let's get back to the agenda.
16:27:26 <smcginnis> #topic Manual Testing for Ocata release
16:27:26 <DuncanT> jgriffith: I think batching during a release can work just as well iif you abandon the idea that you can deploy from trunk and have a sane system
16:27:28 <jgriffith> sorry.. that was completely my fault
16:27:32 <jungleboyj> A DuncanT is good to see!
16:27:33 <smcginnis> scottda: Save us please! :)
16:27:35 <scottda> #link https://etherpad.openstack.org/p/cinder-ocata-testing
16:27:37 <jungleboyj> It is good luck.
16:27:49 <DuncanT> jgriffith: I just fail to understand why 1 version bump per release is easier to understand
16:27:50 <scottda> There's a page for things that need testing before the release ^^^^
16:28:11 <DuncanT> jungleboyj: I may be vanishing for good from cinder soon :-( We'll see
16:28:11 <scottda> We discovered in Newton that we have an ad hoc way of testing things that lack Tempest tests...
16:28:23 <scottda> i.e Just hope that someone tests them.
16:28:29 * jungleboyj doesn't want to hear that!
16:28:30 <smcginnis> scottda: :)
16:28:55 <scottda> Generic groups, upgrades, DB migrations, AA/HA,...these need to be tested, and others.
16:29:18 <scottda> Some folks are already doing this, either because they own the feature, or care , or whaever
16:29:23 <smcginnis> I think good old fashioned exploratory testing can find a lot of things.
16:29:36 <scottda> So, please add thing to the etherpad as needed, and sign up if you are testing.
16:29:40 * e0ne is worried how many manual tests we have to run before the each release
16:29:44 <scottda> That will at least help us identify gaps.
16:29:59 <scottda> e0ne: Yeah, getting automated tests is a separate issue...
16:30:13 <scottda> e0ne: That is the ideal. But in reality, this is our situation.
16:30:19 <smcginnis> e0ne: Probably not a full suite for every release. I think it just helps from time to time to actually try everything out in a given functional area and make sure it's sane.
16:30:21 <scottda> And I think in the past, things have been missed.
16:30:41 <smcginnis> We've had plenty of cases where tests pass just fine, but the logic of the thing is completely broken.
16:31:08 <e0ne> why we didn't care about functional and integration tests during feature development?
16:31:11 <scottda> Yeah, this is just a way to track what should be tested, and what is tested.
16:31:36 <scottda> e0ne: I'm 100% for a better way to ensure adding tests with the feature.
16:31:53 <scottda> But, we still have today's reality. Do we want to release with noone testing this stuff?
16:32:05 <e0ne> scottda: IMO, it should be one of our priorities for Pike
16:32:26 <DuncanT> scottda: Just -2 everything until current test coverage is 100% :-)
16:32:38 <smcginnis> Testing and stabilization was supposed to be a priority for Ocata. So I'd love to see at least some of it done now.
16:32:57 <smcginnis> DuncanT: Hah, full stop on everything. ;)
16:33:09 <scottda> OK, well I'm just wanting to point people to the etherpad. Things need testing, and it's nice to know if someone is testing. That's all.
16:33:10 <DuncanT> smcginnis: Kill or cure
16:33:27 <smcginnis> Thanks scottda
16:33:48 <smcginnis> #topic Status of DRBD
16:33:50 <jungleboyj> scottda: Good effort to start.  Thanks!
16:33:52 <smcginnis> scottda: Still you. :)
16:33:57 <scottda> #link http://lists.openstack.org/pipermail/openstack-dev/2017-January/109887.html
16:34:13 <scottda> ON the ML it was pointed out that drbdmanage isn't GPL'd any more.
16:34:20 <scottda> Needs some explicit user agreement.
16:34:25 <scottda> Do we even care about DRBD?
16:34:36 <scottda> The tests fail 100% of the time.
16:34:37 <smcginnis> Linbit does.
16:34:50 <smcginnis> And I did hear from them that they were going to try to address the concerns.
16:34:54 <e0ne> let's make it unsupported
16:34:55 <smcginnis> But I have not seen any progress there.
16:34:56 <scottda> Well, someone needs to get the tests to pass, for one thing, or they are just noise
16:35:03 <e0ne> or get CI working
16:35:08 <smcginnis> So I think at this point we should remove the test and mark it unsupported.
16:35:14 <scottda> So, prior to the GPL issue, the tests are broken.
16:35:21 <scottda> smcginnis: +1
16:35:26 <smcginnis> Infra should only be running tests for 100% compliant open drivers.
16:35:59 <DuncanT> For sure they should be running their own CI now
16:36:22 <e0ne> smcginnis: +1
16:36:39 <smcginnis> OK, I can put up patches later to remove the job and mark it unsupported.
16:36:48 <smcginnis> Unless someone else wants to grab that.
16:36:56 <DuncanT> The mix of licenses we have make providing a cinder distribution that 'just works' for all supported drivers not legally possible, but I've no longer got any skin in that game and the discussion was going round in circles
16:37:38 <smcginnis> DuncanT: I think that's going to be another one of those long drawn out discussions.
16:37:56 <smcginnis> OK, I'll put that on my todo list for today.
16:38:04 <smcginnis> Any other thoughts or opinions before I move on?
16:38:45 <smcginnis> OK, thanks again scottda
16:38:50 <smcginnis> #topic Adding Bandit as a non-voting gate
16:38:57 <smcginnis> rarora: You around?
16:38:59 <rarora> hi!
16:39:33 <rarora> we had brought this up a few weeks ago and the consensus was to look more into cleaning up the results so there are fewer false positives and see how keystone likes having it in their gate
16:39:53 <smcginnis> rarora: So I'll admit it's been awhile since I ran it, but last time I ran bandit there were pages of warnings and errors...
16:39:57 <e0ne> rarora: did we fix a lot of false positive errors?
16:39:59 <smcginnis> And not one of them was valid.
16:40:41 <rarora> So with filtering for medium severity and confidence, if I remember correctly there are roughly 100 bugs that bandit is coming up with
16:40:51 <rarora> for the entirety of the project
16:41:22 <rarora> which imo isn't too bad
16:41:52 <rarora> and then there are some common things that can be nosec'd so overall I think that it would be a good idea still to add this as a non-voting gate
16:41:55 <smcginnis> rarora: Any idea if any were legitimate though? 100 bugs of noise actually seems very bad to me.
16:42:11 <smcginnis> rarora: Don't get me wrong, I like the project and see its value.
16:42:36 <DuncanT> rarora: I think the nosec patch needs to happen before it goes in the gate or it just becomes yet another thing in the gate we ignore, which we've already got lots of
16:42:46 <smcginnis> DuncanT: +1
16:42:53 <e0ne> DuncanT: +2
16:43:05 <smcginnis> I agree, clean up first, then look at making it a regular job.
16:43:06 <rarora> I do see what you are saying. Is the nosec patch so that we can ignore things using the config rather than commenting a nosec?
16:43:46 <smcginnis> rarora: IIRC, does it just need a #nosec tag in the code like we do now for #noqua for pep8 things?
16:43:54 <rarora> yes
16:44:02 <jonesn> what I looked at was a #nosec in the code.
16:44:13 <DuncanT> rarora: Whichever is gets us a sane & informative result set from bandit gate
16:44:48 <DuncanT> rarora: Adding 100 #nosec might be ugly though.... disabling some of the nosier tests would probably be better
16:45:09 <smcginnis> I think sorting through maybe a dozen false alarms is OK. Sorting through 100+ false alarms just ends up being noise and getting ignored.
16:45:36 <rarora> yes, disabling lib xml and things like binding to all interfaces should help out
16:46:12 <rarora> also not sure what people's positions are on things like disabling warnings for md5 hashing becuase if the hash is not used for security purposes it's a non-issue and that is usually the case
16:46:40 <smcginnis> rarora: I think all of those I looked at last time were not used for security purposes.
16:46:49 <DuncanT> rarora: Better to disable too much initially and get a clean gate run
16:47:07 <DuncanT> rarora: As we #nosec or fix the code, we can enable more tests
16:47:33 <smcginnis> DuncanT: That might be the better approach. Otherwise we're not very likely to get to the passing state.
16:47:37 <DuncanT> rarora: A gate test that always gives even 1 false positive is nearly useless in practice
16:48:26 <rarora> DuncanT: Well the point of this, even if it nearly always would give false positives, is that it would help with people not committing new code with security issues
16:48:43 <jonesn> Do you think bandit could ever be configured to a point where we are guaranteed no false positives?
16:48:50 <rarora> No I do not
16:48:52 <smcginnis> rarora: They're not likely to notice that they are adding new issues if the test always fails anyway though.
16:49:11 <rarora> smcginnis: fair point
16:49:15 <DuncanT> rarora: I'm saying disable nearly everything if needed, and turn each test on in a patch with the relevant #nosec to keep a clean pass
16:49:39 <DuncanT> rarora: Better that than another gate test that nobody reads because there are always warnings
16:49:58 <jessegler> Makes sense to me
16:50:44 <xyang1> DuncanT: what about making it non-voting first?
16:51:01 <smcginnis> It will probably always have to be non-voting.
16:51:49 <smcginnis> OK, we have one more topic and <9 minutes left. I think for now, our preference would be to clean up the false error reporting, then we can look at adding it as a regular non-voting job.
16:51:54 <rarora> DuncanT: I see where you are coming from but at the same time, I feel like if it gets ignored by most people oh well, it's non-voting and isn't that resource intenseive and it at least gives people an easy way to take a look if they want to.
16:52:07 <rarora> smcginnis: okay, no problem :)
16:52:12 <rarora> just glad we got to talk about it
16:52:16 <smcginnis> We just have too many non-voting jobs that are ignored when they fail.
16:52:24 <smcginnis> It decreases the value of the Jenkins results.
16:52:44 <smcginnis> rarora: Yes, thank you for discussing it. I think anything we can do to increase security awareness is a good thing.
16:53:03 <diablo_rojo> 8 min left as a heads up
16:53:13 <smcginnis> OK, I'll move on. Thanks rarora
16:53:17 <smcginnis> #topic Avoid merging Tempest tests that break Cinder CI
16:53:20 <smcginnis> scottda: You again
16:53:23 <Swanson> If it is non voting I traditionally assume a fail is half expected and don't look.
16:53:23 <scottda> #link https://review.openstack.org/#/c/343291/
16:53:42 <scottda> That tempest test for snapshot_manage merged, and broke a bunch of CIs
16:53:53 <scottda> I don't recognize a single Cinder reviewer.
16:54:03 <scottda> Seems kinda broken to merge that in the first place, IMO
16:54:21 <scottda> BTW, revert patch up is: https://review.openstack.org/#/c/418922
16:54:24 <smcginnis> scottda: Totally
16:54:40 <scottda> Not sure what to do. Maybe this will urge caution from Tempest reviewers.
16:54:47 <smcginnis> This might be the better answer than just reverting it:
16:54:48 <scottda> Just seems kinda bad.
16:54:55 <smcginnis> #link https://review.openstack.org/#/c/418928/ Manage feature flag
16:55:11 <smcginnis> But I agree that shouldn't have landed in the first place.
16:55:59 <smcginnis> Good to have the test coverage. But I think even for the drivers that do support manage/unmanage, some require different identifiers and things.
16:56:05 <scottda> OK. Didn't know how many CIs were broken, or whom was affected by this.
16:56:08 <smcginnis> So not sure how useful that test actually is.
16:56:14 <smcginnis> scottda: I was affected.
16:56:34 <smcginnis> scottda: But the interesting thing is one of our drivers does support the feature, so the failure was expected.
16:56:34 <DuncanT> scottda: It passed for LVM though, right?
16:56:42 <jungleboyj> Sad that the CI's caught the problem and no one noticed.
16:56:45 <smcginnis> But our other storage does support it and failed for other reasons.
16:56:48 <scottda> Just woke up to the issue, and thought I'd bring it up. Maybe Tempest team will ping us next time for a review or opinion.
16:57:06 <smcginnis> jungleboyj: Problem is for tempest, I think only LVM is run to validate those patches.
16:57:20 <jungleboyj> smcginnis: Oh ... :-(
16:57:53 <smcginnis> Oh, and ceph, which was the only thing specifically called out to skip the test.
16:58:06 <scottda> DuncanT: I reckon it passed for LVM, but that is not enough. Not sure if there's a process to prevent this, or just "raise awareness".
16:58:28 <smcginnis> Raise awareness is probably all we can hope for at this point.
16:58:32 <smcginnis> 2 minutes
16:58:38 <scottda> OK, that's it for this.
16:58:47 <smcginnis> #topic Open discussion
16:58:50 <jungleboyj> Begs better coordination with the tempest team though.
16:58:55 <smcginnis> Any quick last minute (literally) things?
16:59:03 <jungleboyj> Any idea what the p-1 date will be?
16:59:11 <Swanson> 1/20?
16:59:29 <jungleboyj> Swanson: P-1
16:59:33 <smcginnis> Not up yet: https://releases.openstack.org/pike/schedule.html
16:59:50 <smcginnis> I think I guesstimated somewhere when that would be. I'll see if I can find that.
16:59:50 <jungleboyj> smcginnis: Right.  Guessing that will be early May ?
16:59:55 <dulek> jungleboyj: There's probably a review going in openstack/releases?
16:59:59 <smcginnis> Probably
17:00:07 <smcginnis> dulek: Oh right, there is actually.
17:00:11 <smcginnis> That's time. Thanks everyone.
17:00:16 <smcginnis> #endmeeting