I don't want to write k8 menifest (yaml

[tender flame]

I don't want to write k8 menifest (yaml) files ever again
Unfortunately, that's not how k8s works. You must "feed" it configuration information. It knows nothing else or rather, you can't make anything happen in k8s without sending it configuration. All you can do is possibly translate config information from an imperative programming language, so it is understood by k8s. But, then you need that tool to translate and Dagger doesn't do that and doesn't even come close to doing it. At least not in my understanding of Dagger.

[vast vessel]

exactly what Scott is mentioning here. One thing you can do though @spice sedge , is combining Dagger with Pulumi (https://www.pulumi.com/kubernetes/) so you can keep both your pipeline and the k8s orchestration in the same language. That way, you don't need to edit yaml files anymore

[tender flame]

Yes, Pulumi is a choice to avoid YAML files. Terraform too. 🙂

[spice sedge]

ok thanks for support and can we use https://kubernetes.io/docs/reference/using-api/client-libraries/ instead of pulumi with dagger to solve same thing?

[tender flame]

@spice sedge - Pulumi and Terraform do more for you than just "tell k8s what to do". They also will tear down the things you build automatically, if you tell them to do so. If you work with the client libraries, it is up to you to manage the removal/deletion/destruction of resources yourself.

[spice sedge]

ok but can you please explain me what other problems i can get with client libraries and dagger setup?

[vast vessel]

client libraries are generally more difficult to use and to keep updated given the fast phase that they move at. Having said that, if you're comfortable using them, it's definitely a viable option as well. The reason I was brining up Pulumi is what @tender flame mentioned as well as the fact that the DX is generally better than using the native client libraries.

[spice sedge]

Okay got it, thanks for clarifying.
Is dagger going to have native support for k8 like docker?

[vast vessel]

Is dagger going to have native support for k8 like docker?

to deploy k8s workloads you mean? That's probably going to be through modules. I don't think that'll be embedded in the engine

[tender flame]

Is dagger going to have native support for k8 like docker?
That's just it. Docker doesn't have native support for k8s. Docker Desktop has support for creating a k8s cluster, but that can't really be called "native support". Somehow, I believe your perspective is a bit skewed on what should be used where and how, when it comes to Docker, k8s and Dagger.

[surreal lagoon]

Gptscript will help you dothis.

There is a video about using it to do this

[pine dew]

@graceful leaf good thread to follow for tomorrow’s meetup 🙂 cc @quartz narwhal

[vast vessel]

Not sure if this is something I'd rely in tools like GPTScript to do. Deploying an application to k8s generally is deterministic operation, not something that LLM's are good at besides the fact that you have no guarantess that the output of the LLM will be correct.

[tender flame]

Especially since LLMs are usually based on old data. It would be showing you how to do things 2 years ago or older.

[graceful leaf]

So many threads to pull on here.

1. I dont want to write k8s manifest yaml files ever again
2. k8s is driven by a source of truth, if not yaml, what?
3. Source of truth requires an actor to be useful (pipeline/operator/human)
4. Client library and IaC API calls are not the same in function or features
5. Native libraries enable higher order automation paradigms via IaC
6. In a Dagger + Pulumi scenario, Dagger is the actor, and Pulumi is the source of truth
7. Now you just need to pick your language and build cool stuff!

Bonus: difference between deterministic and probabilistic outcomes.
Extra Credit: How can LLMs provide accurate real time information?

[surreal lagoon]

that's like 7 webinars 😄

[graceful leaf]

i could work on just this little blurb for like 3 months straight. it's crazy!

[tender flame]

1. I dont want to write k8s manifest yaml files ever again

Welp. This isn't the way. YAML is the easiest way to understand what k8s wants. Whether or not you feed it YAML yourself or you have a Helm chart or use Kustomize (which is now native to kubectl too), or some other form of config generation, it is still config.

2. k8s is driven by a source of truth, if not yaml, what?

Config. All k8s wants is some declared config. Why? Because k8s was built to be communicating with other machines, not really with humans. This is why k8s is hard to grasp for many people. You have to know what changes in config cause in terms of changes inside the cluster. This is abstract and you simply have to learn it. No way around it. Which is what it sounds like you are trying to do. I can understand this, as I too was thinking like, "can't I have a friggin API to just tell k8s what to do?" Nope. It ain't happening, for the reason I mentioned above.

3. Source of truth requires an actor to be useful (pipeline/operator/human)

Just machines. Those "should" be the actors. We humans though, tell the machines what to do. If you think in those terms, k8s makes a lot more sense. 🙂

4. Client library and IaC API calls are not the same in function or features

Nope. They won't be. The client libraries give you the entry to offer config, which you can write in the code too (but brutally rudimentary). IaC libraries make you write the config as they prescribe it to be written (but, it is still just config). The IaC libraries then translate what you "programmed" to config for k8s.

5. is true.

6. In a Dagger + Pulumi scenario, Dagger is the actor, and Pulumi is the source of truth

Yes. Dagger only knows what you feed it as commands (with inputs). It's purpose though, is to run workloads in a container for you, without really needing the config to run that container, as is the case with Docker or any other container runtime. It's like CaaSaC or Container as a Service as Code. 🙂 So, if you give Dagger's Engine a task to create a container that will create a service for running a pulumi script, that is what it will do. Theoretically, k8s can do the same thing with a Job container, but then you are back to having to "config" that workflow together, which is a PITA for us humans. 🙂

7. Now you just need to pick your language and build cool stuff!

Aha! 😄 If it were only that easy. But yeah. Dagger opens some doors to a more imperative paradigm of working with containerized work loads. However, if that work has anything to do with automation in k8s, you are always going to end up with producing config to make those automations happen.