Re: [openstack-dev] [tc][elections]questions about one platform vision

[Adam Lawson]

I appreciate the remarks.

I think we are perhaps looking at early data and discussing two separate
things: events versus trends. While I do not doubt K8S has been deployed on
OpenStack, I'm looking at how folks are planning to use those two
platforms. Is it possible to host one in another, absolutely. Is that
supportable at scale or discussed as a serious possibility. Rarely. Where I
believe things are going based on conversations and numerous roadmap
strategy sessions. literally no one I'm talking to talks about the combo as
making sense from a scale perspective whether it be too-big-to-fail banks,
network companies or SaaS companies. Again, this is my perception based on
the folks I'm taking to. That's not where I see the market shifting. And
that's certainly not what I see enterprises doing or planning to go.

On my end I'm seeing many in the OpenStack community falling into a
different trap - believing nothing needs to change to accommodate a
significant new element in the market or to plan a vision for the project
with a misunderstanding of it's place in the FOSS marketplace. The two
platforms do in fact compete as I see things as they are today - and with
increasing interest in orchestrating VM's with K8S, that competition will
likely become more distinct and OpenStack will face a very new
potentiality: OpenStack being considered versus something else. OpenStack
has been IT and the idea of a viable alternate hasn't happened for at least
5 years and I see K8S as a real potential challenger.

But again, everything may change next week and we'll all be wrong. ; )


*Adam Lawson*

Principal Architect
Office: +1-916-794-5706

On Wed, Apr 19, 2017 at 5:14 AM, Flavio Percoco  wrote:

> On 19/04/17 11:17 +0200, Thierry Carrez wrote:
>
>> Adam Lawson wrote:
>>
>>> [...]
>>> I've been an OpenStack architect for at least 5+ years now and work with
>>> many large Fortune 100 IT shops. OpenStack in the enterprise is being
>>> used to orchestrate virtual machines. Despite the additional
>>> capabilities OpenStack is trying to accommodate, that's basically it. At
>>> scale, that's what they're doing. Not many are orchestrating bare metal
>>> that I've seen or heard. And they are exploring K8s and Docker Swarm to
>>> orchestrate containers. They aren't looking at OpenStack to do that.
>>>
>>
>> I have to disagree. We have evidence that some of the largest Kubernetes
>> deployments in the world happen on top of an OpenStack infrastructure,
>> and hopefully some of those will talk about it in Boston.
>>
>> I feel like you fall in the common trap of thinking that both
>> technologies are competing, while one is designed for infrastructure
>> providers and the other for application deployers. Sure, you can be a
>> Kubernetes-only shop if you're small enough or have Google-like
>> discipline (and a lot of those shops, unsurprisingly, were present in
>> Berlin), but most companies have to offer a wider array of
>> infrastructure services for their developers. That's where OpenStack, an
>> open infrastructure stack, comes in. Giving the infrastructure provider
>> a framework to offer multiple options to application developers and
>> operators.
>>
>
>
> Yes, this, a gazillion of times. I do _NOT_ think CNCF and OpenStack are
> (or
> need to be) in competition and I'd rather explore the different ways we can
> combine these 2 communities or, more specifically, some of the
> technologies that
> are part of these communities.
>
> To do this, we need to explore ways to make OpenStack more "flexible" so
> that we
> can allow different combinations of OpenStack, we need to allow people to
> use it
> more like a framework.
>
> I definitely don't mean it's the only thing and I'm really against calling
> almost anything "the one thing" (unless we're talking about pasta or
> pizza) and
> I believe falling into that trap would damage the community (we barely
> made it
> out in our early years/days).
>
>
> Flavio
>
> --
> @flaper87
> Flavio Percoco
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][elections]questions about one platform vision

[Flavio Percoco]

On 19/04/17 11:17 +0200, Thierry Carrez wrote:

Adam Lawson wrote:

[...]
I've been an OpenStack architect for at least 5+ years now and work with
many large Fortune 100 IT shops. OpenStack in the enterprise is being
used to orchestrate virtual machines. Despite the additional
capabilities OpenStack is trying to accommodate, that's basically it. At
scale, that's what they're doing. Not many are orchestrating bare metal
that I've seen or heard. And they are exploring K8s and Docker Swarm to
orchestrate containers. They aren't looking at OpenStack to do that.


I have to disagree. We have evidence that some of the largest Kubernetes
deployments in the world happen on top of an OpenStack infrastructure,
and hopefully some of those will talk about it in Boston.

I feel like you fall in the common trap of thinking that both
technologies are competing, while one is designed for infrastructure
providers and the other for application deployers. Sure, you can be a
Kubernetes-only shop if you're small enough or have Google-like
discipline (and a lot of those shops, unsurprisingly, were present in
Berlin), but most companies have to offer a wider array of
infrastructure services for their developers. That's where OpenStack, an
open infrastructure stack, comes in. Giving the infrastructure provider
a framework to offer multiple options to application developers and
operators.



Yes, this, a gazillion of times. I do _NOT_ think CNCF and OpenStack are (or
need to be) in competition and I'd rather explore the different ways we can
combine these 2 communities or, more specifically, some of the technologies that
are part of these communities.

To do this, we need to explore ways to make OpenStack more "flexible" so that we
can allow different combinations of OpenStack, we need to allow people to use it
more like a framework.

I definitely don't mean it's the only thing and I'm really against calling
almost anything "the one thing" (unless we're talking about pasta or pizza) and
I believe falling into that trap would damage the community (we barely made it
out in our early years/days).

Flavio

--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][elections]questions about one platform vision

[Thierry Carrez]

Adam Lawson wrote:
> [...]
> I've been an OpenStack architect for at least 5+ years now and work with
> many large Fortune 100 IT shops. OpenStack in the enterprise is being
> used to orchestrate virtual machines. Despite the additional
> capabilities OpenStack is trying to accommodate, that's basically it. At
> scale, that's what they're doing. Not many are orchestrating bare metal
> that I've seen or heard. And they are exploring K8s and Docker Swarm to
> orchestrate containers. They aren't looking at OpenStack to do that.

I have to disagree. We have evidence that some of the largest Kubernetes
deployments in the world happen on top of an OpenStack infrastructure,
and hopefully some of those will talk about it in Boston.

I feel like you fall in the common trap of thinking that both
technologies are competing, while one is designed for infrastructure
providers and the other for application deployers. Sure, you can be a
Kubernetes-only shop if you're small enough or have Google-like
discipline (and a lot of those shops, unsurprisingly, were present in
Berlin), but most companies have to offer a wider array of
infrastructure services for their developers. That's where OpenStack, an
open infrastructure stack, comes in. Giving the infrastructure provider
a framework to offer multiple options to application developers and
operators.

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][elections]questions about one platform vision

[Zane Bitter]

On 18/04/17 10:39, Flavio Percoco wrote:

On 16/04/17 09:03 +0100, Neil Jerram wrote:

FWIW, I think the Lego analogy is not actually helpful for another
reason: it has vastly too many ways of combining, and (hence) no sense
at all of consistency / interoperability between the different things
that you can construct with it. Whereas for OpenStack I believe you
are also aiming for some forms of consistency and interoperability.


I agree that this is another important limitation of the analogy.


Could you expand on why you think the lego analogy does not cover
consistency
and interoperability?


This is one of the interesting ways in which building an application 
with multiple independently-governed deployments (like OpenStack) 
differs from building a hosted service (like AWS).


So if you look at https://aws.amazon.com/products/ there is currently 
somewhere north of 90 services listed. Despite this, literally nobody 
ever says things like "Wow, that's so many services... do I have to use 
all of them?" Because it's obvious: as an application 
developer/deployer, you use the ones you need, you don't use the ones 
you don't, and there's no problem. (People, of course, *do* say things 
like "Wow, that's so many services, how do I find the one I need?" or 
"What does all this stuff do?" or "What do all these silly names mean?")


Now with OpenStack, operators look at 
https://www.openstack.org/software/project-navigator and say "Wow, 
that's so many services... do I have to use all of them?" And for the 
most part the answer ought to be equally obvious: install the ones that 
application developers deploying to your cloud need, and not the ones 
they don't. (Strangely, though, we don't often talk about application 
developer needs... OpenStack is largely marketed to operators of clouds, 
with the apparent assumption that application developers will use 
whatever they're given. IMHO this is a colossal mistake - it's the exact 
mechanism by which a lot of really *very* bad 'Enterprise' software has 
gotten developed over the years.)


However, there's a subtlety to it: with a single hosted service, all the 
stuff is already there, and if you want to start using it you just 
start. With multiple deployments, the thing you want may or may not be 
there, or it may be there on only some of the clouds you want to use, or 
it may not even get properly integrated at all.


So, for example, AWS services can all deliver notifications to SNS 
topics that application developers can reliably use to e.g. trigger 
Lambda functions when some event occurs. If you don't need that you 
don't use them, but when you do they'll be right there. (Azure and 
Google also have equivalent functionality.)


OpenStack has equivalents to SNS & Lambda for these purposes (Zaqar & 
Mistral), but they're not installed in most clouds. If you find you need 
them then you have to beg your cloud operator. Even if that works, 
you'll lose interoperability with most other OpenStack clouds by 
depending on them. And in any event, hardly any OpenStack services 
actually produce notifications for Zaqar anyway because most people 
assume that it's just a layered service that only a small class of 
applications might use, and not something that ought to be an integral 
part of any cloud.


Meanwhile in unrelated news, it's 2017 and Horizon still works by 
polling all of the things all of the time.


There certainly exists a bunch of stuff that you can just layer on - 
e.g. if you need Hadoop as a service you should probably install Sahara, 
and if you don't then it won't hurt at all if you don't. But the set of 
stuff that needs to be tightly integrated together and present in most 
deployments to yield an interoperable cloud service is considerably 
larger than just what you need to run a VPS, which is all that we've 
really acknowledged since the start of the 'big tent' debate.


If we treat _everything_ as just an independent building block on top of 
the core VPS functionality then we'll never develop the integrated core 
*cloud* functionality that we need to attract application developers to 
the platform by choice (and hopefully convert them into contributors!).


cheers,
Zane.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][elections]questions about one platform vision

[Doug Hellmann]

Excerpts from Adam Lawson's message of 2017-04-18 10:33:32 -0700:
> My personal feeling:
> 
> We need to be very very careful. While I really respect Jay Pipes and his
> commentary, I fundamentally disagree with his toolbox mindset. OpenStack is
> one tool in the Enterprise toolbox. It isn't a toolbox. K8s is another tool
> in the toolbox since it's turning out to be much more than just a container
> management platform. Believe it or not AWS is another.
> 
> I've been an OpenStack architect for at least 5+ years now and work with
> many large Fortune 100 IT shops. OpenStack in the enterprise is being used
> to orchestrate virtual machines. Despite the additional capabilities
> OpenStack is trying to accommodate, that's basically it. At scale, that's
> what they're doing. Not many are orchestrating bare metal that I've seen or
> heard. And they are exploring K8s and Docker Swarm to orchestrate
> containers. They aren't looking at OpenStack to do that. I recently
> attended the K8s conference in Berlin this year and I'll tell you, the
> container community is not looking at OpenStack as the means to manage
> containers. If they are, they were likely sitting at the OpenStack booth.
> Additionally these enterprises are not going to use two platforms side by
> side with two means of orchestrating resources. That's both unrealistic and
> understandable. Shoe-horning K8s into an OpenStack model really underserves
> the container user space.
> 
> OpenStack's approach is to treat K8s as a tool.
> K8s is working to classify OpenStack as a tool.
> 
> So to me we're one of two - maybe one of three solid FOSS cloud platforms -
> not including Azure and AWS which are both trending up in consumer adoption
> again. All of these are aiming to orchestrate the same resources and in
> different ways, they each do it very well. A One Platform vision coming
> from the minds within one of those projects creates unnecessary friction
> and sounds a little small-minded. Big world out there - we're not the only
> player.

I won't speak for anyone else, but when I say that OpenStack should
be "one thing" I definitely don't mean "the only thing." What I
mean is that someone selecting several OpenStack components to use
to build their stack should have those components behave in similar
ways, and use similar deployment and end-user patterns so that once
someone figures out one component the next is easier to figure out.
It would be great if those components were able to integrate directly
with other tools not produced by the community (serving volumes to
containers with Cinder or authenticating non-OpenStack apps with
Keystone, for example), but that's secondary to the components
produced by our community actually working together, in my mind.

Doug

> 
> In the end I guess I'm trying to say that we need to be careful when we
> make assertions because this vision sounds like we're drinking too much of
> our own Kool-Aid. When we assume our platform orchestrates the heap, we
> need to understand there are several other heaps getting bigger and do
> things OpenStack can't. If we buy into a marketing vision, we start a
> downward path towards where Eucalyptus and CloudStack are today.
> 
> Just my oh, 3 cents worth. ; )
> 
> //adam
> 
> 
> *Adam Lawson*
> 
> Principal Architect
> Office: +1-916-794-5706 <(916)%20794-5706>
> 
> On Tue, Apr 18, 2017 at 7:39 AM, Flavio Percoco  wrote:
> 
> > On 16/04/17 09:03 +0100, Neil Jerram wrote:
> >
> >> FWIW, I think the Lego analogy is not actually helpful for another
> >> reason: it has vastly too many ways of combining, and (hence) no sense at
> >> all of consistency / interoperability between the different things that you
> >> can construct with it. Whereas for OpenStack I believe you are also aiming
> >> for some forms of consistency and interoperability.
> >>
> >
> > Could you expand on why you think the lego analogy does not cover
> > consistency
> > and interoperability?
> >
> >
> > Flavio
> >
> > --
> > @flaper87
> > Flavio Percoco
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][elections]questions about one platform vision

[Adam Lawson]

My personal feeling:

We need to be very very careful. While I really respect Jay Pipes and his
commentary, I fundamentally disagree with his toolbox mindset. OpenStack is
one tool in the Enterprise toolbox. It isn't a toolbox. K8s is another tool
in the toolbox since it's turning out to be much more than just a container
management platform. Believe it or not AWS is another.

I've been an OpenStack architect for at least 5+ years now and work with
many large Fortune 100 IT shops. OpenStack in the enterprise is being used
to orchestrate virtual machines. Despite the additional capabilities
OpenStack is trying to accommodate, that's basically it. At scale, that's
what they're doing. Not many are orchestrating bare metal that I've seen or
heard. And they are exploring K8s and Docker Swarm to orchestrate
containers. They aren't looking at OpenStack to do that. I recently
attended the K8s conference in Berlin this year and I'll tell you, the
container community is not looking at OpenStack as the means to manage
containers. If they are, they were likely sitting at the OpenStack booth.
Additionally these enterprises are not going to use two platforms side by
side with two means of orchestrating resources. That's both unrealistic and
understandable. Shoe-horning K8s into an OpenStack model really underserves
the container user space.

OpenStack's approach is to treat K8s as a tool.
K8s is working to classify OpenStack as a tool.

So to me we're one of two - maybe one of three solid FOSS cloud platforms -
not including Azure and AWS which are both trending up in consumer adoption
again. All of these are aiming to orchestrate the same resources and in
different ways, they each do it very well. A One Platform vision coming
from the minds within one of those projects creates unnecessary friction
and sounds a little small-minded. Big world out there - we're not the only
player.

In the end I guess I'm trying to say that we need to be careful when we
make assertions because this vision sounds like we're drinking too much of
our own Kool-Aid. When we assume our platform orchestrates the heap, we
need to understand there are several other heaps getting bigger and do
things OpenStack can't. If we buy into a marketing vision, we start a
downward path towards where Eucalyptus and CloudStack are today.

Just my oh, 3 cents worth. ; )

//adam


*Adam Lawson*

Principal Architect
Office: +1-916-794-5706 <(916)%20794-5706>

On Tue, Apr 18, 2017 at 7:39 AM, Flavio Percoco  wrote:

> On 16/04/17 09:03 +0100, Neil Jerram wrote:
>
>> FWIW, I think the Lego analogy is not actually helpful for another
>> reason: it has vastly too many ways of combining, and (hence) no sense at
>> all of consistency / interoperability between the different things that you
>> can construct with it. Whereas for OpenStack I believe you are also aiming
>> for some forms of consistency and interoperability.
>>
>
> Could you expand on why you think the lego analogy does not cover
> consistency
> and interoperability?
>
>
> Flavio
>
> --
> @flaper87
> Flavio Percoco
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][elections]questions about one platform vision

[Neil Jerram]

On Tue, Apr 18, 2017 at 3:45 PM Flavio Percoco  wrote:

> On 16/04/17 09:03 +0100, Neil Jerram wrote:
> >FWIW, I think the Lego analogy is not actually helpful for another
> reason: it has vastly too many ways of combining, and (hence) no sense at
> all of consistency / interoperability between the different things that you
> can construct with it. Whereas for OpenStack I believe you are also aiming
> for some forms of consistency and interoperability.
>
> Could you expand on why you think the lego analogy does not cover
> consistency
> and interoperability?
>

Well, for example, because you can build either a house or a jellyfish out
of Lego, and I don't think there's anything about the relationship between
those two things that evokes the consistency that some folks are talking
about / looking for between OpenStack components.

Neil
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][elections]questions about one platform vision

[Flavio Percoco]

On 16/04/17 09:03 +0100, Neil Jerram wrote:

FWIW, I think the Lego analogy is not actually helpful for another reason: it 
has vastly too many ways of combining, and (hence) no sense at all of 
consistency / interoperability between the different things that you can 
construct with it. Whereas for OpenStack I believe you are also aiming for some 
forms of consistency and interoperability. 


Could you expand on why you think the lego analogy does not cover consistency
and interoperability?

Flavio

--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][elections]questions about one platform vision

[Ildiko Vancsa]

> On 2017. Apr 16., at 3:03, Neil Jerram  wrote:
> 
> FWIW, I think the Lego analogy is not actually helpful for another reason: it 
> has vastly too many ways of combining, and (hence) no sense at all of 
> consistency / interoperability between the different things that you can 
> construct with it. Whereas for OpenStack I believe you are also aiming for 
> some forms of consistency and interoperability. 

I see your point here and without being too biased by the Lego analogy I don’t 
fully agree.

On one hand, in my view we can go deep and associate to the new style Legos 
where you can build more realistic things and you have more specific pieces and 
not just the plain colored rectangular ones and can explore all the ways of 
putting them together, but I don’t think we want to do that when we are looking 
for some kind of an analogy to help people digest a new concept. We will not 
find anything that will be perfect, I think we only need a good enough one let 
that be Legos or something else.

On the other hand despite of the many ways to combine the Lego blocks you will 
still find matching things, like the ability of attaching the Lego figures for 
instance. In this sense I think we need to find the right level of 
consistency/interoperability here. Like for instance the characteristics and 
requirements of an HPC and a Telecom cloud are different and I don’t think 
there are many use cases to ever connect these two types of clouds or migrate 
workload between them, but there’s still a subset of functionality that both 
areas expect from their OpenStack based cloud, which are really the basics and 
not every small detail.

What the Lego analogy describes well is the consistency between the building 
blocks, which is a really important message in my opinion.

With that being said, if we can find a better one or decide not to use any 
analogies that also works for me. I don't think we should spend overly too much 
time with this, although if we can find a good enough one, I’m in favor to use 
it as it sometimes makes it much easier to get to know and accept a new(-ish) 
concept.

Thanks,
Ildikó


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][elections]questions about one platform vision

[Neil Jerram]

FWIW, I think the Lego analogy is not actually helpful for another reason: it 
has vastly too many ways of combining, and (hence) no sense at all of 
consistency / interoperability between the different things that you can 
construct with it. Whereas for OpenStack I believe you are also aiming for some 
forms of consistency and interoperability. 


  Original Message  
From: Thierry Carrez
Sent: Friday, 14 April 2017 09:34

[...]
I like the Lego analogy. While it is, in the end, a bunch of building
blocks of various shape and function, we don't describe Lego as a
"collection of blocks". We describe it as "the Lego system" (one
platform) that lets you build stacks in various ways. What makes the
value of the platform is the common experience of operating the blocks,
and the fact that Lego stacks built by someone else are interoperable
with your stacks.

Like all analogies, this one is not perfect (in particular it horribly
fails to capture the "open" nature of the stack), but I think it's still
useful to inform on what OpenStack is.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][elections]questions about one platform vision

[Dean Troyer]

On Fri, Apr 14, 2017 at 9:50 AM, Dean Troyer  wrote:
> [0] https://www.openstack.org/legal/bylaws-of-the-openstack-foundation/
> [1] 
> https://governance.openstack.org/tc/reference/principles.html#one-openstack

Rats, I missed the UC charter:

[2] https://governance.openstack.org/uc/reference/charter.html

dt

-- 

Dean Troyer
dtro...@gmail.com

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][elections]questions about one platform vision

[Dean Troyer]

On Fri, Apr 14, 2017 at 3:34 AM, Thierry Carrez  wrote:
> Like all analogies, this one is not perfect (in particular it horribly
> fails to capture the "open" nature of the stack), but I think it's still
> useful to inform on what OpenStack is.

On the other hand I do think it captures the common feeling of
stepping on them in the dark barefoot...

I think the fact that this question comes up over and over, almost
like clockwork, is a clear signal that we (the community overall)
still do not have a shared understanding of the answer, or some just
don't like the stated answer and their change process is repeating the
question hoping the answer changes.

We've used the term 'cloud operating system' in various places, but
not in our defining documents:

* The Bylaws[0] use the phrase "the open source cloud computing
project which is known as the OpenStack Project"
* The TC charter[1] uses the phrase "one community with one common
mission, producing one framework of collaborating components"
* The UC charter [2] does not include a statement on "what is OpenStack"

I've never liked the "cloud operating system" term because I felt it
mis-represented how we defined ourself, but I've come to realize it
may be the easiest-to-understand metaphor yet for what we are and
where we are today.  Going forward it is increasingly apparent that
hybrid stacks (constellations, etc) will be common that include
significant components that are not OpenStack at layers other than
"layer 0" (ie, below all OpenStack components: database, message
queue, etc).  The example commonly given is of course Kubernetes, but
there are others.

UNIX caught on as well as it did partly because of its well-defined
interfaces between components at user-visible levels, specifically in
userspace.  The 'everything is a file' metaphor, for all its faults,
was simple to understand and use, until it wasn't.  But to still
serves us well.  There was a LOT of 'differentiation' between the
eventual commercial implementations of UNIX which caused a lot of pain
for many (including me) but the masses have settled on the
highly-interoperable GNU/Linux combination. (I am conveniently
ignoring the still-present 'differentiation' that Linux distros insist
on because that will never go away).

[Thank you for reading this far, I didn't intend for this to be so
verbose, but airport terminals can be quite boring at times :) ]

This is where I see OpenStack today.  We are in the role of being the
cloud for the masses, used by both large (hi CERN!) and small (hi
mtrienish's closet!) clouds and largely interoperable.  Just as an OS
(operating system)is the enabling glue for applications to function
and communicate, our OS (OpenStack) is in position to do that for
cloud apps.  What we are lacking for guidance is a direct lineage to
20 years of history.  We have to have our own discipline to keep our
interfaces clean and easy to consume and understand, and present a
common foundation for applications to build on, including applications
that are themselves higher layers of an OS stack.

Phew!  Thank you again for reading this far, I know this is not news
to a lot of our community, but the assumption that "everyone knows
this" is not true, we need to occasionally repeat ourselves to remind
ourselves and inform our newer members what we are, where we are
headed and why we are all here in the first place: to enable awesome
work to build on our foundation, and if we sell a few boxes or service
contracts or chips along the way, our sponsors are happy too.

dt

[0] https://www.openstack.org/legal/bylaws-of-the-openstack-foundation/
[1] https://governance.openstack.org/tc/reference/principles.html#one-openstack

-- 

Dean Troyer
dtro...@gmail.com

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][elections]questions about one platform vision

[Thierry Carrez]

Ildiko Vancsa wrote:
>> […]
>> What's the one platform will be in your own words? What's your
>> proposal and your focus to help one platform vision being achieved?
> 
> In my view it means that OpenStack contains the blocks to build
> platforms that can serve as a base for different use cases and
> workloads. We need to keep the API’s consistent and the interfaces
> between the services well defined and stable.
> 
> In addition, for me, one platform on high level means enablement,
> flexibility, consciousness about the needs of the industry and support
> of the integration points towards related projects/technologies. We need
> OpenStack to be modular with clear communication about the purpose of
> each service and guidance on how to build a platform by using them as
> Lego pieces, like how you have sample photos on the side of the box to
> give you ideas on what you might want.
> 
> I think if we can achieve people seeing OpenStack as a box of Lego,
> tools, you name it, that enables them to build what they need as a base
> platform to run their applications on top we are on the right track.
> This needs good design, consistency and clear communication.

I like the Lego analogy. While it is, in the end, a bunch of building
blocks of various shape and function, we don't describe Lego as a
"collection of blocks". We describe it as "the Lego system" (one
platform) that lets you build stacks in various ways. What makes the
value of the platform is the common experience of operating the blocks,
and the fact that Lego stacks built by someone else are interoperable
with your stacks.

Like all analogies, this one is not perfect (in particular it horribly
fails to capture the "open" nature of the stack), but I think it's still
useful to inform on what OpenStack is.

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][elections]questions about one platform vision

[Ildiko Vancsa]

> +1 for us to publish sets of projects that work together for specific
> scenarios. I heard this idea first from Allison Randall and it
> immediately struck a chord. To be fair folks like Jay Pipes have
> always said (paraphrasing) "OpenStack is a toolbox". So it's the next
> step i guess. Lauren Sell was mentioning yesterday about hearing
> confusion around "Big Tent", i do feel that when we put forth a set of
> constellations we can start deprecating the "Big Tent" terminology if
> appropriate.

I think what we are missing here is more of guidelines and more examples to 
give ideas how to build a platform from the blocks. I see “Big Tent” as a 
terminology that covers our governance as well, therefore I would not go that 
far to deprecate it as of now.

On the other hand, I know at least one other community where a very similar 
concept than the set of constellations here is causing just as much frustration 
as the “Big Tent” currently in our case. I think we need to improve on 
communication and guidance first regardless of whether we get to the conclusion 
of changing the terminology finally or not.

Thanks,
Ildikó


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][elections]questions about one platform vision

[Ildiko Vancsa]

> […]
> What's the one platform will be in your own words? What's your proposal and 
> your focus to help one platform vision being achieved?

In my view it means that OpenStack contains the blocks to build platforms that 
can serve as a base for different use cases and workloads. We need to keep the 
API’s consistent and the interfaces between the services well defined and 
stable.

In addition, for me, one platform on high level means enablement, flexibility, 
consciousness about the needs of the industry and support of the integration 
points towards related projects/technologies. We need OpenStack to be modular 
with clear communication about the purpose of each service and guidance on how 
to build a platform by using them as Lego pieces, like how you have sample 
photos on the side of the box to give you ideas on what you might want.

I think if we can achieve people seeing OpenStack as a box of Lego, tools, you 
name it, that enables them to build what they need as a base platform to run 
their applications on top we are on the right track. This needs good design, 
consistency and clear communication.

Thanks,
Ildikó


> 
> Best Regards
> Chaoyi Huang (joehuang)
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org 
> ?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][elections]questions about one platform vision

[Ed Leafe]

On Apr 11, 2017, at 9:54 PM, joehuang  wrote:

> Can all these efforts lead us to one platform vision? We have to think over 
> the question.
> 
> What's the one platform will be in your own words? What's your proposal and 
> your focus to help one platform vision being achieved?

I think the word "platform" is critical here. OpenStack is not a single "thing" 
that everyone can use the same way. It's a collection of pieces that work 
together to help solve many different workloads. The key to that is having a 
solid base and consistent interfaces among the various projects to create a 
platform that solutions can be built upon.


-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][elections]questions about one platform vision

[Doug Hellmann]

Excerpts from joehuang's message of 2017-04-13 00:47:53 +:
>  Interesting to know the idea considering OpenStack as group of 
> constellations. Does it mean even
> Nova/Cinder/Neutron are not necessary to be tied together in some user cases?

To me, the important aspect of calling OpenStack "one thing"
(platform, product, toolbox, whatever) has always been that when
used together the components appear cohesive. They have similar
APIs, similar deployment patterns, etc. There are obviously going
to be some underlying differences because a block storage service
is not a VM manager -- they provide different features and need
different inputs.  But the differences should not be surprising or
arbitrary (returning different payloads from the "version" API, to
take an example from another recent thread). It should look like
the teams producing the different components like each other and
get together in person regularly to collaborate.

If we have that, then it doesn't matter so much whether every
deployer installs every single component, or only the ones they
need for their use cases.

Doug

> 
> Seems that "one platform" has not been got consensus yet. But the marketing 
> material of
> OpenStack is claiming "one platform" [1][2]
> 
> [1] 
> https://www.openstack.org/assets/marketing/OpenStack-101-Modular-Deck-1.pptx
> [2] OpenStack 101,  https://www.openstack.org/marketing/#tab=collateral
> 
> Best Regards
> Chaoyi Huang (joehuang)
> 
> 
> From: John Garbutt [j...@johngarbutt.com]
> Sent: 12 April 2017 18:51
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [tc][elections]questions about one platform  
>   vision
> 
> On 12 April 2017 at 03:54, joehuang <joehu...@huawei.com> wrote:
> > What's the one platform will be in your own words? What's your proposal and
> > your focus to help one platform vision being achieved?
> 
> The more I think about this, the less I like the phrase "one platform".
> 
> I like to think of OpenStack as group of constellations. Those
> constellations are groups of projects that are built to be used
> together around a shared set of use cases and users. Note that many
> (all?) of those constellations involve open source projects that were
> born and live outside of OpenStack.
> 
> I am trying to kick start the "VM and baremetal" working group to get
> feedback on a specific constellation as a group of projects. Here I am
> thinking about running Nova, Cinder, Neutron, Keystone, etc to give
> you (in some sense) a Software Defined Data Center. Many applications
> and services need to consume and integrate with that platform, like
> Heat, Trove and Magnum, to can get access to the compute, networking
> and storage they need to execute their workloads, such as containers.
> Its like the next generation of consolidation to get to the next level
> of utilization/efficiency. If you look at this constellation the
> database and message queue are important non-OpenStack components of
> the constellation. Maybe this is a false constellation, and there is a
> different set of things that people use together. Thats some of the
> feedback I hope we get at the forum.
> 
> The work ttx mentions is important. I hope the project maps will help
> communicate how users can meet their needs by running various
> combinations of OpenStack and non-OpenStack projects together.
> 
> To be clear, I am not claiming to have the answers here, this is just
> my current thinking. I look forward to all the debate and discussions
> around this topic, and all the interesting things I will learn about
> along that journey, things that will likely make me change my mind.
> 
> Thanks,
> johnthetubaguy
> 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][elections]questions about one platform vision

[Flavio Percoco]

On 12/04/17 02:54 +, joehuang wrote:

Hello,

I heard the one platform vision in OpenStack now and then: One platform for 
virtual machines, containers and bare metal.

I also learned that there are some groups working on making Kubernets being 
able to manage virtual machines. Except running containers in virtual machine, 
there is also the need for running containers in bare metal.

There are several projects connecting OpenStack to container world: Zun, 
Magnum, Kuryr, Fuxi... Projects to deal with bare metal like Ironic, Morgan, ...

Can all these efforts lead us to one platform vision? We have to think over the 
question.

What's the one platform will be in your own words? What's your proposal and 
your focus to help one platform vision being achieved?




TBH, I think the answer here is a combination of some of the answers from other
folks in this thread. I've always liked to think of OpenStack as one platform in
the sense that it's set of teams (or projects even) working towards providing a
solution for clouds. I also like to think about these set of projects as an
independent, combinable, group of tools that constitue the one platform.

The key here is that I don't like to think about OpenStack as a massive project
that is all or nothing. This has been one of my most common discussions ever
since I started working on OpenStack. It's also one thing I loved about Glance
and that drove some of the decisions when we created Zaqar.

We naming we'll use will help representing what OpenStack is with the fewer
words possible (one platform, constellations, maps, sets, etc). What really
matters in the end are the properties of these projects and how they will
interact with each other. This is what makes this question critical and
difficult to answer (so thanks :).

Providing a set of combinations, maps/constallations is a good excersice. It
helps consumers to picture OpenStack and understand its capabilities better. In
the end, however, I'd prefer the users to create their own constellations/groups
based on what they need.

Flavio

--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][elections]questions about one platform vision

[joehuang]

 Interesting to know the idea considering OpenStack as group of constellations. 
Does it mean even
Nova/Cinder/Neutron are not necessary to be tied together in some user cases?

Seems that "one platform" has not been got consensus yet. But the marketing 
material of
OpenStack is claiming "one platform" [1][2]

[1] https://www.openstack.org/assets/marketing/OpenStack-101-Modular-Deck-1.pptx
[2] OpenStack 101,  https://www.openstack.org/marketing/#tab=collateral

Best Regards
Chaoyi Huang (joehuang)


From: John Garbutt [j...@johngarbutt.com]
Sent: 12 April 2017 18:51
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tc][elections]questions about one platform
vision

On 12 April 2017 at 03:54, joehuang <joehu...@huawei.com> wrote:
> What's the one platform will be in your own words? What's your proposal and
> your focus to help one platform vision being achieved?

The more I think about this, the less I like the phrase "one platform".

I like to think of OpenStack as group of constellations. Those
constellations are groups of projects that are built to be used
together around a shared set of use cases and users. Note that many
(all?) of those constellations involve open source projects that were
born and live outside of OpenStack.

I am trying to kick start the "VM and baremetal" working group to get
feedback on a specific constellation as a group of projects. Here I am
thinking about running Nova, Cinder, Neutron, Keystone, etc to give
you (in some sense) a Software Defined Data Center. Many applications
and services need to consume and integrate with that platform, like
Heat, Trove and Magnum, to can get access to the compute, networking
and storage they need to execute their workloads, such as containers.
Its like the next generation of consolidation to get to the next level
of utilization/efficiency. If you look at this constellation the
database and message queue are important non-OpenStack components of
the constellation. Maybe this is a false constellation, and there is a
different set of things that people use together. Thats some of the
feedback I hope we get at the forum.

The work ttx mentions is important. I hope the project maps will help
communicate how users can meet their needs by running various
combinations of OpenStack and non-OpenStack projects together.

To be clear, I am not claiming to have the answers here, this is just
my current thinking. I look forward to all the debate and discussions
around this topic, and all the interesting things I will learn about
along that journey, things that will likely make me change my mind.

Thanks,
johnthetubaguy

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][elections]questions about one platform vision

[German Eichberger]

Hi,

Though I haven’t attended the operator summit in person a them which has been 
mentioned to me is that we need to offer better reference architectures. I use 
the plural here on purpose because I don’t think there will be one 
architecture/combination of projects which works for everybody. As a community 
(and the TC can help) we should write up guides for reference architectures for 
containers, vms, and bare metal. But we  don’t need to offer just one project – 
there are a couple of ways to get there and we should offer choice. But we owe 
it to the operators that we have tested whatever we write up at some scale.

The second meaning for a “one platform” vision would be a unified API for 
Containers, VMs, and bare metal. I have talked to several people who would like 
to write software which doesn’t need to distinguish between different APIs to 
accomplish that. But I still feel that we should adhere to the Unix philosophy 
and make the best API for each technology and then have the orchestration 
platform or higher level abstractions (e.g. cloud native) worry about it.

This leads me to one of my gripes with the way we work. We sort of accepted 
that it is the projects responsibility to write tests and documentation but 
when it comes who is writing the Heat integration, the Open Stack Ansible part, 
or the Gophercloud part – things get real murky. I don’t iike to add another 
burden to some of the small projects but we also need to figure out a way that 
those things are current and compete. I am hoping that having reference 
architectures can guide us in this regard and I think we need to add more 
visibility what those solution supports and where the gaps are.

Thanks,
German


From: joehuang <joehu...@huawei.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Tuesday, April 11, 2017 at 10:54 PM
To: openstack-dev <openstack-dev@lists.openstack.org>
Subject: [openstack-dev] [tc][elections]questions about one platform vision

Hello,

I heard the one platform vision in OpenStack now and then: One platform for 
virtual machines, containers and bare metal.

I also learned that there are some groups working on making Kubernets being 
able to manage virtual machines. Except running containers in virtual machine, 
there is also the need for running containers in bare metal.

There are several projects connecting OpenStack to container world: Zun, 
Magnum, Kuryr, Fuxi... Projects to deal with bare metal like Ironic, Morgan, ...

Can all these efforts lead us to one platform vision? We have to think over the 
question.

What's the one platform will be in your own words? What's your proposal and 
your focus to help one platform vision being achieved?


Best Regards
Chaoyi Huang (joehuang)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][elections]questions about one platform vision

[Chris Dent]

On Wed, 12 Apr 2017, joehuang wrote:


Can all these efforts lead us to one platform vision? We have to
think over the question.

What's the one platform will be in your own words? What's your
proposal and your focus to help one platform vision being
achieved?


These are tough questions. It's great to have a vision of one
platform, but if there are multiple understandings of what that
platform is (even when everyone thinks they are agreeing it's often
the case that they are not), it will be very hard to make progress.
At the same time inertia has enormous power to keep people,
projects, and companies doing the same old thing.

As usual, I think spending more effort to write down ideas, such as
the TC Vision draft and its concept of constellations[1] and the
resolution on cloud applications[2], are an important (but not
fully sufficient) step. The documents provide a focus around which
discussion can happen. While disagreement and enthusiasm are
important indicators, at least as important is the degree to which
people squirm about the assumptions being made. Writing helps to
expose those assumptions and once exposed we can decide what to do
with them.

In order for us to move forward on the one platform idea we need to
take the time and effort first to articulate the multiple approaches
and second to convince people of their merit. This second step will
require consistent engagement with not just project members but with
the companies that are funding most contributors. Those companies
have to be convinced of the merit of change. There's no doubt this
will be challenging, especially in these times when some companies
are willing to declare that OpenStack is "broken".

Making progress will require a TC that is proactive. In the last
election in October there were questions around whether the TC
should be a "a reactive council" or "a proactive committee that
initiates change"[3]. I'm firmly in the latter camp but believe the
action must be driven by a very active feedback loop with the entire
OpenStack community.

In any case, I do have a personal vision. It could very well be far
too pie in the sky and require too much change, but if approached
incrementally could provide benefit. My hope is that lots of people
would have a chance to express their vision and from all of them we
would choose the best bits to form the vision that we pursue. Any
vision will have many dependent tasks that must be satisfied
before the vision can even start. For example common policy
scenarios[4] and application user accounts[5] are global issues we
will need to address.

Essentially the idea is to change or expand the layers at which
humans and external applications interact with OpenStack, in the
style of oaktree[5] or enamel[6], where the outer layer is a single
API service driven by use cases (give me a vm, give me a bare metal
server, give me a pod representing elastic application X,
orchestrate the assemblage of Y). That layer speaks to the service
APIs to achieve its needs. Complex use cases (NFV perhaps?) might
skip the outer layer when they require functionality that the outer
layer does not expose. If the constellation metaphor catches on then
it is also possible that different constellations might have
different outer layers.

Like so many technology solutions, this is "simply" introducing
another layer of indirection. Doing so would enable each layer to
evolve with some independence and, critically, would allow different
implementations of the same service type to leapfrog an
incumbent[7]. To use that hackneyed cliché: skate to where the puck
will be.

If we are going to be thinking of OpenStack as one platform, then we
need to evaluate its various pieces with regard to how they support
that platform and each other as a whole. The needs and goals of the
individual services need to be secondary to the needs and goals of
OpenStack at large. That's a huge change in behavior and attitude,
one that might not be achievable, but worth trying.

I've been around long enough to know that there are many objections
to these kinds of changes, both technical and social. I think,
however, that it is important to at least consider them so we can
discover what improvements are possible. We're starting to recognize
that OpenStack must evolve more quickly. In order to do that we must
figure out ways to work around or loosen the constraints we've built
into our process and ways of engaging new audiences.

None of this is possible, however, unless the OpenStack community in
general and the TC in particular is able to come up with an
effective way to effectively publicize and manage the need for
contributors and other resources. The increased writing described
above will provide some help with that, but another important part
will involve being very clear with all stakeholders about the
sheer volume of work required to create and maintain OpenStack.

[1] https://review.openstack.org/#/c/453262/
[2] 

Re: [openstack-dev] [tc][elections]questions about one platform vision

[John Garbutt]

On 12 April 2017 at 12:04, Davanum Srinivas  wrote:
> On Wed, Apr 12, 2017 at 6:51 AM, John Garbutt  wrote:
>> On 12 April 2017 at 03:54, joehuang  wrote:
>>> What's the one platform will be in your own words? What's your proposal and
>>> your focus to help one platform vision being achieved?
>>
>> The more I think about this, the less I like the phrase "one platform".
>>
>> I like to think of OpenStack as group of constellations. Those
>> constellations are groups of projects that are built to be used
>> together around a shared set of use cases and users. Note that many
>> (all?) of those constellations involve open source projects that were
>> born and live outside of OpenStack.
>
> +1 for us to publish sets of projects that work together for specific
> scenarios. I heard this idea first from Allison Randall and it
> immediately struck a chord. To be fair folks like Jay Pipes have
> always said (paraphrasing) "OpenStack is a toolbox". So it's the next
> step i guess. Lauren Sell was mentioning yesterday about hearing
> confusion around "Big Tent", i do feel that when we put forth a set of
> constellations we can start deprecating the "Big Tent" terminology if
> appropriate.

Right, I have tools for hanging pictures, and tools for putting
together flat pack furniture. They all live in my tool box, and it
turns out I use the hammer for almost everything. (I don't generally
use the hammer when repairing my Tuba, and my wife prefers those
sticky hook things for hanging up pictures, but thats all fine) ... I
maybe stretched that a bit :)

Thanks,
johnthetubaguy

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][elections]questions about one platform vision

[Davanum Srinivas]

On Wed, Apr 12, 2017 at 6:51 AM, John Garbutt  wrote:
> On 12 April 2017 at 03:54, joehuang  wrote:
>> What's the one platform will be in your own words? What's your proposal and
>> your focus to help one platform vision being achieved?
>
> The more I think about this, the less I like the phrase "one platform".
>
> I like to think of OpenStack as group of constellations. Those
> constellations are groups of projects that are built to be used
> together around a shared set of use cases and users. Note that many
> (all?) of those constellations involve open source projects that were
> born and live outside of OpenStack.

+1 for us to publish sets of projects that work together for specific
scenarios. I heard this idea first from Allison Randall and it
immediately struck a chord. To be fair folks like Jay Pipes have
always said (paraphrasing) "OpenStack is a toolbox". So it's the next
step i guess. Lauren Sell was mentioning yesterday about hearing
confusion around "Big Tent", i do feel that when we put forth a set of
constellations we can start deprecating the "Big Tent" terminology if
appropriate.


> I am trying to kick start the "VM and baremetal" working group to get
> feedback on a specific constellation as a group of projects. Here I am
> thinking about running Nova, Cinder, Neutron, Keystone, etc to give
> you (in some sense) a Software Defined Data Center. Many applications
> and services need to consume and integrate with that platform, like
> Heat, Trove and Magnum, to can get access to the compute, networking
> and storage they need to execute their workloads, such as containers.
> Its like the next generation of consolidation to get to the next level
> of utilization/efficiency. If you look at this constellation the
> database and message queue are important non-OpenStack components of
> the constellation. Maybe this is a false constellation, and there is a
> different set of things that people use together. Thats some of the
> feedback I hope we get at the forum.
>
> The work ttx mentions is important. I hope the project maps will help
> communicate how users can meet their needs by running various
> combinations of OpenStack and non-OpenStack projects together.
>
> To be clear, I am not claiming to have the answers here, this is just
> my current thinking. I look forward to all the debate and discussions
> around this topic, and all the interesting things I will learn about
> along that journey, things that will likely make me change my mind.
>
> Thanks,
> johnthetubaguy
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Davanum Srinivas :: https://twitter.com/dims

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][elections]questions about one platform vision

[John Garbutt]

On 12 April 2017 at 03:54, joehuang  wrote:
> What's the one platform will be in your own words? What's your proposal and
> your focus to help one platform vision being achieved?

The more I think about this, the less I like the phrase "one platform".

I like to think of OpenStack as group of constellations. Those
constellations are groups of projects that are built to be used
together around a shared set of use cases and users. Note that many
(all?) of those constellations involve open source projects that were
born and live outside of OpenStack.

I am trying to kick start the "VM and baremetal" working group to get
feedback on a specific constellation as a group of projects. Here I am
thinking about running Nova, Cinder, Neutron, Keystone, etc to give
you (in some sense) a Software Defined Data Center. Many applications
and services need to consume and integrate with that platform, like
Heat, Trove and Magnum, to can get access to the compute, networking
and storage they need to execute their workloads, such as containers.
Its like the next generation of consolidation to get to the next level
of utilization/efficiency. If you look at this constellation the
database and message queue are important non-OpenStack components of
the constellation. Maybe this is a false constellation, and there is a
different set of things that people use together. Thats some of the
feedback I hope we get at the forum.

The work ttx mentions is important. I hope the project maps will help
communicate how users can meet their needs by running various
combinations of OpenStack and non-OpenStack projects together.

To be clear, I am not claiming to have the answers here, this is just
my current thinking. I look forward to all the debate and discussions
around this topic, and all the interesting things I will learn about
along that journey, things that will likely make me change my mind.

Thanks,
johnthetubaguy

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][elections]questions about one platform vision

[Thierry Carrez]

joehuang wrote:
> [...]
> What's the one platform will be in your own words? What's your proposal
> and your focus to help one platform vision being achieved?

OpenStack is "one platform", one open infrastructure platform. It can
provide various resources (VMs, bare metal machines, container
orchestration engines, single container hosts, object storage...) with
shared services. You can use your Keystone authentication across the
board. You get "one platform" for compute resources of different types,
and within that platform they can share networks, block storage or
filesystems. This "open stack" can integrate components that are not
developed by the OpenStack community, but for those that are, we aim to
simplify the operational experience by using the same set of base
services, log formats or configuration style.

We need to produce maps of OpenStack that will make it clearer how
everything fits together, and expose the open nature of the stack. I'm
leading a Board+TC+UC group working on that mapping effort. We need to
make it easier for infrastructure pieces produced outside of our
community to be plugged into the open infrastructure platform, and I'm
reaching out to those communities to preach the word, but also support
Keystone, Cinder and Neutron efforts to serve a wider set of consumer
services. Finally, over the past cycle I pushed a clear definition of
the notion of base services. Over the coming cycle we should refine and
expand the set to include new services that every component in the
OpenStack family could take advantage of, like etcd.

Thanks for raising that question!

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][elections]questions about one platform vision

[Sean McGinnis]

On Wed, Apr 12, 2017 at 02:54:30AM +, joehuang wrote:
> Hello,
> 
> I heard the one platform vision in OpenStack now and then: One platform for 
> virtual machines, containers and bare metal.
> 
> I also learned that there are some groups working on making Kubernets being 
> able to manage virtual machines. Except running containers in virtual 
> machine, there is also the need for running containers in bare metal.
> 
> There are several projects connecting OpenStack to container world: Zun, 
> Magnum, Kuryr, Fuxi... Projects to deal with bare metal like Ironic, Morgan, 
> ...
> 
> Can all these efforts lead us to one platform vision? We have to think over 
> the question.
> 
> What's the one platform will be in your own words? What's your proposal and 
> your focus to help one platform vision being achieved?
> 

I can't claim to have a proposal to get us there. I do think it is something
that will require plenty more discussion and a whole lot of collaboration.

There is certainly overlap is the goals of these efforts. I think it all
comes down to giving the end user the ability to run their workload in the
cloud without requiring (or at least minimizing as much as possible) the
knowledge they need to know about the specific platform implementation.

I think the best way we can get closer to this goal is related to one of the
points I brought up in my candidacy message. I think we need to be open to
collaborating with other open source projects outside of OpenStack to come
up with the best solutions, and to make sure that these parallel or
complementary solutions can work well together.

> 
> Best Regards
> Chaoyi Huang (joehuang)

> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tc][elections]questions about one platform vision

[joehuang]

Hello,

I heard the one platform vision in OpenStack now and then: One platform for 
virtual machines, containers and bare metal.

I also learned that there are some groups working on making Kubernets being 
able to manage virtual machines. Except running containers in virtual machine, 
there is also the need for running containers in bare metal.

There are several projects connecting OpenStack to container world: Zun, 
Magnum, Kuryr, Fuxi... Projects to deal with bare metal like Ironic, Morgan, ...

Can all these efforts lead us to one platform vision? We have to think over the 
question.

What's the one platform will be in your own words? What's your proposal and 
your focus to help one platform vision being achieved?


Best Regards
Chaoyi Huang (joehuang)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev