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