Deprecate support for short JobIDs about bacalhau HOT 4 CLOSED

I think we should try and understand why it's there in the first place, and what problem it's intended to solve.
If it's push back against using v4 UUID strings (because they are unwieldy or because of problems with space in the terminal) , then we could look at using something like Stripe API IDs (they use then like cus_9s6XKzkNRiz8i3 with a type and then ID).

from bacalhau.

Honestly, my biggest thing is that it feels like we're optimizing for making things easy for us instead of for end users.

BUT, if we offered things like tab completion, and IDs with types (agree with @rossjones here), etc, i think that makes things easier.

I'm surprised it's that big an issue - why aren't we converting the ID to long the moment we get it from the user and then convert it immediately?

from bacalhau.

Honestly, my biggest thing is that it feels like we're optimizing for making things easy for us instead of for end users.

It is not a bad thing to build something that is maintainable :). I believe we are all trying to find a balance here between maintainably and user experience, and that is why @frrist is bringing this up.

I'm surprised it's that big an issue - why aren't we converting the ID to long the moment we get it from the user and then convert it immediately?

Converting a short ID back to a long ID isn't straightforward. We will have to do a lookup in the data store to find all jobs with short ID prefix. This means we will have to design the data store or add indexes that enables constant or logarithmic lookups of short IDs, and handle collisions.

Overall, this problem is not unique to job IDs, but to execution, evaluation and node IDs as well. There is a need to generate globally unique IDs for these resources, specially as we move more towards distributed orchestrators and federated clusters. At the same time I agree with @aronchick that presenting and working with shorter IDs is more user friendly, specially when presenting things on the terminal.

The options I see are:

Option 1: Use shorter and globally unique IDs. An example would be to use Base64 representation of UUIDs, which will look like: 550e8400-e29b-41d4-a716-446655440000 -> VQ6EAOErQdSnFkRmVURA. This will reduce the ID length from 36 to 22. Still larger than our current 8 character short IDs, but much smaller than long IDs.

Option 2: Keep supporting short to long ID translations, but standardize it, limit its use to certain places or make it part of job store interface so we don't forget about supporting it such as what happened with boltdb. If it is useful only for CLI users and not API or SDK users, then maybe we can explore exposing an API to translate a short ID to list of long IDs, and only support translation in the CLI or enable auto-complete as @aronchick suggested.

Overall, I don't think we can have it as an option where we only support the long IDs that we have today

from bacalhau.

What specifically about the long Job IDs we generate right now are challenging to work with? One thing I find challenging about them is that I cannot copy them by double clicking, due to hyphens. If we removed the hyphens or replaced them with underscores this would alleviate that. Are there other things we dislike? I'd be in favor of option 1, perhaps with the modification that we use a different UUID generator like the stripe one.

from bacalhau.