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