This reverts commit 48a02a308e73eb0c2fc57c758b23e1b1c25f66bb.
Reason for revert: For the current election cycle Z we
have a candidate who wishes to run for PTL. As a result,
keystone will look to switching back from the DPL model
back to PTL driven.
Change-Id: I673e7bfd360b438abb2fd7f66b32c225c566c4d1
The security-specs repo is slated for retirement[0] as per the
security-sig. This change removes the security-specs repository
from the list that is currently maintained by the security-sig.
Change-Id: I6642ab3e6b40f0565521455907beb08d3752eb70
This charm implements a nimblestorage backend for cinder, acting as
a subordinate charm.
Depends-On: I93aa9fe3ab089bbeae2b87881bfc931f4ddf0204
Change-Id: I25f5c4e5a209e77352a449129895cd33935190cc
Due to a shift in my priorities and being unable to dedicate
enough time, I am transferring the PTL role to suzhengwei.
suzhengwei has been lately the main contributor to the Masakari
project, working on the major features that were introduced in
the last few cycles.
I have already obtained his approval by mail.
Do note his contributions so far were using a different mail
address (sugar-2008@163.com) but I have been asked to use the
Inspur one as it is currently preferred.
Change-Id: I3744b19e91c90ef46f2855c810f40f61ffb8a9a2
This charm implements a solidfire backend for cinder, acting as
a subordinate charm.
Depends-On: I523074a9578bf5f327608de0a4144a0597a65287
Change-Id: Ia0b48d3e399965a6e138ea18c447eafd6009385c
Skyline is an OpenStack dashboard optimized by UI and UE.
It has a modern technology stack and ecology, is easier for
developers to maintain and operate by users, and has higher
concurrency performance.
Here are two videos to preview Skyline:
- Skyline technical overview[1].
- Skyline dashboard operating demo[2].
Skyline has the following technical advantages:
1. Separation of concerns, front-end focus on functional design
and user experience, back-end focus on data logic.
2. Embrace modern browser technology and ecology: React, Ant Design,
and Mobx.
3. Most functions directly call OpenStack-API, the call chain is
simple, the logic is clearer, and the API responds quickly.
4. Use React component to process rendering, the page display
process is fast and smooth, bringing users a better UI and UE
experience.
At present, Skyline has completed the function development of
OpenStack core component, as well as most of the functions of
VPNaaS, Octavia and other components.
corresponding automated test jobs[3][4] are also integrated on
Zuul, and there is good code coverage.
Devstack deployment integration has also been completed, and
integration of kolla and kolla-ansible will complete pending
patch[5][6] after Skyline becomes an official project.
Skyline’s next roadmap will be to cover all existing functions
of Horizon and complete the page development of other OpenStack
components.
[1] https://www.youtube.com/watch?v=Ro8tROYKDlE
[2] https://www.youtube.com/watch?v=pFAJLwzxv0A
[3] https://zuul.opendev.org/t/openstack/project/opendev.org/skyline/skyline-apiserver
[4] https://zuul.opendev.org/t/openstack/project/opendev.org/skyline/skyline-console
[5] https://review.opendev.org/c/openstack/kolla/+/810796
[6] https://review.opendev.org/c/openstack/kolla-ansible/+/810566
Change-Id: Ib91a241c64351c5e69023b2523408c75b80ff74d
Community-wide goals are not coupled with cycle so
this commit adds a clarity on slected goals are Active goals
even they are targetted for more than one cycle.
Change-Id: I900a3912dd2e78fa5b267512e0f817db8bda1ec2
After the discussion on ML [1], it is not recommended
or best way to drop the py3.6 in Yoga, and keeping it
will help in migration from old (having py3.6) to new
distro (moving to higher python version) versions. For
example, Ubuntu 18.04, CentOS Stream 8 still have 3.6.
CentOS Stream 8 and CentOS Stream 9 both will support
Yoga so we need py3.6 to be tested for a smooth migration.
Considering all these factor to provide a smooth
migration to new python version, TC discussed it in today's
meeting [2] and agreed to keep Python 3.6 testing in Yoga.
We will add CentOS Stream 8 and 9 both with python 3.6 as lowest
and python 3.9 as highest version to run unit tests.
[1] http://lists.openstack.org/pipermail/openstack-discuss/2021-November/025988.html
[2] https://meetings.opendev.org/meetings/tc/2021/tc.2021-12-02-15.02.log.html#l-33
Change-Id: I2d242ac161b19b7615c667f0f7b56826dd1029d8
Co-Authored-By: Radosław Piliszek <radoslaw.piliszek@gmail.com>
Add new charm that provides the NVidia vGPU support
to the OpenStack Nova service.
Depends-On: I77e0823d405280a0a067eacb2ab03571c8db7fb4
Change-Id: I45b09e63bb6d8674f61dcc4a3a60952d9465ddf9
As per the new structure of community-wide goal[1],
we will keep all the completed goals into separate
directory 'goals/completed/' which will help to
track the goals and a clear view on what all goals
still need more work.
Keeping 'Migrate from oslo.rootwrap to oslo.privsep'
goal in the selected directory only as this still need to
finish the work. Rest all previous cycle goals are moved
to 'goals/completed/' directory
[1] https://governance.openstack.org/tc/goals/#completing-goals
Change-Id: I6c0d979038f65abb091db646ddb4c0d09c43735a
RBAC goal has been reworked and has clear direction now.
As per the new structure of community-wide goals, goal
will not be associated with any cycle release but will have
different milestones. This goal has defined the different
milestones to complete the work.
Change-Id: I52744507cf5be6e47e96c69af4300cb84018c2e9
The Yoga PTG shed a lot of discussion on the useage of system scope and
default roles.
The yoga community goal is still useful, but the discussions highlighted
some confusion in the current approach. We should update the goal to be
consistent with the discussions from the yoga PTG.
This goal is divided into phases spanning the next few development
cycles.
Co-Authored-By: Ghanshyam Mann <gmann@ghanshyammann.com>
Change-Id: I061994e17bd96ace9e3d2040d342b71d3add99cc
