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