15:00:58 #startmeeting tc 15:00:58 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:02 is o/ 15:01:03 The meeting name has been set to 'tc' 15:01:03 err 15:01:04 smcginnis: Error: Can't start another meeting, one is in progress. Use #endmeeting first. 15:01:06 thanks, fungi & smcginnis 15:01:07 #chair smcginnis 15:01:08 Current chairs: fungi smcginnis 15:01:09 :) 15:01:11 #chair dhellmann 15:01:12 Current chairs: dhellmann fungi smcginnis 15:01:15 #chair TheJulia 15:01:16 Current chairs: TheJulia dhellmann fungi smcginnis 15:01:20 #chair zaneb 15:01:21 Current chairs: TheJulia dhellmann fungi smcginnis zaneb 15:01:24 #chair EmilienM 15:01:24 Current chairs: EmilienM TheJulia dhellmann fungi smcginnis zaneb 15:01:30 start all the meetings 15:01:36 #chair cmurphy 15:01:37 Current chairs: EmilienM TheJulia cmurphy dhellmann fungi smcginnis zaneb 15:01:39 #chair cmurphy 15:01:40 Current chairs: EmilienM TheJulia cmurphy dhellmann fungi smcginnis zaneb 15:01:42 #chair mnaser 15:01:43 Current chairs: EmilienM TheJulia cmurphy dhellmann fungi mnaser smcginnis zaneb 15:01:53 ohai 15:01:55 Our ping list has become a chair list. :) 15:02:01 looks like we have a bunch of tc members around around 15:02:03 heh, that's one way to do it 15:02:05 extra around 15:02:10 #chair ttx 15:02:11 Current chairs: EmilienM TheJulia cmurphy dhellmann fungi mnaser smcginnis ttx zaneb 15:02:34 to be fair, it made more sense to add all two present tc members as chairs during the last office hour ;) 15:03:04 the more the merrier 15:03:20 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 Did the bylaws correction get done? 15:04:33 the board passed a resolution authorizing jbryce to deal with it as part of the next election 15:04:33 bylaws correction next step is making sure it gets on the next ballot for board elections 15:04:34 fungi, ttx : have we already created a story about "Reviewing the TC Vision" ? 15:04:51 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 EmilienM: i haven't yet and not aware of one, that would be great to have 15:05:06 if no, I'll go ahead and do it (+ update Wiki), maybe we could start poking at it today 15:05:09 Yeah, that makes sense to follow it through to completion. 15:05:15 oh, yes, please add links to relevant stories in the wiki 15:06:03 Samuel Cassiba proposed openstack/governance master: Add openstackclient to Chef OpenStack https://review.openstack.org/571504 15:06:11 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 sure. 15:07:02 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 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 EmilienM: it's on dhellmann's wiki already 15:09:08 That way we're also possibly growing the pool of potential leaders as time moves on/giving opportunities. 15:09:25 EmilienM: oh, you mean add link ? Yes++ 15:09:32 ttx: doing it now 15:10:18 EmilienM: I'll create an etherpad where we can dump the current vision and then add comment 15:10:35 TheJulia : are you suggesting that we ask folks not on the TC to take these up? 15:10:57 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 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 if that is no longer the case, then we have a limited pool of resources. 15:11:41 that's why I called them "drivers" and not "owners" 15:11:46 ttx: works for me, it can be faster than using Gerrit for now. 15:12:10 dhellmann: I see your point, I would just worry about drivers being looked at like owners 15:12:57 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 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 perhaps some of these things are backlog items, and not actively being worked on, for example 15:14:44 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 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 dhellmann: that is a valid point, we can't take on the world... at least not without prioritization and planning :) 15:15:46 it relates to the thing we talked about thursday of checking in on project teams more actively 15:16:18 dhellmann: I heard that question from a bunch 15:16:21 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 s/is/was/ 15:16:56 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 Someone raised ?Amrith?, but... yeah. 15:17:01 I thought a team from IBM took up Trove when amrith had proposed moving it to unmaintained. 15:17:07 To the point where a "Stop or encore" session would have been good at forum 15:17:16 smcginnis: yes 15:17:18 dhellmann: good plan then 15:17:44 who wants to check in on the trove team and report back? 15:17:56 I can put that on my todo list 15:18:08 https://review.openstack.org/#/c/526728/ -- looks like they're still kinda landing things 15:18:08 thanks, TheJulia! 15:18:18 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 I have history, can take Trove too 15:18:32 but 6 weeks before that was the last merge 15:18:35 great, please put your names in the wiki, ttx & TheJulia 15:18:41 let's not do it *now* 15:18:44 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 OVH has ben considering taking it over, which is why I looked into it 15:19:13 #link https://governance.openstack.org/tc/reference/tags/status_maintenance-mode.html 15:19:18 It would be good to have an operator get involved 15:19:23 only searchlight has that governance tag applied at the moment 15:19:48 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 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 hehe 15:20:27 smcginnis , I have a ? next to your name on the stein goals item. did you want to help drive that? 15:20:28 dhellmann: next item! :) 15:20:29 * ttx now sees how fun it is to disrupt the chair 15:20:29 dhellmann: maybe that's why we'd need an actual meeting with an agenda besides office hours :> 15:20:43 but back on track 15:20:47 mnaser : there is 1 topic on our agenda today: sort out this todo list! :-) 15:21:10 fair :) 15:21:18 we more or less agreed to always pair up on items, and we have a lot with only 1 driver 15:21:45 ttx: i've noticed that https://www.openstack.org/software/sample-configs redirects to projects from ocata 15:21:48 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 ttx: we might want to update it to Quees, perhaps 15:22:11 EmilienM: will signal it 15:22:18 dhellmann: Yes, I will update that to remove the ? 15:22:20 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 smcginnis : thanks 15:22:40 mnaser : good point 15:22:41 ttx: are these our constellations? they look like it anyway 15:22:41 so i support taking items that have a single driver and aiming for at least two 15:23:24 dhellmann: how long are we planning to keep around stuff that is marked as Approved in the list? 15:23:35 zaneb : until I send the next TC update email on Monday 15:23:48 I skipped this week because there were so many forum update emails already 15:23:52 that makes a lot of sense :) 15:24:56 EmilienM: kind of -- depends on what we mean by constellation :) 15:25:58 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 did I miss anything other than the work dims has started on writing up job descriptions for the help-wanted areas? 15:26:42 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 no rush dhellmann :) 15:27:57 got some feedback from Chris Price on email 15:27:57 maybe we want to move on to other topics, then? 15:28:01 oh, good 15:29:16 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 there are different rules for the board meeting, I think 15:30:13 the board asks members not to post summaries before the official minutes are posted, I think? 15:30:28 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 but I don't think that applies to the joint leadership meeting, since that's not a board meeting 15:30:50 I was going to post an email summary based on my own notes as a personal summary 15:31:25 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 right. yeah, official minutes will presumably eventually appear at 15:31:36 #link https://wiki.openstack.org/wiki/Governance/Foundation/20May2018BoardMinutes 15:31:40 zaneb : right, my point is that the rule on official minutes does not apply here 15:31:59 we met with the board, but it was not an operating meeting of the board of directors 15:32:11 *part* of the day was, but I wasn't in the room then so my summary won't cover that anyway 15:32:12 yeah, afaik it is a "joint leadership meeting" 15:32:15 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 well, there was a roll call and a motion was approved 15:32:37 while we were there 15:32:52 yes, true, that portion of the meeting was more official than the rest 15:32:52 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 do we want to confirm with the board to have a clear understanding? 15:32:59 the agenda that day was a bit messy 15:33:10 ok, I'll ask Alan before I post anything 15:33:12 maybe this is part of increasing communication with our board :) 15:33:27 #action dhellmann to ask Alan about posting a summary of the joint leadership meeting 15:34:40 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 what else is on your minds this week? 15:37:40 dhellmann: you have the extra vote now 15:38:05 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 ++ 15:38:52 TheJulia : thanks 15:38:59 * ttx crosses one more item from his giant list 15:39:01 fungi : ++ 15:39:35 #link http://lists.openstack.org/pipermail/openstack-dev/2018-May/130567.html key store in base services 15:39:44 fungi: are we going to specify which key store? 15:39:47 was the start of the thread where it was suggested 15:39:56 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 zaneb: consensus so far seemed to be around "a castellan-compatible key store" without specifying any one in particular 15:40:40 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 ok, that makes sense 15:41:05 afaik castellan has a 'vault' driver, but barbican also has one too 15:41:10 mnaser: well, castellan was the result of complaints that barbican meant having an extra service 15:41:15 when people were saying Barbican in particular I was wondering if it was more a job for constellations than base services... 15:41:58 i guess this could be a start in openstack projects being able to be used independently 15:42:04 which is good too 15:42:42 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 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 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 yes, that is a bit unusual 15:45:55 I guess one difference is whether the secret is part of the deployment or something owned by an end-user 15:46:45 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 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 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 maybe that workflow is normal and expected, though, I just don't know 15:52:05 The reason that Vault it plugged both at castellan and Barbican levels is because those things do not strictly overlap 15:53:06 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 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 I guess I'm not being clear. 15:54:47 If a user has to create a key to use a feature in cinder, is Vault "good enough"? 15:55:25 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 dhellmann: I /think/ castellan will let you create a key on Vault alright 15:55:51 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 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 https://github.com/openstack/castellan/blob/master/castellan/key_manager/key_manager.py#L43 - create_key 15:57:01 and yes vault manager supports it 15:57:01 dims: yeah 15:57:02 TheJulia : definitely muddy water, if not weeds 15:57:25 right, castellan *can* talk to vault, but it's not a REST API 15:57:36 correct, calls vault directly - https://github.com/openstack/castellan/blob/master/castellan/key_manager/vault_key_manager.py#L139 15:57:59 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 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 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 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 i don't follow 15:58:35 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 Does Cinder volume encryption require you to provide your own key ? Or does it just generate one for you ? 15:58:52 good question for smcginnis ^ ? :) 15:58:53 etcd has a non-openstack api and it's in the base services list 15:59:23 fungi : do we expect users to interact with etcd? 15:59:24 zaneb : yes, that's a good way of putting it 15:59:34 fungi: the cloud user never has to poke any data into etcd 15:59:38 i'm still not following. we wouldn't be saying deployments are required to expose cinder volume encryption either way 15:59:42 do we want every service to invent its own API for creating or uploading keys? 16:00:30 dhellmann: hrm, isn't that what Castellan does ? 16:00:37 dhellmann : we want them to use the common library (like oslo.db and oslo.messaging) 16:00:38 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 we do not, in any other case, require users to use our client libraries 16:00:47 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 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 You create keys on the secret store. 16:01:04 dims : end users do not use those libraries, though 16:01:24 dhellmann : right, they use the native stuff directly like vault or barbican 16:01:49 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 that has nothing to do with end users uploading keys 16:02:18 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 so i really, really, really don't see where this "exposing non-openstack apis to end users" tangent is coming from 16:02:55 it's not just vault, folks want to use castellan + custodia ( https://review.openstack.org/#/c/515190/ ) 16:02:58 fungi : true. that's 1 use case. Is that the only case where being generic about the keystore is useful? 16:03:09 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 and KMIP https://review.openstack.org/#/c/298991/ 16:03:22 yep ttx 16:03:22 Now I'm missing most of the context from that discussion 16:03:26 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 But I remember us going into deep 16:03:51 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 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 with dave-mccowan and kfarr and others 16:04:29 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 if that discussion of 'castellan vs barbican' has been had and a conclusion has been reached 16:04:42 maybe we should just focus on the base services discussion 16:04:44 but that feature will obviously be unavailable on clouds without Barbican, even if they have Vault 16:05:00 dhellmann : another data point, some folks like Huawei have their own barbican equivalent, so castellan is the better integration point 16:05:30 zaneb: right -- so THAT was raised as an unresolved issue last time. Reliance on Barbican-specific features 16:06:08 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 I'm ok with that btw. just trying to clarify Doug 16:06:28 thanks, zaneb 16:06:44 It might still be a problem 16:06:49 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 Doug's point that not all features we might want will be enabled by having just castellan 16:06:57 well, we can always extend castellan 16:07:03 to support barbican specific features 16:07:12 enter key and the apostrophe key are too close as usual 16:07:20 mnaser : we cannot require users to use a specific client library for the trademark programs 16:07:26 mnaser: except those "features" are out of scope for Vault 16:07:29 so we have to enable a REST API for those things at some point 16:07:39 and right now our REST API for this is barbican 16:07:45 Basically the issue here is that Barbican is more than a store 16:07:55 which is why it can plug into Vault for store feature 16:08:01 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 yep fungi 16:08:21 so maybe for now we can say 'castellan' but eventually drop it if we really start running into issues 16:08:23 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 we might be discussing something that is non problematic? 16:08:31 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 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 smcginnis : how would you implement user-provided keys? 16:09:22 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 yeah, it's a fine first step. I just expect us to have to revisit it very soon. 16:09:33 dhellmann: That's the open question. 16:09:34 ++ dims 16:09:44 dims: ++ 16:09:45 maybe when that happens it will be clear why in a way that I seem unable to express. 16:10:15 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 I remember DuncanT had some concerns about Barbican, but I do not know enough about that area to really comment. 16:10:22 dims: that sounds a bit... weird though 16:10:40 People who end up doing Castellan+Vault might be forced to change 16:11:09 arent those the same people who didnt want to run barbican in the first place? :\ 16:11:21 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 mysql / postgresql situation 16:11:41 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 If the projects evolve to have that need, so be it, but at that point it is a conscious decision. 16:12:24 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 ttx: I guess I am questioning that 90% number, though. 16:12:56 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 it's a simple rest api, it can integrate with vault if you're already running it 16:13:33 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 let's get a concrete proposal written up and have some project teams comment on it 16:13:42 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 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 Last time the only things that were raised as potentially needing Barbican were Octavia and Designate iirc 16:13:59 Octavia now uses Castellan... 16:14:13 Octavia support both 16:14:30 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 So 90% might be 99% :) 16:14:40 johnsom: OR or AND ? 16:14:45 clarkb: That's a good point. 16:14:47 johnsom: and octavia has its own apis for storing certs? 16:15:04 mnaser: empowering the deployer to make the choice seems.. ideal, at least to me. 16:15:12 Currently it is an OR, but with flavors (coming) it could be AND. 16:15:37 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 johnsom: no I mean you need one of them, not both, right ? 16:15:45 clarkb No, the user provides Octavia with the reference to the secrets. We do not have an upload interface. 16:16:09 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 (this is dhellmann's concern aiui) 16:16:18 johnsom : how does the user create the secret? 16:16:27 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 ok 16:18:08 fungi , you started the meeting, do you want to close it out? 16:18:17 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 oh! sure 16:18:53 on an interop front ^ is not very friendly and is another case of infra wouldn't use that feature 16:18:54 #endmeeting