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
