Open Stack

Excellent writeup, thanks. Some comments inline.


On Tue, Sep 20, 2016, at 09:20 AM, Sean Dague wrote:
> <snip>
> 
> Performance Bottlenecks
> -----------------------
> 
> * scheduling issues with Ironic - (this is a bug we got through during
>   the week after the session)
> * live snapshots actually end up performance issue for people
> 
> The workarounds config group was not well known, and everyone in the
> room wished we advertised that a bit more. The solution for snapshot
> performance is in there.
> 
> There were also general questions about what scale cells should be
> considered at.
> 
> ACTION: we should make sure workarounds are advertised better
> ACTION: we should have some document about "when cells"?

This is a difficult question to answer because "it depends." It's akin
to asking "how many nova-api/nova-conductor processes should I run?"
Well, what hardware is being used, how much traffic do you get, is it
bursty or sustained, are instances created and left alone or are they
torn down regularly, do you prune your database, what version of rabbit
are you using, etc...

I would expect the best answer(s) to this question are going to come
from the operators themselves. What I've seen with cellsv1 is that
someone will decide for themselves that they should put no more than X
computes in a cell and that information filters out to other operators.
That provides a starting point for a new deployment to tune from.

>  <snip>
> 
> Policy
> ------
> 
> How are you customizing policy? People were largely making policy
> changes to protect their users that didn't really understand cloud
> semantics. Turning off features that they thought would confuse them
> (like pause). The large number of VM states is confusing, and not
> clearly useful for end users, and they would like simplification.
> 
> Ideally policy could be set on a project by project admin, because
> they would like to delegate that responsibility down.
> 
> No one was using the user_id based custom policy (yay!).
> 
> There was desire that flavors could be RBAC locked down, which was
> actually being done via policy hacks right now. Providers want to
> expose some flavors (especially those with aggregate affinity) to only
> some projects.
> 
> People were excited about the policy in code effort, only concern was
> that the defacto documentation of what you could change wouldn't be in
> the sample config.
> 
> ACTION: ensure there is policy config reference now that the sample
> file is empty

We have the "genpolicy" tox target which mimics the "genconfig" target.
It's similar to the old sample except guaranteed to be up to date, and
can include comments. Is that sufficient?


> ACTION: flavor RBAC is a thing most of the room wanted, is there a
> taker on spec / implementation?

This isn't the most clear spec ever but we have an approved backlog spec
for flavor-classes which was looking to get into this area
http://git.openstack.org/cgit/openstack/nova-specs/tree/specs/backlog/approved/flavor-class.rst
. That would add a grouping mechanism for flavors which could then be
used for policy checks. I think having that in place would minimize the
policy explosion that might happen if policy could be attached to
individual flavors.