api-ref: add missing parameters on container create
Change-Id: I4d21ff742d5d505f88b44f2daa9423326b2ae0a3
This commit is contained in:
parent
499863e18a
commit
c1ac26ad78
@ -55,6 +55,9 @@ Request
|
|||||||
- hostname: hostname
|
- hostname: hostname
|
||||||
- auto_remove: auto_remove
|
- auto_remove: auto_remove
|
||||||
- auto_heal: auto_heal
|
- auto_heal: auto_heal
|
||||||
|
- availability_zone: container_availability_zone
|
||||||
|
- hints: hints
|
||||||
|
- mounts: mounts
|
||||||
|
|
||||||
Request Example
|
Request Example
|
||||||
----------------
|
----------------
|
||||||
|
@ -228,6 +228,21 @@ container_actions:
|
|||||||
in: body
|
in: body
|
||||||
required: true
|
required: true
|
||||||
type: array
|
type: array
|
||||||
|
container_availability_zone:
|
||||||
|
in: body
|
||||||
|
type: string
|
||||||
|
required: true
|
||||||
|
description: |
|
||||||
|
The availability zone from which to run the container. Typically,
|
||||||
|
an admin user will use availability zones to arrange container hosts into
|
||||||
|
logical groups. An availability zone provides a form of physical isolation
|
||||||
|
and redundancy from other availability zones. For instance, if some racks
|
||||||
|
in your data center are on a separate power source, you can put containers
|
||||||
|
in those racks in their own availability zone. By segregating resources
|
||||||
|
into availability zones, you can ensure that your application resources are
|
||||||
|
spread across disparate machines to achieve high availability in the event
|
||||||
|
of hardware or other failure. You can see the available availability zones
|
||||||
|
by calling the ``services`` API.
|
||||||
container_list:
|
container_list:
|
||||||
type: array
|
type: array
|
||||||
in: body
|
in: body
|
||||||
@ -362,6 +377,12 @@ forced_down:
|
|||||||
in: body
|
in: body
|
||||||
required: true
|
required: true
|
||||||
type: boolean
|
type: boolean
|
||||||
|
hints:
|
||||||
|
description: |
|
||||||
|
The dictionary of data to send to the scheduler.
|
||||||
|
in: body
|
||||||
|
required: true
|
||||||
|
type: string
|
||||||
host:
|
host:
|
||||||
description: |
|
description: |
|
||||||
The host for the service.
|
The host for the service.
|
||||||
@ -441,6 +462,19 @@ message:
|
|||||||
in: body
|
in: body
|
||||||
required: true
|
required: true
|
||||||
type: string
|
type: string
|
||||||
|
mounts:
|
||||||
|
description: |
|
||||||
|
A list of dictionary data to specify how volumes are mounted into the
|
||||||
|
container. The container will mount the volumes at create time.
|
||||||
|
To provision a container with pre-existing Cinder volumes bind-mounted,
|
||||||
|
specify the UUID or name of the volume in the ``source`` attribute.
|
||||||
|
Alternatively, Cinder volumes can be dynamically created. In this case,
|
||||||
|
the size of the volume needs to be specified in the ``size`` attribute.
|
||||||
|
The volumes will be mounted into the file system of the container and
|
||||||
|
the path to mount the volume needs to be specified in the ``destination``
|
||||||
|
attribute.
|
||||||
|
in: body
|
||||||
|
type: object
|
||||||
name:
|
name:
|
||||||
description: |
|
description: |
|
||||||
The name of the container.
|
The name of the container.
|
||||||
|
Loading…
Reference in New Issue
Block a user