On Sat, May 20, 2017 at 3:47 AM Tal Liron <[email protected]> wrote:
> Phew! Everything seems to work now: functions are parsed and evaluated > properly. But there are some changes that require explaining. > > The "configuration" field in OperationTemplate and Operation models is now > a many-to-many with Parameter. This allows the values to fully support > intrinsic functions and types. > > And I made another change in modeling: Operation now also has "function" > and "arguments" fields, which are what actually gets used by the Task API > instead of "implementation" and "inputs". This means that the > "implementation" and "inputs" values are preserved as is. During the > configuration phase the "arguments" are created according to the usual > logic: for the execution plugin, the "configuration" is massaged into a few > new "arguments", and otherwise other "inputs" are also merged into > "arguments". > > Why make this change? Because I really think we should not mangle the > "inputs": they are logically different from the arguments that get sent to > the @operation function, even if in many cases we might treat them > identically. Also, we cannot lose the "implementation" string: plugins will > need to know what users put in there. The change is not big in terms of > extra code, but I think it helps make the code easier to understand: you > can see exactly what is being merged into the final "arguments" for the > task. The configure phase is now constructive rather than destructive: > existing fields are not changed. > Tal, could you provide several example models to showcase these changes? > > Before moving forward with a PR I want to see what other committers think > about also renaming "implementation" and "inputs" in the Task API to > "function" and "arguments". For now I'm leaving them as is, but I think it > would be even cleaner if they followed the new naming convention in > modeling. I continue being unhappy about how the Task API treats both > arguments and inputs as the same thing and squashing them all together... > :( However, for now I would be happy if we just called them "arguments", > because that's what they really are for us. > > -- > Tal Liron > Solution Architect > [email protected] | +13123758299 <(312)%20375-8299> > Cloudify | http://getcloudify.org > < > http://getcloudify.org?utm_source=signaturesatori&utm_medium=email&utm_campaign=general_signature > > > > <https://twitter.com/CloudifySource> > <https://www.linkedin.com/groups/8467478> > <https://github.com/cloudify-cosmo> <https://github.com/cloudify-cosmo> > [image: Azure Webinar] > < > http://getcloudify.org/webinars/Azure-plugin-for-cloudify-webinar.html?utm_source=signaturesatori&utm_medium=email&utm_campaign=general_signature > > >
