Now that we are running the Victoria tests that include a
voting py38, we can now add the Python 3.8 metadata to the
package information to reflect that support.
Change-Id: Id12970d7cf493564ea0ceb339b8e429bf031ce95
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
Make a few cleanups:
- Remove python 2.7 stanza from setup.py
- Add requires on python >= 3.6 to setup.cfg so that pypi and pip
know about the requirement
- Remove obsolete sections from setup.cfg:
* Wheel is not needed for python 3 only repo
- Update classifiers
- Update requirements, no need for python_version anymore
Change-Id: I705a40cb3a19e16641a2b9de6891ab72fe2b98f0
This patch adds a standard /usr/bin/magnum-api-uwsgi script, which we can
use from uwsgi. Without this patch, there's no way to load the application
correctly, with parameters on the command line.
Change-Id: Icdcd1255e7e08d68a5d31672b21127f781d6ac68
Add fedora coreos driver. To deploy clusters with fedora coreos operators
or users need to add os_distro=fedora-coreos to the image. The scripts
to deploy kubernetes on top are the same with fedora atomic. Note that
this driver has selinux enabled.
The startup of the heat-container-agent uses a workaround to copy the
SoftwareDeployment credentials to /var/lib/cloud/data/cfn-init-data.
The fedora coreos driver requires heat train to support ignition.
Task: 29968
Story: 2005201
Signed-off-by: Spyros Trigazis <spyridon.trigazis@cern.ch>
Change-Id: Iffcaa68d385b1b829b577ebce2df465073dfb5a1
This commit adds the functionality of magnum-status CLI for performing
upgrade checks as part of the Stein cycle upgrade-checkers goal.
It only includes a sample check which must be replaced by real checks in
future.
Change-Id: Ia8a74fd8bd5a804e71bb04eb0615fa114a517bc4
Story: 2003657
Task: 26138
* It removes magnum tempest plugin reference in favour of using
newly magnum-tempest-plugin.
* We removed tempest tests resides under functional.api.v1.test-*
files as they are tempest tests and keeping the rest as they are
used by functional tests.
Depends-On: Ibdddd26da9cfb0d08c2977660320b2c052d7261b
Change-Id: Ida2fa1ef5880ebead787e3b27ac7ebf5aa498f62
This commit uses the existing policy-in-code module to move all
default policies for magnum service and stat into code. This commit
also adds helpful documentation about each API those policies protect,
which will be generated in sample policy files and completely remove
usage of policy.json file.
Co-authored-By: Dai Dang-Van <daidv@vn.fujitsu.com>
Implements: blueprint policy-in-code
Change-Id: I01a8ce964bf8bd569d4aa4e899cbcd9855281835
This change prepares the magnum project to start implementing
policies in code. Subsequent patches will register more magnum
policies in code and remove the corresponding entry from the
policy file maintained in source.
This is part of a community effort to provide better user
experience for those having to maintain RBAC policy. More
information on this effort can be found below:
https://governance.openstack.org/tc/goals/queens/policy-in-code.html
Change-Id: I0e2b34067ea1e4d5868df544a9f65ae3f1944c43
Co-authored-By: Dai Dang-Van <daidv@vn.fujitsu.com>
Implements: blueprint policy-in-code
In order to make it simpler to use the default
configuration files when deploying services
from source, the files are added to pbr's
data_files section so that the files are
included in the built wheels and therefore
deployed with the code. Packaging and deployment
tools can then more easily use the default files
if they wish to.
This pattern is already established with similar
files for neutron, designate and glance as has
been mentioned in the related bug report.
Change-Id: If96de1416714490477ce03dbdf7f33ee1e78de87
Closes-Bug: #1718356
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: Id6d387d7e2cf6395a7ccff6291c9c73787984d51
* Add osprofiler wsgi middleware. This middleware is used for 2 things:
1) It checks that person who wants to trace is trusted and knows
secret HMAC key.
2) It starts tracing in case of proper trace headers
and adds first wsgi trace point, with info about HTTP request
* Add initialization of osprofiler at start of service
Currently that includes oslo.messaging notifer instance creation
to send Ceilometer backend notifications.
* Traces HTTP/RPC/DB API calls
Demo: https://hieulq.github.io/cluster-create-false-new-html.html
Co-Authored-By: Hieu LE <hieulq@vn.fujitsu.com>
Implements: blueprint osprofiler-support-in-magnum
Change-Id: I7d68995aab81d365433950aada078ef1fcd5469b
After patch: https://review.openstack.org/#/c/374906/
magnum-template-manage didn't worked because load_entry_point
method moved to Driver class.
With this patch, magnum-template-manage can be used to list
all available drivers in magnum.
The patch also renames magnum-template-manage cli to
magnum-driver-manage.
Drivers can now be listed using:-
magnum-driver-manage list-drivers
magnum-driver-manage list-drivers -d -p
DocImpact
Change-Id: I17ba94b0e2000486b5fcbf792991ad98183bd26c
Partially-Implements: blueprint bay-drivers
Closes-Bug: #1632630
Initialize magnum centralize config folder and test cases.
Change-Id: Ib68e54701e127546fbaa91e3633f50d149a5b878
Implements: blueprint centralize-config-magnum
The 2 k8s atomic drivers we currently support are added to the
same driver. This breaks ironic support with the stevedore
work I'm currently doing.
With stevedore, we can choose only one driver based on the
server_type, os and coe. We won't be able to pick a driver and
then choose an implementation bases on server_type.
Partially-Implements: blueprint magnum-baremetal-full-support
Co-Authored-By: Spyros Trigazis <strigazi@gmail.com>
Change-Id: Ic1b8103551f48f85baa2ed9ff32d5b70b1fab84e
This is workaround fix to support baremetal.
Following items are remained to support.
* Documents
* Functional test
To test this template, there are some requirements and problem as below.
Requirements:
* `ephemeral_disk` on ironic baremetal flavor
`ephemeral_disk` is used for docker storage instead of cinder volume.
* `fixed_subnet` must be setup with dns_nameservers like following.
* `neutron subnet-update private-subnet --dns-nameserver 8.8.8.8`
* `fixed_subnet` must be IP version 4.
if you use devstack, please add following configuration.
* `IP_VERSION=4`
* Fedora 23 image including kubernetes, etcd, flannel.
Problem:
Ironic stores `instance_info` about nova instance.
`instance_info` contains config_drive data, but this data can be
too large to store ironic.nodes table.
Magnum uses large config drive data to setup k8s.
It means, we can not start ironic instance by Magnum.
Workaround fix is changing column type of ironic.nodes.instance_info.
Following sql will help you.
`alter table ironic.nodes modify instance_info LONGTEXT;`
Partial-Implements: blueprint magnum-baremetal-full-support
Change-Id: Ica87610b9114bff4277b492de8fe528fe2860108
Closes-Bug: #1454895
Closes-Bug: #1472938
Co-Authored-By: Spyros Trigazis <strigazi@gmail.com>
Now that there is a passing gate job, we can claim support for
Python 3.5 in the classifier. This patch also adds the convenience
py35 venv.
Change-Id: Ifd69012586ecb59faaab2a474f43efde9b244756
This patch moves k8s-coreos specific templates and
template_definition class to the new drivers folder.
It also deletes the /magnum/templates folder
as everything has been moved to the drivers directory.
Change-Id: I6b2ca49e4d7d5fcfb96d0abc373d6476fd907358
Paritially-Implements: blueprint bay-drivers
Moves templates and template_definitions to the new
directory structure.
Change-Id: I42e4d2bd056f3d8082ef51ef599d917f2fe82960
Paritially-Implements: blueprint bay-drivers
Moved all the swarm templates and template_definition code
to the magnum/drivers folder.
Moved base template_definition classes to drivers/common
folder
Change-Id: Ieff57f0f47835c35d9f17c3d7d1b7e6a40907462
Partially-Implements: blueprint bay-drivers
Co-Authored-by: Spyros Trigazis <strigazi@gmail.com>
No config generator hooks should ever be registered with a name that
belongs to another project. In this case, using oslo.middleware.cors
means that *every other project* that loads the middleware gets this
application's defaults when the generator is run on a system with
everything installed (such as a dev box with devstack). Use the name
of the app instead, to ensure that the defaults are only set when this
app's sample config and documentation are being generated.
Change-Id: I6a8c7d44b9db9325003ff2fdb667b0ced7739e96
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
The default values needed for magnum's implementation of cors
middleware have been moved from paste.ini into the configuration
hooks provided by oslo.config. Furthermore, these values have been
added to the default initialization procedure. This ensures
that if a value remains unset in the configuration file, it will
fallback to using sane defaults. It also ensures that an operator
modifying the configuration will be presented with that same
set of defaults.
Change-Id: I7d8f8708d53bbab117600070982ac80482fa0a77
Closes-Bug: 1551836
This is a migration step to utilize tempest plugin
system instead of directly calling functional api tests.
This is the approach used by a number of other projects as well
as an approved process by openstack-qa.
The difference in execution is that we will need to execute tempest's
tox instead of our own:
tox -eall-plugin magnum.tests.functional.api.v1 -- --concurrency=1
Implements: blueprint magnum-tempest
Change-Id: Ic3eadae7fb5d88b776f9ded9589ef25279a2e1be
OpenStack Mitaka release does not support Python 2.6 anymore. And
Magnum do not run any test against py26. So remove the classifier.
Change-Id: I2ab904f3f35455e2d50cd64ac84a52c6ed3d31a9
Closes-Bug: 1522620
To implement TLS support, we should store CA and client cert for each
bay. This patch adds common library to store cert to Barbican.
Magnum uses service admin privilege to store the cert, this means that
end user can't retrieve CA cert and private key from Barbican
directly.
This patch is copied from neutron-lbaas project.
* I435189b2637e32803a13ebd4951e61fac4ab234d
Change-Id: I519228d9749ad610db3e0c698caa1144813f9d52
Partial-Implements: blueprint magnum-as-a-ca
Currently magnum has two type of migration tools, one is oslo.db
migration_cli, other is calling alembic migration tool directly.
This fixes to get more consistency.
Closes-Bug: #1487248
Change-Id: I705dd2cc65c1f879ce1e2ebaaf2015dc6dc24c64
After this commit, users should be able to create a Mesos bay.
To do that, they need to create a baymodel first. The baymodel
should have a coe attribute with value 'mesos'. Then they can
create a Mesos bay by using the baymodel.
Change-Id: I19eaa7abf028ab81070bea18991940462ad509ad
Partial-Implements: blueprint mesos-bay-type
This change will allow deployers to select either Kubernetes
or Swarm to be the CoE used in Magnum's bays. A Swarm bay uses
a subset of the BayModel parameters used for Kubernetes.
Node discovery is provided via Docker's public discovery
endpoint, but operators and users can override this with
Bay's discovery_url argument.
Implements: bp multiple-bay-templates
Change-Id: I5278e6d477298085d07673810e5d8813d21b7730
The idea here is to provide a way for magnum to discover and interact
with templates meant to build bays. Template definition discovery is
done through python entry_points, and each class lists the bay_types
it can provide. Each template definition contains a mapping of magnum
object attributes and heat template parameters/outputs.
This will be useful for not only allowing different CoEs, OSes, and
platforms. But can also provide the discovery mechanism for templates
once they are pulled into their own repository.
Partial-Implements: bp multiple-bay-templates
Change-Id: Ia596657856cd861c94e58dcd65acae0677a36d73
Remove conductor. The backend will replace the conductor as the process
name to be more consistent with other OpenStack projects.
Change-Id: If69557b7ca02e48c65372cbb200d2f648613778e
The Ironic codebase is pretty simple for database access. This work
leads into the introduction of versioned object technology from nova
and ironic that will be entering oslo:
https://review.openstack.org/#/c/127532/
This will drastically speed up the process of implementing moving the
RPC objects across the network.
Change-Id: I38aa451b658b66f5b6f10ced03ea2e0355af4ecd
- Added an entry_point for oslo config generator
- Added a script to enumerate config options
- Added a tox target to invoke config generator
Change-Id: I16a2e622db18f8ac4deeecc17e87bb2b5edf3826
Backend processors execute the ReST API using a specific backend. For
example, docker implements the container backends. k8s implements the pod
and services backends. If at some later date, someone wants to implement
a fully native backend, that would be possible. In the short term (next 4-6
weeks) I'd like to focus on backends using k8s and docker only rather then
trying to get native to work.
Change-Id: I77abde65dfe03e12f2931854da52a69f5e618d93
Add an initial conductor API and service. This service allows
operation on the four object types -> bays, pods, services, and
containers and allows the ability to list, read, write, or delete
those objects in the database. The implementation of the
list/read/write/delete is incomplete and should come in a follow-up
patch.
Change-Id: I60e9070e4b5aeaeddba67233b99dd0e3a3cffe22
