1. Got it. 2. Ok, makes sense. I might have been wrong thinking this policy should be special then. About storing in policy information in nodes/templates that the policy is associated with in general - sounds interesting, I'm not sure I'd implement this right away, I think it'd be better to hold off and see what sort of policies might exist in the future and what data might be useful to keep on the node/template first.
3. Yes, I understand it better now, thank you. It does seem somewhat magic-ish and something that can lead to unintended effects.. I personally think it'd be better to err on the safe side i.e. not allow such a topology where 6 relationships are required and 5 is the allowed maximum - despite the fact the template author probably did consider multiple router nodes. But maybe I'm misinterpreting this :) Either way, you're right, this is definitely not related to ARIA-254 directly. On Mon, Jun 5, 2017 at 6:56 PM, Tal Liron <t...@gigaspaces.com> wrote: > > > > > > 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. >
