While nova-network is still supported because of concerns about
migration paths, neutron should be as strongly recommended for any new
deployments as is humanly possible so that we can ultimately get
ourselves out of the mess of having two network stacks.
Since starter-kit:compute is intended to help point a finger at what
people should install when trying things out, we should certainly not
imply that they install a network stack that we plan on deleting in the
future. Neutron in provider-vlan/linuxbridge mode is dead simple in not
requiring openvswitch or SDN, and still gets new users a cloud that is
upwards flexible with the future.
Change-Id: I91bce1bcc51121a8a577cff478fdc91002b689b4
Kuryr aims to service the Docker Container Network Model[1] by leveraging
Neutron in a way similar to how Nova does.
(Directing API's to Neutron API's)
The project will serve as a single effort point for connecting
the various Neutron sub projects with Dockers and provide
different Docker plumbing (connecting the docker instances into
the overlay) images for the various different Neutron plugins
and implementations
[1] https://github.com/docker/docker/blob/master/experimental/networking.md
Change-Id: Ia774a4f4d60377a42e8a5d3ba8a3f3eaace662e4
Depends-On: I38f24906493e25575b084b06b7a62bbfc0c2f414
A new git repo for hosting devstack amqp1 plugin
Depends-On: Ifcc52fee113a9f24fe028bef6e22fc4b68a694f7
Change-Id: I41f50e941a93a4c217bfcbdade6deb052a848dcb
In the Liberty cycle we support new release models, which made
the current release tags taxonomy a bit unusable.
Switch to a new model taxonomy where a repository may only have
one release model:
* release:cycle-with-milestones (think keystone or nova)
* release:cycle-with-intermediary (think swift or libraries)
* release:independent (think zuul)
* release:none (think: openstack/governance)
This will clarify which release models actually exist, and
more clearly communicate to our users (and our tooling) which
model each repository follows.
We also adapt the wording of the release:managed tag to avoid
excluding swift or Oslo libraries (which do not follow the
development milestones model) from being managed if the release
team accepts them.
Change-Id: Ie58a370f2a189a421040535b99949f3fac9eb4eb
The 'integrated-release' tag was a legacy tag to ensure the
transition between the "Integrated Release" project model and
the "Big Tent with Tags" project model.
We are far enough into the transition now that we can remove
the legacy tag and look forward.
Notes:
- "Integrated" was mentioned in two project team mission statements
(Horizon and Release Cycle Management), which means this change
will require their respective PTLs approvals
- Information about integrated release (in particular the "since"
cycle) is not lost and can easily be retrieved using the
april-2015-elections tag
Change-Id: I20c662c812f3a1952f21a4ae1cb677a8ae3db488
The tc-approved-release tag was defined but never applied.
Following the definition, it is initially applied to all
formerly "integrated-release" members.
neutron-fwass was left out since the FWaaS API is experimental
until consensus has been reached on the Neutron team that it is
stable:
https://wiki.openstack.org/wiki/ReleaseNotes/Kilo#Known_Issues_5
Change-Id: I6ffe2cd9969518c72479ea6c9950d9e36d39f80d
This patch proposes that Neutron embrace networking-arista in
its fold. This is according to the procedure specified in [1].
networking-arista implements neutron support for various
Arista products.
[1] https://github.com/openstack/neutron/blob/master/doc/source/devref/sub_projects.rst
Change-Id: I84825adc3f7beba8dd457ddb70b112e0dd2c39dc
Move anchor and bandit from stackforge to openstack namespace. Both
projects are part of the security team already.
Change-Id: I11b5c5d1fb8b4ae7da3faefb89b4a69f75880d4b
Depends-On: Iad678d688265c748fcbaaef294fda959b934dd85
We have a new oslo.reports project under the Oslo program. This
houses the openstack/common/reports/ module under oslo-incubator.
Change-Id: I33a6098f20eaf2b7c246920f87de6784061f7151
A new git repo for hosting devstack zmq plugin
Depends-On: Id6ebf86308536046135ad25070faee5143ad545a
Change-Id: I01694261581935ad95507e9a84c899c35663a363
openstack-doc-tools is manged by the release-team, like
openstackdocstheme.
It is also not a service but a "piece of software that is used to build
another project" and thus add type:library to it.
Change-Id: I4c0ae089d4d0498a05a8f181d94ee03bd8ccf664
As per the guidelines here [1], moving networking-plumgrid
to Neutron.
[1] https://review.openstack.org/#/c/175952/5
Change-Id: I67c2d9cad301aa8296ce3a374540e95f33f19593
This repository was moved to openstack as part of the murano rename but
not part of the governance change. Add it.
Change-Id: Idb4de6c188b3ab8defbe86d01825585108b9ac8b
Depends-On: I56dd0fe97b6aec7026e7ff605f2893cd7521ffcf
Hound is a code-search tool that infra will run.
Change-Id: I79a7bc43157bb1ae0f1bcd88b22214fe5dae7651
Depends-On: Ie2df4a0f40e450f142c84449ed0d03f12b8786e6
This is the puppet module to deploy refstack.
Change-Id: Ibcc8d296f46fbfc09bcd91a1bfb990a05c2d7877
Depends-on: I077bb2c21a6a5724a54110718ebfa6e7ef1d5ff6
The openstack/releases repository will be used by the release management
team to handle requests for releases from other repositories. See
https://review.openstack.org/191193 for details.
Change-Id: I2eaa20bb2fcee83590af03499bd722b0707459ed
Depends-On: Ic821b091ffcba7ebb40309a67d241b1f2fbfba02
When the compute starter kit tag was added, it didn't actually have a
proposed tag name, or any applications in projects.yaml. This patch
fixes that.
Related cleanups
* Move application section higher up to align with other tags
* Also fix up a few typos.
Change-Id: I1973f7d8e3062dee4663a8f14099d685f9ea0b47
Projects that were incubated during the Kilo development cycle used to
have their release management process handled by the release management
team. After discussing it with the team, we'd like to offer to continue
doing that for those projects (Manila, Designate, Zaqar, Barbican) under
the big tent model.
This should get approvals from each project's PTL.
Change-Id: I7a870e016a02090ac6b65a124df265453e80daa6
Add the release:managed tag to the libraries that are being managed by
the release management team.
Change-Id: I043488ef7768d7f63658f3fc6e9251b691a4172f
This effort has been discussed and approved by the Magnum community
including our PTL Adrian Otto in this mailing list thread:
http://lists.openstack.org/pipermail/openstack-dev/2015-June/066701.html
Depends-On: Ice2e14bf999f79ca0c0718948db616456faab907
Change-Id: I180eeb112d7469f69677494574dbcff0cdc7d0ef
Also made a small tweak to the ironic dscription, since it's not
explicitly python anymore.
Change-Id: Iccd7a3e0fd2439c74ae39a502010925ef3e9c023
Depends-on: Ic45c0607d408534b5b6aa9361ceeb4857850594b
This project is intended to be a javascript equivalent of openstack's
"hacking" project. As rules such as this fall under the umbrella of
openstack's QA efforts, it has been placed there.
Change-Id: If925433a704ceccf9d0abe06977ef4fffbae7eb8
Depends-on: I434465d126ee22bd7fb5e1f9d6d77763640aa3d9
Cue is currently an active stackforge project that provides provisioning and
management capabilities for message brokers. The project complements other
Messaging efforts in OpenStack, such as Zaqar, by offering a managed solution
for off-the-shelf messaging technologies. Cue currently supports RabbitMQ
clusters with plans to add other brokers [1].
Cue is similar in lots of way to Trove, in that Cue provides lifecycle
management for existing message brokers, much like how Trove provides
lifecycle management for existing data stores.
From the beginning, the project has followed all of the principles of the
OpenStack way.
All code has been developed under the Apache 2.0 license. All library
dependencies comply with global-requirements and have no restrictions on
distribution or deployment.
Cue leadership is selected by the contributors of the project. The current
PTL for Cue is Vipul Sabhaya. The project has regular IRC meetings, that
are logged [2] and published.
All code is submitted and reviewed through OpenStack gerrit. The Cue project
maintains a core team that approves all changes. All repositories are gated,
and the following tests are run:
- python tests
- tempest-dsvm-gate
- rally-gate (currently experimental)
Cue leverages other OpenStack services, and also heavily leverages Taskflow
to execute all long-running tasks/jobs.
Cue has an extensive set of docs to onboard new contributors, as well as docs
for operators that want to deploy Cue [3].
All cue design discussions occur on IRC #openstack-cue or on the dev mailing
list. The cue team has also held breakout sessions at the Paris and Vancouver
summits to discuss project goals and design, and will continue to do so.
Cue continues to get interest from companies that offer message brokers
seeking to write plugins for their technology.
[1]: https://wiki.openstack.org/wiki/Cue
[2]: http://eavesdrop.openstack.org/meetings/cue/
[3]: http://cue.readthedocs.org/en/latest/
Change-Id: I077b5393b71052637386e237ad04396395a9ebde
The release team is building some tools for automating common release
processes. Some of these tools will look at the type of the repository
to make choices, including skipping or including the repository or
applying different criteria or process steps. For example, most of the
service projects use pre-versioning rather than post-versioning, and
so some of the release tools need to take different steps when
processing a service project.
Change-Id: If01633d5b2762cb09ffd80f212e2dcc72156128d
This repo will be the home for scripts and manifests for functional and
integration testing of the OpenStack Puppet Modules.
Change-Id: I93ba3c63a3d612dd4bd359d80c049ea345d12bdf
Depends-On: Ibb8a31f3d74df67289b2ee269e5080e9f912e2b6
