https://pulumi.com logo
Join Slack
Powered by
This message was deleted.
# general
s
This message was deleted.
c
It’s hidden, but it’s there. The OSS bits are the engine, the service basically handles coordinated state management.
s
brilliant
that means you’re not handicapped in anyway by going local? but you miss out on the awesomeness you’re obviously building. :-)
quick question — i’ve seen you active with jsonnet/ksonnet, haven’t i? would i as a fond user of jsonnet (but missing a better story on type safety) find haven with pulimis typescript world? or is it too terraformy and focused on creating resources in clouds and not “just” configuration? can generated configs be managed on disk naturally as well? i have so many questions ... sorry about that :-)
c
@salmon-pizza-65823 (1), you’re not handicapped, except that managing state files is a pain and you miss out on the nice features of the service
(2) You have. I used to work at Heptio, where Joe Beda and I invented ksonnet. A lot of what Pulumi is, is based on what (I personally believe) are mistakes we made in that system’s design
s
i read the doc, sounds really nice — fingers are itching to try things out
c
The model of Pulumi is quite similar to j/ksonnet’s, in that you use templates to generate Kube resources, rather than like Terraform’s, where you really are using something close to a better JSON to simply declare infrastructure.
The difference between Pulumi and ksonnet is that we made the decision ahead of time to specifically bake in a notion of “completeness” — the idea being that we should be able to tell users when an object has fully initialized.
s
yep, a very important one, fully agree there
c
For many objects, it is possible to serialize them to disk, but for may it is not … for example, imagine provisioning an RDS instance, and then populating a kube secret with the connection string, so your node.js app can connect to it. This will generate normal kube resources that are checkpointed in the state file, but until you provision RDS, those secret values will not be available.
s
yep, that i can live with as well - as long as things that do not depend on remote state can be managed with entirely local workflows
c
This is a major philosophical disagreement between ksonnet and Pulumi. There is a set of k8s users who are scared of using programming languages as an intermediary between the API server and you; in the Pulumi project our view is that the declarative k8s API is great, and it’s actually better to deliver a clear picture of how your change will ripple through app config.
This is implicit with purely-declarative configuration.
So you should be able, in other words, to have both. We should be able to review the changes to a deployment plan, and see how a change will affect the kube API objects, but also to use real languages to model that deployment.
s
i’m certainly also itching to get underneath and see how pulimi up works, and the internal protocol/apis for resources look like
c
For Kubernetes it’s just a souped-up kube client.
We literally just use kubernetes/client-go, should work anywhere you have a kubeconfig file.
the main innovation IMO is the way you model which kube resources depend on which, so that we can build a planned order in which to deploy them.
s
will have to hit the bed now - i could talk/ask questions for days about this, i’m much intrigued by this space, and are looking to solve massive problems with it
so probably expect me to be back — with feedback/questions soon hopefully :-)
thanks for taking time to answer questions!
c
@salmon-pizza-65823 bother me any time with questions or feedback. Always happy to have it.
r
@creamy-potato-29402 Will you have backends or other places to store state?
c
Perhaps!
r
that are open, one nice part about TF
c
So you can store state wherever you want right now.
But the service only know about the state you give it.
r
is that you can use like a consul backend with mutexes
c
Ah yes.
That whole story is yet-to-be-fleshed out.
r
so.... currently if i wanted to do something similar
c
If you have input, you might consider bringing it up in the channel in its own right, as that may affect the roadmap 🙂
r
what is the output json?
c
yeah, it’s just plain-old-JSON
r
cool
so I could just wrap it and put it in a kv
c
sure
some kind of document database or something would work, too.
r
nosql
c
The trick is that you will have to coordinate access to that document. You basically want one client pointed at it at any time, same as TF.
The service right now coordinates among clients with leased locks.
You’d have to do that yourself with a state file.
r
Where do you state you want to stream the output state?
pulumi login --local ahhhh
sorry 😞
c
lol it’s hidden, don’t feel too bad.
the experience is not super slick yet, so we’re reticent to make a big deal about it
r
I'd prefer something more unixy
c
What we don’t want to happen is for users to go local, think that this sucks, and then never come back. 🙂
I suspect many people are like you.
I would be too, I think.
r
where you can just stream the output
logging in is sooo..... eRrRrr
Thanks 🙂
c
Totally.
Np
lmk if you have other questions or concerns.
r
machine readable output of commands
c
hmm, say more!
like `| grep`’able output?
r
Idea = browser => buttonEvent => server => pulumi.up(my pulumi stuffz)
c
ha not to steal our own thunder buuuuut….
r
currently i have to call out to shell, and invoke the pulumi cmd
c
that is already in flight.
r
but if i call out to shell, i need to be able to parse the up
c
parse it with what?
jsonpath or something?
r
the language
c
can you give me a scenario that you have in mind?
r
building a SPA to manage invoking pulumi
c
ah
r
so say i hae a restful endpoint gets a json payload
c
so you want like a legit API you can use as a backend?
r
I want to be able to invoke pulumi, in JS lo
lol*
c
interesting, I’ll keep that in the back of my mind
r
i think Duffy said he could see why that can be useful
c
it’s an interesting scenario.
Oh yeah for sure.
r
well for example
if i have region us-w, us-3, eu-1
it would be nice to be able to invoke pulumi per region
idk, maybe im complicating things
c
nah I agree
r
but i've been burned by mega states
c
For me the question is not is it a good idea, but
r
how to do it without being a jerk
hahahahah
c
what scenarios shoudl I take back to the team to convince them we should do it now
r
ahhhh who cares about now
do it in 6 months
after you are in the CNCF
c
ha ha
r
bryan cantrill adopts projects into the cncf all the time
support smartos.....
😛
c
I love smartos tbh……………………………………. :v
r
hahaha of course
If you have a docker module... im curious how hard it would be to have a native smartos module
c
hmm
not hard to start, unclear how long the tail of bugs would be.
I actually kinda love triton
I very seriously doubt it gets the kind of IOPS efficiency that spark or Hadoop do, but it sure is fun.
Open in Slack
PreviousNext
Powered by