I've added a spreadsheet indicating the versions and structure of the combined "release" charts. This can be used as a reference for comparing against the older version, as indicated by the counterpart spreadsheets in IEC-24.

After making the helm repo available, I naturally went on to test that everything is ok. This means adding the corresponding helm repo and then installing the cord-platform, seba and att-workflow charts.

For this I used one of the internal PODs in the ENEA lab, which was deployed with IEC Type2 platform using the Fuel Installer. The exact same thing as the deployment process in the Akraino IEC CI:
https://jenkins.akraino.org/job/iec-type2-deploy-fuel-baremetal-ubuntu1804-daily-master/

There are useful step-by-step instructions in the Akraino SEBA R2 installation guide, although tailored to REC/TA:
https://jenkins.akraino.org/job/iec-type2-deploy-fuel-baremetal-ubuntu1804-daily-master/

But more to the point this meant:
helm repo add cord https://iecedge.github.io/helm-charts/cord/
helm repo update
helm install -n cord-platform cord/cord-platform --version 7.2.3-dev-arm64

1. Wait for all 3 CRDs to come up
   kubectl get crd | grep -i etcd | wc -l
2. Also wait until all 3 kafka pods come up
   kubectl get pods | grep -i kafka | wc -l
   helm install -n seba cord/seba --version 2.0.0-dev-arm64
3. Wait until the tosca-loader pods are Completed
   kubectl get pods --all-namespaces | grep -i tosca-loader
   helm install -n att-workflow cord/att-workflow --version 1.3.0

I also wanted to do some verification tests to be sure everything works fine, so I decided to install PONSim and run the tests.

This is a little tricky, because PONSim is designed to work with SEBA-in-a-Box, but opencord has a guide here:
https://guide.opencord.org/cord-7.0/profiles/seba/siab.html

In my case, I used a shortcut, and used our forked automation-tools git repo:
https://github.com/iecedge/automation-tools/tree/cord-7.0-arm64

I won't go into all the nitty-gritty details, I will upload a log file of the steps performed, but just very quick, this means faking some of the siab milestones from /tmp/milestones and then calling make stable.

Finally, I called "make run-tests" which executed the robot tests.

The tests were successful, 10 out of 10, so I'm confident the charts are working and I will be closing this Jira issue.

One useful thing I want to mention is that I made some errors when I first started this task and I needed to delete the release archives, but unfortunately the chart-releaser (cr) tool does not have such option. So instead I found and used this tool: https://github.com/cheton/github-release-cli

But also important, after deleting the release there will still be a tag in the github repo, which must be delete otherwise when uploading a new archive, the old content will appear.

Deleting a tag is as simple as "git push origin --delete <tag>", where <tag> is the name of the chart uploaded, minus the .tgz extension.

Making a helm repository in github is described nicely in this tutorial:
https://tech.paulcz.net/blog/creating-a-helm-chart-monorepo-part-1/

I started out by creating a branch called gh-pages and removed all the content to get a clean, empty view.

I then started creating the required charts for the cord-platform and seba set of charts, using the information in IEC-24 to determine the outer-most dependency charts.

For example, for cord-platform, this means creating the charts for onos, logging, nem-monitoring and xos-core. The other two, kafka and etcd-operator, are hosted on the helm-k8s-charts repo created as part of IEC-40.

All the chart requirements need to be pushed to the newly created helm repo, before attempting to create the cord-platform or seba charts, because this time we ensure that the requirements.yaml file in these set of charts point to the helm repo just created. Also important, before calling "helm package <chart> <destination>", the chart requirements must be solved by calling "helm dep update", so this is why I first pushed the requirements and then created the combined charts.

This is also visible by looking at the commit history on the gh-pages branch: 
https://github.com/iecedge/helm-charts/commits/gh-pages

As described in the the guide I first mentioned, the helm repo comes into effect first by pushing the chart archives to the repo release archive and then by creating the index.yaml and pushing it to the gh-pages branch.

So, after creating the 3 set of charts and pushing all the required files to the github, the final form of the index.yaml can be seen on the github.io page:
https://iecedge.github.io/helm-charts/cord/index.yaml