Thinking about it now, won’t configuring Kubernetes be a good fit for Visual Programming? Definitely sounds better in my head that yaml. Does this already exist? Is there a complication I’m missing?
I'm curious to hear more about Pulumi. I had a similar question after looking at Hashicorp's Terraform CDK over the weekend: what's the point? It has to emit a static configuration. JSON basically. What does having a general-purpose PL buy you if you can't add a loop or conditional to the output? Pulumi seems the same, going by tutorials like https://www.pulumi.com/docs/tutorials/aws/ec2-webserver. Can someone point me at a more complex scenario that it can handle?
I'd like to create a host, then monitor its health for 60 seconds before creating a second identical host. Does Pulumi or any other infrastructure-as-code allow me to do that? If I'm reading it right, the declarative-code article above has the same issues with Pulumi.
I don't know exactly how Pulimi works, but I have some experience with Terraform (I use it on my last project as a corporate employee).
The point is that generally you define a desired state and ask Terraform to do all it can to create/modify the corresponding infrastructure. And for that it analyzes your code, checks that everything is OK and proposes you a "plan" which describes what Terraform will actually do: create new resource, deleting some others or just modifying some. Terraform then asks you if you want to proceed and then actually do the job. Of course, you can tell to Terraform to apply changes automatically without asking, if you are very confident about you code or don't care to break things, but generally this is desired thing to be asked because of the tricky nature of infrastructure management.
So I guess the scenario "create something, wait a bit, create something else" is not very common and is actually "not in the spirit". But if this use case is really needed, if I recall well there are some trick to allow doing this kind of pause. In the definition of the first resource you add a script that sleep 60 seconds, maybe with some monitoring, and make the second resource depends on this resource, which will make Terraform wait the end of the script before creating the second resource. The paradigm is to define resources and dependencies.
For loops, there is something that allows you to create a set of ressources with a single definition. I used it to generate thousands of VM. In fact you have a series of tools for "loop/conditionals" at the language level, but always in a spirit of "templating".
But after a bit of practicing, I felt sometime that I would have prefer to code things with a general purpose language. For things like getting env vars, managing some files, etc. I guess it is what Pulumi is about, and I am very curious about it.
Pulumi is very much like Terraform, it actually uses the Terraform providers behind the scenes (Pulumi does not generate files, as AWS CDK does). The only major difference is that you declare that desired state using an API of a general purpose language. But otherwise, Pulumi does exactly what @nicolas decoster said Terraform does — keeping that desired state, creating a plan, previewing it, applying it, etc.
Regarding Kartik Agaram's problem, I think the solution in Pulumi would be similar to the one in Terrraform. Define a custom resource that does nothing than just block execution for an amount of time and then to the health check, then use this resource as a dependency of the second host you want to create.
Going back to the original question of whether it would make sense to have a visual editor for k8s config files, I don't think it would help that much. The problem with YAML is not that it's YAML, it's that it offers no means composition and abstraction. With only a visual editor that all it does is to offer affordances for YAML concepts, things will be the same. But, if that visual editors starts adding some PL concepts, such as variables and functions, then it can be useful, but at this point I think it's no longer about YAML or k8s, it's just about structural editors in general.