Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes
Hi Eli,
Copy that, I will consider that. Thanks.
Regards
Mike
Date: Thu, 28 Apr 2016 17:05:44 +0800
From: Eli Qiao <liyong.q...@intel.com<mailto:liyong.q...@intel.com>>
To: openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to
provision minion nodes
Message-ID: <5721d268.4040...@intel.com<mailto:5721d268.4040...@intel.com>>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
hi Mike
Can you please also consider the effect to do rebuild/resize a bay if you want
to support more than 1 nova flavor?
There are some discussion while in Austin summit, check
https://etherpad.openstack.org/p/newton-magnum-bays-lifecycle-operations
Thanks
Eli.
On 2016?04?28? 16:52, Ma, Wen-Tao (Mike, HP Servers-PSC-BJ) wrote:
>
> Hi Kai Qiang,
>
> Thanks for your comments, your consideration is very comprehensive, I
> think it is a good way to implement this feature.
>
> Regards
>
> Mike
>
> Date: Wed, 27 Apr 2016 17:38:32 +0800
>
> From: "Kai Qiang Wu" <wk...@cn.ibm.com<mailto:wk...@cn.ibm.com>>
>
> 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 supports 2 Nova flavor to
>
> provision minion nodes
>
> Message-ID:
> <201604271004.u3ra49v4008...@d23av04.au.ibm.com<mailto:201604271004.u3ra49v4008...@d23av04.au.ibm.com>>
>
> Content-Type: text/plain; charset="gb2312"
>
> Hi Mike,
>
> Since right now, we have also support bay-update (node_count)
>
> I am thinking the following case:
>
> 1> baymodel-create have default flavor, and extra labels specify
> the(other
>
> node flavors) requirements,
>
> if (other node flavors) count <= bay(node_count), the extra nodes
> would be
>
> created use default flavor
>
> if (other node flavors) count > bay(node_count), it should pop error,
>
> since it not quite clear why flavor to use
>
> 2> magnum bay-update k8sbay replace node_count < existed node_count,
> 2> it
>
> should be OK. same as old behavior
>
> if node_count > existed node_count, all new nodes would use
> default
>
> flavor_id, (if not, we need to find what's the better policy to handle
>
> that)
>
> Refer:
>
> https://github.com/openstack/magnum/blob/master/doc/source/dev/quickst
> art.rst
>
> What do you think ?
>
> 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!
>
> From: "Ma, Wen-Tao (Mike, HP Servers-PSC-BJ)"
> <wentao...@hpe.com<mailto:wentao...@hpe.com>>
>
> To:
> "openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>"
>
> <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
>
> Date: 27/04/2016 03:10 pm
>
> Subject: Re: [openstack-dev] [Magnum] Magnum supports 2
> Nova flavor to
>
> provision minion nodes
>
> Hi Hong bin,
>
> Thanks very much. It?s good suggestion, I think it is a good way by
> using
>
> labels for extra flavors. But I notice that there is not the
> ?node-count
>
> parameter in baymodel.
>
> So I think it doesn?t need specify minion-flavor-0 counts by ?node-count.
>
> We can specify all of the flavor id and count ratio in the labels. It
> will
>
> check the minion node count with this ratio of labels when creating
> magnum
>
> bay that specified total minion node count . If the node-count in
> baycreate
>
> doesn?t match with the flavor ratio, it will return the ratio match
> error
>
> message. If there is not the multi-flavor-ratio key in lables, it will
>
> just use minion-flavor-0 to create 10 minion nodes.
>
> $ magnum baymodel-create --name k8sbaymodel --flavor-id
> minion-flavor
Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes
hi Mike
Can you please also consider the effect to do rebuild/resize a bay if
you want to support more than 1 nova flavor?
There are some discussion while in Austin summit, check
https://etherpad.openstack.org/p/newton-magnum-bays-lifecycle-operations
Thanks
Eli.
On 2016年04月28日 16:52, Ma, Wen-Tao (Mike, HP Servers-PSC-BJ) wrote:
Hi Kai Qiang,
Thanks for your comments, your consideration is very comprehensive, I
think it is a good way to implement this feature.
Regards
Mike
Date: Wed, 27 Apr 2016 17:38:32 +0800
From: "Kai Qiang Wu" <wk...@cn.ibm.com>
To: "OpenStack Development Mailing List \(not for usage questions\)"
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to
provision minion nodes
Message-ID: <201604271004.u3ra49v4008...@d23av04.au.ibm.com>
Content-Type: text/plain; charset="gb2312"
Hi Mike,
Since right now, we have also support bay-update (node_count)
I am thinking the following case:
1> baymodel-create have default flavor, and extra labels specify
the(other
node flavors) requirements,
if (other node flavors) count <= bay(node_count), the extra nodes would be
created use default flavor
if (other node flavors) count > bay(node_count), it should pop error,
since it not quite clear why flavor to use
2> magnum bay-update k8sbay replace node_count < existed node_count, it
should be OK. same as old behavior
if node_count > existed node_count, all new nodes would use default
flavor_id, (if not, we need to find what's the better policy to handle
that)
Refer:
https://github.com/openstack/magnum/blob/master/doc/source/dev/quickstart.rst
What do you think ?
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:"Ma, Wen-Tao (Mike, HP Servers-PSC-BJ)" <wentao...@hpe.com>
To: "openstack-dev@lists.openstack.org"
<openstack-dev@lists.openstack.org>
Date: 27/04/2016 03:10 pm
Subject: Re: [openstack-dev] [Magnum] Magnum supports 2
Nova flavor to
provision minion nodes
Hi Hong bin,
Thanks very much. It?s good suggestion, I think it is a good way by using
labels for extra flavors. But I notice that there is not the ?node-count
parameter in baymodel.
So I think it doesn?t need specify minion-flavor-0 counts by ?node-count.
We can specify all of the flavor id and count ratio in the labels. It will
check the minion node count with this ratio of labels when creating magnum
bay that specified total minion node count . If the node-count in
baycreate
doesn?t match with the flavor ratio, it will return the ratio match error
message. If there is not the multi-flavor-ratio key in lables, it will
just use minion-flavor-0 to create 10 minion nodes.
$ magnum baymodel-create --name k8sbaymodel --flavor-id minion-flavor-0
--labels multi-
flavor-ratio=minion-flavor-0:3,minions-flavor-1:5,minion-flavor-2:2
$ magnum bay-create --name k8sbay --baymodel k8sbaymodel --node-count 10
Do you think about it?
> -Original Message-
> From: Ma, Wen-Tao (Mike, HP Servers-PSC-BJ) [mailto:wentao...@hpe.com]
> Sent: April-26-16 3:01 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to
> provision minion nodes
>
> 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
The suggested approach seems to break the existing behaviour. I think
it is
better to support this feature in a backward-compatible way. How about
using labels:
$ magnum baymodel-create --name k8sbaymodel --flavor-id minion-flavor-0
--node-count 3 --labels
extra-flavor-ids=minions-flavor-1:5,minion-flavor-2:2
> 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_
Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes
Hi Kai Qiang,
Thanks for your comments, your consideration is very comprehensive, I think it
is a good way to implement this feature.
Regards
Mike
Date: Wed, 27 Apr 2016 17:38:32 +0800
From: "Kai Qiang Wu" <wk...@cn.ibm.com>
To: "OpenStack Development Mailing List \(not for usage questions\)"
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to
provision minion nodes
Message-ID: <201604271004.u3ra49v4008...@d23av04.au.ibm.com>
Content-Type: text/plain; charset="gb2312"
Hi Mike,
Since right now, we have also support bay-update (node_count)
I am thinking the following case:
1> baymodel-create have default flavor, and extra labels specify the(other
node flavors) requirements,
if (other node flavors) count <= bay(node_count), the extra nodes would be
created use default flavor
if (other node flavors) count > bay(node_count), it should pop error,
since it not quite clear why flavor to use
2> magnum bay-update k8sbay replace node_count < existed node_count, it
should be OK. same as old behavior
if node_count > existed node_count, all new nodes would use default
flavor_id, (if not, we need to find what's the better policy to handle
that)
Refer:
https://github.com/openstack/magnum/blob/master/doc/source/dev/quickstart.rst
What do you think ?
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:"Ma, Wen-Tao (Mike, HP Servers-PSC-BJ)" <wentao...@hpe.com>
To: "openstack-dev@lists.openstack.org"
<openstack-dev@lists.openstack.org>
Date: 27/04/2016 03:10 pm
Subject: Re: [openstack-dev] [Magnum] Magnum supports 2 Nova
flavor to
provision minion nodes
Hi Hong bin,
Thanks very much. It?s good suggestion, I think it is a good way by using
labels for extra flavors. But I notice that there is not the ?node-count
parameter in baymodel.
So I think it doesn?t need specify minion-flavor-0 counts by ?node-count.
We can specify all of the flavor id and count ratio in the labels. It will
check the minion node count with this ratio of labels when creating magnum
bay that specified total minion node count . If the node-count in baycreate
doesn?t match with the flavor ratio, it will return the ratio match error
message. If there is not the multi-flavor-ratio key in lables, it will
just use minion-flavor-0 to create 10 minion nodes.
$ magnum baymodel-create --name k8sbaymodel --flavor-id minion-flavor-0
--labels multi-
flavor-ratio=minion-flavor-0:3,minions-flavor-1:5,minion-flavor-2:2
$ magnum bay-create --name k8sbay --baymodel k8sbaymodel --node-count 10
Do you think about it?
> -Original Message-
> From: Ma, Wen-Tao (Mike, HP Servers-PSC-BJ) [mailto:wentao...@hpe.com]
> Sent: April-26-16 3:01 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to
> provision minion nodes
>
> 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
The suggested approach seems to break the existing behaviour. I think it is
better to support this feature in a backward-compatible way. How about
using labels:
$ magnum baymodel-create --name k8sbaymodel --flavor-id minion-flavor-0
--node-count 3 --labels
extra-flavor-ids=minions-flavor-1:5,minion-flavor-2:2
> 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
>
Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes
Hi Mike,
Since right now, we have also support bay-update (node_count)
I am thinking the following case:
1> baymodel-create have default flavor, and extra labels specify the(other
node flavors) requirements,
if (other node flavors) count <= bay(node_count), the extra nodes would be
created use default flavor
if (other node flavors) count > bay(node_count), it should pop error,
since it not quite clear why flavor to use
2> magnum bay-update k8sbay replace node_count < existed node_count, it
should be OK. same as old behavior
if node_count > existed node_count, all new nodes would use default
flavor_id, (if not, we need to find what's the better policy to handle
that)
Refer:
https://github.com/openstack/magnum/blob/master/doc/source/dev/quickstart.rst
What do you think ?
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: "Ma, Wen-Tao (Mike, HP Servers-PSC-BJ)" <wentao...@hpe.com>
To: "openstack-dev@lists.openstack.org"
<openstack-dev@lists.openstack.org>
Date: 27/04/2016 03:10 pm
Subject: Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to
provision minion nodes
Hi Hong bin,
Thanks very much. It’s good suggestion, I think it is a good way by using
labels for extra flavors. But I notice that there is not the �Cnode-count
parameter in baymodel.
So I think it doesn’t need specify minion-flavor-0 counts by �Cnode-count.
We can specify all of the flavor id and count ratio in the labels. It will
check the minion node count with this ratio of labels when creating magnum
bay that specified total minion node count . If the node-count in baycreate
doesn’t match with the flavor ratio, it will return the ratio match error
message. If there is not the multi-flavor-ratio key in lables, it will
just use minion-flavor-0 to create 10 minion nodes.
$ magnum baymodel-create --name k8sbaymodel --flavor-id minion-flavor-0
--labels multi-
flavor-ratio=minion-flavor-0:3,minions-flavor-1:5,minion-flavor-2:2
$ magnum bay-create --name k8sbay --baymodel k8sbaymodel --node-count 10
Do you think about it?
> -Original Message-
> From: Ma, Wen-Tao (Mike, HP Servers-PSC-BJ) [mailto:wentao...@hpe.com]
> Sent: April-26-16 3:01 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to
> provision minion nodes
>
> 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
The suggested approach seems to break the existing behaviour. I think it is
better to support this feature in a backward-compatible way. How about
using labels:
$ magnum baymodel-create --name k8sbaymodel --flavor-id minion-flavor-0
--node-count 3 --labels
extra-flavor-ids=minions-flavor-1:5,minion-flavor-2:2
> 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 comment
Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes
Hi Hong bin,
Thanks very much. It's good suggestion, I think it is a good way by using
labels for extra flavors. But I notice that there is not the -node-count
parameter in baymodel.
So I think it doesn't need specify minion-flavor-0 counts by -node-count. We
can specify all of the flavor id and count ratio in the labels. It will check
the minion node count with this ratio of labels when creating magnum bay that
specified total minion node count . If the node-count in baycreate doesn't
match with the flavor ratio, it will return the ratio match error message. If
there is not the multi-flavor-ratio key in lables, it will just use
minion-flavor-0 to create 10 minion nodes.
$ magnum baymodel-create --name k8sbaymodel --flavor-id minion-flavor-0
--labels
multi-flavor-ratio=minion-flavor-0:3,minions-flavor-1:5,minion-flavor-2:2
$ magnum bay-create --name k8sbay --baymodel k8sbaymodel --node-count 10
Do you think about it?
> -Original Message-
> From: Ma, Wen-Tao (Mike, HP Servers-PSC-BJ) [mailto:wentao...@hpe.com]
> Sent: April-26-16 3:01 AM
> To:
> openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to
> provision minion nodes
>
> 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
The suggested approach seems to break the existing behaviour. I think it is
better to support this feature in a backward-compatible way. How about using
labels:
$ magnum baymodel-create --name k8sbaymodel --flavor-id minion-flavor-0
--node-count 3 --labels extra-flavor-ids=minions-flavor-1:5,minion-flavor-2:2
> 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...@hpe.com<mailto:wentao...@hpe.com>
>
> -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@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
> Cc: Ma, Wen-Tao (Mike, HP Servers-PSC-BJ)
> <wentao...@hpe.com<mailto:wentao...@hpe.com>>
> 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.po...@gmail.com]
> Sent: Thursday, April 21, 2016 3:49 AM
> 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 supports 2 Nova flavor to
> provision minion nodes
>
> Hi Hongbin.
>
> On Wed, Apr 20, 2016 at 8:13 PM, Hongbin Lu
> <hongbin...@huawei.com<mailto:hongbin...@huawei.com>>
&
Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes
> -Original Message-
> From: Ma, Wen-Tao (Mike, HP Servers-PSC-BJ) [mailto:wentao...@hpe.com]
> Sent: April-26-16 3:01 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to
> provision minion nodes
>
> 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
The suggested approach seems to break the existing behaviour. I think it is
better to support this feature in a backward-compatible way. How about using
labels:
$ magnum baymodel-create --name k8sbaymodel --flavor-id minion-flavor-0
--node-count 3 --labels extra-flavor-ids=minions-flavor-1:5,minion-flavor-2:2
> 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...@hpe.com
>
> -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@lists.openstack.org>
> Cc: Ma, Wen-Tao (Mike, HP Servers-PSC-BJ) <wentao...@hpe.com>
> 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.po...@gmail.com]
> Sent: Thursday, April 21, 2016 3:49 AM
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev@lists.openstack.org>
> 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...@huawei.com>
> wrote:
> >
> >
> >
> >
> > From: Duan, Li-Gong (Gary, HPServers-Core-OE-PSC)
> > [mailto:li-gong.d...@hpe.com]
> > 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 bar
Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes
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)
> lists.openstack.org<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>>
> Cc: Ma, Wen-Tao (Mike, HP Servers-PSC-BJ) 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)
> 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 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 Kubernet
Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes
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...@hpe.com
-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@lists.openstack.org>
Cc: Ma, Wen-Tao (Mike, HP Servers-PSC-BJ) <wentao...@hpe.com>
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.po...@gmail.com]
Sent: Thursday, April 21, 2016 3:49 AM
To: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
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...@huawei.com> wrote:
From: Duan, Li-Gong (Gary, HPServers-Core-OE-PSC)
[mailto:li-gong.d...@hpe.com]
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/comp
Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes
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...@hpe.com
-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@lists.openstack.org>
Cc: Ma, Wen-Tao (Mike, HP Servers-PSC-BJ) <wentao...@hpe.com>
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.po...@gmail.com]
Sent: Thursday, April 21, 2016 3:49 AM
To: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
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...@huawei.com> wrote:
>
>
>
>
> From: Duan, Li-Gong (Gary, HPServers-Core-OE-PSC)
> [mailto:li-gong.d...@hpe.com]
> 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
Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes
Hi Folks
This is mike, I am working with Gary.
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...@hpe.com
-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@lists.openstack.org>
Cc: Ma, Wen-Tao (Mike, HP Servers-PSC-BJ) <wentao...@hpe.com>
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.po...@gmail.com]
Sent: Thursday, April 21, 2016 3:49 AM
To: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
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...@huawei.com> wrote:
>
>
>
>
> From: Duan, Li-Gong (Gary, HPServers-Core-OE-PSC)
> [mailto:li-gong.d...@hpe.com]
> 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 pro
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.po...@gmail.com] Sent: Thursday, April 21, 2016 3:49 AM To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org> 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...@huawei.com> wrote: > > > > > From: Duan, Li-Gong (Gary, HPServers-Core-OE-PSC) > [mailto:li-gong.d...@hpe.com] > 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-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 __ 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
Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes
Hi Hongbin, Thank you for your comments. I had thought about supporting multiple nova flavors, and as you pointed out, it introduces an additional challenge of expressing a map containing multiple flavors/resource groups with the corresponding node count. If we just support 2 nova flavor, we can create 3 resource group in kubecluster.yaml and one is for master node, the second is for minion nodes of the first flavor, the third is for minion nodes of the second flavor. But if you think it is necessary to support multiple nova flavor, I need to consider a more generic way to implement it. Regards, Gary Duan From: Hongbin Lu [mailto:hongbin...@huawei.com] Sent: Thursday, April 21, 2016 2:13 AM To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes From: Duan, Li-Gong (Gary, HPServers-Core-OE-PSC) [mailto:li-gong.d...@hpe.com] 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? Regards, Gary __ 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
Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes
+1, Looking forward for reviewing this cool feature. On 2016年04月21日 14:57, Kai Qiang Wu wrote: Hi Duan Li, We welcome to that contribution if you had. Just make sure that spec can be flexible handle 2 ~ N flavor cases. That could handle future requirements for N flavors, as in the ML, I found some ops had such requirements. 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! Inactive hide details for "Duan, Li-Gong (Gary, HPServers-Core-OE-PSC)" ---21/04/2016 02:31:46 pm---Hi Eli, This is exactly wha"Duan, Li-Gong (Gary, HPServers-Core-OE-PSC)" ---21/04/2016 02:31:46 pm---Hi Eli, This is exactly what I want. If you guys think this requirement is reasonable, I’d like to c From: "Duan, Li-Gong (Gary, HPServers-Core-OE-PSC)" <li-gong.d...@hpe.com> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Date: 21/04/2016 02:31 pm Subject: Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes Hi Eli, This is exactly what I want. If you guys think this requirement is reasonable, I’d like to commit a design spec so that we could discuss it in details. Regards, Gary Duan *From:*Eli Qiao [mailto:liyong.q...@intel.com] * Sent:*Wednesday, April 20, 2016 5:08 PM* To:*openstack-dev@lists.openstack.org* Subject:*Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes Kannan, I think Duan Li is talking about using both 2 kinds of (secure-booted and non-secure-booted) node deploy *minion* node. The scenario may like this: let say 2 flavors: o flavor_secure o flavor_none_secure For now, flavor-id in baymodel can only be set as one value, Duan Li's requirement is to using flavor-id = [flavor_none_secure, flavor_secure] and provision one cluster which minion nodes are build from 2 types of flavor, then after cluster(bay ) provision finished , passing lable to let k8s cluster to chose a minion node to start pod on that specific node. For now, Magnum doesn't support it yet, I think it good to have it, but the implementation may be differnece per COE since after we provision bay, the scheduler work are done by k8s/swarm/mesos. Eli. On 2016年04月20日16:36, Kai Qiang Wu wrote: Hi Duan Li, Not sure if I get your point very clearly. 1> Magnum did support :_ __https://github.com/openstack/magnum/blob/master/magnum/api/controllers/v1/baymodel.py#L65_ flavor-id for minion node master-flavor-id for master node So your K8s cluster could have such two kinds of flavors. 2> For one question about ironic case (I found you deploy on ironic), I did not think Magnum templates now support ironic case now. As ironic VLAN related feature are still developing, and not merged(many patches are under review, pick one for example _https://review.openstack.org/#/c/277853_) I am not sure how would you use ironic for k8s cluster ? -- Best Regards, Eli Qiao (乔立勇) Intel OTC China__ 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 __ 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 -- Best Regards, Eli Qiao (乔立勇) __ 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
Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes
Hi Duan Li,
We welcome to that contribution if you had. Just make sure that spec can be
flexible handle 2 ~ N flavor cases. That could handle future requirements
for N flavors, as in the ML, I found some ops had such requirements.
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: "Duan, Li-Gong (Gary, HPServers-Core-OE-PSC)"
<li-gong.d...@hpe.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Date: 21/04/2016 02:31 pm
Subject: Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to
provision minion nodes
Hi Eli,
This is exactly what I want. If you guys think this requirement is
reasonable, I’d like to commit a design spec so that we could discuss it in
details.
Regards,
Gary Duan
From: Eli Qiao [mailto:liyong.q...@intel.com]
Sent: Wednesday, April 20, 2016 5:08 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to
provision minion nodes
Kannan,
I think Duan Li is talking about using both 2 kinds of (secure-booted and
non-secure-booted) node deploy *minion* node.
The scenario may like this:
let say 2 flavors:
flavor_secure
flavor_none_secure
For now, flavor-id in baymodel can only be set as one value, Duan Li's
requirement is to using flavor-id = [flavor_none_secure, flavor_secure]
and provision one cluster which minion nodes are build from 2 types of
flavor, then after cluster(bay ) provision finished , passing lable to
let k8s cluster to chose a minion node to start pod on that specific node.
For now, Magnum doesn't support it yet, I think it good to have it, but the
implementation may be differnece per COE since after we
provision bay, the scheduler work are done by k8s/swarm/mesos.
Eli.
On 2016年04月20日 16:36, Kai Qiang Wu wrote:
Hi Duan Li,
Not sure if I get your point very clearly.
1> Magnum did support :
https://github.com/openstack/magnum/blob/master/magnum/api/controllers/v1/baymodel.py#L65
flavor-id for minion node
master-flavor-id for master node
So your K8s cluster could have such two kinds of flavors.
2> For one question about ironic case (I found you deploy on ironic),
I did not think Magnum templates now support ironic case now.
As ironic VLAN related feature are still developing, and not merged
(many patches are under review, pick one for example
https://review.openstack.org/#/c/277853)
I am not sure how would you use ironic for k8s cluster ?
--
Best Regards, Eli Qiao (乔立勇)
Intel OTC China
__
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
__
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
Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes
Hi Eli, This is exactly what I want. If you guys think this requirement is reasonable, I’d like to commit a design spec so that we could discuss it in details. Regards, Gary Duan From: Eli Qiao [mailto:liyong.q...@intel.com] Sent: Wednesday, April 20, 2016 5:08 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes Kannan, I think Duan Li is talking about using both 2 kinds of (secure-booted and non-secure-booted) node deploy *minion* node. The scenario may like this: let say 2 flavors: * flavor_secure * flavor_none_secure For now, flavor-id in baymodel can only be set as one value, Duan Li's requirement is to using flavor-id = [flavor_none_secure, flavor_secure] and provision one cluster which minion nodes are build from 2 types of flavor, then after cluster(bay ) provision finished , passing lable to let k8s cluster to chose a minion node to start pod on that specific node. For now, Magnum doesn't support it yet, I think it good to have it, but the implementation may be differnece per COE since after we provision bay, the scheduler work are done by k8s/swarm/mesos. Eli. On 2016年04月20日 16:36, Kai Qiang Wu wrote: Hi Duan Li, Not sure if I get your point very clearly. 1> Magnum did support : https://github.com/openstack/magnum/blob/master/magnum/api/controllers/v1/baymodel.py#L65 flavor-id for minion node master-flavor-id for master node So your K8s cluster could have such two kinds of flavors. 2> For one question about ironic case (I found you deploy on ironic), I did not think Magnum templates now support ironic case now. As ironic VLAN related feature are still developing, and not merged(many patches are under review, pick one for example https://review.openstack.org/#/c/277853) I am not sure how would you use ironic for k8s cluster ? -- Best Regards, Eli Qiao (乔立勇) Intel OTC China __ 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
Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes
Hi KaiQiang, Thank you for your reply. As for 1), You are correct in that Magnum does support 2 flavors(one is for master node and the other is for minion nodes). What I want to address is whether we should support 2 or N Nova flavors ONLY for minion nodes. As for 2), We have made Magnum templates works with Ironic(only for Fedora/Atomic/Kubernetes) to create a Magnun bay of Kubernetess and uses the flat network for now (as, for now Ironic doesn’t support VLAN network) in our proto environment. Currently we just use Heat template(Resource Group) -> Nova:Server -> Ironic driver as Nova hypervisor to implement it. Regards, Gary From: Kai Qiang Wu [mailto:wk...@cn.ibm.com] Sent: Wednesday, April 20, 2016 4:37 PM To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes Hi Duan Li, Not sure if I get your point very clearly. 1> Magnum did support : https://github.com/openstack/magnum/blob/master/magnum/api/controllers/v1/baymodel.py#L65 flavor-id for minion node master-flavor-id for master node So your K8s cluster could have such two kinds of flavors. 2> For one question about ironic case (I found you deploy on ironic), I did not think Magnum templates now support ironic case now. As ironic VLAN related feature are still developing, and not merged(many patches are under review, pick one for example https://review.openstack.org/#/c/277853) I am not sure how would you use ironic for k8s cluster ? Also in this summit https://etherpad.openstack.org/p/magnum-newton-design-summit-topics, we will have session about ironic cases: here it is : Ironic Integration: Add support for Ironic virt-driver If you had ways to make ironic work with Magnum, we welcome your contribution for that topic. 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! [Inactive hide details for "Duan, Li-Gong (Gary, HPServers-Core-OE-PSC)" ---20/04/2016 03:46:18 pm---Hi Folks, We are considerin]"Duan, Li-Gong (Gary, HPServers-Core-OE-PSC)" ---20/04/2016 03:46:18 pm---Hi Folks, We are considering whether Magnum can supports 2 Nova flavors to provision Kubernetes and From: "Duan, Li-Gong (Gary, HPServers-Core-OE-PSC)" <li-gong.d...@hpe.com<mailto:li-gong.d...@hpe.com>> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: 20/04/2016 03:46 pm 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? Regards, Gary__ 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?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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...@huawei.com> wrote: > > > > > From: Duan, Li-Gong (Gary, HPServers-Core-OE-PSC) > [mailto:li-gong.d...@hpe.com] > 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-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
Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes
I'll go ahead and be the guy to ask for N flavors. :) AZ zones are kind of restrictive in what they can do, so we usually use flavors, which are much more flexable. I can totally see a project with 3 different types of flavors and want them all in the same k8s cluster managed by labels. Thanks, Kevin From: Hongbin Lu [hongbin...@huawei.com] Sent: Wednesday, April 20, 2016 11:13 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes From: Duan, Li-Gong (Gary, HPServers-Core-OE-PSC) [mailto:li-gong.d...@hpe.com] 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? Regards, Gary __ 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
Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes
From: Duan, Li-Gong (Gary, HPServers-Core-OE-PSC) [mailto:li-gong.d...@hpe.com] 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? Regards, Gary __ 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
Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes
Kannan, I think Duan Li is talking about using both 2 kinds of (secure-booted and non-secure-booted) node deploy *minion* node. The scenario may like this: let say 2 flavors: * flavor_secure * flavor_none_secure For now, flavor-id in baymodel can only be set as one value, Duan Li's requirement is to using flavor-id = [flavor_none_secure, flavor_secure] and provision one cluster which minion nodes are build from 2 types of flavor, then after cluster(bay ) provision finished , passing lable to let k8s cluster to chose a minion node to start pod on that specific node. For now, Magnum doesn't support it yet, I think it good to have it, but the implementation may be differnece per COE since after we provision bay, the scheduler work are done by k8s/swarm/mesos. Eli. On 2016年04月20日 16:36, Kai Qiang Wu wrote: Hi Duan Li, Not sure if I get your point very clearly. 1> Magnum did support : https://github.com/openstack/magnum/blob/master/magnum/api/controllers/v1/baymodel.py#L65 flavor-id for minion node master-flavor-id for master node So your K8s cluster could have such two kinds of flavors. 2> For one question about ironic case (I found you deploy on ironic), I did not think Magnum templates now support ironic case now. As ironic VLAN related feature are still developing, and not merged(many patches are under review, pick one for example https://review.openstack.org/#/c/277853) I am not sure how would you use ironic for k8s cluster ? -- Best Regards, Eli Qiao (乔立勇) Intel OTC China <>__ 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
Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes
Hi Duan Li, Not sure if I get your point very clearly. 1> Magnum did support : https://github.com/openstack/magnum/blob/master/magnum/api/controllers/v1/baymodel.py#L65 flavor-id for minion node master-flavor-id for master node So your K8s cluster could have such two kinds of flavors. 2> For one question about ironic case (I found you deploy on ironic), I did not think Magnum templates now support ironic case now. As ironic VLAN related feature are still developing, and not merged(many patches are under review, pick one for example https://review.openstack.org/#/c/277853) I am not sure how would you use ironic for k8s cluster ? Also in this summit https://etherpad.openstack.org/p/magnum-newton-design-summit-topics, we will have session about ironic cases: here it is : Ironic Integration: Add support for Ironic virt-driver If you had ways to make ironic work with Magnum, we welcome your contribution for that topic. 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: "Duan, Li-Gong (Gary, HPServers-Core-OE-PSC)" <li-gong.d...@hpe.com> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Date: 20/04/2016 03:46 pm 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? Regards, Gary __ 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 __ 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
[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? Regards, Gary __ 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
