Skip to content
This repository has been archived by the owner on Aug 17, 2023. It is now read-only.

v1beta1 KfDef #29

Merged
merged 27 commits into from
Sep 17, 2019
Merged

v1beta1 KfDef #29

merged 27 commits into from
Sep 17, 2019

Conversation

gabrielwen
Copy link
Contributor

@gabrielwen gabrielwen commented Sep 6, 2019

Bootstrapping KfDef for v1beta1.

Relates to kubeflow/kubeflow#4002


This change is Reviewable

@jlewi
Copy link
Contributor

jlewi commented Sep 6, 2019

Thanks
LGTM

@yanniszark @kkasravi comments?

@gabrielwen
Copy link
Contributor Author

please help and take a look at condition types and reasons, I try to fit the new status into our new semantics.

@kunmingg
Copy link
Contributor

kunmingg commented Sep 6, 2019

@gabrielwen
Copy link
Contributor Author

no, this is the new version. we will make kfctl to be backward compatible with v1alpha1 KfDef, tho.

@kkasravi
Copy link
Contributor

kkasravi commented Sep 6, 2019

there is a merged doc on conditions and ApplicationStatusCondition

@gabrielwen
Copy link
Contributor Author

@kkasravi I've updated the conditions part according to the link, could you take a second pass?

@kkasravi
Copy link
Contributor

kkasravi commented Sep 6, 2019

thanks @gabrielwen
/lgtm

@gabrielwen
Copy link
Contributor Author

@yanniszark will wait for your review. please approve this when you think it looks good.

Copy link
Contributor

@yanniszark yanniszark left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gabrielwen thanks for the PR!
I have left some comments below, please take a look and tell me what you think 😄

pkg/apis/apps/kfdef/v1beta1/application_types.go Outdated Show resolved Hide resolved
pkg/apis/apps/kfdef/v1beta1/application_types.go Outdated Show resolved Hide resolved
pkg/apis/apps/kfdef/v1beta1/application_types.go Outdated Show resolved Hide resolved
pkg/apis/apps/kfdef/v1beta1/application_types.go Outdated Show resolved Hide resolved
KfAvailable KfDefConditionType = "Available"

// KfDegraded means functionality of Kubeflow is limited.
KfDegraded KfDefConditionType = "Degraded"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What exactly does functionality is limited mean?
Can you give an example?
Is this meant to be used with the ApplyPluginsFailedReason reason?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From the doc:

  • KfAvailable = true && KfDegraded = true means KF is serving (central dashboard is accessible) but the services are limited. For example, we can use notebook but not pipelines.
  • KfAvailable = false && KfDegraded = true means KF is not serving and part/all of services are not serving as well.
  • KfAvailable = true && KfDegraded = false means KF is serving and all services are healthy.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe this doc was mentioned by @kkasravi.
I don't have a problem with using the specific conditions, just wondering if they fit Kubeflow as well.
For example, I don't think we can detect a condition like "KF is serving but not all services are serving" in kfctl.
However, individual conditions do make sense.

In addition, the doc refers to a library that doesn't exist anymore (https://github.com/openshift-kni/operator-status).
I will update the design doc to refer to this doc.
@jlewi @kkasravi thoughts?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should follow the doc only if the conditions make sense in our use case.

I might also suggest holding off defining conditions until we are sure we need them; i.e. we are writing code to implement. I might suggest commenting out and explaining why or opening up an issue to define track what conditions we think we need.

We might want to hold off defining the conditions until we actually need them; i.e. are writing the code to implement them.

Adding conditions later doesn't break compatibility but removing ones could.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, I removed most of conditions/reasons and only keep one or two placeholders that I think we definitely need them.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@yanniszark @gabrielwen if KfDef becomes a CRD, should we define a structured schema
see

pkg/apis/apps/kfdef/v1beta1/application_types.go Outdated Show resolved Hide resolved
@k8s-ci-robot k8s-ci-robot removed the lgtm label Sep 9, 2019
Copy link
Contributor

@yanniszark yanniszark left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gabrielwen I have a few more comments on this, I think we're almost there.

KfAvailable KfDefConditionType = "Available"

// KfDegraded means functionality of Kubeflow is limited.
KfDegraded KfDefConditionType = "Degraded"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe this doc was mentioned by @kkasravi.
I don't have a problem with using the specific conditions, just wondering if they fit Kubeflow as well.
For example, I don't think we can detect a condition like "KF is serving but not all services are serving" in kfctl.
However, individual conditions do make sense.

In addition, the doc refers to a library that doesn't exist anymore (https://github.com/openshift-kni/operator-status).
I will update the design doc to refer to this doc.
@jlewi @kkasravi thoughts?

pkg/apis/apps/kfdef/v1beta1/application_types.go Outdated Show resolved Hide resolved
@gabrielwen
Copy link
Contributor Author

/hold cancel

@gabrielwen
Copy link
Contributor Author

@yanniszark @kkasravi could I have lgtm from both of you?

@kkasravi
Copy link
Contributor

/lgtm

@jlewi
Copy link
Contributor

jlewi commented Sep 16, 2019

/lgtm
/approve
/hold
To give @yanniszark time to review

Copy link
Contributor

@yanniszark yanniszark left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have a few more comments and this should be ready to go for me.
Great work!

pkg/apis/apps/kfdef/v1beta1/application_types.go Outdated Show resolved Hide resolved
pkg/apis/apps/kfdef/v1beta1/application_types.go Outdated Show resolved Hide resolved
pkg/apis/apps/kfdef/v1beta1/application_types.go Outdated Show resolved Hide resolved
pkg/apis/apps/kfdef/v1beta1/application_types_test.go Outdated Show resolved Hide resolved
@k8s-ci-robot k8s-ci-robot removed the lgtm label Sep 17, 2019
@gabrielwen
Copy link
Contributor Author

@yanniszark done, could you take a final look? :)

@yanniszark
Copy link
Contributor

@gabrielwen thanks for all the great work.
/lgtm

One last concern I had, which is worth mentioning now:

AFAIK, we don't have a good story for providing secrets for securing applications.
eg we probably want to configure MySQL, OIDC clients, Minio etc with good random passwords and not default ones like we do now.

Are we confident that we'll be able to have a good story for this without needing a new version?
/cc @jlewi

@gabrielwen @jlewi that's all from my side, please remove the hold when you believe everything is ready.

@jlewi
Copy link
Contributor

jlewi commented Sep 17, 2019

@yanniszark We can extend SecretSource if need be to allow people alternative methods of referencing secrets.

@jlewi
Copy link
Contributor

jlewi commented Sep 17, 2019

/lgtm
/approve
/hold cancel

@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jlewi

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot merged commit 6ebaf60 into kubeflow:master Sep 17, 2019
@gabrielwen gabrielwen deleted the v1beta1-kfdef branch September 18, 2019 05:18
vpavlin pushed a commit to vpavlin/kfctl that referenced this pull request Jul 10, 2020
Fix "replaces" property in 0.6.1 CSV
crobby pushed a commit to crobby/kfctl that referenced this pull request Mar 25, 2021
Update to latest 1.0.5 release
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants