On Jul 15, 2015, at 1:39 PM, [email protected]<mailto:[email protected]> wrote:
+1 for the idea of using Nova flavor directly. Our initial resistance to using flavor is that you may want the same bay to have a combination of different flavors in it. I suppose this might still be possible by changing the flavor value in the bay, and then scaling it. 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, … Well, this would need to be a valid flavor name in nova for it to work. You might have several flavors that are all actually “baremetal”, so it would be up to the cloud operator to map all the flavors to the correct instance types. Perhaps it’s possible to determine which nova dirt driver would be used for each of the flavors, and look that up automatically in order to eliminate thinned for maintaining a mapping. • 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. It would also give us the ability to pass in a flavor id as a parameter to our heat templates to allow them to be more easily used with different flavor sizes. IT could send the value from the bay model initially, or from the bay once it exists. It would also be possible to implement a ‘scale bay’ operation that would also take this as a parameter so you could accomplish the equivalent of “add an 8GB node to this bay”, or "add a giant baremetal node to this bay”. Adrian Best regards, Hongbin From: Fox, Kevin M [mailto:[email protected]] 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) [[email protected]<mailto:[email protected]>] 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 <[email protected]<mailto:[email protected]>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <[email protected]<mailto:[email protected]>> Date: Tuesday, July 14, 2015 at 7:44 PM To: "OpenStack Development Mailing List (not for usage questions)" <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> Date: 07/14/2015 7:20 PM (GMT-08:00) To: "OpenStack Development Mailing List (not for usage questions)" <[email protected]<mailto:[email protected]>> 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:[email protected]] Sent: July-14-15 9:35 PM To: [email protected]<mailto:[email protected]> 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: [email protected]<mailto:[email protected]> 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: [email protected]<mailto:[email protected]>?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
