search

projectatomic / nulecule

[UNMAINTAINED] Specification describing a container-based application
209 stars 46 forks source link

Add pre- and post- hooks for arbitrary scripting #190

Open aweiteka opened 8 years ago

aweiteka commented 8 years ago

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:

goern commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

@aweiteka I wonder about use cases 2 and 3:

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 commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

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 https://github.com/projectatomic/nulecule/issues/190#issuecomment-158445362

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

dustymabe commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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.