Spec: triple-routed-networks-templates Refactor THT for routed nets.
This spec describes the problem set and work items to implement support
for routed network deployment with TripleO Heat templates. For routed
networks, we will need to support an additional layer of abstraction
for isolated networks, where there are multiple broadcast domains, each
with their own VLANs. Separate VLANs with routers connecting them
allows for horizontal scalability and reduced broadcast, multicast and
unknown unicast traffic within each VLAN.
This is a dependency of blueprint tripleo-routed-networks-deployment
Change-Id: I50dab467fde8a1e62ab0b24ce12d639d72dd692b
Provide a common, unified validation framework inside tripleoclient.
This resubmits Iffaa3c99ac401626c70211437dd98f214b4973e4 previously
merged too fast.
This reverts commit 20fc7a387af043809ec96a6ac1c3bac29f60516b.
Blueprint: validation-framework
Change-Id: Ib99f82227d045c07d1e8b602627c8bcd6a88114c
Utilizing the standalone installer to better test the upgrade
tasks within existing ci wall-time and nodes.
As part of Stein PTG discussion [1] it was decided that the
approach outlined here will be one of two main streams for
upgrades CI in S. This for testing service upgrade_tasks
and another stream for testing the workflow. That latter
workflow stream is not considered here.
[1] https://etherpad.openstack.org/p/ptg_denver_2018_tripleo_ci
Co-Authored-By: Jiri Stransky <jistr@redhat.com>, Athlan-Guyot sofer <sathlang@redhat.com>
Change-Id: Ic8a8867018c6fb866856a45a2bf472a0ed65d99b
This is a mechanically generated patch to complete step 1 of moving
the zuul job settings out of project-config and into each project
repository.
Because there will be a separate patch on each branch, the branch
specifiers for branch-specific jobs have been removed.
Because this patch is generated by a script, there may be some
cosmetic changes to the layout of the YAML file(s) as the contents are
normalized.
See the python3-first goal document for details:
https://governance.openstack.org/tc/goals/stein/python3-first.html
Change-Id: I052f587922176126e25bced35d3108425a70e798
Story: #2002586
Task: #24341
I mistakenly merged this spec and it needs further discussion.
This reverts commit 05b5288b286a52386d4f1fff1665355265167404.
Change-Id: I173bb6242070f280b2b4c88c8c1afe44f14aa62c
It happens that we overlook the upgrade impact of some new
features. Add Upgrade impact section to the spec template to make us
think about how do we upgrade to some feature when proposing that
feature.
Change-Id: I137a4353ce73ae961e83ecd656df77d6bd45a4e4
According to Openstack summit session [1],
stestr is maintained project to which all Openstack projects should migrate.
So we should switch to stestr.
[1] https://etherpad.openstack.org/p/YVR-python-pti
Change-Id: Ib6985475a257570c2df000dfcabb8600afc11f4f
We want to default to running all tox environments under python 3, so
set the basepython value in each environment.
We do not want to specify a minor version number, because we do not
want to have to update the file every time we upgrade python.
We do not want to set the override once in testenv, because that
breaks the more specific versions used in default environments like
py35 and py36.
Change-Id: I145e928c29c7e496112c680db54cd8412b2fd0a6
In order to avoid a widely open sudo for a bunch of
users, we must take care of the way privilege escalation
is done in our python script as well as shell calls.
This spec takes care of the "python" aspect of this issue.
Change-Id: I24f373ffbbda09bd5247f29b6b38ce4bd18fccb3
Co-Authored-By: Luke Hinds <lhinds@redhat.com>
Blueprint: improve-privilege-mgmt-in-tripleo
First phase of a multi-cycle spec explaining the requirements for
deploying a controlplane, then batches of compute/storage nodes
independently for scaleout.
Co-Authored-By: John Fulton <fulton@redhat.com>
Change-Id: Ib3511fc2f611e944143035f70e146234ed7a7204
An IRC conversation/question showed that the current wording of the
policy can be misinterpreted to mean that permission must be asked
before restoring a patch. This patch aims to make it explicit that it
is not the case.
Also fix a couple of typos.
Change-Id: Iaf78eedd5e6367bed476e7d4253bbb834ec42bfd
Adding new validations or consuming the latest ones is inconvenient and
error-prone in the current setup.
Co-Authored-By: Ana Krivokapic <akrivoka@redhat.com>
Change-Id: I7f0c951ec5207d1c8f2a2c871983512cf3c0fee5
