Thanks all for the helpful feedback. On Thu, Aug 25, 2016 at 4:42 PM, Clayton Coleman <[email protected]> wrote:
> 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. Here's the ideal scenario I would love to see: (All of this assumes a single conceptual app, consistingly of multiple related deploymentconfigs, stored in a single logical source repository, OpenShift objects stored in same repository as the rest of the code). Developers edit code for the app, and occasionally need to create or delete deploymentconfigs and buildconfigs. Currently, an OpenShift buildconfig watches a git repository and keeps building images according to its own config. But what if the buildconfig's yaml itself has been changed, or new buildconfigs added? Ideally, there'd bay a different layer that watches the repository, and when there are changes, goes and deleletes all buildconfigs/deploymentconfigs whose underlying yaml files have been deleted, creates all new ones, and run 'oc apply' on the others. Only then do all resulting buildconfigs that watch the same repository go and build images with their new, up-to-date configs. Given this kind of mechanism, one could also ensure that the QA pipeline (which watches a pre-release branch of the same repository) runs with the exact same set of OpenShift configs. One small part that would help to make this work is a oc subcommand with the semantics of `oc create` if the object does not yet exist, and `oc apply` if already exists. A larger step towards this would be an oc subcommand that takes a set of yaml/json files on the command line, as well as a selector. This command then marks all objects that match the selector but for which no yaml/json has been given to be deleted, ands runs the aforementioned oc create/apply on the rest. Then one can run that command with all openshift yaml files in the repository as input, and use it as a super-duper get everything up-to-date. (In production, this will have to be careful not to delete objects until all the new deploymentconfigs etc. are up-and-running). The problem I'm trying to solve is this: in the real world, there is a tight coupling between the source code for an app, and the OpenShift objects that host that app. For example, if we rename the environment variable that an app uses to find its' database, the old deploymentconfig with the old variable name makes no sense against an image built from the commit that changed it, and the new deploymentconfig with the new variable name makes no sense against an omage build from a commit before it changed. We want all to change in lockstep without extra manual steps. Currently, we have all kinds of manual steps we run to deploy our applications on our servers. Once we've finished porting to OpenShift, I don't want us to end up with just as many manual steps as before, except this time round the steps are "run `oc create...`" instead of "ssh to server and run apt-get install...". -- Pieter Nagel Lautus Solutions (Pty) Ltd Building 27, The Woodlands, 20 Woodlands Drive, Woodmead, Gauteng 0832587540
_______________________________________________ dev mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
