[Openstack-operators] [Large Deployments Team][Tags] Ops Tag for "Scale"

Tim Bell Tim.Bell at cern.ch
Sun Sep 27 18:38:46 UTC 2015

In the past, we considered large deployments as those who were looking at O(1) scalability rather than O(n)… i.e. adding further resources is just business as usual rather than needing a corresponding increase in resources.


It was more of a mentality (i.e. CI, config mgmt, automation, acceptance of infrastructure failure) rather than >N nodes or M GBs.


Tagging a project is not easy on this basis, however. 


Certainly, our experience is variable across projects. Ceilometer, for example, has not been easy to scale. 




From: Kris G. Lindgren [mailto:klindgren at godaddy.com] 
Sent: 27 September 2015 20:16
To: Shamail Tahir <itzshamail at gmail.com>; Clint Byrum <clint at fewbar.com>
Cc: openstack-operators <openstack-operators at lists.openstack.org>
Subject: Re: [Openstack-operators] [Large Deployments Team][Tags] Ops Tag for "Scale"


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.



Kris Lindgren

Senior Linux Systems Engineer



From: Shamail Tahir
Date: Sunday, September 27, 2015 at 11:49 AM
To: Clint Byrum
Cc: openstack-operators
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> 




Shamail Tahir

t: @ShamailXD

tz: Eastern Time

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150927/a086c8eb/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7349 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150927/a086c8eb/attachment.bin>

More information about the OpenStack-operators mailing list