<html><body>
<p><font size="2" face="sans-serif">Hi Fox and Adrian,</font><br>
<br>
<font size="2" face="sans-serif">Let me summarize,</font><br>
<br>
<font size="2" face="sans-serif">1)</font><font size="2" face="sans-serif"><b> We all agree to replace 'platform' word to 'server_type' (let's not discuss this anymore)</b></font><br>
<br>
<br>
<font size="2" face="sans-serif">2) For bay-creation now in magnum,</font><br>
<br>
<font size="2" face="sans-serif">We pass it to baymodel.</font><br>
<br>
<font size="2" face="sans-serif">Cloud Operators created lots of baymodels, maybe, like kubernets-vm-baymodel, kubernetes-baremetal-baymodel.</font><br>
<br>
<font size="2" face="sans-serif">Cloud Users just select what kinds of baymodels they like(or they can create themselves, which depend on policy files)</font><br>
<br>
<font size="2" face="sans-serif">For example,</font><br>
<font size="2" color="#333333" face="Consolas">magnum baymodel-create --name k8sbaymodel \<br>
--image-id fedora-21-atomic-3 \<br>
--keypair-id testkey \<br>
--external-network-id ${NIC_ID} \<br>
--dns-nameserver 8.8.8.8 \<br>
--flavor-id m1.small \<br>
--docker-volume-size 5 \<br>
--coe kubernetes</font><br>
<br>
<br>
<font size="2" face="sans-serif">One question for if user want to create a kubernetes-baremetal-baymodel, he should input </font><font size="2" color="#333333" face="Consolas">flavor-id</font><font size="2" face="sans-serif"> with baremetal flavor.</font><br>
<br>
<font size="2" face="sans-serif"><b><i>Magnum template selection now:</i></b></font><br>
<font size="2" face="sans-serif"> </font><font size="2" face="sans-serif"><i> baymodel = conductor_utils.retrieve_baymodel(context, bay</i></font><font size="2" face="sans-serif"><i>)</i></font><br>
<font size="2" face="sans-serif"><i> cluster_distro = baymodel.cluster_distro</i></font><br>
<font size="2" face="sans-serif"><i> cluster_coe = baymodel.coe</i></font><br>
<font size="2" face="sans-serif"><i> definition = TDef.get_template_definition(</i></font><font size="2" face="sans-serif"><b><i>'vm'</i></b></font><font size="2" face="sans-serif"><i>, cluster_distro,</i></font><br>
<font size="2" face="sans-serif"><i> cluster_coe)</i></font><br>
<br>
<font size="2" face="sans-serif">You can find 'vm' is hardcode now, since ironic template not fully supported before. When I introduce ironic templates management. My first thought is here 'vm' should be code with baymodel.server_type.</font><br>
<font size="2" face="sans-serif">So I propose to create baymodel with one parameter --server_type baremetal (default is 'vm', if user not specified).</font><br>
<br>
<br>
<font size="2" face="sans-serif">This solution is simple, I think not make cloud-users confused. </font><br>
<font size="2" face="sans-serif">For example, if user want to deploy baremetal. they need specify baremeatl flavor. If they not know which flavor is baremetal, how can they boot baremetal instances?</font><br>
<font size="2" face="sans-serif">If they know they used baremetal flavor, they also know server_type is 'baremetal', not 'vm'. It seems not complicated. </font><br>
<br>
<br>
<font size="2" face="sans-serif">The nova support now for ironic, it needs customized flavors. need some metadata input. You can not boot successfully baremetal instance with m1.small flavors I think, as nova scheduling would thought it is not right.</font><br>
<br>
<br>
<br>
<font size="2" face="sans-serif">3) For you suppose use nova flavor, </font><br>
<br>
<font size="2" face="sans-serif"><i> definition = TDef.get_template_definition(</i></font><font size="2" face="sans-serif"><b><i>'vm'</i></b></font><font size="2" face="sans-serif"><i>, cluster_distro,</i></font><br>
<font size="2" face="sans-serif"><i> cluster_coe)</i></font><br>
<br>
<font size="2" face="sans-serif">Replace 'vm' to be with</font><br>
<font size="2" face="sans-serif"> if baymodel.flavor.metadata['***'],</font><br>
<font size="2" face="sans-serif"> server_type = 'baremeatal'</font><br>
<font size="2" face="sans-serif"> else</font><br>
<font size="2" face="sans-serif"> server_type = 'vm'</font><br>
<br>
<font size="2" face="sans-serif"><i> definition = TDef.get_template_definition(</i></font><font size="2" face="sans-serif">server_type</font><font size="2" face="sans-serif"><i>, cluster_distro,</i></font><br>
<font size="2" face="sans-serif"><i> cluster_coe)</i></font><br>
<br>
<font size="2" face="sans-serif">I think it seems not stable, Because 'vm' flavor can also have metadata.</font><br>
<font size="2" face="sans-serif">Does 'baremetal' metadatas have consistent tagging(officially released) ? (for x86, arm. power arch all applies)</font><br>
<br>
<font size="2" face="sans-serif"><b>I am open to use flavors to detect baremetal or 'vm', if metadata has consistent reliable fields. </b></font><br>
<br>
<br>
<br>
<font size="2" face="sans-serif">Thanks!</font><br>
<br>
<font size="2" face="sans-serif">Best Wishes,</font><br>
<font size="2" face="sans-serif">--------------------------------------------------------------------------------</font><br>
<font size="2" face="sans-serif">Kai Qiang Wu (吴开强 Kennan）<br>
IBM China System and Technology Lab, Beijing<br>
<br>
E-mail: wkqwu@cn.ibm.com<br>
Tel: 86-10-82451647<br>
Address: Building 28(Ring Building), ZhongGuanCun Software Park, <br>
No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193</font><br>
<font size="2" face="sans-serif">--------------------------------------------------------------------------------</font><br>
<font size="2" face="sans-serif">Follow your heart. You are miracle! </font><br>
<br>
<img width="16" height="16" src="cid:1__=C7BBF416DF99E6E28f9e8a93df938@cn.ibm.com" border="0" alt="Inactive hide details for "Fox, Kevin M" ---07/17/2015 08:30:25 AM---Adrian, I know for sure you can attach key=value metadata "><font size="2" color="#424282" face="sans-serif">"Fox, Kevin M" ---07/17/2015 08:30:25 AM---Adrian, I know for sure you can attach key=value metadata to the flavors. I just looked up in the ad</font><br>
<br>
<font size="1" color="#5F5F5F" face="sans-serif">From: </font><font size="1" face="sans-serif">"Fox, Kevin M" <Kevin.Fox@pnnl.gov></font><br>
<font size="1" color="#5F5F5F" face="sans-serif">To: </font><font size="1" face="sans-serif">"OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org></font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Date: </font><font size="1" face="sans-serif">07/17/2015 08:30 AM</font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Subject: </font><font size="1" face="sans-serif">Re: [openstack-dev] [magnum] [nova] Magnum template manage use platform VS others as a type?</font><br>
<hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br>
<br>
<br>
<font size="2" face="Tahoma">Adrian,</font><br>
<font size="2" face="Tahoma"><br>
I know for sure you can attach key=value metadata to the flavors. I just looked up in the admin guide, (</font><font size="2" face="Tahoma"><a href="http://docs.openstack.org/admin-guide-cloud/content/customize-flavors.html">http://docs.openstack.org/admin-guide-cloud/content/customize-flavors.html</a></font><font size="2" face="Tahoma">) and it mentions that the extra_specs key=value pairs are just used for scheduling though. :/<br>
<br>
So, Nova would have to be extended to support a non scheduled type of metadata (That could be useful for other things too...), but doesn't seem to exist today.<br>
<br>
One other possibility would be, if a nova scheduling filter can remove things from the extra_specs metadata before it hits the next plugin, we could slide in a MagnumFilter at the beginning of scheduler_default_filters that removes the magnum_server_type entry. Looking through the code, I think it would work, but makes me feel a little dirty too. I've attached an example that might be close to working for that... Maybe the Nova folks would like to weigh in if its a good plan or not?<br>
<br>
But, if the filter doesn't fly, then for Liberty it looks like your config option plan seems to be the best way to go.<br>
<br>
I like the plan, especially the default flavor/image. That should make it much easier to use if the user trusts what the admin setup for them. Nice and easy. :)<br>
<br>
Thanks,<br>
Kevin<br>
<br>
class MagnumFilter(filters.BaseHostFilter):<br>
def host_passes(self, host_state, filter_properties):<br>
try:<br>
del filter_properties['instance_type']['extra_specs']['magnum_server_type']<br>
except:<br>
pass<br>
return True<br>
</font><br>
<hr width="100%" size="2" align="left"><br>
<font size="2" face="Tahoma"><b>From:</b></font><font size="2" face="Tahoma"> Adrian Otto [adrian.otto@rackspace.com]</font><font size="2" face="Tahoma"><b><br>
Sent:</b></font><font size="2" face="Tahoma"> Thursday, July 16, 2015 2:51 PM</font><font size="2" face="Tahoma"><b><br>
To:</b></font><font size="2" face="Tahoma"> OpenStack Development Mailing List (not for usage questions)</font><font size="2" face="Tahoma"><b><br>
Subject:</b></font><font size="2" face="Tahoma"> Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type?</font><font size="3" face="Roman"><br>
</font><br>
<font size="3" face="Roman">Kevin,</font><br>
<br>
<font size="3" face="Roman">You make a really good point. Reducing required inputs from users in exchange for a little more setup by cloud operators is a well justified tradeoff. I'm pretty sure flavors in Nova can have tag Metadata added without a nova extension, right? Can someone check to be sure?</font><br>
<br>
<font size="3" face="Roman">If we do have a way to tag flavors, then let's default the value (as you said) to use in cases where the flavor is untagged, and make that configurable as a Magnum config directive. We could also log a warning each time the default is used unless the administrator disables the log notices in our config. That way we have a way to direct them to relevant documentation if they start using Magnum without tagging any flavors first.</font><br>
<br>
<font size="3" face="Roman">We should also mention flavor tagging in our various setup guides with references to detailed instructions.</font><br>
<br>
<font size="3" face="Roman">Let's also make sure that flavor and image args to bay_create also have a configurable default in Magnum for when they are omitted by the user.</font><br>
<br>
<font size="3" face="Roman">Adrian</font><br>
<font size="3" face="Roman"><br>
<br>
-------- Original message --------<br>
From: "Fox, Kevin M" <Kevin.Fox@pnnl.gov> <br>
Date: 07/16/2015 1:32 PM (GMT-08:00) <br>
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> <br>
Subject: Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type? <br>
</font><br>
<font size="2" face="Tahoma">Good point.<br>
<br>
+1 on server_type. it seems reasonable.<br>
<br>
As for the need, I'd really rather not have my users have to know how to map flavors to server_types themselves. Its something they will get wrong at times, and we'll get emails about/spend time explaining.<br>
<br>
The lack of heat conditionals has been unpleasant. I know its being worked on now, but not there yet.<br>
<br>
In talking with the heat developers, their current recommendation has been, put the conditional stuff as provider resources in different environment files, and make the template generic. (ala </font><a href="http://hardysteven.blogspot.com/2013/10/heat-providersenvironments-101-ive.html)." target="_blank"><font size="2" color="#0000FF" face="Tahoma"><u>http://hardysteven.blogspot.com/2013/10/heat-providersenvironments-101-ive.html).</u></font></a><font size="2" face="Tahoma"> You can then switch out one environment for another to switch things somewhat conditionally then. I'm not sure if this is flexible enough to handle the concern you have though.<br>
<br>
But, I think the conditional thing is not the real issue. Whether it supported proper conditionals, it would work with environments, or it would work with seperate templates, any way you slice it, you need some way to fetch which of the choices you want to specify. Either by being specified manually by the user, or some stored mapping in a config file, nova flavor metadata, or flavor mapping stored in the magnum db.<br>
<br>
So does the user provide that piece of information or does the admin attach it to the flavor some how? I'm all for the admin doing it, since I can do it when I setup the flavors/magnum and never have to worry about it again. Maybe even support a default = 'vm' so that I only have to go in and tag the ironic flavors as such. That means I only have to worry about tagging 1 or 2 flavors by hand, and the users don't have to do anything. A way better user experience for all involved.<br>
<br>
Thanks,<br>
Kevin<br>
</font><br>
<hr width="100%" size="2" align="left"><br>
<font size="2" face="Tahoma"><b>From:</b></font><font size="2" face="Tahoma"> Adrian Otto [adrian.otto@rackspace.com]</font><font size="2" face="Tahoma"><b><br>
Sent:</b></font><font size="2" face="Tahoma"> Thursday, July 16, 2015 12:35 PM</font><font size="2" face="Tahoma"><b><br>
To:</b></font><font size="2" face="Tahoma"> OpenStack Development Mailing List (not for usage questions)</font><font size="2" face="Tahoma"><b><br>
Subject:</b></font><font size="2" face="Tahoma"> Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type?</font><font size="3" face="Roman"><br>
</font><br>
<font size="3" face="Roman">To be clear we have two pursuits on this thread: </font><br>
<br>
<font size="3" face="Roman">1) What to rename bay.blatform to.</font><br>
<font size="3" face="Roman">2) How we might eliminate the attribute, or replace it with something more intuitive</font><br>
<br>
<font size="3" face="Roman">We have a consensus now on how to address #1. My direction to Kannan is to proceed using server_type as the new attribute name. If anyone disagrees, you can let us know now, or submit a subsequent patch to address that concern, and we can vote on it in Gerrit.</font><br>
<br>
<font size="3" face="Roman">On this subject of potentially eliminating, or replacing this attribute with something else, let’s continue to discuss that.</font><br>
<br>
<font size="3" face="Roman">One key issue is that our current HOT file format does not have any facility for conditional logic evaluation, so if the Bay orchestration differs between various server_type values, we need to select the appropriate value based on the way the bay is created. I’m open to hearing suggestions for implementing any needed conditional logic, if we can put it into a better place.</font><br>
<br>
<font size="3" face="Roman">Adrian</font><br>
<ul style="padding-left: 36pt"><font size="3" face="Roman">On Jul 16, 2015, at 8:54 AM, Fox, Kevin M <</font><a href="mailto:Kevin.Fox@pnnl.gov" target="_blank"><font size="3" color="#0000FF" face="Roman"><u>Kevin.Fox@pnnl.gov</u></font></a><font size="3" face="Roman">> wrote:</font><br>
<br>
<font size="2" face="Tahoma">Wait... so the issue is if you were to just use nova flavor, you don't have enough information to choose a set of templates that may be more optimal for that flavor type (like vm's or bare metal)? Is this a NaaS vs flatdhcp kind of thing? I just took a quick skim of the heat templates and it wasn't really clear why the template needs to know.<br>
<br>
If that sort of thing is needed, maybe allow a heat environment or the template set to be tagged onto nova flavors in Magnum by the admin, and then the user can be concerned only with nova flavors? They are use to dealing with them. Sahara and Trove do some similar things I think.<br>
<br>
Thanks,<br>
Kevin<br>
</font><br>
<hr width="100%" size="2" align="left"><br>
<font size="2" face="Tahoma"><b>From:</b></font><font size="2" face="Tahoma"> Hongbin Lu [</font><a href="mailto:hongbin.lu@huawei.com" target="_blank"><font size="2" color="#0000FF" face="Tahoma"><u>hongbin.lu@huawei.com</u></font></a><font size="2" face="Tahoma">]</font><font size="2" face="Tahoma"><b><br>
Sent:</b></font><font size="2" face="Tahoma"> Wednesday, July 15, 2015 8:42 PM</font><font size="2" face="Tahoma"><b><br>
To:</b></font><font size="2" face="Tahoma"> OpenStack Development Mailing List (not for usage questions)</font><font size="2" face="Tahoma"><b><br>
Subject:</b></font><font size="2" face="Tahoma"> Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type?</font><font size="3" face="Times New Roman"><br>
</font><br>
<font size="2" color="#1F497D" face="Calibri">Kai,</font><br>
<font size="2" color="#1F497D" face="Calibri"> </font><br>
<font size="2" color="#1F497D" face="Calibri">Sorry for the confusion. To clarify, I was thinking how to name the field you proposed in baymodel [1]. I prefer to drop it and use the existing field ‘flavor’ to map the Heat template.</font><br>
<font size="2" color="#1F497D" face="Calibri"> </font><br>
<font size="2" color="#1F497D" face="Calibri">[1] </font><a href="https://review.openstack.org/#/c/198984/6" target="_blank"><font size="2" color="#800080" face="Calibri"><u>https://review.openstack.org/#/c/198984/6</u></font></a><br>
<font size="2" color="#1F497D" face="Calibri"> </font><br>
<font size="2" face="Tahoma"><b>From:</b></font><font size="2" face="Tahoma"> Kai Qiang Wu [</font><a href="mailto:wkqwu@cn.ibm.com" target="_blank"><font size="2" color="#0000FF" face="Tahoma"><u>mailto:wkqwu@cn.ibm.com</u></font></a><font size="2" face="Tahoma">] </font><font size="2" face="Tahoma"><b><br>
Sent:</b></font><font size="2" face="Tahoma"> July-15-15 10:36 PM</font><font size="2" face="Tahoma"><b><br>
To:</b></font><font size="2" face="Tahoma"> OpenStack Development Mailing List (not for usage questions)</font><font size="2" face="Tahoma"><b><br>
Subject:</b></font><font size="2" face="Tahoma"> Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type?</font><br>
<font size="3" face="serif"> </font><br>
<font size="2" face="Arial">Hi HongBin,</font><font size="3" face="serif"><br>
</font><font size="2" face="Arial"><br>
I think flavors introduces more confusion than nova_instance_type or instance_type.</font><font size="3" face="serif"><br>
<br>
</font><font size="2" face="Arial"><br>
As flavors not have binding with 'vm' or 'baremetal',</font><font size="3" face="serif"><br>
</font><font size="2" face="Arial"><br>
Let me summary the initial question: <br>
We have two kinds of templates for kubernetes now, <br>
(as templates in heat not flexible like programming language, if else etc. And separate templates are easy to maintain)<br>
The two kinds of kubernets templates, One for boot VM, another boot Baremetal. 'VM' or Baremetal here is just used for heat template selection.</font><font size="3" face="serif"><br>
<br>
</font><font size="2" face="Arial"><br>
1> If used flavor, it is nova specific concept: take two as example, <br>
m1.small, or m1.middle. <br>
m1.small < 'VM' m1.middle < 'VM' <br>
Both m1.small and m1.middle can be used in 'VM' environment.<br>
So we should not use m1.small as a template identification. That's why I think flavor not good to be used.</font><font size="3" face="serif"><br>
<br>
</font><font size="2" face="Arial"><br>
2> @Adrian, we have --flavor-id field for baymodel now, it would picked up by heat-templates, and boot instances with such flavor.</font><font size="3" face="serif"><br>
<br>
</font><font size="2" face="Arial"><br>
3> Finally, I think instance_type is better. instance_type can be used as heat templates identification parameter.</font><font size="3" face="serif"><br>
</font><font size="2" face="Arial"><br>
instance_type = 'vm', it means such templates fit for normal 'VM' heat stack deploy</font><font size="3" face="serif"><br>
</font><font size="2" face="Arial"><br>
instance_type = 'baremetal', it means such templates fit for ironic baremetal heat stack deploy.</font><font size="3" face="serif"><br>
<br>
<br>
<br>
<br>
</font><font size="2" face="Arial"><br>
Thanks!</font><font size="3" face="serif"><br>
</font><font size="2" face="Arial"><br>
<br>
Best Wishes,<br>
--------------------------------------------------------------------------------<br>
Kai Qiang Wu (</font><font size="2" face="serif">吴开强</font><font size="2" face="Arial"> Kennan</font><font size="2" face="serif">）</font><font size="2" face="Arial"><br>
IBM China System and Technology Lab, Beijing<br>
<br>
E-mail: </font><a href="mailto:wkqwu@cn.ibm.com" target="_blank"><font size="2" color="#800080" face="Arial"><u>wkqwu@cn.ibm.com</u></font></a><font size="2" face="Arial"><br>
Tel: 86-10-82451647<br>
Address: Building 28(Ring Building), ZhongGuanCun Software Park, <br>
No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193<br>
--------------------------------------------------------------------------------<br>
Follow your heart. You are miracle! </font><font size="3" face="serif"><br>
<br>
<image001.gif></font><font size="2" color="#424282" face="Arial">Hongbin Lu ---07/16/2015 04:44:14 AM---+1 for the idea of using Nova flavor directly. Why we introduced the “platform” field to indicate “v</font><font size="3" face="serif"><br>
</font><font size="1" color="#5F5F5F" face="Arial"><br>
From: </font><font size="1" face="Arial">Hongbin Lu <</font><a href="mailto:hongbin.lu@huawei.com" target="_blank"><font size="1" color="#800080" face="Arial"><u>hongbin.lu@huawei.com</u></font></a><font size="1" face="Arial">></font><font size="1" color="#5F5F5F" face="Arial"><br>
To: </font><font size="1" face="Arial">"OpenStack Development Mailing List (not for usage questions)" <</font><a href="mailto:openstack-dev@lists.openstack.org" target="_blank"><font size="1" color="#800080" face="Arial"><u>openstack-dev@lists.openstack.org</u></font></a><font size="1" face="Arial">></font><font size="1" color="#5F5F5F" face="Arial"><br>
Date: </font><font size="1" face="Arial">07/16/2015 04:44 AM</font><font size="1" color="#5F5F5F" face="Arial"><br>
Subject: </font><font size="1" face="Arial">Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type?</font><br>
<hr width="100%" size="2" align="left" noshade style="color:#000000; "><br>
<font size="3" face="serif"><br>
<br>
</font><font size="2" color="#1F497D" face="Calibri"><br>
+1 for the idea of using Nova flavor directly.<br>
<br>
Why we introduced the “platform” field to indicate “vm” or “baremetel” is that magnum need to map a bay to a Heat template (which will be used to provision the bay). Currently, Magnum has three layers of mapping:</font>
<ul style="padding-left: 36pt"><font size="2" color="#1F497D" face="Symbol">・ </font><font size="2" color="#1F497D" face="serif"> </font><font size="2" color="#1F497D" face="Symbol"> </font><font size="2" color="#1F497D" face="serif"> </font><font size="2" color="#1F497D" face="Symbol"> </font><font size="2" color="#1F497D" face="serif"> </font><font size="2" color="#1F497D" face="Symbol"> </font><font size="2" color="#1F497D" face="serif"> </font><font size="2" color="#1F497D" face="Symbol"> </font><font size="2" color="#1F497D" face="Calibri">platform: vm or baremetal</font><font size="2" color="#1F497D" face="Symbol"><br>
・ </font><font size="2" color="#1F497D" face="serif"> </font><font size="2" color="#1F497D" face="Symbol"> </font><font size="2" color="#1F497D" face="serif"> </font><font size="2" color="#1F497D" face="Symbol"> </font><font size="2" color="#1F497D" face="serif"> </font><font size="2" color="#1F497D" face="Symbol"> </font><font size="2" color="#1F497D" face="serif"> </font><font size="2" color="#1F497D" face="Symbol"> </font><font size="2" color="#1F497D" face="Calibri">os: atomic, coreos, …</font><font size="2" color="#1F497D" face="Symbol"><br>
・ </font><font size="2" color="#1F497D" face="serif"> </font><font size="2" color="#1F497D" face="Symbol"> </font><font size="2" color="#1F497D" face="serif"> </font><font size="2" color="#1F497D" face="Symbol"> </font><font size="2" color="#1F497D" face="serif"> </font><font size="2" color="#1F497D" face="Symbol"> </font><font size="2" color="#1F497D" face="serif"> </font><font size="2" color="#1F497D" face="Symbol"> </font><font size="2" color="#1F497D" face="Calibri">coe: kubernetes, swarm or mesos</font></ul>
<font size="2" color="#1F497D" face="Calibri"> <br>
I think we could just replace “platform” with “flavor”, if we can populate a list of flovars for VM and another list of flavors for baremetal (We may need an additional list of flavors for container in the future for the nested container use case). Then, the new three layers would be:</font>
<ul style="padding-left: 36pt"><font size="2" color="#1F497D" face="Symbol">・ </font><font size="2" color="#1F497D" face="serif"> </font><font size="2" color="#1F497D" face="Symbol"> </font><font size="2" color="#1F497D" face="serif"> </font><font size="2" color="#1F497D" face="Symbol"> </font><font size="2" color="#1F497D" face="serif"> </font><font size="2" color="#1F497D" face="Symbol"> </font><font size="2" color="#1F497D" face="serif"> </font><font size="2" color="#1F497D" face="Symbol"> </font><font size="2" color="#1F497D" face="Calibri">flavor: baremetal, m1.small, m1.medium, …</font><font size="2" color="#1F497D" face="Symbol"><br>
・ </font><font size="2" color="#1F497D" face="serif"> </font><font size="2" color="#1F497D" face="Symbol"> </font><font size="2" color="#1F497D" face="serif"> </font><font size="2" color="#1F497D" face="Symbol"> </font><font size="2" color="#1F497D" face="serif"> </font><font size="2" color="#1F497D" face="Symbol"> </font><font size="2" color="#1F497D" face="serif"> </font><font size="2" color="#1F497D" face="Symbol"> </font><font size="2" color="#1F497D" face="Calibri">os: atomic, coreos, ...</font><font size="2" color="#1F497D" face="Symbol"><br>
・ </font><font size="2" color="#1F497D" face="serif"> </font><font size="2" color="#1F497D" face="Symbol"> </font><font size="2" color="#1F497D" face="serif"> </font><font size="2" color="#1F497D" face="Symbol"> </font><font size="2" color="#1F497D" face="serif"> </font><font size="2" color="#1F497D" face="Symbol"> </font><font size="2" color="#1F497D" face="serif"> </font><font size="2" color="#1F497D" face="Symbol"> </font><font size="2" color="#1F497D" face="Calibri">coe: kubernetes, swarm or mesos</font></ul>
<font size="2" color="#1F497D" face="Calibri"> <br>
This approach can avoid introducing a new field in baymodel to indicate what Nova flavor already indicates.<br>
<br>
Best regards,<br>
Hongbin<br>
</font><font size="2" face="Tahoma"><b><br>
From:</b></font><font size="2" face="Tahoma"> Fox, Kevin M [</font><a href="mailto:Kevin.Fox@pnnl.gov" target="_blank"><font size="2" color="#800080" face="Tahoma"><u>mailto:Kevin.Fox@pnnl.gov</u></font></a><font size="2" face="Tahoma">] </font><font size="2" face="Tahoma"><b><br>
Sent:</b></font><font size="2" face="Tahoma"> July-15-15 12:37 PM</font><font size="2" face="Tahoma"><b><br>
To:</b></font><font size="2" face="Tahoma"> OpenStack Development Mailing List (not for usage questions)</font><font size="2" face="Tahoma"><b><br>
Subject:</b></font><font size="2" face="Tahoma"> Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type?</font><font size="3" face="Arial"><br>
</font><font size="2" face="Tahoma"><br>
Maybe somehow I missed the point, but why not just use raw Nova flavors? They already abstract away irconic vs kvm vs hyperv/etc.<br>
<br>
Thanks,<br>
Kevin</font><div align="center"><hr width="100%" size="2" align="center"></div><font size="2" face="Tahoma"><b>From:</b></font><font size="2" face="Tahoma"> Daneyon Hansen (danehans) [</font><a href="mailto:danehans@cisco.com" target="_blank"><font size="2" color="#0000FF" face="Tahoma"><u>danehans@cisco.com</u></font></a><font size="2" face="Tahoma">]</font><font size="2" face="Tahoma"><b><br>
Sent:</b></font><font size="2" face="Tahoma"> Wednesday, July 15, 2015 9:20 AM</font><font size="2" face="Tahoma"><b><br>
To:</b></font><font size="2" face="Tahoma"> OpenStack Development Mailing List (not for usage questions)</font><font size="2" face="Tahoma"><b><br>
Subject:</b></font><font size="2" face="Tahoma"> Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type?</font><font size="2" face="Courier"><br>
All,</font><font size="2" face="Times New Roman"><br>
</font><font size="2" face="Courier"><br>
IMO virt_type does not properly describe bare metal deployments. What about using the compute_driver parameter?</font><font size="3" face="Times New Roman"><br>
</font><font size="3" face="Arial"><br>
compute_driver</font><font size="2" face="Times New Roman"> = </font><font size="3" face="Arial">None<br>
</font><font size="3" face="serif"><br>
</font><font size="3" face="Arial"><br>
(StrOpt) Driver to use for controlling virtualization. Options include: libvirt.LibvirtDriver, xenapi.XenAPIDriver, fake.FakeDriver, baremetal.BareMetalDriver, vmwareapi.VMwareVCDriver, hyperv.HyperVDriver<br>
</font><font size="3" face="serif"><br>
</font><font size="3" color="#800080" face="serif"><u><br>
</u></font><a href="http://docs.openstack.org/kilo/config-reference/content/list-of-compute-config-options.html" target="_blank"><font size="3" color="#800080" face="Arial"><u>http://docs.openstack.org/kilo/config-reference/content/list-of-compute-config-options.html</u></font></a><font size="3" color="#800080" face="serif"><u><br>
</u></font><a href="http://docs.openstack.org/developer/ironic/deploy/install-guide.html" target="_blank"><font size="3" color="#800080" face="Times New Roman"><u>http://docs.openstack.org/developer/ironic/deploy/install-guide.html</u></font></a><font size="2" face="Calibri"><br>
</font><font size="2" face="Calibri"><b><br>
From: </b></font><font size="2" face="Calibri">Adrian Otto <</font><a href="mailto:adrian.otto@rackspace.com" target="_blank"><font size="2" color="#800080" face="Calibri"><u>adrian.otto@rackspace.com</u></font></a><font size="2" face="Calibri">></font><font size="2" face="Calibri"><b><br>
Reply-To: </b></font><font size="2" face="Calibri">"OpenStack Development Mailing List (not for usage questions)" <</font><a href="mailto:openstack-dev@lists.openstack.org" target="_blank"><font size="2" color="#800080" face="Calibri"><u>openstack-dev@lists.openstack.org</u></font></a><font size="2" face="Calibri">></font><font size="2" face="Calibri"><b><br>
Date: </b></font><font size="2" face="Calibri">Tuesday, July 14, 2015 at 7:44 PM</font><font size="2" face="Calibri"><b><br>
To: </b></font><font size="2" face="Calibri">"OpenStack Development Mailing List (not for usage questions)" <</font><a href="mailto:openstack-dev@lists.openstack.org" target="_blank"><font size="2" color="#800080" face="Calibri"><u>openstack-dev@lists.openstack.org</u></font></a><font size="2" face="Calibri">></font><font size="2" face="Calibri"><b><br>
Subject: </b></font><font size="2" face="Calibri">Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type?<br>
</font>
<ul style="padding-left: 36pt"><font size="2" face="Calibri">One drawback to virt_type if not seen in the context of the acceptable values, is that it should be set to values like libvirt, xen, ironic, etc. That might actually be good. Instead of using the values 'vm' or 'baremetal', we use the name of the nova virt driver, and interpret those to be vm or baremetal types. So if I set the value to 'xen', I know the nova instance type is a vm, and 'ironic' means a baremetal nova instance. <br>
<br>
Adrian<br>
<br>
<br>
-------- Original message --------<br>
From: Hongbin Lu <</font><a href="mailto:hongbin.lu@huawei.com" target="_blank"><font size="2" color="#800080" face="Calibri"><u>hongbin.lu@huawei.com</u></font></a><font size="2" face="Calibri">> <br>
Date: 07/14/2015 7:20 PM (GMT-08:00) <br>
To: "OpenStack Development Mailing List (not for usage questions)" <</font><a href="mailto:openstack-dev@lists.openstack.org" target="_blank"><font size="2" color="#800080" face="Calibri"><u>openstack-dev@lists.openstack.org</u></font></a><font size="2" face="Calibri">> <br>
Subject: Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type? </font><font size="2" color="#1F497D" face="Calibri"><br>
I am going to propose a third option:<br>
<br>
3. virt_type<br>
<br>
I have concerns about option 1 and 2, because “instance_type” and flavor was used interchangeably before [1]. If we use “instance_type” to indicate “vm” or “baremetal”, it may cause confusions.<br>
<br>
[1] </font><a href="https://blueprints.launchpad.net/nova/+spec/flavor-instance-type-dedup" target="_blank"><font size="2" color="#800080" face="Calibri"><u>https://blueprints.launchpad.net/nova/+spec/flavor-instance-type-dedup</u></font></a><font size="2" color="#1F497D" face="Calibri"><br>
<br>
Best regards,<br>
Hongbin<br>
</font><font size="2" face="Tahoma"><b><br>
From:</b></font><font size="2" face="Tahoma"> Kai Qiang Wu [</font><a href="mailto:wkqwu@cn.ibm.com" target="_blank"><font size="2" color="#800080" face="Tahoma"><u>mailto:wkqwu@cn.ibm.com</u></font></a><font size="2" face="Tahoma">] </font><font size="2" face="Tahoma"><b><br>
Sent:</b></font><font size="2" face="Tahoma"> July-14-15 9:35 PM</font><font size="2" face="Tahoma"><b><br>
To:</b></font><font size="2" face="Tahoma"> </font><a href="mailto:openstack-dev@lists.openstack.org" target="_blank"><font size="2" color="#800080" face="Tahoma"><u>openstack-dev@lists.openstack.org</u></font></a><font size="2" face="Tahoma"><b><br>
Subject:</b></font><font size="2" face="Tahoma"> [openstack-dev] [magnum] Magnum template manage use platform VS others as a type?</font><font size="3" face="Arial"><br>
</font><font size="2" face="Arial"><br>
Hi Magnum Guys,</font><font size="3" face="Arial"><br>
</font><font size="2" face="Arial"><br>
<br>
I want to raise this question through ML.</font><font size="3" face="Arial"><br>
</font><font size="2" face="Arial"><br>
<br>
In this patch </font><a href="https://review.openstack.org/#/c/200401/" target="_blank"><font size="2" color="#800080" face="Arial"><u>https://review.openstack.org/#/c/200401/</u></font></a><font size="3" face="Arial"><br>
</font><font size="2" face="Arial"><br>
<br>
For some old history reason, we use </font><font size="2" face="Arial"><b>platform </b></font><font size="2" face="Arial">to indicate 'vm' or 'baremetal'.<br>
This seems not proper for that, @Adrian proposed nova_instance_type, and someone prefer other names, let me summarize as below:</font><font size="3" face="Arial"><br>
</font><font size="2" face="Arial"><br>
<br>
1. nova_instance_type 2 votes<br>
<br>
2. instance_type 2 votes<br>
<br>
3. others (1 vote, but not proposed any name)</font><font size="3" face="Arial"><br>
</font><font size="2" face="Arial"><br>
<br>
Let's try to reach the agreement ASAP. I think count the final votes winner as the proper name is the best solution(considering community diversity).</font><font size="3" face="Arial"><br>
</font><font size="2" face="Arial"><br>
<br>
BTW, If you not proposed any better name, just vote to disagree all, I think that vote is not valid and not helpful to solve the issue.</font><font size="3" face="Arial"><br>
</font><font size="2" face="Arial"><br>
<br>
Please help to vote for that name. </font><font size="3" face="Arial"><br>
</font><font size="2" face="Arial"><br>
<br>
Thanks</font><font size="3" face="Arial"><br>
<br>
<br>
</font><font size="2" face="Arial"><br>
<br>
Best Wishes,<br>
--------------------------------------------------------------------------------<br>
Kai Qiang Wu (</font><font size="2" face="serif">吴开强</font><font size="2" face="Arial"> Kennan</font><font size="2" face="serif">）</font><font size="2" face="Arial"><br>
IBM China System and Technology Lab, Beijing<br>
<br>
E-mail: </font><a href="mailto:wkqwu@cn.ibm.com" target="_blank"><font size="2" color="#800080" face="Arial"><u>wkqwu@cn.ibm.com</u></font></a><font size="2" face="Arial"><br>
Tel: 86-10-82451647<br>
Address: Building 28(Ring Building), ZhongGuanCun Software Park, <br>
No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193<br>
--------------------------------------------------------------------------------<br>
Follow your heart. You are miracle! </font><font size="2" face="serif">__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: </font><a href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank"><font size="2" color="#800080" face="serif"><u>OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</u></font></a><font size="2" color="#800080" face="serif"><u><br>
</u></font><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><font size="2" color="#800080" face="serif"><u>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</u></font></a></ul>
<br>
<font size="1" face="serif">__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: </font><a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank"><font size="1" color="#0000FF" face="serif"><u>OpenStack-dev-request@lists.openstack.org</u></font></a><font size="1" face="serif">?subject:unsubscribe</font><font size="1" color="#0000FF" face="serif"><u><br>
</u></font><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><font size="1" color="#0000FF" face="serif"><u>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</u></font></a></ul>
<tt><font size="2">__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
</font></tt><tt><font size="2"><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></font></tt><tt><font size="2"><br>
</font></tt><br>
</body></html>