[EnMasse] Upcoming REST API changes

[Ulf Lilleengen]

On 05/09/2018 10:17 AM, Lohmann Carsten (INST/ECS4) wrote:
>>
>> Agreed with this logic, it might not be an issue then. So just thinking about the
>> resource then, it could be something like:
>>
>> apiVersion: enmasse.io/v1
>> kind: AddressSpace
>> metadata:
>>     name: myspace
>> spec:
>>     type: standard
>>     plan: small-standard
>>     addresses:
>>       - address: myqueue
>>         type: queue
>>         plan: small-queue
>>       - address: mytopic
>>         type: topic
>>         plan: small-topic
>> status:
>>     isReady: true
>>     addresses:
>>       - address: myqueue
>>         phase: Configuring
>>         isReady: false
>>         messages:
>>           - "Autolink not present on router"
>>           - "Address not present on router"
>>       - address: mytopic
>>         phase: Active
>>         isReady: true
>>
>> Making status a subresource, we can then also assign permissions so that only the
>> internal controllers may update the status whereas the user only get read
>> permissions (same as for pods).
>>
>> I think doing this would be a great simplification from a user POV, so I really hope
>> it can work.
>>
>> As a first step, I can modify the API server to consume this format and convert
>> to/from the configmaps we use today.
>>
>> Wdyt? Are there any tests we should/can do to ensure that this approach will
>> actually work? Any other concerns?
> 
> One thing to note here, is that I guess with this solution, there is no direct way to delete single addresses via kubectl.
> 
>  From what I see, with a command like this
> kubectl patch AddressSpace my-addressspace --type json -p='[{"op": "remove", "path": "/spec/addresses[0]"}]'
> referencing a specific "address" element can only be done using indexes, not via a value match.
> 
> Concerning the HTTP API, I guess there would be need to be "non-standard" methods/resources added in order to support adding/deleting single addresses (so that no replacing of the whole address list in the address space is needed by the API user).
> 

Good observation Carsten. As you say, we can still keep an 'extended' 
REST API to do the kind of operations that is difficult when everything 
is bundled into the address space definition.

I just tried adding the path

/v1/namespaces/[:namespace]/addressspaces/[:name]/addresses

to the REST API, and using that path proxies through the kubernetes 
master, and that works.

This means that even though oc/kubectl be used to manage single 
addresses, that will still be possible using the REST API. I.e. the 
standard-controller/agent can still operate on separate address 
resources as today, whereas the CRD exposed to kubectl will be the 
address space definition with the addresses defined.

It seems to me that this provides the best of both worlds. We get a nice 
way for users to manage address space and addresses in a single unit, 
_and_ a way for our internal components to operate on smaller units.

The REST API simply provides different URLs for different views into the 
data. The storage of the data is fully orthogonal to those views.

I like that!

Best regards,

Ulf