Re: [openstack-dev] [Keystone][Oslo] Future of Key Distribution Server, Trusted Messaging
On 11/29/2013 10:06 AM, Mark McLoughlin wrote: Hey Anyone got an update on this? The keystone blueprint for KDS was marked approved on Tuesday: https://blueprints.launchpad.net/keystone/+spec/key-distribution-server and a new keystone review was added on Sunday, but it must be a draft since I can't access it: https://review.openstack.org/58124 Thanks, Mark. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev It was an approach to deploying KDS inside of Keystone but as a separate server/running on a different port. Jamie Lennox was working at the same time and has a more mature patch. His review will be posted shortly, and mine can be abandoned. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone][Oslo] Future of Key Distribution Server, Trusted Messaging
I also don't like that the discussions suggested that because it would be hard to get Barbican incubated/integrated it should not be used. That is just crazy talk. TripleO merged with Tuskar because Tuskar is part of deployment. We are completing our incubation request for Barbican right now. I am waiting to send it until tomorrow as I figured it woudn't get a lot of traction right before the break. As I've said before, I think the KDS should be part of Barbican, but if Keystone wants to merge it sooner, I won't complain. Barbican has a pretty full roadmap through the Icehouse release, so I doubt my team would get to this. We'd be happy to help anyone interested in implementing it and I would merge it, but that's up to the authors. The public / private service argument I don't really get. The KDS will be an internal server regardless of whether it is in Barbican or Keystone so I don't think that is a differentiator. Seems to me that pulling Barbican into the identity _program_, but still as its own project/repo/etc. would solve that problem. Not sure I agree here. Key management solves many problems, some of which are identity problems, but key management is not fundamentally an identity service. For example, SSL certificates for services, symmetric key generation for at rest encryption, etc. What do we think are the reasons for combining the two efforts? Jarret smime.p7s Description: S/MIME cryptographic signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone][Oslo] Future of Key Distribution Server, Trusted Messaging
Excerpts from Adam Young's message of 2013-11-25 20:25:50 -0800: Back in the Day, Barbican was just one Service of Cloud Keep. While I would say that KDS belongs in the Cloud Keep, it is not the same as, and should not be deployed with Barbican. Is it possible to keep them as separate services? I think that is the right way to go. Barbican is for the end users of Cloud, but KDS is not. Does this make sense? They're doing the same fundamental thing for two different sets of users with two overlapping use cases. Why would we implement two KDS services for this? I also don't like that the discussions suggested that because it would be hard to get Barbican incubated/integrated it should not be used. That is just crazy talk. TripleO merged with Tuskar because Tuskar is part of deployment. Seems to me that pulling Barbican into the identity _program_, but still as its own project/repo/etc. would solve that problem. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone][Oslo] Future of Key Distribution Server, Trusted Messaging
Hey Anyone got an update on this? The keystone blueprint for KDS was marked approved on Tuesday: https://blueprints.launchpad.net/keystone/+spec/key-distribution-server and a new keystone review was added on Sunday, but it must be a draft since I can't access it: https://review.openstack.org/58124 Thanks, Mark. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone][Oslo] Future of Key Distribution Server, Trusted Messaging
On Tue, Nov 26, 2013 at 5:25 AM, Adam Young ayo...@redhat.com wrote: Back in the Day, Barbican was just one Service of Cloud Keep. While I would say that KDS belongs in the Cloud Keep, it is not the same as, and should not be deployed with Barbican. Is it possible to keep them as separate services? I think that is the right way to go. Barbican is for the end users of Cloud, but KDS is not. Does this make sense? I think that make sense to say that Barbican is for public and KDS for internal services and should be kept as different WSGI daemons. If we were having it in two different projects when assuming barbican graduate it may end-up more confusing for the end user. Chmouel. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Keystone][Oslo] Future of Key Distribution Server, Trusted Messaging
Hello folks, FWIW, I've created a wiki page here aimed at easing the code transition to barbican for the KDS patch: https://github.com/cloudkeep/barbican/wiki/Blueprint:-KDS-Service Please let us know if we can be of further help. Thanks, John ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From: Thierry Carrez [thie...@openstack.org] Sent: Monday, November 25, 2013 4:17 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Keystone][Oslo] Future of Key Distribution Server, Trusted Messaging Adam Young wrote: Keep KDS configuration separate from the Keystone configuration: the fact that they both point to the same host and port is temporary. In fact, we should probably spin up a separate wsgi service/port inside Keystone for just the KDS. This is not hard to do, and will support splitting it off into its own service. KDS should not show up in the Service catalog. It is not an end user visible service and should not look like one to the rest of the world. Once we have it up and running, we can move it to its own service or hand off to Barbican when appropriate. Right, I think a decent trade-off between availability and avoiding code duplication would be to have a minimal KDS available as an option in Keystone, with Barbican/something-else being developed in parallel as the complex/featureful/configurable option. If Barbican/something-else reaches feature parity, covers the basic and simple use case and is integrated, we could deprecate the in-Keystone minimal-KDS option. I know this plan looks a bit like the nova-network chronicles, but I think the domain is more simple so feature parity is not as much of a challenge. -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone][Oslo] Future of Key Distribution Server, Trusted Messaging
Back in the Day, Barbican was just one Service of Cloud Keep. While I would say that KDS belongs in the Cloud Keep, it is not the same as, and should not be deployed with Barbican. Is it possible to keep them as separate services? I think that is the right way to go. Barbican is for the end users of Cloud, but KDS is not. Does this make sense? On 11/25/2013 11:24 AM, John Wood wrote: Hello folks, FWIW, I've created a wiki page here aimed at easing the code transition to barbican for the KDS patch: https://github.com/cloudkeep/barbican/wiki/Blueprint:-KDS-Service Please let us know if we can be of further help. Thanks, John ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From: Thierry Carrez [thie...@openstack.org] Sent: Monday, November 25, 2013 4:17 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Keystone][Oslo] Future of Key Distribution Server, Trusted Messaging Adam Young wrote: Keep KDS configuration separate from the Keystone configuration: the fact that they both point to the same host and port is temporary. In fact, we should probably spin up a separate wsgi service/port inside Keystone for just the KDS. This is not hard to do, and will support splitting it off into its own service. KDS should not show up in the Service catalog. It is not an end user visible service and should not look like one to the rest of the world. Once we have it up and running, we can move it to its own service or hand off to Barbican when appropriate. Right, I think a decent trade-off between availability and avoiding code duplication would be to have a minimal KDS available as an option in Keystone, with Barbican/something-else being developed in parallel as the complex/featureful/configurable option. If Barbican/something-else reaches feature parity, covers the basic and simple use case and is integrated, we could deprecate the in-Keystone minimal-KDS option. I know this plan looks a bit like the nova-network chronicles, but I think the domain is more simple so feature parity is not as much of a challenge. -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone][Oslo] Future of Key Distribution Server, Trusted Messaging
I hear a concerted effort to get this bootstrapped in Keystone. We can do this if it is the voice of the majority. If we do: Keep KDS configuration separate from the Keystone configuration: the fact that they both point to the same host and port is temporary. In fact, we should probably spin up a separate wsgi service/port inside Keystone for just the KDS. This is not hard to do, and will support splitting it off into its own service. +1 on spinning up a new service/wsgi KDS should not show up in the Service catalog. It is not an end user visible service and should not look like one to the rest of the world. I believe that KDS should be discoverable, but I agree that it is not an end user service, so I am unsure of the best approach wrt the catalog. The other concern is the library interfacing with KDS (I would assume this goes into keystoneclient? At least for the time being). Once we have it up and running, we can move it to its own service or hand off to Barbican when appropriate. Are people OK with the current API implementation? I didn;t see a lot of outside comment on the code review, and there were certainly some aspects of it that were unclear. I think the API is if not ready to go, very close (maybe a single cleanup revision). If we are going to do this lets get the spec done ASAP and get the code in right away so we can get traction on it. Icehouse milestones will be coming through fast. I think it is imminently possible to have this in the repo and running fairly quickly with concerted effort. The code might need minor tweaking to conform to the spec if it changes. But as I recall almost 100% of the back and forth at this point was does it belong in keystone. https://review.openstack.org/#/c/40692/ --Morgan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone][Oslo] Future of Key Distribution Server, Trusted Messaging
On Sun, Nov 24, 2013 at 1:52 PM, Morgan Fainberg m...@metacloud.com wrote: The other concern is the library interfacing with KDS (I would assume this goes into keystoneclient? At least for the time being). I would rather see the client get its own repo, too. We still need to do that with the middleware. dt -- Dean Troyer dtro...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone][Oslo] Future of Key Distribution Server, Trusted Messaging
On 11/22/2013 01:49 PM, Mark McLoughlin wrote: On Fri, 2013-11-22 at 11:04 +0100, Thierry Carrez wrote: Russell Bryant wrote: [...] I'm not thrilled about the prospect of this going into a new project for multiple reasons. - Given the priority and how long this has been dragging out, having to wait for a new project to make its way into OpenStack is not very appealing. - A new project needs to be able to stand on its own legs. It needs to have a reasonably sized development team to make it sustainable. Is this big enough for that? Having it in Barbican (and maybe have Barbican join under the identity program) would mitigate the second issue. But the first issue stands, and I share your concerns. Yes, I agree. It's disappointing that this change of plans looks like its going to push out the ability of an OpenStack deployment to be secured. If this becomes a Barbican API, then we might be able to get the code working quickly ... but it will still be some time before Barbican is an integrated project, and so securing OpenStack will only be possible if you use this non-integrated project. Mark. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I hear a concerted effort to get this bootstrapped in Keystone. We can do this if it is the voice of the majority. If we do: Keep KDS configuration separate from the Keystone configuration: the fact that they both point to the same host and port is temporary. In fact, we should probably spin up a separate wsgi service/port inside Keystone for just the KDS. This is not hard to do, and will support splitting it off into its own service. KDS should not show up in the Service catalog. It is not an end user visible service and should not look like one to the rest of the world. Once we have it up and running, we can move it to its own service or hand off to Barbican when appropriate. Are people OK with the current API implementation? I didn;t see a lot of outside comment on the code review, and there were certainly some aspects of it that were unclear. https://review.openstack.org/#/c/40692/ Note that we have lost Simo as a resource for this, so if it is going to move forward, we need other members of the community to step forward and keep the process going. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone][Oslo] Future of Key Distribution Server, Trusted Messaging
Russell Bryant wrote: [...] I'm not thrilled about the prospect of this going into a new project for multiple reasons. - Given the priority and how long this has been dragging out, having to wait for a new project to make its way into OpenStack is not very appealing. - A new project needs to be able to stand on its own legs. It needs to have a reasonably sized development team to make it sustainable. Is this big enough for that? Having it in Barbican (and maybe have Barbican join under the identity program) would mitigate the second issue. But the first issue stands, and I share your concerns. -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone][Oslo] Future of Key Distribution Server, Trusted Messaging
On 11/21/13, 7:51 PM, Jamie Lennox jamielen...@redhat.com wrote: So i've a feeling that this was proposed and dismissed once before. I don't remember why. So my concern with barbican is that i'm under the impression that barbican was going to be an 'overcloud' service. That's a really bad way of putting it, but it is service and user facing and discovered via the service catalog. This feature will need to be configured at a lower level (runs in situations without a token) and so we will need to configure the services to point to an IP for the KDS service. Why would there be a need for token less authentication? My understanding of the feature is that each service account would have a KDS key associated with it. This means that each account would need to authenticate to Keystone before talking to Barbican. Are there service accounts that don’t have a keystone account? Is this an expected deployment of barbican (i can't see why not)? We certainly could enable this if needed. We already create separate uwsgi processes for the main and admin apis. We could create another one for the KDS. I’d rather not do that unless we have to though. Jarret Jamie On Thu, 2013-11-21 at 20:08 +, Jarret Raim wrote: The Barbican team has been taking a look at the KDS feature and the proposed patch and I think this may be better placed in Barbican rather than Keystone. The patch, from what I can tell, seems to require that a service account create use a key under its own tenant. In this use case, Barbican can handle the entire exchange and Keystone can just provide auth/auth for the process. This would allow for some great additional features including guaranteed entropy and additional security through the use of HSMs, auditing / logging, etc. Barbican is pretty far along at this point and it doesn¹t appear to be a huge amount of work to move the patch over as it doesn¹t seem to use any Keystone internals. What would people think about this approach? We¹re happy to help move the patch over and I¹m certainly happy to merge it as it feels like a good feature for barbican. Jarret On 11/21/13, 12:55 AM, Russell Bryant rbry...@redhat.com wrote: Greetings, I'd like to check in on the status of this API addition: https://review.openstack.org/#/c/40692/ The last comment is: propose against stackforge as discussed at summit? I don't see a session about this and from a quick look, don't see notes related to it in other session etherpads. When was this discussed? Can you summarize it? Last I heard, this was just being deferred to be merged early in Icehouse [1]. This is blocking one of the most important security features for OpenStack, IMO (trusted messaging) [2]. We've been talking about it for years. Someone has finally made some real progress on it and I feel like it has been given little to no attention. I'm not thrilled about the prospect of this going into a new project for multiple reasons. - Given the priority and how long this has been dragging out, having to wait for a new project to make its way into OpenStack is not very appealing. - A new project needs to be able to stand on its own legs. It needs to have a reasonably sized development team to make it sustainable. Is this big enough for that? What's the thinking on this? [1] http://lists.openstack.org/pipermail/openstack-dev/2013-August/013992.ht ml [2] https://review.openstack.org/#/c/37913/ -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone][Oslo] Future of Key Distribution Server, Trusted Messaging
On Fri, 2013-11-22 at 11:04 +0100, Thierry Carrez wrote: Russell Bryant wrote: [...] I'm not thrilled about the prospect of this going into a new project for multiple reasons. - Given the priority and how long this has been dragging out, having to wait for a new project to make its way into OpenStack is not very appealing. - A new project needs to be able to stand on its own legs. It needs to have a reasonably sized development team to make it sustainable. Is this big enough for that? Having it in Barbican (and maybe have Barbican join under the identity program) would mitigate the second issue. But the first issue stands, and I share your concerns. Yes, I agree. It's disappointing that this change of plans looks like its going to push out the ability of an OpenStack deployment to be secured. If this becomes a Barbican API, then we might be able to get the code working quickly ... but it will still be some time before Barbican is an integrated project, and so securing OpenStack will only be possible if you use this non-integrated project. Mark. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone][Oslo] Future of Key Distribution Server, Trusted Messaging
On 11/21/2013 01:55 AM, Russell Bryant wrote: Greetings, I'd like to check in on the status of this API addition: https://review.openstack.org/#/c/40692/ The last comment is: propose against stackforge as discussed at summit? Yes, it was discussed in a small group, and not officially. That comment is just a place holder. Instead of running it in Keystone, it will run in its own service. There really is nothing in Keystone that related to KDS, nor the other way around. KDS is Undercloud specific functiojnality (for now) and not really appropriate to expose via the Service catalog. The current thinking is that Pecan (and maybe WSME) and the current code base is the correct way to launch it. Like all our web services, I suggest the production version run via mod_wsgi in Apache HTTPD to allow for TLS and X509 Certificate support. The service/project will still be under the Keystone program (for now, we can discuss where it will live long term). It should be a relatively short ramp up to get it deployed. I know the Barbican folks are interested as well, and I expect they will be contributing to make this happen. I don't see a session about this and from a quick look, don't see notes related to it in other session etherpads. When was this discussed? Can you summarize it? Last I heard, this was just being deferred to be merged early in Icehouse [1]. This is blocking one of the most important security features for OpenStack, IMO (trusted messaging) [2]. We've been talking about it for years. Someone has finally made some real progress on it and I feel like it has been given little to no attention. I'm not thrilled about the prospect of this going into a new project for multiple reasons. - Given the priority and how long this has been dragging out, having to wait for a new project to make its way into OpenStack is not very appealing. - A new project needs to be able to stand on its own legs. It needs to have a reasonably sized development team to make it sustainable. Is this big enough for that? What's the thinking on this? [1] http://lists.openstack.org/pipermail/openstack-dev/2013-August/013992.html [2] https://review.openstack.org/#/c/37913/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone][Oslo] Future of Key Distribution Server, Trusted Messaging
The Barbican team has been taking a look at the KDS feature and the proposed patch and I think this may be better placed in Barbican rather than Keystone. The patch, from what I can tell, seems to require that a service account create use a key under its own tenant. In this use case, Barbican can handle the entire exchange and Keystone can just provide auth/auth for the process. This would allow for some great additional features including guaranteed entropy and additional security through the use of HSMs, auditing / logging, etc. Barbican is pretty far along at this point and it doesn¹t appear to be a huge amount of work to move the patch over as it doesn¹t seem to use any Keystone internals. What would people think about this approach? We¹re happy to help move the patch over and I¹m certainly happy to merge it as it feels like a good feature for barbican. Jarret On 11/21/13, 12:55 AM, Russell Bryant rbry...@redhat.com wrote: Greetings, I'd like to check in on the status of this API addition: https://review.openstack.org/#/c/40692/ The last comment is: propose against stackforge as discussed at summit? I don't see a session about this and from a quick look, don't see notes related to it in other session etherpads. When was this discussed? Can you summarize it? Last I heard, this was just being deferred to be merged early in Icehouse [1]. This is blocking one of the most important security features for OpenStack, IMO (trusted messaging) [2]. We've been talking about it for years. Someone has finally made some real progress on it and I feel like it has been given little to no attention. I'm not thrilled about the prospect of this going into a new project for multiple reasons. - Given the priority and how long this has been dragging out, having to wait for a new project to make its way into OpenStack is not very appealing. - A new project needs to be able to stand on its own legs. It needs to have a reasonably sized development team to make it sustainable. Is this big enough for that? What's the thinking on this? [1] http://lists.openstack.org/pipermail/openstack-dev/2013-August/013992.html [2] https://review.openstack.org/#/c/37913/ -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone][Oslo] Future of Key Distribution Server, Trusted Messaging
On 11/21/2013 03:08 PM, Jarret Raim wrote: The Barbican team has been taking a look at the KDS feature and the proposed patch and I think this may be better placed in Barbican rather than Keystone. The patch, from what I can tell, seems to require that a service account create use a key under its own tenant. In this use case, Barbican can handle the entire exchange and Keystone can just provide auth/auth for the process. This would allow for some great additional features including guaranteed entropy and additional security through the use of HSMs, auditing / logging, etc. Barbican is pretty far along at this point and it doesn¹t appear to be a huge amount of work to move the patch over as it doesn¹t seem to use any Keystone internals. What would people think about this approach? We¹re happy to help move the patch over and I¹m certainly happy to merge it as it feels like a good feature for barbican. I'm ok with it. I would, however, like to suggest that we work to make the KDS as a seperatly runnable service, so that you don't need to run the rest of Barbican to get it. Barbican was originally envisioned as a customer/outward facing project, and KDS is internal (primarily), they should be runnable at the same time, without getting confused about which service they belong in. Thus, While I would be OK with KDS under the Barbican/CloudKeep program, it might not make sense to bundle it with the Barbican server. Using Barbican as a way to bootstrap the deployment for the short term is probably OK, though. Jarret On 11/21/13, 12:55 AM, Russell Bryant rbry...@redhat.com wrote: Greetings, I'd like to check in on the status of this API addition: https://review.openstack.org/#/c/40692/ The last comment is: propose against stackforge as discussed at summit? I don't see a session about this and from a quick look, don't see notes related to it in other session etherpads. When was this discussed? Can you summarize it? Last I heard, this was just being deferred to be merged early in Icehouse [1]. This is blocking one of the most important security features for OpenStack, IMO (trusted messaging) [2]. We've been talking about it for years. Someone has finally made some real progress on it and I feel like it has been given little to no attention. I'm not thrilled about the prospect of this going into a new project for multiple reasons. - Given the priority and how long this has been dragging out, having to wait for a new project to make its way into OpenStack is not very appealing. - A new project needs to be able to stand on its own legs. It needs to have a reasonably sized development team to make it sustainable. Is this big enough for that? What's the thinking on this? [1] http://lists.openstack.org/pipermail/openstack-dev/2013-August/013992.html [2] https://review.openstack.org/#/c/37913/ -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Keystone][Oslo] Future of Key Distribution Server, Trusted Messaging
Greetings, I'd like to check in on the status of this API addition: https://review.openstack.org/#/c/40692/ The last comment is: propose against stackforge as discussed at summit? I don't see a session about this and from a quick look, don't see notes related to it in other session etherpads. When was this discussed? Can you summarize it? Last I heard, this was just being deferred to be merged early in Icehouse [1]. This is blocking one of the most important security features for OpenStack, IMO (trusted messaging) [2]. We've been talking about it for years. Someone has finally made some real progress on it and I feel like it has been given little to no attention. I'm not thrilled about the prospect of this going into a new project for multiple reasons. - Given the priority and how long this has been dragging out, having to wait for a new project to make its way into OpenStack is not very appealing. - A new project needs to be able to stand on its own legs. It needs to have a reasonably sized development team to make it sustainable. Is this big enough for that? What's the thinking on this? [1] http://lists.openstack.org/pipermail/openstack-dev/2013-August/013992.html [2] https://review.openstack.org/#/c/37913/ -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
