The tripleoclient command to get the ansible failures using
mistral api has been removed in the dependant patch.
Depends-On: https://review.opendev.org/720345
Change-Id: Ife5c2b41f7cfc48f5b648ea8647457efeaadcacb
This has some useless code that assume we're running mistral
workflows and also we've moved some of other logic to
tripleoclient.
Depends-On: https://review.opendev.org/719386
Change-Id: I54960bd8abc8ad67e08947d5d4900e405c8a401c
This change removes the use of a mistral workflow from our deployment process
which assertains the ansible deployment status. This is being removed because
deployments are not longer executed via mistral so any data provided by mistral
would be wrong.
This change also removes the mistral workflow reference in our documentation
strings so it does not confuse folks maintaining the code.
Story: 2007212
Task: 38962
Task: 38961
Change-Id: I94fed2dd4968879d0ac3ea775dd498de20b78130
Signed-off-by: Kevin Carter <kecarter@redhat.com>
DeployIdentifier needs to be empty if --skip-deploy-identifier is used
otherwise a new identifier is generated and the --skip-deploy-identifier
feature doesn't work, as Puppet and Ansible will be executed on all the
nodes.
Closes-Bug: #1866135
Change-Id: Ib1928b60ba7b03983f303577a53df078d32d2b1b
Historically we've included unused services in all the roles as a way
for users to enable the services for a given role. By default many are
set to OS::Heat::None. For large scale deployments this results in many
extra resources managed by heat.
This change adds a function to look at the resource registry of the
environment and will remove any unused services from the roles data.
Removing these services from the roles data reduces number of heat
resource and hence possibly little deployment time.
Change-Id: I54539f7dd694e0804006470221e55fd3cafea539
Co-Authored-By: Alex Schultz <aschultz@redhat.com>
Co-Authored-By: Thomas Herve <therve@redhat.com>
https://review.opendev.org/#/c/669182/ had removed the workflow
using it. It's not been used anywhere else.
Change-Id: Ie802d6f1137fad816384e2b02dfbb7d21d3bdf18
It includes:
* mistral action for generating clouds.yaml once
overcloud deployment finishes.
* clouds_yaml.py library for generating clouds.yaml
* Moved global vars to tripleo-common constants.
https://review.opendev.org/#/c/664586/ adds the review in
python-tripleoclient to create the clouds.yaml for
overcloud by calling the above mistral actions.
Related-Bug: #1719369
Change-Id: Ie9004222ca5f77031795eaa4b4a757da8b409d05
Signed-off-by: Chandan Kumar (raukadah) <chkumar@redhat.com>
A number of actions still use ProcessTemplatesAction as a base class.
This doesn't make sense in most cases. This is an attempt to decouple
these classes.
Change-Id: I93106288c3f085034efb79a89e01b705f70db6ee
Co-Authored-By: Alex Schultz <aschultz@redhat.com>
This is no longer needed as we've ship keystone v3 by default for some
relaases now. overcloudrc has the same content.
Related-Bug: #1733640
Depends-On: I137e08213ef7f0f49510e2ebc905e351fb25b85a
Change-Id: Iaafef5b49802e1ea25f374014ebf8632ad0bcc31
In python3 we need to make sure our passwords and secrets are strings
and not binary since when we try and json.dumps a dict with binary
values it fails.
Change-Id: I61568e00babcaf3c8106cd71c25bb7f645c9237d
Related-Blueprint: python3-support
To properly handle the differences between python2/python3 we need to
ensure that when we interact with swift and are dealing with string data
that we handle the types correctly. This change adds a swift utils
helper to call to get the string data from an object out of swift. For
example our json and yaml files are all strings so if we try to use
something like json.dumps() from data we pull from swift, it errors
because we're given a bytes like object in python3.
Change-Id: I7996cc08cdd3bddf3f4ba0fb2e48f926f944c0dd
Related-Blueprint: python3-support
Prevent upgrading a stack to a version of tripleo templates or
environment that specifies neutron mechanism drivers that are
incompatible with the existing stack.
Change-Id: I33fafe07326dcff4e4abb856a219d57a4c9699a1
This change fixes KeyError which occurred In case when
config_download_deploy workflow execution is not finished
and the output is empty.
Change-Id: I5cc5731b5dafd753d6bcd5242052e1f08ce0d974
This is useful when deploying a cloud that doesn't use the default
region name.
Change-Id: I21b462f78b32cd334acdf8a5644b70b1f24c8162
Closes-Bug: #1804449
The stack creation and update can fail with validation errors, catch the
errors to propagate them properly to the client.
Change-Id: I6b723b703b5a931851759d71242868394ce00066
Closes-Bug: #1800493
Update the deployment status if needed when retrieving the status. We do
this since tripleoclient does not yet use a single API for overcloud
deployment. Since there is no long running process to make sure the
status is updated, we instead update the status if needed when we get it
with this action.
The logic to update the status is detailed in a comment in the code.
Also as part of this commit the status is kept as deploying in
deploy_play when not triggering config_download, since the client will
trigger config_download on it's own. It makes more sense to keep the
status as deploying in that scenario.
Change-Id: I6d329e974965edf28d6f5b12e6854319cfb683f4
Closes-Bug: #1798193
Retrieving the overcloud stack with its outputs is expensive for Heat,
let's skip it where we can.
Change-Id: Ifacdff939f7a8dedbcf2685595ebeb9340af092a
Since the config-download files are stored per plan name, we don't need
to reach for deployment status object and execution any more.
This change also updates get_deployment_failures workflow to set status
FAILED when an error message is returned from the action.
Closes-Bug: 1779093
Change-Id: I49805f1e2ce845b1cebc04df813261cca12ec431
If a deployment was created before the introduction of config-download,
this workflow can recover this deployment, and transform it into one
that works with config-download.
Change-Id: I83e7329c1e0e7457ab221bc9b92357aed7275548
Implements: blueprint config-download-workflows
Adds a new workflow and corresponding custom action for querying the
ansible failures that occurred during a plan deployment with
config-download.
Relies on the json-error.py ansible callback plugin to provide a
structured data format for the errors.
Change-Id: I16d2dd0b3022cd5964919d07dd0ec603490a3ed7
This is needed to land I2c5b511df50f29c63aa613899c2bebb506360bf4,
see the reasoning on that patch.
This reverts commit 6fa7a0974a.
Partial-Bug: #1771627
Change-Id: Ia86842b0b1f42512f25390d6bdb695e0f8133c6d
This gets a TLS certificate for the overcloud when necessary:
* If no incoming cert/key is provided and we don't expect the
overcloud's certmonger instances to request the certificates,
we request one to the undercloud's certmonger local CA.
* If a certificate was provided, we verify if it's user-provided
or if it was autogenerated.
- If it was user-provided we pass through that certificate
- If it was autogenerated, we request or resubmit the request
if it's needed.
* We also accept the EnableTLS flag, which the deployer can
explicitly turn off if they decide not to use TLS.
Depends-On: Ic70dd323b33596eaa3fc18bdc69a7c011ccd7fa1
Change-Id: I3d3cad0eb1396e7bee146794b29badad302efdf3
Cryptography tools (such as the ones in the cryptography library), read
bytes instead of python strings. So lets read the file as such.
Change-Id: I0853f17c8081934e96e01f05df9ec4c6454c1d8a
This merely breaks the code that sets the default CA in the deployment
workflow to more functions. Preparing for setting the certificate for
the overcloud in a subsequent commit.
Change-Id: I8076604be59878703976380123532e06832ca918
As part of making the undercloud use TLS by default, this sets the
undercloud's CA certificate to be deployed to the overcloud nodes
as part of the depoy workflow. This workflow was used because it
assures us that it's undercloud specific (which might have a different
CA certificate).
Change-Id: I55caee4fc3e04362f8a6f7935d6ad0ea72527b70
If the action fails, it returns an error to be used in the workflow.
While this is useful it means there is little trace of the error in the
log files. Adding the error also to the logs will make it easier to
debug and track down.
Related-Bug: #1734747
Change-Id: I5faba1feec7e87bb595edb3448a096caa0812a9b
This is part of the ongoing change to remove the mistral
dependency from tripleo-common and use mistral_lib instead
In order to do that we are using the Result class from mistral_lib
Change-Id: I59ce8c6d68de9e9719d84cbaa82462fbd8d647e2
Depends-on: Icc0036bae3c969112f2f67c4a8264bae18f3cc73
Start using the plan environment file in Swift for plan environment
storage instead of Mistral.
Add util functions to get/update environment data.
Remove CreatePlanAction and UpdatePlanAction as all they did was
sync between Mistral and Swift environments. Amend the corresponding
workflows to account for removal of these actions.
Implements: blueprint stop-using-mistral-env
Co-Authored-By: Julie Pichon <jpichon@redhat.com>
Depends-On: I3bcef27413e685c498165b43a8b59c8c9cc5cf5e
Change-Id: Ieedecf92113142e43925131dcbccc4c0cd5b1a18
mistral_lib base TripleoAction has a context in the run method
signature. These changes remove the mistral.context and make use
of the one provide by the default executor
Change-Id: Ib1a5aa8d5735b05f5308dc943ac088b5eeeec253
Add a new action argument, skip_deploy_identifier to DeployStackAction.
The argument will disable setting a unique value for the
DeployIdentifier parameter, which means the SoftwareDeployment resources
in the templates will only be triggered if there is an actual change to
their configuration. This argument can be used to avoid always applying
configuration, such as during node scale out.
Change-Id: Idb901a841846fec33d189b3c95f669b0380498ce
The container to store Swift rings is not deleted when the stack is
deleted. This results in re-deploying old rings when deploying a new
stack.
This patch creates a copy of the old rings with a timestamp suffix and
removes the original object. Doing this will create new rings when
creating a new stack.
Closes-Bug: 1671783
Change-Id: Ie6363987ada9b516064c1ed3b215f809c3924393
Some constructor methods were missing the super call to the parent
class. This change adds the missing calls.
Some constructor methods only had the super calls to the parent class,
which makes them redundant. This change removes those methods.
Change-Id: I3bdda1a1f1bcfa19d166b994d3d3ae2218b95c43
The underscore typically designates these methods as private, but
they are intended to be used by any/all of the subclasses. This
change clarifies the API.
Change-Id: I4dc95a0e1f84570b184f8b75f51a2c1456909fb9
This standardises how we create mistral.workflow.utils.Result instances.
Previously we used a combination of passing empty strings or None values
to pass errors only. Using kwargs makes this clearer and cleaner. This
is also means we use the Result class in the same way as the builtin
Mistral actions.
Change-Id: Ic94c0513b1fba030de70263ac1df32b4ab130e9a
This patch reverts the two commits listed below. There was a problem
with CephClusterFSID generation as it was created by the password
generation code in Mistral in Newton. However, this password generation
didn't work for upgrades as it didn't take into account upgrades and
passwords that were in use in an existing Heat stack.
This issue was resolved in I3ea6bbd0d9c5dd345b8a4a26a1788326e09d4209.
Now when a deployment plan is created, if there is an existing Heat
stack it takes the parameters from the Heat stack and uses those, rather
than regenerating. This change should also resolve the issue where the
CephClusterFSID was regenerated.
Revert "Generate CephClusterFSID for new stacks"
This reverts commit 20167e850a.
Revert "Revert "Add CephClusterFSID to generated passwords""
This reverts commit ad64050485.
Related-Bug: #1636555
Change-Id: I10b5613eda4bd47554a4f5e9f57218010b835fe7