HPCC-33182 make all helm examples dropzone subpaths to "mydropzone"

[xwang2713]

There are some inconsistences for dropzone subpath in Helm Charts.
Some use "mydropzone" and the others use "dropzone"
Since our regression tests assume "mydropzone" and to make it consistent "mydropzone" will be used.

There is a seperate JIRA https://hpccsystems.atlassian.net/browse/HPCC-33183 for documentation.

Signed off by [email protected]

Type of change:

• This change is a bug fix (non-breaking change which fixes an issue).
• This change is a new feature (non-breaking change which adds functionality).
• This change improves the code (refactor or other change that does not change the functionality)
• This change fixes warnings (the fix does not alter the functionality or the generated code)
• This change is a breaking change (fix or feature that will cause existing behavior to change).
• This change alters the query API (existing queries will have to be recompiled)

Checklist:

• My code follows the code style of this project.
  • My code does not create any new warnings from compiler, build system, or lint.
• The commit message is properly formatted and free of typos.
  • The commit message title makes sense in a changelog, by itself.
  • The commit is signed.
• My change requires a change to the documentation.
  • I have updated the documentation accordingly, or...
  • I have created a JIRA ticket to update the documentation.
  • Any new interfaces or exported functions are appropriately commented.
• I have read the CONTRIBUTORS document.
• The change has been fully tested:
  • I have added tests to cover my changes.
  • All new and existing tests passed.
  • I have checked that this change does not introduce memory leaks.
  • I have used Valgrind or similar tools to check for potential issues.
• I have given due consideration to all of the following potential concerns:
  • Scalability
  • Performance
  • Security
  • Thread-safety
  • Cloud-compatibility
  • Premature optimization
  • Existing deployed queries will not be broken
  • This change fixes the problem, not just the symptom
  • The target branch of this pull request is appropriate for such a change.
• There are no similar instances of the same problem that should be addressed
  • I have addressed them here
  • I have raised JIRA issues to address them separately
• This is a user interface / front-end modification
  • I have tested my changes in multiple modern browsers
  • The component(s) render as expected

Smoketest:

• Send notifications about my Pull Request position in Smoketest queue.
• Test my draft Pull Request.

Testing:

Tested on Docker Desktop environment. This will fix Regress Quick Test pipe8.ecl with "dropzone" as subpath.

[github-actions]

Jira Issue: https://hpccsystems.atlassian.net//browse/HPCC-33182

Jirabot Action Result:
Workflow Transition To: Merge Pending
Updated PR

[jakesmith]

$ ../helm/examples$ fgrep -R dropzone | fgrep -i subpath
fsx/hpcc-fsx-dynamic-pv/values.yaml:  subPath: dropzone
efs/hpcc-efs-dynamic-pv/values.yaml:  subPath: dropzone
efs/hpcc-efs-static-pv/values.yaml:  subPath: dropzone
esdl/values-hpcc-localfile.yaml:  subPath: dropzone
local/hpcc-localfile/values.yaml:  subPath: dropzone
azure/hpcc-azurefile/values.yaml:  subPath: dropzone
nfs/hpcc-nfs/values.yaml:  subPath: dropzone

all subPath's are currently (before this PR) "dropzone", and I think that's logical
In the same way other planes paths, e.g. data are not 'mydata'.

The prefix paths in the generated example files are not consistent though, i.e.:

/helm/examples$ fgrep -R dropzone | fgrep -i prefix
fsx/values-retained-fsx.yaml:    prefix: "/var/lib/HPCCSystems/mydropzone"
efs/values-retained-efs.yaml:    prefix: "/var/lib/HPCCSystems/mydropzone"
efs/values-auto-efs.yaml:    prefix: "/var/lib/HPCCSystems/mydropzone"
esdl/values-echo-example-localfile.yaml:    prefix: "/var/lib/HPCCSystems/dropzone"
local/values-localfile.yaml:    prefix: "/var/lib/HPCCSystems/mydropzone"
azure/values-auto-azurefile.yaml:    prefix: "/var/lib/HPCCSystems/mydropzone"
azure/values-retained-azurefile.yaml:    prefix: "/var/lib/HPCCSystems/mydropzone"

the only that's right is esdl/values-echo-example-localfile.yaml.
I think it would be more consistent to change these to paths to /var/lib/HPCCSystems/dropzone
OR, drop 'my' altogether, use 'dropzone' for the plane name and the subPath (and hence the prefix too).

[jakesmith]

@xwang2713 - see comment.

[xwang2713]

OK. I will discuss with Attila

[xwang2713]

@AttilaVamos is it OK if we use "dropzone" instead of "mydropzone"? I will make change in helm/examples if you agree

[xwang2713]

If we agree to use "mydropzone" I will update following for esdl:

esdl/values-echo-example-localfile.yaml: prefix: "/var/lib/HPCCSystems/dropzone"
esdl/README.md:2. Create subdirectories named dalistorage, debug, dropzone, esdl\echo-example, hpcc-data, queries and sasha.
esdl/values-hpcc-localfile.yaml: subPath: dropzone

[jakesmith]

The configuration/example files in cloud - should not really adhere to old anacronyms (e.g. "my").
NB: this is trivially unimportant, since these are just example files and there's nothing significantly wrong with it as it is, just a small inconsistenty.
[ from Attila's email, the error he saw was not as a result of the inconsistency, just a slight source of confusion, however, most of the planes in our stock environment do not have (and are not are expected to have) the same tail sub-dirs as their plane names. ]

If a change is going to be made to fix this minor inconsistency, it is better to keep the config/examples clean, and in keeping with no longer having, mydali, mythor etc in general, i.e. not introduce more legacy/BM 'my' baggage.

[xwang2713]

Make change from "dropzone" to "mydropzone" for esdl

[jakesmith]

@xwang2713 - see my previous comments - why are we introducing more 'my'* legacy baggage ? This isn't a change that really needs to be made at all, but if we fix the inconsistency should remove the 'my'*'s not add more.

[xwang2713]

@jakesmith if we don't use "mydropzone" some regress test such as pipe8.ecl since it assume default drop sub path "/var/lib/HPCCSystems/mydropzone". We found this during build verification test. If the storage setup by HPCC cluster which will use values.yaml (mydropzone) the regress run OK which the storage is not persistent. If we want to set up a persistent storage with helm/examples then current sub path of dropzone will be "dropzone" will cause pipe8.ecl test failed. As we find there are too many places in HPCC Platform source use "mydropzone" it is easier to adopt it everywhere in our source and documentation.

[jakesmith]

@jakesmith if we don't use "mydropzone" some regress test such as pipe8.ecl since it assume default drop sub path "/var/lib/HPCCSystems/mydropzone".

pipe8.ecl does not rely on that path. It dynamically gets the actual dropzone path via File.GetDefaultDropZone, see the test ECL:

dropzonePath := File.GetDefaultDropZone() : STORED('dropzonePath');

As @AttilaVamos has pointed out (in an email) and I've pointed out in my previous comments above, the failure was not related to this:

[ from Attila's email, the error he saw was not as a result of the inconsistency, just a slight source of confusion, however, most of the planes in our stock environment do not have (and are not are expected to have) the same tail sub-dirs as their plane names. ]

@xwang2713 - we should either close this PR as it is not really necessary (it is not causing any failures), or conform to consistent standard not using legacy 'my' baggage.

[jakesmith]

dropzonePath := File.GetDefaultDropZone() : STORED('dropzonePath');

FWIW - there are other regression queries (not pipe8.ecl) that do have 'mydropzone' hard-coded in them, e.g. despray.ecl, i.e.:

dropzonePathTemp := '/var/lib/HPCCSystems/mydropzone/' : STORED('dropzonePath');

But that STORED is set via via ecl-test.json - and should be correct for that reason.
However, these tests should really all use File.GetDefaultDropZone() too.

@AttilaVamos - because it is not directly related to this PR (this PR is not necessary to resolve failures), but it would still be good to make the regression suites consistently use File.GetDefaultDropZone (and not have to rely on a STORED setting), I think they should be changed. Unless you disagree, can you open a new JIRA to change any existing regression suite query to use File.GetDefaultDropZone() ?

[xwang2713]

It is OK to close this PR. So the regress test can use default storage settings as helm/hpcc/values.yaml

[AttilaVamos]

I think the title of this PR is misleading. I doesn't intend to change all helm charts, only those are in the helm/examples/ directory. So it doesn't impacts the official helm charts and and how the HPCC platform deployed by default.
Moreover, If I understand well the aim of this changes are to fix inconsistency what caused regression failure when the Platform deployed with the example charts.

[jakesmith]

If I understand well the aim of this changes are to fix inconsistency what caused regression failure when the Platform deployed with the example charts.

The regression suite queries should consistently use File.GetDefaultDropZone().
If they did, regardless of what the example prefixes are - it would work.
NB: pipe8.ecl is one of the regression queries that does use File.GetDefaultDropZone(), so should not fail regardless of the dropzone prefix.

So the inconsistencies that need fixing are :

1. make sure all regression suite queries that reference dropzones use File.GetDefaultDropZone()
   @AttilaVamos - can you make that change?
2. very minor issue of examples file using 'my' - it would be good if consistently didn't use my (like the other planes) - but this is really very unimportant.

So, I recommend:

1. closing this PR - reopening one to just remove 'my' if you really want to (or repurpose this one)
2. issue a new JIRA/PR to ensure regression suite queries use the configure path vs a hardcoded path.

[AttilaVamos]

The regression test which led to this JIRA/PR is the pipe8.ecl failing only in an environment deployed by the charts located in the example directory. It is passing in AKS (Minikube) deployed by the default helm charts.
The pipe8.ecl is by default using that function:

dropzonePath := File.GetDefaultDropZone() : STORED('dropzonePath');

Related to the

make sure all regression suite queries that reference dropzones use File.GetDefaultDropZone()
@AttilaVamos - can you make that change?

I will do that soon. ( https://hpccsystems.atlassian.net/browse/HPCC-33265 )

[jakesmith]

The regression test which led to this JIRA/PR is the pipe8.ecl failing only in an environment deployed by the charts located in the example directory. It is passing in AKS (Minikube) deployed by the default helm charts. The pipe8.ecl is by default using that function:

dropzonePath := File.GetDefaultDropZone() : STORED('dropzonePath');

Yes, if installed correctly. Pipe8.ecl will work without issue.

@xwang2713 , did you install the hpcc-localfile chart, and then the hpcc chart pointing to helm/examples/local/values-localfile.yaml ?
If you did - that's the/a problem. The pre-generated values-localfile.yaml is wrong (does not match what is generated by the chart).

These storage example charts should be installed like this:

1. install [e.g.] hpcc-localfile, and capture the output to yaml, discarding the 1st few lines of non-yaml.
   e.g. : helm install anyname hpcc-localfile | sed -n '/#The following is a generated/,$p' > mystorage.yaml
2. install the hpcc chart with the capture yam
   e.g.: helm install myhpcc hpcc/hpcc -f mystorage.yaml
   That will ensure the correct/matching naming etc.

NB: There is brief note about this at the bottom of the hpcc-localfile/README.md

So, conclusions:

1. trivially unimportant anacronyms in naming of dropzone plane in hpcc-localfile and other storage example helm charts. i.e. name is currently "mydropzone" - would be slightly better if we dropped legacy 'my' baggage as has been done for other plane
   and instance names.
2. Most of the supplied pre-generated example chart outputs do not match what the example chart generate. These pre-generated files should be changed to match to avoid confusion, e.g. the prefix the LZ plane in local/values-localfile.yaml should be /var/lib/HPCCSystems/dropzone
3. The README.md could be clearer to emphasis that these pre-generated files are just for illustration purposes, and the correct way to install the storage charts is to capture the output and use it, which will ensure the plane configuration supplied to the hpcc chart matches the storage chart.

[xwang2713]

We will address the "sub path" of dropzone laster. Probably like Jake suggest we should adopt more properate name as "dropzone" and remove the pre-fix "my".