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 17:29:42 GMT
Alexey,

I probably was not clear in my email earlier. I think that
DeploymentProvider is a good abstraction and we should have it. My comment
was that I would like it to be exposed as a URI string vs. "new
DeploymentProvider(...)".

For example, GitDeploymentProvider would be configured as
"git://some.repo?param1=1&param2=2"

As far as our point about Maven repositories, we can think of a way to
expose it artifacts and repo coordinates in a URI string. For example, we
can have "mvn://..." and "mvnrepo://" URIs.

Does this make sense?

D.


On Tue, Jul 28, 2015 at 10:19 AM, Alexey Goncharuk <
alexey.goncharuk@gmail.com> wrote:

> I still do not like this approach. Maven artifacts may require another URL
> for an external repository, now we would have to encode a URI into another
> URI. The git repository may require some settings for a build system, which
> also may not always be expressed in terms of URI parameters.
>
> Besides, if I understood correctly, we should still leave a room for users
> to implement their own provider that will parse an URI and provide
> artifacts, which is the exact interface suggested by Val, but
> getArtifacts() method now has an URI as an argument. But instead of passing
> these providers to deploy() method, we need to set them in configuration.
>
> 2015-07-28 1:47 GMT-07:00 Dmitriy Setrakyan <dsetrakyan@apache.org>:
>
> > 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