Use index instead or enclave name of hash for enclave and engine names

[barnabasbusa]

Background & motivation

Would it be possible to migrate from kurtosis-enclave--af4a70624dae4a91a91cab4cfdc37f75 to kurtosis-enclave--0 and possibly kurtosis-enclave--1,2,3 in case of multiple enclaves?

Same for engine; going from kurtosis-engine--856cb53dd06c425c988612a366fec76b to kurtosis-engine--0

It can be somewhat confusing when you have multiple enclaves running at the same time, and have to switch among them.

Desired behaviour

Mentioned above.

How important is this to you?

Nice to have; this feature would make using Kurtosis more enjoyable.

[mieubrisse]

Hey @barnabasbusa , could explain more how you're coming across the enclave UUID and how you're doing the switch between them? We try to make the name the central feature by which enclaves are manipulated, e.g.:

$ kurtosis enclave ls
UUID           Name               Status     Creation Time
79813f61cdf7   gloomy-steppe      RUNNING    Mon, 17 Jul 2023 13:27:02 -03
0222af561e1f   calm-orchard       RUNNING    Mon, 17 Jul 2023 14:25:55 -03
93f3016a4d09   dull-marsh         RUNNING    Mon, 17 Jul 2023 14:26:38 -03
11e998fee997   lazy-sea           RUNNING    Mon, 17 Jul 2023 14:26:49 -03
3e4466c0210f   stunning-atoll     RUNNING    Mon, 17 Jul 2023 14:33:53 -03
c5d35f9492de   aged-reef          RUNNING    Mon, 17 Jul 2023 14:38:06 -03
6aa3c8c99351   empty-glade        RUNNING    Mon, 17 Jul 2023 16:23:35 -03
6fcb12f513dc   sacred-plateau     RUNNING    Tue, 18 Jul 2023 10:19:42 -03

[barnabasbusa]

My primary interaction with the content of an enclave is kubectl, and namespaces, not kurtotis itself (yet).

[mieubrisse]

Ah, got it. I'd be keen to learn more about what workflows are missing in the kurtosis CLI for that to be your primary interaction with Kurtosis? We try to make the CLI pleasant to use with lots of quality-of-life stuff (e.g. tab-complete for all fields, descriptive error messages, etc.)

[barnabasbusa]

My primary usecase for kurtosis will be chaos testing. In order to do that, I'll have to deploy chaos tools, such as chaos-mesh to play around with the latency of the pods on different nodes.

This will require me to fetch pod labels/podIDs and other kube resources directly from kubectl.

Highly doubt that this is going to be use case for most users, thus I would keep these away from kurtosis. I just wanna make sure that there is a good enough experience for users that use kubectl also.

I already have tab complete for all fields, and I'm happy to use kurtosis for basic debugging.

Looking at logs for a long time via kurtosis seems to time out every now and then though.

[mieubrisse]

Ah thanks for explaining - makes sense. I agree that Chaos Mesh shouldn't be a part of Kurtosis (at least for right now - maybe in the future). Re. using labels - you can actually use the com.kurtosistech.enclave-name label to find a namespace by name! And the namespace UUID is available in the com.kurtosistech.guid field on the namespace. For pods, they'll also have the com.kurtosistech.enclave-id field that corresponds to the enclave's com.kurtosistech.guid, so you should actually be able to do all the dereferencing that Kurtosis does purely through Kubernetes labels.

Re. looking at the logs for a long time and getting a timeout - would you mind filing a bug ticket for this, preferably with a copy-paste of error and the result of kurtosis engine logs as well? You can easily file bugs using kurtosis feedback --bug from the CLI!

[mieubrisse]

For this ticket though, we're truthfully not very likely to change the enclave naming scheme in Kubernetes. We actually used to name the namespace after the enclave name, but we undid it because Kubernetes is very restrictive on item naming (no longer than 63 characters, only lowercase alphanumeric and -) and it proved annoying for users. Additionally, using enclave name (rather than UUID) as a unique identifier would also mean that no two users on the same cluster could have enclaves with the same name (so you and I couldn't both have a test enclave).

[barnabasbusa]

Re. using labels - you can actually use the com.kurtosistech.enclave-name label to find a namespace by name! using enclave name (rather than UUID) as a unique identifier would also mean that no two users on the same cluster could have enclaves with the same name (so you and I couldn't both have a test enclave).

Is there a strong reason to have this possibility? I feel like this is can cause more issues than resolve them. If you have multiple enclaves with the same name, how can you remove your enclave with name test but ensure that someone else having access to the cluster doesn't get their enclave nuked thats also called test ? I would be in favor to use unique enclave names, otherwise you would never know if you want to create a new enclave or edit a running one.

you can actually use the com.kurtosistech.enclave-name label to find a namespace by name

Would it be possible to have these labels part of each pod as well? This would help me find a specific pod that I want to set a certain restriction to. Otherwise I will have to use the enclave-id to look up the corresponding guid and parse that way. Feels like an extra step for no reason?

would you mind filing a bug ticket for this

https://github.com/kurtosis-tech/kurtosis/issues/998

we're truthfully not very likely to change the enclave naming scheme in Kubernetes

I'm quite sad to hear that.

restrictive item naming proved to be annoying for users

Would it be a good compromise to use the enclave name as a namespace if its RFC 1123 compliant, and use the generated one otherwise or possibly make(convert) the namespace RFC 1123 compliant; e.g: enclave name: Test -> test? I have a hard time believing that there are that many users that want to use special characters/super long enclave names anyway. I don't see 1123 as a huge annoyance personally, but I'm happy to be proven otherwise.

[mieubrisse]

@barnabasbusa deterministic names are coming in #1100

[mieubrisse]

Fixed now that #1100 is out