The chair is responsible for making sure meetings are held
according to the rules described in our charter, and for
communicating the decisions taken during those meetings to the
Board of Directors and the OpenStack community at large.
Change-Id: I8cf96ee2928f99e3fea8ff4e8a66f26fc8bcd16c
There is no reason to hold off on naming releases one we know their
location. And holding off on release naming is more likely to create
confusion where the dev community just picks a placeholder, uses it in
communication, and that placeholder is wrong later.
Especially as projects are now moving into a phase of planning for
multiple releases in advance for larger efforts, the current
restriction just adds confusion and cleanup work later.
Change-Id: Ife143447ff4a6d2d85260fd9d889853863eff272
There has been some concern voiced over the ambiguity of the language
used in this resolution. Concerns were brought up about whether new or
existing contributors will now need to sign a CLA or alter workflow. It
is my understanding that this is not the case.
To make this clear, I propose adding this unambiguous writing to the
resolution.
Change-Id: Iac0f87678479e694350cccfb9bb87ce3bb946ff6
Following the directive
http://governance.openstack.org/reference/new-projects-requirements.html
OpenStack Mission Alignment:
The Astara project is to provide an integrated network service orchestration
for connecting and security multi-tenant OpenStack environments. Astara
provides deployer configurable multi-provider orchestration for Layer-3 through
7 network services (e.g. load balancing, routing). Astara (formerly called
Akanda) was designed from the beginning to integrate with OpenStack and further
OpenStack's mission. Astara features a driver based orchestrator to
orchestrate network functions from different providers on bare metal,
VMs and containers. All core members have served the OpenStack community in
many ways such PTL, Stable Release management and critical 3rd party library
maintainers. Astara has been open source and in production since Grizzly.
Following the 4 opens
Open Source:
Astara uses the open source Apache v2.0 license. Astara does not have any
library dependencies that would restrict how the projects may be distributed
or deployed.
Open Community:
The Astara leadership is chosen by the contributors of the project. The current
PTL is adam_g. The Astara project has regular IRC meetings
https://wiki.openstack.org/wiki/Meetings/akanda and
everything is logged http://eavesdrop.openstack.org/meetings/akanda
Open Development:
- All code reviews are through the OpenStack infra CI
https://review.openstack.org/#/q/status:open+project:stackforge/akanda-appliance+OR+project:stackforge/akanda-appliance+OR+project:stackforge/akanda-rug+OR+project:stackforge/akanda-horizon+OR+project:stackforge/akanda-neutron,n,z
- Astara has core reviewers
https://review.openstack.org/#/admin/groups/682,members and
gate tests.
- The Astara PTL acts as the liaison for cross-project teams
- Astara collaborates with the OpenStack projects Oslo and Neutron.
- Astara will contribute to Oslo as the opportunities arise.
Open Design:
- Astara started holding public design meetings at the Kilo summit and
will continue to do so.
- The policy of the Astara team is to use IRC and openstack-dev ML to discuss
design. At this time, the public IRC channel, Launchpad and Gerrit are
the primary locations where discussions occur.
Basic OpenStack Project Interopability:
Astara is compatable with OpenStack project APIs and reuses Oslo.
Common Questions:
Why is there a project name change?
The Astara team choose to select a new name to create a clear distinction
between entities providing commercial services and the project itself.
The new name was selected to further our original intent in placing this
project under governace -- a team open to all contributors.
Why not the Neutron stadium?
The Astara team is concerned our setup will create an additional burden
on the Neutron team due to the differences relative to other stadium
projects.
- Astara currently has 3 respostiories for code that are designed to
integrate with projects other than Neutron and 1 Neutron driver repo. The
current Neutron Stadium members have only 1 repository each and the repo
directly integrates with Neutron.
- Astara provides a sepearate management cli and RPC API not connected to
Neutron REST API. Our tenantative plans for the upcoming cycle includes
expanding the capabilities of the administrative cli tools and API.
- Astara via the driver model is capable of orchestration and
management of services where the Neutron API is not available to
tenants. The team plans to investigate this further during the next two
cycles.
Does Astara overlap with existing projects?
Astara implements network specific orchestration for logical resources managed
by tenants via the Neutron API, so it is natural for overlap to exist with
other implementations that provide load balancing, routing and/or VPN. Astara
is different from other projects currently under the OpenStack namespace
because it supports orchestrating a mix of Layer-3 through 7 network
functions via baremetal, VMs and containers from within a single service. Where
possible we've reached out to other projects to share code, exchange ideas
and explore joint development. The Astara team has been present online
and at the Neutron and Advance Service mid-cycles for the previous two years
to promote a close working relationship with the community.
Active Team of Contributors:
Astara has an active group of contributors
http://stackalytics.com/report/contribution/akanda/180http://stackalytics.com/report/contribution/akanda-rug/180http://stackalytics.com/report/contribution/akanda-appliance/180http://stackalytics.com/report/contribution/akanda-horizon/180http://stackalytics.com/report/contribution/akanda-neutron/180
Change-Id: I7ddb84c011cb933e2d30caacaaf423887b389e22
this adds ollows-standard-deprecation tag to Ceilometer as
Ceilometer already follows a 2 cycle deprecation period on major
features.
this is not applied to Gnocchi or Aodh as they do not have
intermediary releases.
Change-Id: I8d3cb91d66225063f6a432cc44bcf14213c8f789
Historically, ironic-python-agent has always recommended deploying from
master branch. However, we realize that actual releases and stable
branches bring value to some folks. So, this commit:
* makes IPA managed by the release team
* makes IPA do intermediary releases with a coordinated cycle release
* makes IPA do stable branches
Change-Id: I04a8242692831a054430f763414c3a38cba46617
The recent application by the Kosmos project [1] prompted a discussion
on whether or not a project should apply to the TC right away or if it
should have some amount of history of operating as an OpenStack project
first. The consensus on that application was that we should wait and
let the project get going first.
This patch updates the new projects requirements to clarify this point.
As noted by ttx on [1], this guideline will henceforth be known as
"the Kosmos jurisprudence".
[1] https://review.openstack.org/#/c/223674/
Change-Id: Ifc964d09ea2107e3ecd95f9579543bcb77f457d0
Signed-off-by: Russell Bryant <rbryant@redhat.com>
This patch adds the openstack-ansible-security repository into the
openstack-ansible 'big tent'. This will be an Ansible role which
deployers optionally choose to consume.
Change-Id: Id98ece8943f52fe7acca45811412872d7f19e2a7
Depends-On: I89cd1367b13c8b85b4e76ab8281c15dbae571c01
Over the liberty cycle MagnetoDB had 6 commits, 3 of which were
procedural. It had 14 reviews. It now has no PTL candidate. While
the effort on the project was appreciated, it is clear that the project
has joined burrow and melange in the realm of projects of yesteryear.
In addition to removing the project from the reference, the MagnetoDB repo
should receive a commit that deletes all the content and replaces it with a
README file that indicates the project has retired.
Change-Id: I6cc8de967bcbe021abb16384abb8faa32de1edc9
puppet-openstack_spec_helper will be a Gem library consummed by Puppet
OpenStack modules.
It will be first use to put common code used to configure beaker-rspec
but it could become later a common library used by our modules to
realize common tasks specific to OpenStack CI.
Change-Id: I1e0ae76f4e2a2d88c2daa7918b79eebe3e0010d0
renderspec is a new tool that renders generic RPM .spec templates into
distribution specific .spec files to build packages from.
This way, we can share one package dist-git between different RPM
distributions.
Change-Id: Icacedc575c090ab1fdb8c8952e17328b146f32bb
pymod2pkg is a simple python module used to translate upstream python module
names to corresponding distribution package names.
Change-Id: I2afab698426791c8063c2ea29040f7dc11b7e744
