ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Setrakyan <dsetrak...@apache.org>
Subject Re: automatically deploying user libraries
Date Tue, 28 Jul 2015 08:47:54 GMT
Hm...

I actually don't like the complexity of creating a DeploymentProvider for
every deployment source. How about we just use URI-like approach?

git://my.git.repository/master
svn://...
file:///....
mvn:my.maven.artifact
etc...

This way we can simply have a collection of URIs as a parameter to the
deploy method. At implementation level we can have a different
DeploymentProvider for each deployment protocol we support.

D.

On Mon, Jul 27, 2015 at 5:43 PM, Valentin Kulichenko <
valentin.kulichenko@gmail.com> wrote:

> On Mon, Jul 27, 2015 at 12:32 PM, Alexey Goncharuk <
> alexey.goncharuk@gmail.com> wrote:
>
> > I like the idea, however I do not like the API.
> >
> > Why do we need to limit deployment process to a list of files or GIT
> > repositories? What if I want to build artifacts from Mercurial using
> > gradle? I think the entity that provides artifacts should be an interface
> > and Ignite should provide an out-of-the-box set of builders that can
> fetch
> > files or Maven artifacts or build GIT repos with pom files.
> >
> >
> Agree. deploy() method should take smth like DeploymentProvider interface
> with getArtifacts() method. We can also add it as a configuration property
> to apply automatically on startup.
>
> I'm also not sure about -deploy option for ignite.sh. It seems to me that
> deployment should be used by an application that deployed it. What can a
> standalone node do with it?
>
>
> > Besides the API, we should describe how the deployment process interacts
> > with other Ignite subsystems. For example, once artifacts are deployed,
> > they should be made available on joining nodes on early stages of
> > discovery, so that dynamic cache start feature can use those classes to
> > instantiate cache store. Should we provide a method to undeploy
> artifacts?
> > If yes, we should gracefully clean up all components that may have used
> > deployed code: stop caches, distributed services, tasks. Looks like
> > deploy() should return an instance of Ignite which has a deployment
> > context, and deployed classes should be made available only for method
> > invocations made on that particular Ignite instance.
> >
>
> I think ability to redeploy (and therefore undeploy) is a must here.
> Otherwise you will need to restart the cluster each time you have changes.
> This makes the feature useless.
>
>
> >
> > --AG
> >
> > 2015-07-27 11:49 GMT-07:00 Valentin Kulichenko <
> > valentin.kulichenko@gmail.com>:
> >
> > > +1 for the feature. Looks like really good usability enhancement.
> > >
> > > -Val
> > >
> > > On Sun, Jul 26, 2015 at 10:31 PM, Dmitriy Setrakyan <
> > dsetrakyan@apache.org
> > > >
> > > wrote:
> > >
> > > > Igniters,
> > > >
> > > > So far Ignite deployment process left it up to a user to deploy all
> the
> > > > libraries on all the nodes manually, before a node can even be
> started
> > > up.
> > > >
> > > > What about adding *Ignite.deploy(...)* method that could do the
> > > deployment
> > > > automatically? As parameters to this method, it could receive either
> a
> > > URI
> > > > of the user archives, a GIT repository, or Maven repositories and
> > > > artifacts.
> > > >
> > > > I have described the design here:
> > > > https://issues.apache.org/jira/browse/IGNITE-1160
> > > >
> > > > Please provide comments on whether you think this functionality is
> > useful
> > > > or sufficient.
> > > >
> > > > D,
> > > >
> > >
> >
>

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