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 <[email protected]> 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. >
