Object Definition Files, I can live with that one :) And I agree it's very useful to be able to put the whole "Application Lifecycle Landscape", as you call it, inside one of them. But... the issue we're encountering is with the "full parameterization" part. It's okay if every single property value within the Obj Def Files is within your control, but the moment you let the system generate a value for you that you need somewhere else things become more complex.
Let's say for example that your Obj Def File describes both a backend service and a frontend web application that depends on it., The backend service needs to be publically available because the web app's JavaScript code needs to be able to access it, so no nice Kubernetes DNS tricks where you can just use the name of the application as its host name to connect to. Of course if you can just set the host name of the backend's Route element everything is fine, but that isn't very useful for DEV and QA, DEV is most likely running things on minishift or using "oc cluster up". If you use a Route without a specified host name you get one generated for you nicely. But of course now we have the problem of how to tell the frontend what URL it should connect to! Which is what I'm trying to solve here:) On Sat, Oct 21, 2017 at 2:01 AM, Louis Santillan <[email protected]> wrote: > Terminology: I tend to call the YAML/JSON files used in `oc apply -f ...`: > YAML Files, Object Files, Object Definition Files, API Object Files. > OpenShift also has multiple concepts of Template Files in the form of jinja > files (which produce YAML Files) and multiple API Object Files in a single > file YAML file, and parameterized API Object Files that contain a > `parameters:` section one or more API Object Definitions [0]. > > I find the latter especially useful. You can create an entire Application > Lifecycle Landscape (DEV, QA, PROD) and the requisite API Objects (bc, dc, > svc, etc.) in one call to `oc process -f ... | oc appy -f -` with full > parameterization [1]. Every single API Object can be created this way, > and, you can add them to the OpenShift project namespace `openshift` and > make your templates available to other users of the cluster (using `oc > create template -f myTemplate.yaml`). > > [0] https://docs.openshift.com/container-platform/3.6/ > dev_guide/templates.html#writing-templates > [1] https://docs.openshift.com/container-platform/3.6/ > dev_guide/templates.html#generating-a-list-of-objects > > > ___________________________________________________ > > LOUIS P. SANTILLAN > > SENIOR CONSULTANT, OPENSHIFT, MIDDLEWARE & DEVOPS > > Red Hat Consulting, NA US WEST <https://www.redhat.com/> > > [email protected] M: 3236334854 > <https://red.ht/sig> > TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> > > On Thu, Oct 19, 2017 at 8:39 AM, Tako Schotanus <[email protected]> > wrote: > >> Hi, >> >> is it possible in some way to refer to actual runtime values from within >> an OpenShift template (I'm calling it templates because I don't know the >> official terminology. I'm referring to the json/yaml files that can be >> applied using "oc apply" for example). >> >> What I'm really trying to do is to figure out what hostname was used for >> a Route that was created using an earlier apply and use it in the template >> that is to be applied. >> >> I'm guessing there's no such thing, but I want to make sure before coming >> up with some kind of system ourselves to do replacements in template files. >> >> Thanks >> >> -- >> >> TAKO SCHOTANUS >> >> SENIOR SOFTWARE ENGINEER >> >> Red Hat >> >> <https://www.redhat.com/> >> <https://red.ht/sig> >> >> >> _______________________________________________ >> users mailing list >> [email protected] >> http://lists.openshift.redhat.com/openshiftmm/listinfo/users >> >> > -- TAKO SCHOTANUS SENIOR SOFTWARE ENGINEER Red Hat <https://www.redhat.com/> <https://red.ht/sig>
_______________________________________________ users mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/users
