20:00:46 <redrobot> #startmeeting barbican
20:00:47 <openstack> Meeting started Mon Jan 18 20:00:46 2016 UTC and is due to finish in 60 minutes.  The chair is redrobot. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:48 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:51 <openstack> The meeting name has been set to 'barbican'
20:00:56 <redrobot> #topic Roll Call
20:01:00 <woodster_> o/
20:01:15 <diazjf> 0/
20:01:16 <spotz> o/
20:01:31 <jmckind_> \o/
20:01:35 <edtubill> o/
20:01:43 <kfarr> o/
20:02:04 <redrobot> all the usual suspects :)
20:02:47 <arunkant> o/
20:03:19 <redrobot> As usual the agenda can be found here:
20:03:36 <redrobot> #link https://wiki.openstack.org/wiki/Meetings/Barbican#Agenda
20:04:12 <redrobot> #topic Action Items
20:04:25 <redrobot> #link http://eavesdrop.openstack.org/meetings/barbican/2016/barbican.2016-01-04-20.00.html
20:04:31 <redrobot> I had a ton of action items, but only finished one
20:04:41 <redrobot> so I have to punt on a couple
20:04:47 <redrobot> #action redrobot to check on status of reported security bug
20:04:55 <redrobot> #action redrobot to ping ccneill about the nova+cinder security bug
20:05:21 <redrobot> #topic Liaison Updates
20:05:37 <redrobot> I half-attended the oslo meeting this morning
20:05:55 <redrobot> looks like the mitaka-2 releases for oslo.* have been released
20:06:15 <redrobot> Any other liaison updates?
20:06:43 <redrobot> hockeynut isn't here so I'll skip QA
20:07:17 <redrobot> someone pinged me about documentation...  looks like we'll be having to write some WADLs and such to get our API docs up to spec
20:07:34 <redrobot> but I was busy with midcycle things so I haven't had a chance to look into all the work that needs to be done
20:07:48 <redrobot> #action redrobot to follow up with Anne Gentle re: docs
20:08:15 <diazjf> redrobot, I know a couple people here would like to join the effort on updating docs
20:08:20 <redrobot> alee isn't here either so I'll skip the Magnum cross-project stuff
20:08:30 <redrobot> diazjf cool, I'll keep you posted with what I find out
20:08:42 <redrobot> ok, on to the agenda for today
20:08:55 <redrobot> which I'm going to make up on the fly, because nobody added anything to the wiki
20:09:09 <redrobot> #topic Mid-Cycle Recap
20:09:14 <redrobot> #link https://etherpad.openstack.org/p/barbican-mitaka-midcycle
20:09:35 <redrobot> The mid-cycle meetup last week was awesome.  Many thanks to everyone who made the trip down to San Antonio
20:09:54 <edtubill> thanks for having us it was fun.
20:10:07 <silos> o/
20:10:14 <redrobot> There's lots of notes in the etherpad, including a lot of ACTION items
20:10:34 <redrobot> some of those have not been claimed, so if anyone is looking for things to do, have a gander at the etherpad
20:12:00 <rellerreller> o/ (sorry I'm late)
20:12:04 <redrobot> also, for those of you interested in Federation, diazjf will be working on a cross-project effort to get Push BYOK into OpenStack
20:12:25 <redrobot> rellerreller gonna need you to stay for 12 min after the meeting is over. :-P
20:12:45 <rellerreller> redrobot booo :(
20:12:58 <diazjf> redrobot, I'll have a spec up in OS-Security by the end of the week 8-)
20:13:13 <hockeynut> redrobot hockeynut is in another meeting :-(
20:13:39 <rellerreller> diazjf is that for byok?
20:13:49 <redrobot> rellerreller yep
20:14:26 <diazjf> rellerreller, yup see https://etherpad.openstack.org/p/cEA79A5fG1
20:14:41 <redrobot> rellerreller we had a few cross-team discussions with the ossp folks, and the consensus was that Push-model (where the client always provides the key) would be a good starting point.
20:14:47 <diazjf> ^ general notes from the midcycle
20:15:20 <redrobot> the idea is to bring an implementation plan to the Austin summit and talk about it during the cross-project design sessions.
20:16:25 <redrobot> anyway, awesome stuff during the midcycle
20:16:32 <redrobot> although we didn't land much in the way of blueprints
20:16:37 <redrobot> which brings me to the next topic
20:16:48 <redrobot> #topic Blueprint: API healthcheck
20:16:58 <redrobot> #link https://review.openstack.org/#/c/207317/
20:17:11 <redrobot> there were some concerns about this BP
20:17:32 <redrobot> I think that as long as this is an optional endpoint, and disabled by default, then I would be for adding it
20:18:44 <woodster_> sounds reasonable
20:19:39 <redrobot> rellerreller what do you think?  I recall you being concerned about the new unauthenticated resource
20:20:16 <rellerreller> I would rather see it have access controls in place and then if you want it like the spec describes then allow all read.
20:20:43 <rellerreller> I think it is better to have the security baked in up front as opposed to later.
20:20:58 <rellerreller> But if it is optional it's not a big deal for me.
20:21:08 <woodster_> rellerreller:  so deployers would mod their policy json files for that call then?
20:21:14 <redrobot> rellerreller so you'd like to see the default policy need auth for it, even if it's opt-in ?
20:21:18 <rellerreller> woodster_ yes
20:21:34 <rellerreller> woodster_ you would modify policy to allow all and then continue as normal
20:21:47 <rellerreller> redrobot yes
20:22:01 <redrobot> seems reasonable to me.  I'll add a comment to the spec linking back to this meeting.
20:22:16 <rellerreller> I feel like if it is not added now then people will enable it and there will be informatio leak
20:22:26 <redrobot> #agreed Healthcheck endpoint should be authenticated in the default policy file, and disabled in the default paste config.
20:22:36 <rellerreller> I also think it will fit the pattern of the other end points as well. This one won't look any different.
20:23:16 <woodster_> rellerreller:  shold this be an admin only access then?
20:23:24 <rellerreller> My only other comment on that one was about the return value.
20:23:40 <rellerreller> woodster_ I think admin would be good.
20:24:02 <redrobot> rellerreller woodster_ to be clear, this should be accesible only by the service-admin (the account owned by the deployer)
20:24:05 <rellerreller> I was wondering why not return different error codes for different errors?
20:24:05 <redrobot> ?
20:24:37 <rellerreller> redrobot that sounds good to me.
20:25:30 <rellerreller> It seems like if returning a more specific error code would be helpful. That way can begin to identify source of issue (db, threading, etc.)
20:25:34 <redrobot> rellerreller haven't looked at an exhaustive list of 5xx errors lately, but it makes sense to return different ones where appropriate
20:26:11 <redrobot> I'll leave that as a comment as well, since jkf isn't here to talk about the spec
20:26:12 <rellerreller> redrobot not 5xx errors from web server, but application defined error codes.
20:26:46 <redrobot> rellerreller ah I see...  I think there was a concern about information leak, but if we're locking it down by default, then error codes may make sense.
20:27:06 <rellerreller> redrobot those are my thoughts exactly.
20:27:42 <redrobot> ok, I think we've got enough to move this BP forward
20:27:46 <redrobot> on to the next one
20:27:49 <woodster_> please add comments to the blueprint for sure
20:28:02 <rellerreller> will do
20:28:14 <redrobot> #topic Blueprint: Mutiple secret-store backends
20:28:16 <redrobot> #link https://review.openstack.org/#/c/263972/
20:29:19 <redrobot> I don't particularly care for this BP.  I fundamentally disagree with the assumption that separate endpoints for distinct backends are "not a good user experience"
20:29:36 <redrobot> that said, I seemed to be the only dissenting one at the midcycle
20:29:45 <rellerreller> I am dissenting
20:30:19 <arunkant> redrobot: I see some good comments from alee so will update this one. rellerreller: Is it possible to remove -2 so that larger community can provide comments on this.
20:30:20 <rellerreller> I don't see how the other services will know which backend to use.
20:30:21 <redrobot> rellerreller I think you and I are the minority here
20:30:53 <redrobot> As I understand the BP, the backend would be configurable per-project
20:30:56 <rellerreller> redrobot what are your thoughts on -2?
20:31:11 <woodster_> rellerreller:  it is similar to how CAs are discovered now...there would be a ca_id sort of thing optionally specified to designate a secret store backend
20:31:30 <rellerreller> redrobot I put -2 to make sure not merged because I have strong reservations against it. I did not want it to be merge, but I also don't want to block discussion.
20:31:38 <rellerreller> I'm not exactly sure of the policy on that stuff.
20:31:45 <woodster_> rellerreller:  ...and project-configured default backends
20:32:25 <redrobot> rellerreller I'm not sure whether -2 discourages reviews from other reviewers.
20:33:07 <woodster_> Overall I like the possibility of having different 'qualities of service' for secrets in barbican
20:33:26 <redrobot> rellerreller I would personally only -1, because I disagree with the BP but I'm deferring to others to weigh in on it too, and possibly merged if it gets enough support.
20:33:36 <woodster_> ...but that is the sort of discussion to have on the blueprint CR I suppose :)
20:33:39 <redrobot> rellerreller sounds like you have a hard stance against it though, so -2 seems appropriate.
20:33:42 <rellerreller> woodster_ +1, but I'm not sure if this is the best way to achieve that.
20:34:06 <arunkant> redrobot: I have seen people even not looking into spec if it has -2 on it.
20:34:21 <woodster_> rellerreller:  if you can pitch an alternate approach that would be cool as well
20:34:41 <rellerreller> redrobot I do feel strongly about this one. Until I know for sure this will not break features, which I believe it will, then I would not like for this to merge. It is a big change.
20:34:46 <redrobot> woodster_ the alternate approach is already in the BP.  basically use different deployments of Barbican for different backends.
20:35:25 <woodster_> redrobot:  oh got it I though rellerreller had a different idea in mind
20:35:37 <rellerreller> No, that was it.
20:36:33 <arunkant> rellerreller: alee has already commented on transport key topic in spec and as per midcycle disucssion, I don't recall any isse around that during discussion
20:36:44 <rellerreller> I'm worried about relationships between keys and how that would work.
20:37:15 <redrobot> so one of the use cases that made sense to me was for a big cloud offering Barbican aaS, then upselling the customer into a "more secure hsm-backed" backend for more $ and still have them use the same endpoint.
20:37:16 <rellerreller> Like can I create a container that has keys in two different backends?
20:37:24 <woodster_> My preference is to tag secrets with quality of service explicitly, then the backend is selected automatically/optionally based on that, but that could wait till later.
20:37:45 <rellerreller> I would like to see key wrapping at some point. What if my keys are in two different backends?
20:37:50 <woodster_> rellerreller:  containers are just lightweight collections of secrets...the secrets are independent
20:38:14 <arunkant> rellerreller: Whatever is the concern, that can be raised in spec review. Please jJust don't block the discussion. We have very valid use-cases around this.
20:38:39 <rellerreller> I'm not blocking the discussion. The discussion can happen and should.
20:39:09 <redrobot> arunkant if there are Barbican cores that are avoiding the review because of the -2 please let me/them know.  I don't think we should ignore reviews based on a single dissenting vote.
20:41:20 <arunkant> redrobot: What -2 means..that this spec can never be merged. The concerns raised have been discussed nd updated in spec. I don't see why it needs to have -2 if there are some specific concern.
20:43:05 <arunkant> redrobot: I don't have any control on how other people behave when they see -2 or -1..but generally -2 means, its blocked so people would not even go there to review.
20:44:01 <arunkant> redrobot: I think there was enough consensus in mid-cycle and people have interest in having this feature.
20:44:25 <redrobot> arunkant I understand your concern, but I think that since rellerreller has a strong opinion on this, that the -2 from him is appropriate.  Like I said, if you feel other reviewers are not reviewing because of it, let me know.
20:44:44 <redrobot> arunkant there was, but currently there are no +X votes on there.
20:45:32 <redrobot> arunkant and I do apologize for not setting up a hangout last Friday
20:45:33 <arunkant> redrobot: alee has already reviewed it and you were also reviewing in midcycle.
20:45:37 <redrobot> arunkant I was tied up with OSSP mid-cycle
20:46:10 <arunkant> I believe _woodster was also okay with the idea.
20:46:39 <woodster_> it would probably be good for everyone's action items this week to review the blueprints out there...folks are standing by to implement them and we are running out of time in this cycle
20:46:57 <redrobot> woodster_ +1
20:47:00 <woodster_> arunkant:  the feature seems useful to me for sure
20:47:44 <arunkant> I don't see any outstanding question from rellerreller on this..other than we may want to implement key wrapping in some future ..and that may have some issue.
20:48:59 <redrobot> I think the concern was around the added complexity of having concurrent backends and the implications for other features, such as containers.
20:49:52 <arunkant> redrobot: I am not sure what complexity, it adds. Its new feature quite similar to CA support which alee added in liberty.
20:50:06 <rellerreller> Yes, key dependencies/transport keys, added complexity, and implications for other features
20:51:51 <arunkant> I don't see what kind of complexity is being talked here. Its opt-in feature which can be very useful in many private cloud deployments.
20:51:55 <redrobot> I'm going to table this discussion...  maybe we can get alee and woodster_ to give some positive reviews of the BP
20:52:58 <redrobot> then revisit later this week, maybe do a google hangout
20:53:15 <redrobot> #topic Blueprint: DB cleanup
20:53:28 <edtubill> ok
20:53:31 <redrobot> edtubill you were talking about this yes?
20:53:49 <arunkant> redrobot: I am all for discussion and making the spec better if there are any technical or functional concern but cannot answer on future features.
20:54:18 <edtubill> yes, there were some constraints that I was worried about, so I wanted to set up a hangout later on so we can discuss this.
20:54:25 <edtubill> And wanted other people to join in if interested
20:54:44 <redrobot> ok, so to summarize for other folks
20:54:51 <redrobot> (and try to fit into a few min)
20:54:59 <redrobot> edtubill is working on a BP to clean up the DB
20:55:22 <redrobot> edtubill a new function of barbican-manage would delete soft-deleted and expired secrets.
20:55:39 <redrobot> however, currently Orders has a non-nullable reference to Secret
20:55:52 <edtubill> ok, so for that was a false concern
20:56:02 <redrobot> which means we can't delete Secrets that were created by an order even if the Secret is soft-deleted or expired
20:56:04 <redrobot> ...
20:56:06 <edtubill> I looked at it again and it is nullable, but I would need to set it to null first.
20:56:11 <redrobot> or I may be making up stuff :D
20:56:30 <edtubill> :) no that was my bad. But there was another thing for order_retry_tasks that I was worried about.
20:56:51 <edtubill> for what happens if someone deletes an order when it was in the retry queue
20:57:00 <redrobot> edtubill does it affect the clean up Secrets BP?
20:57:38 <edtubill> it shouldn't really, but I'm more interested in getting info on implementation wise.
20:57:53 <edtubill> The blue print will be the same, I will make another blue print for expiring secrets.
20:58:08 <woodster_> edtubill: the worker processing that request would raise an error due to a non-existent order, but would juts report/log that and the move on
20:58:29 <redrobot> edtubill  I thought the current BPs would focus on cleaning up Secrets only?
20:58:36 <edtubill> wooderster_, but would it be cleaned up afterwards?
20:58:52 <edtubill> redrobot, the blue print is for anything that is soft deletable
20:59:06 <edtubill> we aren't touching orders unless it is soft deleted.
20:59:13 <redrobot> edtubill ok, cool
20:59:30 <redrobot> almost out of time here... we can continue discussion on #openstack-barbican if people want to stick around.
20:59:40 <redrobot> thanks for coming everyone
20:59:42 <redrobot> #endmeeting