search

Mirantis / k8s-AppController

AppController is a pod that you can spawn in your Kubernetes cluster which will take care of your complex deployments for you.
Apache License 2.0
220 stars 40 forks source link

Support for multi phase deployments in one namespace #233

Open nebril opened 7 years ago

nebril commented 7 years ago

@tomkukral

tomkukral commented 7 years ago

User story is: I'd like to start the deployment, wait for user to verify it (or do any user testing) and then let the deployment to continue (promote).

jellonek commented 7 years ago

Quite interesting, but pointed to manual testing, verification - this seems to be wrong from arch perspective.

Still I think that multi phase deployment can be useful for steered by external tool which use appcontroller in some parts, would do something in the middle, and then will call appcontroller to proceed later parts. Also looks like quite good place for flows (which are sub graphs) use in general.

I think that this functionality can be achieved right now, for monolitic graph, without any coding. This could be done by starting deployment which pauses on some command (maybe fully ended job resource - waiting for user interaction - e.x. by micro service waiting for user response to finish, e.x. after calling some http endpoint, which could be reached by simple curl invocation) and later continues rest of deployment.

So in theory this only requires something what could be used as job, which will finish after user interaction - if you want - i can tomorrow provide example for that using netcat + bash working as such job waiting for user interaction through http protocol ;)

istalker2 commented 7 years ago

looks like something that can be achieved with flows - split graph into two flows "prepare" and "promote" and run them separately

tomkukral commented 7 years ago

Former idea was to have something like wait condition handle from Heat ... user testing is just user story.

I wanted to suggest something which is not easy to acomplish with init containers and use already running appcontainer pod for listening on the service. Script something like this with init containes would be real nightmare :see_no_evil:

jellonek commented 7 years ago

So this ends with generic "wait for user" step, which can be handled in a way which i described. At the end - we don't need nothing more special than such step, but this can be handled now by described earlier job, but also can have a specific resource type, or flow state.

Btw. still, nice topic to investigate...