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 <r...@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 <t...@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>
