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

[Martin P Pain <martinpain@uk.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] 

I'm using "pipeline" in a general sense
here.

> 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. 

I'm looking at three different set-ups that could
be calling remote processes: 
A. build script (ant/bash/etc) on its own,
B. Jenkins job, and 
C. Jenkins + OSLC.
(Perhaps I ought to have three lists...)
In A, you can call remote servers' APIs, but to get
the UI overview you need to put in extra work. In plain Jenkins (B), you
get the UI overview, but to integrate with other servers you either need
their Jenkins plug-ins (if they have them; one per product being integrated)
or you need to write something yourself (can just be in bash/ant, but called
by Jenkins). In C you get Jenkins' benefits of the UI plus you don't need
to know the servers' APIs.

So, adding OSLC into Jenkins (if/when the servers
support it, or adapters are available for them) makes it easier for pipelines
to take advantage of the UI benefits of a tool like Jenkins - but it doesn't
actually provide that benefit itself, which I guess is your point.

> 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?


I'm finding it difficult to parse that sentence, but
I think I get your question.
But where in the slides are you referring to?
Currently, they use non-standard APIs. Therefore to
be used from Jenkins (currently) they either need a custom Jenkins plug-in,
or for users to write a script that calls that API and call that from Jenkins
(which is more opaque and provides less of a rich integration with Jenkins).
In Jenkins+OSLC, they will no longer need a separate
Jenkins plugin, as the integration in Jenkins will be provided by the single
OSLC consumer implementation(/plugin) in Jenkins. (However, they will each
need a native OSLC interface, or an adapter to OSLC - but these should
be more reusable due to everything that motivated OSLC: openness and loose
coupling.)

> 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. 

I took the term from JTS. It is not a Jenkins term.
I haven't fleshed out what it would mean specifically in Jenkins, but it
would probably mean adding the URL of the service catalog of the server
to a list, and doing any authentication/approvals needed to get access
to the OSLC resources on that server.

> 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. 

This is entirely on the Jenkins side of the interface.
Jenkins provides its list of variables (from its built-in variables, plus
potentially output parameters from previous automation plans/requests)
for the user to choose from, and Jenkins will perform the substitution
before submitting the Automation Request for submission.

> 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. 

I think that was supposed to be compared to another
example I was considering giving in parallel, but didn't. I'll remove it,
as it's not adding anything.

> 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? 

It would need some standardized way to identify the
parameter to pass in the identifier (URI?) of the build artifacts, and
also to identify what the deployment plan is expecting at the other end
of that URI (e.g. a zip, a WebDAV directory, an OSLC Asset Mgmt resource,
an LDP container of multiple instances or one of those types, etc). I don't
know exactly how it would look - this scenario doesn't even specify what
the build artifacts are or how the deployment step uses the - we would
need other scenarios to investigate what sort of things we would need to
support here, but I believe that can be done separately, if needed - unless
it is actually the most important or useful part of this whole scenario.

> 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. 

My intention for that point was about taking an output
parameter and putting it into an input parameter. Which is technically
different from passing the same value into two input parameters, but admittedly
from the user's perspective it's stil using the same thing in two places.
I'll clarify that bullet point and move it to a sub-point
of the one below it (which they does talk about repetition).

> 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]. 

"Artifact repository" in this case is something
designed to publish, store, version, tag (etc) the output of software builds.
So it might need more than a collection... but sometimes maybe not.
The scenarios of OSLC Asset Mgmt might demonstrate
all that would need to be supported in this story, but I don't intend on
looking at them yet (unless it is vitally important to this scenario, which
I'm not convinced it is - I see it more as a point of extensibility, so
Automation just leaves it open for "any other technology" to
fill the gap).

> [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 

Thanks,
Martin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU