[Openstack-operators] [Large Deployments Team][Tags] Ops Tag for "Scale"
Kris G. Lindgren
klindgren at godaddy.com
Sun Sep 27 18:15:58 UTC 2015
We (LDT) actually don't have a formal definition of what defines a "large" deployment. We have historical said that the definition of large is up to the operator to decide. We have members people who operate the worlds largest public cloud, we have members who operate many many many private clouds of varying size, we have members who currently only operate a small openstack cloud but are trying to grow that in what would be considered by most a "large deployment". We have others that have a "large deployment" but compared to their other infrastructure consider their deployment fairly small.
I think it would be best to consult the User survey to figure out what constitutes a small/medium/large/huge deployment. We (ops/LDT) can then provide feedback as to if something performs at that scale. I think part of the feedback needs to be on how a project is used as well. For Example, we (Godaddy) use neutron for networking, however we do not use tunneling of any type and we do not create virtual routers or private networks and we do not rely on dhcp (we use config-drive to set instance ip configuration). So areas that other deployments have ran into in the past on scaling neutron (router scheduling performance, router HA, dhcp server performance) we simply avoided (by luck) due to the way that we implemented neutron in our environment.
Senior Linux Systems Engineer
From: Shamail Tahir
Date: Sunday, September 27, 2015 at 11:49 AM
To: Clint Byrum
Subject: Re: [Openstack-operators] [Large Deployments Team][Tags] Ops Tag for "Scale"
On Sat, Sep 26, 2015 at 8:10 PM, Clint Byrum <clint at fewbar.com<mailto:clint at fewbar.com>> wrote:
Excerpts from Shamail's message of 2015-09-26 11:40:17 -0700:
> Hi Large Deployments Team,
> The ops-tags team was brainstorming potential future tags at our last meeting and one topic of interest was to express the "scale" a service can operate at via tags.
> Scale, of course, can imply several different dimensions (not to mention test types). We figured who better to talk to about the definition of scale than the large deployment team. :-)
> Can you please help us understand how your team classifies a deployment as being large? I recall that, in the initial discussions, LDT was using the number of nodes. Is this still the case? Does large deployment factor in things such as throughout requirements, number of networks, number of volumes, etc. when deciding if a deployment is "large"?
> Thanks in advance for your help. If it makes more sense to discuss this topic at the next LDT meeting then I would be glad to join.
I wasn't involved with the discussion, but I think it is an important one.
IMO, the objective way to do this is to add tests for scaling factors,
like ensuring reasonable resource cost per operation, response time during
simulated high concurrency, and actual large scale 3rd-party CI. If a
project hasn't done that, they shouldn't be considered "high scale".
I think these are all good suggestions, as a starting point though, our thought process was that maybe we could use the same criteria as LDT. Let's say (as an example) that a deployment that is considered a "large deployment" is using a project then we could then say the project has been known to achieve "scale". With this method, we are inferring scale based on real world deployments rather than establishing it via testing. I think both views (testing criteria for scale along with real-world data) probably have a part to play in the longer term scope of the tag. Will definitely factor in your suggestions in the tag description though even if its a future objective.
(note that I don't think any of the projects actually has these things
surfaced upstream, but we are definitely going to need these things)
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
tz: Eastern Time
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-operators