The repo devstack-plugin-container is a devstack plugin for
installing container engines such as Docker. This plugin is
currently used by a few official services such as Zun,
Kuryr-libnetwork, Kuryr-kubernetes, and Fuxi. This patch proposes
to include devstack-plugin-container as a deliverable of QA team.
Change-Id: I474bf587c0a9c9c560fbe4fde108940df379e863
Qinling aims to provide "Function as a service" in OpenStack. Qinling provides
a platform to support serverless functions (like AWS Lambda) by leveraging the
container orchestration platforms (Kubernetes/Swarm, etc.) and different
function package storage backends (local/Swift/S3) using plugable mechanism.
Project History:
As an OpenStack based public cloud provider in New Zealand,
Catalyst Cloud[1] helps most of local enterprise customers to innovate by using
and contributing lots of OpenStack projects. From the feedback and requirements
of our customers, FaaS is one of the most wanted services. After evaluating the
existing open source projects, we decided to create a new project in OpenStack
and started development from the April of 2017. We also did several successful
POCs during 2017 after the first alpha release. In Sydney Summit, the project
was first introduced to the whole community[2].
As most of the engineers from Catalyst Cloud development team are active
and experienced contributors in OpenStack upstream, the project developement
process aligns with the OpenStack upstream convention from day 1. What's more,
as an OpenStack project, we are trying to integrate with other OpenStack
services as possible as we could, e.g. Qinling uses keystonemiddleware for
authentication; supports functions to be stored in Swift; in the function code,
the developers can easily interact with other services without explicitly
providing and storing their own OpenStack credentials; Qinling supports webhook
URL for functions that can be used direclty in Aodh or Zaqar, etc. Most
importantly, Qinling doesn't rely on any commercial product for its
implementation.
Satisfaction of new projects requirements:
* Open Source: All Qinling source codes, specifications, and
documentations are use Apache License 2.0. All the library dependencies
come from the global requirements file of openstack/requirements repo.
* Open Community: I myself am current PTL of the project and will continue
working on it almost full time. Although we don't have weekly irc meeting
yet, #openstack-qinling IRC channel is always open for anyone to interact
with Qinling team. I keep sending the project update email by-weekly in
openstack-dev mailing list[3][4]. After the Qinling presentation in Sydney
Summit, there are more and more developers showing interests to the project
by contribution[5].
* Open Development: Qinling uses Gerrit for code reviews and Launchpad
for bugs and blueprints tracking[6]. The project is integrated with the
Openstack CI, and runs pep8, py27 and functional jobs. Qinling is implemented
using libraries and technologies adopted by other existing OpenStack projects.
* Open Design: Currently, all the features and bugs can be found in Launchpad,
any feature requests are welcomed. As I mentioned, we also use openstack-dev
mailing list for discussion about anything related to the project.
The Qinling team is happy to participate in any goals specified by TC, and meet
any other policies that the TC requires.
[1]: https://www.catalyst.net.nz/catalyst-cloud
[2]: https://youtu.be/NmCmOfRBlIU
[3]: http://lists.openstack.org/pipermail/openstack-dev/2017-December/125413.html
[4]: http://lists.openstack.org/pipermail/openstack-dev/2018-January/126018.html
[5]: http://stackalytics.com/?project_type=openstack-others&metric=commits&release=all&module=qinling
Change-Id: I5fe1ff0067d4df12b2d05da0f7bc723da24e5975
Release naming polls originally were conducted as public polls
in Launchpad (requiring only a Launchpad account). Then we moved
to CIVS-driven Condorcet polls, with personal voting links to
all Foundation members (requiring a Foundation membership to vote).
Due to limitations in the CIVS service, it's currently not practical
to send Condorcet voting links to every Foundation member. Instead
we'll use the public voting feature of CIVS, and allow anyone with
the link to cast their vote.
That opens the vote to ballot stuffing, but the choice is not that
critical, the proposed names all follow strict criteria, and there
are many safeguards in place to exclude bad names (from a legal or
marketing standpoint). So it feels safe enough to use public voting,
originally disseminating the voting URL through the openstack
mailing-lists.
Change-Id: I2f4b7fb24ccfb54403d0dedc0a757af3c6769d61
n-g-s recently was added under Openstack baremetal program
Ie08c9ef029e29845c766d9c10329817124954e16
This patch adds n-g-s tempest plugin under baremetal program too.
Depends-On: Ia8a5b7244a76983a5940ae294ea773004db0645e
Change-Id: Id6868b54b236aa0f4a6062c1fd4340179e33b3a7
tempest-stress is to perform stress testing of cloud using tempest.
This framework used to be in tempest earlier but due to tempest scope
it had been moved out of tempest tree. During queens PTG (even earlier)
we discussed to make it in separate repo.
Depends-On: I063303642f5c99e4ca95d0e02c2360a003688ad6
Change-Id: Ib6fb2eac8568f6e86aae24782bfa6d9cca4fe54c
Use an ordered dictionary loader to maintain the order items appear in
the projects file so we can produce them in the same order in the
output.
Change-Id: I96707f96056cc94a34cf9f4b9edfb73f42f7bb27
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
* https://review.openstack.org/#/c/531138/ moves the bundled
in tree tempest plugin to blazar-tempest-plugin repo.
Change-Id: I2078cc5e1da38e68c6e77ce93ed10581521cd536
