Closed tzach closed 10 years ago
tgrabiec
commented
10 years ago In this scheme I will not be able to subscribe to OSv if I am behind a firewall, without being able to reconfigure the firewall behind me. Is it not our concern, why?
Why not putting the client on the initiating side? Client could maintain an active connection with OSv.
tzach
commented
10 years ago In this scheme I will not be able to subscribe to OSv if I am behind a firewall, without being able to reconfigure the firewall behind me. Is it not our concern, why?
Yes, the client will need to explicitly include his public (external) IP in the request.
Why not putting the client on the initiating side? Client could maintain an active connection with OSv.
Do you mean pooling? It is basically what we have now. The problem is either requests are often (loading the system), or rare (slow response to notifications). Notification give both. This suggestion is following SNMP convention for monitoring. It is less natural with REST.
tgrabiec
commented
10 years ago 2014-02-13 10:37 GMT+01:00 Tzach Livyatan notifications@github.com:
In this scheme I will not be able to subscribe to OSv if I am behind a firewall, without being able to reconfigure the firewall behind me. Is it not our concern, why?
Yes, the client will need to explicitly include his public (external) IP in the request.
Why not putting the client on the initiating side? Client could maintain an active connection with OSv.
Do you mean pooling?
No, the OSv would send the data (push), but it would be the client who is initiating TCP connection, which remains active as long as the client is interested.
I still don't see why the connection needs to be initiated by OSv, but I can see that it causes problems (firewall, NAT, client moved to another server).
It is basically what we have now. The problem is either requests are often (loading the system), or rare (slow response to notifications). Notification give both. This suggestion is following SNMP convention for monitoring. It is less natural with REST.
Reply to this email directly or view it on GitHubhttps://github.com/cloudius-systems/mgmt/issues/26#issuecomment-34961858 .
tzach
commented
10 years ago @tgrabiec The more I think about it, the more I think REST is not necessarily the right interface for notifications. A better fit might be the logger interface which we plan.
An example from a related platform: http://pubs.vmware.com/appdirector-5/index.jsp?topic=%2Fcom.vmware.appdirector5.api.doc%2FGUID-064292E4-E722-43B5-8FB5-DCAA91B8331D.html
REST API is use for registration, AMQP is used for the notification
tzach
commented
10 years ago I came to a conclusion REST API is not the right way to send operational notifications.
OS should be able to send notification (traps) to external monitoring system. Regular REST API, require HTTP server on OSv Notification require HTTP client on OSv to connect to an external HTTP server. This can be done in two ways:
The subscription API should includes the IP to report to, and registration time. It can be later extended to register on particular events.
Number of external subscription should be limited and managed, to avoid large number of subscription slowing the system down. Practically, there is no reason to have 1 digit number of subscriptions.