[openstack-dev] [magnum] [nova] Magnum template manage use platform VS others as a type?
Kai Qiang Wu
wkqwu at cn.ibm.com
Fri Jul 17 02:22:43 UTC 2015
Hi Fox and Adrian,
Let me summarize,
1) We all agree to replace 'platform' word to 'server_type' (let's not
discuss this anymore)
2) For bay-creation now in magnum,
We pass it to baymodel.
Cloud Operators created lots of baymodels, maybe, like
kubernets-vm-baymodel, kubernetes-baremetal-baymodel.
Cloud Users just select what kinds of baymodels they like(or they can
create themselves, which depend on policy files)
For example,
magnum baymodel-create --name k8sbaymodel \
--image-id fedora-21-atomic-3 \
--keypair-id testkey \
--external-network-id ${NIC_ID} \
--dns-nameserver 8.8.8.8 \
--flavor-id m1.small \
--docker-volume-size 5 \
--coe kubernetes
One question for if user want to create a kubernetes-baremetal-baymodel, he
should input flavor-id with baremetal flavor.
Magnum template selection now:
baymodel = conductor_utils.retrieve_baymodel(context, bay)
cluster_distro = baymodel.cluster_distro
cluster_coe = baymodel.coe
definition = TDef.get_template_definition('vm', cluster_distro,
cluster_coe)
You can find 'vm' is hardcode now, since ironic template not fully
supported before. When I introduce ironic templates management. My first
thought is here 'vm' should be code with baymodel.server_type.
So I propose to create baymodel with one parameter --server_type baremetal
(default is 'vm', if user not specified).
This solution is simple, I think not make cloud-users confused.
For example, if user want to deploy baremetal. they need specify baremeatl
flavor. If they not know which flavor is baremetal, how can they boot
baremetal instances?
If they know they used baremetal flavor, they also know server_type is
'baremetal', not 'vm'. It seems not complicated.
The nova support now for ironic, it needs customized flavors. need some
metadata input. You can not boot successfully baremetal instance with
m1.small flavors I think, as nova scheduling would thought it is not right.
3) For you suppose use nova flavor,
definition = TDef.get_template_definition('vm', cluster_distro,
cluster_coe)
Replace 'vm' to be with
if baymodel.flavor.metadata['***'],
server_type = 'baremeatal'
else
server_type = 'vm'
definition = TDef.get_template_definition(server_type, cluster_distro,
cluster_coe)
I think it seems not stable, Because 'vm' flavor can also have metadata.
Does 'baremetal' metadatas have consistent tagging(officially released) ?
(for x86, arm. power arch all applies)
I am open to use flavors to detect baremetal or 'vm', if metadata has
consistent reliable fields.
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: "Fox, Kevin M" <Kevin.Fox at pnnl.gov>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Date: 07/17/2015 08:30 AM
Subject: Re: [openstack-dev] [magnum] [nova] Magnum template manage use
platform VS others as a type?
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.otto at 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.Fox at pnnl.gov>
Date: 07/16/2015 1:32 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?
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.otto at 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.Fox at 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.lu at 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: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!
<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.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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150717/e64e9cbd/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/20150717/e64e9cbd/attachment.gif>
More information about the OpenStack-dev
mailing list
