- armada-airskiff-deploy is voting gate again
- fixed falcon.API deprecation - -> falcon.App
- fixed collections.abc.defaultdict not found error
- fixed tox4 requirements
- implemented requirements-frozen.txt approach to make allike as other
Airship projects
- uplifted docker version in the image building and publishing gate
Change-Id: I337ec07cd6d082acabd9ad65dd9eefb728a43b12
Bumping k8s client to v25.3.0
Cronjob batch v1beta1 no longer available in k8s 1.25
Update tox.ini file to be compatible with v4
Change-Id: Iac79c52c97c9ef1223ae8d502da1572ef8d068fa
For now we leave the tiller status enpdpoint, until
Shipyard has had a release to stop depending on it [0].
[0]: https://review.opendev.org/c/airship/shipyard/+/802718
Signed-off-by: Sean Eagan <seaneagan1@gmail.com>
Change-Id: If8a02d7118f6840fdbbe088b4086aee9a18ababb
From recently merged document updates in [0] there is a desire to
standardize the Airship project python codebase. This is the effort
to do so for the Armada project.
[0] https://review.opendev.org/#/c/671291/
Change-Id: I4fe916d6e330618ea3a1fccfa4bdfdfabb9ffcb2
This introduces v2 docs in order to allow users to opt in to
breaking changes, while still supporting v1 docs for a time
so folks can migrate. At some point v1 doc support will be
removed.
This initial version of v2 docs is experimental. Further
breaking changes will be made before v2 docs are finalized.
A v1-v2 migration guide is included in the documentation.
This also refactors the internal data model to include the full
document structure, such as `metadata` and `schema`, so that
different behavior can be acheived for v1, v2, etc.
Change-Id: Ia0d44ff4276ef4c27f78706ab02c88aa421a307f
This creates a new mechanism in Armada to enable functions to only be
run once across multiple instances of Armada working with the same
Kubernetes cluster. This is accomplished by utilizing custom resources
via the Kubernetes API.
This also introduces new config defaults that can be used to configure
the lock timeout, expiration, and update interval.
Some notes on how the lock works:
* Functions to be locked can add the new decorator
* The optional name parameter can be used to create multiple
types of locks which can coexist
* If the lock is unable to be acquired before the timeout a new
exception is raised
* The lock is updated regularly while the decorated function is
still running
* If a lock already exists it will only be overwritten if the
duration since its last update is longer than the expiration time
For now this locking method is being used for components that require
write access to Tiller so that simultaneous write operations are
avoided.
Change-Id: Iee07da9a233ee2e2a54c6bc4881185388b377c05
This adds a new configuration default to specify the Tiller host IP.
This is important to be able to configure in environments where
Armada is unable to find a Tiller pod.
Change-Id: I12fd9fbd16f2b591620e566affcf19f859ed1855
This changes unsequenced chart group deployments, such that each chart
in the group is deployed in parallel, including the install/upgrade,
wait, and tests.
Previously, whether and when to wait was entangled with whether or not
the chart group was sequenced, since running helm install/upgrade's
native wait (which cannot be run later) and armada's labels based wait,
delayed (or even prevented in the case of failure) the next chart from
being deployed, which is the intention for sequenced, but not for
unsequenced. With this patchset, sequencing and waiting are now
orthogonal. Hence we can now allow the user to explictly specify whether
to wait, which this patchset does for the case of helm's native wait
via a new `wait.native.enabled` flag, which defaults to true.
Previously, armada's labels-based wait sometimes occurred both between
charts and at the end of the chart group. It now occurs once directly
after chart deployment.
Previously, passing armada's --wait was documented to be equivalent to
forcing sequencing of chart groups, however helm tests did not run in
sequence as they normally would with sequenced chart groups, they now
do.
Since chart deploys can now occur in parallel, log messages for each
become interleaved, and thus when armada is deploying a chart, log
messages are updated to contain identifying information about which
chart deployment they are for.
Change-Id: I9d13245c40887712333aaccfb044dcdc4b83988e
- Adding yapf diff to pep8 target
- Adding yapf tox target to do actual format
** The rest of this PS contains formatted code only, no other changes
Change-Id: Idfef60f53565add2d0cf65bb8e5b91072cf0aded
This removes duplicate option certfile from
Armada config causing:
2018-06-13 16:44:42.093 24 ERROR armada File "/usr/local/lib/python3.5/site-packages/oslo_config/cfg.py", line 801, in _is_opt_registered
2018-06-13 16:44:42.093 24 ERROR armada raise DuplicateOptError(opt.name)
2018-06-13 16:44:42.093 24 ERROR armada oslo_config.cfg.DuplicateOptError: duplicate option: certfile
2018-06-13 16:44:42.093 24 ERROR armada
This appears to because authtoken Keystone middleware
automatically adds Keystone session options to Armada's
CONF automatically [0]. Thus including
`ks_loading.register_session_conf_options` causes option
duplication.
However, I still don't understand where auth options are set
automatically by other services, which is why
`ks_loading.register_auth_conf_options` is left in the code
(which adds yet other options related to Keystone auth
plugin options, required for creating a Keystone session).
[0] https://docs.openstack.org/keystonemiddleware/latest/middlewarearchitecture.html#configuration
Change-Id: I2c2576c35d87a7b0e3c96ad64fcd88ce54fff86b
This patchset adds missing Keystone options to registration
of config, including timeout, which is causing the following
error in testing:
packages/oslo_config/cfg.py", line 3130, in _get_opt_info
2018-06-12 20:28:40.318 9 ERROR armada.api raise NoSuchOptError(opt_name, group)
2018-06-12 20:28:40.318 9 ERROR armada.api oslo_config.cfg.NoSuchOptError: no such option timeout in group [keystone_authtoken]
2018-06-12 20:28:40.318 9 ERROR armada.api
This fix is similar to a recent Shipyard patchset [0] which
aimed to solve the same issue but expands on it by following
Nova patterns here: [1].
This also updates the sample config file which now includes
the timeout option.
[0] https://review.openstack.org/#/c/572563/
[1] http://git.openstack.org/cgit/openstack/nova/tree/nova/conf/cinder.py
Change-Id: I2c35bcfe9cacbc3a443f7f0975ad2ab43c7ca7c2
ARMADA-29: CI/CD Armada Testing Framework Entrypoints defined
It does not appear the the docker run command to call tox tests/unit
is necessary. The Makefile already includes several testing checks.
Added a few additional targets as specified in the upc-integration
code-convenstions to satisfy the clcp Makefile standards.
Change-Id: Ia920a856ed6d607fcf38d5f85dbb9a0c8aae4fa6
- Add support for SSH key auth using existing config file value
- Add authentication exceptions
- Remove redundant git error handling from Armada handler
Closes #169
Change-Id: Ia0f61e0b74893289bb90560a743a243393d89c56
- adding .editorconfig file
- minor cleanup in various files related to .editorconfig
- typos, whitespace, etc.
- other general housekeeping items on the codebase
Change-Id: I104f8dcb06aafb180da12f7ee4c0ded41fc07b9d
Adding tiller-namespace (tn) flag to allow for setting specific tiller namespace
Updated:
- Armada API
- Test API
- Tiller API
- Armada handler
- Tiller handler
- cli/apply
- cli/test
- cli/tiller
Change-Id: I3a18d6ec2ce2f771c9349d6b337537f193f6c73d
This allows the user to apply and/or validate a manifest using
either a filepath (as before) or URL.
Addition by sh8121att:
- Create a general document resolver class to handle local paths
and URIs
- Allow multiple filenames and combine them into a single document
set
- Change API to allow for passing document reference URIs to be
resolved server-side rather
- Update validation API to conform to UCP specification
- Dockerfile updates to speed up build
- Fix unit tests
Closes #96
Change-Id: I5a57779f10d1b63ffc161a14afec851a34ae9efe
This PS sets the foundation for unskipping Armada API unit tests
by making necessary framework changes where necessary as well
as test refactoring so that the tests not only can be unskipped
but also execute successfully.
However, until a feature-rich testing framework is in place, it's
not possible to do end-to-end testing as mocking is currently used
to stub out Tiller API.
Negative RBAC tests will be added in a follow-up.
Included in this PS:
- policy fixture for asserting that expected policies are enforced
- unit tests for tiller/armada API
- test_utils module
Change-Id: I2f454b27b014875bc35fd706f7c0d05364ce562a
- Add labels to Tiller pod searching
- Add Tiller pod labels to default config options
- Add exception for case when Tiller pod cannot be found using labels
- Add exception for case when Tiller pod is not in running state
- Update exception documentation
Closes #172
Change-Id: I7e54c4b4a60638bca1073457c256030344832ef9
Allow user to set logging levels, using keystone's implementation
Updated:
- armada/shell
- armada/conf/init
Closes #177
Change-Id: I5c6cc0fa33f103df77860c90a3bc8b82f5f9d61e
- using click framework
- added api client
- allow interactions between code and service endpoints
- documention on the command line
- updated gitignore
Change-Id: Ibe359025f5b35606d876c29fa88e04048f276cc8
This patch set makes Armada pep8 compliant. Note the hapi/** is
autogenerated and therefore should be excluded from linting.
Change-Id: I123eefb543f9bd9cf0bc6bd98ed95646d8d72cc3
* Ensure that configurations are done via the global `cfg` object
* Ensure that the logger is configure through the global object
* Upload a configuration sample file with DEFAULT section having
the armada.conf and oslo_log namespace
- Refactor API structure
- Add API support for existing CLI flags
- Add Keystone token and RBAC authentication
- Add API documentation
- Add API unit tests
- Adds Oslo logging libraries
- Enables logging configuration with a config file
- Enables debug logging with --trace flag
- Supports Docker logs
- Adds logging for tiller
Ruslan Aliev