<div dir="ltr">Thanks for the additional data-points on the granularity that we might need to address scale (component rather than project level) along with additional clarification on drivers (scale equivalent to resource being available versus needing additional resources).  As mentioned earlier, deployment options (types of infrastructure, services, and their configuration) also play a vital part in the 'scale' of a service.  This is a great starting point to the conversation.  </div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 28, 2015 at 10:03 AM, Jonathan D. Proulx <span dir="ltr"><<a href="mailto:jon@csail.mit.edu" target="_blank">jon@csail.mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sun, Sep 27, 2015 at 06:15:58PM +0000, Kris G. Lindgren wrote:<br>
<br>
>For Example, we (Godaddy) use neutron for networking, however<br>
>we do not use tunneling of any type and we do not create virtual<br>
>routers or private networks and we do not rely on dhcp (we use<br>
>config-drive to set instance ip configuration).<br>
<br>
</span>This is an important thing to consider.  Even at my <100 node scale I<br>
don't use neutron L3 so even if a site reports using a project it's<br>
hard to say what parts tehy are using or how they modefied it to mak<br>
eit 'scale' as this could include leaving large pieces that don't<br>
scale on the floor...<br>
<br>
-Jon<br>
<br>
<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div style="font-size:small">Thanks,</div><div style="font-size:small">Shamail Tahir</div><div style="font-size:small">t: @ShamailXD</div><div style="font-size:small">tz: Eastern Time</div></div></div></div></div>
</div>