[almighty] Major Architectural Question for the Build

Wed Nov 2 13:36:15 UTC 2016

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