ok to ask about test:nginx here?

david.birdsong · 2015-12-30T05:46:30+00:00

Hi folks I am happy to announce the new formal release, 1.9.7.1, of the OpenResty web platform based on NGINX and Lua: https://openresty.org/#Download...

ok to ask about test:nginx here?

david.birdsong

In trying to write tests for some new code that uses ngx.balancer, I need some way to spin up some backends. What's a good way to have the test tool generate an entire server stanza that I can control.

Something like:

server {
listen 127.0.0.10:9001;
location / { return 404; }

}

http_config nor config appear to be the correct stanza to use.

agentzh

Hello!

On Tue, Dec 29, 2015 at 1:46 PM, David Birdsong wrote:
> In trying to write tests for some new code that uses ngx.balancer, I need
> some way to spin up some backends. What's a good way to have the test tool
> generate an entire server stanza that I can control.
>
>
> Something like:
> server {
>         listen 127.0.0.10:9001;
>         location / { return 404; }
>
> }
>
> http_config nor config appear to be the correct stanza to use.
>

Maybe you should take a look at the test suite for ngx.balancer itself
in the lua-resty-core repos? That is,

    https://github.com/openresty/lua-resty-core/blob/master/t/balancer.t

And the test suite for lua-resty-upstream-healthcheck may be helpful as well:

    https://github.com/openresty/lua-resty-upstream-healthcheck/blob/master/t/sanity.t

BTW, it's fine to discuss Test::Nginx here since it's still NGINX and
OpenResty related :)

Regards,
-agentzh

david.birdsong

On Tue, Dec 29, 2015 at 2:00 PM, Yichun Zhang (agentzh) <age...@gmail.com> wrote:

Hello!

On Tue, Dec 29, 2015 at 1:46 PM, David Birdsong wrote:
> In trying to write tests for some new code that uses ngx.balancer, I need
> some way to spin up some backends. What's a good way to have the test tool
> generate an entire server stanza that I can control.
>
>
> Something like:
> server {
> listen 127.0.0.10:9001;
> location / { return 404; }
>
> }
>
> http_config nor config appear to be the correct stanza to use.
>

Maybe you should take a look at the test suite for ngx.balancer itself
in the lua-resty-core repos? That is,

https://github.com/openresty/lua-resty-core/blob/master/t/balancer.t

I was looking at this one actually. I don't see any example of any additional listener sections.

I suppose I could set the upstream to the test port since the url doesn't overlap w/ the original request and so another location could match the circled-back proxy_pass request and return 404 as desired.

And the test suite for lua-resty-upstream-healthcheck may be helpful as well:

https://github.com/openresty/lua-resty-upstream-healthcheck/blob/master/t/sanity.t

BTW, it's fine to discuss Test::Nginx here since it's still NGINX and
OpenResty related :)

Regards,
-agentzh
.

agentzh

Hello!

On Tue, Dec 29, 2015 at 2:05 PM, David Birdsong wrote:
>
> I was looking at this one actually. I don't see any example of any
> additional listener sections.
>

Additional server {} blocks should go with your upstream {} blocks (if
any) in the same
--- http_config section. The "http_config" thing means putting custom
stuff inside the http {} block.

> I suppose I could set the upstream to the test port since the url doesn't
> overlap w/ the original request and so another location could match the
> circled-back proxy_pass request and return 404 as desired.
>

If you want to add more "listen" directives in the default server {}
block, then just add them to the --- config section as below

    === TEST 8: multiple listening ports
    --- config
        listen 8081;
        listen 8082;

        location = /t {
            echo $server_port;
        }
    --- request
    GET /t
    --- response_body
    1984
    --- no_error_log
    [error]

Regards,
-agentzh

david.birdsong

On Tue, Dec 29, 2015 at 2:14 PM, Yichun Zhang (agentzh) <age...@gmail.com> wrote:

Hello!

On Tue, Dec 29, 2015 at 2:05 PM, David Birdsong wrote:
>
> I was looking at this one actually. I don't see any example of any
> additional listener sections.
>

Additional server {} blocks should go with your upstream {} blocks (if
any) in the same
--- http_config section. The "http_config" thing means putting custom
stuff inside the http {} block.

> I suppose I could set the upstream to the test port since the url doesn't
> overlap w/ the original request and so another location could match the
> circled-back proxy_pass request and return 404 as desired.
>

If you want to add more "listen" directives in the default server {}
block, then just add them to the --- config section as below

=== TEST 8: multiple listening ports
--- config
listen 8081;
listen 8082;

location = /t {
echo $server_port;
}
--- request
GET /t
--- response_body
1984
--- no_error_log
[error]

Regards,
-agentzh

great, that's simple. i was stupidly restricting myself to location directives only. makes sense.

.

david.birdsong

On Tue, Dec 29, 2015 at 2:15 PM, David Birdsong <david....@gmail.com> wrote:

On Tue, Dec 29, 2015 at 2:14 PM, Yichun Zhang (agentzh) <age...@gmail.com> wrote:
Hello!

On Tue, Dec 29, 2015 at 2:05 PM, David Birdsong wrote:
>
> I was looking at this one actually. I don't see any example of any
> additional listener sections.
>

Additional server {} blocks should go with your upstream {} blocks (if
any) in the same
--- http_config section. The "http_config" thing means putting custom
stuff inside the http {} block.

> I suppose I could set the upstream to the test port since the url doesn't
> overlap w/ the original request and so another location could match the
> circled-back proxy_pass request and return 404 as desired.
>

If you want to add more "listen" directives in the default server {}
block, then just add them to the --- config section as below

=== TEST 8: multiple listening ports
--- config
listen 8081;
listen 8082;

location = /t {
echo $server_port;
}
--- request
GET /t
--- response_body
1984
--- no_error_log
[error]

Regards,
-agentzh

great, that's simple. i was stupidly restricting myself to location directives only. makes sense.

just to follow-up for posterity: i recall why re-using the existing server block doesn't help out.

it would be nice to be able to express a fully intact server stanza for testing upstream_by* and balancer_by*. for balancer tests, a fully encapsulated server stanza lets us fake out an entire backend. in my current example, i'm able to workaround using path and location to stub out a backend. for more complicated tests, an entire server means there's no issue with colliding url's sent upstream and existing location blocks in the server that originates the proxy_pass.

.

agentzh

Hello!

On Tue, Dec 29, 2015 at 2:42 PM, David Birdsong wrote:
>
> it would be nice to be able to express a fully intact server stanza for
> testing upstream_by* and balancer_by*. for balancer tests, a fully
> encapsulated server stanza lets us fake out an entire backend. in my current
> example, i'm able to workaround using path and location to stub out a
> backend.  for more complicated tests, an entire server means there's no
> issue with colliding url's sent upstream and existing location blocks in the
> server that originates the proxy_pass.
>

Well, if I understand you correctly, you can just put your own server
{} block(s) under --- http_server. It's common practice in the
openresty testing world.

Regards,
-agentzh

david.birdsong

On Tue, Dec 29, 2015 at 2:46 PM, Yichun Zhang (agentzh) <age...@gmail.com> wrote:

Hello!

On Tue, Dec 29, 2015 at 2:42 PM, David Birdsong wrote:
>
> it would be nice to be able to express a fully intact server stanza for
> testing upstream_by* and balancer_by*. for balancer tests, a fully
> encapsulated server stanza lets us fake out an entire backend. in my current
> example, i'm able to workaround using path and location to stub out a
> backend. for more complicated tests, an entire server means there's no
> issue with colliding url's sent upstream and existing location blocks in the
> server that originates the proxy_pass.
>

Well, if I understand you correctly, you can just put your own server
{} block(s) under --- http_server. It's common practice in the
openresty testing world.

cool, i was wondering about that and in the process of trying out a simple test.

Regards,
-agentzh

.