https://pulumi.com logo
Docs
Join the conversationJoin Slack
Channels
announcements
automation-api
aws
azure
blog-posts
built-with-pulumi
cloudengineering
cloudengineering-support
content-share
contribex
contribute
docs
dotnet
finops
general
getting-started
gitlab
golang
google-cloud
hackathon-03-19-2020
hacktoberfest
install
java
jobs
kubernetes
learn-pulumi-events
linen
localstack
multi-language-hackathon
office-hours
oracle-cloud-infrastructure
plugin-framework
pulumi-cdk
pulumi-crosscode
pulumi-deployments
pulumi-kubernetes-operator
pulumi-service
pulumiverse
python
registry
status
testingtesting123
testingtesting321
typescript
welcome
workshops
yaml
Powered by Linen
general
  • f

    fresh-king-3299

    09/04/2018, 4:05 AM
    I’ll give it a try. Thanks @creamy-potato-29402
  • c

    creamy-potato-29402

    09/04/2018, 4:05 AM
    np
  • f

    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
  • c

    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
  • f

    fresh-king-3299

    09/04/2018, 4:08 AM
    That was fast. Thanks!
  • f

    fresh-king-3299

    09/04/2018, 4:10 AM
    how do you feel about #179?
  • c

    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.
  • c

    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…
  • c

    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.
  • f

    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.
  • c

    creamy-potato-29402

    09/04/2018, 4:16 AM
    In theory, an option like this could go there.
  • c

    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
  • c

    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.
  • f

    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
  • c

    creamy-potato-29402

    09/04/2018, 4:21 AM
    but what is the effect? What does
    deployment.metadata.apply(m => m.name)
  • c

    creamy-potato-29402

    09/04/2018, 4:21 AM
    return?
  • c

    creamy-potato-29402

    09/04/2018, 4:21 AM
    does it throw an error?
  • f

    fresh-king-3299

    09/04/2018, 4:22 AM
    hmm, think error is reasonable.
  • c

    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?
  • f

    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.
  • f

    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
  • c

    creamy-potato-29402

    09/04/2018, 4:30 AM
    Oh yes, I remember.
  • c

    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.
  • c

    creamy-potato-29402

    09/04/2018, 4:30 AM
    This was, and is, a major sore point in the community.
  • c

    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.
  • c

    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?
  • c

    creamy-potato-29402

    09/04/2018, 4:35 AM
    ¯\_(ツ)_/¯
  • c

    creamy-potato-29402

    09/04/2018, 4:35 AM
    just my opinion.
  • c

    creamy-potato-29402

    09/04/2018, 4:36 AM
    🙂
  • f

    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
Powered by Linen
Title
f

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
View count: 2