Re: [PROPOSAL] Public API for Cluster Configuration

Thank you for all the comments/suggestions. I've updated the wiki page with more details and scope of this api. https://cwiki.apache.org/confluence/display/GEODE/Public+API+for+Cluster+Configuration Thanks! On Wed, Mar 14, 2018 at 11:57 AM, John Blum wrote: > *> @Jake, I

Re: [PROPOSAL] Public API for Cluster Configuration

*> @Jake, I vaguely remember that we had once spoken about the concept of nouns and verbs for commands. Maybe this could be a start, understanding what the nouns are and then understand the verbs that should go with them. That might actually start flushing out the configuration services. i.e noun:

Re: [PROPOSAL] Public API for Cluster Configuration

If I understand it correctly, the intended users of this public API are people writing extensions to geode that need to save their own configuration elements, is that correct? It might be good to spell out in a little more detail how that will work. Does CacheConfig have methods that let you add

Re: [PROPOSAL] Public API for Cluster Configuration

+1 to what John said and many are thinking. @Jake, I vaguely remember that we had once spoken about the concept of nouns and verbs for commands. Maybe this could be a start, understanding what the nouns are and then understand the verbs that should go with them. That might actually start

Re: [PROPOSAL] Public API for Cluster Configuration

I echo everything John Said. I also want to throw out that we have a “public api” for config in sorts through gfsh. I am by no means suggesting users programmatically invoke command lines to gfsh but what if we could leverage gfsh as a console terminal app, a Java API, or REST daemon? A common

Re: [PROPOSAL] Public API for Cluster Configuration

John, great points. I updated the wiki page with some bullet points that might address your concerns. Goals - The API is intended to ONLY update the cluster or server-group's configuration saved by the locator(s). For example, when developer uses the api to add a region definition to

Re: [PROPOSAL] Public API for Cluster Configuration

Some initial thoughts after looking over the spec... 1. As a developer (application, API/framework, tool or even a module developer), I really don't care nor should I care what Apache Geode is storing the configuration as under-the-hood. It could be XML, JSON, YAML, a database or even some

Re: [PROPOSAL] Public API for Cluster Configuration

for normal usages, developers will only need to use the updateCacheConfig(groupName, mutator) api, like: service.updateCacheConfig("cluster", cacheConfig->{ cacheConfig.getRegion().add(aRegionConfig); cacheConfig.getAsyncEventQueue().add(aQueue); return cacheConfig; }); Only when module

Re: [PROPOSAL] Public API for Cluster Configuration

Hmm... Jinmei has it right -- that the *Element were for declaring custom XML entries -- but they were only really used during exploration. With this minimal API, we're not actually using those interface-tags in a publicly-visible way... Now I'm torn. On the one hand, it seems a bit strange to

Re: [PROPOSAL] Public API for Cluster Configuration

1. CacheElement/RegionElement are used for custom xml element that are to be added by other modules. They are not meant for those elements defined by cache.xsd already, like region, gatewayreceiver etc. Maybe we should rename it back CustomCacheElement/CustomRegionElement 1. the mutator updates

Re: [PROPOSAL] Public API for Cluster Configuration

I have few comments: 1, What is ClusterElement/RegionElement interfaces used for? 2. I see that using unary mutator one can mutate both cache and region configurations, so the methods in ClusterConfigurationService can be getClusterConfig and updateClusterConfig? The naming is debatable as

Re: [PROPOSAL] Public API for Cluster Configuration

All, I have added a section "Additional Concerns" addressing security and concurrent use of the proposed interface. Imagination is Change. ~Patrick