The secrets generator still fails if kolla-ansible isn't installed
because it continues to look for files installed from that package. This
patch changes the code to look at the ansible code location in the
kolla-kubernetes package.
Change-Id: Idd3e35b198ebf0d4c109906b18234bd06e74d48f
This is a direct copy of generate_passwords.py from kolla-ansible to
remove the kolla-ansible dependency.
Change-Id: Ia8a19ee4e196c4bd5f6d42fe0f6ccfc36f0bfb7f
Partially-Implements: blueprint remove-deps
The gating on python 3.4 is restricted to <= Mitaka. This is due
to the change from Ubuntu Trusty to Xenial, where only python3.5
is available. There is no need to continue to keep these settings.
Change-Id: Ic8fb72a0618db4099b149faf5282611bddb19080
Python 3.3 is not supported from Mitaka, as per Infra.
This patch removes the support for the same.
Change-Id: Ied7355b2c2368583194dfad2d3af4842ac01d915
Currently, running ``tox -e cover`` errors out and does not generate
the correct coverage report. The problem is caused by (a) a typo in
``tox.ini``, and (b) a mix up between ``kolla_kubernetes`` vs.
``kolla-kubernetes`` in .coveragerc and setup.cfg. This causes the
coverage report to not properly pick up the module. This patch set
addresses the problem.
Change-Id: I0a10c0eb563968f4b88a816276455a6afcf5df80
Closes-Bug: #1650266
This Patch Set reworks the cli. For now, instead of replacing the
'kolla-kubernetes' tool it makes a new tool called 'kollakube'.
This new command requires less typing. Operators who will need to
type the command a lot, so shortening the cli will help over time.
In a future PS the old 'kolla-kubernetes' command will be removed.
It reworks the resource and template system to allow the operator
to specify multiple entries to be processed at once. This aligns
kollakube with kubectl behavior.
The 'resource-template' subcommand is renamed to just 'template'.
The 'resource-map' subcommand is renamed to just 'map'.
The 'template' subcommand drops the action argument as it has no
effect.
Aliases are added from 'resource' to 'res' and 'template' to 'tmpl'.
The 'kollakube' cli removes any workflow related subcommands as they
are unlikely to work well moving forward and will be replaced
shortly with an ansible workflow.
Change-Id: Ide7b5d391a4ac0a514c027cf761033d9eb94d152
- No bug-fixes, blue-prints, nor code changes.
- Originally, kolla-kubernetes only used 3 types of kubernetes
resource files (job, pod, svc). Bootstrap files (job) were separated
from service files (pod, svc). Subcommands were tied directly to the
files their respective directories (bootstrap command -> ./bootstrap
dir, run command -> ./services dir).
- This was done because of the way kolla-kubernetes used to work.
Upon subcommand launch, all of the files in its respective
directory were jinja processed and then loaded into kubernetes (in
random order).
- Now that we have added a bunch of resources that require ordering
(disk, pv, pvc, etc), and kolla-kubernetes directly references each
type of file based on the configuration of
./etc/kolla-kubernetes/kolla-kubernetes.yml, we no longer need to
separate bootstrap and service files.
Change-Id: I595388a686330cfdeb662b9a0a8b52cc1d45c913
- Not a bug-fix nor blue-print, or even code change with exception of
import paths and renaming.
- Moved cmd/shell.py to app.py, and renamed the class inside of it
from KollaKubernetesShell to KollaKubernetesApp.
- Deleted type_utils.py and moved its type_utils class into
utils.py:TypeUtils, and also its respective tests.
- Split cli/service.py into commands/cmd_service.py and
commands/cmd_resource.py. All original service commands
(kill/run/bootstrap) are in cmd_service.py, and all of the new
resource commnads (resource, resource-template, resource-map) are
now in cmd_resource.py.
- Moved common/* files (utils.py, pathfinder.py) up one directory to
parent for both files and tests. There isn't much "common" about
these files.
- Modified setup.cfg to reflect the new command locations.
- Any other files edited are because the import paths needed to
change.
Change-Id: I35771734d77f59efe68f0bbc2dda7fea5a0096b8
- This is prep work, and a dependency for the Ansible workflow engine
as well as upcoming multi-node kolla-kubernetes patches.
- The original bootstrap/run/kill commands are still present, and left
untouched for the moment. The workflow engine will replace these
monolithic commands.
- The original commands did quite a few things (process jinja, create
configmaps, create svcs, create pods) all at once. Broke up each of
these discrete bits of logic into their own smaller CLI commands.
- Added new subcommand, used to create or delete kolla-kube resources
kolla-kubernetes resource [-h] <action> <resource-type> <service-name>
<action> One of [create|delete]
<resource-type> One of [configmap|disk|pv|pvc|svc|bootstrap|pod]
<service-name> One of [mariadb|memcached|keystone|horizon|
rabbitmq|glance|nova|neutron|swift]
- Added new subcommand, used to process templates for resources
kolla-kubernetes resource-template [-h] [--print-jinja-vars]
[--print-jinja-keys-regex <print-jinja-keys-regex>] <action>
<resource-type> <service-name> <template-file>
- Added new subcommand which allows an operator to discover and list
available services, resource types, and resource files.
kolla-kubernetes resource-map [-h] [--resource-type <resource-type>]
[--service-name <service-name>]
- Made explicit the ordering of kolla-kube resources in
service_resources.yml. Resources are explicity configured, instead of
discovered, because there is inherent dependency ordering required
when creating resources. For example, services have a dependency
order of creation. Disks, pv, pvc, svc, pods also require order.
Prior, we only needed to support pod and service definitions, which
were created in any order.
- Added ability to process jinja templates that are scripts. This
leaves room for persistent disk creation in follow-on patch to support
multi-node kolla-kubernetes.
- The steps to create all resources for a working Horizon are:
kolla-kubernetes resource create svc mariadb
kolla-kubernetes resource create configmap mariadb
kolla-kubernetes resource create bootstrap mariadb
kolla-kubernetes resource create pod mariadb
kolla-kubernetes resource create svc memcached
kolla-kubernetes resource create configmap memcached
kolla-kubernetes resource create pod memcached
kolla-kubernetes resource create svc keystone
kolla-kubernetes resource create configmap keystone
kolla-kubernetes resource create bootstrap keystone
kolla-kubernetes resource create pod keystone
kolla-kubernetes resource create svc horizon
kolla-kubernetes resource create configmap horizon
kolla-kubernetes resource create pod horizon
Change-Id: Ie27ea4537cdbaf0922a14e3a5e24040e598e32e8
Partially-implements: blueprint kolla-kubernetes-cli
Partially-implements: blueprint ansible-orchestration
- This patch is neither a bp nor bugfix... It is refactor only, with
exception of adding two CLI commands to help debugging jinja
templating.
- Enhancement: New CLI commands added
kolla-kubernetes jinja template <path_to_template_file>
Processes the template output using the jinja vars and prints
to stdout.
kolla-kubernetes jinja vars <service_name>
Creates the jinja dict from the merged config files and prints
to stdout
- The refactored code merges configuration files based on priority
order into an python dict, which is applied to a jinja template to
create files.
- Simplified code, removing much logic.
- Enhancement: Made things much faster. Old algorithm ran recursively
at Order(n) of the number of keys in each configuration file
(hundreds of calls). New algorithm runs iteratively at Order(n) of
nested jinja variables (a few calls). Each call to jinja creates a
new environment and applies a template.
- Enhancement: Configuration files (kolla-kubernetes.yml, globals.yml,
passwords.yml) are treated the same as the ansible configuration
files, and these files may now reference jinja variables like the
other ansible files.
- Fix: Old algorithm would flatten nested keys, accidentally
overriding keys at higher levels. For example, consider yaml:
"docker_common_options":
"environment":
"KOLLA_CONFIG_STRATEGY": "COPY_ALWAYS"
The issue would cause "KOLLA_CONFIG_STRATEGY" to accidentally end
one at the root level. This new algorithm allows key values to
maintain their nested structure, which would be expected for
templating consumers.
- Fix: Enabled all commands to process yaml files containing a stream
of documents. Validation will now be done by kubectl. In the
future, we'll pass it directly to kubectl for validation before
submission.
- Verified: The differences between the old and new algorithm dict
generation. The only difference is the new algorithm does not
flatten nested yaml.
Change-Id: Iad2572a90ed3955ed8555d7556fb7283b8ede17f
Step 1: setup configmaps and run bootstrap jobs
Step 2: run service
Partially-implements: blueprint kolla-kubernetes-cli
Co-authored-by: Ryan Hallisey <rhallise@redhat.com>
Change-Id: Ie074f21984ac89291e11e7b4798f3a18a8cc200e
Existing code assumes that there's a directory services/ and that
the bootstrap directory is adjacent in the directory tree.
Change-Id: I9ce619d32f858473c0685655c7d20c511690b95b
kolla_kubernetes.py has same name as package which caused import error:
from kolla_kubernetes.common import utils
ImportError: No module named common
Change-Id: I33e77cf098212b5fcc685cf06dd02cece054deb7
The warnerrors boolean option is used to tell Sphinx builders to
treat warnings as errors which will cause sphinx-build to fail if
it encounters warnings. This is generally useful to ensure your
documentation stays clean once you have a good docs build.
since we are python 2 and 3 compatible we should create a
universal wheel distribution.
Change-Id: I2a45596590d20b50abd232e3b070454cc28113ad
Picked up code from old repositories. Main change is in service.py.
related blueprint kolla-kubernetes
implements blueprint kolla-kubernetes-cli
Change-Id: I9caefe557ac827ca7a3b8f9a1693d623cf369080
Jeffrey Zhang