Closed loewenstein closed 8 years ago
We have created an issue in Pivotal Tracker to manage this:
https://www.pivotaltracker.com/story/show/121205093
The labels on this github issue will be updated when the story is started.
Hi @loewenstein! I just saw this slack thread and wanted to follow up with you https://cloudfoundry.slack.com/archives/cf-docs/p1465928312000007. Do you have any updates surrounding this issue?
No. Unfortunately I did not get any response yet.
Hello @loewenstein, if you haven't heard anything back, I think I'm going to go ahead an close this issue. But please feel free to re-open if you get any new information!
Hi @ljarzynski,
The current description in the docu is apparently pretty useless (though harmless as well).
My 2 cents.
Regards Jan
@loewenstein That is helpful! I'll figure out who I can talk to about this.
Closing this issue as we received the following explanation:
"I don't know how we came to that example to validate the API rate limit. It never make sense, even on previous OpenStack versions, the default rate limit for GET request was higher than 100req/sec, it only makes sense to validate POST request. I remember that we were hit frequently when updating the server metadata, so maybe this is a better validation."
Docs will be updated via PR.
As part of our efforts to automate OpenStack validation (https://github.com/cloudfoundry-incubator/cf-openstack-validator) we introduce a rate limit test.
We just discovered two things:
compute.servers
, i.e. a valid check would beservers = compute.servers; 100.times { servers.reload }
https://github.com/cloudfoundry/docs-deploying-cf/blob/master/openstack/validate_openstack.html.md.erb#L36-L41
What is the background of this specific check?