[Oslc-Automation] Parameters: need for input and output parameters?
Charles Rankin
rankinc at us.ibm.com
Wed Jan 11 17:24:22 EST 2012
Not really replying directly to you, Dan. Just throwing out my opinions.
:)
I can see the concept of (probably read-only) input parameters on the
Automation Plan as a means to define which parameters may/must be provided
upon execution (in lieu of something like a Resource Shape). I can see
the idea of (writeable on creation, read-only otherwise) input parameters
on the Automation Request as a way to specify the incoming parameters and
for consumers to see what data was specified when the request was
submitted. These will likely be different (structurally) from what you
see on the Automation Plan as not only will they have values associated
with them, but they won't need to specify any of the input constraints
that you might see associated with the input parameters on the Automation
Plan. I can also see (read-only) input parameters associated with the
Automation Result as a way to see what was used when the associated
Automation Plan/Request was run. This set may be larger than what is seen
on the Automation Request (or Automation Plan) as some interesting inputs
may be auto-generated by the underlying system.
With respect to output parameters, I'm not a big proponent here, at least
not for the first version of the spec. I don't think there is any
commonality at all among prospective implementers on this. In most cases,
I don't believe the concept even exists. I suggest the use of a Result
Contribution to handle this for the first version of the spec. In an
appendix, we could provide guidance on the potential type and structure of
a Result Contribution that could hold the collective set of output
parameters (I do not suggest having a one-to-one mapping between output
parameters and Result Contributions). If we see sufficient uptake on
that, then it would be something we could look to make more "first class"
in the next version of the spec. If it comes to pass that we do spec
explicit output parameters on one or more of the resources, I would
suggest that it only be on the Automation Result resource (again, at least
for the first version of the spec).
Charles Rankin
Rational CTO Team -- Mobile Development Strategy
101/4L-002 T/L 966-2386
From:
Daniel Berg/Raleigh/IBM at IBMUS
To:
"oslc-automation at open-services.net" <oslc-automation at open-services.net>
Date:
01/06/2012 05:03 PM
Subject:
Re: [Oslc-Automation] Oslc-Automation Digest, Vol 11, Issue 4
I agree that input parameters are declared by the Automation Plan and the
values are provided by the Request and the values used by the request
are recorded in the Result. So far so good.
Now the thought with output parameters is a way that an Automation Plan
could declare parameters that could be referened
by another Request knowing that the value would be resolved (i.e., set)
after the Automation Plan has been executed.
Separating input from output is necessary to identify what values can be
set by a Request (input only) since the Plan
is responsible for setting output parameters during execution. However
both input and output parameters can be references by downstream Requests.
Note the use of output parameters on an Automation Plan does not scale
well were there may be multiple outputs that require some structural
knowledge.
For example if you have an Automation Plan that provisions multiple VMs
you will likely need output parameters for the host names of each VM that
was provisioned.
Having multiple output parameters named "hostname" is not useful. There
would need to be some context. This can be achieved in one of two ways.
One, each output parameter is required to have a unique name. Better but
not ideal. Second, a topological graph is managed by the Automation Plan
(do we support
composition??) providing context for all parameters (input and output)
that could be set and retrieved during the execution
of the plan. In the second case the topological node values would be
available for downstream requests to use and possibly set.
The first approach is simpler in my opinion and the second makes many more
assumptions about how the orchestration mechanism will work and manage
parameter passing. Thus I lean towards the first approach since it is
simpler.
Dan
Sent from my iPad
On Jan 6, 2012, at 12:15 PM, oslc-automation-request at open-services.net
wrote:
>
> Message: 1
> Date: Fri, 6 Jan 2012 22:47:33 +0530
> From: Pramod K Chandoria <pchandor at in.ibm.com>
> To: David N Brauneis <brauneis at us.ibm.com>
> Cc: oslc-automation at open-services.net,
> oslc-automation-bounces at open-services.net
> Subject: Re: [Oslc-Automation] Parameters: need for input and output
> parameters?
> Message-ID:
> <OFA014377B.D0006D33-ON6525797D.005D4E77-6525797D.005EB961 at in.ibm.com>
> Content-Type: text/plain; charset="us-ascii"
>
> If we do that ("define a ResultContribution type that is a name-value
> pair"), that does not help to distinguish between what to be passed on
to
> next automation v/s what not to pass, except we decide to pass all
> parameters to next request.
> Comparatively, 'output parameters' could provide opportunity to limit
> explicitly what is available as input for next automation request in
> sequence. However It brings another problem who and how determines what
to
> be made available in output parameters. I think it would be the
> responsibilities of the workflow orchestrator to determine what to be
> passed on from one request to next request.In that case distinguishing
> between input and output parameter may not be of worth.
>
> Currently RQM uses similar concept to pass variables from one Testcase
> Execution to next for Test Suite execution. In this case all variables
all
> passed and merged to next request.
> There is NO difference between input v/s output parameter. At any stage,
> any request have collection of parameters without distinguishing what
was
> input, what was modified or added. The result of request have all
> parameters copied from request.
>
> Regards,
>
___________________________________________________________________________
>
> -|- Pramod K Chandoria
>
>
> Advisory Software Engineer
>
> IBM Rational, India Software Lab
>
> Bangalore, India | +91-80-417-77045 | +91 99805 68253
> What's new | Ask Question in forum | Online Help | Download RQM 3.0.1
>
>
>
>
>
>
>
> From: David N Brauneis <brauneis at us.ibm.com>
> To: oslc-automation at open-services.net
> Date: 01/06/2012 09:42 PM
> Subject: Re: [Oslc-Automation] Parameters: need for input and
> output parameters?
> Sent by: oslc-automation-bounces at open-services.net
>
>
>
> Paul,
>
> I guess that I was not making the assumption that contribution is
> necessarily a "resource" but that it could be... In fact, could we not
> define a ResultContribution type that is a name-value pair???
>
> Regards,
> David
> ____________________________________________________
> David Brauneis
> STSM, Rational Software Delivery Automation Chief Architect
> email: brauneis at us.ibm.com | phone: 720-395-5659 | mobile: 919-656-0874
>
>
>
> From: Paul McMahan/Raleigh/IBM at IBMUS
> To: oslc-automation at open-services.net
> Date: 01/06/2012 10:33 AM
> Subject: Re: [Oslc-Automation] Parameters: need for input and
> output parameters?
> Sent by: oslc-automation-bounces at open-services.net
>
>
>
> I was thinking that the difference between contributions and output
> parameters is that a contribution is a "resource" - i.e. an autonomous
> artifact with properties of its own that can be inlined in the result or
> referenced via URL. On the other hand, output parameters are name/value
> pairs that can be used to facilitate further downstream automation. For
> example, another automation request might be created with input
parameters
> copied from the automation result's output parameters. Another scenario
> could be if the provider actually changed the value of a particular
input
> parameter during the automation and needs to make a record of that. If
> the parameters were not distinguished as input vs. output then there
> wouldn't be any way to denote that the provider had used a different (or
> maybe just more refined) value than what was provided as input.
>
>
> Best wishes,
> Paul McMahan
> Rational Quality Manager
>
>
>
>
> From: David N Brauneis/Raleigh/IBM at IBMUS
> To: oslc-automation at open-services.net
> Date: 01/06/2012 10:10 AM
> Subject: Re: [Oslc-Automation] Parameters: need for
input
> and output
> parameters?
> Sent by: oslc-automation-bounces at open-services.net
>
>
>
> Michael,
>
> Thanks for taking the time to write this information up to the give the
> group a starting point for the discussion going forward... I'm mostly in
> agreement with everything that you have written down so far with the
> exception of the outputParameters. I'm having a little trouble getting
my
> head around the need for an outputParameter and how that is really
> different than a ResultContribution. Perhaps I am just being a little
> dense
> but I was thinking that the parameters (name-value pairs) would be input
> with the request and would be read-only in the result but that anything
> created during processing (like an MD5 checksum) would be a
> ResultContribution. Am I thinking about this completely differently than
> everyone else?
>
> Regards,
> David
> ____________________________________________________
> David Brauneis
> STSM, Rational Software Delivery Automation Chief Architect
> email: brauneis at us.ibm.com | phone: 720-395-5659 | mobile: 919-656-0874
>
>
>
> From: Michael F Fiedler/Durham/IBM at IBMUS
> To: oslc-automation at open-services.net
> Date: 01/05/2012 09:22 PM
> Subject: [Oslc-Automation] Parameters: need for input and output
> parameters?
> Sent by: oslc-automation-bounces at open-services.net
>
>
>
>
> An important point came up at the end of today's call around the
zero-many
> *parameter* attribute on Automation Plans, Requests and Results. There
> was
> sentiment that there needs to be a distinction between input parameters
> and
> output parameters for Results, and possibly for each of the resources.
> Continuing the discussion, here are some thoughts on what the usage
might
> be for each artifact:
>
> Automation Plan: The parameters are likely to all be input parameters.
> Some may have default values, others may be empty. These provide
> consumers with a starting point of what parameters are required for
> successful request creation. Are there scenarios for output parameters
on
> the Plan? None are occurring to me.
>
> Automation Request: When creating a Request, consumers provide the
input
> parameters for actual automation execution (or at least the subset of
> parameters they have control over). There is likely a scenario for the
> service provider adding additional parameters to the request, but they
> would still be input parameters. Is there a scenario for output
> parameters on the Request artifact? Possibly as the result of
processing
> that the service provider does to "accept" the Request?
>
> Automation Result: The input parameters here would be a "final" record
of
> what parameters were used to run this automation and create the result.
> As discussed today, there also seems to be a strong case for output
> parameters on the result. I.e., as the automation executed, certain
> information, apart from the main result contributions, is generated and
> needs to be captured in the result - especially for consumers of the
> result
> such as downstream automations. Examples might be the MD5 hash of a
> binary which was the result of an automation or the filesystem location
of
> the primary automation result artifact.
>
> We never reached the point of proposing it, but I think the direction
was
> to propose 2 sets of parameter attributes/predicates: inputParameter
and
> outputParameter. From the descriptions above, outputParameter might
only
> be appropriate for a subset of the artifacts, but could be included on
all
> for symmetry.
>
> Comments? We'll discuss in the next meeting, but a discussion on list
> would be fine as well.
>
> Regards,
> Mike
>
> Michael Fiedler
> IBM Rational Software
> fiedler at us.ibm.com
> 919-254-4170
>
>
> _______________________________________________
> Oslc-Automation mailing list
> Oslc-Automation at open-services.net
>
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
>
>
> _______________________________________________
> Oslc-Automation mailing list
> Oslc-Automation at open-services.net
>
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
>
>
>
>
> _______________________________________________
> Oslc-Automation mailing list
> Oslc-Automation at open-services.net
>
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
>
>
> _______________________________________________
> Oslc-Automation mailing list
> Oslc-Automation at open-services.net
>
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20120106/5511253a/attachment.html
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: image/gif
> Size: 360 bytes
> Desc: not available
> URL: <
http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20120106/5511253a/attachment.gif
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: image/gif
> Size: 3624 bytes
> Desc: not available
> URL: <
http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20120106/5511253a/attachment-0001.gif
>
>
> ------------------------------
>
> _______________________________________________
> Oslc-Automation mailing list
> Oslc-Automation at open-services.net
>
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
>
>
> End of Oslc-Automation Digest, Vol 11, Issue 4
> **********************************************
> _______________________________________________
Oslc-Automation mailing list
Oslc-Automation at open-services.net
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20120111/9842bc1a/attachment-0003.html>
More information about the Oslc-Automation
mailing list