Opened 51 years ago
Last modified 10 years ago
#895 new defect
IZ589: Two default systems can coexist and one may mask the other
Reported by: | afisch | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | hedeby | Version: | 1.0u1 |
Severity: | Keywords: | Sun cli | |
Cc: |
Description
[Imported from gridengine issuezilla http://gridengine.sunsource.net/issues/show_bug.cgi?id=589]
Issue #: 589 Platform: Sun Reporter: afisch (afisch) Component: hedeby OS: All Subcomponent: cli Version: 1.0u1 CC: None defined Status: NEW Priority: P3 Resolution: Issue type: DEFECT Target milestone: 1.0u5next Assigned to: adoerr (adoerr) QA Contact: adoerr URL: * Summary: Two default systems can coexist and one may mask the other Status whiteboard: Attachments: Issue 589 blocks: Votes for issue 589: Vote for this issue Opened: Mon Nov 3 03:53:00 -0700 2008 ------------------------ Description: The problem arises if two sdm instances with same name (dummySystem) but different pref type exist and the user mode instance is set as default (set_default_bootstrap_config). The show_bootstrap_config command lists the two instances and flags both with default. % ./sdmadm -s dummySystem -p user set_default_bootstrap_config WARNING: Host dummy is not resolvable WARNING: Host dummy is not resolvable Default system set to 'dummySystem' % ./sdmadm show_bootstrap_config WARNING: Host xyz is not resolvable WARNING: Host dummy is not resolvable system type host port properties version --------------------------------------------------------------------- dummySystem SYSTEM xyz 2 default 1.0u2 USER dummy 1 default 1.0u2 Furthermore, the cli uses the instance with pref type system as "active" default, although default is set for pref type user. This can be deduced from the warning messages in the example below. See the complain about a not resolvable host xyz (Fake cs host of the instance with pref type system): ./sdmadm show_components WARNING: Host xyz is not resolvable WARNING: Host xyz is not resolvable Error: Cannot connect to jvm cs_vm@xyz: Failed to retrieve RMIServer stub: javax.naming.ConfigurationException [Root exception is java.rmi.UnknownHostException: Unknown host: xyz; nested exception is: java.net.UnknownHostException: xyz] Evaluation: The issue is rated as p3 defect. A workaround exists. However it might be not too obvious from the error message provided. Suggested fix / work around: Fix: Given the case that the default system is ambigous, as described above. Any command (for example show_components) that need the system name should fail if no system name is explicitly provided via -s or env variable.The command should state that the system name is ambiguous. The command remove_bootstrap_config already works like this: ./sdmadm remove_bootstrap_config WARNING: Host xyz is not resolvable WARNING: Host xyz is not resolvable Error: Non ambiguous system name 'dummySystem'. Please use the --prefs option (BTW: The "Non ambigous.." typo is allready addressed in issue 587. ) Additionally the default property should be automatically removed and it should be printed: "The system "dummySystem" was flagged as default but it is ambiguous. The default flag has been removed." The show_bootstrap_config command should list no default flag in case that it is ambiguous, remove any ambiguous default flag and report it in the same way. Workaround: Explicity use the prefType option to clarify which instance is ment. Analysis: The problem with the double entry is rooted in: com.sun.grid.grm.cli.cmd.monitoring.ShowConfigsCliCommand#158-#180 If no pref type is provided the show command collects all elements from both bootstrap dirs. Then it asks for the default system name and marks all matches as default. The current code does not allow to find out which the original intended system name was. Thus the code should check if two entries exist and clear the default in this case as described before and list no default at all. The problem with the ambiguouity detection should be addressed with a resolveSystem() routine that can be called from other commands in a convinient way. It should find out the system name and preference type and cover all scenarios of possible identifications and react accordingly. system name provided (-s|env variable|default) pref type provided (-p|not provided) ambigous system name (yes|no) The routine should be reused in the set of commands like show_components that suffer from this resolving problem. How to test: The new method to resolve the system should be tested with a jUnit test that covers all combinations of provided identifications (see above). Additionally there should be a TS test for show_bootstrap_config, show_components and any other command that uses the new routine. ETC: 4.0 + x PD { 1 PD for new resolve routine 0.5 PD for Junit test 0.5 PD fixing show_bootstrap_config and show_components 1 PD for TS tests x PD for fixes & tests of other commands } ------- Additional comments from afisch Wed Nov 5 10:10:02 -0700 2008 ------- The issue should be fixed together with issue 597 and 598. ------- Additional comments from rhierlmeier Wed Nov 25 07:21:11 -0700 2009 ------- Milestone changed
Note: See
TracTickets for help on using
tickets.