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 <jhu...@pivotal.io> wrote: > 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! > > > >>>>>>> > > > >>> > > > >>> > > > >> > > > > > > > > > >
