New flavor for baremetal servers
This spec proposes a new flavor for both general nodes and Valence nodes. Change-Id: I355a3f817eefb54a763314c6365c0b9d030988b3
This commit is contained in:
Zhenguo Niu
parent
605c0698c0
commit
5f58e34f1e
|
|
@ -0,0 +1,236 @@
|
|||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
==========
|
||||
New Flavor
|
||||
==========
|
||||
|
||||
https://blueprints.launchpad.net/mogan/+spec/new-flavor
|
||||
|
||||
Ironic added a "resource class" attribute to the primary node object represents
|
||||
the hardware specs. And not like VMs, baremetal nodes are consumed atomically,
|
||||
not piecemeal, so we would like to have the scheduler using a simplified search
|
||||
for the baremetal nodes that only looks for node that has a particular resource
|
||||
class.
|
||||
|
||||
Operators are the people who create the flavors and set the baremetal node
|
||||
resource class attribute, so we need to add a 'resources' field to the flavor
|
||||
which can include one or more resource classes (not only baremetal node, may
|
||||
also extend to add other resources later). And a 'description' field would be
|
||||
added for operators to fill the detail hardware profile.
|
||||
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
Currently, we just use the flavor name to match with the baremetal nodes,
|
||||
which is not flexible, as we also want to support associating one flavor to
|
||||
some different resource classes. And the detail hardware properties fields
|
||||
make the flavor too complex, we need to keep the flavor simple.
|
||||
|
||||
Use Cases
|
||||
---------
|
||||
|
||||
Operators and users wish to use a simple flavor/scheduler to search for
|
||||
baremetal nodes.
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
We proposes to add a resources field which can associate one or more resource
|
||||
classes with the required quantities, like I need $N this resource, but for
|
||||
baremetal node, it's atomic, so it always be 1. And we also need a description
|
||||
field for hardware profile. For Valence integration, the flavor.resources can
|
||||
also reference to a Valence flavor which include all detail required hardware
|
||||
properties.
|
||||
|
||||
The operator might define the flavors as such::
|
||||
|
||||
- baremetal-gold
|
||||
resources:
|
||||
CUSTOM_BAREMETAL_GOLD: 1
|
||||
resource_traits:
|
||||
CUSTOM_BAREMETAL_GOLD: FPGA
|
||||
description:
|
||||
Intel(R) Xeon(R) E5620 2.40GHz 16 cores, 8GB RAM
|
||||
|
||||
- baremetal-RSD-gold
|
||||
resources:
|
||||
valence-gold-flavor: 1
|
||||
resource_traits:
|
||||
valence-gold-flavor: PodM1
|
||||
description:
|
||||
Intel(R) Xeon(R) E5620 2.40GHz 16 cores, 8GB RAM
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
None
|
||||
|
||||
Data model impact
|
||||
-----------------
|
||||
|
||||
The proposed change will be adding the following fields to the flavor object
|
||||
with their data type and default value for migrations.
|
||||
|
||||
+-----------------------+--------------+-----------------+
|
||||
| Field Name | Field Type | Default Value |
|
||||
+=======================+==============+=================+
|
||||
| uuid | UUID | None |
|
||||
+-----------------------+--------------+-----------------+
|
||||
| name | String | None |
|
||||
+-----------------------+--------------+-----------------+
|
||||
| resources | DictOfString | None |
|
||||
+-----------------------+--------------+-----------------+
|
||||
| resource_traits | DictOfString | None |
|
||||
+-----------------------+--------------+-----------------+
|
||||
| description | String | None |
|
||||
+-----------------------+--------------+-----------------+
|
||||
| is_public | Bool | True |
|
||||
+-----------------------+--------------+-----------------+
|
||||
| disabled | Bool | False |
|
||||
+-----------------------+--------------+-----------------+
|
||||
|
||||
The `resources` field indicates the resource quantities and the
|
||||
`resource_traits` field reference to the resource qualities.
|
||||
|
||||
The `disabled` field is intended to be used when phasing out flavors. In this
|
||||
case, a delete wouldn't work because the flavor needs to still be available
|
||||
for live servers using that flavor, but we don't want to allow *new* servers
|
||||
created from that flavor. And we propose to deny deleting flavors if they are
|
||||
associated with servers.
|
||||
|
||||
REST API impact
|
||||
---------------
|
||||
|
||||
REST API will be changed as part of this change.
|
||||
|
||||
- To create a new flavor, a user will::
|
||||
|
||||
POST /v1/flavors
|
||||
|
||||
With a body containing the JSON description of the flavor.
|
||||
|
||||
JSON Schema::
|
||||
|
||||
{
|
||||
"type": "object",
|
||||
"properties": {
|
||||
'name': {'type': 'string', 'minLength': 1, 'maxLength': 255},
|
||||
'resources': {
|
||||
'type': 'object',
|
||||
'patternProperties': {
|
||||
'^[a-zA-Z0-9-_:. ]{1,255}$': {
|
||||
'type': 'integer', 'minimum': 1
|
||||
}
|
||||
},
|
||||
'additionalProperties': False
|
||||
},
|
||||
'resource_traits': {
|
||||
'type': 'object',
|
||||
'patternProperties': {
|
||||
'^[a-zA-Z0-9-_:. ]{1,255}$': {
|
||||
'type': 'string', 'maxLength': 255
|
||||
}
|
||||
},
|
||||
'additionalProperties': False
|
||||
},
|
||||
'description': {'type': 'string', 'minLength': 1},
|
||||
'disabled': {'type': 'boolean'},
|
||||
'is_public': {'type': 'boolean'},
|
||||
},
|
||||
'required': ['name', 'resources', 'description'],
|
||||
'additionalProperties': False,
|
||||
}
|
||||
|
||||
- To update a flavor, a user will::
|
||||
|
||||
PATCH /v1/flavors/flavor_uuid
|
||||
|
||||
We only allow to update below attributes::
|
||||
|
||||
['/name', '/is_public', '/disabled']
|
||||
|
||||
Example of request BODY::
|
||||
|
||||
{
|
||||
"op": "replace",
|
||||
"path": "/disabled",
|
||||
"value": true
|
||||
}
|
||||
|
||||
Update other properties is not allowed, as it will make server properties
|
||||
not consistent with the real hardware. Users need to create a new flavor
|
||||
instead in this scenario. And when creating a server, we will check if
|
||||
the specified flavor is disabled.
|
||||
|
||||
Security impact
|
||||
---------------
|
||||
|
||||
None
|
||||
|
||||
Notifications impact
|
||||
--------------------
|
||||
|
||||
None
|
||||
|
||||
Other end user impact
|
||||
---------------------
|
||||
|
||||
None
|
||||
|
||||
Performance Impact
|
||||
------------------
|
||||
|
||||
None
|
||||
|
||||
Other deployer impact
|
||||
---------------------
|
||||
|
||||
None
|
||||
|
||||
Developer impact
|
||||
----------------
|
||||
|
||||
None
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee:
|
||||
<niu-zglinux>
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
* Modify flavor object with the proposed fields.
|
||||
* Change REST API to support new flavor properties.
|
||||
* Change scheduler filters/weighters to match the new flavor.
|
||||
* Change CLI to support flavor management.
|
||||
* Add UT and docs.
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
None
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
Unit Testing will be added.
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
|
||||
Docs about new flavor will be added.
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
None
|
||||
Loading…
Reference in New Issue