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, server3'; gfsh> deploy cache-loader --name=L1 --members='server10'; -j On Fri, Jan 6, 2017 at 11:19 AM, John Blum <jb...@pivotal.io> 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! >> > > > >> > > > >> > > >> > >> > > > > -- > -John > john.blum10101 (skype) > -- -John john.blum10101 (skype)
