Add pre- and post- hooks for arbitrary scripting

[aweiteka]

For some applications on some providers there is a need to prep the host before running (pre-hook). There is also much value in providing a method for validating an application is running (post-hook). We should specify these generally so they can be implemented broadly. I'm not sure if these go in the graph or elsewhere. Use cases:

• run a shell script to create a directory on the host for arbitrary storage
• run an ansible playbook to prepare one or more remote systems before deployment
• run a script to manage certificates before deployment
• run a container-based test suite after application has run to validated deployment

[goern]

Do you think we can formulate that as a requirement for an object in the graph?
Why dont we hand over the responsibility to pre/post-hook-container? So could there be a requirement for 'run once before "graph-object-name"' ?

[aweiteka]

Why dont we hand over the responsibility to pre/post-hook-container? So could there be a requirement for 'run once before "graph-object-name"' ?

Yes, that could work. It's at least simple. However, it's pretty constraining not to allow a shell script.

[vpavlin]

Remember the rule of thumb that the deployment is most probably happenning on a different host and we don't have ssh access to it, i.e running scripts is worthless.

If you really want to modify the host, it's probably a good case for a SPC taking care of it.

I am not sure, but requirements as they are defined now, are application specific, not graph component specific, correct?

How do we specify how to run tge container? What avout making these pre/post hooks just a special kind of graph component?

Btw..this is coming to Kubernetes soon-ish

[goern]

@aweiteka I wonder about use cases 2 and 3:

• run an ansible playbook to prepare one or more remote systems before deployment
• run a script to manage certificates before deployment

They sound more like a systems management or configuration management activity rather than deploying an application.

1. is definitely a task for the systems management's "deploy new host" service, I think it is a job for the orchestrator to provide the capacity of hosts to deploy applications to that hosts. Afterwards the orchestrator may call atomic app install ....

[aweiteka]

They sound more like a systems management or configuration management activity rather than deploying an application.

Good point. I'm noticing complex apps always have prerequisites. For example, OpenShift's EFK stack actually has a "deployer" template (aka installer) pattern[1] to boostrap the actual services. Even in this case where they've presumably optimized automation they have to create secrets (certs), create service accounts and assign policy.

While this may be the domain of config mgmt it would be good to define a clear line where Nulecule stops and config mgmt picks up.

[1] https://github.com/openshift/origin-aggregated-logging/blob/master/deployment/README.md

[cdrage]

@aweiteka @goern @vpavlin
are you three still wanting this to be implemented? i could add this as an experimental feature in atomic app as I too have encountered cases where it would be ideal to have pre-scripting capabilities before deployment.

then again, as what @goern said, these are more adminstrative tasks than deployment :( since commonly a k8s or openshift cluster is located elsewhere than localhost

[goern]

To me it feels like a 'super nice to have' feature, so please make a decision if it is valuable to AtomicApp. If so, consider using the 'run container via hook' pattern, see #190 (comment)

If you implement this experiment in AtomicApp, lets formalize it to the Nulecule Spec.

[dustymabe]

hmm - can we come up with some specific examples? i could see this as useful in the "docker only" case but I don't really think it's something you want to do when you get to the kube/openshift/mesos level. If it's just for the docker case then does it really make sense?

[cdrage]

yes, the ideal situation would be for the docker provider. for example, having a pre-hook before using http://www.projectatomic.io/blog/2015/08/fun-with-kubenetes-and-atomicapp/ would be ideal in order to create ssl certs, etc.

[dustymabe]

yeah - here we are again at another case where a feature makes sense for the one set of providers vs the other. i.e. defining storage/secrets works good for "platforms" like kube/ose. pre scripts are nice for just the "docker" provider, etc.