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 explicitly, you can copy them into Ignite libs folder or manually add them to the classpath on every node. On Sun, Jan 8, 2017 at 8:13 PM Wes Williams <wwilli...@pivotal.io> wrote: > 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're discussing: > > > "Our suggestion is to include all 3rd party libraries into class path of > > every node. This can be achieved by copying your JAR files into the > Ignite > > libs folder." > > > As for the dynamical loading and running of Spring jars, let's say that > timeline pressures and money outweigh a small, temporary network > saturation as we distribute Spring jars to the nodes. We then get to the > dynamic loading: > > If class is not locally available, then a request will be sent to the > > originating node to provide class definition. Originating node will send > > class byte-code definition and the class will be loaded on the worker > node. > > This happens only once per class - once class definition is loaded on a > > node, it will never have to be loaded again. > > > I think it's practical. However, iIsn't this potentially dangerous as a > client could intentionally inject malicious code into the grid? Whereas > gfsh> deploy --jar=... gives Operations a control check point that > theoretically can thwart such an attack. > > > > *Wes Williams | Pivotal Advisory **Data Engineer* > 781.606.0325 <(781)%20606-0325> > http://pivotal.io/big-data/pivotal-gemfire > > On Fri, Jan 6, 2017 at 8:46 PM, Roman Shaposhnik <ro...@shaposhnik.org> > wrote: > > > 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 <aba...@pivotal.io> > wrote: > > > 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 some lifecycle hooks to alloc/free resources. This seems > > conceptually similar to the “war” model which is pretty familiar to most > > Java devs. > > > > > > Anthony > > > > > >> On Jan 6, 2017, at 11:37 AM, Udo Kohlmeyer <ukohlme...@pivotal.io> > > wrote: > > >> > > >> 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 class for one but not the > > other.... > > >> > > >> It's a very grey area.... > > >> > > >> On 1/6/17 11:19, 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 have a JAR file I > > just > > >>> deployed (uploaded) that contains Functions, Listeners, Loaders, > > Writers, > > >>> etc but I only want to deploy functions. > > >>> > > >>> Having 1 uber "deploy" command with many options gets cumbersome. > > >>> > > >>> It is a simple matter to introduce multiple command but have those > > commands > > >>> share similar logic. This would also enable different workflows for > > >>> different commands in a more non-convoluted, maintainable way. > > >>> > > >>> These could be matched with corresponding `undeploy` commands. > > >>> > > >>> Food for thought, > > >>> > > >>> John > > >>> > > >>> > > >>> > > >>> On Fri, Jan 6, 2017 at 11:11 AM, Kirk Lund <kl...@apache.org> wrote: > > >>> > > >>>> 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" so people don't expect it to copy > > to an > > >>>> arbitrary target directory on the remote machine > > >>>> > > >>>> Back to "deploy jar": > > >>>> > > >>>> The deploy command is only for deploying Apache Geode callbacks > > (Function, > > >>>> CacheListener, etc). "deploy resource" such Spring jars or Spring > xml > > files > > >>>> or anything similar does not overlap with "deploy jar". There is > > continued > > >>>> confusion over what "deploy jar" is or does. I propose we rename it > to > > >>>> "deploy functions" or "deploy callbacks" or something along those > > lines to > > >>>> end the confusion. > > >>>> > > >>>> On Fri, Jan 6, 2017 at 8:13 AM, Michael Stolz <mst...@pivotal.io> > > wrote: > > >>>> > > >>>>> 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 deploy > > Spring > > >>>>> Data Geode xml configuration files. > > >>>>> 3. There is also an issue with attempting to deploy Spring Data > > Geode > > >>>>> functions that we should try to work out. > > >>>>> > > >>>>> Anything else that anyone is aware of? > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> -- > > >>>>> Mike Stolz > > >>>>> Principal Engineer, GemFire Product Manager > > >>>>> Mobile: 631-835-4771 <(631)%20835-4771> > > >>>>> > > >>>>> On Fri, Jan 6, 2017 at 10:59 AM, Jacob Barrett < > jbarr...@pivotal.io> > > >>>>> wrote: > > >>>>> > > >>>>>> 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 <aba...@pivotal.io> > > >>>> wrote: > > >>>>>>> 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 deploy` that supports > hot > > >>>>>> deploy > > >>>>>>> and reconfiguration. > > >>>>>>> > > >>>>>>> Anthony > > >>>>>>> > > >>>>>>>> On Jan 6, 2017, at 2:38 AM, Swapnil Bawaskar < > > sbawas...@pivotal.io > > >>>>>>> wrote: > > >>>>>>>> Some application may need to copy files to all the servers. > These > > >>>>> files > > >>>>>>>> could either be data files or they could be configuration files > > >>>>> needed > > >>>>>> by > > >>>>>>>> the application or they could be jar files (that don't have > > >>>> functions > > >>>>>> but > > >>>>>>>> have say, spring data geode jar files) that need to be on the > > >>>>> server's > > >>>>>>>> classpath. > > >>>>>>>> We could accomplish this by enhancing the current gfsh "deploy" > > >>>>> command > > >>>>>>> to > > >>>>>>>> accept any kind of file and write it to the servers file system > OR > > >>>>>>> create a > > >>>>>>>> new gfsh "copy" command to copy any arbitrary file to the > servers. > > >>>>>>>> I would personally like to repurpose the deploy command but > would > > >>>>> like > > >>>>>> to > > >>>>>>>> hear the community's opinion. > > >>>>>>>> > > >>>>>>>> Thanks! > > >>>>>>> > > >>> > > >>> > > >> > > > > > >
