glassfish
  1. glassfish
  2. GLASSFISH-14887

Value passed for --nodedir to create-node-config command is not used when the instance is created using create-local-instance

    Details

    • Type: Bug Bug
    • Status: In Progress
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 3.1_b31
    • Fix Version/s: future release
    • Component/s: admin
    • Labels:
      None
    • Environment:

      Linux

      Description

      When creating a simple config that consists of
      DAS
      One additional local node
      One instance found in the additional node

      The --nodedir specified when running asadmin create-node-config is not used at all. Instead, all files are placed under GF home\glassfish\nodes\NODENAME
      The simple steps to reproduce are:
      asadmin create-domain --domaindir /scratch/gfwork/das --savemasterpassword=true my_domain
      asadmin start-domain --domaindir /scratch/gfwork/das my_domain
      asadmin create-node-config --nodedir /scratch/gfwork/node1 node1
      asadmin create-local-instance --node node1 server_one

      After doing the above steps, the node files are actually found at GFInstallDir/glassfish/nodes/node1, instead of /scratch/gfwork/node1

      If the --nodedir argument is added to the asadmin command create-local-instance then the value is used.

      If that is the case, then why does create-node-config have this argument available? It is being ignored when the instance in the node is actually created.

      Furthermore, if one creates a cluster and then creates an instance that is a member of the cluster, the issue above causes the cluster startup to fail because it is actually looking for the node files in the correct place (using abonve DAS):
      asadmin create-node-config --nodedir /scratch/gfwork/node2 node2
      asadmin create-cluster myCluster
      asadmin create-local-instance --node node1 --cluster myCluster server2
      asadmin start-cluster myCluster

      The error from this is:
      server1: Could not start instance server2 on node node2 (myhost).

      Command failed on node node1 (myhost): Command start-local-instance failed.

      Server instance directory /scratch/gfwork/node2/node2/server2 does not exist or is not a directory

      To complete this operation run the following command locally on host myhost from the GlassFish install location /scratch/glassfish3:

      asadmin start-local-instance --node node2 --nodedir /scratch/gfwork/node2 --sync normal server2

      The command start-instance failed for: server12
      Command start-cluster completed with warnings.

        Activity

        Hide
        Nazrul added a comment -

        This is blocking C*Web Testing

        Show
        Nazrul added a comment - This is blocking C*Web Testing
        Hide
        Jennifer Chou added a comment -

        The workaround is either use
        1. create-instance instead of create-local-instance
        2. specify --nodedir in create-local-instance:
        asadmin create-local-instance --node node1 --nodedir /scratch/gfwork/node1 --cluster myCluster server2

        The nodedir is stored on DAS, create-instance is a remote command which can easily get the nodedir from DAS. However, create-local-instance is a local command, which calls a remote command _register-instance on DAS. Then calls a local command _create-instance-fileystem to create the file directories. Currently, there is not an easy way to get the nodedir from DAS and pass it to _create-instance-filesystem.

        Joe suggested having validation check for discrepancy for nodedir and return an error message.

        Show
        Jennifer Chou added a comment - The workaround is either use 1. create-instance instead of create-local-instance 2. specify --nodedir in create-local-instance: asadmin create-local-instance --node node1 --nodedir /scratch/gfwork/node1 --cluster myCluster server2 The nodedir is stored on DAS, create-instance is a remote command which can easily get the nodedir from DAS. However, create-local-instance is a local command, which calls a remote command _register-instance on DAS. Then calls a local command _create-instance-fileystem to create the file directories. Currently, there is not an easy way to get the nodedir from DAS and pass it to _create-instance-filesystem. Joe suggested having validation check for discrepancy for nodedir and return an error message.
        Hide
        Nazrul added a comment -

        Since there is a work-around I am removing the [BLOCKING] tag.

        Show
        Nazrul added a comment - Since there is a work-around I am removing the [BLOCKING] tag.
        Hide
        Joe Di Pol added a comment -

        Two options for 3.1:

        1) As Jennifer said, do a validation check to detect the discrepancy so you get an error when running create-local-instance (without providing the correct --nodedir). Or

        2) Make the --nodedir option to create-node-config hidden and remove it from the console. This would minimize the ability to create the inconsistency.

        Show
        Joe Di Pol added a comment - Two options for 3.1: 1) As Jennifer said, do a validation check to detect the discrepancy so you get an error when running create-local-instance (without providing the correct --nodedir). Or 2) Make the --nodedir option to create-node-config hidden and remove it from the console. This would minimize the ability to create the inconsistency.
        Hide
        Joe Di Pol added a comment -

        To mitigate this bug I've done the following for 3.1:

        Improved the validation that occurs when you run create-local-instance to catch this condition sooner and give an error if you don't specify a nodedir and the config node has a nodedir specified. This was integrated in r43515.

        Filled bug http://java.net/jira/browse/GLASSFISH-15019 on the admin console to hide the nodedir (and other) fields for config nodes since that information will be provided to/by create-local-instance. This is targeted for 3.1.

        Currently we are not planning on removing the CLI options to create-node-config – leaving those for advance use.

        This is all we plan on doing for the 3.1 release, so I'm reducing the priority.

        Show
        Joe Di Pol added a comment - To mitigate this bug I've done the following for 3.1: Improved the validation that occurs when you run create-local-instance to catch this condition sooner and give an error if you don't specify a nodedir and the config node has a nodedir specified. This was integrated in r43515. Filled bug http://java.net/jira/browse/GLASSFISH-15019 on the admin console to hide the nodedir (and other) fields for config nodes since that information will be provided to/by create-local-instance. This is targeted for 3.1. Currently we are not planning on removing the CLI options to create-node-config – leaving those for advance use. This is all we plan on doing for the 3.1 release, so I'm reducing the priority.
        Hide
        jpleau added a comment -

        I noticed this new validation today, however it has a flaw. If the nodedir provided during create-node-config happens to have a symlink in it's path, then the validation fails as the path stored in the node config is the absolute path with the actual filesystem values, however the nodedir provided during create-instance is the symlinked path. You can see this behaviour when looking at the example below:
        asadmin create-domain --domaindir /scratch/gfbugs/testdomain --savemasterpassword=true testdomain
        asadmin start-domain --domaindir /scratch/gfbugs/testdomain testdomain
        mkdir /scratch/gfbugs/nodes
        ln -s /scratch/gfbugs/nodes /scratch/gfbugs/symlinknode
        ls /scratch/gfbugs/ -l
        total 8
        drwxr-xr-x 2 jpleau g900 4096 Dec 9 14:26 nodes
        lrwxrwxrwx 1 jpleau g900 21 Dec 9 14:26 symlinknode -> /scratch/gfbugs/nodes
        drwxr-xr-x 3 jpleau g900 4096 Dec 9 14:24 testdomain
        asadmin create-node-config --nodedir /scratch/gfbugs/symlinknode testnode
        asadmin create-local-instance --node testnode --nodedir /scratch/gfbugs/symlinknode testserver
        org.glassfish.api.admin.CommandException: remote failure: Attribute mismatch for node 'testnode': the value for the 'nodedir' attribute from the command (/scratch/gfbugs/nodes) does not match the value in the DAS configuration (/scratch/gfbugs/symlinknode)
        Command create-local-instance failed.

        This was discovered because in our development env, the work directory is a symlink from the code source view to a local working dir.

        Show
        jpleau added a comment - I noticed this new validation today, however it has a flaw. If the nodedir provided during create-node-config happens to have a symlink in it's path, then the validation fails as the path stored in the node config is the absolute path with the actual filesystem values, however the nodedir provided during create-instance is the symlinked path. You can see this behaviour when looking at the example below: asadmin create-domain --domaindir /scratch/gfbugs/testdomain --savemasterpassword=true testdomain asadmin start-domain --domaindir /scratch/gfbugs/testdomain testdomain mkdir /scratch/gfbugs/nodes ln -s /scratch/gfbugs/nodes /scratch/gfbugs/symlinknode ls /scratch/gfbugs/ -l total 8 drwxr-xr-x 2 jpleau g900 4096 Dec 9 14:26 nodes lrwxrwxrwx 1 jpleau g900 21 Dec 9 14:26 symlinknode -> /scratch/gfbugs/nodes drwxr-xr-x 3 jpleau g900 4096 Dec 9 14:24 testdomain asadmin create-node-config --nodedir /scratch/gfbugs/symlinknode testnode asadmin create-local-instance --node testnode --nodedir /scratch/gfbugs/symlinknode testserver org.glassfish.api.admin.CommandException: remote failure: Attribute mismatch for node 'testnode': the value for the 'nodedir' attribute from the command (/scratch/gfbugs/nodes) does not match the value in the DAS configuration (/scratch/gfbugs/symlinknode) Command create-local-instance failed. This was discovered because in our development env, the work directory is a symlink from the code source view to a local working dir.
        Hide
        schaarsc added a comment -

        the symlink issue described by ipleau in previous comment is relevant for us. From my point of view symlink should not be resolved to real path. should we open new issue, since the name from this issue does not say anything about symlinks?

        Show
        schaarsc added a comment - the symlink issue described by ipleau in previous comment is relevant for us. From my point of view symlink should not be resolved to real path. should we open new issue, since the name from this issue does not say anything about symlinks?
        Hide
        Joe Di Pol added a comment -

        I've created this bug to cover the symlink issue. Feel free to comment on it if you have anything else to add:

        GLASSFISH-15889 Node path validation does not handle symlinks correctly

        Show
        Joe Di Pol added a comment - I've created this bug to cover the symlink issue. Feel free to comment on it if you have anything else to add: GLASSFISH-15889 Node path validation does not handle symlinks correctly

          People

          • Assignee:
            Joe Di Pol
            Reporter:
            jpleau
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated: