[openstack-dev] [magnum] Magnum template manage use platform VS others as a type?

Ton Ngo ton at us.ibm.com
Thu Jul 16 15:25:37 UTC 2015


+1, seems like the best choice.
Ton Ngo,



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 06:33 AM
Subject:	Re: [openstack-dev] [magnum] Magnum template manage use
            platform VS others as a type?



I am OK with server_type as well.

From: Kai Qiang Wu [mailto:wkqwu at cn.ibm.com]
Sent: July-16-15 3:22 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?



+ 1 about server_type.

I also think it is OK.


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!

(Embedded image moved to file: pic28496.gif)Inactive hide details for
Adrian Otto ---07/16/2015 03:18:04 PM---I’d be comfortable with
server_type. AdrianAdrian Otto ---07/16/2015 03:18:04 PM---I’d be
comfortable with server_type. Adrian

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




I’d be comfortable with server_type.

Adrian
      On Jul 15, 2015, at 11:51 PM, Jay Lau <jay.lau.513 at gmail.com> wrote:

      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/

            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!

            <graycol.gif>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

            From: Kai Qiang Wu [mailto: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
            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!

            <graycol.gif>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>
            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
                  __________________________________________________________________________

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

      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
__________________________________________________________________________
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 --------------
A non-text attachment was scrubbed...
Name: pic28496.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150716/29f503bf/attachment.gif>


More information about the OpenStack-dev mailing list