Open aweiteka opened 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"' ?
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.
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.
atomic app install ....
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 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
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.
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 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.
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: