[EnMasse] Upcoming REST API changes

[Ulf Lilleengen]

On 05/08/2018 11:20 AM, Rob Godfrey wrote:
> 
> 
> On 8 May 2018 at 11:02, Gordon Sim <gsim at redhat.com 
> <mailto:gsim at redhat.com>> wrote:
> 
>     On 08/05/18 04:17, Ulf Lilleengen wrote:
> 
>         For addresses, the REST API also changes in the same way, making
>         the addresses scoped by both namespace and address space. The
>         metadata.addressSpace field will be mandatory now that it cannot
>         be inferred from the URL path anymore.
> 
>         Creating multiple addresses at once using AddressList is
>         removed, as this is handled client-side when using the kubectl
>         command line and not server-side. We could still keep it at
>         server side if we think it will be of value.
> 
> 
>     To create 10,000 addresses, I think one request with a large payload
>     might be simpler than 10,000 separate requests.
> 
> 
> Agreed - but I think this only makes sense in the context of creating 
> multiple addresses within a single address space.
> 

Yes, we could still keep the API. It just won't be used by the 
oc/kubectl client.

> 
*SNIP*
> 
>         To delete an address:
> 
>         DELETE /apis/enmasse.io/v1/namespaces/myproject/addresses/addr1
>         <http://enmasse.io/v1/namespaces/myproject/addresses/addr1>
> 
> 
> 
> Will it be possible to use the URL query / labelSelector in the 
> PUT/DELETE as well as GET?  Otherwise I presume you are first going to 
> need to query for the address "name" using a GET (since the name may 
> must essentially just be an ID for an (addressSpace, address) pair).
> 

Hmm, a very good point. We can add the labelSelector to those operations 
as well, but it seems to be a very clunky approach.

>     Does that mean an address is unique within the namespace? I.e. if I
>     have two address spaces in the same namespace, they cannot contain
>     addresses with the same name/address? If so, I'm not sure how much
>     value there is in having separate address-spaces in the same
>     namespace. To what extent is that a conscious design choice as
>     opposed to something forced on us by adopting CRDs?
> 

An address is not unique within the namespace, but as Rob pointed out, 
we would need the ability to use labelSelectors to identify which when 
deleting for instance.

The design is very much forced by the CRDs.

>     To me, a more intuitive API would access the addresses via the
>     address-space, e.g.
>     /apis/enmasse.io/v1/namespaces/myproject/addressspaces/myspace/addresses/
>     <http://enmasse.io/v1/namespaces/myproject/addressspaces/myspace/addresses/>
>     and/or even directly setting the addresses as part of the
>     address-space definition. That makes the containment more obvious
>     and also scopes the addresses to address-space.
> 

I agree it is more intuitive and would be my preference if the goals was 
to create a REST API without considering CRDs.

Unfortunately, the aggregated api server cannot extend the path for the 
resources in that way. It does support a concept of subresources, but at 
first sight it seems to be too limiting to be used by addresses.

One of my goals with this work is that we in the future could migrate 
all components today working on configmaps to use this API instead 
(through the kubernetes master). This would allow us to change how we 
persist the data from configmaps to something more fitting.  My worry is 
that if we put all addresses into the address space definition, we would 
end up facing issues in standard-controller and agent due to status 
updates needing to fetch/query a lot of data when one of the addresses 
change.

If we can use subresources in a way that would avoid that problem, then 
I agree it would be better to define addresses as part of address spaces.

> 
> I prefer this form - it is much more natural from a usability perspective.
>
> Further, when we talk about "addressSpace" and "address" here, are we 
> talking about the names as the user will understand them (i.e. not bound 
> by kubernetes naming restrictions) or some sort of mangled form are 
> valid kubernetes names?
> -- Rob
> 

In the REST API paths, its the sanitized form as it is today.

> 
>     _______________________________________________
>     enmasse mailing list
>     enmasse at redhat.com <mailto:enmasse at redhat.com>
>     https://www.redhat.com/mailman/listinfo/enmasse
>     <https://www.redhat.com/mailman/listinfo/enmasse>
> 
> 
> 
> 
> -- 
> _____________________________________________________________________________
> 
> Red Hat GmbH, www.de.redhat.com <http://www.de.redhat.com/>,
> Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, 
> HRB 153243,
> Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, 
> Michael O'Neill
> 
> 
> _______________________________________________
> enmasse mailing list
> enmasse at redhat.com
> https://www.redhat.com/mailman/listinfo/enmasse
> 

-- 
Ulf