/ping endpoint

[sonata-nfv]

/ping endpoint

[felipevicens]

Hello @StefanUPB

In nginx, would be enough to add this to the default site:

location /ping {
    return 200 '{'ping': 'pong'}';
    add_header Content-Type application/json;
}

Or even:

location /ping {
    return 200 ':-)';
    add_header Content-Type text/plain;
}

[jbonnet]

@StefanUPB
Please mind that the returned status really reflects the component status, i.e., imagine the nginx is running hapilly without knowing the actual requests to the component are failling...

[stefanbschneider]

You're right. I guess it should somehow check if the GUI is accessible before sending the response. I'll have to think about how to do this. Do you have any suggestions?

[jbonnet]

@felipevicens
But what happens when the nginx is in a container and the service is in another? Does nginx already checks this with the configured upstreams?

[stefanbschneider]

Maybe what Felipe is suggesting is enough. After all, the descriptorgen is just a web-based GUI served by a web server (e.g., nginx). Users go to the container's IP to access the GUI and use the descriptorgen. So if nginx is running, the descriptorgen GUI should be accessible.

So far, there are no direct interactions with other components.

[felipevicens]

@jbonnet this nginx serve static files. I think is enough for "tng-sdk-descriptorgen"

In case of others repo, the answer is yes, we will need mechanisms to check the backend.

[jbonnet]

:-) fine on me

[efotopoulou]

@jbonnet @StefanUPB
My point of view, (maybe is too simplistic) is totally in line with @felipevicens . I do not think there is any need for an extra web server per component. Each component (ex.tng-policy-mngr) should support the /ping API. tng-devops component knows all registred components from sdk,V&V and sp , so maybe an extra test there could gather the 200 HTTP responses or report the failed interactions.