diff --git a/specs/pike/approved/new-flavor.rst b/specs/pike/approved/new-flavor.rst
new file mode 100644
index 0000000..a28f227
--- /dev/null
+++ b/specs/pike/approved/new-flavor.rst
@@ -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