[openstack-dev] [magnum] Magnum template manage use platform VS others as a type?
Jay Lau
jay.lau.513 at gmail.com
Thu Jul 16 06:51:44 UTC 2015
After more thinking, I agree with Hongbin that instance_type might make
customer confused with flavor, what about using server_type?
Actually, nova has concept of server group, the "servers" in this group can
be vm. pm or container.
Thanks!
2015-07-16 11:58 GMT+08:00 Kai Qiang Wu <wkqwu at cn.ibm.com>:
> Hi Hong Bin,
>
> Thanks for your reply.
>
>
> I think it is better to discuss the 'platform' Vs instance_type Vs others
> case first.
> Attach: initial patch (about the discussion):
> *https://review.openstack.org/#/c/200401/*
> <https://review.openstack.org/#/c/200401/>
>
> My other patches all depend on above patch, if above patch can not reach a
> meaningful agreement.
>
> My following patches would be blocked by that.
>
>
>
> 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!
>
> [image: Inactive hide details for Hongbin Lu ---07/16/2015 11:47:30
> AM---Kai, Sorry for the confusion. To clarify, I was thinking how t]Hongbin
> Lu ---07/16/2015 11:47:30 AM---Kai, Sorry for the confusion. To clarify, I
> was thinking how to name the field you proposed in baymo
>
> 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 11:47 AM
>
> Subject: Re: [openstack-dev] [magnum] Magnum template manage use platform
> VS others as a type?
> ------------------------------
>
>
>
> Kai,
>
> 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.
>
> [1] *https://review.openstack.org/#/c/198984/6*
> <https://review.openstack.org/#/c/198984/6>
>
> *From:* Kai Qiang Wu [mailto:wkqwu at cn.ibm.com <wkqwu at cn.ibm.com>]
> * Sent:* July-15-15 10:36 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?
>
>
> 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* <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!
>
> [image: Inactive hide details for Hongbin Lu ---07/16/2015 04:44:14
> AM---+1 for the idea of using Nova flavor directly. Why we introduc]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
>
> From: Hongbin Lu <*hongbin.lu at huawei.com* <hongbin.lu at huawei.com>>
> To: "OpenStack Development Mailing List (not for usage questions)" <
> *openstack-dev at lists.openstack.org* <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* <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/kilo/config-reference/content/list-of-compute-config-options.html>
> *http://docs.openstack.org/developer/ironic/deploy/install-guide.html*
> <http://docs.openstack.org/developer/ironic/deploy/install-guide.html>
>
> * From: *Adrian Otto <*adrian.otto at rackspace.com*
> <adrian.otto at rackspace.com>>
> * Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" <*openstack-dev at lists.openstack.org*
> <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* <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* <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* <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*
> <https://blueprints.launchpad.net/nova/+spec/flavor-instance-type-dedup>
>
> Best regards,
> Hongbin
>
> * From:* Kai Qiang Wu [*mailto:wkqwu at cn.ibm.com* <wkqwu at cn.ibm.com>]
> * Sent:* July-14-15 9:35 PM
> * To:* *openstack-dev at lists.openstack.org*
> <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/*
> <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* <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*
> <OpenStack-dev-request at lists.openstack.org?subject:unsubscribe>
> *http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev*
> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
> __________________________________________________________________________
> 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
>
>
>
> __________________________________________________________________________
> 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
>
>
--
Thanks,
Jay Lau (Guangya Liu)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150716/6b887843/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/6b887843/attachment.gif>
More information about the OpenStack-dev
mailing list
