Let's talk about scaling (ARIA-254)

[Tal Liron <ta...@gigaspaces.com>]

The TOSCA spec says nothing about how multiple nodes per template would be
created, leaving it the orchestrator to decide. The provided scaling policy
in the Simple Profile is empty, just providing a base type for users to
extend.

What I'm proposing is to support basic policy-based scaling to ARIA. I have
a pull request that works and you can try out:

https://github.com/apache/incubator-ariatosca/pull/143

The way it works is that you can define a default_instances number for any
number of nodes (or nodes in the group) by applying the scaling policy to
it. min_instances and max_instances are also there, though ARIA doesn't
know what to do with them at the moment. They would be available for
plugins to implement their own scaling system, to make sure their workflows
are scaling with the user-defined bounds.

In terms of code, it meant removing the default_instances, min_instances,
and max_instances fields from the NodeTemplate model. Instead, there is a
default_instance property that will grab the value from applicable policies.

Works great! But I would be happy to hear feedback about this bold
approach. I think one negative is that if you want to give default scaling
parameters for different nodes you would have to define separate policies.
But I don't think this is so bad, and is actually the correct usage of
policies (and groups) in TOSCA.

Re: Let's talk about scaling (ARIA-254)

[Ran Ziv <ra...@gigaspaces.com>]

I think since this is possibly not the most obvious override (policy and
capability), emitting a validation error might make the most sense - seems
to be the safer choice here, and I don't think such an edge case will be
bothering anyone for raising an error rather than working out of the box.



On Tue, Jun 13, 2017 at 7:11 PM, Tal Liron <ta...@gigaspaces.com> wrote:

> Right, TOSCA also defines tosca.policies.Scaling as a base type for
> potential scaling policies, though leaves it entirely empty. So, I think we
> are doing it the right "TOSCA way" by supporting both.
>
> About which should override which -- I'm really not entirely sure. The way
> the code works right now: it tries to apply capability values, and then
> policy values. So policy values would override those.
>
> Another option would be to emit a validation error if there is
> conflict/ambiguity between the values. What do you think?
>
> On Tue, Jun 13, 2017 at 4:25 AM, Ran Ziv <ra...@gigaspaces.com> wrote:
>
> > I think that's a very good solution. The semantics of capability being
> > first in precedence makes sense - basically if you'd like to scale a
> > compute node, do it the "TOSCA way" - Otherwise, use the policy.
> >
> > I also agree that despite the quirkiness, the policy should have
> identical
> > properties/defaults as the capability does (despite the extra step
> required
> > in order to set >1 instances).
> > This should also mean that a user could also scale the number of
> instances
> > by setting "min_instances=X" and "max_instances>=X", yet without setting
> > "default_instances". The number of instances in this scenario should be
> X.
> >
> >
> > Have you seen the 5.4.10.3 note by the way? It talks about the number of
> > instances possibly being governed by a separate policy - Even though this
> > is still not properly defined in TOSCA, perhaps this means that the
> > policy's values should override the capability's if both exist? I'd
> rather
> > it didn't, as it could make things confusing, and because it's still an
> > ARIA-specific definition. Just thought I'd bring it up though.
> >
> >
> >
> >
> > On Tue, Jun 13, 2017 at 1:54 AM, Tal Liron <ta...@gigaspaces.com> wrote:
> >
> > > Let's talk about scaling some more. :)
> > >
> > > Earlier, I complete missed the definition of
> tosca.capabilities.Scalable:
> > >
> > > http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-
> > > YAML/v1.0/cos01/TOSCA-Simple-Profile-YAML-v1.0-cos01.html#
> > > DEFN_TYPE_CAPABILITIES_SCALABLE
> > >
> > > The reason I missed it is that it's actually *not* declared in
> > > tosca.nodes.Root, but specifically declared only for
> tosca.nodes.Compute
> > > and tosca.nodes.Container.Runtime. This seems a bit odd to me. From our
> > > experience, we know that it's not only VM nodes that need to be scaled,
> > but
> > > in fact *any* node in the topology is a template that can have more
> than
> > > one instances (or possibly even zero in some situations). I'm honestly
> > > confused as to why TOSCA did it this way.
> > >
> > > So, I currently propose this: support *both* the capability and a
> policy.
> > > The mechanism works by first looking through the node templates
> > > capabilities to find whether it has a "scalable"-role capability. If it
> > > doesn't, it will see if there is a "scalable"-role policy that applies
> to
> > > it.
> > >
> > > I'll note that the "scalable"-role policy is part of the ARIA Profile,
> > but
> > > even without that profile we will still support the more basic
> > scalability
> > > defined in the Simple Profile. Supporting both is actually very easy in
> > > terms of the code, just a few lines for each once the mechanism is in
> > > place: the properties names and usages are the same in each.
> > >
> > > One quirk is how tosca.capabilities.Scalable defines its properties.
> > We're
> > > used to thinking that max_instances defaults to infinity, and
> > > default_instances defaults to 1. The way the Simple Profile defines it,
> > > max_instances defaults to 1, and default_instances is an optional
> field.
> > > Meaning that in a sense it is up to the orchestrator to define the
> > default
> > > number of instances for a node template. I recommend we switch to the
> way
> > > the Simple Profile works, for our policy as well.
> > >
> > > What this means is that if, for example, you want a node to have 5
> > > instances, then you need to set default_instances to 5, but *also* set
> > > max_instances to >=5, otherwise you will get a validation error. I
> > > personally think this is annoying, and prefer our way of thinking, but
> I
> > > think we should adhere to TOSCA here.
> > >
> >
>
>
>
> --
> Tal Liron, Senior Solutions Architect <http://cloudify.co>
> ------------------------------
> M: +1-312-375-8299 http://cloudify.co @cloudifysource
> <https://twitter.com/CloudifySource>
> <https://www.linkedin.com/company-beta/17918192/>
> <https://github.com/cloudify-cosmo>
> <https://www.youtube.com/cloudifysource>
>

Re: Let's talk about scaling (ARIA-254)

[Tal Liron <ta...@gigaspaces.com>]

Right, TOSCA also defines tosca.policies.Scaling as a base type for
potential scaling policies, though leaves it entirely empty. So, I think we
are doing it the right "TOSCA way" by supporting both.

About which should override which -- I'm really not entirely sure. The way
the code works right now: it tries to apply capability values, and then
policy values. So policy values would override those.

Another option would be to emit a validation error if there is
conflict/ambiguity between the values. What do you think?

On Tue, Jun 13, 2017 at 4:25 AM, Ran Ziv <ra...@gigaspaces.com> wrote:

> I think that's a very good solution. The semantics of capability being
> first in precedence makes sense - basically if you'd like to scale a
> compute node, do it the "TOSCA way" - Otherwise, use the policy.
>
> I also agree that despite the quirkiness, the policy should have identical
> properties/defaults as the capability does (despite the extra step required
> in order to set >1 instances).
> This should also mean that a user could also scale the number of instances
> by setting "min_instances=X" and "max_instances>=X", yet without setting
> "default_instances". The number of instances in this scenario should be X.
>
>
> Have you seen the 5.4.10.3 note by the way? It talks about the number of
> instances possibly being governed by a separate policy - Even though this
> is still not properly defined in TOSCA, perhaps this means that the
> policy's values should override the capability's if both exist? I'd rather
> it didn't, as it could make things confusing, and because it's still an
> ARIA-specific definition. Just thought I'd bring it up though.
>
>
>
>
> On Tue, Jun 13, 2017 at 1:54 AM, Tal Liron <ta...@gigaspaces.com> wrote:
>
> > Let's talk about scaling some more. :)
> >
> > Earlier, I complete missed the definition of tosca.capabilities.Scalable:
> >
> > http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-
> > YAML/v1.0/cos01/TOSCA-Simple-Profile-YAML-v1.0-cos01.html#
> > DEFN_TYPE_CAPABILITIES_SCALABLE
> >
> > The reason I missed it is that it's actually *not* declared in
> > tosca.nodes.Root, but specifically declared only for tosca.nodes.Compute
> > and tosca.nodes.Container.Runtime. This seems a bit odd to me. From our
> > experience, we know that it's not only VM nodes that need to be scaled,
> but
> > in fact *any* node in the topology is a template that can have more than
> > one instances (or possibly even zero in some situations). I'm honestly
> > confused as to why TOSCA did it this way.
> >
> > So, I currently propose this: support *both* the capability and a policy.
> > The mechanism works by first looking through the node templates
> > capabilities to find whether it has a "scalable"-role capability. If it
> > doesn't, it will see if there is a "scalable"-role policy that applies to
> > it.
> >
> > I'll note that the "scalable"-role policy is part of the ARIA Profile,
> but
> > even without that profile we will still support the more basic
> scalability
> > defined in the Simple Profile. Supporting both is actually very easy in
> > terms of the code, just a few lines for each once the mechanism is in
> > place: the properties names and usages are the same in each.
> >
> > One quirk is how tosca.capabilities.Scalable defines its properties.
> We're
> > used to thinking that max_instances defaults to infinity, and
> > default_instances defaults to 1. The way the Simple Profile defines it,
> > max_instances defaults to 1, and default_instances is an optional field.
> > Meaning that in a sense it is up to the orchestrator to define the
> default
> > number of instances for a node template. I recommend we switch to the way
> > the Simple Profile works, for our policy as well.
> >
> > What this means is that if, for example, you want a node to have 5
> > instances, then you need to set default_instances to 5, but *also* set
> > max_instances to >=5, otherwise you will get a validation error. I
> > personally think this is annoying, and prefer our way of thinking, but I
> > think we should adhere to TOSCA here.
> >
>



-- 
Tal Liron, Senior Solutions Architect <http://cloudify.co>
------------------------------
M: +1-312-375-8299 http://cloudify.co @cloudifysource
<https://twitter.com/CloudifySource>
<https://www.linkedin.com/company-beta/17918192/>
<https://github.com/cloudify-cosmo>
<https://www.youtube.com/cloudifysource>

Re: Let's talk about scaling (ARIA-254)

[Ran Ziv <ra...@gigaspaces.com>]

I think that's a very good solution. The semantics of capability being
first in precedence makes sense - basically if you'd like to scale a
compute node, do it the "TOSCA way" - Otherwise, use the policy.

I also agree that despite the quirkiness, the policy should have identical
properties/defaults as the capability does (despite the extra step required
in order to set >1 instances).
This should also mean that a user could also scale the number of instances
by setting "min_instances=X" and "max_instances>=X", yet without setting
"default_instances". The number of instances in this scenario should be X.


Have you seen the 5.4.10.3 note by the way? It talks about the number of
instances possibly being governed by a separate policy - Even though this
is still not properly defined in TOSCA, perhaps this means that the
policy's values should override the capability's if both exist? I'd rather
it didn't, as it could make things confusing, and because it's still an
ARIA-specific definition. Just thought I'd bring it up though.




On Tue, Jun 13, 2017 at 1:54 AM, Tal Liron <ta...@gigaspaces.com> wrote:

> Let's talk about scaling some more. :)
>
> Earlier, I complete missed the definition of tosca.capabilities.Scalable:
>
> http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-
> YAML/v1.0/cos01/TOSCA-Simple-Profile-YAML-v1.0-cos01.html#
> DEFN_TYPE_CAPABILITIES_SCALABLE
>
> The reason I missed it is that it's actually *not* declared in
> tosca.nodes.Root, but specifically declared only for tosca.nodes.Compute
> and tosca.nodes.Container.Runtime. This seems a bit odd to me. From our
> experience, we know that it's not only VM nodes that need to be scaled, but
> in fact *any* node in the topology is a template that can have more than
> one instances (or possibly even zero in some situations). I'm honestly
> confused as to why TOSCA did it this way.
>
> So, I currently propose this: support *both* the capability and a policy.
> The mechanism works by first looking through the node templates
> capabilities to find whether it has a "scalable"-role capability. If it
> doesn't, it will see if there is a "scalable"-role policy that applies to
> it.
>
> I'll note that the "scalable"-role policy is part of the ARIA Profile, but
> even without that profile we will still support the more basic scalability
> defined in the Simple Profile. Supporting both is actually very easy in
> terms of the code, just a few lines for each once the mechanism is in
> place: the properties names and usages are the same in each.
>
> One quirk is how tosca.capabilities.Scalable defines its properties. We're
> used to thinking that max_instances defaults to infinity, and
> default_instances defaults to 1. The way the Simple Profile defines it,
> max_instances defaults to 1, and default_instances is an optional field.
> Meaning that in a sense it is up to the orchestrator to define the default
> number of instances for a node template. I recommend we switch to the way
> the Simple Profile works, for our policy as well.
>
> What this means is that if, for example, you want a node to have 5
> instances, then you need to set default_instances to 5, but *also* set
> max_instances to >=5, otherwise you will get a validation error. I
> personally think this is annoying, and prefer our way of thinking, but I
> think we should adhere to TOSCA here.
>

Re: Let's talk about scaling (ARIA-254)

[Tal Liron <ta...@gigaspaces.com>]

Let's talk about scaling some more. :)

Earlier, I complete missed the definition of tosca.capabilities.Scalable:

http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.0/cos01/TOSCA-Simple-Profile-YAML-v1.0-cos01.html#DEFN_TYPE_CAPABILITIES_SCALABLE

The reason I missed it is that it's actually *not* declared in
tosca.nodes.Root, but specifically declared only for tosca.nodes.Compute
and tosca.nodes.Container.Runtime. This seems a bit odd to me. From our
experience, we know that it's not only VM nodes that need to be scaled, but
in fact *any* node in the topology is a template that can have more than
one instances (or possibly even zero in some situations). I'm honestly
confused as to why TOSCA did it this way.

So, I currently propose this: support *both* the capability and a policy.
The mechanism works by first looking through the node templates
capabilities to find whether it has a "scalable"-role capability. If it
doesn't, it will see if there is a "scalable"-role policy that applies to
it.

I'll note that the "scalable"-role policy is part of the ARIA Profile, but
even without that profile we will still support the more basic scalability
defined in the Simple Profile. Supporting both is actually very easy in
terms of the code, just a few lines for each once the mechanism is in
place: the properties names and usages are the same in each.

One quirk is how tosca.capabilities.Scalable defines its properties. We're
used to thinking that max_instances defaults to infinity, and
default_instances defaults to 1. The way the Simple Profile defines it,
max_instances defaults to 1, and default_instances is an optional field.
Meaning that in a sense it is up to the orchestrator to define the default
number of instances for a node template. I recommend we switch to the way
the Simple Profile works, for our policy as well.

What this means is that if, for example, you want a node to have 5
instances, then you need to set default_instances to 5, but *also* set
max_instances to >=5, otherwise you will get a validation error. I
personally think this is annoying, and prefer our way of thinking, but I
think we should adhere to TOSCA here.

Re: Let's talk about scaling (ARIA-254)

[Ran Ziv <ra...@gigaspaces.com>]

Oh, I might have misunderstood then. But looks like we reached at the same
conclusion at the end, so I guess we're good :)

On Wed, Jun 7, 2017 at 6:51 PM, Tal Liron <ta...@gigaspaces.com> wrote:

> > About storing in policy information in nodes/templates that the policy is
> > associated with in general - sounds interesting, I'm not sure I'd
> implement
> > this right away, I think it'd be better to hold off and see what sort of
> > policies might exist in the future and what data might be useful to keep
> on
> > the node/template first.
> >
>
> Oh sorry, I was trying to make the opposite point. :) I don't think there
> is a good reason to store special policy information in nodes, when it can
> easily be looked up. And so in this case I am considering the aria.Scaling
> Policy to be just another policy, which is why I am saying we shouldn't
> store "default_instances" in the node...
>

Re: Let's talk about scaling (ARIA-254)

[Tal Liron <ta...@gigaspaces.com>]

> About storing in policy information in nodes/templates that the policy is
> associated with in general - sounds interesting, I'm not sure I'd implement
> this right away, I think it'd be better to hold off and see what sort of
> policies might exist in the future and what data might be useful to keep on
> the node/template first.
>

Oh sorry, I was trying to make the opposite point. :) I don't think there
is a good reason to store special policy information in nodes, when it can
easily be looked up. And so in this case I am considering the aria.Scaling
Policy to be just another policy, which is why I am saying we shouldn't
store "default_instances" in the node...

Re: Let's talk about scaling (ARIA-254)

[Ran Ziv <ra...@gigaspaces.com>]

1. Got it.

2. Ok, makes sense. I might have been wrong thinking this policy should be
special then.
About storing in policy information in nodes/templates that the policy is
associated with in general - sounds interesting, I'm not sure I'd implement
this right away, I think it'd be better to hold off and see what sort of
policies might exist in the future and what data might be useful to keep on
the node/template first.

3. Yes, I understand it better now, thank you. It does seem somewhat
magic-ish and something that can lead to unintended effects.. I personally
think it'd be better to err on the safe side i.e. not allow such a topology
where 6 relationships are required and 5 is the allowed maximum - despite
the fact the template author probably did consider multiple router nodes.
But maybe I'm misinterpreting this :)
Either way, you're right, this is definitely not related to ARIA-254
directly.



On Mon, Jun 5, 2017 at 6:56 PM, Tal Liron <ta...@gigaspaces.com> wrote:

> >
> >
> > The scaling policies are definitely needed e.g. for group, but it'd have
> > been nice to have some simplified manner for defining multiple instances
> of
> > a given node without having to go through actual scaling policies
> > definitions (e.g. a special property on the node to define this etc).
> >
>
> I simply cannot think of a way to do this in TOSCA. For our operation
> configuration we made use of dependencies in a creative way. But for nodes
> there just isn't much there to use. I considered using artifact definitions
> ... but this is really going too far in my view in terms of weirdness. And
> policies is the right way to do it in TOSCA.
>
>
> > 2) I'm not sure about removing the relevant fields from NodeTemplate. The
> > scaling policy is after all a special one, and having it fill these
> fields'
> > values seems somewhat logical IMO.
> >
>
> Actually, the scaling policy is not especially special :) -- it's parsed
> and stored like any other policy (unlike custom workflow policies, which
> become OperationTemplate models). And there can be many other TOSCA
> policies: placement, allotment, allocations, etc., that may or may not be
> supported by ARIA specifically, and may or may not be used by other TOSCA
> tools up or down the line.
>
> For example, someone might create an ARIA extension to support resource
> allocation policies with its own list of special properties. Why does
> scaling get a privileged column in NodeTemplate but not them? I say we
> treat all policies fairly and equally and not sully the NodeTemplate model
> with policy specifics. The policies are exactly designed to be in a
> separate section in the TOSCA template so you can look them and see all
> that apply to your nodes.
>
> There's actually something else interesting we can do here: create a
> special "policies" property for NodeTemplate that combines those directly
> associated with it with those that are associated indirectly via
> GroupTemplate (this extra combination was the only reason I didn't use SQL
> relationships directly to find them). This could be implemented via a SQL
> query. What do you think?
>
> 3) You've mentioned once before that TOSCA also defines an implicit
> > mechanism for creating multiple instances via the
> requirements&capabilities
> > mechanism; What are your ideas regarding that, and how do they fit in
> > together with this?
> >
>
> So, here's how I understand it: in capabilities definition (section
> 3.6.1.1) you have an "occurrences" field, which by default is unbounded but
> can definitely be set to an explicit max. For example, a router might
> define an "upstream" capability limited to 5. During the reqs-and-caps
> matching process, let's say that 5 relationships have been forged with the
> node, and now you have an extra node that also requires "upstream" from us.
> To me, this seems to imply than an extra router node should be created.
>
> But ... I might very well be wrong here. This kind of auto-scaling might
> have unforeseen consequences if the template author was not aware that this
> could happen.
>
> I think it's best that we should not apply any magical autoscaling at the
> design phase, HOWEVER, we can take into consider the policy if it was set.
> If default_instances is 1, and max_instances is 5, then it means the
> template author has considered multiple router nodes.
>
> I hope this makes sense, it's a somewhat shadowy corner of the TOSCA
> spec... Note I would consider implementing this as a separate JIRA if we
> agree that this is correct.
>

Re: Let's talk about scaling (ARIA-254)

[Tal Liron <ta...@gigaspaces.com>]

>
>
> The scaling policies are definitely needed e.g. for group, but it'd have
> been nice to have some simplified manner for defining multiple instances of
> a given node without having to go through actual scaling policies
> definitions (e.g. a special property on the node to define this etc).
>

I simply cannot think of a way to do this in TOSCA. For our operation
configuration we made use of dependencies in a creative way. But for nodes
there just isn't much there to use. I considered using artifact definitions
... but this is really going too far in my view in terms of weirdness. And
policies is the right way to do it in TOSCA.


> 2) I'm not sure about removing the relevant fields from NodeTemplate. The
> scaling policy is after all a special one, and having it fill these fields'
> values seems somewhat logical IMO.
>

Actually, the scaling policy is not especially special :) -- it's parsed
and stored like any other policy (unlike custom workflow policies, which
become OperationTemplate models). And there can be many other TOSCA
policies: placement, allotment, allocations, etc., that may or may not be
supported by ARIA specifically, and may or may not be used by other TOSCA
tools up or down the line.

For example, someone might create an ARIA extension to support resource
allocation policies with its own list of special properties. Why does
scaling get a privileged column in NodeTemplate but not them? I say we
treat all policies fairly and equally and not sully the NodeTemplate model
with policy specifics. The policies are exactly designed to be in a
separate section in the TOSCA template so you can look them and see all
that apply to your nodes.

There's actually something else interesting we can do here: create a
special "policies" property for NodeTemplate that combines those directly
associated with it with those that are associated indirectly via
GroupTemplate (this extra combination was the only reason I didn't use SQL
relationships directly to find them). This could be implemented via a SQL
query. What do you think?

3) You've mentioned once before that TOSCA also defines an implicit
> mechanism for creating multiple instances via the requirements&capabilities
> mechanism; What are your ideas regarding that, and how do they fit in
> together with this?
>

So, here's how I understand it: in capabilities definition (section
3.6.1.1) you have an "occurrences" field, which by default is unbounded but
can definitely be set to an explicit max. For example, a router might
define an "upstream" capability limited to 5. During the reqs-and-caps
matching process, let's say that 5 relationships have been forged with the
node, and now you have an extra node that also requires "upstream" from us.
To me, this seems to imply than an extra router node should be created.

But ... I might very well be wrong here. This kind of auto-scaling might
have unforeseen consequences if the template author was not aware that this
could happen.

I think it's best that we should not apply any magical autoscaling at the
design phase, HOWEVER, we can take into consider the policy if it was set.
If default_instances is 1, and max_instances is 5, then it means the
template author has considered multiple router nodes.

I hope this makes sense, it's a somewhat shadowy corner of the TOSCA
spec... Note I would consider implementing this as a separate JIRA if we
agree that this is correct.

Re: Let's talk about scaling (ARIA-254)

[Ran Ziv <ra...@gigaspaces.com>]

Controlling node scaling via policy makes sense, but I do have a few
concerns:

1) As you've mentioned, this would impose some overhead, for example when
users would want to create multiple instances of a simple node-template.
The scaling policies are definitely needed e.g. for group, but it'd have
been nice to have some simplified manner for defining multiple instances of
a given node without having to go through actual scaling policies
definitions (e.g. a special property on the node to define this etc).

2) I'm not sure about removing the relevant fields from NodeTemplate. The
scaling policy is after all a special one, and having it fill these fields'
values seems somewhat logical IMO.
It's not that having them only on the scaling policy seems terribly wrong -
One could argue that the node-template shouldn't have any declarations of
the min/max instances of it that should be created (but rather that these
values should indeed be set in a policy) - but when I try to think about
how a scaling workflow would look like I'm wondering if it's not more
intuitive to have these values on the node-template still.

3) You've mentioned once before that TOSCA also defines an implicit
mechanism for creating multiple instances via the requirements&capabilities
mechanism; What are your ideas regarding that, and how do they fit in
together with this?


None of these is a real objection to what you've suggested though, only
some thoughts about it :)


On Thu, Jun 1, 2017 at 10:52 PM, Tal Liron <ta...@gigaspaces.com> wrote:

> The TOSCA spec says nothing about how multiple nodes per template would be
> created, leaving it the orchestrator to decide. The provided scaling policy
> in the Simple Profile is empty, just providing a base type for users to
> extend.
>
> What I'm proposing is to support basic policy-based scaling to ARIA. I have
> a pull request that works and you can try out:
>
> https://github.com/apache/incubator-ariatosca/pull/143
>
> The way it works is that you can define a default_instances number for any
> number of nodes (or nodes in the group) by applying the scaling policy to
> it. min_instances and max_instances are also there, though ARIA doesn't
> know what to do with them at the moment. They would be available for
> plugins to implement their own scaling system, to make sure their workflows
> are scaling with the user-defined bounds.
>
> In terms of code, it meant removing the default_instances, min_instances,
> and max_instances fields from the NodeTemplate model. Instead, there is a
> default_instance property that will grab the value from applicable
> policies.
>
> Works great! But I would be happy to hear feedback about this bold
> approach. I think one negative is that if you want to give default scaling
> parameters for different nodes you would have to define separate policies.
> But I don't think this is so bad, and is actually the correct usage of
> policies (and groups) in TOSCA.
>