deploymenttransactionsopenshiftokd

Can `oc create` behave in a "transactional"/"atomic" manner when asked to create _multiple_ objects on the cluster?


I have written a number of related OKD object definitions, each in its own YAML file. These together essentially make up an application deployment. I am doing something like the following to install my application on an OKD cluster, which works to my satisfaction when none of the objects already exist [on the cluster]:

oc create -f deploymentconfig.yaml,service.yaml,route.yaml,configmap.yaml,secret.yaml

However, if some of the objects oc create is asked to create, already exist on the cluster, then oc create refuses to re-create them (naturally) but it will have created all the other ones that did not exist.

This isn't ideal when the objects I am creating on the cluster were made to behave "in tandem", and are parts of an application where they depend on one another -- the configuration map, for instance, is pretty much a hard requirement as without it the container will fail to start properly (lacking configuration data through a mounted volume).

I'd like to know, can oc create be made to behave like either all of the objects specified on the command line, are installed, or none if some of them already exist or if there were errors?

I am aware OKD has template faculties and other features that may greatly help with application deployment, so if I am putting too much (misplaced) faith on oc create here, I'll take an alternative solution if oc create by design does not do "transactions". This is just me trying what seems simple from where I currently stand -- not being much of an OKD expert.


Solution

  • Unfortunately, there is no such thing.

    In Kubernetes (and so in Openshift), manifests are declarative and idempotent in the most of scenarios. Each kind can be modified in atomic way, but not a group of resources all together.

    You can oc apply or oc replace to create or modify some resource in a atomic way, but the same cannot be done with a lot of resources because Kubernetes don't see them as a unity.

    Even if you have a Template or a List, some resources may have problems and you will end with a part of the whole.

    For this kind of thing helm is much more versatile and works as you want with --atomic flag.

    If you have all your manifests separated, you can achieve a similar effect with:

    oc apply -f dirwithmanifests/