Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

inconsistent labels across different kubeflow components #1649

Closed
Bobgy opened this issue Nov 16, 2020 · 8 comments
Closed

inconsistent labels across different kubeflow components #1649

Bobgy opened this issue Nov 16, 2020 · 8 comments

Comments

@Bobgy
Copy link
Contributor

Bobgy commented Nov 16, 2020

#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

@Bobgy Bobgy mentioned this issue Nov 16, 2020
1 task
@yanniszark
Copy link
Contributor

yanniszark commented Nov 16, 2020

@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
Copy link
Contributor Author

Bobgy commented Nov 16, 2020

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
Copy link
Member

@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
Copy link
Member

Jeffwan commented Nov 16, 2020

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
Copy link
Contributor Author

Bobgy commented Nov 16, 2020

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
Copy link
Member

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

@Bobgy
Copy link
Contributor Author

Bobgy commented Nov 17, 2020

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

Then we can tackle this by manifest WG

@yanniszark
Copy link
Contributor

Now that we've:

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants