Open Stack

I apologize that this mail will appear at the incorrect position in
the thread, but I somehow got unsubscribed from openstack-dev due to
bounces and didn't receive the original email.

On 9/11/13 03:15 UTC, Adrian Otto <adrian.otto at rackspace.com> wrote:
> So, I don't intend to argue the technical minutia of each design point, but I challenge you to make sure that we
> (1) arrive at a simple system that any OpenStack user can comprehend,

I think there is tension between simplicity of the stack and
simplicity of the components in that stack. We're making sure that the
components will be simple, self-contained, and easy to understand, and
the stack will need to plug them together in an interesting way.

> (2) responds quickly to alarm stimulus,

Like Zane, I don't really buy the argument that the API calls to Heat
will make any significant impact on the speed of autoscaling. There
are MUCH bigger wins in e.g. improving the ability for people to use
cached, pre-configured images vs a couple of API calls. Even once
you've optimized all of that, booting an instance still takes much,
much longer than running the control code.

> (3) is unlikely to fail,

I know this isn't exactly what you mentioned, but I have some things
to say not about resilience but instead about reaction to failures.

The traceability and debuggability of errors is something that
unfortunately plagues all of OpenStack, both for developers and
end-users. It is fortunate that OpenStack compononts make good use of
each other, but unfortunate that

1. there's no central, filterable logging facility (without investing
significant ops effort to deploy a third-party one yourself);
2. not enough consistent "tagging" of requests throughout the system
that allows operators looking at logs to understand how a user's
original request led to some ultimate error;
3. no ubiquitous mechanisms for propagating errors between service
APIs in a way that ultimately lead back to the consumer of the
service;
4. many services don't even report detailed information with errors
that happen internally.

I believe we'll have to do what we can, especially in #3 and #4, to
make sure that the users of autoscaling and Heat have good visibility
into the system when errors occur.

> (4) can be easily customized with user-supplied logic that controls how the scaling happens, and under what conditions.

I think this is a good argument for using Heat for the scaling
resources instead of doing it separately. One of the biggest new
features that the new AS design provides is the ability to scale *any*
resource, not just AWS::EC2::Instance. This means you can write your
own custom resource with custom logic and scale it trivially. Doing it
in terms of resources instead of launch configurations provides a lot
of flexibility, and a Resource implementation is a nice way to wrap up
that custom logic. If we implemented this in the AS service without
using Heat, we'd either be constrained to nova instances again, or
have to come up with our own API for customization.

As far as customizing the conditions under which scaling happens,
that's provided at the lowest common denominator by providing a
webhook trigger for scaling policies (on top of which will be
implemented convenient Ceilometer integration support).  Users will be
able to provide their own logic and hit the webhook whenever they want
to execute the policy.


> It would be better if we could explain Autoscale like this:

> Heat -> Autoscale -> Nova, etc.
> -or-
> User -> Autoscale -> Nova, etc.

> This approach allows use cases where (for whatever reason) the end user does not want to use Heat at all, but still wants something simple to be auto-scaled for them. Nobody would be scratching their heads wondering why things are going in circles.

The "Heat" behind "Autoscale" isn't something that the *consumer* of
the service knows about, only the administrator. Granted, the API
design that we're running with *does* currently require the user to
provide "snippets" of heat resource templates -- just specifying the
individual resources that should be scaled -- but I think it would be
trivial to support an alternative type of "launch configuration" that
does the translation to heat templates in the background, if we really
want to hide all the Heatiness from a user who just wants the
simplicity of knowing only about Nova and autoscaling.

To conclude, I'd like to just say I basically agree with what Clint,
Keith, and Steven have said in other messages in this thread. I
doesn't appear that the design of Heat autoscaling (informed by Zane,
Clint, Angus and others) fails to meet the criteria you've brought up.

-- 
IRC: radix
Christopher Armstrong
Rackspace