Hi all, Based on the discussion on the Train PTG, and reference to the records on the etherpad and ML, I was updated that SPEC, and I think there are some details need to be discussed, and I have listed some details, if there are any other things that I have not considered, or if some place that I thoughtless, please post a discussion.
List some details as follows, and you can review that spec in https://review.opendev.org/#/c/663563.
Listed details: - Don't change the model of the flavor in nova code and in the db.
- No change for operators who choose not to request the flavor extra specs group.
- Requested more than one flavor extra specs groups, if there are different values for the same spec will be raised a 409.
- Flavor in request body of server create that has the same spec in the request ``flavor_extra_specs_group``, it will be raised a 409.
- When resize an instance, you need to compare the ``flavor_extra_specs_group`` with the spec request spec, otherwise raise a 400.
---------------------------------------------------------------------------------------- Items: [lists.openstack.org代发][nova][ptg] Flavor explosion
original spec: https://review.opendev.org/#/c/663563 with -2s
The first round of discussion was resulted in no agreement. Then on Friday we revisited the issue based on mdbooth's proposal about composability.
Agreement in the room: * Do not try to change the model of the flavor in nova code and in the db. * Define a "ComposableFlavorBit" (bikeshed on the name please) REST API entity that can hold any kind of flavor bits (extra specs, normal flavor fields), propose some format in the spec for it. This entity can only be created by the admin by default * Extend the server create REST API to allow the end user to specify what "ComposableFlavorBit"s she wants to add to the "base" flavor she used in the create request. * The nova api then merges the "ComposableFalvorBit"s with the base flavor and embed the resulted flavor object into the instance. * Do a similar thing for resize
TODOs: * brinzhang (with possible help from yawang) to re-write the spec
Cheers, gibi
On Sun, Nov 10, 2019 at 16:09, Brin Zhang(张百林) zhangbailin@inspur.com wrote:
Hi all, Based on the discussion on the Train PTG, and reference to the records on the etherpad and ML, I was updated that SPEC, and I think there are some details need to be discussed, and I have listed some details, if there are any other things that I have not considered, or if some place that I thoughtless, please post a discussion.
List some details as follows, and you can review that spec in https://review.opendev.org/#/c/663563.
Listed details:
Don't change the model of the flavor in nova code and in the db.
No change for operators who choose not to request the flavor
extra specs group.
- Requested more than one flavor extra specs groups, if there are
different values for the same spec will be raised a 409.
- Flavor in request body of server create that has the same spec in
the request ``flavor_extra_specs_group``, it will be raised a 409.
- When resize an instance, you need to compare the
``flavor_extra_specs_group`` with the spec request spec, otherwise raise a 400.
Thanks Brin for updating the spec, I did a review round on it and left comments.
gibi
Hi all, The patch link is https://review.opendev.org/#/c/663563
Rename the bp name from "add-flavor-metadata-or-metadata-group" to "resources-metadata-of-instance", because it not only can compose the extra specs from the *flavor* (current status), and it can be compose the vcpu, ram and disk, I think call this is resource metadata is ok, if you have some suggestion please leave a comment. About the model design, there will be add two DB table in the nova api DB: a) Add "resources_metadata" to record the composable bits, as following fields: - id(int),create_at,updated_at,deleted_at, name, rules, description and deleted fields Saved format like this: { "cpu_pinning": { "hw:cpu_policy": "shared", "hw:cpu_thread_policy": "require" } } If there is one spec that you need, you can set it in the rules as {"key": value}, it means like this: { "mem_huge_page": { "hw:mem_page_size": "1GB" } } b) Add "resources_metadata_mapping" to record the composable bits used by which instance, as following fields: - created_at, updated_at,deleted_at, id(int), resources_md_id, instance_uuid and deleted fields.
With b, we have another alternative way, it was wrote in the "Alternatives" in the SPEC, it means add a column to the ``instance_medata`` table, but, this way we should separate the rule in the "resources_metadata" to one by one to save. This way will change the existing data table structure, I am not sure if this will affect some of the features of the instance. (more details you can review this SPEC)
We can get all the metadata used by an instance (instance_uuid) through the "resources_metadata_mapping" table easily.
Items: Re: [nova][ptg] Flavor explosion
On Sun, Nov 10, 2019 at 16:09, Brin Zhang(张百林) zhangbailin@inspur.com wrote:
Hi all, Based on the discussion on the Train PTG, and reference to the records on the etherpad and ML, I was updated that SPEC, and I think there are some details need to be discussed, and I have listed some details, if there are any other things that I have not considered, or if some place that I thoughtless, please post a discussion.
List some details as follows, and you can review that spec in https://review.opendev.org/#/c/663563.
Listed details:
Don't change the model of the flavor in nova code and in the db.
No change for operators who choose not to request the flavor extra
specs group.
- Requested more than one flavor extra specs groups, if there are
different values for the same spec will be raised a 409.
- Flavor in request body of server create that has the same spec in
the request ``flavor_extra_specs_group``, it will be raised a 409.
- When resize an instance, you need to compare the
``flavor_extra_specs_group`` with the spec request spec, otherwise raise a 400.
Thanks Brin for updating the spec, I did a review round on it and left comments.
gibi
participants (2)
-
Balázs Gibizer
-
Brin Zhang(张百林)