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
These were the commits from github repo(s)
84d943e Initial commit
3d15bd1 Created the pecan project for containers for API
b49297b Added rest functionality to the v2 apis
227e1dd Added rest functionality to the v2 apis
39500ae Added the base API call like POST, GET, PUT & DELETE.
e404e94 adding wsme support to pecan
f90f540 Added wsme support to the magnum apis
c879329 added changes to api
24ebc32 Fixed the bugs in the container apis
01725ef Rename dir from containers to magnum
1a1375a Add requirements and test-requirements
f957e2e Add ASL2.0 license
8f4c0ee Move tests to the proper location
48dd100 Move setup files to proper directory
86cc435 Fix the setup so the installation is sanitary
b766d59 Make the installation and tox testing work
c477236 This is a new project - start with v1 for api
cf20cac Remove pep8 errors
d23b325 Merge with code generated using OpenStack cookie-cutter
b6b9f34 Ability to run pecan serve from command line
Had to update requirements.txt to get jobs working
Change-Id: I068389412d023c258bda40dfbdff5a40f2e7d175
Co-Authored-By: Digambar Patil <digambarpat@gmail.com>
Co-Authored-By: Steven Dake <sdake@redhat.com>
