Open santiagordguez opened 7 years ago
I'm getting this @srodriguezOPT https://sp.int3.sonata-nfv.eu/api/v2/vims/b86771d2-2176-48d8-a484-a390e902cc29 [{"core_total":20,"core_used":7,"memory_total":51200,"memory_used":18432,"vim_city":"Athens","vim_endpoint":"10.100.32.200","vim_name":"Athens-200","vim_uuid":"1111-22222222-33333333-4444"}]
@felipevicens with the rate limiter you get a 429 HTTP code (Too many requests
). Do I understand correctly by @srodriguezOPT comment, that the problem is not there anymore?
Hi @felipevicens , @jbonnet
In the BSS,
responses with
{"status":201,"count":1,"items":{"request_uuid":"bd613b65-c2a7-45b9-999b-c8bddfcf911d"},"message":"OK"}
but
responses with
And as you mention, if the request is made directly in a browser, works fine
@srodriguezOPT , @felipevicens Let me check...
@srodriguezOPT The call is asyncronous. We need to wait until the answer is ready. The IA takes some time creating the reply to son-gtksrv. That's why the answer is empty
Exactly, just like the service instantiation requests...
A retrying policy with 1 second between requests was implemented in the BSS for the getVims. It seems solved but we must put an eye on this to confirm it.
@srodriguezOPT A better solution is the BSS to have an endpoint the GK could call when things are ready (a callback). That endpoint should be passed in the initial request. Same for the services instantiation, update and termination.
@jbonnet Yes, I agree. After this release, we need to develop a better solution for asynchronous requests. This solution (really ugly) is temporal for this release.
Hi @jbonnet
Once recovered the list of vim requests (GET /vims) that responses with
{"status":201,"count":1,"items":{"request_uuid":"b86771d2-2176-48d8-a484-a390e902cc29"},"message":"OK"}
the GET https://sp.int3.sonata-nfv.eu/api/v2/vims/b86771d2-2176-48d8-a484-a390e902cc29 responses with a "[]" but in the logs we can see:#son-gtkvim log:
son-gtkapi log:
Is this related with the rate limiter?