ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Boudnik <...@apache.org>
Subject Re: automatically deploying user libraries
Date Tue, 28 Jul 2015 18:20:44 GMT
On Tue, Jul 28, 2015 at 10:29AM, Dmitriy Setrakyan wrote:
> 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"

I am missing a point of doing the git:, svn:, or any other vcs: URI, really.
Checking binaries into a VCS system is very problematic and unclean thing to
do, actually. Why would you encourage that with the proposed API?

> 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?

I'd leave this job to the systems that already doing this and perhaps do it
quite well. Why would you spend time developing your own mvn provider? Esp in
the world that has gradle APIs? I have expressed this pow in the JIRA, so I
will step out now ;)

Cos

> 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
View raw message