Support global 'bosh deploy' flags to accompany all incoming bosh deploy requests

[anshrupani]

We were just wondering if it would be helpful to have a mechanism at the director level through which in any environment with a bosh director, wherever there are scripts calling bosh deploy, we can have an option to include deployment flags like "--fix", or "--recreate", or "--fix-releases", without changing the implementation of other complements and scripts.

We have observed some situations where enabling these flags globally through a configuration property, without changing the implementation for other components calling the deploy command would save us a lot of manual efforts. Switching this property to set a flag and then back to normal (no flag scenario) is something which could be handled by custom code in such environments.

Maybe it's already possible somehow at the director level, or if the community finds it useful, maybe we can discuss what could be an elegant way for the implementation.

For now it just seems including a director property called deployment_flags could be configured with a list of flags that are needed, and then we maintain a check in the actual deploy implementation to see if such high priority flags are configured through deployment_flags

[jpalermo]

Feedback/ideas from the foundation infrastructure working group meeting today:

This can possibly be implemented with changes only needed in the bosh cli by leveraging the generic "configs" provided by the bosh director. The most common config types are "Runtime" and "Cloud", but bosh allows configs of any type to be created. An example of this is the Resurrection Configs that are used by the Health Monitor to enable/disable resurrection of specific deployments/instance groups.

So some sort of "deployment" or "deployment_flags" config could be created by the operator and the bosh cli could be updated to look for these configs.

Very little was discussed about the level of detail these configs might contain, but it could be a very simple "list of flags that are applied to all bosh deployments" or it could include complexity allowing flags to be applied, or excluded from specific deployments based on criteria of some kind.

[beyhan]

I was thinking whether we need a CLI flag which activates this behaviour. With this we can make this fully backwards compatible. WDYT?

Another option could be to extend the Deployment Recovery with an option to recover broken releases. This is more work on the CLI side and will include manual interaction to generate the recovery plan and apply it.

[jpalermo]

I like not having a flag to activate it, it uses them by default, but if it does use them print out a message so the user is aware the config is being used (and reduces the number of "why is it doing that weird thing" situations). It might be useful to have a flag to NOT use them though.

I'm not 100% clear on the original use case, so I might be misspeaking here, but I thought the problem was that they didn't want to have to do something manual for each deployment. And currently a Deployment Recovery only applies to a single deployment, so I'm not sure it would could be easily adapted without changing it to apply to all deployments at once.

Something we'll have to think about is how Teams play into this, and can you have multiple configs at the same time, or is it a singleton. Whatever we currently do for Runtime and Cloud configs probably makes sense, which I think is that if both a Team and Global config exist, only the team one is used (although I'm not totally sure on that), and you can't have multiple copies of the config at the same time (that might be a global thing with the way configs work?)

[beyhan]

I like not having a flag to activate...

I agree that having good logging why something happens with the global flag is really important. I think the disable/enable global flag option is depending on the solution we decide here. We can wait with this until we have more clarity and decide then.

I'm not 100% clear on the original use case,...

I brought this up because it is a new feature and i'm not sure whether everyone is well aware of it and it has such a cool name which fits to this situation :-). The suggested solution here requires manual interaction to manage the configs, but compared to the Deployment Recovery it is much less and as mentioned Deployment Recovery is per deployment and not global.

Something we'll have to think about is how Teams play into this...

According to the Generic Configs docs it seems to be a global thing but I didn't look deeper into this.

[fmoehler]

We have implemented the following draft PR: cloudfoundry/bosh-cli#633 as a POC. It reads a config of type "deploy" (name: "default") and appends these flags to the arguments provided.