Add ability to orchestrate multiple (depending) deployments

[livelace]

Main discussion - openshift/jenkins-plugin#33

@ironcladlou

If your concern is the updater scaling up without regards to pod readiness, we'll need to take the discussion to origin/kubernetes, because the rolling updater progresses scale-ups based on replica count of the RC which doesn't take readiness into account.

[0xmichalis]

@smarterclayton I remember you were saying the rolling updater shouldn't care about readiness when scaling up.

[smarterclayton]

Growth should not be readiness limited. Deployments must satisfy their readiness criteria to succeed and ensure that failed deployments are recognized

[bparees]

the fundamental issue in my mind is that the replication controller is reporting an active count of 1 despite the fact that the only pod that exists is in a FAILED state.

[livelace]

Hello. Any news about this ?

[0xmichalis]

Not really. Unless somebody else wants to take a stab at it (which will first require discussion upstream) I am not going to get at this for some time (most probably not before 1.3)

[0xmichalis]

@GrahamDumpleton also had a request about orchestrating multiple depending deployments

[livelace]

It's great :)

[0xmichalis]

AppController seems like it's trying to solve a problem related to this issue:

https://www.youtube.com/watch?v=BXRToNV4Rdw
kubernetes/kubernetes#29453
https://github.com/Mirantis/k8s-AppController

[smarterclayton]

We need to see a concrete proposal before we get too excited - they're not doing a good job of following the Kube process yet, so it's hard to say how it will fall out.

[livelace]

I glad these mechanism are appearing. On video was asked interesting question about conditions between namespaces.

[0xmichalis]

We need to see a concrete proposal before we get too excited - they're not doing a good job of following the Kube process yet, so it's hard to say how it will fall out.

Having dependecies as third-party object is a nice idea. Maybe something we can think about more when we introduce a graph API? cc: @deads2k

[deads2k]

Having dependecies as third-party object is a nice idea. Maybe something we can think about more when we introduce a graph API? cc: @deads2k

Depends on how tightly you want to control ACLs. Assuming you want the correct data and you can't leak information, you cannot pre-compute all possible dependency graphs to show to a user. Inside a project its probably possible, but since projects in openshift depend on external projects for things like images and builds, an editor in project A does not have the same access another editor in A that also has access to B. They should get different graphs.

Precomputation is an interesting though for a few common cases, but stitching would still be required.

[0xmichalis]

Closing in favor of https://trello.com/c/3WmAlsu8/509-ability-to-chain-deployments-evg