What you described is a consequence of its current design/implementation, a tightly coupled one at that.
* Why does the "Configuration Service" have to be limited to *Locators*? * Likewise, why would a "Management Service" be limited to *Managers*? I think of the later (*Locators/Managers*) as "dedicated processes" assigned with certain "responsibilities" (or functions), primarily "Location-based/aware services" and "Management services", respectively. While processes (in the distributed system) may serve in particular roles and have certain responsibilities, by no means should "Services" be tied to only to dedicated processes; it's a "Service" after all, with its own API and set of provider implementations, etc. Process is context and Service is function, which is also an important distinction with consideration to Security. Expanding on this concept, the Configuration Service could also be charged with providing/serving the current configuration (not just recording it), and both the Configuration Service and Management Service could be grouped together as part of a larger, composite service, like an Administrative Service, since both are indeed related functions to a certain degree. Food for thought, -j On Wed, Feb 21, 2018 at 2:57 PM, Jens Deppe <jde...@pivotal.io> wrote: > One thing that prompted this initial proposal is that our (management and > monitoring) service boundaries, (or one could say APIs), are not well > defined. > > Case in point; we currently have a 'configuration service' which is used to > persist configuration. This service is only available on locators. The > 'management service' (as defined/used by gfsh to manipulate configuration) > can exist on both locators and servers. If it runs on servers then it > suddenly does not have access to the configuration service. > > It almost feels like we need more capabilities around > distributed/discoverable micro-services inside Geode. > > --Jens > > On Wed, Feb 21, 2018 at 10:44 AM, John Blum <jb...@pivotal.io> wrote: > > > Typo; Sorry! > > > > This.. > > > > > I may even launch and connect additional servers using Gfsh within my > IDE > > (or using *Gfsh*) that are connected to my *Boot* server, particularly if > > that *Boot* server also embeds a *Locator*. > > > > should have read... > > > > > I may even launch and connect additional servers *within my IDE* (or > > using > > *Gfsh*) that are connected to my *Boot* server, particularly if that > > *Boot* > > server also embeds a *Locator*. > > > > > > On Wed, Feb 21, 2018 at 10:25 AM, Kirk Lund <kl...@apache.org> wrote: > > > > > Most of the geode developers are working to get rid of singleton calls > > (and > > > next up static code) with the goal of being able to have multiple Cache > > > instances in one JVM. This is to facilitate writing geode and geode > > > application tests in one JVM. This fits in with what John is saying as > > > well. > > > > > > Basically, don't make any changes that are going to make testing more > > > difficult or prevent running everything in geode within one JVM. > > > > > > On Wed, Feb 21, 2018 at 10:12 AM, John Blum <jb...@pivotal.io> wrote: > > > > > > > Hi Jinmei- > > > > > > > > Plain and simple, "development purposes". I can easily debug such a > > > server > > > > when I can launch it from my IDE and I can still inspect the server > > using > > > > *Gfsh*. I may even launch and connect additional servers using Gfsh > > > within > > > > my IDE (or using *Gfsh*) that are connected to my *Boot* server, > > > > particularly if that *Boot* server also embeds a *Locator*. > > > > > > > > Primarily, I just want to be able to run commands that allow me to > > > inspect > > > > the server(s) (e.g. `list members`, `list regions`, `describe > region`, > > > > etc). > > > > > > > > Frequently, and more importantly, I run queries using the `query > > > > --query=...` > > > > command to look at the data sent by clients. > > > > > > > > > > > > 3 questions... > > > > > > > > 1. What is the primary issue (limitations, etc) of supporting an > > embedded > > > > *Manager* on a [cache] server? > > > > > > > > I can understand in production, you don't want to have the additional > > > > responsibility, load or security implications that comes with > exposing > > > the > > > > Management service on a *CacheServer*. However, I would argue the > same > > > > thing for a *Locator*. If the *Locator(s)* go down because they were > > > > overloaded by Management responsibilities, that has dire consequences > > for > > > > the cluster. E.g. I can no longer add members, clients may no longer > > be > > > > able to connect (leveraging Single-Hop, Load-Balancing, and other > > > > capabilities) and in a cloud environments (PCF using PCC) where > > > > auto-scaling to the meet demand is critical, service reliability is > at > > > > risk. After all, a *Manager* is "federating" are large amount of > > > meta-data > > > > from other members in the cluster, in memory. > > > > > > > > Therefore, in my production cluster, I would prefer to have dedicated > > > *Data > > > > Nodes*, *CacheServers* (grouped), *Locators* and *Managers*, all > > > separate. > > > > > > > > 2. What's the difference if the *CacheServer* also runs an embedded > > > > *Locator* with Management services running vs a standalone > > > > *Locator/Manager* > > > > ? > > > > > > > > 3. Finally, how did we envision developers doing this during > > development > > > > (I.e. launching servers, debugging, etc)? > > > > > > > > > > > > Again, my desire to want a *CacheServer* with an embedded > > > *Manager/Locator* > > > > is also purely development-driven, for convenience and to iterate > > > quickly, > > > > easily. > > > > > > > > Longer term, 1 of my visions is to improve on IDE support (e.g. with > > > > plugins) that replace things like *Pulse's* *DataBrowser*, being able > > to > > > do > > > > most things inside the IDE instead, along with monitoring > capabilities > > > and > > > > integration with *Spring Boot Actuator*, which is now based on > > > > *Micrometer*, > > > > etc. > > > > > > > > Thanks, > > > > John > > > > > > > > > > > > > > > > On Wed, Feb 21, 2018 at 8:35 AM, Jinmei Liao <jil...@pivotal.io> > > wrote: > > > > > > > > > Hi, John, what's the intended usage of this jmx-manager on the > > > > > cache-server when app developers started a cache-server that way in > > > > spring > > > > > boot? Is that usually for pulse or other jmx client for monitoring > > > > purpose > > > > > mostly? Or they would still want to connect using gfsh and execute > > > bunch > > > > of > > > > > commands to create regions/indexes etc? We are just wondering how > > much > > > > > command support we should do for such jmx-managers. > > > > > > > > > > On Tue, Feb 20, 2018 at 3:05 PM, John Blum <jb...@pivotal.io> > wrote: > > > > > > > > > > > So long as we **never** remove the ability to start an "embedded" > > > > > > *Locator/Manager* in an [application] *CacheServer *process*, > > *which > > > is > > > > > > highly valuable during "*development*". > > > > > > > > > > > > For instance, I may want to spin up an application peer > > *CacheServer* > > > > > > instance > > > > > > with an embedded *Locator/Manager*, like this... > > > > > > > > > > > > https://github.com/jxblum/simplifying-apache-geode-with- > > > > > > spring-data/blob/master/simplifying-apachegeode- > > > > > > springdata-complete/src/main/java/example/app/server/ > > > > > > SpringBootApacheGeodeServerApplication.java > > > > > > > > > > > > Given this simple *Spring Boot *application class, it is real > easy > > to > > > > > form > > > > > > a "*cluster of servers*" also just by changing the run profile > > > > > > configuration in my IDE. > > > > > > > > > > > > Optionally, I should not have to start a *Manager* in my > > > > > application-based > > > > > > *CacheServer* even if I do start an embedded *Locator*. > > > Additionally, > > > > > > while it might be less likely to occur, it is also nice to be > able > > to > > > > > start > > > > > > an application-based *CacheServer* process with an embedded > > *Manager* > > > > > > without having to start a *Locator* if I don't want to, since it > is > > > > still > > > > > > possible to connect to this node using *Gfsh*, like so... > > > > > > > > > > > > gfsh> connect --jmx-manager=localhost[1099] > > > > > > > > > > > > However, the real point is, as an application developer, I should > > not > > > > > have > > > > > > to go outside my IDE and use *Gfsh* to spin up separate > > > > > > *Locator/Manager(s)* > > > > > > and *CacheServer*(s), which is a non-starter for quick, iterative > > > > > > development, particularly if I want to enable *debugging*, which > is > > > > > > significantly more difficult to do with *Gfsh* (not impossible, > but > > > > > > definitely more difficult). *Gfsh* is not a "development" tool. > > > > > > > > > > > > -j > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Cheers > > > > > > > > > > Jinmei > > > > > > > > > > > > > > > > > > > > > -- > > > > -John > > > > john.blum10101 (skype) > > > > > > > > > > > > > > > -- > > -John > > john.blum10101 (skype) > > > -- -John john.blum10101 (skype)
