settingsLogin | Registersettings

[openstack-dev] [magnum] CoreOS template v2

0 votes

Hi,

The CoreOS template is not really up to date and in sync with upstream CoreOS « Best Practice » (https://github.com/coreos/coreos-kubernetes), it is more a port of th fedora atomic template but CoreOS has its own Kubernetes deployment method.

I’d like to implement the changes to sync kubernetes deployment on CoreOS to latest kubernetes version (1.5.2) along with standards components according the CoreOS Kubernetes guide :
- « Defaults » add ons like kube-dns , heapster and kube-dashboard (kube-ui has been deprecated for a long time and is obsolete)
- Canal for network policy (Calico and Flannel)
- Add support for RKT as container engine
- Support sane default options recommended by Kubernetes upstream (admission control : https://kubernetes.io/docs/admin/admission-controllers/, using service account…)
- Of course add every new parameters to HOT.

These changes are difficult to implement as is (due to the fragment concept and everything is a bit messy between common and specific template fragment, especially for CoreOS).

I’m wondering if it is better to clone the CoreOS v1 template to a new v2 template en build from here ?


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Jan 25, 2017 in openstack-dev by Kevin_Lefevre (300 points)   1

4 Responses

0 votes

Hi.

IMO, you should add a BP and start by adding a v2 driver in /contrib.

Cheers,
Spyros

On Jan 24, 2017 20:44, "Kevin Lefevre" lefevre.kevin@gmail.com wrote:

Hi,

The CoreOS template is not really up to date and in sync with upstream
CoreOS « Best Practice » (https://github.com/coreos/coreos-kubernetes),
it is more a port of th fedora atomic template but CoreOS has its own
Kubernetes deployment method.

I’d like to implement the changes to sync kubernetes deployment on CoreOS
to latest kubernetes version (1.5.2) along with standards components
according the CoreOS Kubernetes guide :
- « Defaults » add ons like kube-dns , heapster and kube-dashboard
(kube-ui has been deprecated for a long time and is obsolete)
- Canal for network policy (Calico and Flannel)
- Add support for RKT as container engine
- Support sane default options recommended by Kubernetes upstream
(admission control : https://kubernetes.io/docs/
admin/admission-controllers/, using service account…)
- Of course add every new parameters to HOT.

These changes are difficult to implement as is (due to the fragment
concept and everything is a bit messy between common and specific template
fragment, especially for CoreOS).

I’m wondering if it is better to clone the CoreOS v1 template to a new v2
template en build from here ?


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jan 24, 2017 by Spyros_Trigazis (1,780 points)   1
0 votes

As Spyros mentioned, an option is to start by cloning the existing templates. However, I have a concern for this approach because it will incur a lot of duplication. An alternative approach is modifying the existing CoreOS templates in-place. It might be a little difficult to implement but it saves your overhead to deprecate the old version and roll out the new version.

Best regards,
Hongbin

From: Spyros Trigazis [mailto:strigazi@gmail.com]
Sent: January-24-17 3:47 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] CoreOS template v2

Hi.

IMO, you should add a BP and start by adding a v2 driver in /contrib.

Cheers,
Spyros

On Jan 24, 2017 20:44, "Kevin Lefevre" lefevre.kevin@gmail.com wrote:
Hi,

The CoreOS template is not really up to date and in sync with upstream CoreOS « Best Practice » (https://github.com/coreos/coreos-kubernetes), it is more a port of th fedora atomic template but CoreOS has its own Kubernetes deployment method.

I’d like to implement the changes to sync kubernetes deployment on CoreOS to latest kubernetes version (1.5.2) along with standards components according the CoreOS Kubernetes guide :
- « Defaults » add ons like kube-dns , heapster and kube-dashboard (kube-ui has been deprecated for a long time and is obsolete)
- Canal for network policy (Calico and Flannel)
- Add support for RKT as container engine
- Support sane default options recommended by Kubernetes upstream (admission control : https://kubernetes.io/docs/admin/admission-controllers/, using service account…)
- Of course add every new parameters to HOT.

These changes are difficult to implement as is (due to the fragment concept and everything is a bit messy between common and specific template fragment, especially for CoreOS).

I’m wondering if it is better to clone the CoreOS v1 template to a new v2 template en build from here ?


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jan 24, 2017 by hongbin.lu_at_huawei (11,620 points)   3 3 7
0 votes

Or start writing down (in the BP) what you want to put in the driver.
Network, lbaas, scripts, the order of the scripts and then we can see
if it's possible to adapt to the current coreos driver.

Spyros

On Jan 24, 2017 22:54, "Hongbin Lu" hongbin.lu@huawei.com wrote:

As Spyros mentioned, an option is to start by cloning the existing
templates. However, I have a concern for this approach because it will
incur a lot of duplication. An alternative approach is modifying the
existing CoreOS templates in-place. It might be a little difficult to
implement but it saves your overhead to deprecate the old version and roll
out the new version.

Best regards,

Hongbin

From: Spyros Trigazis [mailto:strigazi@gmail.com]
Sent: January-24-17 3:47 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] CoreOS template v2

Hi.

IMO, you should add a BP and start by adding a v2 driver in /contrib.

Cheers,

Spyros

On Jan 24, 2017 20:44, "Kevin Lefevre" lefevre.kevin@gmail.com wrote:

Hi,

The CoreOS template is not really up to date and in sync with upstream
CoreOS « Best Practice » (https://github.com/coreos/coreos-kubernetes),
it is more a port of th fedora atomic template but CoreOS has its own
Kubernetes deployment method.

I’d like to implement the changes to sync kubernetes deployment on CoreOS
to latest kubernetes version (1.5.2) along with standards components
according the CoreOS Kubernetes guide :
- « Defaults » add ons like kube-dns , heapster and kube-dashboard
(kube-ui has been deprecated for a long time and is obsolete)
- Canal for network policy (Calico and Flannel)
- Add support for RKT as container engine
- Support sane default options recommended by Kubernetes upstream
(admission control : https://kubernetes.io/docs/
admin/admission-controllers/, using service account…)
- Of course add every new parameters to HOT.

These changes are difficult to implement as is (due to the fragment
concept and everything is a bit messy between common and specific template
fragment, especially for CoreOS).

I’m wondering if it is better to clone the CoreOS v1 template to a new v2
template en build from here ?


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jan 24, 2017 by Spyros_Trigazis (1,780 points)   1
0 votes

Hi,

I did write a blueprint a while ago but did not start to implement it.

https://blueprints.launchpad.net/magnum/+spec/coreos-best-pratice

Le 24 janv. 2017 à 23:16, Spyros Trigazis strigazi@gmail.com a écrit :

Or start writing down (in the BP) what you want to put in the driver.
Network, lbaas, scripts, the order of the scripts and then we can see
if it's possible to adapt to the current coreos driver.

Spyros

On Jan 24, 2017 22:54, "Hongbin Lu" hongbin.lu@huawei.com wrote:
As Spyros mentioned, an option is to start by cloning the existing templates. However, I have a concern for this approach because it will incur a lot of duplication. An alternative approach is modifying the existing CoreOS templates in-place. It might be a little difficult to implement but it saves your overhead to deprecate the old version and roll out the new version.

Best regards,

Hongbin

From: Spyros Trigazis [mailto:strigazi@gmail.com]
Sent: January-24-17 3:47 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] CoreOS template v2

Hi.

IMO, you should add a BP and start by adding a v2 driver in /contrib.

Cheers,

Spyros

On Jan 24, 2017 20:44, "Kevin Lefevre" lefevre.kevin@gmail.com wrote:

Hi,

The CoreOS template is not really up to date and in sync with upstream CoreOS « Best Practice » (https://github.com/coreos/coreos-kubernetes), it is more a port of th fedora atomic template but CoreOS has its own Kubernetes deployment method.

I’d like to implement the changes to sync kubernetes deployment on CoreOS to latest kubernetes version (1.5.2) along with standards components according the CoreOS Kubernetes guide :
- « Defaults » add ons like kube-dns , heapster and kube-dashboard (kube-ui has been deprecated for a long time and is obsolete)
- Canal for network policy (Calico and Flannel)
- Add support for RKT as container engine
- Support sane default options recommended by Kubernetes upstream (admission control : https://kubernetes.io/docs/admin/admission-controllers/, using service account…)
- Of course add every new parameters to HOT.

These changes are difficult to implement as is (due to the fragment concept and everything is a bit messy between common and specific template fragment, especially for CoreOS).

I’m wondering if it is better to clone the CoreOS v1 template to a new v2 template en build from here ?


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

responded Jan 25, 2017 by Kevin_Lefevre (300 points)   1
...