Ok, thanks.

Can you imagine any other viable way to pass some information to each
server? It doesn't need to change between server restarts.
I may use a distinct variable for each of them but this seems ugly and
error-prone...

In case you are curious why would I need this, let me explain.
Upstream directive support "hash consistent" method and in that case it
uses `ketama` algorithm. That means that each server assigned a key and
depending on its value (actually hash of that value) each server mapped to
a multiple points on the ketama ring. So far so good.
Documentation says that keys distribution is compatible with Perl
Cache::Memcached::Fast module. And that means that key for each server is
"$ip\0$port" (or something else for unix sockets, doesn't matter).
This means that if server ip changes, position of server points on ketama
ring will change too. Now, I'm balancing via this upstream not memcacheds
or other rather ephemeral storages but files. Each server in the upstream
have a hundreds of gigabytes of files. And I would like to avoid
rebalancing all these files in case of public ip changes.
So my idea was to pass a key for each server via parameter. Actually, to
preserve compatibility with current keys, I would pass a base64 of
"$ip\0$port" value, decode it during module init and happily use it for
ketama purposes. And be safe against servers redeployments.


Best regards,
Dmitriy Shalashov

2015-02-12 16:36 GMT+03:00 Maxim Dounin <mdounin@mdounin.ru>:

> Hello!
>
> On Wed, Feb 11, 2015 at 09:40:12PM +0300, Дмитрий Шалашов wrote:
>
> > Hi!
> >
> > As far as I see Nginx have limited number of possible server parameters
> > inside upstream block. It is enforced by function
> ngx_http_upstream_server for
> > example.
> > Now, having my own upstream module how can I approach the task of adding
> a
> > couple more parameters to a servers inside it?
>
> You can't. Parameters of the "server" directive are not currently
> extendable.
>
> > I would like to find a solution without resorting to patch Nginx source
> > code, resilient to Nginx updates (self-contained, in other words) and
> > having that -- as simple as possible.
> >
> > I have to confess that this module is the only piece of C code I've ever
> > wrote, and I was "taking inspiration" from other modules :-)
> > My best guess so far is overriding ngx_http_upstream_server (googling
> shows
> > it's likely possible) with my own function which will find my new
> > parameters, remove them from cf->conf and then call original function.
>
> While this approach may work, it will likely result in big
> problems in the future.
>
> --
> Maxim Dounin
> http://nginx.org/
>
> _______________________________________________
> nginx-devel mailing list
> nginx-devel@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel