[almighty] Major Architectural Question for the Build

[Michael Kleinhenz]

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