On 19/06/13 06:01, Adrian Otto wrote:
Angus,
I'm glad you are asking good questions. I have additional input for you to
consider below.
On Jun 18, 2013, at 6:09 PM, Angus Salkeld <asalk...@redhat.com> wrote:
On 18/06/13 23:32 +0000, Adrian Otto wrote:
Yes. I think having a POST method in the API makes perfect sense. Assuming we
reach agreement on that, the next question that comes up is:
Err, I am not convinced.
Before that, I think it's worth highlighting the different
proposals/requirements here:
1) heat needs a way to setup an autoscaling group
2) autoscaling needs a way of telling heat to scale up/down
3) People might want to integrate other orchestration engines with Heat
So one by one:
1) autoscaling has a post api that the Heat autoscaling group resource
posts to, Heat will provide a webhook in the event of a scaling action.
2) when autoscaling determines that there should be a scaling action
it calls the webhook. The reason I suggest a webhook is in-instance
applications might want to scale their applications (like
openshift-gears) - so don't assume a heat endpoint.
Also we can have this as an action not a resource-create.
PUT /$tenant/stacks/$stack/resources/<autoscale-group>
(with an action of scale-up/down)
I think we should discourage (make it impossible) for users from modifing
stacks outside of stack-update.
To me one of the most powerful and apealing things of Heat is the
ability to reproducibly re-create a stack from a template. This
new public API is going to make this difficult.
Adding an API only makes it difficult if you decide to bypass templates and use
the API. You can still be disciplined and keep your templates updated to
achieve the reproducible goal. Yes, and API of this sort is a sharp instrument,
but it can be useful if applied properly.
A giant -2 to that. We should be designing technology in such a way as
to guide users into using it in ways that meet their goals, not painting
a target on their foot, handing them a shotgun and telling them to go
forth and "be disciplined". In my considered opinion this is one of the
core responsibilities we, as engineers, have to society.
The ability to quickly and easily add or modify a resource in a stack/assembly
is very useful, particularly in cases where an orchestration was partially
successful, but gets stuck. Imagine if it's something that takes 4 hours to
conduct from beginning to end, and you got 3.8 hours into it when something
jammed. It would be *really* handy to be able to un-jam it without starting
over from scratch. You'd still need to fix your template if you wanted to tweak
to persist for the next time you use the template.
That use case is a genuine problem, and Clint has already suggested
(and I support) allowing retries to help mitigate it. There may be other
things we can do too.
I'm not sure if it's possible to write an orchestration system that is
robust in the face of users changing stuff in the middle of a
deployment, but I am pretty sure I am not smart enough to write it and I
am completely sure that Heat is a million miles from ever being that system.
It's also useful for situations like rolling updates, for when a complete
redeployment is not practical, affordable, or desirable. Think of this as the
point of intersection between a configuration management system and the
orchestration system. Yes, you can accomplish this with stack-update, but that
could be rather awkward or impractical depending on the size of the
stack/assembly. Imagine something with 2000 nodes in it… perhaps a large scale
triple-o use case. Sometimes groupings are sufficient, and sometimes they are
not.
I don't understand this. Stack updates do not do a complete
redeployment. Either you want to change something on all 2000 nodes, in
which case doing it manually doesn't buy you anything, or you don't, in
which case the number of unchanged nodes is irrelevant.
Also creating a resource is not a trivial issue, the user would have
create the resources in the correct order (with correct inter-resource
references etc..) mostly throwing away the point of orchestation in
the first place. If you are doing this you may as well talk directly
to nova/cinder/networking directly.
Using the low level API's would bypass the workflow features of Heat, which we
plan to contribute to considerably. We don't want to do that. We want to
leverage those workflow features. There is value in pulling strings through
Heat, even if all you are doing is adding a node. There is value to having an
expression of the complete deployment, and all of the related resources that's
consistent with what's happened with the lower level APIs (such as
nova/cinder/networking). That value does not diminish when you have a need to
surgically alter a stack.
Stack update can already surgically alter a stack. The difference
between stack update and this proposal is that stack updates can be
orchestrated in a robust manner, and this proposal pushes all of the
orchestration work onto the user (who has the added handicap of not
being able to see what else is going on).
cheers,
Zane.
How to do you modify resources that have been created with a POST?
You mention HTTP PUT as an answer to that. Unfortunately PUT is only really
useful for doing a full resource replacement, not just tweaking something
that's already there. For that, you really want HTTP PATCH
(http://tools.ietf.org/html/rfc5789). You can make this really elegant for JSON
with JSON Patch (http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-10).
We should note that offering API methods to adjust a stack (aka: assembly)
means that there will be a divergence between what's described in the original
template, and the actual running state of the stack/assembly created by the
template, well beyond the results of an autoscale policy. In fact, it would be
possible to build a stack/assembly with no template at all, if the right API
methods are present. There are good use cases for this, particularly for higher
level compatibility layers where it would be awkward to generate permutations
of templates to immediately feed into an API, rather than just use an API
method for adjusting the stack/assembly in place. it would be much more
elegant, for example, to implement a CAMP implementation on top of Heat if Heat
had a REST API for creating and managing individual resources within a
stack/assembly. This same argument applies to integrating any other
orchestration or configuration management system with Heat.
So this is "3)":
As I was alluding to above, if you are integrating at this level what
value is Heat providing to you? If you are just using it for resource
create this is a thin layer over the python clients. I'd suggest just
using the resources as python plugins. I think exposing this would
bring more harm than good.
The value is in the expression of the stack/assembly for the purposes of system
management, task-flow/workflow, application lifecycle management, and (future)
the ability to manage a multi-cloud deployment with a single point of control.
Yes, sharp instruments can be dangerous. They can also be very handy when you
need one.
Thanks,
Adrian
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
