Open Stack

On Fri, Jul 12, 2013 at 11:54 PM, Tom Fifield <tom at openstack.org> wrote:

> Hi all,
>
> I've been having a nice little monologue over at:
>
> https://bugs.launchpad.net/**openstack-manuals/+bug/1090654<https://bugs.launchpad.net/openstack-manuals/+bug/1090654>
>
> which is a bug to document the introduction (into grizzly) of a feature
> called "Instance Resource Quotas", that allow you to set limits on how much
> cpu/disk/network particular instance types consume.
>
> As you can read, I had some initial confusion on where this would go. So
> here are my conclusions, provided so we can use it as an excercise in
> scoping with the current restructure efforts:
>
> The feature would _not_ be listed in:
> * Install guide: the install guide is for a basic description of
> installation, and this is not a necessary part
>
> * Config reference: the configuration reference is for parts of the system
> that need root access to systems be configured - really, things that need
> to be tweaked in {nova,neutron,...}.conf. This feature is always enabled,
> and set in user-space, using nova commands.
>
>
> The feature _may_ be listed in:
> * The Operations Guide: it may be a best practice to set instance resource
> limits when configuing flavors
>
> * The Secuity Guide: there are security implications of not setting these
> limits - where in certain situations guests could eg consume all the
> bandwidth, leading to a DoS attack
>
>
> This feature would predominantely live in:
>
> * The Admin User manual: since configuring flavours lives there, and this
> is a part of configuring flavours. A link to hypervisors section in config
> ref might be included, with a note on support of the feature across various
> hypervisors.
>
> * The `Comprehensive` Admin Manual: if/when this exists, it would contain
> an extensive discussion of the "extra_specs" metadata field, which is used
> to implement the Instance Resource Quotas
>
>
> Well that's my take - what's yours? If we can converge on this simple bug,
> we have achieved a minor success in scoping :)
>
>
>
+1, I am in complete agreement.


Lorin

-- 
Lorin Hochstein
Lead Architect - Cloud Services
Nimbis Services, Inc.
www.nimbisservices.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20130714/354de401/attachment.html>