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
As we meet every week, we do not need separate office hour as such.
And with the office hour mostly inactive, in TC meeting[1], we decided
to remove it for now. If meeting time change to monthly or so then
we can re-add the weekly office hour.
[1] https://meetings.opendev.org/meetings/tc/2021/tc.2021-11-04-15.02.log.html#l-24
Change-Id: I283eace0e1805c567082017af1ce8b68c5b8d88e
This module has been incomplete and doesn't support very fundamental
resources like packages, services and so on. Because we haven't seen
any effort to complete its implementation for a long and we have
received no objections to dropping the module[1], I'd propose retiring
this module from Puppet OpenStack now.
[1] http://lists.openstack.org/pipermail/openstack-discuss/2021-November/025655.html
Depends-on: https://review.opendev.org/817327/
Change-Id: I2f84a5484e5ab602fe91ba5ac7d811255f33645a
We aim to switch balancing of MariaDB that is part of the deployment
to ProxySQL and want to make a separate role for that which could
be also used outside of the OSA.
Depends-On: https://review.opendev.org/c/openstack/project-config/+/817271
Change-Id: I87f9978cbbc1bfc664828b7b674efe96690654b3
As discussed in Yoga PTG[1] and centos stream 9
is released, we are updating Yoga testing runtime with:
- Add Debian 11 as tested distro
- Change centos stream 8 -> centos stream 9
- Bump lowest python version to test to 3.8
and highest to python 3.9
[1] https://etherpad.opendev.org/p/tc-yoga-ptg
Change-Id: I2fb3a1daa5ee812ea45bab0c2fb7c0997dc2d116
Since a couple of series those oslo projects produce
independent deliverables not synched with the coordinated
series, de facto, they are branchless projects.
I don't think is it possible to follow the stable policy
without related stable branches.
The independent deliverables aren't compatible with this
policy.
Also we should notice that keeping these deliverables
under the stable policy umbrella mislead downstream
maintainers. Removing them inform maintainers to stick
to the upper-constraints available for a given series.
Change-Id: Ia9b96932a7f7712bee9c1c833539cfe32c44bd35
