creamy-potato-29402
09/04/2018, 4:05 AMfresh-king-3299
09/04/2018, 4:06 AMcreamy-potato-29402
09/04/2018, 4:07 AMfresh-king-3299
09/04/2018, 4:08 AMfresh-king-3299
09/04/2018, 4:10 AMcreamy-potato-29402
09/04/2018, 4:11 AMcreamy-potato-29402
09/04/2018, 4:12 AMcreamy-potato-29402
09/04/2018, 4:13 AMfresh-king-3299
09/04/2018, 4:15 AMcreamy-potato-29402
09/04/2018, 4:16 AMcreamy-potato-29402
09/04/2018, 4:17 AMtrue
, what happens to the computed values? deployment.metadata.apply(m => m.resource)
would be semantically meaninglesscreamy-potato-29402
09/04/2018, 4:19 AMfresh-king-3299
09/04/2018, 4:21 AMcreamy-potato-29402
09/04/2018, 4:21 AMdeployment.metadata.apply(m => m.name)
creamy-potato-29402
09/04/2018, 4:21 AMcreamy-potato-29402
09/04/2018, 4:21 AMfresh-king-3299
09/04/2018, 4:22 AMcreamy-potato-29402
09/04/2018, 4:25 AMfresh-king-3299
09/04/2018, 4:28 AMfresh-king-3299
09/04/2018, 4:29 AMcreamy-potato-29402
09/04/2018, 4:30 AMcreamy-potato-29402
09/04/2018, 4:30 AMcreamy-potato-29402
09/04/2018, 4:30 AMcreamy-potato-29402
09/04/2018, 4:33 AMkubectl
makes an overall worse experience for users. It means that:
1. Users must re-implement a notion of a rollout in their monitoring stack
2. There are all sorts of weird gotchas, like the fact that changing data in a ConfigMap
does not trigger a rollout in `Deployment`s that reference it.creamy-potato-29402
09/04/2018, 4:35 AMConfigMap
with new data in it, update `Deployment`s to reference it.
2. Wait for rollout of those `Deployment`s to complete, and
3. Finally, after it succeeds, delete the old ConfigMap
.
Why ask users to re-implement this for every new app? Why not just handle it for them?creamy-potato-29402
09/04/2018, 4:35 AMcreamy-potato-29402
09/04/2018, 4:35 AMcreamy-potato-29402
09/04/2018, 4:36 AMfresh-king-3299
09/04/2018, 4:37 AMcreamy-potato-29402
09/04/2018, 4:38 AM