15:00:58 <fungi> #startmeeting tc
15:00:58 <openstack> Meeting started Thu May 31 15:00:58 2018 UTC and is due to finish in 60 minutes.  The chair is fungi. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:00 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:02 <TheJulia> is o/
15:01:03 <openstack> The meeting name has been set to 'tc'
15:01:03 <TheJulia> err
15:01:04 <openstack> smcginnis: Error: Can't start another meeting, one is in progress.  Use #endmeeting first.
15:01:06 <dhellmann> thanks, fungi & smcginnis
15:01:07 <fungi> #chair smcginnis
15:01:08 <openstack> Current chairs: fungi smcginnis
15:01:09 <smcginnis> :)
15:01:11 <fungi> #chair dhellmann
15:01:12 <openstack> Current chairs: dhellmann fungi smcginnis
15:01:15 <fungi> #chair TheJulia
15:01:16 <openstack> Current chairs: TheJulia dhellmann fungi smcginnis
15:01:20 <fungi> #chair zaneb
15:01:21 <openstack> Current chairs: TheJulia dhellmann fungi smcginnis zaneb
15:01:24 <fungi> #chair EmilienM
15:01:24 <openstack> Current chairs: EmilienM TheJulia dhellmann fungi smcginnis zaneb
15:01:30 <cmurphy> start all the meetings
15:01:36 <dhellmann> #chair cmurphy
15:01:37 <openstack> Current chairs: EmilienM TheJulia cmurphy dhellmann fungi smcginnis zaneb
15:01:39 <fungi> #chair cmurphy
15:01:40 <openstack> Current chairs: EmilienM TheJulia cmurphy dhellmann fungi smcginnis zaneb
15:01:42 <fungi> #chair mnaser
15:01:43 <openstack> Current chairs: EmilienM TheJulia cmurphy dhellmann fungi mnaser smcginnis zaneb
15:01:53 <ttx> ohai
15:01:55 <smcginnis> Our ping list has become a chair list. :)
15:02:01 <fungi> looks like we have a bunch of tc members around around
15:02:03 <dhellmann> heh, that's one way to do it
15:02:05 <fungi> extra around
15:02:10 <fungi> #chair ttx
15:02:11 <openstack> Current chairs: EmilienM TheJulia cmurphy dhellmann fungi mnaser smcginnis ttx zaneb
15:02:34 <fungi> to be fair, it made more sense to add all two present tc members as chairs during the last office hour ;)
15:03:04 <dhellmann> the more the merrier
15:03:20 <dhellmann> we have several items on our tracker list without drivers (or with only 1). what should we do about that? https://wiki.openstack.org/wiki/Technical_Committee_Tracker
15:04:09 <smcginnis> Did the bylaws correction get done?
15:04:33 <dhellmann> the board passed a resolution authorizing jbryce to deal with it as part of the next election
15:04:33 <fungi> bylaws correction next step is making sure it gets on the next ballot for board elections
15:04:34 <EmilienM> fungi, ttx : have we already created a story about "Reviewing the TC Vision" ?
15:04:51 <dhellmann> I thought we would want to keep tracking it to ensure that correction makes it onto the ballot, and fungi signed up for that
15:05:00 <fungi> EmilienM: i haven't yet and not aware of one, that would be great to have
15:05:06 <EmilienM> if no, I'll go ahead and do it (+ update Wiki), maybe we could start poking at it today
15:05:09 <smcginnis> Yeah, that makes sense to follow it through to completion.
15:05:15 <dhellmann> oh, yes, please add links to relevant stories in the wiki
15:06:03 <openstackgerrit> Samuel Cassiba proposed openstack/governance master: Add openstackclient to Chef OpenStack  https://review.openstack.org/571504
15:06:11 <TheJulia> dhellmann: I think for some of them, I think we need to see if someone steps forward. It is also the week after summit and people are likely still decompressing/processing last week
15:06:43 <dhellmann> sure.
15:07:02 <dhellmann> I didn't know if we wanted to ask people to sign up, move unowned things to a separate list, or something else.
15:07:57 <TheJulia> I think we should broadcast that we would like someone to step forward for these items, and kind of revisit it in a week.
15:09:01 <ttx> EmilienM: it's on dhellmann's wiki already
15:09:08 <TheJulia> That way we're also possibly growing the pool of potential leaders as time moves on/giving opportunities.
15:09:25 <ttx> EmilienM: oh, you mean add link ? Yes++
15:09:32 <EmilienM> ttx: doing it now
15:10:18 <ttx> EmilienM: I'll create an etherpad where we can dump the current vision and then add comment
15:10:35 <dhellmann> TheJulia : are you suggesting that we ask folks not on the TC to take these up?
15:10:57 <TheJulia> We had discussed in the past that we felt that it was acceptable for non-tc members to take up causes and work with the TC
15:11:09 <dhellmann> I don't have a problem with us asking for help, but these are the things we said we wanted to do, so I think we should have TC members attached to each of them.
15:11:11 <TheJulia> if that is no longer the case, then we have a limited pool of resources.
15:11:41 <dhellmann> that's why I called them "drivers" and not "owners"
15:11:46 <EmilienM> ttx: works for me, it can be faster than using Gerrit for now.
15:12:10 <TheJulia> dhellmann: I see your point, I would just worry about drivers being looked at like owners
15:12:57 <dhellmann> it's hard for me to reconcile a desire to be more active with the idea that we wouldn't do things. :-)
15:13:46 <dhellmann> maybe we should have the conversation about what % of time TC members feel they have to contribute, and whether that should have some effect on the length of our todo list
15:14:06 <dhellmann> perhaps some of these things are backlog items, and not actively being worked on, for example
15:14:44 <cmurphy> what is "Trove Project Health"? I was in that session but I'm not sure what actions should be taken around that
15:15:18 <dhellmann> zaneb thought he was the one who brought that up, but I didn't remember. the question was "is anyone actually working on trove any more?"
15:15:46 <TheJulia> dhellmann: that is a valid point, we can't take on the world... at least not without prioritization and planning :)
15:15:46 <dhellmann> it relates to the thing we talked about thursday of checking in on project teams more actively
15:16:18 <ttx> dhellmann: I heard that question from a bunch
15:16:21 <TheJulia> dhellmann: cmurphy: I believe the comment is that there is nobody working on it any longer, and that maintainers and contributors are needed
15:16:26 <TheJulia> s/is/was/
15:16:56 <dhellmann> I took a peek in gerrit and saw what looked like relatively recent reviews landed, but it still seemed like enough of a question that I left it on the list
15:16:58 <TheJulia> Someone raised ?Amrith?, but... yeah.
15:17:01 <smcginnis> I thought a team from IBM took up Trove when amrith had proposed moving it to unmaintained.
15:17:07 <ttx> To the point where a "Stop or encore" session would have been good at forum
15:17:16 <ttx> smcginnis: yes
15:17:18 <TheJulia> dhellmann: good plan then
15:17:44 <dhellmann> who wants to check in on the trove team and report back?
15:17:56 <TheJulia> I can put that on my todo list
15:18:08 <mnaser> https://review.openstack.org/#/c/526728/ -- looks like they're still kinda landing things
15:18:08 <dhellmann> thanks, TheJulia!
15:18:18 <fungi> yeah, i think the worry is that trove engagement hasn't continued since the new team was put in control. if memory serves we had nobody in vancouver to run the trove sessions
15:18:18 <ttx> I have history, can take Trove too
15:18:32 <mnaser> but 6 weeks before that was the last merge
15:18:35 <dhellmann> great, please put your names in the wiki, ttx & TheJulia
15:18:41 <dhellmann> let's not do it *now*
15:18:44 <zaneb> the last I heard Trove was in 'maintenance mode' and there is no new development, but it is maintained. I haven't actually checked so I don't know that this is the case
15:18:57 <ttx> OVH has ben considering taking it over, which is why I looked into it
15:19:13 <fungi> #link https://governance.openstack.org/tc/reference/tags/status_maintenance-mode.html
15:19:18 <TheJulia> It would be good to have an operator get involved
15:19:23 <fungi> only searchlight has that governance tag applied at the moment
15:19:48 <zaneb> people (possibly including me) might have used the word 'unmaintained' to describe that, but at least in my case it wasn't based on any new information
15:19:58 * dhellmann was hoping to use this time for team organization, not a deep dive into trove
15:20:03 <ttx> I think at this point they don't dare taking it over, but we could encourage them if it's in bad shape
15:20:07 <ttx> hehe
15:20:27 <dhellmann> smcginnis , I have a ? next to your name on the stein goals item. did you want to help drive that?
15:20:28 <TheJulia> dhellmann: next item! :)
15:20:29 * ttx now sees how fun it is to disrupt the chair
15:20:29 <mnaser> dhellmann: maybe that's why we'd need an actual meeting with an agenda besides office hours :>
15:20:43 <mnaser> but back on track
15:20:47 <dhellmann> mnaser : there is 1 topic on our agenda today: sort out this todo list! :-)
15:21:10 <mnaser> fair :)
15:21:18 <dhellmann> we more or less agreed to always pair up on items, and we have a lot with only 1 driver
15:21:45 <EmilienM> ttx: i've noticed that https://www.openstack.org/software/sample-configs redirects to projects from ocata
15:21:48 <dhellmann> do people still feel like pairing is a good way to ensure depth of coverage and to support each other? and important enough to do?
15:21:57 <EmilienM> ttx: we might want to update it to Quees, perhaps
15:22:11 <ttx> EmilienM: will signal it
15:22:18 <smcginnis> dhellmann: Yes, I will update that to remove the ?
15:22:20 <mnaser> dhellmann: i think it's beneficial being able to lean on someone else who will hopefully be intimately familiar with the topic
15:22:23 <dhellmann> smcginnis : thanks
15:22:40 <dhellmann> mnaser : good point
15:22:41 <EmilienM> ttx: are these our constellations? they look like it anyway
15:22:41 <mnaser> so i support taking items that have a single driver and aiming for at least two
15:23:24 <zaneb> dhellmann: how long are we planning to keep around stuff that is marked as Approved in the list?
15:23:35 <dhellmann> zaneb : until I send the next TC update email on Monday
15:23:48 <dhellmann> I skipped this week because there were so many forum update emails already
15:23:52 <zaneb> that makes a lot of sense :)
15:24:56 <ttx> EmilienM: kind of -- depends on what we mean by constellation :)
15:25:58 <dhellmann> ok, as TheJulia pointed out we probably have a few people on PTO after the summit, so I won't stress too much about these not having drivers until next week
15:26:20 <dhellmann> did I miss anything other than the work dims has started on writing up job descriptions for the help-wanted areas?
15:26:42 <dhellmann> I will add that item after I send my summary of the joint leadership meeting, if dims doesn't beat me to it
15:26:57 <dims> no rush dhellmann :)
15:27:57 <dims> got some feedback from Chris Price on email
15:27:57 <dhellmann> maybe we want to move on to other topics, then?
15:28:01 <dhellmann> oh, good
15:29:16 <zaneb> when is it kosher to post info from the board meeting? usually jbryce posts a summary, but he wasn't actually there...
15:29:54 <dhellmann> there are different rules for the board meeting, I think
15:30:13 <dhellmann> the board asks members not to post summaries before the official minutes are posted, I think?
15:30:28 <smcginnis> I thought we discussed that recently and heard board members need to wait for jbryce to post a summary, but non-board do not?
15:30:31 <dhellmann> but I don't think that applies to the joint leadership meeting, since that's not a board meeting
15:30:50 <dhellmann> I was going to post an email summary based on my own notes as a personal summary
15:31:25 <zaneb> as a participant in the meeting, I would feel uncomfortable posting a summary before other participants (i.e. board members) are allowed to
15:31:32 <fungi> right. yeah, official minutes will presumably eventually appear at
15:31:36 <fungi> #link https://wiki.openstack.org/wiki/Governance/Foundation/20May2018BoardMinutes
15:31:40 <dhellmann> zaneb : right, my point is that the rule on official minutes does not apply here
15:31:59 <dhellmann> we met with the board, but it was not an operating meeting of the board of directors
15:32:11 <dhellmann> *part* of the day was, but I wasn't in the room then so my summary won't cover that anyway
15:32:12 <mnaser> yeah, afaik it is a "joint leadership meeting"
15:32:15 <fungi> but only the board members (and possibly foundation staff?) are expected to refrain from making public comments before the minutes are posted
15:32:32 <zaneb> well, there was a roll call and a motion was approved
15:32:37 <zaneb> while we were there
15:32:52 <dhellmann> yes, true, that portion of the meeting was more official than the rest
15:32:52 <fungi> oh, right that too. there _was_ a board meeting, but it was at the very end of the day, lasted a handful of minutes and involved nothing of substance
15:32:58 <mnaser> do we want to confirm with the board to have a clear understanding?
15:32:59 <dhellmann> the agenda that day was a bit messy
15:33:10 <dhellmann> ok, I'll ask Alan before I post anything
15:33:12 <mnaser> maybe this is part of increasing communication with our board :)
15:33:27 <dhellmann> #action dhellmann to ask Alan about posting a summary of the joint leadership meeting
15:34:40 <dhellmann> the review https://review.openstack.org/564060 about goal champions needs 1 more vote, so please take a look at that when you have time
15:36:13 <dhellmann> what else is on your minds this week?
15:37:40 <TheJulia> dhellmann: you have the extra vote now
15:38:05 <fungi> now that the summit's over and there's been no objection to the related ml thread, i was going to propose the base services addition change for a castellan-compatible key store
15:38:46 <ttx> ++
15:38:52 <dhellmann> TheJulia : thanks
15:38:59 * ttx crosses one more item from his giant list
15:39:01 <dhellmann> fungi : ++
15:39:35 <fungi> #link http://lists.openstack.org/pipermail/openstack-dev/2018-May/130567.html key store in base services
15:39:44 <zaneb> fungi: are we going to specify which key store?
15:39:47 <fungi> was the start of the thread where it was suggested
15:39:56 <dhellmann> fungi : I'm not sure what services that means today, so we probably want to make it clear that we welcome new drivers in castellan to cover other services that people want to be able to use
15:40:20 <fungi> zaneb: consensus so far seemed to be around "a castellan-compatible key store" without specifying any one in particular
15:40:40 <mnaser> one concern that i have is.. i feel like castellan is this extra layer of api abstraction on top of barbican, a secret store that abstracts other api stores
15:40:47 <zaneb> ok, that makes sense
15:41:05 <mnaser> afaik castellan has a 'vault' driver, but barbican also has one too
15:41:10 <fungi> mnaser: well, castellan was the result of complaints that barbican meant having an extra service
15:41:15 <zaneb> when people were saying Barbican in particular I was wondering if it was more a job for constellations than base services...
15:41:58 <mnaser> i guess this could be a start in openstack projects being able to be used independently
15:42:04 <mnaser> which is good too
15:42:42 <fungi> apparently some distros/deployments already have vault for other reasons and wanted a way of being able to just use it without adding a barbican service to manage
15:42:49 <dhellmann> I see it as a bit like oslo.messaging or oslo.db: services can rely on something for which we have a driver and use the abstraction layer to avoid dictating to deployers what to actually use
15:44:17 <zaneb> dhellmann: yeah, it's just a little bit weird in this case because an openstack service can be a backend. like if there was a Trove driver for oslo.db
15:45:31 <dhellmann> yes, that is a bit unusual
15:45:55 <dhellmann> I guess one difference is whether the secret is part of the deployment or something owned by an end-user
15:46:45 <dhellmann> so if a service wants to have end-user-managed secrets for doing things like encryption, that may imply barbican is actually required as an implementation detail, even if it is a wrapper around something else
15:49:31 <fungi> i think what we're more worried about for now is other services being able to rely on havnig somewhere safe to quarantine secrets/keys so that they don't all have to duplicate that work badly and end up neutering their security features as a result or influencing distros/operators to avoid turning on useful security features which might otherwise benefit from having it
15:51:12 <dhellmann> sure. is there actually a difference in user-facing vs. service-only keys? or is that distinction not important? I'm not that familiar with this space or how one interacts with something like vault, but it seems odd for us to say "in order to encrypt your cinder volume, put a key in vault and then tell us about it" since vault doesn't have an "Openstack API"
15:51:31 <dhellmann> maybe that workflow is normal and expected, though, I just don't know
15:52:05 <ttx> The reason that Vault it plugged both at castellan and Barbican levels is because those things do not strictly overlap
15:53:06 <dhellmann> yeah, that part made sense to me. I just wonder if saying a "castellan-supported secret store" is actually the right thing if we want services to provide features that require users to interact with the key store
15:54:02 <fungi> dhellmann: i think the difference between user-facing and service-only is more in how we end up saying whether it's a standard feature. for service-only we have the base services list saying what other services are allowed to depend on being present. for user-facing we decide with trademark programs and interoperability testing
15:54:20 <dhellmann> I guess I'm not being clear.
15:54:47 <dhellmann> If a user has to create a key to use a feature in cinder, is Vault "good enough"?
15:55:25 <dhellmann> Because if so, we're telling services that relying on having users interact with non-openstack services is OK, and I think that's a new statement?
15:55:27 <ttx> dhellmann: I /think/ castellan will let you create a key on Vault alright
15:55:51 <fungi> if we want services to provide features that require users to interact with the key store then it's a matter for trademark programs/interop and would probably spell out barbican as a requirement
15:55:57 <dhellmann> ttx: castellan is a python library. it's how cinder would interact with vault. it's not how a user would.
15:56:51 * TheJulia wonders if the discussion is in or just above the weeds
15:56:51 <dims> https://github.com/openstack/castellan/blob/master/castellan/key_manager/key_manager.py#L43 - create_key
15:57:01 <dims> and yes vault manager supports it
15:57:01 <ttx> dims: yeah
15:57:02 <dhellmann> TheJulia : definitely muddy water, if not weeds
15:57:25 <dhellmann> right, castellan *can* talk to vault, but it's not a REST API
15:57:36 <dims> correct, calls vault directly - https://github.com/openstack/castellan/blob/master/castellan/key_manager/vault_key_manager.py#L139
15:57:59 <fungi> from a base services perspective, we're just saying it's okay for services to rely on it, not saying anything about what those services expose (and we're not saying they're required to expose anything to the user)
15:58:10 <dhellmann> so we would be saying that it's OK for an openstack cloud to rely on a service that has no openstack API, and that's different from the other base services that are all hidden behind the cloud's API
15:58:30 <mnaser> i mean, in terms of interop, how would we think about ceph and it's exposed openstack 'swift' compatible api.. it's an external component providing the same functionality (kindof?)
15:58:31 <dhellmann> ok. I just think it's not going to be useful if there's not also a way for users to actually interact with the store
15:58:34 <fungi> i don't follow
15:58:35 <zaneb> so what dhellmann is saying is that the secret has to pass through Cinder API->Castellan->Vault, instead of going straight to the Barbican API. and that may be a less safe way of handling it
15:58:39 <ttx> Does Cinder volume encryption require you to provide your own key ? Or does it just generate one for you ?
15:58:52 <mnaser> good question for smcginnis ^ ? :)
15:58:53 <fungi> etcd has a non-openstack api and it's in the base services list
15:59:23 <dhellmann> fungi : do we expect users to interact with etcd?
15:59:24 <dhellmann> zaneb : yes, that's a good way of putting it
15:59:34 <zaneb> fungi: the cloud user never has to poke any data into etcd
15:59:38 <fungi> i'm still not following. we wouldn't be saying deployments are required to expose cinder volume encryption either way
15:59:42 <dhellmann> do we want every service to invent its own API for creating or uploading keys?
16:00:30 <ttx> dhellmann: hrm, isn't that what Castellan does ?
16:00:37 <dims> dhellmann : we want them to use the common library (like oslo.db and oslo.messaging)
16:00:38 <zaneb> fungi: if there's no OpenStack API for secrets available then every API becomes an API for secrets, proxying via Castellan on the back end
16:00:41 <dhellmann> we do not, in any other case, require users to use our client libraries
16:00:47 <fungi> we'd be saying it's okay for services to assume a castellan-compatible key store is available to those services, we aren't saynig anyone has to expose any particular related api to end users
16:00:48 <ttx> Also "creating" and "uploading" are not two separate things
16:01:00 * TheJulia feels like people are approaching this from different contexties and that we need to actually write it down at this point
16:01:00 <ttx> You create keys on the secret store.
16:01:04 <dhellmann> dims : end users do not use those libraries, though
16:01:24 <dims> dhellmann : right, they use the native stuff directly like vault or barbican
16:01:49 <fungi> take designate's desire for this, as an example. designate would like to treat a key store as an hsm, have it generate keys and handle signing requests, without those keys ever leaving the store
16:02:05 <fungi> that has nothing to do with end users uploading keys
16:02:18 <zaneb> fungi: yes, that's a case that castellan works for
16:02:48 * smcginnis had to step away for a bit, reading scrollback
16:02:49 <fungi> so i really, really, really don't see where this "exposing non-openstack apis to end users" tangent is coming from
16:02:55 <dims> it's not just vault, folks want to use castellan + custodia ( https://review.openstack.org/#/c/515190/ )
16:02:58 <dhellmann> fungi : true. that's 1 use case. Is that the only case where being generic about the keystore is useful?
16:03:09 <ttx> I'm sad that we keep having this "should we require Castellan or Barbican" discussion every 6 months. Last time we spent one hour on it and concluded Castellan
16:03:13 <dims> and KMIP https://review.openstack.org/#/c/298991/
16:03:22 <dims> yep ttx
16:03:22 <ttx> Now I'm missing most of the context from that discussion
16:03:26 <dhellmann> fungi : I'm trying to understand if it is sufficient to say "castellan supported" or if that's only going to enable 1 use case.
16:03:31 <ttx> But I remember us going into deep
16:03:51 <fungi> in fact, the previous time we discussed it we convinced the barbican team to create castellan so that we could consider it for this purpose
16:04:03 <zaneb> e.g. in Heat we want to be able to auth to other OpenStack clouds, which requires the user's credentials for those cloud. we don't want to see those through the Heat API, so we're going to ask the user to put them in Barbican directly
16:04:05 <dims> with dave-mccowan and kfarr and others
16:04:29 <dhellmann> ok, I'll let it go. I'm sorry I've been unable to express my concern in a way that folks can understand.
16:04:33 <mnaser> if that discussion of 'castellan vs barbican' has been had and a conclusion has been reached
16:04:42 <mnaser> maybe we should just focus on the base services discussion
16:04:44 <zaneb> but that feature will obviously be unavailable on clouds without Barbican, even if they have Vault
16:05:00 <dims> dhellmann : another data point, some folks like Huawei have their own barbican equivalent, so castellan is the better integration point
16:05:30 <ttx> zaneb: right -- so THAT was raised as an unresolved issue last time. Reliance on Barbican-specific features
16:06:08 <dhellmann> I am not suggesting that services should only talk to barbican. I am suggesting that leaving barbican out of the base services list is going to mean we have a lot of features we can't implement  because we don't provide users a way to deal with keys *or* that we will have a lot of services adding their own APIs for dealing with keys. Both are reasons we have the list in the first place.
16:06:19 <zaneb> I'm ok with that btw. just trying to clarify Doug
16:06:28 <dhellmann> thanks, zaneb
16:06:44 <ttx> It might still be a problem
16:06:49 <fungi> yeah, i personally felt like settling on barbican as the api was best for interoperability purposes, but it seems like there was a lot of pushback from deployment and operations representatives so at least having some way for projects to avoid duplicating this effort badly/insecurely/inconsistently on their own would be nice
16:06:51 <zaneb> Doug's point that not all features we might want will be enabled by having just castellan
16:06:57 <mnaser> well, we can always extend castellan
16:07:03 <mnaser> to support barbican specific features
16:07:12 <zaneb> enter key and the apostrophe key are too close as usual
16:07:20 <dhellmann> mnaser : we cannot require users to use a specific client library for the trademark programs
16:07:26 <ttx> mnaser: except those "features" are out of scope for Vault
16:07:29 <dhellmann> so we have to enable a REST API for those things at some point
16:07:39 <dhellmann> and right now our REST API for this is barbican
16:07:45 <ttx> Basically the issue here is that Barbican is more than a store
16:07:55 <ttx> which is why it can plug into Vault for store feature
16:08:01 <fungi> castellan could also be extended to have multiple drivers for those different features to placate people who really don't want barbican running
16:08:14 <dims> yep fungi
16:08:21 <mnaser> so maybe for now we can say 'castellan' but eventually drop it if we really start running into issues
16:08:23 <smcginnis> Cinder uses castellan. Users do not provide a key, though there have been some recent informal proposals to have user provided keys per volume for encryption.
16:08:30 <mnaser> we might be discussing something that is non problematic?
16:08:31 <ttx> The other factor here is that ANYTHING is better than the current situation so we tend to jump on anything that passes
16:09:02 <smcginnis> I think it's fair to state castellan is a base service, but what is used behind that is left to the deployer.
16:09:22 <dhellmann> smcginnis : how would you implement user-provided keys?
16:09:22 <dims> we should start with castellan as a base library requirement, then if barbican takes hold among operators then we can go to full dependency on barbican
16:09:32 <dhellmann> yeah, it's a fine first step. I just expect us to have to revisit it very soon.
16:09:33 <smcginnis> dhellmann: That's the open question.
16:09:34 <mnaser> ++ dims
16:09:44 <smcginnis> dims: ++
16:09:45 <dhellmann> maybe when that happens it will be clear why in a way that I seem unable to express.
16:10:15 <fungi> i think that as soon as we're talking about whether it's safe for a trademark-covered service to require exposing another api to users, then we need that api also covered under the same trademark program(s)
16:10:19 <smcginnis> I remember DuncanT had some concerns about Barbican, but I do not know enough about that area to really comment.
16:10:22 <ttx> dims:  that sounds a bit... weird though
16:10:40 <ttx> People who end up doing Castellan+Vault might be forced to change
16:11:09 <mnaser> arent those the same people who didnt want to run barbican in the first place? :\
16:11:21 <dhellmann> keystone is a good parallel here. we say that all of the services can rely on having keystone present to authenticate users, so that those services don't have to implement their own authentication. s/authentication/key management/
16:11:24 <dims> mysql / postgresql situation
16:11:41 <TheJulia> I would urge us not to force additional services where they are not needed. Use cases are going to differ as this discussion shows, and the standalone usage or back-end integration points make very valid sense as some operators have different use context and business needs.
16:12:21 <TheJulia> If the projects evolve to have that need, so be it, but at that point it is a conscious decision.
16:12:24 <ttx> I guess the issue is that for 90% of the use cases castellan is enough... and forcing everyone to go full Barbican might hinder solution for those 90%
16:12:51 <dhellmann> ttx: I guess I am questioning that 90% number, though.
16:12:56 <mnaser> maybe this is an outlier and not the time for this comment, but barbican really isn't that heavy of a service.
16:13:07 <mnaser> it's a simple rest api, it can integrate with vault if you're already running it
16:13:33 <clarkb> as an end user this type of compromise typically means I never use any of these features (and if you look at infra's consumption of openstack its a very reduced feature set because very few things are reliably available). To me that effectively means not enforcing a complete solution is as bad as not having a solution at all
16:13:41 <dhellmann> let's get a concrete proposal written up and have some project teams comment on it
16:13:42 <TheJulia> mnaser: but it is still another network accessible service, that has to be monitored, reported upon, it is security related so additional reporting controls have to be put into place depending on operating and regulatory requirements
16:13:44 <fungi> and the hope is that we can overcome the catch-22 critical mass inflection point which is causing deployments to resist implementing security features they'd find useful
16:13:49 <ttx> Last time the only things that were raised as potentially needing Barbican were Octavia and Designate iirc
16:13:59 <ttx> Octavia now uses Castellan...
16:14:13 <johnsom> Octavia support both
16:14:30 <mnaser> TheJulia: that's true, but that's up to the deployer if they want to use the extra features, then they'll have to support the things that come with it
16:14:30 <ttx> So 90% might be 99% :)
16:14:40 <ttx> johnsom: OR or AND ?
16:14:45 <smcginnis> clarkb: That's a good point.
16:14:47 <clarkb> johnsom: and octavia has its own apis for storing certs?
16:15:04 <TheJulia> mnaser: empowering the deployer to make the choice seems.. ideal, at least to me.
16:15:12 <johnsom> Currently it is an OR, but with flavors (coming) it could be AND.
16:15:37 <zaneb> so Heat needs Barbican for multi-cloud. It's fine if that's a soft dependency, but obviously better if it were available to everyone
16:15:40 <ttx> johnsom: no I mean you need one of them, not both, right ?
16:15:45 <johnsom> clarkb No, the user provides Octavia with the reference to the secrets. We do not have an upload interface.
16:16:09 <clarkb> johnsom: right so if the secret is in vault fronted by castellan how do I (the end user) give that service my certs so that octavia can use them?
16:16:13 <clarkb> (this is dhellmann's concern aiui)
16:16:18 <dhellmann> johnsom : how does the user create the secret?
16:16:27 <johnsom> ttx It's an operator choice thing.  Barbican has been supported for a long time, but people wanted Vault so we added Castellan
16:16:35 <ttx> ok
16:18:08 <dhellmann> fungi , you started the meeting, do you want to close it out?
16:18:17 <johnsom> dhellmann We leave that to the user.  Either the barbican CLI or custom UI systems.  One operator already has a cert management UI for vault, so just uses that.  Our cookbooks describe how to use OpenStack client to add certs to Barbican.  There was also castellan-ui dashboard plugin, but I'm not sure if that is finished.
16:18:47 <fungi> oh! sure
16:18:53 <clarkb> on an interop front ^ is not very friendly and is another case of infra wouldn't use that feature
16:18:54 <fungi> #endmeeting