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!
