Out of date hosted templates

[jperville]

Just reporting it here before working on a PR (little time this week).

I tried to deploy the openshift logging addon with openshift origin 1.4.1, and I found out that the template that is loaded into openshift (stored on the master as /usr/share/openshift/hosted/logging-deployer.yaml) is not compatible with v1.4.1 of the logging addon; I run into the following error:

==> master: ---- Begin output of oadm policy add-cluster-role-to-user rolebinding-reader system:serviceaccount:logging:aggregated-logging-elasticsearch ----
==> master: STDOUT: 
==> master: STDERR: Error from server: role "rolebinding-reader" not found
==> master: ---- End output of oadm policy add-cluster-role-to-user rolebinding-reader system:serviceaccount:logging:aggregated-logging-elasticsearch ----

My own cookbook supplies an uptodate version of the template but it was not installed because a "not_if" clause said there is already a template installed for "logging-deployer-template" in the openshift namespace.

If we compare the template supplied by this cookbook here with the current template on the origin-aggregated logging project (as of v1.4.1) here we see the templates have evolved quite a bit. There are many differences, at least the "rolebinding-reader" role is missing in this cookbook's version.

My questions:

• is it possible to have uptodate templates for the addons, without turning the code into a mess with one version of each template per openshift version (1.2, 1.3, 1.4) and distribution (origin, enterprise)
• can we disable installation of hosted_templates like we can disable the example templates today?
• why do we supply a template for the logging addon if the cookbook does not supply a recipe or template to deploy the logging addon (maybe a PR is missing here!)

[IshentRas]

@jperville Thanks for bringing that :-)
a) The true is we do need to pay more attention to updates against templates...
b) Our code should handle new versions regardless so you should not be in a position when there is a new version and it does not get replicated or updated..

execute 'Import Openshift Hosted Examples' do
  command "#{node['cookbook-openshift3']['openshift_common_client_binary']} create -f #{node['cookbook-openshift3']['openshift_common_hosted_base']} --recursive --config=admin.kubeconfig -n openshift || #{node['cookbook-openshift3']['openshift_common_client_binary']} replace -f #{node['cookbook-openshift3']['openshift_common_hosted_base']} --recursive --config=admin.kubeconfig -n openshift"
  cwd Chef::Config[:file_cache_path]
  ignore_failure true
end

c) Happy to put a new logic for handling the versioning (why not :-))
d) I do not think we should drop the hosted template logic as it is used for setting up logging/metrics etc..
And to be honest, not automatically installing the hosted services (logging, metrics...) does not mean that people do not use them afterwards (Post actions by team A...)
What we should tend to offer is a way of automating everything as possible.

Having you and @ianmiell will make things easier I believe as we can do more together.

[jperville]

I think we should add a LWRP to deploy the logging addon, similar to how we deploy the metrics, registry and router addons. From my experience, both metrics and logging are difficult to get right (different setup needed depending on openshift version, deployer pod which can fail for many reasons, and impossible to update automatically). At least we can deploy for a target version and explain that automatic upgrades between major versions are not supported yet.

At the minimum, we should deploy the addon hosted templates from within the LWRPs that use it (eg. the logging-deployer template from the logging LWRP, the metrics templates from the metrics LWRP) instead of globally, regardless of whether we use the cookbook to deploy the feature or not.

That way we can deploy the proper version and not be out of sync, and if we chose not to deploy for example metrics with this cookbook's LWRP we won't have a hosted template coming back at every chef-run which is incompatible with what we deploy.

For example, if I want to deploy v1.3.2 of the logging addon (version selected by a LWRP attribute), the LWRP will fetch https://github.com/openshift/origin-aggregated-logging/blob/v1.3.2/deployer/deployer.yaml and will setup service account and SCCs as exampled in instructions for v1.3.2. If I want to install v1.4.1 instead, then I will use the template at tag v1.4.1, and will setup the aggregated-logging-elasticsearch service account to have the rolebinding-reader cluster role (which does not exist in versions earlier than v1.4.0).

Should I work on such a PR to remove the global addon templates and install the proper version from each addon LWRP instead?

[IshentRas]

👍 I agree with you and my point was more or less : Yes we should and let's do it

[IshentRas]

#96

[ianmiell]

Tests passed.

[jperville]

The hosted templates are now up to date (as of v1.10.40), thanks @IshentRas .