Solutions config.yaml & product.txt should be merged in a single manifest.yaml file

[alexandre-allard]

Component: solutions

Why this is needed:
Actually we have 2 files describing the Solution instead of one, moreover the config.yaml file is badly name as it suggests this is a configuration file rather than a manifest of the Solution.

What should be done:

• Merge config.yaml and product.txt in a single file and name it with a more relevant name such as manifest.yaml.
• Adapt Salt to use the new file
• Adapt the Solutions post-merge tests in the CI

Implementation proposal (strongly recommended):

Test plan:
There is already Solutions tests with pytest-bdd and cypress, they must not break.

[gdemonet]

What about MetalK8s ISO and product.txt? Could we unify the tooling for this?

[NicolasT]

I'd rather stick with product.txt, for one very simple reason: it can be read, parsed,... without any tooling, libraries,... For bootstrapping purposes, this is quite important.

[gdemonet]

OK, fair point. But we don't have the same need for Solution ISOs, right?

[NicolasT]

OK, fair point. But we don't have the same need for Solution ISOs, right?

Likely, indeed. My remark mostly concerns MetalK8s ISOs that need to be bootstrap'able.

[miniscruff]

I am wondering if this is going to be done in the next month or so as I am building the zenko solution. Or alternatively, if the current implementation will be maintained for a minor release or two for compatibility.

[gdemonet]

@miniscruff we'll make sure to have it available in the next iteration of Solutions, which we really want to work on for next month. In any case, you'll need #2389, which will change the format of this file (at the very least, remove the customApiGroups section), so if you can wait a bit, we'll update this ticket / our docs to reflect the next format (single manifest.yaml file).
For your question on compatibility, we could maintain it for a minor version (2.5.x), and drop it in the following, if that's needed. But I'd rather have the "next" approach for Zenko Solution ISO, since it's starting just now :)

[miniscruff]

I think the zenko solution is meant to be code complete this month, not sure if we can wait on that or if we just need to do an update when this is ready. @rahulreddy thoughts?

[gdemonet]

In any case, there are going to be some changes in the Solutions framework until the next delivery, to make sure Zenko Operator can achieve what it needs. Some other tickets already scheduled on our side: #2389, #2199.
Now, don't wait, it's just a few static files you'll generate at build-time, shouldn't be too hard to evolve once Metal can handle a new format. Focus on the current approach, we'll make sure it works and keeps working for next delivery, and if we are lucky and have time, we'll help you adjust to the new format described here.

[alexandre-allard]

Actually, we have a config.yaml which contains the following information:

apiVersion: solutions.metalk8s.scality.com/v1alpha1
kind: SolutionConfig
operator:
  image:
    name: example-solution-operator
    tag: 0.1.0-dev
ui:
  image:
    name: example-solution-ui
    tag: 0.1.0-dev
customApiGroups:
  - example-solution.metalk8s.scality.com

And the product.txt:

NAME=Example Solution
VERSION=0.1.0-dev
SHORT_VERSION=0-1
GIT=2.4.3-99-g3dba870e
DEVELOPMENT_RELEASE=0
BUILD_TIMESTAMP=2020-05-08T20:29:47Z
BUILD_HOST=MyComputer

So we could format the new manifest.yaml as follows:

apiVersion: solutions.metalk8s.scality.com/v1alpha1
kind: Solution
metadata:
  name: example-solution
  annotations:
    solutions.metalk8s.scality.com/display-name: Example Solution
    solutions.metalk8s.scality.com/git-revision: 2.4.3-99-g3dba870e
    solutions.metalk8s.scality.com/development-release: 0
    solutions.metalk8s.scality.com/build-timestamp: 2020-05-08T20:29:47Z
    solutions.metalk8s.scality.com/build-host: MyComputer
spec:
  version: 0.1.0-dev
  operator:
    image:
      name: example-solution-operator
      tag: 0.1.0-dev
  ui:
    image:
      name: example-solution-ui
      tag: 0.1.0-dev

With all annotations being optional.
I'm not including customApiGroups as it will be removed by #2389

[gdemonet]

Done in #2565