Re: [openstack-dev] [magnum] [nova] Magnum template manage use platform VS others as a type?
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: 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!
From: Fox, Kevin M kevin@pnnl.gov
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@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
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.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
