Re: [OpenStack Foundation] The two types of interoperability
Mark Collier wrote:
To get close to total interop (which I think is the goal, or ideal at least) you have to start where you are (bootstrap).
If we were to, at this moment, define OpenStack as something no current cloud would qualify for, that wouldn't be very practical. I think we can bootstrap while encouraging the trend to move towards the ideal over time.
As far as we clearly establish that "total interoperability" is the end goal, then I think it's OK to start with some compromises to bootstrap the effort, then gradually (but constantly) increase constraints. That said, that only works if there is a bit of consensus in OpenStack companies that this is the end goal, otherwise you won't be able to increase the constraints. Does everyone agree on the end goal ? In all cases, there is a lot of value in having the board clearly stating it. -- Thierry Carrez (ttx)
Interop is a good goal. However, I frankly don't see us ever achieving "total interoperability" by exclusively relying on trademark enforcement as leverage. The only path I see currently towards the type of interop that would allow for workload federation across providers is if there was an upstream project, whereby various providers would proactively write and maintain connectors into a central auth system... kinda like an "openstack native rightscale." Those deploying openstack on-prem would then be able to leverage this module to federate on-prem environment with all the providers that have a functional driver. I.e. just like you have multiple storage provider drivers to cinder, we need services providers to write and maintain drivers against something in OpenStack. I've seen discussions and even blueprints on federated keystone in the past, but am not sure how much progress has been made... Thierry maybe you know more? I.e. there has to be a technology solution to back up administrative action. Not just trademarks and definitions. Thoughts? -Boris On Wed, Feb 5, 2014 at 6:25 AM, Thierry Carrez <thierry@openstack.org>wrote:
Mark Collier wrote:
To get close to total interop (which I think is the goal, or ideal at least) you have to start where you are (bootstrap).
If we were to, at this moment, define OpenStack as something no current cloud would qualify for, that wouldn't be very practical. I think we can bootstrap while encouraging the trend to move towards the ideal over time.
As far as we clearly establish that "total interoperability" is the end goal, then I think it's OK to start with some compromises to bootstrap the effort, then gradually (but constantly) increase constraints.
That said, that only works if there is a bit of consensus in OpenStack companies that this is the end goal, otherwise you won't be able to increase the constraints. Does everyone agree on the end goal ?
In all cases, there is a lot of value in having the board clearly stating it.
-- Thierry Carrez (ttx)
_______________________________________________ Foundation mailing list Foundation@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation
On 02/06/2014 05:21 PM, Boris Renski wrote:
Interop is a good goal. However, I frankly don't see us ever achieving "total interoperability" by exclusively relying on trademark enforcement as leverage.
The only path I see currently towards the type of interop that would allow for workload federation across providers is if there was an upstream project, whereby various providers would proactively write and maintain connectors into a central auth system... kinda like an "openstack native rightscale." Those deploying openstack on-prem would then be able to leverage this module to federate on-prem environment with all the providers that have a functional driver. I.e. just like you have multiple storage provider drivers to cinder, we need services providers to write and maintain drivers against something in OpenStack. I've seen discussions and even blueprints on federated keystone in the past, but am not sure how much progress has been made... Thierry maybe you know more?
I.e. there has to be a technology solution to back up administrative action. Not just trademarks and definitions.
Thoughts?
Federation is interesting, too. However, I think you can have what I would consider total interop without federation. As a user, I just want to be able to point my application at a different cloud (with a different set of credentials) and have it work and behave the same way. There's no federation needed to achieve that. The OpenStack project itself is a huge consumer of OpenStack clouds via the infrastructure project. They shouldn't have to do special casing for which cloud they're talking to, yet they do. -- Russell Bryant
On Feb 6, 2014, at 3:36 PM, Russell Bryant <rbryant@redhat.com> wrote:
As a user, I just want to be able to point my application at a different cloud (with a different set of credentials) and have it work and behave the same way. There's no federation needed to achieve that.
The OpenStack project itself is a huge consumer of OpenStack clouds via the infrastructure project. They shouldn't have to do special casing for which cloud they're talking to, yet they do.
How do you fix this without dictating architecture/design decisions? I’ve been building infrastructure for 23 years and deploying apps on top of infrastructure in an automated fashion for 13 years. I just don’t understand how you resolve this problem without either special casing OR dictating a reference architecture. Am I missing something obvious? I sure would like to know if I am. --Randy Founder & CEO, Cloudscaling Board of Directors, OpenStack Foundation +1 (415) 787-2253 [SMS or voice] TWITTER: twitter.com/randybias LINKEDIN: linkedin.com/in/randybias CALENDAR: doodle.com/randybias
participants (4)
-
Boris Renski
-
Randy Bias
-
Russell Bryant
-
Thierry Carrez