Difference between revisions of "Magnum/NativeAPI"
Adrian Otto (talk | contribs) (→Magnum's Native Container APIs) |
|||
(One intermediate revision by one other user not shown) | |||
Line 1: | Line 1: | ||
+ | Containers in Magnum clusters are created only using the native container orchestrator API. Please refer to: | ||
+ | * https://docs.openstack.org/magnum/latest/user/index.html#native-clients | ||
+ | * https://docs.openstack.org/magnum/latest/install/launch-instance.html | ||
+ | |||
NOTICE: This is a work-in-progress draft. Our community is working on refining this draft here: https://etherpad.openstack.org/p/magnum-native-api | NOTICE: This is a work-in-progress draft. Our community is working on refining this draft here: https://etherpad.openstack.org/p/magnum-native-api | ||
Line 9: | Line 13: | ||
==Use Cases for Magnum's "container" Resource== | ==Use Cases for Magnum's "container" Resource== | ||
We are seeking production use cases for the <code>/container</code> resource offered in the Magnum API. If you have one, please identify it here: | We are seeking production use cases for the <code>/container</code> resource offered in the Magnum API. If you have one, please identify it here: | ||
− | * | + | * Deploy containers from other OpenStack services. Expecting services to abstract every possible supported bay type is not scalable. A more precise example, I'd like trove to deploy DBs on containers and to do that, I'd like it to use Magnum's containers API. (flaper87) |
Latest revision as of 09:51, 15 January 2018
Containers in Magnum clusters are created only using the native container orchestrator API. Please refer to:
- https://docs.openstack.org/magnum/latest/user/index.html#native-clients
- https://docs.openstack.org/magnum/latest/install/launch-instance.html
NOTICE: This is a work-in-progress draft. Our community is working on refining this draft here: https://etherpad.openstack.org/p/magnum-native-api
Magnum's Native Container APIs
Magnum bays support native API access as well as a more limited form of wrapped access to that same functionality through a /container
resource in the Magnum API. This means that, depending on which bay type you select: Docker Swarm, Kubernetes, or Apache Mesos, you get the API that comes with that container orchestration engine. For example, if I create a Bay in Magnum using the Docker Swarm bay type, I will have an endpoint for the Docker API that I can interact with using the native docker
CLI tools.
Project Position on Native APIs
Magnum's contributors recognize the native API approach is preferred, as it offers users a more complete set of features and capabilities, and those can be updated without waiting for Magnum to re-implement them. It also allows for use of native tooling, which is the preferred user experience.
Use Cases for Magnum's "container" Resource
We are seeking production use cases for the /container
resource offered in the Magnum API. If you have one, please identify it here:
- Deploy containers from other OpenStack services. Expecting services to abstract every possible supported bay type is not scalable. A more precise example, I'd like trove to deploy DBs on containers and to do that, I'd like it to use Magnum's containers API. (flaper87)