[EnMasse] Upcoming REST API changes

[Lohmann Carsten (INST/ECS4)]

Hi,

> To create address space:
> 
> POST /apis/enmasse.io/v1/namespaces/myproject/addressspaces
> Return: the created address space
> 
> The 'namespace' field in the metadata previously decided in which namespace the
> messaging infrastructure was created. This is now instead indicated by the
> 'enmasse.io/namespace' annotation and should be regarded as an implementation
> detail as we eventually move towards sharing the infrastructure between address
> spaces.

I think, naming the annotation something like 'enmasse.io/messaging-infrastructure-namespace' instead of 'enmasse.io/namespace' could make that relationship clearer.
That would make it clear, that the namespace containing address-controller, keycloak, etc. is not meant here.


> >     Presumably each CRD needs to have a unique name/identity though?
> >     Using kubectl, how would you delete an address? I guess one approach
> >     would be to prefix the address with the address-space name/id to get
> >     the addresses own identity?
> >
> >
> > such prefixing can't (easily) produce guaranteed uniqueness though,
> > for simplicity, assume the separator character is - : address space
> > a-b with address c would give the same compound address as space a,
> > address b-c
> 
> You could reserve some special character as the separator and not allow it in
> address names (so one restriction, but much less than implied by kubernetes
> names). (e.g. # @ $...)
> 
> Not ideal though I agree. I'm not seriously proposing that either, just thinking
> aloud.

Perhaps using "." as a separator for the address Kubernetes name (i.e. "addressSpaceName.addressName") and restricting address space names to not contain ".".
There are anyway not many special separator chars to choose from (K8s names: "..maximum length of 253 characters and consist of lower case alphanumeric characters, -, and .").

(Another idea in order to simplify the (K8s-) naming of the addresses would be to restrict 1 Namespace to only have 1 AddressSpace - kind of having a AddressSpace CRD singleton per Namespace. If messaging infrastructure is in another Namespace anyway, that could possibly be not too much of a restriction. But I guess it would feel unnatural in terms of the K8s API and could prevent some valid use cases.)

Best regards 
Carsten Lohmann

(INST/ECS4) 
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com 

Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber, Michael Hahn