Update log file names to be prefixed with the namespace

[jeromy-cannon]

Currently, we have two log files on the users machine from which we run Solo:

• ~/.solo/logs/solo.log
• ~/.solo/logs/hashgraph-sdk.log

This will cause problems as we start to support using Solo for multiple deployments from the same machine.

I propose that we prefix the log file name with the namespace which matches the deployment. E.g.: namespace=solo-e2e

• ~/.solo/logs/solo-e2e-solo.log
• ~/.solo/logs/solo-e2e-hashgraph-sdk.log

[JeffreyDallas]

I found in indexts logger was instantiate first

const logger = logging.NewLogger('debug')`

then after manager, include configManager depends on logger, even before argv being parsed and set to flags.

Maybe we could just
do ~/.solo/<name-space/logs

even for other subdirectory cache we could put under ~/.solo<name-space/cache

so each name-space has its own dedicated directory for logs, caches

[jeromy-cannon]

I'm okay with using the as a directory for logs and everything. as you mentioned:

~/.solo/<namespace>/logs/
~/.solo/<namespace>/cache/

I think to get the namespace you will need to either manually parse the argv (could be -n or --namespace, or you will need to run the yargs parsing engine against it using all flags. Not sure how much of a performance hit it is, to use yargs like this.

[JeffreyDallas]

When calling solo cluster setup, it starts to dump logs to solo.log but at the moment, there is no user specific namespace
set yet, we could use clusterNamespace as prefix or subdirectory,
but then we may end up with two solo.log

<cluster_namespace>/solo.log
<user_namespace>solo.log

[jeromy-cannon]

Jeromy Cannon
Today at 18:33
LocalConfig will have currentDeploymentName, which is the same as namespace,

solo/src/core/config/LocalConfig.ts

Line 48 in e049a36

currentDeploymentName : string

Also, see in my PR how I pull from argv early in main:#814

Jeffrey Tang
Today at 19:18
I don't think pull argv early would work, since we only set name space at network deploy step.
solo init
solo cluster setup
solo network deploy -n name_space
so when calling solo init or solo cluster setup we do not know the name space yet.
Maybe this issue 798 should wait until LocalConfig.ts get merged

Jeromy Cannon
Today at 19:27
in the future we will need to connect to or create a deployment first, which will set the namespace earlier. We can put a hold on this until after some of the other work is done if needed. Or, default to a /default/ directory if no namespace is found.

[JeffreyDallas]

While doing some experiment, I found a tricky part.
The flags such as apiPermissionProperties or log4j2xml, those instances would instantiate
even before main function parsing any input arguments.
so their default values would be always using any old/default directory names.

export const apiPermissionProperties: CommandFlag = {
  constName: 'apiPermissionProperties',
  name: 'api-permission-properties',
  definition: {
    describe: 'api-permission.properties file for node',
    defaultValue: path.join(constants.SOLO_CACHE_DIR, 'templates', 'api-permission.properties'),
    type: 'string'
  }
}

export const apiPermissionProperties: CommandFlag = {
  constName: 'apiPermissionProperties',
  name: 'api-permission-properties',
  definition: {
    describe: 'api-permission.properties file for node',
    defaultValue: path.join(getCacheDirectory(), 'templates', 'api-permission.properties'),
    type: 'string'
  }
}

[jeromy-cannon]

While doing some experiment, I found a tricky part. The flags such as apiPermissionProperties or log4j2xml, those instances would instantiate even before main function parsing any input arguments. so their default values would be always using any old/default directory names.

export const apiPermissionProperties: CommandFlag = {
  constName: 'apiPermissionProperties',
  name: 'api-permission-properties',
  definition: {
    describe: 'api-permission.properties file for node',
    defaultValue: path.join(constants.SOLO_CACHE_DIR, 'templates', 'api-permission.properties'),
    type: 'string'
  }
}

export const apiPermissionProperties: CommandFlag = {
  constName: 'apiPermissionProperties',
  name: 'api-permission-properties',
  definition: {
    describe: 'api-permission.properties file for node',
    defaultValue: path.join(getCacheDirectory(), 'templates', 'api-permission.properties'),
    type: 'string'
  }
}

How does this impact the logs referenced in this GH Issue?

[JeffreyDallas]

don't we want to put log/ and cache/ directories under the same namespace directory ?

~/.solo/<namespace>/logs/
~/.solo/<namespace>/cache/

files will be copied to default directory, ~/.solo/<default_name>/cache/

instead of ~/.solo/<namespace>/cache/

because any flags are instantiated before arguments are parsed.

[jeromy-cannon]

This is a good idea. I think that the keys and the profiles should stay with the namespace which ultimately is also the deployment with multi-cluster. Maybe we should open a separate PR though. I think that it requires a bit more design and restructuring to achieve this due to the problems you already mentioned.

[jeromy-cannon]

we could just dump the logs directory under the cache directory. since, cache directory already can be utilized by the user as an override for many subcommands.