@Mike- *> Does all this stuff get easier if we actually create a Spring Boot application that embeds Geode server functionality?*
This is a loaded question. At development-time, yes, much easier, I think. You can even leverage *Spring Boot* DevTools <http://docs.spring.io/spring-boot/docs/1.4.3.RELEASE/reference/htmlsingle/#using-boot-devtools> [1] (for examle <http://docs.spring.io/spring-boot/docs/1.4.3.RELEASE/reference/htmlsingle/#howto-reload-java-classes-without-restarting> [2]). If Geode is a separate service (as is the case in PCF), then not really. You still have the same problems, i.e. how to keep your application in-sync with your "external" services, which might also share or need the same dependencies. But then, to be fair, *Spring Boot* apps are typically deployed as "cache clients" consuming a separate Geode/GemFire service (i.e. the traditional client/server approach). It's just easier to configure, bootstrap and deploy a *Spring Boot* application (that uses *Spring* config), which might also happen to be a peer (embedded Geode/GemFire UC). An app is a single, self-contained, testable, and deployable unit, and "currency" in a cloud environment. I can scale it up or down by initiating more instances of my app. These apps can form a Geode/GemFire cluster, even within a managed environment, that is all architected/organized from the perspective of the app. This moves you closer to a pure microservices model, where each individual app/service technically has it's own data store. Though in our hybrid, mutated model our apps would share the data store since all the same *Spring Boot* apps would/could form a cluster in Geode/GemFire. One advantage of this hybrid approach is you achieve strong consistency along with availability in a highly distributed manner, where the pure microservices approach emphases availability over consistency. We don't pitch/recommend this approach in practice, TMK. There are certainly tradeoffs, particularly if you thing about JVM heap, or what it actually means for an app to be a member in the cluster, subject to all the responsibilities and consequences that come with it. -John [1] http://docs.spring.io/spring-boot/docs/1.4.3.RELEASE/reference/htmlsingle/#using-boot-devtools [2] http://docs.spring.io/spring-boot/docs/1.4.3.RELEASE/reference/htmlsingle/#howto-reload-java-classes-without-restarting On Fri, Jan 6, 2017 at 1:41 PM, John Blum <jb...@pivotal.io> wrote: > @Dan- > > `deploy resource` is like `deploy jar` today, but *without* the > additional steps of constructing/initializing and (possibly) registering > GemFire objects (which currently only handles Functions today). > > The idea is, a user may not want the same objects applied to all > servers/nodes in the cluster, especially if all their application artifacts > and dependencies are all uploaded in 1 JAR (which is as it should be, but > technically, is an application developers design decision, IMO). > > For instance, a Function does not (and perhaps, should not) necessarily be > deployed on every single node in the cluster. And by "deploy" I really > mean "applied"; not whether the bits physically exists or not. In fact, > the bits should exist on all nodes in case the user wants to deploy/apply > the Function, Listener, or whatever, to another existing, or possibly new > node in the cluster. > > The same might be true of a Loader or Writer, though I don't recall > whether Geode may think the Region configuration conflicts in this case if > all nodes hosting the Region do not have the same Listeners, Loader and > Writer configured???. > > Anyhow... perhaps "deploy" is the wrong terminology as I did not mean > that each individual `deploy` command: `deploy function`, `deploy > cache-listener`, etc, "uploads" artifacts; NO, yuck! Only `deploy > resource`, or rather `upload resource` would. > > SIDE NOTE: We keep talking about containers as if they just handle class > loading or something. That is not all that is required to be a container, > much less, a completely "managed" environment (which PCF has covered)!. > Class loading is an implementation detail. It would have been easier if > containers just forked individual JVM processes, IMO (some do). Spring XD > switched from class loading to individual JVM processes in SCDF. This class > loading business is highly error prone, and, well, overly complicated to > get right in all situations. > > In addition, you cannot be a proper container without an SPI or extension > points to customize lifecycle, scope, events, etc, all the things > application components need in a managed environment. > > > On Fri, Jan 6, 2017 at 1:34 PM, Michael Stolz <mst...@pivotal.io> wrote: > >> Does all this stuff get easier if we actually create a Spring Boot >> application that embeds Geode server functionality? >> >> -- >> Mike Stolz >> Principal Engineer, GemFire Product Manager >> Mobile: 631-835-4771 >> >> On Fri, Jan 6, 2017 at 4:11 PM, John Blum <jb...@pivotal.io> wrote: >> >> > *@Anthony-* >> > >> > *> The server should be smart enough to figure out what's in my bundle >> and >> > understand how to deploy it including any dependencies* >> > >> > Agreed on the dependencies part, but... "*smart enough to figure out >> what's >> > in my bundle*". Hmmm. Beyond recognizing Geode/GemFire >> > objects/interfaces, I don't see how this is likely. >> > >> > For instance, I recently added the ability (SGF-106 >> > <https://jira.spring.io/browse/SGF-106> [1]) in SDG to create Indexes >> > using >> > Annotations on application domain objects/entities properties/fields >> when >> > using the SDG mapping support >> > <http://docs.spring.io/spring-data-gemfire/docs/current/ >> > reference/html/#mapping> >> > [2] >> > (and SD *Repositories*). Currently, Geode/GemFire does not even >> recognize >> > SDG "defined" (annotated) Functions. How is it going to know (or how I >> am >> > I going tell it) about Index annotations now, or something else. Of >> > course, Geode/GemFire could delegate to the *Spring* container in both >> > instances, but that does not cover cases where *Spring* is not used. >> > >> > [1] https://jira.spring.io/browse/SGF-106 >> > [2] >> > http://docs.spring.io/spring-data-gemfire/docs/current/ >> > reference/html/#mapping >> > >> > >> > On Fri, Jan 6, 2017 at 12:49 PM, Jacob Barrett <jbarr...@pivotal.io> >> > wrote: >> > >> > > We need to take a lesson from any modern Java application an embrace >> > class >> > > loader modularization. The only thing in the system class path should >> be >> > > very minimal bootstrap jar. The rest of our needs should be addressed >> by >> > > well organized and isolated class loaders. >> > > >> > > The deployment of a function, or set of functions, should operate in a >> > > fully isolated class loader. The deployment should include all >> > dependencies >> > > except for the APIs provided by the Geode framework. >> > > >> > > -Jake >> > > >> > > 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 <(631)%20835-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) > -- -John john.blum10101 (skype)
