OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

oslc-automation message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

> 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

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]