Open Stack

Hi HongBin,

I think flavors introduces more confusion than nova_instance_type or
instance_type.


As flavors not have binding with 'vm' or 'baremetal',

Let me summary the initial question:
  We have two kinds of templates for kubernetes now,
(as templates in heat not flexible like programming language, if else etc.
And separate templates are easy to maintain)
The two kinds of kubernets templates,  One for boot VM, another boot
Baremetal. 'VM' or Baremetal here is just used for heat template selection.


1> If used flavor, it is nova specific concept: take two as example,
    m1.small, or m1.middle.
           m1.small < 'VM' m1.middle < 'VM'
           Both m1.small and m1.middle can be used in 'VM' environment.
So we should not use m1.small as a template identification. That's why I
think flavor not good to be used.


2> @Adrian, we have --flavor-id field for baymodel now, it would picked up
by heat-templates, and boot instances with such flavor.


3> Finally, I think instance_type is better.  instance_type can be used as
heat templates identification parameter.

instance_type = 'vm', it means such templates fit for normal 'VM' heat
stack deploy

instance_type = 'baremetal', it means such templates fit for ironic
baremetal heat stack deploy.





Thanks!


Best Wishes,
--------------------------------------------------------------------------------
Kai Qiang Wu (吴开强  Kennan）
IBM China System and Technology Lab, Beijing

E-mail: wkqwu at cn.ibm.com
Tel: 86-10-82451647
Address: Building 28(Ring Building), ZhongGuanCun Software Park,
         No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China
100193
--------------------------------------------------------------------------------
Follow your heart. You are miracle!



From:	Hongbin Lu <hongbin.lu at huawei.com>
To:	"OpenStack Development Mailing List (not for usage questions)"
            <openstack-dev at lists.openstack.org>
Date:	07/16/2015 04:44 AM
Subject:	Re: [openstack-dev] [magnum] Magnum template manage use
            platform VS others as a type?



+1 for the idea of using Nova flavor directly.

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:
      ・         platform: vm or baremetal
      ・         os: atomic, coreos, …
      ・         coe: kubernetes, swarm or mesos

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:
      ・         flavor: baremetal, m1.small, m1.medium,  …
      ・         os: atomic, coreos, ...
      ・         coe: kubernetes, swarm or mesos

This approach can avoid introducing a new field in baymodel to indicate
what Nova flavor already indicates.

Best regards,
Hongbin

From: Fox, Kevin M [mailto:Kevin.Fox at pnnl.gov]
Sent: July-15-15 12:37 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Magnum template manage use platform
VS others as a type?

Maybe somehow I missed the point, but why not just use raw Nova flavors?
They already abstract away irconic vs kvm vs hyperv/etc.

Thanks,
Kevin

From: Daneyon Hansen (danehans) [danehans at cisco.com]
Sent: Wednesday, July 15, 2015 9:20 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Magnum template manage use platform
VS others as a type?
All,

IMO virt_type does not properly describe bare metal deployments.  What
about using the compute_driver parameter?

compute_driver = None


(StrOpt) Driver to use for controlling virtualization. Options include:
libvirt.LibvirtDriver, xenapi.XenAPIDriver, fake.FakeDriver,
baremetal.BareMetalDriver, vmwareapi.VMwareVCDriver, hyperv.HyperVDriver


http://docs.openstack.org/kilo/config-reference/content/list-of-compute-config-options.html
http://docs.openstack.org/developer/ironic/deploy/install-guide.html

From: Adrian Otto <adrian.otto at rackspace.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
openstack-dev at lists.openstack.org>
Date: Tuesday, July 14, 2015 at 7:44 PM
To: "OpenStack Development Mailing List (not for usage questions)" <
openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [magnum] Magnum template manage use platform
VS others as a type?

 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.

 Adrian


 -------- Original message --------
 From: Hongbin Lu <hongbin.lu at huawei.com>
 Date: 07/14/2015 7:20 PM (GMT-08:00)
 To: "OpenStack Development Mailing List (not for usage questions)" <
 openstack-dev at lists.openstack.org>
 Subject: Re: [openstack-dev] [magnum] Magnum template manage use platform
 VS others as a type?
 I am going to propose a third option:

 3. virt_type

 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.

 [1] https://blueprints.launchpad.net/nova/+spec/flavor-instance-type-dedup

 Best regards,
 Hongbin

 From: Kai Qiang Wu [mailto:wkqwu at cn.ibm.com]
 Sent: July-14-15 9:35 PM
 To: openstack-dev at lists.openstack.org
 Subject: [openstack-dev] [magnum] Magnum template manage use platform VS
 others as a type?

 Hi Magnum Guys,


 I want to raise this question through ML.


 In this patch https://review.openstack.org/#/c/200401/


 For some old history reason, we use platform to indicate 'vm' or
 'baremetal'.
 This seems not proper for that, @Adrian proposed nova_instance_type, and
 someone prefer other names, let me summarize as below:


 1. nova_instance_type  2 votes

 2. instance_type 2 votes

 3. others (1 vote, but not proposed any name)


 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).


 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.


 Please help to vote for that name.


 Thanks




 Best Wishes,
 --------------------------------------------------------------------------------

 Kai Qiang Wu (吴开强  Kennan）
 IBM China System and Technology Lab, Beijing

 E-mail: wkqwu at cn.ibm.com
 Tel: 86-10-82451647
 Address: Building 28(Ring Building), ZhongGuanCun Software Park,
         No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China
 100193
 --------------------------------------------------------------------------------

 Follow your heart. You are miracle!
 __________________________________________________________________________
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150716/421caa91/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150716/421caa91/attachment.gif>