To briefly summarize - all Openshift API objects are designed to be "config" - declarative representation of end objects. Just updating an existing object should be enough to transform the actual config. We do have "imperative" style concepts in the APIs - for instance, deployment triggers and build configs are intended to support iterative config updates without user intervention - but it should be possible to describe apps via checked in config.
The "apply" command is intended to perform declarative update (merging scale or user input via the API with new versions of config), although there are some known gaps that we are addressing. The "export" command (as Harrison described) helps take existing API objects and turn them into "generic config" (some things like image references still need additional export support). We do intend to allow "patches" that represent specific environment changes to be defined in the future. Please provide any feedback about limitations in export that you can - we intend "create, tweak, export, apply, apply, ..." to function exactly as it would for any config driven system. On Aug 25, 2016, at 8:47 AM, Pieter Nagel <pie...@lautus.net> wrote: I'm trying to figure out how to manage OpenShift apps from an "Infrastructure as code" perspective. The obvious place to start is by keeping the yaml or json representation of all OpenShift objects as files under source control. But people can still edit objects via the Web console (and sometimes that will be the most convenient route in development). So at some point you will need to get the yaml files in source control up-to-date. The problem is, `oc get -o yaml` has a lot of output that one wouldn't want to keep under source control. For example creationTimestamp, resourceVersion, selfLink and uid seem redundant to me - if I need to recreate the same logical app from source, or update testing to look like development, I don't care if the objects have the same timestamps and uids they used to have. So you need to postprocess the output of `oc get` to transform it into suitable source, you can't just pipe the output of `oc get` to overwrite your source files. Before I reinvent the wheel on anything, does anyone know if there are existing solutions? -- Pieter Nagel Lautus Solutions (Pty) Ltd Building 27, The Woodlands, 20 Woodlands Drive, Woodmead, Gauteng 0832587540 _______________________________________________ dev mailing list dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
_______________________________________________ dev mailing list dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
