settingsLogin | Registersettings

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

0 votes

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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Apr 19, 2017 in openstack-dev by joehuang (17,140 points)   2 6 9

26 Responses

0 votes

On Wed, Apr 12, 2017 at 02:54:30AM +0000, 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-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Apr 12, 2017 by Sean_McGinnis (11,820 points)   2 2 5
0 votes

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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Apr 12, 2017 by Thierry_Carrez (57,480 points)   3 8 13
0 votes

On 12 April 2017 at 03:54, joehuang joehuang@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Apr 12, 2017 by John_Garbutt (15,460 points)   3 4 5
0 votes

On Wed, Apr 12, 2017 at 6:51 AM, John Garbutt john@johngarbutt.com wrote:
On 12 April 2017 at 03:54, joehuang joehuang@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.

+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-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Apr 12, 2017 by Davanum_Srinivas (35,920 points)   2 4 8
0 votes

On 12 April 2017 at 12:04, Davanum Srinivas davanum@gmail.com wrote:
On Wed, Apr 12, 2017 at 6:51 AM, John Garbutt john@johngarbutt.com wrote:

On 12 April 2017 at 03:54, joehuang joehuang@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.

+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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Apr 12, 2017 by John_Garbutt (15,460 points)   3 4 5
0 votes

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] https://review.openstack.org/#/c/447031/
[3] http://lists.openstack.org/pipermail/openstack-dev/2016-October/104953.html
[4] https://review.openstack.org/#/c/245629/
[5] https://github.com/openstack/oaktree
[6] https://github.com/jaypipes/enamel
[7] Note that I'm not suggesting here that a new implementation of
a service type implement the same internal API. I'm saying there could
be a new API and implementation that the outer layer would interface
with to satisfy the same use cases using changed technologies.

--
Chris Dent ¯_(ツ)_/¯ https://anticdent.org/
freenode: cdent tw: @anticdent__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

responded Apr 12, 2017 by cdent_plus_os_at_ant (12,800 points)   2 2 5
0 votes

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 joehuang@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Apr 12, 2017 by German_Eichberger (720 points)  
0 votes

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 [john@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 joehuang@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-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Apr 13, 2017 by joehuang (17,140 points)   2 6 9
0 votes

On 12/04/17 02:54 +0000, 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


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

responded Apr 13, 2017 by Flavio_Percoco (36,960 points)   3 7 11
0 votes

Excerpts from joehuang's message of 2017-04-13 00:47:53 +0000:

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 [john@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 joehuang@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Apr 13, 2017 by Doug_Hellmann (87,520 points)   3 4 9
...