[almighty] Major Architectural Question for the Build

[Pete Muir]

This reminded me of the VS Code/LSP architecture. In this architecture
there are a number of proceses running:

1) The VS Code tool
2) A server which can control and talk to any LSP implementation via a
socket or REST or other transport protocol
3) The LSP implementation(s) written in the language of choice, talking a
JSON protocol

This is closest to the the Consumer model that Michael describes, but I
think we could also look at also being able to run the plugin (and the
thing it connects to) on our servers, but using transports other than HTTP
(e.g. sockets).

I don't think allowing people to write scripts that execute inside our
processes is a good idea.



On 27 October 2016 at 12:54, Michael Kleinhenz <kleinhenz at redhat.com> wrote:

> That may also be something Todd should look at..
>
> On Thu, Oct 27, 2016 at 6:53 PM, Michael Kleinhenz <kleinhenz at redhat.com>
> wrote:
> > Just for addition: I am believing the Deployment-SPI is the way to go,
> > not because of technical considerations, just because of the market
> > acceptance that the system will need. to succeed. It should be as easy
> > as possible for vendors to integrate with us.
> >
> > On Thu, Oct 27, 2016 at 6:16 PM, Tomas Nozicka <tnozicka at redhat.com>
> wrote:
> >> Hi Michael,
> >>
> >> (inline)
> >>
> >> tl;dr; "Consumer-SPI"
> >>
> >> On Thu, 2016-10-27 at 17:44 +0200, Michael Kleinhenz wrote:
> >>> Hi Tomas, Andy,
> >>>
> >>> I encountered a foundational architectural question while thinking
> >>> about specific TODOs for the build stuff: is our SPI a
> >>> "Deployment-SPI" or a "Consumer-SPI"? Let me elaborate:
> >>>
> >>> Deployment-SPI: a 3rd party build provider writes a "plugin",
> >>> possibly
> >>> something scripted that could run in a sandbox, that is deployed on
> >>> Almighty. The plugin provides an API defined by us for the build
> >>> system. The plugin itself uses the build providers proprietary
> >>> network
> >>> protocol to talk to the actual build provider's systems.
> >>>
> >>> Consumer-SPI: we define a REST api that the build provider has to
> >>> implement. The Almighty system just gets the URL of the endpoint plus
> >>> the AuthN info.
> >>>
> >>> Advantages Deployment-SPI:
> >>> * the build provider "plugin" can be written by a 3rd party different
> >>> from the actual build provider.
> >> That's true for REST SPI as well.
> >>
> >>> * the build provider can be "generic" for a software, not a vendor; a
> >>> jenkins plugin can be used against any jenkins installation.
> >>> * the change requirements for the build provider on his exposed
> >>> services are not necessary; providing support for Almighty is just
> >>> writing a bit of software that is deployed elsewhere (this may be
> >>> cucial for adoption)
> >>>
> >>> Disadvantages Deployment -SPI:
> >>> * we need to run software on our systems that are not under our
> >>> control; this needs contract-based policies with the build provider
> >>> and/or a well working sandbox.
> >> And this forces user to write in language selected by us and and a
> >> subset of it restricted by our environment with special functions. It
> >> has a steep learning curve.
> >>
> >>>
> >>> Advantages Consumer-SPI:
> >>> * we don't need do deploy anything on our servers, we just use the
> >>> remote service.
> >>   * user can choose implementation language and use regular constructs
> >> there
> >>   * no steep learning curve
> >>   * independently scalable, ...
> >>   * can be a proxy to build system or the system itself with exposed
> >> Build provider SPI
> >>   * no need for special technologies like sandbox
> >>>
> >>> Disadvantages Consumer-SPI:
> >>> * the build provider must change/extend its service offering, what
> >>> may
> >>> need some investment.
> >> I don't think he need to change anything. He or anybody else will just
> >> write proxy for it fulfilling Build Provider SPI. He has to do the same
> >> work in case of "plugin".
> >>
> >> (For example we will be writing OSBP but no change or action is
> >> required from OpenShift for it. It will "just translate" calls and
> >> objects into different ones that OpenShift understands.)
> >>
> >>> Any thoughts?
> >> In both cases user has to at least write some kind of proxy translating
> >>     Build SPI into the target system. Whether it is done like a
> >> sandboxed plugin or fulfilled by REST SPI service.
> >>
> >> I firmly believe that REST service is a better and cleaner solution.
> >>
> >> So, "Consumer-SPI".
> >>
> >> But let's wait for other feedback, at least from Andy.
> >>
> >> Regards,
> >> Tomas
> >>
> >>>
> >>> -- Michael
> >>>
> >
> >
> >
> > --
> > Michael Kleinhenz
> > Principal Software Engineer
> >
> > Red Hat Deutschland GmbH
> > Werner-von-Siemens-Ring 14
> > 85630 Grasbrunn
> > Germany
> >
> > RED HAT | TRIED. TESTED. TRUSTED.
> > Red Hat GmbH, www.de.redhat.com,
> > Registered seat: Grasbrunn, Commercial register: Amtsgericht München,
> > HRB 153243,
> > Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham,
> > Michael O'Neill
>
>
>
> --
> Michael Kleinhenz
> Principal Software Engineer
>
> Red Hat Deutschland GmbH
> Werner-von-Siemens-Ring 14
> 85630 Grasbrunn
> Germany
>
> RED HAT | TRIED. TESTED. TRUSTED.
> Red Hat GmbH, www.de.redhat.com,
> Registered seat: Grasbrunn, Commercial register: Amtsgericht München,
> HRB 153243,
> Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham,
> Michael O'Neill
>
> _______________________________________________
> almighty-public mailing list
> almighty-public at redhat.com
> https://www.redhat.com/mailman/listinfo/almighty-public
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20161027/8a55f033/attachment.htm>