Hi guys,
On Thu, Jul 20, 2017 at 02:35:22PM +0200, Adis Nezirovic wrote:
> On 07/20/2017 12:17 PM, Thierry FOURNIER wrote:
> > I understand the problem, but I can't accept this patch because it makes
> > the proxies list unusable. Your patch remove the proxies names, and the
> > user cannot have solution for knowning the real name of the proxies
> > now called 1, 2, 3, ...
> >
> > I propose 2 solutions:
> >
> > - Two new lists called "frontend" and "backend" with no name collision
> > by design
> >
> > - a prefix "@f:" for fontend and "@b:" for backends and keep the name
> > without prefix for the compatibility.
> >
> > I prefer the two new lists.
>
> Hello Thierry,
>
> Yeah, dropping the name might be inconvenient, we were traversing the
> proxy list and calling get_stats() on each object, and fetched "pxname"
> attribute.
>
> How about different approach, can we set "name" and "type" attribute for
> Proxy objects? Maybe expose some other attributes (id, ...)
The difficulty is that it is allowed to have both a frontend and a backend
with the same name. This is so that configs using a "listen" section can
easily be split into "frontend" and "backend" and continue to work (think
about "use_backend", "track bkname/srvname", tables and so on).
The per-proxy lookup is necessary in order to be able to find a proxy by
its name (think about the Lua equivalent of "use_backend"). However what
is certain is that for a given name, there cannot be more than two proxies
because you cannot have overlapping capabilities (frontend and backend).
So you can have :
0 or 1 "listen"
0 or 1 "frontend" + 0 or 1 "backend"
Just a few ideas come to my mind :
- is it possible to store arrays into arrays ? I mean, could we have
for example core.proxies["foo"].side[FRONT|BACK] where each side is
set only when the two differ ?
- or is it to return a list (1 or 2 elements) ? That would be even more
convenient to use. If you have "p = core.proxies[foo]" and can use p
then next(p), you're sure to always scan everything.
- otherwise I like the principle of being able to force the type using
a prefix "@f:" or "@b:" in front of the name. But we must be careful
not to insert duplicates. So probably by default only "listen" instances
would be created without the "@" prefix. My initial idea was to be able
to always return the plain form and point to whichever exists, but for
enumeration it would require to keep only the "@" form, which might be
more complicated.
> Also, apply the same logic to the 'Listener' and 'Server' classes.
These ones do not support duplicate names so we should not need to impact
them.
Just my two cents,
Willy
