[SPIKE] Make Epiphany upgrades selective (Kafka)

[sk4zuzu]

Description

In this spike we want to consider an option with selective Kafka upgrades by Epicli.

It should be relatively simple (likely requires no changes in upgrade procedures themselves) to refactor Epiphany upgrades and make it possible for the user to control what components will be upgraded. That may bring value not only to users with legacy clusters but also to the process of testing.

• It needs to be checked if Kafka supports upgrades from any version to any other version. If it requires incremental upgrades between versions, it have to be taken into account.
• The output of this task is a PoC with selective Kafka upgrade by epicli.
• If it's possible, design document can be created.

All the topics related to the Kafka module will be done separately and covered by #1976 task and tasks that will be created as a result of #1976.

Additional information

The original task contained additional options related to Kafka module, but to avoid dependencies and clarify a single topic per task, these options are not covered here:

2. In the near future we will start introducing modules that will replace classic Epiphany components (like Kafka clusters etc). If we'd do that soon enough then the question would be if there is a possiblity to reuse modules with exising legacy on-prem clusters and what needs to be done to achieve that.

3. Support both 1. and 2.

We'd like to understand how much work do these options require to be implemented.

We want a design-doc out of his research. 

[sk4zuzu]

To clarify this one is about preparing some Kafka solution for very old releases of Epiphany :). For customers that do not want or it's not easy for them to upgrade to newer versions.

[DaOsie]

In my opinion there are 3 separate spikes "secretly" coded in the description:

• checking whether selective upgrades of components are possible in the legacy versions of epiphany
• checking whether modules will be able to be used in previous epiphany versions that do not use modules yet
• find the best way to introduce kafka for older releases of Epiphany

At first sight, they seem to be connected with each other, however I think they aim for 3 different things. Shouldn't we just check the easiest way for introducing kafka on legacy clusters?

[mkyc]

This one probably depends on #1976

[atsikham]

As I described in this comment, we still have to investigate a lot related to the Kafka module. All things related to modules including comparison with Kafka component of epicli will be done in the scope of #1976 and other tasks that will be created after #1976 is done.

This task is only about selective upgrades for epicli, Kafka component. At the moment we upgrade all components by a single run even not asking (specifying) target components. It also needs to be checked if Kafka supports upgrades from any version to any other version. If it requires incremental upgrades between versions, it have to be taken into account.

[przemyslavic]

@ar3ndt We urgently need these fixes:

1. The when conditions are invalid. Regardless of what components we select for the upgrade, all of them will be upgraded, because the conditions are always resolved as true.

Instead of the condition when: ('"kafka" in upgrade_components') or upgrade_components|length == 0
the condition when: "'kafka' in upgrade_components or upgrade_components|length == 0" seems to work fine.
The first condition always returns true (thanks @to-bar for debugging this together).

2. It looks like the condition is missing here at all which runs the kubernetes role even though I only set the kafka to be updated.
3. It would be nice to have the values sorted alphabetically here and separated additionally by a space for readability.
   

Moving this task back to TODO.

[przemyslavic]

1, 2, 3 Fixed.
User can run the upgrade command with an optional argument --upgrade-components providing the list of components to be updated.
Running the command without this argument will update all components.