inconsistent labels across different kubeflow components

[Bobgy]

#1647 (comment)

It seems that distributions sometimes refer to application overlay and sometimes refer to base_v3, causing different components to have different labels.
Because we are already making breaking changes in #1647, we should take the chance to get a consistent label set.

cc distribution owners (Did I miss anyone? what's the best way to cc all distribution owners?)
/cc @animeshsingh @kubeflow/azure @kubeflow/aws @kubeflow/arrikto @thesuperzapper

[yanniszark]

@Bobgy is this for 1.2? For 1.3, we'll be refactoring the manifests according to https://github.com/kubeflow/community/blob/master/wg-manifests/charter.md, in order to re-use the manifests published by upstream applications. Should we tackle this issue as part of the 1.3 effort?

[Bobgy]

Makes sense to me targetting 1.3
So I think we should leave #1647 not cherry picked, because it's not worth it if we need to do a breaking change again in 1.3

[PatrickXYS]

@yanniszark I think it's okay to put it on 1.3.

But I would like to have some patch versions of 1.2, e.g, 1.2.1, 1.2.2, etc. This is to help develop some lightweight features before major release e.g, 1.3.

Who will be taking care of 1.2 patch versions, and what's our plan to support in that way? I'd like to help as well

/cc @Jeffwan

[Jeffwan]

The issue was from v1.1 the time community migrate to v3 manifest. Labels were not taken care of carefully. This could be either under 1.2 minor version release scope or 1.3. We need to figure out what's the impact and how users reply on them. If that's a breaking change, I would suggest to postpost to 1.3 release cycle as well

[Bobgy]

We've known in the past it's a breaking change, because deployment label selector is an immutable field.

Shall we revert the cherry pick #1648?

[thesuperzapper]

@Bobgy #1648 doesn't include the commit we are talking about from #1647

[Bobgy]

@thesuperzapper thanks, sorry I mistook another commit as the PR.

Then we can tackle this by manifest WG

[yanniszark]

Now that we've:

• Moved manifest development back to upstream repos: Step 2: Move manifests development upstream #1740
• Consolidated multiple manifests versions into one: Step 4: Consolidate manifests with multiple versions into 1 #1769

there should be no issue with the base and base_v3 kustomizations going out of sync.