[almighty] Major Architectural Question for the Build

[Michael Kleinhenz]

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