Re: [Openstack] Setting Expectations
Andrew Clay Shafer wrote: What is OpenStack? Clearly, OpenStack is many things to many people and organizations. What does it mean to contribute to OpenStack? What does it mean to deploy OpenStack? What does it mean to operate OpenStack? What do we mean when we say compatible? interoperable? community? branded? Is OpenStack a framework? a project? a product? Recent discussions make it clear that we have a lot of different ideas about all of these things. These are important and difficult questions. As you say, OpenStack is many different things to different people. So far we survived while avoiding to answer clearly, mostly because we had no good way of coming up with answers. That ultimately creates tension between participants in our community when the different models clash. My hope is that the formation of the Foundation will help providing a forum for this discussion, and a mechanism to come with clearer answers. I actually see that as the main mission of the Foundation for the first year. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Setting Expectations
These are important and difficult questions. As you say, OpenStack is many different things to different people. So far we survived while avoiding to answer clearly, mostly because we had no good way of coming up with answers. That ultimately creates tension between participants in our community when the different models clash. Yes, these are difficult questions. I'm don't agree with the assertion that there was no good way of coming up with answers, but for a variety of reasons, we did not. You say OpenStack has survived, but I believe we may have compounded and multiplied the challenges OpenStack faces by collectively neglecting to resolve this. Without going into all the technical necessity and political complexity, I would argue we allowed OpenStack fragmentation at the project level. Without a unified conscience of purpose, the fragmentation only gets magnified at the point users are interacting with different deployments. I want to also respond to the idea that OpenStack can be seen like the Linux kernel. This is a point I made and articulated early in the OpenStack discussion. The artifacts of my using that analogy date back to the Fall of 2010: http://www.slideshare.net/littleidea/open-stack-sdforum/44 http://www.slideshare.net/littleidea/openstack-summit-a-community-of-service-providers/27 I don't believe that the kernel is a perfect analogy, but even if it was this one sentence 'OpenStack is like the Linux kernel' will not make it so. Linus Torvalds provides both technical oversight and the kind of conscience I keep referring to. What is the OpenStack equivalent of this? https://lkml.org/lkml/2012/3/8/495 I suggest everyone read the whole email from Linus at that link. On some level, this attitude is what prevents a preponderance of the tension we have recently seen in OpenStack mailing lists. Granted, it implies other more pointed conflict, but some of that is Linus being Linus. The very real choice in these types of projects is between resolving open conflict early and often or sublimated conflicts that tend to erupt with a vengeance later. My hope is that the formation of the Foundation will help providing a forum for this discussion, and a mechanism to come with clearer answers. I actually see that as the main mission of the Foundation for the first year. I share this hope, but I also don't think we should abdicate all responsibility for this to the Foundation. We are all ostensibly individual members of the foundation, if not corporate members. OpenStack will be what we collectively make it. Cheers, Andrew ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Setting Expectations
On Tue, Aug 14, 2012 at 1:06 PM, Andrew Clay Shafer
a...@parvuscaptus.com wrote:
You say OpenStack has survived, but I believe we may have compounded and
multiplied the challenges OpenStack faces by collectively neglecting to
resolve this. Without going into all the technical necessity and political
complexity, I would argue we allowed OpenStack fragmentation at the project
level. Without a unified conscience of purpose, the fragmentation only gets
magnified at the point users are interacting with different deployments.
This fragmentation with projects and goals is a real threat to the
long-term viability of OpenStack as a cloud standard.
I don't believe that the kernel is a perfect analogy, but even if it was
this one sentence 'OpenStack is like the Linux kernel' will not make it so.
Honestly, I HATE this analogy. OpenStack has no BDFL, it has now a
foundation that is governed by Corporate interests that have a history
of working on common standards and tweaking them to add 'value'
('differentiation' I think is the buzzword for that). The
organization of the foundation is partially designed to prevent any
one or two of these interests from pushing the whole in their
particular direction. The foundation will have to prove itself
capable of pulling the projects forward. Together.
What is the OpenStack equivalent of this?
https://lkml.org/lkml/2012/3/8/495
The problem we have is that people in Linus' position are not created,
they grow and the position, respect and authority is earned. The TC
may be able to earn some of that over time, but without unifying
leadership it will be tough going. Hopefully their separation from
the rest of the board can give them a chance to provide the technical
leadership and direction needed even if it stubs a few toes along the
way.
It kills me that the acronym for OpenStack Foundation is OSF. While I
don't think we can really be the Linux of the cloud any time soon, we
will have to really work to NOT be the UNIX of the cloud...
dt
--
Dean Troyer
dtro...@gmail.com
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Setting Expectations
+1 to everything dean said.
On Tue, Aug 14, 2012 at 12:58 PM, Dean Troyer dtro...@gmail.com wrote:
On Tue, Aug 14, 2012 at 1:06 PM, Andrew Clay Shafer
a...@parvuscaptus.com wrote:
You say OpenStack has survived, but I believe we may have compounded and
multiplied the challenges OpenStack faces by collectively neglecting to
resolve this. Without going into all the technical necessity and
political
complexity, I would argue we allowed OpenStack fragmentation at the
project
level. Without a unified conscience of purpose, the fragmentation only
gets
magnified at the point users are interacting with different deployments.
This fragmentation with projects and goals is a real threat to the
long-term viability of OpenStack as a cloud standard.
I don't believe that the kernel is a perfect analogy, but even if it was
this one sentence 'OpenStack is like the Linux kernel' will not make it
so.
Honestly, I HATE this analogy. OpenStack has no BDFL, it has now a
foundation that is governed by Corporate interests that have a history
of working on common standards and tweaking them to add 'value'
('differentiation' I think is the buzzword for that). The
organization of the foundation is partially designed to prevent any
one or two of these interests from pushing the whole in their
particular direction. The foundation will have to prove itself
capable of pulling the projects forward. Together.
What is the OpenStack equivalent of this?
https://lkml.org/lkml/2012/3/8/495
The problem we have is that people in Linus' position are not created,
they grow and the position, respect and authority is earned. The TC
may be able to earn some of that over time, but without unifying
leadership it will be tough going. Hopefully their separation from
the rest of the board can give them a chance to provide the technical
leadership and direction needed even if it stubs a few toes along the
way.
It kills me that the acronym for OpenStack Foundation is OSF. While I
don't think we can really be the Linux of the cloud any time soon, we
will have to really work to NOT be the UNIX of the cloud...
dt
--
Dean Troyer
dtro...@gmail.com
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
[Openstack] Setting Expectations
What is OpenStack? Clearly, OpenStack is many things to many people and organizations. What does it mean to contribute to OpenStack? What does it mean to deploy OpenStack? What does it mean to operate OpenStack? What do we mean when we say compatible? interoperable? community? branded? Is OpenStack a framework? a project? a product? Recent discussions make it clear that we have a lot of different ideas about all of these things. Our collective and individual responsibilities to each other are also a point of tension. There is a marked difference in the perspective of those developing the projects, those operating the projects as services and the final consumers/clients of those services. If OpenStack is going to live up to it's full potential and stated mission, I believe there needs to be a much stronger collective conscience about how decisions are made. I feel we will all benefit by making some things more explicit. If the expectation is that OpenStack is a framework, which is a word I've heard people use many times, then does an upgrade path have to exist? The OpenStack dashboard was essentially rewritten to upgrade to a new version of Django. Was there any expectation that Django should upgrade itself for us? Upgrading an application to use a different versions of Rails, another framework, often borders on impossible, particularly if the application happens have some feature with a dependency of a gem that hasn't been kept in sync with the upstream project. Is OpenStack more or less complicated than those frameworks? What responsibility should OpenStack core development have to consider existing deployments? Frameworks are expected be a foundation to build on. By definition, changing foundations is not easy. Clearly, OpenStack can be deployed and operated, but if OpenStack needs to be easier to deploy, operate and upgrade, and that is a responsibility of OpenStack itself, that can't be something that get's tacked on at the end. There is no 'ease of deployment' powder to sprinkle on at the end. Distributions and tooling can and do obscure the difficultly for the downstream user, but that also leads to a lot of potential fragmentation. And is that the right answer? Who can and should answer that? That OpenStack should be easy to deploy and upgrade is somewhat at odds with OpenStack supporting every possible combination of hypervisor, storage and networking option, let alone what the expectation should be with closed source customizations/integrations. Which brings up questions of compatibility. API compatibility is potentially misleading if the semantics and behaviors vary. I've heard several service provider discuss ideas about how they can be differentiated in the market, and many of those ideas lead differences in APIs to expose. Is that wrong? Maybe, maybe not, but it certainly makes a lot of work if your core business is dependent on maintaining integrations with service providers. Taken to an extreme these decisions complicate and call into question any future of federated OpenStack services. I'm not advocating any choice here. I just want to point out there are compromises that have to be made. There are goals and desires for OpenStack that are at odds with each other. Some of that is a function of the perspective of persona, but a lot is also from fundamental differences in understanding about where OpenStack is, where OpenStack needs to be, and how to get there. If there isn't a core guiding conscience about what we are trying to accomplish that gets applied across the board, then I worry that the future of OpenStack ends up with more fragments optimizing for their perspective and inevitable skirmishes when the perspectives collide. I see there are many conversations we aren't having, which leads to surfacing all the unaddressed issues when someone does try to involve the community in discussions. OpenStack can't be all things, but we get to decide what it will be. The question is will we do that explicitly and consciously, or indirectly and passively. There is no one person who can address this alone. I'm hoping this can start a conversation. Best Regards, Andrew ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Setting Expectations
So many questions, so hard to reply. Whats the best question to answer here ;) From: Andrew Clay Shafer a...@parvuscaptus.commailto:a...@parvuscaptus.com Date: Fri, 10 Aug 2012 14:41:03 -0700 To: openstack openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Subject: [Openstack] Setting Expectations What is OpenStack? Clearly, OpenStack is many things to many people and organizations. What does it mean to contribute to OpenStack? What does it mean to deploy OpenStack? What does it mean to operate OpenStack? What do we mean when we say compatible? interoperable? community? branded? Is OpenStack a framework? a project? a product? Recent discussions make it clear that we have a lot of different ideas about all of these things. Our collective and individual responsibilities to each other are also a point of tension. There is a marked difference in the perspective of those developing the projects, those operating the projects as services and the final consumers/clients of those services. If OpenStack is going to live up to it's full potential and stated mission, I believe there needs to be a much stronger collective conscience about how decisions are made. I feel we will all benefit by making some things more explicit. If the expectation is that OpenStack is a framework, which is a word I've heard people use many times, then does an upgrade path have to exist? The OpenStack dashboard was essentially rewritten to upgrade to a new version of Django. Was there any expectation that Django should upgrade itself for us? Upgrading an application to use a different versions of Rails, another framework, often borders on impossible, particularly if the application happens have some feature with a dependency of a gem that hasn't been kept in sync with the upstream project. Is OpenStack more or less complicated than those frameworks? What responsibility should OpenStack core development have to consider existing deployments? Frameworks are expected be a foundation to build on. By definition, changing foundations is not easy. Clearly, OpenStack can be deployed and operated, but if OpenStack needs to be easier to deploy, operate and upgrade, and that is a responsibility of OpenStack itself, that can't be something that get's tacked on at the end. There is no 'ease of deployment' powder to sprinkle on at the end. Distributions and tooling can and do obscure the difficultly for the downstream user, but that also leads to a lot of potential fragmentation. And is that the right answer? Who can and should answer that? That OpenStack should be easy to deploy and upgrade is somewhat at odds with OpenStack supporting every possible combination of hypervisor, storage and networking option, let alone what the expectation should be with closed source customizations/integrations. Which brings up questions of compatibility. API compatibility is potentially misleading if the semantics and behaviors vary. I've heard several service provider discuss ideas about how they can be differentiated in the market, and many of those ideas lead differences in APIs to expose. Is that wrong? Maybe, maybe not, but it certainly makes a lot of work if your core business is dependent on maintaining integrations with service providers. Taken to an extreme these decisions complicate and call into question any future of federated OpenStack services. I'm not advocating any choice here. I just want to point out there are compromises that have to be made. There are goals and desires for OpenStack that are at odds with each other. Some of that is a function of the perspective of persona, but a lot is also from fundamental differences in understanding about where OpenStack is, where OpenStack needs to be, and how to get there. If there isn't a core guiding conscience about what we are trying to accomplish that gets applied across the board, then I worry that the future of OpenStack ends up with more fragments optimizing for their perspective and inevitable skirmishes when the perspectives collide. I see there are many conversations we aren't having, which leads to surfacing all the unaddressed issues when someone does try to involve the community in discussions. OpenStack can't be all things, but we get to decide what it will be. The question is will we do that explicitly and consciously, or indirectly and passively. There is no one person who can address this alone. I'm hoping this can start a conversation. Best Regards, Andrew ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Setting Expectations
I personally equate OpenStack to the Linux Kernel. It's the foundation and core components that, in OpenStack's case, make up an Infrastructure as as Service (IaaS) system, a cloud kernel. We should expect the core components and APIs to be stable with sane deprecation policies, but OpenStack shouldn't do everything for everyone. It should facilitate and provide the stable framework or foundation in which to build production quality, large scale (and small) public and private IaaS systems. In and of itself I believe OpenStack is not an IaaS distribution, ala Linux distributions (Debian, Fedora, RedHat, SuSe, Ubuntu) which take the Linux kernel and build all the user-space and complementary services that make up a manageable, secure, monitored system. However, that doesn't mean OpenStack ignores the user/operator/packager/distro side of things. Where we the developers and operators of OpenStack see areas to make configuration, management, development, documentation of OpenStack easier we strive to incorporate those things back into core. None of the above is meant as criticism, it's simply how I categorize OpenStack in the cloudy landscape. Nate On Aug 10, 2012 5:47 PM, Andrew Clay Shafer a...@parvuscaptus.com wrote: What is OpenStack? Clearly, OpenStack is many things to many people and organizations. What does it mean to contribute to OpenStack? What does it mean to deploy OpenStack? What does it mean to operate OpenStack? What do we mean when we say compatible? interoperable? community? branded? Is OpenStack a framework? a project? a product? Recent discussions make it clear that we have a lot of different ideas about all of these things. Our collective and individual responsibilities to each other are also a point of tension. There is a marked difference in the perspective of those developing the projects, those operating the projects as services and the final consumers/clients of those services. If OpenStack is going to live up to it's full potential and stated mission, I believe there needs to be a much stronger collective conscience about how decisions are made. I feel we will all benefit by making some things more explicit. If the expectation is that OpenStack is a framework, which is a word I've heard people use many times, then does an upgrade path have to exist? The OpenStack dashboard was essentially rewritten to upgrade to a new version of Django. Was there any expectation that Django should upgrade itself for us? Upgrading an application to use a different versions of Rails, another framework, often borders on impossible, particularly if the application happens have some feature with a dependency of a gem that hasn't been kept in sync with the upstream project. Is OpenStack more or less complicated than those frameworks? What responsibility should OpenStack core development have to consider existing deployments? Frameworks are expected be a foundation to build on. By definition, changing foundations is not easy. Clearly, OpenStack can be deployed and operated, but if OpenStack needs to be easier to deploy, operate and upgrade, and that is a responsibility of OpenStack itself, that can't be something that get's tacked on at the end. There is no 'ease of deployment' powder to sprinkle on at the end. Distributions and tooling can and do obscure the difficultly for the downstream user, but that also leads to a lot of potential fragmentation. And is that the right answer? Who can and should answer that? That OpenStack should be easy to deploy and upgrade is somewhat at odds with OpenStack supporting every possible combination of hypervisor, storage and networking option, let alone what the expectation should be with closed source customizations/integrations. Which brings up questions of compatibility. API compatibility is potentially misleading if the semantics and behaviors vary. I've heard several service provider discuss ideas about how they can be differentiated in the market, and many of those ideas lead differences in APIs to expose. Is that wrong? Maybe, maybe not, but it certainly makes a lot of work if your core business is dependent on maintaining integrations with service providers. Taken to an extreme these decisions complicate and call into question any future of federated OpenStack services. I'm not advocating any choice here. I just want to point out there are compromises that have to be made. There are goals and desires for OpenStack that are at odds with each other. Some of that is a function of the perspective of persona, but a lot is also from fundamental differences in understanding about where OpenStack is, where OpenStack needs to be, and how to get there. If there isn't a core guiding conscience about what we are trying to accomplish that gets applied across the board, then I worry that the future of OpenStack ends up with more fragments optimizing for their perspective and inevitable
Re: [Openstack] Setting Expectations
On Aug 10, 2012, at 20:49, Nathanael Burton nathanael.i.bur...@gmail.com wrote: I personally equate OpenStack to the Linux Kernel. It's the foundation and core components that, in OpenStack's case, make up an Infrastructure as as Service (IaaS) system, a cloud kernel. We should expect the core components and APIs to be stable with sane deprecation policies, but OpenStack shouldn't do everything for everyone. It should facilitate and provide the stable framework or foundation in which to build production quality, large scale (and small) public and private IaaS systems. In and of itself I believe OpenStack is not an IaaS distribution, ala Linux distributions (Debian, Fedora, RedHat, SuSe, Ubuntu) which take the Linux kernel and build all the user-space and complementary services that make up a manageable, secure, monitored system. An even better example might be Apache. They have their own foundation and have a number of services that get installed to machines, but they don't have a distribution or any clear deployment solutions. Some of their applications such as the httpd are just core pieces that get installed to a single system and multiple services on multiple machines don't communicate, but others are horizontally scaling solutions with inter-process communication, such as Hadoop. Whatever the case, they're still not building a distribution. OpenStack in some ways appears to be the kernel on which applications run, but its applications are just applications. If the question is where the foundation draws the line at acceptance of projects, it is an interesting one... as long as there is a foundation, you can't really use Linux as any sort of example. Instead, if you want to draw parallels to operating systems, you'll have to look more closely to the BSD systems. With BSD, they've coupled the kernels and the distributions. I do not think this is a model that OpenStack should follow, but I do see a tendency of some toward this. Instead, I believe the community and the foundation should move into the direction of Apache. If someone wants to create their own independent distribution, they should, but it shouldn't be part of the project or blessed by the foundation. Instead, they would follow the steps of Slackware, Debian, and Gentoo; not the steps taken by FreeBSD. The community already has a number of emerging proprietary and/or corporate-sponsored distributions, it would not do the community a favor for the foundation to create its own. Regards, Eric Windisch (sent from my iPad)___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Setting Expectations
Openstack is like linux kernel for cloud Anyone welcome to.create distro on it like ubuntu tolinux... and yea ubunti cloud to openstack On Aug 11, 2012 8:46 AM, Eric Windisch e...@cloudscaling.com wrote: On Aug 10, 2012, at 20:49, Nathanael Burton nathanael.i.bur...@gmail.com wrote: I personally equate OpenStack to the Linux Kernel. It's the foundation and core components that, in OpenStack's case, make up an Infrastructure as as Service (IaaS) system, a cloud kernel. We should expect the core components and APIs to be stable with sane deprecation policies, but OpenStack shouldn't do everything for everyone. It should facilitate and provide the stable framework or foundation in which to build production quality, large scale (and small) public and private IaaS systems. In and of itself I believe OpenStack is not an IaaS distribution, ala Linux distributions (Debian, Fedora, RedHat, SuSe, Ubuntu) which take the Linux kernel and build all the user-space and complementary services that make up a manageable, secure, monitored system. An even better example might be Apache. They have their own foundation and have a number of services that get installed to machines, but they don't have a distribution or any clear deployment solutions. Some of their applications such as the httpd are just core pieces that get installed to a single system and multiple services on multiple machines don't communicate, but others are horizontally scaling solutions with inter-process communication, such as Hadoop. Whatever the case, they're still not building a distribution. OpenStack in some ways appears to be the kernel on which applications run, but its applications are just applications. If the question is where the foundation draws the line at acceptance of projects, it is an interesting one... as long as there is a foundation, you can't really use Linux as any sort of example. Instead, if you want to draw parallels to operating systems, you'll have to look more closely to the BSD systems. With BSD, they've coupled the kernels and the distributions. I do not think this is a model that OpenStack should follow, but I do see a tendency of some toward this. Instead, I believe the community and the foundation should move into the direction of Apache. If someone wants to create their own independent distribution, they should, but it shouldn't be part of the project or blessed by the foundation. Instead, they would follow the steps of Slackware, Debian, and Gentoo; not the steps taken by FreeBSD. The community already has a number of emerging proprietary and/or corporate-sponsored distributions, it would not do the community a favor for the foundation to create its own. Regards, Eric Windisch (sent from my iPad) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Setting Expectations
First, thanks to Andrew for starting this thread. I think it's an important discussion. Second, the problem with the analogies made so far is, IMHO, at the API level and what it does to the ecosystem. Let's take, for example, Apache HTTP Client stuff. 3.1 and 4.x are wildly different object models. But that's OK for the Apache model in a way that isn't for OpenStack. When I decided to move Dasein Cloud to the new stuff, it was on my time frame, not Apache's. With OpenStack, the deprecation of APIs is hugely problematic because the ecosystem is live dependent on the APIs. If I roll out a new version into a infrastructure with rich tool support and that version has API inconsistencies, I immediately and irrevocably break critical operational tools. With the Apache stuff, there's no external visibility into the HTTPclient APIs. It's just my code that I can compile and test pre-deployment. It's a problem for any tool with a public facing RESTful API. That's why I believe in never deprecating except in extreme circumstances. The most successful cloud API out there, the EC2 API, never breaks existing tools. NEVER. Seriously, never. -George On Aug 10, 2012, at 9:33 PM, Frans Thamura fr...@meruvian.org wrote: Openstack is like linux kernel for cloud Anyone welcome to.create distro on it like ubuntu tolinux... and yea ubunti cloud to openstack On Aug 11, 2012 8:46 AM, Eric Windisch e...@cloudscaling.com wrote: On Aug 10, 2012, at 20:49, Nathanael Burton nathanael.i.bur...@gmail.com wrote: I personally equate OpenStack to the Linux Kernel. It's the foundation and core components that, in OpenStack's case, make up an Infrastructure as as Service (IaaS) system, a cloud kernel. We should expect the core components and APIs to be stable with sane deprecation policies, but OpenStack shouldn't do everything for everyone. It should facilitate and provide the stable framework or foundation in which to build production quality, large scale (and small) public and private IaaS systems. In and of itself I believe OpenStack is not an IaaS distribution, ala Linux distributions (Debian, Fedora, RedHat, SuSe, Ubuntu) which take the Linux kernel and build all the user-space and complementary services that make up a manageable, secure, monitored system. An even better example might be Apache. They have their own foundation and have a number of services that get installed to machines, but they don't have a distribution or any clear deployment solutions. Some of their applications such as the httpd are just core pieces that get installed to a single system and multiple services on multiple machines don't communicate, but others are horizontally scaling solutions with inter-process communication, such as Hadoop. Whatever the case, they're still not building a distribution. OpenStack in some ways appears to be the kernel on which applications run, but its applications are just applications. If the question is where the foundation draws the line at acceptance of projects, it is an interesting one... as long as there is a foundation, you can't really use Linux as any sort of example. Instead, if you want to draw parallels to operating systems, you'll have to look more closely to the BSD systems. With BSD, they've coupled the kernels and the distributions. I do not think this is a model that OpenStack should follow, but I do see a tendency of some toward this. Instead, I believe the community and the foundation should move into the direction of Apache. If someone wants to create their own independent distribution, they should, but it shouldn't be part of the project or blessed by the foundation. Instead, they would follow the steps of Slackware, Debian, and Gentoo; not the steps taken by FreeBSD. The community already has a number of emerging proprietary and/or corporate-sponsored distributions, it would not do the community a favor for the foundation to create its own. Regards, Eric Windisch (sent from my iPad) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comSkype: nspollutiont: @GeorgeReesep: +1.207.956.0217 enStratus: Enterprise Cloud Management - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net
Re: [Openstack] Setting Expectations
On Friday, August 10, 2012 at 22:53 PM, George Reese wrote: First, thanks to Andrew for starting this thread. I think it's an important discussion. Second, the problem with the analogies made so far is, IMHO, at the API level and what it does to the ecosystem. Let's take, for example, Apache HTTP Client stuff. 3.1 and 4.x are wildly different object models. But that's OK for the Apache model in a way that isn't for OpenStack. Aren't you making the wrong comparison here? This might apply to the OS API client libraries, or euca2ools (which is NOT an OpenStack project), but this comparison does not apply to the OpenStack services or EC2 endpoint compatibility. Instead, the comparison of EC2 endpoint compatibility should be made to Apache's HTTP endpoint, their httpd. A better question is: Has the Apache httpd broken HTTP compatibility in any significant way? Besides, perhaps, from allowing you to configure it in a broken manner? In fact, this might be a good comparison, because Apache's httpd doesn't HAVE to be deployed in a standards-compliant way, although tools (i.e. browsers) and operators have figured out how to make this work, and to a large degree, people are able to successfully load webpages served by the Apache httpd. In a similar way, OpenStack Nova installations may vary greatly in their behavior. They don't HAVE to be deployed in a standards-complaint way (whatever that means); Yet, hopefully, people will be able to successfully launch instances served by OpenStack Nova with a common set of tools. I'm often advocating compatible clouds over advanced client API wrappers (such as Dasein), but the reality is that it needs to happen on both ends. The cloud server software needs to enable a compatible and standards-compliant service endpoint, enforced or not… and the client API libraries need to be flexible enough to handle a variety of services that might not be 100% identical. Just like the HTTP servers and client libraries that we have today. Regards, Eric Windisch ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
