ariatosca-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tal Liron <>
Subject Re: Let's talk about scaling (ARIA-254)
Date Tue, 13 Jun 2017 16:11:16 GMT
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 <> 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 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 <> wrote:
> > Let's talk about scaling some more. :)
> >
> > Earlier, I complete missed the definition of tosca.capabilities.Scalable:
> >
> >
> > YAML/v1.0/cos01/TOSCA-Simple-Profile-YAML-v1.0-cos01.html#
> >
> > 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 <>
M: +1-312-375-8299 @cloudifysource

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message