ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Valentin Kulichenko <valentin.kuliche...@gmail.com>
Subject Re: automatically deploying user libraries
Date Wed, 29 Jul 2015 01:25:01 GMT

I'm not sure I understand the purpose of this discussion. Maven-based and
Git-based providers are just examples of pluggable implementations that we
can provide out of the box - user is never forced to use them.

I see two main use cases for the feature:

   - Dynamic deployment and redeployment of user's code during development.
   From my experience it can noticeably speed up the development, so I really
   like it. And Git+Maven approach fits here very well, BTW.
   - Interactive apps where users are allowed to deploy their custom stuff.
   Security concerns are valid here, of course. But it's up to developer to
   choose proper mechanisms of deployment and security.

I think we should discuss the feature itself, its API and how to provide
good abstraction that will allow the user to customize it in the way he
needs to achieve his goals and ensure required level security.


On Tue, Jul 28, 2015 at 3:29 PM, Ognen Duzlevski <ognen.duzlevski@gmail.com>

> >
> > It's called a remote code execution exploit. Anyone who has write access
> > to the repo (i.e., anyone who can hack in) can change the deployed code
> > and DOS your whole cluster.
> >
> I believe these decisions are best left to the end user, the mechanism
> proposed may or may not have valid uses for you but it may have valid uses
> to others. I am an old dog too and I don't practice or agree with some of
> the stuff "software engineers" pass along as good practice these days but
> that doesn't mean other people should be deprived of a possibility. At the
> end of the day, so long as the source code to something is online or on a
> machine connected to the Internet, there is risk. Ever since that one paper
> got us thinking (
> https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf) ...

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message