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