Re: copy files to servers

I’m implying the existence of a application descriptor (configuration, annotations, etc) in the resource bundle :-) Anthony > On Jan 6, 2017, at 1:11 PM, John Blum wrote: > > Agreed on the dependencies part, but... "*smart enough to figure out what's > in my bundle*". Hmmm. Beyond recognizin

Re: copy files to servers

Yeah, can't have auto-deploy in production. Maybe we can just fix our current deploy command to not generate errors when used to deploy libraries? -- Mike Stolz Principal Engineer, GemFire Product Manager Mobile: 631-835-4771 On Mon, Jan 9, 2017 at 11:18 AM, Jason Huynh wrote: > Wes, I think

Re: copy files to servers

Wes, I think that is why they suggest turning this dynamic deployment stuff off for production... Development vs Production It is recommended that peer-class-loading is disabled in production. Generally you want to have a controlled production environment without any magic. To deploy your classes

Re: copy files to servers

This seems dangerous to me as a client could send malicious code for execution to all servers. Geode requires an administrative step to do gfsh> deploy --jar=..., that provides a control step that theoretically should check a malicious client. As for third-party jars, they do the same as what we'r

Re: copy files to servers

Oh, nevermind... I just read the section under "3rd Party Libraries." It's still cool though. On Fri, Jan 6, 2017 at 6:15 PM, Kirk Lund wrote: > That's very cool! I look forward to seeing how they dynamically pull in > remote transitive dependencies over the wire such as Spring, JDBC drivers >

Re: copy files to servers

That's very cool! I look forward to seeing how they dynamically pull in remote transitive dependencies over the wire such as Spring, JDBC drivers and other libraries that deployed classes reference and use. That sounds tricky!

Re: copy files to servers

Btw, I'm sure a comparison of capabilities with Ignite will come up at some point. So here's what they do in this department (which I personally find really cool): http://apacheignite.gridgain.org/v1.0/docs/zero-deployment Thanks, Roman. On Fri, Jan 6, 2017 at 12:11 PM, Anthony Baker wrote: >

Re: copy files to servers

@Mike- *> Does all this stuff get easier if we actually create a Spring Boot application that embeds Geode server functionality?* This is a loaded question. At development-time, yes, much easier, I think. You can even leverage *Spring Boot* DevTools

Re: copy files to servers

@Dan- `deploy resource` is like `deploy jar` today, but *without* the additional steps of constructing/initializing and (possibly) registering GemFire objects (which currently only handles Functions today). The idea is, a user may not want the same objects applied to all servers/nodes in the clus

Re: copy files to servers

Does all this stuff get easier if we actually create a Spring Boot application that embeds Geode server functionality? -- Mike Stolz Principal Engineer, GemFire Product Manager Mobile: 631-835-4771 On Fri, Jan 6, 2017 at 4:11 PM, John Blum wrote: > *@Anthony-* > > *> The server should be smart

Re: copy files to servers

*@Anthony-* *> The server should be smart enough to figure out what's in my bundle and understand how to deploy it including any dependencies* Agreed on the dependencies part, but... "*smart enough to figure out what's in my bundle*". Hmmm. Beyond recognizing Geode/GemFire objects/interfaces, I

Re: copy files to servers

We need to take a lesson from any modern Java application an embrace class loader modularization. The only thing in the system class path should be very minimal bootstrap jar. The rest of our needs should be addressed by well organized and isolated class loaders. The deployment of a function, or s

Re: copy files to servers

I don't understand the difference between this proposal: > gfsh> deploy resource --name=myApplicationDependencies.jar > gfsh> deploy cache-writer --name=x.y.z.MyApplicationCacheWriter --members=serverX And this example, which you can already do today: gfsh> depoy --jar=myApplicationStuff.jar gfs

Re: copy files to servers

Hmmm, I agree with Udo. I’d like to push a new version of my application with a single idempotent command. The server should be smart enough to figure out what's in my bundle and understand how to deploy it including any dependencies (because who writes dependency-free code?). I do want som

Re: copy files to servers

@Luke- *> if my CacheWriter had depenancies of its own, would the expectation be I bundle them as a fat jar and use the explict deploy cachewriter command?* Yes, I would envisions something like this... gfsh> deploy resource --name=myApplicationDependencies.jar gfsh> deploy cache-writer --name

Re: copy files to servers

+1 I like no ambiguity On Fri, Jan 6, 2017 at 11:28 AM Luke Shannon wrote: > +1 on John's suggestion for explict commands > > > > On Jan 6, 2017 2:20 PM, "John Blum" wrote: > > > > How about... > > > > * deploy function > > * deploy cache-listener > > * deploy cache-loader > > * deploy cache-lo

Re: copy files to servers

In some ways that is a great idea but sometimes too explicit... Do we expect them to have fine grained jars? Also how do we handle dependencies as a single util class might be used by both a cache-listener and a partition listener... is the expectation that we update the dependent util c

Re: copy files to servers

One question John, if my CacheWriter had depenancies of its own, would the expectation be I bundle them as a fat jar and use the explict deploy cachewriter command? On Jan 6, 2017 2:28 PM, "Luke Shannon" wrote: > +1 on John's suggestion for explict commands > > On Jan 6, 2017 2:20 PM, "John Blu

Re: copy files to servers

+1 on John's suggestion for explict commands On Jan 6, 2017 2:20 PM, "John Blum" wrote: How about... * deploy function * deploy cache-listener * deploy cache-loader * deploy cache-loader * deploy resource (jar, xml, properties, etc) * etc. Might as was make it explicit. For instance, I may ha

Re: copy files to servers

1 more thing + correction 1 of the `deploy cache-loader` was meant to be `deploy cache-writer`. Additionally, I may want to target certain Functions, Listeners, Loader, Writers, etc, all separately at particular members as in... gfsh> deploy function --name=F1 --members='server1, server2, server

Re: copy files to servers

How about... * deploy function * deploy cache-listener * deploy cache-loader * deploy cache-loader * deploy resource (jar, xml, properties, etc) * etc. Might as was make it explicit. For instance, I may have a JAR file I just deployed (uploaded) that contains Functions, Listeners, Loaders, Write

Re: copy files to servers

With appropriate constraints, a copy file type command could be secure. 1) don't use Apache Geode without security AND make the command require authorization permissions 2) limit the target directory to a directory under the working directory of the remote server 3) rename it to "deploy resource"

Re: copy files to servers

The problem is always tricky when you are working with dependencies and class loading. It is a two part problem. 1. First, you must acquire and deploy the dependencies an application will need at runtime. This can be achieved many different ways, such as by "copying" files to a designated, well

Re: copy files to servers

Even though Apache Geode is accepting jars containing Geode callback implementations (Functions, CacheListener, etc), it's NOT a container or application server. You can WANT it to be a container or EXPECT it to be a container but it's not ;) This would require Apache Geode becoming an application

Re: copy files to servers

Here’s a use-case I’m dealing with right now: A single cluster supporting multiple applications (i.e. a multi-tenant cluster). One new application wants to do Spring http session replication. This requires placing 3 Spring jars onto the start server —classpath=$SPRING_JARS:… It requires a clust

Re: copy files to servers

Got to chime in here and +1 on what Anthony's and Jake's sentiments are. Let's be *very* careful and try to understand what users are trying to achieve. If we're providing a 'gfsh cp' option that then requires further intervention to actually achieve what the user wants (i.e. server restart or wh

Re: copy files to servers

I think I can see the benefit of this feature. If you have Geode running in the cloud, it is easier to have a single management tool that can copy resource files to all the servers within the cluster. Although I would not see this a feature I'd promote, as it could really be abused, I believ

Re: copy files to servers

So maybe a generic copy command is too insecure, I agree. What we should do is think about exactly what files we think we are trying to deploy. 1. I believe that there is a need to deploy dependency jars into the system classpath. 2. I believe that there is also a desire to be able to dep

Re: copy files to servers

Agree with Anthony. A copy command would either duplicate what deploy does by only putting files within as specific location in the server's directory or creating a security nightmare if allowed to write anywhere on the host. On Fri, Jan 6, 2017 at 7:56 AM Anthony Baker wrote: > I think there a

Re: copy files to servers

I think there are lots of great OS orchestration and automation tools. I’m not sure I understand the need for `gfsh cp`. If I could easily grab the member hostnames from `gfsh list members` and pipe them into mpssh (for example) that would do the job. I *do* like the idea of an improved `gfsh

Re: copy files to servers

Are you thinking about adding a --destination= command option to tell deploy that it's not a function and where to put it? -- Mike Stolz Principal Engineer - Gemfire Product Manager Mobile: 631-835-4771 On Jan 6, 2017 5:38 AM, "Swapnil Bawaskar" wrote: > Some application may need to copy files t