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
Adding Spec file for adding ovs-hw_offload functionality to tripleo.
This functionality is already available from the Pike release in
Open Stack.
Herein this specification tries to capture what we need to do to
get this functionality within tripleo
Change-Id: Iffb9e5eaa9be751fdbca5f20a6750c1b24da1fec
This spec introduces support for a time synchronization
method called PTP (defined in the IEEE 1588-2008) which
provides better time accuracy than NTP in general. With
hardware timestamping support on the host, PTP can
achieve clock accuracy in the sub-microsecond range,
making it suitable for measurement and control systems.
Change-Id: I3e5cc2e854eb8e0374e36640816dcdb5fc8a773f
Fast-forward upgrades are upgrades that move an environment from release
`N` to `N+X` in a single step, where `X` is greater than `1` and for
fast forward upgrades is typically `3`. This spec outlines how such
upgrades can be orchestrated by TripleO between the Newton and Queens
releases.
Change-Id: I7a422f2355b63dde788207d6ff388f6bee594b33
This specification is to allow for the separation of RPC and
Notify messaging backends. Builds upon capabilities that were
added in the Pike release.
Change-Id: I07ed146d86698ecbb12324cea534aef7ff163628
We need a formal way to track and be able to report when we do things in
code or during the cycle that should or need to be fixed later. Without
a unified policy to do this, it's hard to really understand where all
the tech-debt lives. Given the size of tripleo there is already a lot
of existing and undocumented techdebt but there's no reason why we
cannot start tracking it now to make sure we do not continue to add to
the work.
Change-Id: I7d5a7920a14324670d94034a97160189cb7fe891
This transitions from Pike to Queens.
Change-Id: I7726262530df377374553086e7856be1c530fcf7
Co-authored-by: Andrew Beekhof <abeekhof@redhat.com>
Co-authored-by: Lars Kellogg-Stedman <lars@redhat.com>
Co-authored-by: Perry Myers <pmyers@redhat.com>
Co-authored-by: Peter Portante <peter.a.portante@gmail.com>
Co-authored-by: Rich Megginson <rmeggins@redhat.com>
Signed-off-by: Bogdan Dobrelya <bdobreli@redhat.com>
Proposed specs will never be published in this doc, so the title
should be "Approved". In addition, two Pike entries were added
at some point so the one that is out of order is removed.
Change-Id: I1a39c645135a1f87b5cb6ebe3f9ac1bec34ae071
Adding deployment-time to track bugs that affect the Deployment time, so
we can easily list all of them and create some working group working on
this topic.
Change-Id: Ibaf0f349f1f4185f03134c92eb92211727ebd3ec
Interested people should be able to receive tempest report by mail
containing information about TripleO periodic jobs running tempest.
Change-Id: Ib3c364bd4db57f9ac73aa71c55ffb7e959968133
With the introspection data of the nodes available, it is possible
to run pre-calculated formulas, to derive the deployment parameters
to ease the deployment steps for complex features. Mistral workflow
is used to create this formulas. This spec explains all details
around it.
blueprint tripleo-derive-parameters
Co-Authored-By: Saravanan KR <skramaja@redhat.com>
Change-Id: Id49af12ae9943f0c2907e44c9647d557743b205f
In order improve general housekeeping, we should establish a policy for
handling stale patches that continue to sit for the TripleO projects.
Change-Id: Ie3920b1762a6ec8aa88a8eb7511951da9eae1bbc
Co-Authored-By: Ben Nemec <bnemec@redhat.com>
Proposes the use of Mistral to trigger Ansible playbooks provided
by the Ceph community project ceph-ansible in order to provide an
alternative method to deploy and manage Ceph with TripleO.
Change-Id: I100ae3311540f4fb234c12f71d31aef341bbe6d9
A common tool to generate sample Heat environment files would be beneficial
in two main ways:
* Consistent formatting and details. Every environment file would include
parameter descriptions, types, defaults, etc.
* Ease of updating. The parameters can be dynamically read from the templates
which allows the sample environments to be updated automatically when
parameters are added or changed.
Change-Id: I9104f1abe2a5f0aaf68d927c8716bee4bc85a41e
New CI jobs need to be added following a specific process in order to ensure
they don't block patches unnecessarily and that they aren't ignored by
developers.
Change-Id: I1cf1964c221819e9ad3da661d0423bd0885ce9ba
Introduce a composable service to manage AIDE and ensure
the AIDE package is installed, create rule entries and populate a cron
job to allow a periodic check of the AIDE database.
AIDE (Advanced Intrusion Detection Environment) is a file and directory
integrity verfication system. Security Frameworks such as DISA STIG /
CSI require that AIDE be installed and configured on all Linux systems.
Change-Id: I7b84df3a51c4309b2d4856072205e6eb64402da8
We have been gradually moving all of the bugs from
lp/tripleo-quickstart to lp/tripleo with the quickstart tag. We
didnt ever actually add it to the official tags though.
This patch fixes that.
Change-Id: I4acf7d0e6082ac899d5028db70eebb0f28d98733