[almighty] Major Architectural Question for the Build

[Tomas Nozicka]

Hi Michael,

just to add a bit:

I actually believe the opposite, but for the same reasons :) (and some
more)

IMO nobody wants to write plugins in some subset of sand-boxed
scripting language. At least I wouldn't. (And we don't want to provide
such environment for complexity and security reasons.) It has a steep
learning curve in opposite to writing simple REST service that everyone
already knows how to do and can pick the right and familiar tools
(language, framework, ...) for the job. Not talking about other
benefits for the vendors like being easily testable, ...

I believe that for market acceptance and adoption REST API ("Consumer-
SPI") is the way to go.

Regards,
Tomas

On Thu, 2016-10-27 at 18:53 +0200, Michael Kleinhenz 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
> > > 
> 
> 
>