[EnMasse] Upcoming REST API changes

[Ulf Lilleengen]

tir. 8. mai 2018 kl. 03:23 skrev Gordon Sim <gsim at redhat.com>:

> On 08/05/18 11:13, Ulf Lilleengen wrote:
> > 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.
>
> At present they need to do that anyway, as there is no reliable way of
> tracking changes (especially deletions) except by periodically
> retrieving the whole list.


The periodic resync  is less frequent than the status checks which is what
typically trigger the watches a lot when configuring many addresses. If we
put addresses into then address space definition, then all addresses is
read on every update to any address, whereas today only a single address is
read when the status is changed.


>
> Would the same 'watch' approach be used with these APIs also or would
> there be something different?
>
Yes, watches would eventually need to be supported as well before we could
use this api internally.

However, just an idea on the status ‘problem’: we could remove the status
field from the address definition, and instead make the status field on the
address space aggregate all of the events occurring for addresses. This
could reduce the “storm” of events a bit (isReady true/false) when
configuring many addresses. I’m not sure what to do about the “phase”
though which doesn’t aggregate that well and is used to track the state of
the address.

The status itself maps well to a sub resource that can be independently
read/written from the main resource.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/enmasse/attachments/20180508/5d10334c/attachment.htm>