[oslc-core] [Oslc-Automation] Request for review of OSLC Automation specification

Mon Jun 4 06:35:51 EDT 2012

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 

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 

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-core_open-services.net/attachments/20120604/f1cd6e47/attachment-0003.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-core_open-services.net/attachments/20120604/f1cd6e47/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-core_open-services.net/attachments/20120604/f1cd6e47/attachment-0001.gif>