If you're talking about GFSH commands only... removing JMX manager options from "start server" then that's probably reasonable.
But as John described better than me, I wouldn't make non-dedicated-locators unable to host certain services such as JMX manager or locator. For example, it wasn't easy to remove the restriction that locators couldn't have a cache. Following in that direction again is the wrong way for Geode. On Wed, Feb 21, 2018 at 4:47 PM, John Blum <jb...@pivotal.io> wrote: > 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) >
