UPSTREAM: <carry>: hack out the oapi for restmapping resources when m…#18377
UPSTREAM: <carry>: hack out the oapi for restmapping resources when m…#18377openshift-merge-robot merged 2 commits intoopenshift:masterfrom
Conversation
openshift-ci-robot
added
the
approved
openshift-ci-robot
added
the
size/M
openshift-merge-robot
added
the
vendor-update
| var oapiResources = map[schema.GroupVersionResource]bool{ | ||
| {Resource: "deploymentconfig"}: true, | ||
| {Resource: "deploymentconfigs"}: true, | ||
| {Resource: "dc"}: true, |
There was a problem hiding this comment.
there's less than 100 of these
There was a problem hiding this comment.
can we make this pluggable in upstream, so you can register "ignored" resources like:
type predicateFunc func(gvk) bool
var IgnoredResources = map[schema.GroupVersionResource]predicateFunc{}
// then in origin we will have something like:
meta.IgnoredResources["deploymentconfig"] = func(gvk) { len(gvk.Group) == 0 }There was a problem hiding this comment.
(just thinking loud to avoid carry patch ;-)
There was a problem hiding this comment.
can we make this pluggable in upstream, so you can register "ignored" resources like
I don't think there's a use-case upstream.
|
Uh this is the only way to force our groupified resources to be used? |
Fully open to other pulls. Priority is based on groupversion. The We have a special case for 75 or so resources in |
|
I cannot think of a better solution off the top of my head (I expect any solution to be some variation on this hack in the end). |
|
/retest |
|
(flake was the router/prometheus ) |
…ore than one is present
deads2k
force-pushed
the
cli-18-priority
branch
from
c29cfa3 to
e6249a4
Compare
openshift-ci-robot
added
size/L
|
now with our 75 or so resources |
deads2k
changed the title
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: deads2k, enj The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these OWNERS Files:
You can indicate your approval by writing |
|
/retest |
|
Automatic merge from submit-queue (batch tested with PRs 18390, 18389, 18290, 18377, 18385). |
…lectric-boogaloo Automatic merge from submit-queue. UPSTREAM: <carry>: Short-circuit HPA oapi/v1.DC The legacy oapi v1 group-version very much confuses anything not designed to explicitly work with it. Since we now don't do any custom HPA setup, we need to teach the scale client and the HPA what to do with the oapi version of DC, since it won't even show up in its discovery process. Related to #18377
Automatic merge from submit-queue (batch tested with PRs 18666, 18810, 18430, 18517, 18653). Add migrate command for legacy HPAs There are current broken HPAs floating around that either use the legacy oapi DeploymentConfig defintion (`v1.DeploymentConfig`) or the incorrect API group, due to the webconsole (all scalables, but with the group as `extensions/v1beta1`). This introduces a migrate command that corrects the ScaleTargetRef of those HPAs to have correct API groups that are usable by generic scale clients. Related to #18377, #18380, openshift/origin-web-console#2776 cc @deads2k @liggitt @spadgett
5 participants
…ore than one is present
If there is more than one kind or resource for a value (the CLI uses this for deciding what to do about deploymentconfigs as a for instance), anything in that list that is an openshift resource (I've only listed one to prove the concept), will be removed.
I think that referencing names from a file will still work since that should come back with one match.
@juanvallejo can you see if files containing oapi resources still work.
@soltysh @mfojtik @smarterclayton is this a thing we can live with? It will finally make the groupified resources have priority on the CLI.
@DirectXMan12 I really wish this had not worked.