Humble refers to a short meeting we had for him to bring me up to speed on the Kube and OCP resource types.
>From what he explained to me, what we want is to maintain the ability to manage versioned deployments as well as do rollbacks of deployments. If I understand this correctly, then I ask: Humble, did you mean Templates or DeploymentConfigs? DeploymentConfigs, best I can tell, are what provide the features we want and are not tied to Templates in any way. I would definitely want to keep DeploymentConfigs for use in OpenShift. This may have been confused because of the following line in the OpenShift docs: A deployment in OpenShift Enterprise is a replication controller based on a user defined template called a deployment configuration. So they're calling it a "template" in the general sense of the word, not a "Template" in the OpenShift resource sense. Is that right? --Jose On Thu, Dec 8, 2016 at 11:47 AM, Humble Chirammal <hchir...@redhat.com> wrote: > I think my point was/is atleast clear to Jose, the Deamonset artifacts lack > the support like upgrading with different strategies. As the 'dc' is > bundleed in templates, I referred that way. > > On Thu, Dec 8, 2016 at 9:29 PM, Luis Pabon <lpa...@chrysalix.org> wrote: >> >> I'm not sure what meeting you are talking about. Templates do not compare >> with daemonsets. Templates is the ability to substitute variables in an >> object. Your comparison is incorrect. A better comparison is that >> Deployments (or DeploymentConfig in OpenShift) allow for rollback, upgrades, >> etc. True, today daemonsets do not have that upgrade ability, but it is >> going to be added. >> >> Templates themselves provide no benefit to our deployments. >> >> - Luis >> >> On Thu, Dec 8, 2016 at 10:34 AM, Humble Chirammal <hchir...@redhat.com> >> wrote: >>> >>> As I pointed out in our meeting, templates bring us the main advantage of >>> upgrading our solution with different strategies like rolllback and upgrade >>> to a particular version ..etc which is not possible with just a config >>> artifact like Deamonset. So, according to me we should keep it. >>> >>> On Fri, Dec 2, 2016 at 8:32 PM, Jose A. Rivera <jar...@redhat.com> wrote: >>>> >>>> Okay, what are these advantages? :) It would be a lot easier to >>>> maintain one set of files for both Kube and OpenShift than separate >>>> files for each. >>>> >>>> --Jose >>>> >>>> On Fri, Dec 2, 2016 at 8:11 AM, Humble Chirammal <hchir...@redhat.com> >>>> wrote: >>>> > More or less, there are different advantages we get when we use >>>> > Templates, >>>> > so I am negative to drop templates from our deployment model. >>>> > >>>> > On Fri, Dec 2, 2016 at 7:37 PM, Humble Chirammal <hchir...@redhat.com> >>>> > wrote: >>>> >> >>>> >> Hi jose, >>>> >> >>>> >> Iic, templates are the recommended way to deploy an application in >>>> >> openshift. Also 'Deamonset' can be inside a template. So I dont see a >>>> >> reason >>>> >> to move away from Templates :) >>>> >> >>>> >> On Thu, Dec 1, 2016 at 5:46 AM, Jose A. Rivera <jar...@redhat.com> >>>> >> wrote: >>>> >>> >>>> >>> Heyo, >>>> >>> >>>> >>> Naturally, as soon as I upload OpenShift support for the gk-deploy >>>> >>> script, I find myself wondering: why do we have templates for heketi >>>> >>> for OpenShift? Specifically, why do we create Template objects >>>> >>> instead >>>> >>> of the direct objects (e.g. Service, DeploymentConfig)? Do we have a >>>> >>> need for the ability to recreate heketi pods with different >>>> >>> parameters >>>> >>> within the same namespace? We live without them in Kubernetes, and >>>> >>> at >>>> >>> present even with Templates the deployment of heketi in OpenShift is >>>> >>> not much easier for a sysadmin if at all. >>>> >>> >>>> >>> --Jose >>>> >>> >>>> >>> P.S. This all comes as I'm trying to bring a DaemonSet GlusterFS to >>>> >>> OpenShift. ;) >>>> >>> _______________________________________________ >>>> >>> heketi-devel mailing list >>>> >>> heketi-devel@gluster.org >>>> >>> http://lists.gluster.org/mailman/listinfo/heketi-devel >>>> >> >>>> >> >>>> > >>> >>> >>> >>> _______________________________________________ >>> heketi-devel mailing list >>> heketi-devel@gluster.org >>> http://lists.gluster.org/mailman/listinfo/heketi-devel >>> >> > _______________________________________________ heketi-devel mailing list heketi-devel@gluster.org http://lists.gluster.org/mailman/listinfo/heketi-devel
