[almighty] Major Architectural Question for the Build

Wed Nov 2 16:36:33 UTC 2016

An addition: hence when we are designing that stuff, we should not
think "how do we provide the best technical solution?" but "how can we
provide the cheapest solution for the integrators?". It all boils down
to someone asking someone else "how expensive will it be to integrate
this stuff?"...

On Wed, Nov 2, 2016 at 5:33 PM, Michael Kleinhenz <kleinhenz at redhat.com> wrote:
> I understand the point, in the REST API model, a 3rd party could write
> a proxy and host it elsewhere, but is that a realistic scenario?
>
> This boils down to three scenarios:
>
> 1. the build provider's vendor would host it themselves, then this
> would be prone to the described problem "must operate our integration,
> which costs ongoing money".
> 2. we host it, then there is no real difference between the REST API
> case and the Plugin case.
> 3. a 4th party hosts it, at which point I would say that is a very
> fragile construct, both technically and from a policy standpoint (the
> secret key is going thu not 2 parties, but 3!).
>
> So either way, I see the "proxy" model only asa theoretical model, not
> a real one.
>
> And I don't like it either, but tech considerations are if ever, only
> 50% of the consideration when providing external integration points.
> The best designed system does not make sense if customers don't adopt
> this stuff because of business reasons.
>
>
> On Wed, Nov 2, 2016 at 3:54 PM, Tomas Nozicka <tnozicka at redhat.com> wrote:
>> Both models require NO changes to vendor's existing systems!
>>
>> Max, I am a bit confused by that argument as well. Maybe Michael would
>> like to elaborate on that?
>>
>> Let's summarize:
>>
>> = Plugin model (Deployment API) =
>> The plugin will be "a proxy" translating Almighty Build SPI -> Target
>> build environment API calls.)
>>
>> + doesn't need any hosting
>> + no changes to vendor's existing system
>> - runs inside Almighty process in sandbox - major *security risk*
>> - forces user to learn subset of Lua (or any scripting language we
>> *force* them to use) with special functions - *steep learning curve*;
>> - additional complexity for Almighty to implement sandboxing
>>
>>
>>
>> = REST API (Consumer API)
>> The REST service will be "a proxy" translating Almighty Build SPI ->
>> Target build environment API calls. Also a vendor can *choose* to build
>> such API into their build system providing a native support for
>> Almighty without need for such proxy. Again *choose*.)
>>
>> + *vendor chooses implementation language* he likes (uses) an writes
>> simple REST (stateless) service (like a proxy translating Almighty
>> Build SPI -> Target build environment API calls)
>> + no changes to vendor's existing system
>> + scales independently
>> + one provider can be used by multiple Almighty instances
>> + *testable*
>> + *secure*
>> - needs hosting (but that's dead simple e.g. with OpenShift Online
>> especially for stateless service)
>>
>>
>> I don't really see any advantage in writing a plugin than the fact that
>> you don't need to deploy it. But that's really simple in the age of
>> OpenShift, Kubernetes and CaaS...
>>
>> Otherwise there are only advantages if we choose the REST approach.
>>
>> Regards,
>> Tomas
>>
>>
>>
>> On St, 2016-11-02 at 14:36 +0100, Michael Kleinhenz wrote:
>>> Ah, sorry, missed the words. I meant the "Deployment Model", not the
>>> "Consumer Model", sorry. I meant the one I would recommend :-)
>>> Everything else applies :-)
>>>
>>> On Wed, Nov 2, 2016 at 2:22 PM, Max Rydahl Andersen <manderse at redhat.com> wrote:
>>> >
>>> > On 2 Nov 2016, at 14:15, Michael Kleinhenz wrote:
>>> >
>>> > >
>>> > > Hi all,
>>> > >
>>> > > preliminary notice: I can live with any of the solutions, I see
>>> > > advantages and problems with both.
>>> > >
>>> > > Maybe I have done too much sales on such stuff, but I think the
>>> > > "Consumer Model" will be a major roadblock in actually convincing
>>> > > people to support us. This model will require lots of effort, changes
>>> > > to their live system and/or deployment and operations(!) to support
>>> > > integrating with us. In my experience especially the last one,
>>> > > operations, is a real blocker for 3rd parties. Just my 0.02€ on real
>>> > > world adoption of products in the corporate world..
>>> >
>>> >
>>> > I'm really confused how something that requires no changes on their external
>>> > systems
>>> > is a problem for adoption ?
>>> >
>>> > I'm missing something in this argument ;)
>>> >
>>> > >
>>> > > I think our way of approaching that question is way to technical and
>>> > > not enough sales. (I am feeling dirty that I have said that :-)
>>> > >
>>> > > But anyway, again: if we decide for the consumer style model, thats
>>> > > fine for me, I just want to say that there might be another, non-tech,
>>> > > view on that.
>>> >
>>> >
>>> > /max
>>> > >
>>> > >
>>> > >
>>> > > -- Michael
>>> > >
>>> > > On Tue, Nov 1, 2016 at 6:30 PM, Andrew Lee Rubinger <alr at redhat.com>
>>> > > wrote:
>>> > > >
>>> > > >
>>> > > > Gave some time to think this through. :)  Appreciate the thoughts
>>> > > > Michael,
>>> > > > because I think your email here has redirected our line of thinking into
>>> > > > something better than originally designed.
>>> > > >
>>> > > > To me, the most important issues this thread has vetted are:
>>> > > >
>>> > > > 1) Encouraging extension of Almighty through new providers
>>> > > > 2) Security
>>> > > >
>>> > > > Now, I had been initially conceiving something akin to what Michael is
>>> > > > calling the "Deployment" model; an interface that providers implement.
>>> > > > On
>>> > > > further reflection I've come to find the REST-based approach outlined as
>>> > > > the
>>> > > > "Consumer" model accomplishes all of our goals and better handles the two
>>> > > > points above.
>>> > > >
>>> > > > For 1), we let users register their own service, running *somewhere*, to
>>> > > > be
>>> > > > written in whatever language and execution environment they decide.  This
>>> > > > imposes on providers writers the burden of deploying their thing instead
>>> > > > of
>>> > > > deploying it into Almighty, but, as 2) shows, this is a good thing.
>>> > > >
>>> > > > The security constraints of 2) really say that we will absolutely not run
>>> > > > untrusted code in our online service offering.  Initially I'd thought
>>> > > > that
>>> > > > anyone who wants to write their own providers could be on their own to
>>> > > > host
>>> > > > an Almighty instance as well, but by making the provider model a firewall
>>> > > > where untrusted code runs externally to Almighty, we could be opening
>>> > > > ourselves off to safe extensibility or community-driven extensions in the
>>> > > > future.  While this is not a requirement for our first launch, it's
>>> > > > definitely the kind of thing Todd envisions for us going forward.
>>> > > >
>>> > > > TL;DR for me now: a REST-based extension SPI model, and registration
>>> > > > mechanism with Almighty core which sets that up.  Will look forward to
>>> > > > seeing those designs.
>>> > > >
>>> > > > S,
>>> > > > ALR
>>> > > >
>>> > > > On Mon, Oct 31, 2016 at 10:57 AM, Tomas Nozicka <tnozicka at redhat.com>
>>> > > > wrote:
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > > Hi Pete,
>>> > > > >
>>> > > > > (see inline)
>>> > > > >
>>> > > > > On Thu, 2016-10-27 at 13:15 -0400, Pete Muir wrote:
>>> > > > > >
>>> > > > > >
>>> > > > > > 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
>>> > > > >
>>> > > > > I like the separation and implementation language independence.
>>> > > > >
>>> > > > > >
>>> > > > > >
>>> > > > > > 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 am not opposing the idea, but would you mind laying out some story
>>> > > > > why it would be useful?
>>> > > > >
>>> > > > > From my point of view vendors can run such service on OpenShift Online
>>> > > > > or any other server (or cloud).
>>> > > > >
>>> > > > > Even we were (are) planing to run OSBP on different server using
>>> > > > > HTTPS.
>>> > > > >
>>> > > > > I don't see the use case for supporting sockets (or similar mechanisms)
>>> > > > > especially when Almighty will be running in the cloud; if such
>>> > > > > mechanism could even work there.
>>> > > > >
>>> > > > > >
>>> > > > > >
>>> > > > > > I don't think allowing people to write scripts that execute inside
>>> > > > > > our processes is a good idea.
>>> > > > >
>>> > > > > +1
>>> > > > >
>>> > > > >
>>> > > > > Regards,
>>> > > > > Tomas
>>> > > >
>>> > > >
>>> > > >
>>> > > >
>>> > > >
>>> > > > --
>>> > > > Red Hat Developer Group Architecture
>>> > > > @ALRubinger
>>> > >
>>> > >
>>> > > --
>>> > > 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
>>> >
>>> >
>>> >
>>> > /max
>>> > http://about.me/maxandersen
>>>
>>>
>>>
>
>
>
> --
> 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