-
Notifications
You must be signed in to change notification settings - Fork 172
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
fix oapi, which has become obsolete in 4.0 #84
Conversation
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: pruan-rht If they are not already assigned, you can assign the PR to them by writing 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 |
FYI |
Actually we still have some hotfix will be backported to the version under 3.4, for this part, how to deal with? |
@wjiangjay, can you specify what kind of hotfixes you are referring to? IMO 3.4 is barely touched now so we can consider that separately. |
@@ -6,7 +6,7 @@ module OpenShift | |||
extend Helper | |||
|
|||
def self.populate(path, base_opts, opts) | |||
populate_common("/oapi/<oapi_version>", path, base_opts, opts) | |||
populate_common("/apis/user.openshift.io/<oapi_version>", path, base_opts, opts) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
::populate
method is used by all calls. And I believe user.openshift.io
is only for the user subsystem and will not work for ::list_projects
for example.
I think that we need to drop this openshift/kube api calls separation because now openshift calls are not a separate endpoint, just extensions to kube API. And we can handle all calls in same way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@akostadinov do you mean get ride of lib/rest_openshift.rb
and merge it into lib/rest_kubernetes.rb
@pruan-rht , @wjiangjay , maybe we can create a branch that will be dedicated to 3.5 and older so that we are not held back by such old versions. WDYT? |
Or shall we create a 3.x branch so that we design things according to 4.x in master from now on? Or do we still think expansion on 3.11 test cases is still ongoing? @openshift/team-qe , opinions? |
@akostadinov I vote for 4.x branch since it's so drastically different from 3.x. This way we don't need to monkey-patch all of these. perhaps something like v4 (like we did from v2 migrated to v3) |
My vote is the same, but now we make |
@akostadinov I'm fine with using |
@akostadinov having master at v4 sounds good to me |
@pruan-rht @akostadinov The hotfix often means some CVEs(this need smoke or acceptance testing of versions from 3.1 to 3.11). I am also fine with master is for v4 |
@wjiangjay if that's the case, then it's better IMO to create a separate branch for |
closing this PR in favor of #88 |
/oapi
is obsoleted in 4.0 . Anything newer than 3.5 should use the groupified resources/apis/user.openshift.io/v1/users/~