[Oslc-Automation] [oslc-core] Request for review of OSLC Automation specification
Michael F Fiedler
fiedler at us.ibm.com
Wed Jun 13 15:21:56 EDT 2012
With respect to the state/verdict discussion in this thread.
The specification does define the states and verdicts [1].
States are: new, queued, inProgress, canceling, canceled and complete.
The intent is to indicate where the request or result is in its lifecycle
Verdicts are: incomplete, pass, warning and fail. The intent is to
indicate the relative success of the execution.
On an automation result, I could see the possibility of not making state
mandatory since we have the incomplete verdict.
I've queued up discussion of whether state should be mandatory on results
as an agenda item for tomorrow.
Regards,
Mike
Michael Fiedler
IBM Rational Software
fiedler at us.ibm.com
919-254-4170
David N Brauneis/Raleigh/IBM wrote on 06/04/2012 06:34:47 AM:
> David N Brauneis/Raleigh/IBM
> 06/04/2012 06:34 AM
>
> To
>
> Pramod K Chandoria <pchandor at in.ibm.com>,
>
> cc
>
> Michael F Fiedler/Durham/IBM at IBMUS, oslc-automation at open-
> services.net, oslc-automation-bounces at open-services.net, oslc-
> core at open-services.net, oslc-core-bounces at open-services.net
>
> Subject
>
> Re: [oslc-core] [Oslc-Automation] Request for review of OSLC
> Automation specification
>
> Pramod,
>
> See further responses/thoughts in bold red.
>
> 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: Pramod K Chandoria <pchandor at in.ibm.com>
> To: David N Brauneis/Raleigh/IBM at IBMUS
> Cc: Michael F Fiedler/Durham/IBM at IBMUS, oslc-automation at open-
> services.net, oslc-automation-bounces at open-services.net, oslc-
> core at open-services.net, oslc-core-bounces at open-services.net
> Date: 06/04/2012 02:26 AM
> Subject: Re: [oslc-core] [Oslc-Automation] Request for review of
> OSLC Automation specification
>
> Thanks David for the answers,
> My answers inlined between <pchandor></pchandor>
>
> -|- Pramod Chandoria
>
>
>
> From: David N Brauneis <brauneis at us.ibm.com>
> To: Pramod K Chandoria/India/IBM at IBMIN
> Cc: Michael F Fiedler <fiedler at us.ibm.com>, oslc-
> automation at open-services.net, oslc-automation-bounces at open-
> services.net, oslc-core at open-services.net,
oslc-core-bounces at open-services.net
> Date: 06/03/2012 04:53 AM
> Subject: Re: [oslc-core] [Oslc-Automation] Request for review
> of OSLC Automation specification
>
>
>
> Pramod,
>
> I have a couple of thoughts on what you have proposed, I have added
> them inline in bold red.
>
> 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: Pramod K Chandoria <pchandor at in.ibm.com>
> To: Michael F Fiedler/Durham/IBM at IBMUS
> Cc: oslc-automation at open-services.net, oslc-core at open-
> services.net, oslc-automation-bounces at open-services.net
> Date: 06/02/2012 09:37 AM
> Subject: Re: [oslc-core] [Oslc-Automation] Request for review
> of OSLC Automation specification
> Sent by: oslc-core-bounces at open-services.net
>
>
>
> I have few comments as mentioned below.
>
> Automation plan: Can we just call it Automation. Do we gain any
> meaning with plan. I think that the whole topic of the working group
> is automation and there are many things associated with it, I like
> keeping it as an automation plan and have already started to use
> that terminology with customers (and it seems to resonate).
> <pchandor>I have no big concern here</pchandor>
>
> Automation plan: We don't have oslc_auto:automationType attribute.
> Without this we can't distinguish whether Automation is for build,
> test, deployment, cloud etc.. I think this needs to be typed. I
> actually do not agree with an approach that types the automation,
> there are some automation plans that might perform one or more of
> those different types as a part of the workflow (think a continuous
> integration or continuous delivery product - i.e., DevOps)... How
> would you characterize those? Also, some automation providers will
> exist that can support more than one type of automation and do not
> need them to be separated. What do we gain by forcing this?
> <pchandor>I think when a AutomationPlan represents a group of
> Automations (like TestSuite in RQM, workflow in DevOps), it might
> make sense to call them "complex" type. Consider a scenario like
> user is defining a workflow in RTC, that when a build automation is
> completed, wants to run a Test Automation. When user will query
> automation from the automation provider (RQM), It would definitely
> like automation plan of 'test' type be listed to choose from. Do we
> think this should be defined in service providers name space?. I
> think having a type in spec will provide client hint about what type
> of Automation plan it is.</pchandor> <dnb>I really think this is
> unnecessary, it is by choosing the automation plans from the
> provider where this "hint" of what the automation plan might do. I
> think that the type would like end up being close to unique per
> automation provider which kind of defeats the purpose. What about
> automation providers that can do some generic automation work, would
> it then be up to the Automation Provider to change and require the
> end user to define the type of automation it is from a list of
> categories. I do not see what the gain for the consumer is here...
> If I ask RQM and it returns test, if I ask RTC and it returns build,
> and if I ask RAF and it returns deployment (always in each of these
> cases) what is the purpose?</dnb>
>
> Automaton Request: oslc_auto:state - Probably it's value can be
> defined by specification, rather loosely relying on the provider.
> This will allows clients to write more predictable code rather
> writing specific code to each provider. I think verdict domain can
> be different for different provider but state of the Automation
> Request can be guided by specification across all providers. I think
> is needed because most automation providers will have the concepts
> of queued, started, running, paused, complete, etc.
> <pchandor>Exactly you answered my question here. Probably specifying (
> queued, started, running, paused, complete) states would be
> sufficient here.</pchandor>
>
> AutomationResult: oslc_auto:verdict is used for end result's verdict,
> oslc_auto:state - I am not sure why this property is mandatory when
> verdict is already available. In RQM there is only one field for
> verdict, there is no other state for result. I am thinking this
> should not be one-many but zero-many property. I thought this meant
> whether or not the automation executed successfully or failed.
> <pchandor>If it's meaning is only for client to determine whether it
> was successful or not, then it should be of type of boolean? With
> type being (anyType), what value we attain for the client. In that
> case client can also determine same from the verdict.</pchandor>
> <dnb>I think there might be a couple of more verdict states (I was
> simplifying it for the purposes of differentiating it from state - I
> think other possible verdicts might be "successful with warnings" or
> even "canceled."</dnb>
>
> Regards,
>
___________________________________________________________________________
>
> -|- Pramod K Chandoria
>
> Advisory Software Engineer
>
> IBM Rational, India Software Lab
>
> [image removed]
>
> Bangalore, India | +91-80-417-77045 | +91 99805 68253
>
> What's new in 4.0 RC0 | Ask Question in forum | Online Help |
> Download RQM 4.0 RC0
>
> [image removed]
>
>
>
>
>
>
>
>
> From: Michael F Fiedler <fiedler at us.ibm.com>
> To: oslc-automation at open-services.net, oslc-core at open-services.net
> Date: 05/08/2012 07:49 PM
> Subject: [Oslc-Automation] Request for review of OSLC
> Automation specification
> Sent by: oslc-automation-bounces at open-services.net
>
>
>
> The Automation workgroup continues to make progress on the
> specification and is working to move towards convergence with
> several early implementations beginning now.
>
> The workgroup would like to invite you to review the current draft
> [1] of the specification. All comments are welcome. We would
> especially be interested in feedback from Core members and
> Automation members who have not been in attendance lately.
>
> [1] - http://open-services.net/bin/view/Main/AutoSpecificationV2
>
>
> 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-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20120613/7c45ffd1/attachment-0003.html>
More information about the Oslc-Automation
mailing list