> > > 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). >
I simply cannot think of a way to do this in TOSCA. For our operation configuration we made use of dependencies in a creative way. But for nodes there just isn't much there to use. I considered using artifact definitions ... but this is really going too far in my view in terms of weirdness. And policies is the right way to do it in TOSCA. > 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. > Actually, the scaling policy is not especially special :) -- it's parsed and stored like any other policy (unlike custom workflow policies, which become OperationTemplate models). And there can be many other TOSCA policies: placement, allotment, allocations, etc., that may or may not be supported by ARIA specifically, and may or may not be used by other TOSCA tools up or down the line. For example, someone might create an ARIA extension to support resource allocation policies with its own list of special properties. Why does scaling get a privileged column in NodeTemplate but not them? I say we treat all policies fairly and equally and not sully the NodeTemplate model with policy specifics. The policies are exactly designed to be in a separate section in the TOSCA template so you can look them and see all that apply to your nodes. There's actually something else interesting we can do here: create a special "policies" property for NodeTemplate that combines those directly associated with it with those that are associated indirectly via GroupTemplate (this extra combination was the only reason I didn't use SQL relationships directly to find them). This could be implemented via a SQL query. What do you think? 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? > So, here's how I understand it: in capabilities definition (section 3.6.1.1) you have an "occurrences" field, which by default is unbounded but can definitely be set to an explicit max. For example, a router might define an "upstream" capability limited to 5. During the reqs-and-caps matching process, let's say that 5 relationships have been forged with the node, and now you have an extra node that also requires "upstream" from us. To me, this seems to imply than an extra router node should be created. But ... I might very well be wrong here. This kind of auto-scaling might have unforeseen consequences if the template author was not aware that this could happen. I think it's best that we should not apply any magical autoscaling at the design phase, HOWEVER, we can take into consider the policy if it was set. If default_instances is 1, and max_instances is 5, then it means the template author has considered multiple router nodes. I hope this makes sense, it's a somewhat shadowy corner of the TOSCA spec... Note I would consider implementing this as a separate JIRA if we agree that this is correct.
