I7c6effe6e440f2147f8c68df090152e716c38fba added support to automatically
keep the 'Application to current projects' section pull from
projects.yaml but several of the tags used the wrong formatting causing
the tag pages to not list any projects as tagged.
Change-Id: I37afc38b43d1d812b3b9e1baabeafaec0b6fec59
Provide a simple YAML-based language to write workflows (tasks and
transitions), and a service that allows to upload them, modify, run them at at
scale and in a highly available manner, manage and monitor workflow executions
and states of individual tasks.
The code base has existed for 1 year and 4 months in the stackforge code
namespace.
Mistral community has been consistently growing from cycle to cycle and now
includes more than 10 contributors from Mirantis, StackStorm, Huawei, HP,
Symantec, and Ericsson.
We will hold elections for our PTL, currently Renat Akhmerov, on a regular basis
according to standard OpenStack community practices. We hold weekly team
meetings on IRC where we discuss Mistral design, blueprints, issues, roadblocks
and roadmap. We also use openstack-dev@lists.openstack.org mailing list for all
offline discussions related to new ideas, design and implementation. Blueprints
and bugs are tracked using Launchpad according to OpenStack rules. The gerrit
review board rules are strictly followed. Mistral is integrated with devstack,
and runs tempus functional tests as gate tests. Functional tests are integrated
with devstack, tempest, and rally and run as gates.
Mistral is implemented using libraries and technologies adopted by OpenStack
community such as SqlAlchemy for object persistence, oslo.messaging for RPC
communications, and others.
Mistral is also integrated with other OpenStack services. It has full dynamic
support for OpenStack actions - Keystone, Nova, Glance, Heat, Cinder, Neutron,
so any openstack operations can be used in workflows. Murano project has the
ability to call Mistral workflows from Murano PL. There are also two patches on
review that add Mistral related resources into Heat (workflows and cron
triggers). There is interest from other projects to using Mistral, expressed
from Congress, Trove, Solum, Barbican, Heat, and Keystone.
Change-Id: I5d0e877903c3f55ce2330e301b27da9435f677c5
This commit adds the devstack-vagrant repo to the QA program. This
was another repo which was missed during the devstack qa merge last
year.
Change-Id: Ie86b894607ada24611768ba475cc292bae0c809b
Rally is a tool that simplifies testing, performance analysis and
benchmarking of all OpenStack clouds.
Our mission is to provide OpenStack ecosystem with framework and tool
that answer the question "How well OpenStack performs" and help developers
to improve OpenStack:
- Rally tasks as a common language between QA/Dev/Ops and community
- Simplify reproduction of performance/scale issues and races
- Rally gate jobs that allows developers to
work on performance/scale issues and races together in gates
- Performance regression testing in gates and on scale
- Automation of cloud performance validation
The Rally contributor community being made up of more then 135
developers from more then 36 companies.
Boris Pavlovic was selected as the PTL by Rally contributors according
to standard OpenStack community practices.
Our meetings are weekly, on IRC, and our road map is transparent and
managed via specs, feature requests, launchpad, Google drive and
other OpenStack community practices.
Change-Id: I53d42e5bff9217160703768e3d9643e4d1f9ecfa
Adopt openstack-dev/specs-cookiecutter by release management team.
The repository is a "blueprint" for new specs repositories, it was
added by change Ic0d86eef7ec4a2f2076c4adbdbf4fa79d1661790.
Change-Id: I89e6c1fd29a3d214c5b8f15b8284cc43b9a46ee3
The VMT and the OSSG have merged to form a single security team.
We are seeking to have this team recognised as a horizontal project
within OpenStack, similar in many ways to the current documentation
team.
Advisories, Documentation, Security Notes, Threat Analysis etc
are all measured through their respective respositories.
Change-Id: I9d0db560952380d3283ca710608ed0fdd3af64da
Propose adding openstack/tripleo-common to the TripleO
program. tripleo-common will be a python library
which will contain code common for Tuskar UI and TripleO CLI.
Change-Id: I5ae63c2ca3a5253897848b1e52a4475ebbd6b178
This tag lets us differentiate between projects that happen
to have stable branch cut out of their last release in the
development cycle (like Oslo libraries or Python client libs)
and projects that consciously make a release at the very end
of the 6-month development cycle to match with the "managed"
coordinated release (like Swift or Manila).
Those are different bits of information to convey to our users
(will they have a release to match with the coordinated 6-month
release, vs. will they have a stable branch to draw
backward-compatible safe updates from).
To make it easier to judge what that means, this change directly
applies the new tag to the existing set of projects.
I also clarified the meaning of the "release:at-6mo-cycle-end" tag
and removed it from projects that don't make a coordinated release.
Change-Id: Icb3b5a348e0a45437d6ac6a044ed098c6380ee97
After being part of the openstackclient project, the os-client-config
repo gets moved to openstack.
Change-Id: I313b76877400ebc61b4f384f2c25f48310f04521
Depends-On: I58c2280511c29b6235cd03ffaf05ecd8685a545e
When the devstack program was merged into the QA program late in the
Juno cycle only the devstack repo was added under QA. However, the
bashate repo was also under devstack but we neglected to add it to
QA. This commit corrects this oversight.
Change-Id: Id0e1c5271fe665a8e3b06b9aad83efb7c44e4abf
This commit adds a new repo under QA, os-testr. The intent of this repo
is to provide tooling to interact and use testr. Right now it contains
2 pieces subunit-trace, which has become the de-facto output filter
for running tests, and ostestr which is a testr wrapper similar to the
pretty_tox.sh scripts which are currently used everywhere but expands
on that functionality.
Change-Id: Idbd6251546809f6ea7a651be9e758619fddd4e7f
Apply previously-defined release:* tags to current repositories.
In the corresponding tag definitions, add links to list of projects
that have the tag applied.
Change-Id: I93c192235b82d071e280c68a86950aa0004d98fb
Thierry suggested the addition of a two-organization rule during the
review of the team:diverse-affiliation tag. This patch adds that rule
and notes that it does not trigger any changes to the application of
the tag at this point. However, it comes close for Trove.
This patch also includes a wording change from "company" to
"organization" in the tag definition, which was suggested by Anne
during the original review.
Change-Id: I132aa31a2c33580685619c41ec2d7d7a84d858c5
This patch applies the team:diverse-affiliation tag to the teams that
meet the criteria.
So far we've only defined tags as applying to projects (git repos).
However, this tag is defined as applying to the sum of the team's
work. So, I propose applying this tag at the team level. Any tags
applied at the team level can be inherited by every git repo the
team manages. This reduces a *lot* of unnecessary duplication of this
tag in the yaml file.
The following teams receive the tag:
<Team> (top commit % | top review % | top core review % | (top core reviewer %)
Nova (19.61% | 19.85% | 25.50% | 31.25%)
Swift (27.31% | 26.42% | 37.15% | 36.36%)
Glance (23.37% | 29.19% | 39.84% | 33.33%)
Keystone (42.62% | 29.91% | 46.61% | 37.50%)
Horizon (27.97% | 16.94% | 22.53% | 30.77%)
Neutron (26.50% | 19.63% | 24.44% | 16.67%)
Cinder (11.73% | 11.33% | 16.68% | 20.00%)
Heat (33.10% | 33.98% | 38.75% | 27.78%)
Trove (35.16% | 38.89% | 47.22% | 42.86%)
Ironic (26.79% | 28.23% | 31.09% | 33.33%)
Oslo (31.18% | 28.08% | 34.42% | 23.08%)
Infrastructure (39.10% | 49.58% | 48.20% | 40.91%)
Documentation (19.68% | 26.75% | 35.92% | 19.05%)
Quality Assurance (26.90% | 26.17% | 32.39% | 33.33%)
Magnum (32.10% | 35.80% | 36.81% | 28.57%)
The following teams do not receive the tag:
Barbican (51.09% | 48.49% | 52.67% | 55.56%)
Ceilometer (52.33% | 31.96% | 63.04% | 50.00%)
Designate (56.50% | 64.63% | 65.49% | 60.00%)
Manila (47.77% | 30.60% | 44.93% | 50.00%)
Murano (85.14% | 91.99% | 99.33% | 87.50%)
OpenStackClient (34.50% | 36.22% | 56.21% | 33.33%)
Sahara (52.52% | 58.97% | 60.35% | 57.14%)
TripleO (54.89% | 56.66% | 62.67% | 60.87%)
Zaqar (48.89% | 67.11% | 77.99% | 66.67%)
Change-Id: I7a71ebb508d3f8d2fd8d9e33f920e2de70ebb7a4
Mission is updated in order to correct incorrectly composed phrase.
Change-Id: If1b2c097590607901490180e8b8d345a8e1d064c
Co-Authored-By: Anne Gentle <anne@openstack.org>
Murano is a set of code repositories that implements an application catalog.
Our mission is to provide a RESTful API and user interface that allows users
to compose and deploy complex composite application environments and manage
the lifecycle of those environments. The code base has existed for well
over 2 years in the stackforge code namespace.
The Murano contributor community being made up of more
than 10 contributors from Mirantis, HP, Telefonica, and
other organizations, and we hope to get it more diverse
after moving to /openstack space.
We will hold elections for our PTL, currently Serg Melikyan, on a regular basis
according to standard OpenStack community practices. Our meetings are weekly,
on IRC, and our roadmap is transparent and managed on Launchpad again
using standard OpenStack community practices.
We rely on Heat as orchestration engine for provisioning application on vm,
and plan to move storing application packages to Glance, once
Artifact Repository will be available in Glance.
Change-Id: I24b5309a2365495e041155ee2d6799dbf79479d9
Jenkins
Joe Gordon
Dmitri Zimine
Matthew Treinish
Boris Pavlovic
Russell Bryant
Andreas Jaeger
Robert Clark
Jan Provaznik
Thierry Carrez
Monty Taylor
Serg Melikyan
Marton Kiss
Sean Roberts
Yolanda Robla