pulumi-community #general

Docs

Join the conversation Join Slack

general

fresh-king-3299

09/04/2018, 4:05 AM

I’ll give it a try. Thanks @creamy-potato-29402

creamy-potato-29402

09/04/2018, 4:05 AM

fresh-king-3299

09/04/2018, 4:06 AM

FYI I’m trying to work on this https://github.com/pulumi/pulumi-kubernetes/issues/179

creamy-potato-29402

09/04/2018, 4:07 AM

btw I have a fix for this ready: https://github.com/pulumi/pulumi-kubernetes/issues/178

💯 1

fresh-king-3299

09/04/2018, 4:08 AM

That was fast. Thanks!

fresh-king-3299

09/04/2018, 4:10 AM

how do you feel about #179?

creamy-potato-29402

09/04/2018, 4:11 AM

I think you’re right that this is useful, but I’m not sure how to make it work in the programming model.

creamy-potato-29402

09/04/2018, 4:12 AM

A lot of the utility of the programming model is that it expects resources to complete initialization at some point…

creamy-potato-29402

09/04/2018, 4:13 AM

This notion IS in fact very foreign to kubernetes, but I don’t think that’s because this notion isn’t useful to Kubernetes, I think it’s because Kubernetes wants components to be very loosely-coupled.

fresh-king-3299

09/04/2018, 4:15 AM

I think we should at least have the option. I looked into ComponentResourceOptions and ResourceOptions but it looks like it’s not really a bag of settings.

creamy-potato-29402

09/04/2018, 4:16 AM

In theory, an option like this could go there.

creamy-potato-29402

09/04/2018, 4:17 AM

But when the flag is set to

true

, what happens to the computed values?

deployment.metadata.apply(m => m.resource)

would be semantically meaningless

creamy-potato-29402

09/04/2018, 4:19 AM

So it’s difficult to know what we’d have to do to implement such a flag.

fresh-king-3299

09/04/2018, 4:21 AM

I think that’s ok since this will an explicit setting so the user would know the effect

creamy-potato-29402

09/04/2018, 4:21 AM

but what is the effect? What does

deployment.metadata.apply(m => m.name)

creamy-potato-29402

09/04/2018, 4:21 AM

return?

creamy-potato-29402

09/04/2018, 4:21 AM

does it throw an error?

fresh-king-3299

09/04/2018, 4:22 AM

hmm, think error is reasonable.

creamy-potato-29402

09/04/2018, 4:25 AM

Do you have an example of something that is really annoying or painful to do without this feature?

fresh-king-3299

09/04/2018, 4:28 AM

It’s not a show stopper at this time. I’m used to behavior kubectl apply where it returns immediately and am just thinking the synchronous nature of the awaiter concept might be a problem.

fresh-king-3299

09/04/2018, 4:29 AM

Also there has been other conversations on the kubernetes project about this kind of dependencies and they have rejected them

creamy-potato-29402

09/04/2018, 4:30 AM

Oh yes, I remember.

creamy-potato-29402

09/04/2018, 4:30 AM

I was an early engineer a company called Heptio, which was founded by the founders of the Kubernetes project.

creamy-potato-29402

09/04/2018, 4:30 AM

This was, and is, a major sore point in the community.

creamy-potato-29402

09/04/2018, 4:33 AM

Personally, I think that the “fire-and-forget” model of

kubectl

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 AM

Point (2) in particular implies that you have to use something higher-level to orchestrate your rollouts. In order to safely rollout a new configuration, you have to: 1. Create a new

ConfigMap

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 AM

¯\_(ツ)_/¯

creamy-potato-29402

09/04/2018, 4:35 AM

just my opinion.

creamy-potato-29402

09/04/2018, 4:36 AM

🙂

fresh-king-3299

09/04/2018, 4:37 AM

Yes I see your point. But I also have use cases where I do not want a full rollout of a deployment simply because a configmap has changed. The best way forward is to offer users different options for different use cases