<div dir="ltr">There used to be a limit of 1MB per ConfigMap AFAIK (which is driven by etcd default record size, so CRD would have similar limit). If that is still valid, do you plan to split the addresses into several ConfigMaps? Because 1MB doesn't give you much space for 10000+ addresses.<div><br></div><div>Regards</div><div>Jakub</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 13, 2018 at 10:47 AM, Ulf Lilleengen <span dir="ltr"><<a href="mailto:lulf@redhat.com" target="_blank">lulf@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On 03/13/2018 10:40 AM, Gordon Sim wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 13/03/18 09:16, Ulf Lilleengen wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If one address status needs to be changed, the controller then have to read/write 1000 addresses worth of data, so I wouldn't say that it is more manageable. If the problem is that the kubernetes master is overloaded by enmasse use, this could even make it worse.<br>
</blockquote>
<br>
It is certainly speculative, but often smaller numbers of slightly larger data items are easier to manage and cause less load. While updating status would indeed cause some unneeded data transfer, retrieval of the addresses (which I would argue is by far the more common operation, assuming the addresses change relatively infrequently on a running system) would involve far fewer calls. Likewise for a bulk update of addresses (10,000 PUTs will generally cause more load that 10, even if the latter have more data in them).<br>
<br>
</blockquote>
<br></span>
I think we already read addresses in batches by reading a ConfigMapList (though maybe that translates to 10000 reads from etcd, I'm not sure if it supports it natively).<br>
<br>
A PUT with AddressList currently generates 10000 configmap PUTs. However, I think that could be improved by moving to custom resources as well, as you get 'native' support in the kubernetes API for doing a list PUT.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In any case though, I would suggest we start with some actual experiments on pushing the scale wrt the number of addresses and find out where the actual bottlenecks are and figure out how to alleviate them.<br>
</blockquote>
<br></span>
Fully agreed, numbers don't lie (usually :))<br>
<br>
Best regards,<br>
<br>
Ulf<div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<wbr>_________________<br>
enmasse mailing list<br>
<a href="mailto:enmasse@redhat.com" target="_blank">enmasse@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/enmasse" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/enmasse</a><br>
</div></div></blockquote></div><br></div>