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.

Sign up for GitHub

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

Jump to bottom

Move PodSecurityPolicy to policy api group #25666

Closed
zhouhaibing089 opened this issue May 16, 2016 · 3 comments
Closed

Move PodSecurityPolicy to policy api group #25666

zhouhaibing089 opened this issue May 16, 2016 · 3 comments

Comments

@zhouhaibing089
Copy link
Contributor

zhouhaibing089 commented May 16, 2016 •
edited
Loading

As the name podsecuritypolicy suggests, it may be better to put it at policy api group.

Besides, it looks there is convention violation here:

podSecurityPolicyStorage := pspetcd.NewREST(restOptions("podsecuritypolicy"))
// ....(restOptions("podsecuritypolicies")) ?
if c.APIResourceConfigSource.ResourceEnabled(version.WithResource("podsecuritypolicy")) {
    storage["podSecurityPolicies"] = podSecurityPolicyStorage
    // storage["podsecuritypolicies"] = podSecurityPolicyStorage ?
}

/cc @erictune @liggitt @pweil-
@liggitt
Copy link
Member

liggitt commented May 16, 2016

The policy API group didn't exist when PSP was added. If I understand it correctly, it is not intended to contain authorization type policy objects (which @deads2k pointed out would be confusing when the policy API group was introduced)

@zhouhaibing089
Copy link
Contributor Author

I see there is an ongoing pull request which introduces networkpolicy and that's why I feel the same for psp. what's the confusing point then? I personally feel it is more natural to find a podsecuritypolicy in a policy api group..

@zhouhaibing089
Copy link
Contributor Author

nothing is tracked here, close it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@liggitt @mikedanese @zhouhaibing089