https://pulumi.com
Join Slack
This message was deleted.
# general
s
This message was deleted.
i
I wanted to get some feedback to the pulumi team while this is new and fresh and before this all becomes a normal thing - hang in here for a few minutes so I can type this out..
1. In general, the docs have been good to use
2. Finding pointers to specific options and usage was a bit painful - such as gcp specific options for cluster and db extras like autoUpgrade, maintenance window configs etc. It wasn’t clear that I should probably jump to the GCP api docs to find those
3. I expected the ^^^ to be in the typescript definitions - but they weren’t. I think I understand why, but nonetheless the TS could definitely be more restrictive when gcp only allows a few values - e.g. a simple one would be gcp db tier (nice to have - not critical)
4. I read the programming model docs but for some reason it didn’t really land for me until I re-read it after some usage attempts. e.g. recent slack discussion relating Input/Output - I remember reading but it didn’t stick. Once up and running with pulumi, finally I was reminded on slack that it was like promises and it all made sense.
5. I have referenced 3 main samples:
I think further work on the kube the prod way would be time well spent. I used jenkins to understand general deployment and secrets usage
6. Best practice on k8s cluster creation - network, subnetwork, master auth is unclear to me. Both from the variety of examples and general reading. I resorted to a simpler gcp ip alias creation with no master auth - not sure I understand the implications good or bad.
7. It took a while to see the importance of ComponentResource, but now I get it. The jenkins sample was good in this regard. 8. Slack responses have been useful and important in on-boarding us.
General feedback after a few days working with it:
I really like it, especially using ts and the programming model. I think the kube the prod way should setup code reuse from a common package for utilities - happy to discuss more but it took me a bit of tsconfig fiddling to get this right. Regardless, once I figured it out, it has been really easy to reuse code and continue moving forward in a productive way.
^^^ that’s it. If there are any questions please let me know. Thanks for putting together a great product. We’ll be a paying customer shortly after our prototype is done.
g
This is excellent feedback. Thanks so much for sharing!
And thank you sticking it out through some of the rough edges.
c
I forget who was working on this. @microscopic-florist-22719? @incalculable-sundown-82514?
i
For being rough, it has been pretty smooth! Diving into ts definitions has been a great resource for self help. I find myself there more in vscode than on the website docs.
➕ 1
c
@important-leather-28796 yeah this is a good question, and part of a general set of questions about dependencies.
we’re still thinking about it, but it’s not clear yet, I think, how we’ll solve it.
g
@creamy-potato-29402 are you referring to the 
dependsOn
question?
c
oh yeah sorry
👍 1
@important-leather-28796 so anyway for the namespace issue, you if you use set a resource’s 
.metadata.namespace
to be 
yourNamespace.metadata.apply(m => m.name)
the dependency should be recorded automatically.
Is that not sufficient for your use cases?
@important-leather-28796 also, you will be pleased to know that we are planning more stuff around ktpw, though the details are not yet solidified.
I’ve shared the feedback with the team, thanks for providing it.
i
the k8 ns has to be created previous to adding something to the ns - that’s what I understood.
c
I meant you might be able to do something like:
Copy code
const ns = k8s.core.v1.Namespace("my-ns", {...});
const app = k8s.apps.v1.Deployment("my-app", {
  metadata: { namespace: ns.metadata.apply(m => m.name) },
  [...]
})
The 
ns.metadata.apply
will automatically record the dependency relationship on 
ns
so it will always be deployed first.
g
BTW, with the latest version of the k8s package, you should be able to do:
Copy code
const ns = k8s.core.v1.Namespace("my-ns", {...});
const app = k8s.apps.v1.Deployment("my-app", {
  metadata: { namespace: ns.metadata.name },
  [...]
})
👍 1
i
ah, ok. That’s interesting to understand. It’ll be fine, I’ll just have to 
import {ns}
in a bunch of files though and add this code to all components e.g. 8 files.
c
yeah. Maybe someday we’ll add better facilities for this.
not super clear what that would involve yet, though
i
I think importing and using with the latest syntax is clean enough
c
it would be great to have maybe a function:
Copy code
const ns = k8s.core.v1.Namespace("my-ns", {...});
ns.addResource(new k8s.apps.v1.Deployment("my-app", { ...})
or something like that.
not sure how it would work yet, though.
that code as written doesn’t really work
i
not a bad idea, but it does deviate from the k8 model so it might be left unused if the user’s knowledge centers on k8 instead of pulumi
c
this would probably be a library on top of the k8s provider SDK
core will remain faithful to the API
Open in Slack
PreviousNext
Powered by

Pulumi Community

No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Powered by