+1 I like no ambiguity On Fri, Jan 6, 2017 at 11:28 AM Luke Shannon <lshan...@pivotal.io> wrote:
> +1 on John's suggestion for explict commands > > > > On Jan 6, 2017 2:20 PM, "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) > >
