Adrian,

I know for sure you can attach key=value metadata to the flavors. I just looked 
up in the admin guide, 
(http://docs.openstack.org/admin-guide-cloud/content/customize-flavors.html) 
and it mentions that the extra_specs key=value pairs are just used for 
scheduling though. :/

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.

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?

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.

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

Thanks,
Kevin

class MagnumFilter(filters.BaseHostFilter):
      def host_passes(self, host_state, filter_properties):
        try:
          del 
filter_properties['instance_type']['extra_specs']['magnum_server_type']
        except:
          pass
        return True

________________________________
From: Adrian Otto [adrian.o...@rackspace.com]
Sent: Thursday, July 16, 2015 2:51 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?

Kevin,

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?

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.

We should also mention flavor tagging in our various setup guides with 
references to detailed instructions.

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.

Adrian


-------- Original message --------
From: "Fox, Kevin M" <kevin....@pnnl.gov>
Date: 07/16/2015 1:32 PM (GMT-08:00)
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [magnum] Magnum template manage use platform VS 
others as a type?

Good point.

+1 on server_type. it seems reasonable.

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.

The lack of heat conditionals has been unpleasant. I know its being worked on 
now, but not there yet.

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 
http://hardysteven.blogspot.com/2013/10/heat-providersenvironments-101-ive.html).
  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.

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.

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.

Thanks,
Kevin

________________________________
From: Adrian Otto [adrian.o...@rackspace.com]
Sent: Thursday, July 16, 2015 12:35 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?

To be clear we have two pursuits on this thread:

1) What to rename bay.blatform to.
2) How we might eliminate the attribute, or replace it with something more 
intuitive

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.

On this subject of potentially eliminating, or replacing this attribute with 
something else, let’s continue to discuss that.

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.

Adrian

On Jul 16, 2015, at 8:54 AM, Fox, Kevin M 
<kevin....@pnnl.gov<mailto:kevin....@pnnl.gov>> wrote:

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.

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.

Thanks,
Kevin

________________________________
From: Hongbin Lu [hongbin...@huawei.com<mailto:hongbin...@huawei.com>]
Sent: Wednesday, July 15, 2015 8:42 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?

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:wk...@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: wk...@cn.ibm.com<mailto:wk...@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!

<image001.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...@huawei.com<mailto:hongbin...@huawei.com>>
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@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....@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) [daneh...@cisco.com<mailto:daneh...@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.o...@rackspace.com<mailto:adrian.o...@rackspace.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, July 14, 2015 at 7:44 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@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...@huawei.com<mailto:hongbin...@huawei.com>>
Date: 07/14/2015 7:20 PM (GMT-08:00)
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@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:wk...@cn.ibm.com]
Sent: July-14-15 9:35 PM
To: openstack-dev@lists.openstack.org<mailto:openstack-dev@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: wk...@cn.ibm.com<mailto:wk...@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-requ...@lists.openstack.org?subject:unsubscribe<mailto:openstack-dev-requ...@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-requ...@lists.openstack.org<mailto:openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to