Boskos does not allow duplicate resource name even for different types

[amwat]

resources:
- type: bar
  names: 
  - foo
- type: qwe
  names:
  - foo

results in {"error":"duplicated resource name: foo","level":"fatal","msg":"failed to create ranch!" }

This seems like something we should support?

/cc @krzyzacy @ixdy @sebastienvas

[krzyzacy]

no the CRDs cannot have the same name, unless we change CRDs to $name_$type

[amwat]

yeah, was imagining something similar

[krzyzacy]

easier just name them that way :-)

[amwat]

Eh, technically my job just cares about the name. I shouldn't need to split string etc. to get it.
whereas the CRD naming scheme is arbitrary.

[ixdy]

I agree that this is something we should support.

/area boskos

[krzyzacy]

feel free to decouple the internal naming scheme from config :-)

[lilinji]

/area boskos

[stevekuznetsov]

Let's not flatten structured data into strings for naming on the CRDs. Can we use other unique identifiers?

[ixdy]

We could possibly move the name of the resource (from the ConfigMap) to the spec and then use an autogenerated name for the actual kubernetes object (possibly based on the resource name).

The kubernetes object name can only be up to 253 characters long, and can only contain digits, lower-case letters, -, and .. So it definitely does not make sense to try to put the resource type into the object name.

[sebastienvas]

what s wrong with using a hash from (type, name), the only issue is that any change like is backward incompatible, so might need to migrate your resources.

[ixdy]

it's nicer to manually list resources if they have human-readable names (instead of hashes or UUIDs).

OTOH, not using the name at all (or obfuscating it) would allow names that don't match the strict DNS requirements. (Not an issue at the moment, but maybe it could be someday - e.g. what if you wanted to list service account names which included @ symbols?)

[ixdy]

passing thought: /acquirebystate currently assumes that all resources have unique names. We'd have to modify this API (in some backwards-compatible way?) to allow specifying types as well.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[ixdy]

Moving this issue to kubernetes-sigs/boskos#14.
/close

[k8s-ci-robot]

@ixdy: Closing this issue.

In response to this:

Moving this issue to kubernetes-sigs/boskos#14.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.