IZ589: Two default systems can coexist and one may mask the other

[afisch]

[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