[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Bootstrap template



Thanks for your answers, they basically solve my case :)

It might be better suited to "process", which could conceivably allow
better bulk processing of templates.  Definitely open to feedback and
ways of simplifying working with sets of templates.

Indeed `oc process` would be the correct location for that. I mentioned `oc export` because of my need to have a top-level template that can instantiate nested templates from the GUI. I don't think that having it on `oc process` would solve this use-case, but this is probably a limitation of the GUI rather than `export` or `process`.

I don't think that not having a "flatten" feature in `export` or `process` is currently a huge limitation on the CLI, as using the CLI allows to script around this kind of limitations anyway :) I am also not even sure that "flattening" is actually what `process` should provide, rather it would probably be better to be able to instantiate all templates up to a given nesting level, or to extract the list (or tree) of nested templates which would allow to easily drive their deployment from a script.

For the GUI though we are limited in terms of script-hacking, and it would be nice to have the option to instantiate nested template as well (instead of- or in addition to installing them as templates) directly from the top-level template's page. This could be a lot nicer than what I do now with my "flatten" script, as I can't manage duplicate parameters (I have to make sure that parameters across the templates that end up nested do not share the same name) and they are all displayed in a single parameters list without the ability to group them according to the actual nested template they belong to.

Technically templates will be able to contain service bindings in a
few releases, which let you potentially reference them that way.  The
template broker will be able to instantiate templates you offer.  Only
alpha in 3.6 though.
I am not sure that I understand the concept correctly.

When the user attempts to instantiate template B that defines a binding to a service A that is not deployed yet, if he can then instantiate the template for A in the same step, i.e. the GUI would ask the user for the parameters to instantiate unmet dependencies on the same page/process as the target service he wants to deploy, then that would be exactly what I need :)

Aside from the obvious wow effect that it would provide (always good when you have potential customers in front of you :D), it would allow to quickly bootstrap a whole multi-service project (at least when the list of dependencies is rigid, which is the case for my current project: all the "backend services" need to be deployed, even if we could replace some of them by mocked-up versions) when new developers are starting on it.

Reading again my last paragraphs, it seems a bit overkill to cram all of this into openshift's GUI (if that's what the service bindings will actually be used for: great!), and by the looks of it this would probably be best delegated to third-party templates/deployments management solutions working on top of openshift.

Best regards,
Jeremiah


On 22. 06. 17 14:38, Clayton Coleman wrote:
On Jun 22, 2017, at 7:24 AM, Jeremiah Menetrey <jeremiah menetrey adnovum ch> wrote:

Hello,

I am using an openshift origin cluster and defined a few dozen objects grouped in several yaml files.
Now I would like to "package" them into a single template such that everything can be bootstrapped from scratch in as few steps as possible from the GUI catalog, but I also want to avoid having to maintain manually a separate template with all the objects I already defined.

My current solution is to use `oc export --as-template` to wrap all my objects into a single template, and then I still have to massage the result a bit: since some of my original objects are templates themselves, if I just create a new application from the generated template the "nested templates" will be created effectively as templates, and I would need more steps and clicks through the GUI to deploy those.

So I wrote a `flatten` script that, given the template generated by `oc export`, promotes all nested templates one level up (if an object is a template, take its parameters and objects, and append them to the top-level template's, the nested template is then dropped).

So in order to create a "bootstrapping" template in the project, I could do something like:

    oc export --as-template=bootstrap -f objects/ | flatten.py | oc annotate -f - ... | oc create -f -

I could also pipe the output of `flatten.py` to `oc process` in order to create all the objects directly (assuming that I'm also specifying the templates' parameters).

This works well for my specific case, but it doesn't really seem right. So:
- How is this kind of situation usually managed?
I see a lot of people doing simply scripting over directories of
content, processing everything in them (if they are templates), or
using an alternate templating solution (envsubst works pretty well
against openshift templates!).  The more config you manage, the more
likely you want some standard conventions and predictable application
of those.  That doesn't help your UI case, though.

The sweet spot of templates is 2-10 objects - a discrete unit of
function you want to repeatedly deploy with some parameterizarion.
The more you add, the more likely you want a more sophisticated
templating language and then there are many options (Ansible, helm, Go
templates, direct jinja, jsonnet or the newer ksonnet).  I will note
that what you've described sounds a bit like other forms of static
generation (creating a final template from many parts) and there are
lots of tools to do that

Oc process *should* support reading from directories, if you wanted to
be opinionated about how those directories were structured so as to
have templates in one place and apps in another.



- Does openshift itself provide a way (or guidelines on how) to manage objects/configurations? otherwise what are some usual solutions to this issue? (note: the question is about whole platforms hosted on openshift, with a few dozens of interacting services)
It is very common to layer config systems over openshift - we (today)
are trying to be a really effective target for those systems (with
ensuring apply works well, making it easier to do cert injection or
use reencrypt routes with default destination CAs), and many different
workflows can work well on top.

- Would a "flatten" feature be a useful companion to `oc export --as-template`? Or why wouldn't it be?
It might be better suited to "process", which could conceivably allow
better bulk processing of templates.  Definitely open to feedback and
ways of simplifying working with sets of templates.

- Alternatively, is there a way to reference other templates from a template, such that the GUI catalog allows to display, configure and deploy a set of templates at once? (the presentation factor is kind of important in my project)
Technically templates will be able to contain service bindings in a
few releases, which let you potentially reference them that way.  The
template broker will be able to instantiate templates you offer.  Only
alpha in 3.6 though.

Thanks,
Jeremiah

_______________________________________________
users mailing list
users lists openshift redhat com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

--
Jeremiah Men├ętrey, Junior Software Engineer
MSc in Computer Science

AdNovum Informatik AG
Roentgenstrasse 22, 8005 Zurich, Switzerland
phone +41 44 272 6111
jeremiah menetrey adnovum ch
www.adnovum.ch

Locations: Zurich (HQ), Bern, Lausanne, Budapest, Ho Chi Minh City, Singapore


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]