This new repository will be the new place to store code related to
StarlingX virtualization packages and tools.
It will be the result of splitting the virt directory from
starlingx/integ in order to separate the virtualization stack from it.
Signed-off-by: Thales Elero Cervi <thaleselero.cervi@windriver.com>
Change-Id: I3195abfc9ef5b156b5a8591b1d6b595c76081658
In prior changes moving to submit-requirements, we standardised on
"NoBlock" instead of "NoOp" because that's what the upstream migration
tools do. But it seems we missed some, correct that here.
This was found by the linter in
I971f626bd7dbee012dc93a5807145d206b645cfd
Change-Id: I557f3615d15eca899a262b0989986fb2754ac870
Prior change Id5157b9f59082485b6aff92c4f3527fb4c8084aa updated the
Review-Priority label; this converts the couple of remaining
AnyWithBlock labels that didn't match the review-priority pattern to
submit requirements.
Change-Id: Id57bdb4f6ed38a90a37a738068446197e6a24769
Similar to Ic43f561174ebf30474b1b54be2bed02695cebedc and
I83160aeec0a450f8678ecb583fb7570ac0e71f4a, this converts the existing
Review-Priority rules to submit-requirements following the gerrit
migration rules from [1].
These are all using "AnyWithBlock" which means that only the lowest
possible vote blocks submission. Thus we replace this with a
submit-requirement of "-label:Review-Priority=MIN". The function is
changed to NoBlock as done by the migration tool.
As with the prior change; the submit-requirement with the same name as
the label will avoid us having migrations run on these ACL's and
keep our gerrit in-sync with project-config.
Also as with the prior change, this should have no affect for users.
[1] https://gerrit-review.googlesource.com/c/gerrit/+/339542
Change-Id: Id5157b9f59082485b6aff92c4f3527fb4c8084aa
Similar to Ic43f561174ebf30474b1b54be2bed02695cebedc, this converts
the existing Backport-Candidate rules to submit-requirements following
the gerrit migration rules from [1].
The function is left as NoBlock, and a no-op submit-requirement is
added with the same name.
As with the prior change; the submit-requirement with the same name as
the label will avoid us having migrations run on these ACL's and keep
our gerrit in-sync with project-config.
Also as with the prior change, this should have no affect for users.
[1] https://gerrit-review.googlesource.com/c/gerrit/+/339542
Change-Id: I83160aeec0a450f8678ecb583fb7570ac0e71f4a
The submit functions are deprecated in Gerrit 3.7 and replaced with
submit-requirements.
This starts at the replacement with ACL's currently using the NoOp
function.
This implements the migrations steps encded with [1] upstream. The
function is changed to NoBlock, and a "non-applicable"
submit-requirement of "applicableIf = is:false" and "submittableIf =
is:true" is added, with the same name as the label.
Since we are matching the upstream rules for idempotence -- a
submit-requirement with the same name as the label, we will avoid
future upgrades modifying our ACL's and getting them out of sync with
what we have in project-config.
From a user's point-of-view, this change itself should be a no-op.
[1] https://gerrit-review.googlesource.com/c/gerrit/+/339542
Change-Id: Ic43f561174ebf30474b1b54be2bed02695cebedc
The NebulOuS project aims to deliver a Meta Operating System and
Fog Brokerage Platform for transient cloud continuum ecosystems. [1]
This patch follows the Project Creator's Guide to create a new
project in OpenDev's collaboratory.
It also creates the project-config repo in preparation for the creation
of a new Zuul tenant: nebulous.
[1] https://www.nebulouscloud.eu/
Change-Id: I369177cd43f92f02a73011b46545210015d5112a
We've decided to add a new group to help manage stable maintenance of
the stable branches in the charms group of projects. Note that
charms-ceph and charms-vault are part of the charms set of projects but
already have slightly different groups of maintainers.
Change-Id: Ibcb89c87a15d72d05b6a9f599aede3a7b60f4df6
StarlingX needs a centralized place to store it's
public keys and certificates, rather than having them
sattered throughout the source code.
Story: 2009221
Task: 47097
Signed-off-by: Scott Little <scott.little@windriver.com>
Change-Id: Ia64a1224b97caa52ee94e072016ae4cde6c7f601
This change should not change any effective permisssions; it's being
pushed in order to create some file churn so earlier ironic-inspector
changes will apply. As a benefit, it also removes redundant things from
config.
Change-Id: I67a5de270a74ae88a4596c41e73dc59955e83439
The copy conditions here have been replaced by the "copyCondition"
query tag. This updates the deprecated values to a new query which
does the same thing -- i.e. this should be a noop.
Mostly these are setup to have votes on labels that should be copied
on a no code change/trivial rebase, and if they're -2/+2 (i.e. max
votes are sticky). To be exact the group of
copyallScoresIfNoCodeChange = true
copyAllScoresOnTrivialRebase = true
copyMaxScore = true
copyMinScore = true
becomes
changekind:NO_CODE_CHANGE or changekind:TRIVIAL_REBASE \
or is:MAX or is:MIN
Note all but ocatvia.conf, octavia-dashboard, octavia-lib, and
python-octaviaclient are copying -2/+2 votes; I feel like this is
probably a bug but I have modified these 4 projects to maintain the
same behaviour of not copying the votes.
A small number of projects copy any vote; glance.config,
kayobe.config, kolla.config, nova-specs.config, nova.config,
os-vif.config, placement.config, python-novaclient.config -- they are
replaced with is:ANY.
The old conditions have been deprecated since gerrit 3.5 [1].
Although the old conditions have not been removed yet, this will help
as we think about also changing these to submission requirements for
Gerrit 3.7.
[1] https://gerrit.googlesource.com/gerrit/+/c429ff33d944272b1f4da9f84f904f6403919ea3
Change-Id: Id13fdf588d07c1fec73978e7a69f1d9097989696
Following the Gerrit upgrade, the release team lost the "PTL+1" column
in the release dashboard, which made it convenient dte screen
ready-to-process changes.
New gerrit only displays "required" labels. This change makes PTL+1
blocking in case the lowest negative value is selected (AnyWithBlock),
while defining a negative value that nobody can actually set.
Change-Id: Idbf614be4b88db56258ed3b0e7725b581196a6fb
Ironic bugfix branches are not fully supported by release tooling.
Instead, we have to grant ACLs directly to a subset of Ironic cores to
allow them to tag bugfix-[]-eol and delete the related branches.
For more information, see the Ironic meeting log from when this was
discussed: https://meetings.opendev.org/meetings/ironic/2022/ironic.2022-12-05-15.01.log.html#l-50
Change-Id: I42ab660b8e3d5effae52db6c88b858213f0b0d5a
WIP state in Gerrit is tricky and has side effects a lot of new
contributors might not expect it to completely remove their patch
from the dashboards. In those cases; it's nice for a core to be
able to toggle the wip state.
Change-Id: I255a9c7070c268f48504f688a25e4de79a8b158b
The kolla project has decided that it no longer needs to have a
dedicated kolla-ansible-core group that is different from the kolla-core
group. Membership between the two groups has already been synced, so
this change is essentially a no-op, but allows us to only maintain a
single group going forward.
[0] https://meetings.opendev.org/meetings/kolla/2022/kolla.2022-11-23-14.00.log.html
Change-Id: I1dc5e5ed9f93ad40f2089891c63b530994b290f2
WIP state in Gerrit is tricky and has side effects a lot of new
contributors might not expect it to completely remove their patch
from the dashboards. In those cases; it's nice for a core to be
able to toggle the wip state.
Change-Id: I88e5e0df93b20ebf0db7e10462af051526541780
WIP state in Gerrit is tricky and has side effects a lot of new
contributors might not expect it to completely remove their patch
from the dashboards. In those cases; it's nice for a core to be
able to toggle the wip state.
Change-Id: I5ed45854166e6a56be49034fc142b6c015fe6745
The Charms team would like to enabled passive voting on patches
for backport candidates. This means that backport candidate votes
will not block a patch from merging, but will allow the team to
better track patches that should be backported.
Change-Id: I00e701c7763e91e54f4a7b40442b213e09c5c644
In order to implement post-check pipeline for dealing with secrets in
the check pipeline it is required to add additional flag to gerrit that
will be set as a prerequisite to start jobs.
Change-Id: I3f0d7fe7e0014c28465aaab060e74e39a527b745
The STS-Silicom app is intended to be used to configure
PTP/SyncE configurations on certain NICs from the Silicom
vendor.
Story: 2010213
Task: 46215
Signed-off-by: Steven Webster <steven.webster@windriver.com>
Change-Id: Ie6bf611af6f6e61aefd54dbfeed61896c98b437b
Currently the value persists only if it's the max or min, and only
when there are no code changes or if it's a trivial rebase.
The behavior we'd like is that the assigned priority should persist
across the series of patch sets, even if there are code changes,
because this label indicates the relative importance of getting eyes
on the review, and is not directly involved in the code being approved.
A -1 Review-Priority ("Branch Freeze"), in addition to being sticky,
will continue to block submission of the patch.
Change-Id: Iee323ab80f9a58bf49827c23934560edfad57bf3
This project will contain whitebox neutron related tempest tests useful
for the Tripleo based deployments, which don't fit well into official
neutron-tempest-plugin repository.
Change-Id: Ie0c7bc4558e4e73910664b6796d5ada7848bf5d2
In order to filter some potentially problematic content from the
x/stackalytics repository's master branch history, grant its
maintainers permission to push --force that rewrite including
changes from other committers and merge commits.
Change-Id: I0b7fc39fb422f89a04ec926607619c3418016787
This change updates the defintion of Review-priority
to match the new defintion in our contrib docs.
Change-Id: I2b172439e959753b6a62483703bfa8bd93175187
Thales Elero Cervi