On 18/11/13 12:57 +0100, Zane Bitter wrote:
On 16/11/13 11:15, Angus Salkeld wrote:
On 15/11/13 08:46 -0600, Christopher Armstrong wrote:
On Fri, Nov 15, 2013 at 3:57 AM, Zane Bitter <[email protected]> wrote:
On 15/11/13 02:48, Christopher Armstrong wrote:
On Thu, Nov 14, 2013 at 5:40 PM, Angus Salkeld <[email protected]
<mailto:[email protected]>> wrote:
On 14/11/13 10:19 -0600, Christopher Armstrong wrote:
http://docs.heatautoscale.__apiary.io/
<http://docs.heatautoscale.apiary.io/>
I've thrown together a rough sketch of the proposed API for
autoscaling.
It's written in API-Blueprint format (which is a simple subset
of Markdown)
and provides schemas for inputs and outputs using JSON-Schema.
The source
document is currently at
https://github.com/radix/heat/__raw/as-api-spike/
autoscaling.__apibp
<https://github.com/radix/heat/raw/as-api-spike/autoscaling.apibp
Things we still need to figure out:
- how to scope projects/domains. put them in the URL? get them
from the
token?
- how webhooks are done (though this shouldn't affect the API
too much;
they're basically just opaque)
Please read and comment :)
Hi Chistopher
In the group create object you have 'resources'.
Can you explain what you expect in there? I thought we talked at
summit about have a unit of scaling as a nested stack.
The thinking here was:
- this makes the new config stuff easier to scale (config get
applied
 per scaling stack)
- you can potentially place notification resources in the scaling
 stack (think marconi message resource - on-create it sends a
 message)
- no need for a launchconfig
- you can place a LoadbalancerMember resource in the scaling stack
 that triggers the loadbalancer to add/remove it from the lb.
I guess what I am saying is I'd expect an api to a nested stack.
Well, what I'm thinking now is that instead of "resources" (a
mapping of
resources), just have "resource", which can be the template definition
for a single resource. This would then allow the user to specify a
Stack
resource if they want to provide multiple resources. How does that
sound?
My thought was this (digging into the implementation here a bit):
- Basically, the autoscaling code works as it does now: creates a
template
containing OS::Nova::Server resources (changed from AWS::EC2::Instance),
with the properties obtained from the LaunchConfig, and creates a
stack in
Heat.
- LaunchConfig can now contain any properties you like (I'm not 100%
sure
about this one*).
- The user optionally supplies a template. If the template is
supplied, it
is passed to Heat and set in the environment as the provider for the
OS::Nova::Server resource.
I don't like the idea of binding to OS::Nova::Server specifically for
autoscaling. I'd rather have the ability to scale *any* resource,
including
nested stacks or custom resources. It seems like jumping through hoops to
big +1 here, autoscaling should not even know what it is scaling, just
some resource. solum might want to scale all sorts of non-server
resources (and other users).
I'm surprised by the negative reaction to what I suggested, which is
a completely standard use of provider templates. Allowing a
user-defined stack of resources to stand in for an unrelated resource
type is the entire point of providers. Everyone says that it's a
great feature, but if you try to use it for something they call it a
"hack". Strange.
I am not against templateResources.
So, allow me to make a slight modification to my proposal:
- The autoscaling service manages a template containing
OS::Heat::ScaledResource resources. This is an imaginary resource
type that is not backed by a plugin in Heat.
Just an interface/property definition really?
- If no template is supplied by the user, the environment declares
another resource plugin as the provider for OS::Heat::ScaledResource
(by default it would be OS::Nova::Server, but this should probably be
configurable by the deployer... so if you had a region full of Docker
containers and no Nova servers, you could set it to
OS::Docker::Container or something).
- If a provider template is supplied by the user, it would be
specified as the provider in the environment file.
This, I hope, demonstrates that autoscaling needs no knowledge
whatsoever about what it is scaling to use this approach.
The only way that it would require some knowledge is if we restricted
the properties that can be passed to the launch config to match some
particular interface, but I believe we already have a consensus that
we don't want to do that.
This assumes that we need a default resource type, though it would be
substantially unchanged if we didn't have a default resource type
(we'd just make supplying the template mandatory). In my reply to you
other post I put forward an argument why I don't think that we should
have no default. If your objection is that the default is of a
different type (Server vs. provider stack) to the general case then
let's consider the different ways we could handle this:
Basically we need a resource interface definition:( - tho' I am
not keen on building a language here.
So I'll assume a TemplateResource below, but could be nested stack (just
didn't want to duplicate the verbage) - honestly not stressed which.
Autoscaling needs to say "What ever resource you pass me I need:
- these X properties that I am going to read from and
- these Y properties that I am going to write to
- all other properties must be provided already and I'll ignore them".
So we just need to define what are the properties that
autoscaling needs and find a way of making sure that the resource
that is passed in has these defined (make validation sane).
If we make the definition OS::Nova::Server then the user has to
implement a big api that probably makes no sense to their resource.
We also need to document that this resource is the "scaling unit"
and don't assume that all referenced resources will be magically
scaled too. If you want that then you need to write a Template and
make a TemplateResource with the correct Properties and that whole
resource will be scaled. I was harping on about nested stacks as
I thought this would probably be more obvious, but I agree that TemplateResource
looks neater. I am more interested in:
1. defining the scope of what is a "scaling unit" and making sure the user is
aware
of this. (doesn't ref one of these new config appliers and think it
will be magically applied somehow).
2. validating that the resource/stack passed in has it's required
inputs.
-Angus
1) As proposed above, just use OS::Nova::Server (or whatever type is
configured in heat.conf) as the provider.
- The autoscaling code won't need to know anything about it,
everything is handled internally in Heat.
- The default (most common) case avoids the overhead of a stack for
every scaled resource.
2) Grab the default template from http://heat.example.com/<tenant_id>/resource_types/OS::Nova::Server/template
(or whatever type is configured in heat.conf) as the provider.
- The composition of all scaling groups is consistent.
- Requires an extra ReST call.
3) Embed the default template in the autoscaling configuration.
- The composition of all scaling groups is consistent.
- No extra ReST API call
- The template could get out of date; there's no guarantee that it
matches the plugin in Heat that we're talking to.
Those are in order of my personal preference. I wouldn't support (3),
but I am fine with (2) if you think that consistency is worth the
extra overhead. At the end of the day this is an implementation
detail that is not visible to the user at all.
support custom resources by overriding OS::Nova::Server instead of just
allowing users to specify the resource that they really want directly.
How about we offer two "types" of configuration, one which supports
arbitrary resources and one which supports OS::Nova::Server-specific
launch
configurations? We could just add a type="server" / type="resource"
parameter which specifies which type of scaling unit to use.
How about just one "nested-stack".
Keep it simple.
+1
Why would we have two configurations:
type: server
resource_type: this is ignored
and:
type: resource
resource_type: OS::Nova::Server
that do exactly the same thing? This increases complexity and adds
zero value to the user.
This should require no substantive changes to the code since it uses
existing abstractions, it makes the common case the default, and it
avoids
the overhead of nested stacks in the default case.
-1
As I said in reply to your other message, I think we're really only
disagreeing about implementation. "Everything is a nested stack" and
Yeah, just the little details really.
"Everything is a provider stack" are not really different ideas, just
subtly different implementations. In both cases you pass a template
to the API as the thing to scale. IMO the provider implementation is
far better for the user though, because it enables them to use the
tools we have already built to support that - e.g. they can grab the
pass-through provider template for a resource from http://heat.example.com/<tenant_id>/resource_types/<resource_type>/template
and modify it. Any other tools we build around providers will make
autoscaling easier for free too.
Doing things like passing complex JSON properties to a template
through the parameters are tricky, and we may need to change it over
time. It's much better to encapsulate as much as possible of this
inside Heat - and we have an existing mechanism to do so.
cheers,
Zane.
_______________________________________________
OpenStack-dev mailing list
[email protected]
X>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
