Clearer responsibility of `kosli create` command

[dangrondahl]

Going through the CLI reference, and with a background in Kubernetes, I am a bit confused on the impact and functionality of kosli create having both create and update functionality.

I was wondering if it at some point would make sense to consider introducing kosli apply <resource> as a more clear update method for resources.
This also implies changing kosli create <resource> to only cover creation of new resources. This will cause a breaking change.

To elaborate: Users that are familiar with Kubernetes would know that the different between these two commands are:

• kubectl create (imperative): Creates a new resource, fails if already present.
• kubectl apply (declarative): Creates a resource if not existing, otherwise it updates the resource.

Moreover kubectl apply is idempotent, meaning state doesn't change upon applying the same resource several times. As a kosli user, it is bit unclear to me if e.g. kosli create flow is actually idempotent when recreating the exact same resource, i.e. does state change?

To recap perceived outcome would be:

• Better aligned with already established Kubernetes practices, similar to how kubectl, GitOps, etc. works.
• Clearer functionality: I'm more in control of what I actually want kosli create/apply to do.

[dangrondahl]

Also a bit confused on the update part of kosli begin trail. "Begin" sounds like creation, hence more similar to kosli create (trail).

[tooky]

One of the principles of create being used for both creation and update was that it could be a command that was part of a CI workflow. You can rerun create and if there are no changes it would do nothing. If there were, it would perform the update.

This does 2 things:

1. It means you don’t need to put if-then checks in workflow, around a create command. Making it easier to roll out
2. You can use git to manage the Kosli resources, meaning that you update files/variables in the repo to update Kosli.

I think it’s worth considering if this principle is still what we want as part of considering this issue.

I also think we should consider it in the context of providing more IaC options for customers rolling Kosli out across a very large estate. “Less CLI/click ops, more standard tools.”

[dangrondahl]

I agree and having an update functionality makes total sense as not to have the if/else check etc. Both points are valid.

So maybe I'm just splitting hairs here, but to me create commands normally guarantees to only cover creation of new resource, otherwise it will fail.
In other words, create guardrails me to not create an already existing resource. However, current kosli create behaves similar to kubectl apply.

It's about the CLI being explicit about what it does (imperative/declarative), leaning on conventions from other well known systems, like Kubernetes.

So if we magically had a kosli apply <resource>, I would immediately understand it's create-otherwise-update functionality. :)