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.o...@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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
