[heketi-devel] OpenShift Templates: Unnecessary?

[Jose A. Rivera]

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 <hchiramm at 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 <lpabon at 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 <hchiramm at 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 <jarrpa at 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 <hchiramm at 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 <hchiramm at 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 <jarrpa at 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 at gluster.org
>>>> >>> http://lists.gluster.org/mailman/listinfo/heketi-devel
>>>> >>
>>>> >>
>>>> >
>>>
>>>
>>>
>>> _______________________________________________
>>> heketi-devel mailing list
>>> heketi-devel at gluster.org
>>> http://lists.gluster.org/mailman/listinfo/heketi-devel
>>>
>>
>