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:[email protected]] 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" <[email protected]<mailto:[email protected]>> 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: [email protected]?subject:unsubscribe<http://[email protected]?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
