One question John, if my CacheWriter had depenancies of its own, would the
expectation be I bundle them as a fat jar and use the explict deploy
cachewriter command?
On Jan 6, 2017 2:28 PM, "Luke Shannon" wrote:
> +1 on John's suggestion for explict commands
>
> On Jan 6, 2017 2:20 PM, "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 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 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
> > > 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
> > 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)
>
>
>
