Our stance on applier vs oc module

[etsauer]

Here's my first stab at answering this question...

First off, applier and oc are not equivalent technologies. Applier is a higher level framework that is built on top of oc and is opinionated toward the use of only a few primatives that can be universally used to do essentially anything that you can do in OpenShift and Kubernetes. These primatives are:

• oc apply
• oc create
• oc delete

NOTE: Technically applier allows the use of oc replace in there as well, but we see replace as functionally redundant with apply so we don't include it here.

Applier as a concept

The idea behind applier is that if you are disciplined in only using these primatives to apply yaml or json objects to do things in openshift as opposed to "helper functions" (e.g. oc new-app, oc new-project, oc adm etc.) what you will end up with is an easily repeatable and automatable structure that can be easily version controlled in git and managed as a long term solution.

The openshift-applier is a framework that builds on this concept to provide an ansible inventory syntax that can be used to tie together all of your openshift resource files and templates

How this relates to oc and the ansible modules for openshift

Since openshif-applier relies on oc, we do have an interest in any developments to improve the ansible experience with openshift client tools. Currently though, there are multiple ansible modules for openshift. Some are being developed by the ansible community, others by the openshift community, and they tend to have a lot of overlapping functionalities and many are incomplete. At some point we hope the communities standardize on something and at that point we would look to replace our use of the oc binary with a module that gives us similar functionality.