Skip to content
Snippets Groups Projects
Select Git revision
  • master default protected
1 result
Search by author
  • Any Author
  • aas13 aas13 aas13
  • jiachun5 jiachun5 jiachun5
  • tabassm2 tabassm2 tabassm2
3 authors
  1. Sep 28, 2018
  3. Sep 26, 2018
  5. Sep 25, 2018
  7. Sep 23, 2018
    • Richard Gee's avatar
      Change the http status code on unfound function error to 404 · e3306170
      Richard Gee authored 
      
Signed-off-by: default avatarRichard Gee <richard@technologee.co.uk>
      e3306170
    • Richard Gee's avatar
      Add checking for existent function in GetReplicas · df6f4c49
      Richard Gee authored 
      
Within MakeScalingHandler() there is a call to GetReplicas() which was not returning an error when a non-200 http response was received from /system/function/.  The call would also return a populated struct, so the perception was that a function existed an had been scaled to zero.  This meant that the function would be added to the function cache and the code would continue into SetReplicas() where an attempt would be made to scale up a non-existent function.

This change amends GetReplicas() so that it will return an error if the gateway returns anything other than a 200 reponse code from the /system/function/ endpoint.  This causes MakeScalingHandler() to return earlier with an error indicating that the function could not be found.  The cache.Set call is also moved to after the error check so that the cache is only updated to include existent functions.

During investigations as to the cause of #876 tests were added to function_cache to check that Get() is behaving as intended when function exists and when not.  Tests are also added to plugin/external to test that GetReplicas() and SetReplicas() are following their intended modes of operation when 200 and non-200 responses are received from the gateway.

Signed-off-by: default avatarRichard Gee <richard@technologee.co.uk>
      df6f4c49
  9. Sep 20, 2018
  11. Sep 19, 2018
  13. Sep 18, 2018
  15. Sep 17, 2018
    • Alex Ellis (VMware)'s avatar
      Alter graceful shutdown sequence · e67811c9
      Alex Ellis (VMware) authored 
      
- the shutdown sequence meant that the kubelet was still passing
work to the watchdog after the HTTP socket was closed. This change
means that the kubelet has a chance to run its check before we
finally stop accepting new connections. It will require some
basic co-ordination between the kubelet's checking period and the
"write_timeout" value in the container.

Tested with Kubernetes on GKE - before the change some Pods were
giving a connection refused error due to them being not detected
as unhealthy. Now I receive 0% error rate even with 20 qps.

Issue was shown by scaling to 20 replicas, starting a test with
hey and then scaling to 1 replica while tailing the logs from the
gateway. Before I saw some 502, now I see just 200s.

Signed-off-by: default avatarAlex Ellis (VMware) <alexellis2@gmail.com>
      e67811c9
  17. Sep 16, 2018
  19. Sep 15, 2018
  21. Sep 14, 2018
  23. Sep 12, 2018
  25. Sep 10, 2018
  27. Sep 08, 2018
  29. Sep 06, 2018