New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Literal configuration of multiple objects (was Service up/down scripts) #113
Comments
Just don't call it config... ;) |
For now, we should ensure that it's straightforward to write robust, idempotent "up" and "down" scripts with our tools and APIs. I'd lump a more general declarative approach with update support. |
I filed another issue for idempotent creation (#148). We can use this issue for multi-resource declarative configuration, starting with up/down. |
@smarterclayton @brendandburns I suggest we use this issue to discuss literal (i.e., without parameterization and inheritance) instantiation of multiple objects. |
Namespace is inferred on creation - should it also be inferred on deletion? We don't have auto-naming yet, so we don't have unnamed resources. |
Closing in favor of #1905, which has more detail. |
Retrieve 0 stats/samples when user asked for zero stats/samples
grpc for pod remove
…e-update Update Project Managers Group To PM Google Group
Create a deployment spec file that will: apiVersion: apps/v1 |
People are going to want to write scripts to bring an entire service up/down. We should provide a standard way of doing so now, or everyone is going to roll their own. This could mean python api bindings and a template or something else (a better go client library?).
The text was updated successfully, but these errors were encountered: