[almighty] Major Architectural Question for the Build

[Todd Mancini]

Andrew knows that I feel all CS problems can be solved by adding another
level of indirection...

On Wed, Nov 2, 2016 at 10:46 AM, Andrew Lee Rubinger <alr at redhat.com> wrote:

> It's a fair point.  Will talk it over with Todd.
>
> By the way, using the "Deployment" model you can delegate to the
> "Consumer" one like an adaptor.  Don't underestimate the power of Another
> Level of Indirection. :)
>
> On Nov 2, 2016 9:15 AM, "Michael Kleinhenz" <kleinhenz at redhat.com> 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 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.
>>
>> -- 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20161102/4f989ee9/attachment.htm>