Geode unit tests completed in 'develop/IntegrationTest' with non-zero exit code
Pipeline results can be found at: Concourse: https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/IntegrationTest/builds/285
[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #857 was SUCCESSFUL (with 2379 tests)
--- Spring Data GemFire > Nightly-ApacheGeode > #857 was successful. --- Scheduled 2381 tests in total. https://build.spring.io/browse/SGF-NAG-857/ -- This message is automatically generated by Atlassian Bamboo
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 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: region verb: create, update, destroy, clear* > > This was exactly the intent behind the Management REST-like API when it was > designed, i.e. proper resource abstractions such as *Regions*, *Indexes*, > *DiskStores*, etc along with actions on the resources (with REST over HTTP, > the verbs being: POST, GET, PUT/PATCH, DELETE) and eventually hypermedia > controls to allow for a discoverable API (by tooling, for instance). > However, on the *Richardson's Maturity Model*, it never quite reached full > maturity since the initial intent was to just provide an HTTP tunnel > between > *Gfsh* and the Apache Geode *Manager*. However, it would not have been so > much work to continue down that path if the Management REST API had not > changed as it has now. It was also language neutral. > > I do have more thoughts on our (ab)use/notion of "internal" API(s), but I > will save it for another thread/time as it does not directly relate to this > topic. In a nutshell, it is concerned with putting interfaces and classes > in "internal" packages and claiming they are for internal use only, when > occasionally, there is no public API to accomplish the task at hand. Also, > you don't need something heavy like OSGi, or even Java 9 modules, to > properly enforce truly internal APIs either. Finally, I would argue that > most things (if not all) should just be in the public API, i.e. with proper > interfaces (APIs and/or SPIs) no one should really have to worry about > accessing "implementation" classes. > > Regards, > John > > > > On Wed, Mar 14, 2018 at 11:40 AM, Dan Smith wrote: > > > 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 extension elements? > > > > The section on concurrency seems a bit hand-wavy. What specifically is > the > > API guaranteeing? That the cluster configuration will be consistent on > all > > locators and it will be the result of the last write? When do I need to > use > > a distributed lock? > > > > -Dan > > > > > > > > On Wed, Mar 14, 2018 at 9:17 AM, Jacob Barrett > > wrote: > > > > > 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 interface/command > set > > to > > > rule them all. It is not fun as a plug-in developer to have to > implement > > > multiple interfaces for multiple configuration systems. > > > > > > The other thing I’ll toss out is rather than rework what we have how > > about > > > replacing it all with something already mature. There are many other > open > > > source projects that have solved the configuration problem. Let’s not > > > reinvent the wheel here. > > > > > > -Jake > > > > > > > > > > > > > On Mar 13, 2018, at 1:59 PM, John Blum wrote: > > > > > > > > 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 configuration > > > server. > > > > It is an implementation detail and I simply don't care; i.e. nothing > in > > > the > > > > interface or types should suggest otherwise. I am not saying this is > > the > > > > case now, just to be mindful of this when refining this API. > > > > > > > > Things like... > > > > > > > > 1.1. "... *as well as injection of elements into the cache and region > > > > levels of the cluster configuration.*" > > > > 1.2. "*Define a no-op interfaces CacheElement and RegionElement to > > > identify > > > > classes that may be saved to the cache and region XML entities*" > > > > 1.3. "*Leverage JAXB to generate an initial set of configuration > > > objects.*" > > > > > > > > .. are dangerously suspicious. > > > > > > > > > > > > 2. "*Expose ClusterConfigurationService via the cache, provided a > > locator > > > > is managing that cache.*" > > > > > >
Re: [PROPOSAL] use default value for validate-serializable-objects in dunit
+0.5 I think we can turn this off (back to the default) now since the AnalyzeSerializables tests for other modules have been created. These tests ensure that serializable objects are properly white-listed or excluded and are able to be serialized/deserialized. Excluded classes are not tested, though, so if you add an excluded class and are wrong about whether it is sent over the wire you will break Geode. Having serialization validation enabled in dunit tests protects against this if you write tests that use the excluded class. We also have non-default values for cluster configuration in dunit runs. On 3/13/18 10:03 AM, Kirk Lund wrote: I want to propose using the default value for validate-serializable-object in dunit tests instead of forcing it on for all dunit tests. I'm sympathetic to the reason why this was done: ensure that all existing code and future code will function properly with this feature enabled. Unfortunately running all dunit tests with it turned on is not a good way to achieve this. Here are my reasons: 1) All tests should start out with the same defaults that Users have. If we don't do this, we are going to goof up sometime and release something that only works with this feature turned on or worsen the User experience of Geode in some way. 2) All tests should have sovereign control over their own configuration. We should strive towards being able to look at a test and determine its config at a glance without having to dig through the framework or other classes for hidden configuration. We continue to improve dunit in this area but I think adding to the problem is going in the wrong direction. 3) It sets a bad precedent. Do we follow this approach once or keep adding additional non-default features when we need to test them too? Next one is GEODE-4769 "Serialize region entry before putting in local cache" which will be disabled by default in the next Geode release and yet by turning it on by default for all of precheckin we were able to find lots of problems in both the product code and test code. 4) This is already starting to cause confusion for developers thinking its actually a product default or expecting it to be enabled in other (non-dunit) tests. Alternatives for test coverage: There really are no reasonable shortcuts for end-to-end test coverage of any feature. We need to write new tests or identify existing tests to subclass with the feature enabled. 1) Subclass specific tests to turn validate-serializable-object on for that test case. Examples of this include a) dunit tests that execute Region tests with OffHeap enabled, b) dunit tests that flip on HTTP over GFSH, c) dunit tests that run with SSL or additional security enabled. 2) Write new tests that cover all features with validate-serializable-object enabled. 3) Rerun all of dunit with and without the option. This doesn't sound very reasonable to me, but it's the closest to what we really want or need. Any other ideas or suggestions other than forcing all dunit tests to run with a non-default value? Thanks, Kirk
Re: [PROPOSAL] use default value for validate-serializable-objects in dunit
+1 agreement with Kirk and Sean. Any non default configuration should probably have it's own set of tests. I can understand some exploratory work where someone might want to run the whole precheckin with a non default value to help identify areas that they may have missed or are unexpectedly affected. At that point the relevant tests should have been identified and copies of them could be made with the new configuration. On Thu, Mar 15, 2018 at 9:46 AM Sean Goller wrote: > I agree with this. We should have a default state that reflects an “out of > the box” configuration, and if tests expects a different configuration, it > should manage that within the context of the test. > > -Sean > > On Tue, Mar 13, 2018 at 10:04 AM Kirk Lund wrote: > > > I want to propose using the default value for > validate-serializable-object > > in dunit tests instead of forcing it on for all dunit tests. I'm > > sympathetic to the reason why this was done: ensure that all existing > code > > and future code will function properly with this feature enabled. > > Unfortunately running all dunit tests with it turned on is not a good way > > to achieve this. > > > > Here are my reasons: > > > > 1) All tests should start out with the same defaults that Users have. If > we > > don't do this, we are going to goof up sometime and release something > that > > only works with this feature turned on or worsen the User experience of > > Geode in some way. > > > > 2) All tests should have sovereign control over their own configuration. > We > > should strive towards being able to look at a test and determine its > config > > at a glance without having to dig through the framework or other classes > > for hidden configuration. We continue to improve dunit in this area but I > > think adding to the problem is going in the wrong direction. > > > > 3) It sets a bad precedent. Do we follow this approach once or keep > adding > > additional non-default features when we need to test them too? Next one > is > > GEODE-4769 "Serialize region entry before putting in local cache" which > > will be disabled by default in the next Geode release and yet by turning > it > > on by default for all of precheckin we were able to find lots of problems > > in both the product code and test code. > > > > 4) This is already starting to cause confusion for developers thinking > its > > actually a product default or expecting it to be enabled in other > > (non-dunit) tests. > > > > Alternatives for test coverage: > > > > There really are no reasonable shortcuts for end-to-end test coverage of > > any feature. We need to write new tests or identify existing tests to > > subclass with the feature enabled. > > > > 1) Subclass specific tests to turn validate-serializable-object on for > that > > test case. Examples of this include a) dunit tests that execute Region > > tests with OffHeap enabled, b) dunit tests that flip on HTTP over GFSH, > c) > > dunit tests that run with SSL or additional security enabled. > > > > 2) Write new tests that cover all features with > > validate-serializable-object > > enabled. > > > > 3) Rerun all of dunit with and without the option. This doesn't sound > very > > reasonable to me, but it's the closest to what we really want or need. > > > > Any other ideas or suggestions other than forcing all dunit tests to run > > with a non-default value? > > > > Thanks, > > Kirk > > >
Re: [PROPOSAL] use default value for validate-serializable-objects in dunit
I agree with this. We should have a default state that reflects an “out of the box” configuration, and if tests expects a different configuration, it should manage that within the context of the test. -Sean On Tue, Mar 13, 2018 at 10:04 AM Kirk Lund wrote: > I want to propose using the default value for validate-serializable-object > in dunit tests instead of forcing it on for all dunit tests. I'm > sympathetic to the reason why this was done: ensure that all existing code > and future code will function properly with this feature enabled. > Unfortunately running all dunit tests with it turned on is not a good way > to achieve this. > > Here are my reasons: > > 1) All tests should start out with the same defaults that Users have. If we > don't do this, we are going to goof up sometime and release something that > only works with this feature turned on or worsen the User experience of > Geode in some way. > > 2) All tests should have sovereign control over their own configuration. We > should strive towards being able to look at a test and determine its config > at a glance without having to dig through the framework or other classes > for hidden configuration. We continue to improve dunit in this area but I > think adding to the problem is going in the wrong direction. > > 3) It sets a bad precedent. Do we follow this approach once or keep adding > additional non-default features when we need to test them too? Next one is > GEODE-4769 "Serialize region entry before putting in local cache" which > will be disabled by default in the next Geode release and yet by turning it > on by default for all of precheckin we were able to find lots of problems > in both the product code and test code. > > 4) This is already starting to cause confusion for developers thinking its > actually a product default or expecting it to be enabled in other > (non-dunit) tests. > > Alternatives for test coverage: > > There really are no reasonable shortcuts for end-to-end test coverage of > any feature. We need to write new tests or identify existing tests to > subclass with the feature enabled. > > 1) Subclass specific tests to turn validate-serializable-object on for that > test case. Examples of this include a) dunit tests that execute Region > tests with OffHeap enabled, b) dunit tests that flip on HTTP over GFSH, c) > dunit tests that run with SSL or additional security enabled. > > 2) Write new tests that cover all features with > validate-serializable-object > enabled. > > 3) Rerun all of dunit with and without the option. This doesn't sound very > reasonable to me, but it's the closest to what we really want or need. > > Any other ideas or suggestions other than forcing all dunit tests to run > with a non-default value? > > Thanks, > Kirk >
