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>
Andrew Melton