-
Notifications
You must be signed in to change notification settings - Fork 46
Add pre- and post- hooks for arbitrary scripting #190
Comments
Do you think we can formulate that as a requirement for an object in the graph? |
Yes, that could work. It's at least simple. However, it's pretty constraining not to allow a shell script. |
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 |
@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.
|
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 |
@aweiteka @goern @vpavlin 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 |
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. |
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? |
yes, the ideal situation would be for the |
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. |
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:
The text was updated successfully, but these errors were encountered: