Open Stack

On Sat, Sep 26, 2015 at 8:10 PM, Clint Byrum <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
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>



-- 
Thanks,
Shamail Tahir
t: @ShamailXD
tz: Eastern Time
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150927/e2f53f83/attachment.html>