Based on requirements defined in [1], I believe that is
a fair statement to claim cold upgrades support for Neutron.
Rolling upgrades are not too far off, but not within our reach
to allow us to claim assert:support-rolling-upgrade, just yet.
This is mainly because of lack of full stack integration testing
with services arranged in a mid-upgrade manner. This is planned
for Mitaka, and I count to reconsider adding the latter tag in
time for the release.
[1] http://governance.openstack.org/reference/tags/assert_supports-upgrade.html#requirements
Change-Id: I691325fe5f8562fb59239ecde75f0992a53d599e
Glance follows such policy for deprecating the different parts of the
project whenever it's deprecation is required.
Change-Id: I83006821e5bb1271484ec23b1216c6a39bf6470e
Added supports-upgrade and follows-standard-deprecation to the
cinder service. Also updated PTL email.
Change-Id: I7554fd9f66bdbfe04dceeca5963e18e3582bbe77
Horizon packages many of its dependencies with xstatic hosted on pypi,
and they (mostly) have respective openstack projects for community
review. These should be listed as valid openstack projects within
governance.
Change-Id: Ie03bc7bd5c4f6f9c9133e45ad3b1d37f83cb224b
os-vif is a project to define an object model and plugin system
to integrate OpenStack network providers (eg Neutron) and
OpenStack compute providers (eg Nova)
It will be developed jointly by representatives from both the
Nova and Neutron teams, but for the sake of governance Nova is
set as the owner.
Change-Id: Ife95bea0cba68901a8c820c4f32a9782d5735beb
Depends-on: Ifc2c1a3198075aafc3fd97f0c5355eb27ba8bc19
Objectively communicates when project teams are driven by a single
organization, so that this fact can be taken into account in project
adoption decisions.
Change-Id: I399046ab7c3266b08c2a48382abfb89c33aab146
This updates governance for new roles that will be coming online
as the OpenStack-Ansible moves to break out our roles from the
main repo.
Implements: blueprint independent-role-repositories
Depends-On: Ibfd5e745b7c5836b1c421b06ff8ef1e122c14108
Change-Id: I63a999bdfae487f05e9918a2817433c6e026e79f
Signed-off-by: Kevin Carter <kevin.carter@rackspace.com>
After discussion with Mistral core team, we decided to adopt the
specification approval process, like other official projects.
Change-Id: I7da1ffaee454383704beb94b0c2bc9786dd1846f
Nova has:
- Asserted assert:supports-rolling-upgrade
- Has a defined plan for operators to upgrade individual compute resources
separately from control services, eliminating the need to restart the
entire deployment all at once.
- Has had full-stack testing of mixed-version mid-upgrade services in its
gate consistently for several releases.
Change-Id: I79e50b2345adeb15d729f348c36b6a5808dfa37d
Nova has stable configuration changes, database schema upgrades, a defined
upgrade process that doesn't change, and always includes upgrade details
in the release notes. These statements have been consistently true for
the last several cycles.
Change-Id: I31d0f50fe4e7864dd8ef505c429f9df40520f238
Monasca provides a multi-tenant, highly scalable, performant, fault-tolerant
monitoring-as-a-service solution for metrics. Metrics can be published to the
Monasca API, stored and queried. Alarms can be created and notifications, such
as email, can be sent when alarms transition state. Support for complex event
processing and logging is in progress. Monasca builds an extensible platform
for advanced monitoring services that can be used by both operators and tenants
to gain operational insight and visibilty, ensuring availabilty and stability.
All code has been developed under an Apache 2.0 license and has no restrictions
on distribution or deployment. All Monasca code is submitted and reviewed
through OpenStack Gerrit [1]. The Monasca project maintains a core team that
approves all changes. Bugs are filed, reviewed and tracked in Launchpad [10].
Monasca integrates in with several OpenStack projects and services. The Monasca
API uses Keystone for authentication and multi-tenancy. Oslo libraries are used
by all components where applicable. Keystone middleware is used by the Monasca
API. The Monasca project is in the process of integrating with Ceilometer by
using the Ceilometer data collection pipeline as well as the Ceilometer API via
a Ceilometer to Monasca storage driver, which will enable Monasca to consume
OpenStack notifications from other OpenStack services [5]. A monitoring panel
has been developer for Horizon. An integration with Heat for auto-scaling
support is under active development.
Monasca has been running weekly meetings from the start of the project.
Meetings are held on Tuesday's at 9:00 AM MST and are open to anyone that wants
to attend. Currently, the Monasca PTL is Roland Hochmuth. Regular elections
will be held to elect new PTLs and core members.
Monasca was initially discussed at the Atlanta Summit. The first Monasca
mid-cycle meetup was held in August 2014 at which three companies attended. At
the Paris Summit a session on Monsca was held. In addition, at the Paris
Summit, there as a design summit session held to discuss areas for collaboration
between Ceilometer and Monasca. A Monasca Liberty mid-cycle meetup was held on
August 7-8, 2015, and included six companies [9]. Monasca is planning on
holding Monasca specific sessions at the Tokyo Summit as well as joint sessions
with other OpenStack projects. Monasca is interested in developing integrations
with Ceilometer, Heat, Mistral, Congress and others. There have been several
local meetups on Monasca in 2015, including Austin, TX, Boulder, CO, and San
Francisco, CA.
Monasca has an extensive set of documentation. Overall documentation and links
to documentation are at the Monasca Wiki [2]. The Monasca API is documented
[3]. The optional Monasca Agent is documented [4].
Monasca has several official deployment solutions available. Ansible roles are
available [6]. Puppet modules are available via the openstack organization
[7]. Monasca also has a turn-key development environment based on Vagrant,
Devstack and Ansible [8]. Monasca integrates with DevStack via a Monasca
plugin [11] for DevStack. Tempest tests for Monasca [12] are also available.
Monasca is continually deployed to test and production environments off of
master branch and maintains a very high level of quality. The first major
release of Monasca was tagged for Kilo. The second major release of Monasca
will be tagged for Liberty.
[1]: https://review.openstack.org/#/q/status:open+monasca,n,z
[2]: https://wiki.openstack.org/wiki/Monasca
[3]: http://git.openstack.org/cgit/openstack/monasca-api/tree/docs/
monasca-api-spec.md
[4]: https://git.openstack.org/openstack/monasca-agent
[5]: https://git.openstack.org/openstack/monasca-ceilometer
[6]: https://github.com/search?utf8=%E2%9C%93&q=ansible-monasca
[7]: https://git.openstack.org/openstack/puppet-monasca
[8]: https://git.openstack.org/openstack/monasca-vagrant
[9]: https://etherpad.openstack.org/p/monasca_liberty_mid_cycle
[10]: https://bugs.launchpad.net/monasca
[11]: https://git.openstack.org/openstack/monasca-api/devstack
[12]: https://git.openstack.org/openstack/monasca-api/monasca_tempest_tests
Change-Id: I04eeb7651167ca2712f525af3f5b2b5d45dacb5f
This is a request to add Senlin [1] to the Big Tent.
Senlin is designed to be a generic clustering service for OpenStack clouds
that makes the creation and management of homogeneous objects as groups an
easier task. Examples of objects include Heat stacks, Nova servers, etc.
Senlin provides an open framework that consists of:
- an engine that manages clusters and nodes and the primitives to operate
them as abstract objects;
- profile plugins that enable senlin to talk to a specific OpenStack
service for object CRUD operations.
- policy plugins that capture rule sets which are checked/enforced when
object operations are performed, e.g. placement, deletion, scaling, health
and others.
- trigger plugins that customize the external signals/alarms/events that can
trigger operations on clusters/objects/profiles/policies;
The project was started in Nov, 2014 after the Paris summit as a standalone
service that will offload the auto-scaling service from Heat. The scope was
then expanded to include other policies for a comprehensive clustering or
collection service on OpenStack. The project was openly discussed with the Heat
team during Vancouver summit. Plan is being developed for migrating the
existing auto-scaling support in a way that reduce (or totally avoid) user land
changes.
Senlin is also working with other OpenStack projects to explore collaboration
opportunities. For example, team has worked with intern students to manage
container clusters under the Magnum context. The goal is to investigate how to
manage the VM groups and container clusters so that these two layers can be
scaled, load-balanced in accordance with each other. A demo is scheduled on
the Tokyo summit.
Senlin strictly follows the "4 opens" principle of the community.
The project is fully licensed under the Apache 2.0 license. All code changes
are submitted and reviewed using the OpenStack infrastructure and gated
through gerrit[2][3][4]. Team has been using the +2/+A process for patch
reviews. The current unit test coverage is 90% and functional gate is in place
helping ensure everything works together. The project strictly obeys the
coordinated project interfaces, including tox, pbr, global-requirements etc.
All dependencies of the project falls within the range of global requirements.
The gating now runs pep8, py27, py34, docs tasks and optionally a functional
test.
The PTL was chosen by election to be Qiming Teng during Mitaka cycle. The PTL
serves as liason between the Senlin community and other projects to coordinate
the interactions with for example python-openstacksdk, heat, ceilometer, etc.
Team plans to excercise a PTL rotation among core contributors.
Project team has been using openstack-dev mailing list and freenode IRC
channel #senlin heavily for cooperation. The #senlin channel is logged [5] and
the logging is notified in the channel. Project team has weekly IRC meeting on
channel #openstack-meeting on 1300 UTC every Tuesday [6] to accommodate
contributors from east Asia and America.
Senlin has a well-documented, reasonably stable API [7] ready to be merged by
upstream project. It has documents for beginner users [8] and new developers
[9]. Developer team has been answering questions related to installation and/or
usage in IRC actively.
It is true that Senlin has been initiated by a single company but the project
has now attracted contributors from more than 6 affiliations. We have reasons
to believe the adoption by Big Tent will help encourage more contributions to
its design and implementation, thus improve the diversity status of the team.
[1]https://wiki.openstack.org/wiki/Senlin
[2]https://review.openstack.org/#/q/project:openstack/senlin,n,z
[3]https://review.openstack.org/#/q/project:openstack/python-senlinclient,n,z
[4]https://review.openstack.org/#/q/project:openstack/senlin-dashboard,n,z
[5]http://eavesdrop.openstack.org/irclogs/%23senlin/
[6]https://wiki.openstack.org/wiki/Meetings/SenlinAgenda
[7]http://git.openstack.org/cgit/openstack/senlin/tree/doc/api-site/api-ref/src/wadls/clustering-api/src/v1
[8]http://git.openstack.org/cgit/openstack/senlin/tree/doc/source/getting_started
[9]http://git.openstack.org/cgit/openstack/senlin/tree/doc/source/developer
Change-Id: I3a6581578cbff3e76ed197d2dfecc7a2ef3e1dd5
This tool, when ran can create diagrams that show what
exactly the big-tent is and/or what the subprojects/deliverables
a project produces are.
For example, here is the way to create a output for ironic
and its deliverables:
$ python tools/universe_dot.py reference/projects.yaml \
ironic_universe.dot ironic;
$ neato -Tsvg ironic_universe.dot > ironic_universe.svg
Then view svg as is, or convert to png or other...
This requires pydot2 and pyyaml to be installed to work.
Change-Id: Idcd73f9e678e200d65eda4d1d54f1156fd18853b
Refine type:service definition so that it only applies to
classic OpenStack user-facing services, and not to internal
long-running agents.
Apply the new definition to current projects.
Change-Id: I34881f957f5f047ccc5bc4559e12fac43d9481ff
The assert:supports-rolling-upgrade tag defines a standard minimum for
what we consider to be "rolling upgrade" capabilities in OpenStack
services. Project teams may assert that they follow at least
this policy.
This is an essential bit of information to communicate to our users,
and a key factor in assessing a given project's maturity.
Change-Id: I7ba9cdbe1b6ba026da374dd66e30611133538e91
