Re: [oslc-automation] Re: Broadcast: OASIS OSLC Automation TC meeting - please RSVP & look at deployment scenario

[John Arwe <johnarwe@us.ibm.com>]

general: seems to assume some familiarity
with Jenkins.  I personally lack that, so I'm interpreting 'pipeline'
in a fairly general sense that appears to agree with the bold build
script (pipeline),  at [1]

before/after: not obvious why before.3 is an issue.  saying it's _easier_ to build a UI showing the steps, sure.  saying it's _impossible_ w/o OSLC seems like an overstatement.

before/after: it sounds from the slides like _when it is the case that before.1/2 use non-standard APIs_ that a separate Jenkins plugin is needed, which is a barrier for the implementations - or are they already assumed to all know and love the Jenkins plugin API?

Jenkins scenario [1]:

J1: "configured to be a "friend" to two OSLC servers" ... what is this 'friend' term, a Jenkins term of art?  Not sure what it would mean.  I know what it means to JTS, but that's not the context here.

J2: "Jenkins inserts "${BUILD_TAG}" "... is this syntax something you foresee Automation defining, or an ignorable (wrt Automation) implementation choice?  To first order, these sorts of IDs flowing where the/some client is "just supposed to know what to do with them" screams out "then use a URI instead of a proprietary ID!" to me.

J3: "Simple, three steps " ... well they're not #d, but >> 3 to my eyes.  3 steps in the example pipeline, but >>3 in the scenario.

J4: "Deployment plan might need to be tightly-coupled to Jenkins. "  Well the implementation would be, perhaps.  At the interface level, it's the name/value pairs that form the interface to each Plan (which apparently Jenkins calls a pipeline step), in the sense of "what part of a Plan's interface is not standardised by Automation already".  Is this leading to standardization of some set of Plans and/or parameter names, in your mind?

J5: "User might need to tie parameters together manually. - This scenario doesn't actually encounter this problem. "  To me, that's exactly what's going on here, so this makes me think I'm reading it differently than you intended.  In the slides, how does the user know that the env on 13 is the same one from 8?  Aside from the potentially coincidental use of a common label in a UI, knowing that they are "wanting" to re-use a single concept seems like exactly a bit of knowledge filled in by the user.

slides:

10:  "standard for artifact repositories" ... not sure how it's positioned, but certainly it is true that OSLC Asset Mgmt [2] exists and has been used as the API for at least one artifact repo (Rational Asset Mgr).  I could also say that any API with a collection in it (nearly all of them) fit the words "artifact repo" though, so perhaps there is some implied meaning involved that I'm not grokking.  LDP is another [3].

[1] https://wiki.oasis-open.org/oslc-automation/UseCasesAndRequirements/DeployingBuildArtifactsContinuousIntegration

[2] open-services.net ailing at this hour - google it.

[3] http://www.w3.org/TR/ldp/

Best Regards, John

Voice US 845-435-9470  BluePages
Cloud and Smarter Infrastructure OSLC Lead