Re: [openstack-dev] [magnum] CoreOS template v2

2017-01-25 Thread Kevin Lefevre 
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 <strig...@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...@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:strig...@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.ke...@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-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



signature.asc
Description: Message signed with OpenPGP
__
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] CoreOS template v2

2017-01-24 Thread Spyros Trigazis 
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...@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:strig...@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.ke...@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-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] CoreOS template v2

2017-01-24 Thread Hongbin Lu 
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:strig...@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.ke...@gmail.com<mailto:lefevre.ke...@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-requ...@lists.openstack.org?subject:unsubscribe<http://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] CoreOS template v2

2017-01-24 Thread Spyros Trigazis 
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"  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-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] CoreOS template v2

2017-01-24 Thread Kevin Lefevre 
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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev