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

cli: remove usage of internal apps helpers from all CLI commands #20362

Merged
merged 7 commits into from
Jul 26, 2018

Conversation

mfojtik
Copy link
Contributor

@mfojtik mfojtik commented Jul 19, 2018

This PR removes usage of appsinternalutil from all CLI commands, making the CLI not depend on the internal apps types.

/cc @juanvallejo
/cc @deads2k
/cc @tnozicka

@mfojtik mfojtik requested review from soltysh and deads2k July 19, 2018 12:58
@openshift-ci-robot openshift-ci-robot added approved Indicates a PR has been approved by an approver from all required OWNERS files. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. labels Jul 19, 2018

// deploymentStatusReasonAnnotation represents the reason for deployment being in a given state
// Used for specifying the reason for cancellation or failure of a deployment
deploymentStatusReasonAnnotation = "openshift.io/deployment.status-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.

@tnozicka note that this collection is used exclusively by util helpers and nothing else... i thinks we should not make it public but have helpers that allow to use them.

Copy link
Contributor

Choose a reason for hiding this comment

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

I'd make it public and moved it to library-go or somewhere so people can import it. The annotation is API-ish as that's part of the public facing status and an annotation just because we don't control the API for the upstream object.

i thinks we should not make it public but have helpers that allow to use them.

I thought we are trying to get rid of those one line helpers.

Copy link
Contributor

Choose a reason for hiding this comment

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

Those are useful consts for someone writing an integration, making them private will just lead to code duplication


deploymentName := LatestDeploymentNameForConfig(config)

podSpec := v1.PodSpec{}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

err have to drop this

@@ -86,6 +86,15 @@ func NewPerDeploymentConfigResolver(dataSet DataSet, keepComplete int, keepFaile
}
}

// ByMostRecent sorts deployments by most recently created.
type ByMostRecent []*kapi.ReplicationController
Copy link
Contributor Author

Choose a reason for hiding this comment

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

only resolvers use this, I don't see a reason for this to live in apps util package... if resolvers want special sort, then lets make them define it here.

kc kclientset.Interface

appsClient appstypedclient.AppsV1Interface
kubeClient kubernetes.Interface
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@juanvallejo @deads2k there are some commands I had to switch to external client now to avoid local conversions

configName = appsinternalutil.DeploymentConfigNameFor(obj)
case *appsapi.DeploymentConfig:
configName = appsutil.DeploymentConfigNameFor(obj)
case *appsv1.DeploymentConfig:
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@deads2k @juanvallejo can you confirm this will work? :-)

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 you have to change the scheme in the resource builder in o.findResource to be WithScheme(ocscheme.ReadingInternalScheme, ocscheme.ReadingInternalScheme.PrioritizedVersionsAllGroups()...), otherwise, you'll still be dealing with internal objects here

Copy link
Contributor Author

Choose a reason for hiding this comment

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

fixed, thanks!

*appsapitest.OkHPAForDeploymentConfig(config, 1, 3),
}}, nil
})
// TODO: re-enable when we switch describer to external client
Copy link
Contributor Author

Choose a reason for hiding this comment

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

every big win has some small looses :-)

@juanvallejo I can deal with this in a follow up PR, but I didn't want to groom this PR with switching the HPA to external as well (+300 lines of changes)

@@ -77,7 +82,7 @@ func describerMap(clientConfig *rest.Config, kclient kclientset.Interface, host
if err != nil {
glog.V(1).Info(err)
}
appsClient, err := appsclient.NewForConfig(clientConfig)
appsClient, err := appstypedclient.NewForConfig(clientConfig)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@soltysh @juanvallejo i believe this is the holy grail path and we want to switch all describers to external at some point?

Copy link
Contributor

Choose a reason for hiding this comment

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

hm, what about upstream describers? I believe some of those make use of the pkg/printers/internalversion package.
Since we do not use the printers/internalversion package in kubectl to the extent that we used to (with humanreadable printing) due to the introduction of server-side printing, maybe the best path forward for describers would be something similar to server-side printing?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@juanvallejo not super familiar with server side printing, but in general I think describers are not that generic and are very custom for some resources. I think for origin resources, as we continue moving forward with external clients and external types, we will likely convert our describers to external... I would expect that if kubectl is also taking the external path, they will do the same...

/cc @soltysh

Copy link
Contributor

Choose a reason for hiding this comment

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

At least in the scope of this PR, does switching the describer func for deploymentconfigs affect the oc describe command?

@@ -74,12 +75,6 @@ func DecodeDeploymentConfig(controller metav1.ObjectMetaAccessor) (*appsapi.Depl
return config, nil
}

// DeployerPodSelector returns a label Selector which can be used to find all
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@deads2k you asked about number of remaining internal helpers... these are left overs (used by REST and controllers)... Note that not all if them are duplicated into pkg/apps/util, some live sorely to make just controllers happy.

Copy link
Contributor

Choose a reason for hiding this comment

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

@deads2k you asked about number of remaining internal helpers... these are left overs (used by REST and controllers)... Note that not all if them are duplicated into pkg/apps/util, some live sorely to make just controllers happy.

glad to see it moving in the right direction

@mfojtik
Copy link
Contributor Author

mfojtik commented Jul 19, 2018

/retest

@mfojtik mfojtik force-pushed the apps-04-refactor-cli branch 4 times, most recently from e2b8017 to 80f1367 Compare July 19, 2018 14:44
if o.kc == nil {
return fmt.Errorf("kc must not be nil")
if o.kubeClient == nil {
return fmt.Errorf("kubeInternalClient must not be nil")
}
if o.getBuilder == nil {
return fmt.Errorf("getBuilder must not be nil")
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think this validation check is necessary - we don't do it in any other commands

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yeah, when I saw it I thought it is weird... will remove that

@openshift-bot openshift-bot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jul 19, 2018
@openshift-bot openshift-bot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jul 20, 2018
@mfojtik
Copy link
Contributor Author

mfojtik commented Jul 20, 2018

/retest

1 similar comment
@mfojtik
Copy link
Contributor Author

mfojtik commented Jul 20, 2018

/retest

@openshift-bot openshift-bot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jul 20, 2018
@mfojtik
Copy link
Contributor Author

mfojtik commented Jul 23, 2018

/retest

1 similar comment
@mfojtik
Copy link
Contributor Author

mfojtik commented Jul 23, 2018

/retest

@@ -54,7 +55,16 @@ func bold(v interface{}) string {
return "\033[1m" + toString(v) + "\033[0m"
}

func convertEnv(env []api.EnvVar) map[string]string {
// DEPRECATED:
func convertEnvInternal(env []api.EnvVar) map[string]string {
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this still used by something? Do we need to keep it?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

not used, I can remove it in follow up if you're fine with that (don't want to mess with the queue now)

@mfojtik
Copy link
Contributor Author

mfojtik commented Jul 24, 2018

/refresh

@openshift-bot openshift-bot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jul 24, 2018
@openshift-ci-robot
Copy link

New changes are detected. LGTM label has been removed.

@openshift-ci-robot openshift-ci-robot removed the lgtm Indicates that a PR is ready to be merged. label Jul 25, 2018
@openshift-bot openshift-bot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jul 25, 2018
@mfojtik mfojtik added the lgtm Indicates that a PR is ready to be merged. label Jul 25, 2018
@mfojtik
Copy link
Contributor Author

mfojtik commented Jul 25, 2018

reapplying LGTM label, simple conflict fixed in oc rollout cancel.

@mfojtik
Copy link
Contributor Author

mfojtik commented Jul 25, 2018

/retest

2 similar comments
@mfojtik
Copy link
Contributor Author

mfojtik commented Jul 25, 2018

/retest

@mfojtik
Copy link
Contributor Author

mfojtik commented Jul 25, 2018

/retest

@openshift-bot openshift-bot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jul 25, 2018
@openshift-ci-robot
Copy link

New changes are detected. LGTM label has been removed.

@openshift-ci-robot openshift-ci-robot removed the lgtm Indicates that a PR is ready to be merged. label Jul 26, 2018
@openshift-bot openshift-bot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jul 26, 2018
@mfojtik
Copy link
Contributor Author

mfojtik commented Jul 26, 2018

re-adding lgtm, simple conflict in describer

@mfojtik mfojtik added the lgtm Indicates that a PR is ready to be merged. label Jul 26, 2018
@openshift-merge-robot openshift-merge-robot merged commit 305c0c2 into openshift:master Jul 26, 2018
@mfojtik mfojtik deleted the apps-04-refactor-cli branch September 5, 2018 21:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants