As discussed in the Liberty Design Summit "Moving apps to Python 3"
cross-project workshop, the way forward in the near future is to
switch to the pure-python PyMySQL library as a default.
https://etherpad.openstack.org/p/liberty-cross-project-python3
Change-Id: I5d2a9ec4cd52b81b715003e58e593f8395e66959
Some parameters like ServiceNetMap are defaulted in the master_seed
template. If there is no default set for this parameter in any of
the role templates where it is used, propagate the default value
from the master_seed to that role (overcloud-without-mergepy.yaml).
The default value is also included in the environment file
Change-Id: I1ff97ccabf6be6afba03fc08f817c0d98f554ed2
This is mostly for development purposes, but when working on the TripleO
Heat Templates, it's common to flush out all of the existing roles from
Tuskar and load in the changed ones. It was tedious to do when
specifying all of the UUIDs, so this is provided as a shortcut.
Change-Id: Ib8063eb7aa737a71b208a142318ea62c02b039a7
generate_sample.sh fails if MODULEPATH is already set. This fix was
adapted from a change in nova: https://review.openstack.org/#/c/168745/
Change-Id: I2b0b52b5d71157a42028d95d84e36eeb0fe3016d
The Oslo libraries have moved all of their code out of the 'oslo'
namespace package into per-library packages. The namespace package was
retained during kilo for backwards compatibility, but will be removed by
the liberty-2 milestone. This change removes the use of the namespace
package, replacing it with the new package names.
The patches in the libraries will be put on hold until application
patches have landed, or L2, whichever comes first. At that point, new
versions of the libraries without namespace packages will be released as
a major version update.
Please merge this patch, or an equivalent, before L2 to avoid problems
with those library releases.
Blueprint: remove-namespace-packages
https://blueprints.launchpad.net/oslo-incubator/+spec/remove-namespace-packages
Change-Id: Id25875f3ef51c2b84cf2b9362039a5196feaa531
Though constraints and type are both plumbed into the parsing
and storage models, for some reason these were not being captured
in the generated Plan object returned to the client. This adds
those missing attributes of Plan parameters. Also updates the
docs to reflect the "new" attrs
Change-Id: I138818daef38f084acd6e2250986351352b3835d
When loading the seed, resource registry entries referencing other files
was recently added to the final environment. However, other aliases were
skipped and this should not be the case.
The test_load_roles is the primary verification, but having another
example in the test_parser is helpful for awareness.
Change-Id: I28c8175140f45a1769eb372edcffb3f78bdd780f
Now that we have decoupled the Role name from the name of the file that
defines it, there is no longer a link between a Role and the resource
registry type that it defines. For instance, there is no link between
'Compute' and the relevant entry in the resource registry:
OS::TripleO::Compute: puppet/compute-puppet.yaml
When loading the role, capture its file as part of the Role object so
that we can dereference the Role name against the resource registry,
regardless of name.
Change-Id: I0d36355dbf4e296584d05bf5a137926f85a78b43
In aa754741a3, the -servers suffix was
dropped, so the name used from the resource group (for example in the
seed template) needs to also drop the suffix.
Have grepped the source for any remaining "-server" strings, so I think
this completes the transition.
Change-Id: I0366953e1186c0aeddf1cfbf5814c6fdf4312279
The parameter default value was not properly being used upon copying
to the environment, resulting in an empty string rather than an empty
list.
Change-Id: I4cf0f29e01661f3059686fb0403aebe0fe912db1
When generating overcloud templates, tuskar includes non role
templates that are read from the resource registry (environment.yaml)
These templates typically include a path in their name, like
'puppet/compute-post-puppet.yaml'.
The resource registry templates can also include extra-data and
so when these are resolved, include the prefix path from the name.
Change-Id: I43b6aa5eb96c7bcade501b01f0ce93353e65af64
This adds a stand-alone tuskar-load-role command which takes a name
and path to the main file defining this role. If no name is provided
this is deduced from the path (filename) as currently occurs with
tuskar-load-roles. If a path is not specified then a SystemExit
occurs.
This also wires up the relative_path into the role creation
(this is added to the model by the parent commit)
Optionally you may specify the extra-data files that the given role
uses as multiple '--extra-data' arguments to tuskar-load-role.
Change-Id: I9c143afb52c43e4258c3a6797a9707c08d8dcdaf
This field is optional and can be used to carry information on the
directory structure expected for role templates.
Change-Id: Ic68ac09196de7604466a45f2dd929544597c1b9f
The current Tuskar API doesn't cover the role resource lifecycle.
For development purposes there is no easy way to delete existing
roles that were created with tuskar-load-role and friends.
This review adds a tuskar-delete-roles utility that takes a --uuids
list of ids to delete. If any of the specified role uuids do not
exist, an unknownUUID exception is raised. If any of the specified
uuids are in use by an existing plan, a OvercloudRoleInUse exception
is raised. In case of either of the above, no roles are deleted and
the operation exits.
The --dryrun flag can be specified which still goes through the
validation above but still does not perform any deletions when
that passes.
Example invocation:
tuskar-delete-roles --config-file ~/tuskar.conf --dryrun --uuids
c3b43c3c-e69b-4db7-b0df-3bf2bb8c04cf
5cffe8b6-df60-4cc6-92c6-c8067f0067eb
Change-Id: Idb397fd0d6d35b143646d42b171deebc1bce6b36
This command is essentially the tuskar-load-roles functionality broken
out specifically to handle just the master seed (and the required
resource registry). Example usage:
$ tuskar-load-seed --config-file etc/tuskar/tuskar.conf --master-seed
~/tripleo-heat-templates/overcloud-without-mergepy.yaml --resource-registry
~/tripleo-heat-templates/overcloud-resource-registry-puppet.yaml
Subsequent runs will update the templates which is the same behavior as
the tuskar-load-roles command.
Change-Id: I07450edebd0dacd86bd0b28665eb1aaa3ea30ecb
This paves the way for loading roles in separate steps with different
executables rather than just one load operation.
Change-Id: I4eec7548837e19b7bc50616ba7e5355a0b86261c
The same block of code was repeated several times in whole function.
Replace it with one, reusable function to prevent from possible
problems and simplify usage.
Change-Id: I4dbddcf1b361b59344a7bc15a793c568dba00f13
This uses the new TemplateExtraStore to process stored extra-data
files and match them against the template for each defined role
This information is included when a client requests the existing
/plans/plan_uuid/templates path. To retrieve the extra-data for
any particular role a new /role/role_uuid/extra_data path is added
Change-Id: Ic52280248b0d169f4a3c27e10a826d3dbb2b9bf3
The dry run flag isn't currently dry as the database is changed even if
it is enabled. This change removes the feature as it was never
particularly useful.
Change-Id: I7f796aa2ef2759ade3827db68b86d463f2db7fed
This enables use of '--role-extra /path/to/file.yaml' to specify
extra template files that are included in the main role templates
(via 'get_file' directives).
tuskar-load-roles --config-file ~/tuskar.conf
--master-seed $DIR/overcloud-without-mergepy.yaml
--resource-registry $DIR/overcloud-resource-registry-puppet.yaml
-r $DIR/puppet/compute-puppet.yaml
-r $DIR/puppet/controller-puppet.yaml
--role-extra $DIR/puppet/hieradata/common.yaml
--role-extra $DIR/puppet/hieradata/compute.yaml
Includes basic testing for load-roles with --role-extra and also
exercises the (internal) role-extra name generation code
Change-Id: I738f07b0b3d056b804394e57392b636d8fdf55fd
This change allows for resources utilized in the master seed that are
specified in the resource registry, but are not a provider resource to
be stored and saved to disk. There is no additional information required
to pass as all the data is stored while loading roles.
Previously tuskar always assumed that there was a 1:1 correspondence
between the final resource registry and the number of roles, but this is
no longer the case. The API for /v2/plans/templates has changed to
include non-role resources specified in the resource registry (CLI
operation tuskar plan-templates).
(Also, ignores tags file in git)
Change-Id: Ia15c0fdad0c036564b81f664e49fca280bc7ce7e
Next release of oslo.db is going to break Tuskar DB tests: when
a test case cleanup is run, it fails to fetch 'schema' attribute of
oslo.db base test case, set in its setup. The problem is that Tuskar
base test case intentionally removes all attributes from a test case
class instance in its cleanup callback (to ensure there are no memory
leaks).
So in order for Tuskar unit tests to work correctly with new release
of oslo.db we need either to remove inheritance from Tuskar base test
case or to change the order of base classes to achieve the 'proper'
MRO for DB test cases.
In future, oslo.db is going to introduce a DB fixture instead of a
base test case class to avoid such problems with multiple inheritance.
Change-Id: Ia0ca1b261d707b6fbe349fd536599c845da0a2e9
OpenDev Sysadmins