Hi Eli,
Because we want the 1 magnum bay support N flavor to provision minion nodes and
each flavor has multiply minion nodes, so it must be assign the percentage of
minion nodes for each flavor. So it is the percentage of minion nodes for each
flavor in the baymodel.
The -�Cnode-count is the total minion node number. it should to calculate the
percentage of minion nodes with total node count for each flavor when creating
a magnum bay.
Thanks && Best Regards
Mike
> hi Mike
> One questions:
> Currently, we can specify --master-count --node-count when creating a
> bay, so how will that work if you have defined the nodes count in baymodel?
> I think we need some rethinking here.
> Eli.
On 2016年04月26日 15:00, Ma, Wen-Tao (Mike, HP Servers-PSC-BJ) wrote:
> Hi Hongbin, Ricardo
> This is mike, I am working with Gary now.
> Thanks for Ricardo's good suggestion. I have tried the "map/index" method ,
> we can use it to passed the minion_flavor_map and the index into the minion
> cluster stack. It does work well.
> I think we can update magnum baymodel-create to set the N minion flavors in
> the minion_flavor_map and assign minion counts for each flavor.
> For example :
> magnum baymodel-create --name k8s-bay-model --flavor-id
> minion-flavor-0:3,minion-flavor-1:5, minion-flavor-2:2. It will create 3
> types flavor minion node and total minion nodes count is 10. The magnum
> baymode.py will parse this dictionary and pass them to the heat template
> parameters minion_flavor_map, minion_flavor_count_map. Then the heat stack
> will work well.
>
> kubecluster-fedora-ironic.yaml
> parameters:
> minion_flavor_map:
> type: json
> default:
> '0': minion-flavor-0
> '1': minion-flavor-1
> '2': minion-flavor-2
>
> minion_flavor_count_map:
> type: json
> default:
> '0': 3
> '1': 5
> '2': 2
>
> resources:
> kube_minions_flavors:
> type: OS::Heat::ResourceGroup
> properties:
> count: { get_param: minion_flavors_counts }
> resource_def:
> type: kubecluster-minion-fedora-ironic.yaml
> properties:
> minion_flavor_map: {get_param: minion_flavor_map}
> minion_flavor_count_map: {get_param: minion_flavor_count_map}
> minion_flavor_index: '%index%'
>
> How do you think about this interface in magnum baymodel to support N falvor
> to provision minion nodes? Do you have any comments about this design for
> this feature?
>
> Thanks && Regards
> Mike Ma
> HP Servers Core Platform Software China Email wentao.ma at
> hpe.com<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
> -----Original Message-----
> From: Duan, Li-Gong (Gary, HPServers-Core-OE-PSC)
> Sent: Monday, April 25, 2016 3:37 PM
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev at
> lists.openstack.org<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>>
> Cc: Ma, Wen-Tao (Mike, HP Servers-PSC-BJ) <wentao.ma at
> hpe.com<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>>
> Subject: RE: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to
> provision minion nodes
>
> Hi Ricardo,
>
> This is really good suggestion. I'd like to see whether we can use
> "foreach"/"repeat" in ResourceGroup in Heat.
>
> Regards,
> Gary Duan
>
> -----Original Message-----
> From: Ricardo Rocha [mailto:rocha.porto at
> gmail.com<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>]
> Sent: Thursday, April 21, 2016 3:49 AM
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev at
> lists.openstack.org<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>>
> Subject: Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to
> provision minion nodes
>
> Hi Hongbin.
>
> On Wed, Apr 20, 2016 at 8:13 PM, Hongbin Lu <hongbin.lu at
> huawei.com<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>>
> wrote:
>>
>>
>>
>> From: Duan, Li-Gong (Gary, HPServers-Core-OE-PSC)
>> [mailto:li-gong.duan at
>> hpe.com<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>]
>> Sent: April-20-16 3:39 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to
>> provision minion nodes
>>
>>
>>
>> Hi Folks,
>>
>>
>>
>> We are considering whether Magnum can supports 2 Nova flavors to
>> provision Kubernetes and other COE minion nodes.
>>
>> This requirement comes from the below use cases:
>>
>> - There are 2 kind of baremetal machines in customer site: one is
>> legacy machines which doesn’t support UEFI secure boot and others are
>> new machines which support UEFI secure boot. User want to use Magnum
>> to provisions a Magnum bay of Kubernetes from these 2 kind of
>> baremetal machines and for the machines supporting secure boot, user
>> wants to use UEFI secure boot to boot them up. And 2 Kubernetes
>> label(secure-booted and
>> non-secure-booted) are created and User can deploy their
>> data-senstive/cirtical workload/containers/pods on the baremetal
>> machines which are secure-booted.
>>
>>
>>
>> This requirement requires Magnum to supports 2 Nova flavors(one is
>> “extra_spec: secure_boot=True” and the other doesn’t specify it) based
>> on the Ironic
>> feature(https://specs.openstack.org/openstack/ironic-specs/specs/kilo-
>> implemented/uefi-secure-boot.html
>> ).
>>
>>
>>
>> Could you kindly give me some comments on these requirement or whether
>> it is reasonable from your point? If you agree, we can write design
>> spec and implement this feature?
>>
>>
>>
>> I think the requirement is reasonable, but I would like to solve the
>> problem in a generic way. In particular, there could be another user
>> who might ask for N nova flavors to provision COE nodes in the future.
>> A challenge to support N groups of Nova instances is how to express
>> arbitrary number of resource groups (with different flavors) in a Heat
>> template (Magnum uses Heat template to provision COE clusters). Heat
>> doesn’t seem to support the logic of looping from 1 to N. There could
>> be other challenges/complexities along the way. If the proposed design
>> can address all the challenges and the implementation is clean, I am
>> OK to add support for this feature. Thoughts from others?
> This looks similar to the way we looked at passing a list of availability
> zones. Mathieu asked and got a good answer:
> http://lists.openstack.org/pipermail/openstack-dev/2016-March/088175.html
>
> Something similar can probably be used to pass multiple flavors? Just in case
> it helps.
>
> Cheers,
> Ricardo
>
>>
>>
>> Regards,
>>
>> Gary
>>
>>
>> ______________________________________________________________________
>> ____ OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at
>> lists.openstack.org<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>?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<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>?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<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> --
> Best Regards, Eli Qiao (乔立勇)
> Intel OTC China
-------------- next part --------------
A non-text attachment was scrubbed...
Name: liyong_qiao.vcf
Type: text/x-vcard
Size: 123 bytes
Desc: not available
URL:
<http://lists.openstack.org/pipermail/openstack-dev/attachments/20160426/8890d7c8/attachment.vcf>
Mike Ma
HP Servers Core Platform Software China
Mobile +86 18610248322
Email wentao...@hpe.com<mailto:wentao...@hpe.com>
[http://h71028.www7.hp.com/hpe_logo_email_signature/HPE_logo_email_signature.png]<http://www.hpe.com/>
__________________________________________________________________________
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
