-
Notifications
You must be signed in to change notification settings - Fork 39.6k
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
Namespace certificates API group #31887
Conversation
Can one of the admins verify that this patch is reasonable to test? If so, please reply "ok to test". This message will repeat several times in short succession due to jenkinsci/ghprb-plugin#292. Sorry. |
1 similar comment
Can one of the admins verify that this patch is reasonable to test? If so, please reply "ok to test". This message will repeat several times in short succession due to jenkinsci/ghprb-plugin#292. Sorry. |
@k8s-bot ok to test |
3829555
to
47d1fd0
Compare
I'd like to get this in for v1.4 On Thu, Sep 1, 2016 at 8:49 AM, Jordan Liggitt [email protected]
|
a89b830
to
07d4ae7
Compare
07d4ae7
to
a869de6
Compare
@pwittrock requesting that this be included in v1.4 milestone.
Not risky. This is a rest path change of an API that will be introduced as alpha in v1.4.
Not hard. This is mostly a rename. Some autogenerated swagger files are touched but the change is isolated to certificates API sections of those files so there won't be merge conflicts.
Even if we wanted to make a compatible new API version of this API, we could not. Although the API is alpha and we reserve the right to break it, we should aim to avoid this if at all possible. Without this change, all API consumers will break on upgrade from v1.4 to v1.5. cc @gtank |
GCE e2e build/test passed for commit a869de6. |
tests are green, all the verify scripts are happy brought up an API server and tested with:
verified requests are hitting the /apis/certificates.k8s.io endpoint |
LGTM, @caesarxuchao can you make sure the api bits look fine? |
I thought the decision in the sig meeting yesterday is using "kubernetes.io", not "k8s.io"? @lavalamp |
I didn't think there was a strong preference, but maybe I misread. For consistency with our import package ( existing API groups:
|
@bgrant0607 prefers it spelled out. Not sure if that list will convince him otherwise but we can ask? |
Sadly, we're not consistent. It depends on who does the API review. We have API groups qualified with domains and those without. We use .k8s.io in the cases above and .kubernetes.io in most annotations. My general position for the API is to not abbreviate. Kubernetes contributors know what K8s means, but I wouldn't expect users to. However, I don't hear people being confused by K8s as often as I used to. In any case, my other rule is that consistency trumps correctness, so if we've used .k8s.io in other API group names but not .kubernetes.io, then stick with .k8s.io. |
k8s.io is supposed to be shorthand. I've intentionally used kubernetes.io for all public domains. The one exception is the go-get path, and perhaps that was a mistake. That said, it IS shorter and I am lazy. We should use the short form in places that humans type a lot. I don't think this is one of those cases. Inconsistency annoys me, so if the ship has sailed, then consistency wins. If it's not too late, I'd still argue for "kubernetes.io". I suppose aliasing it with "secondary" names is right out? Accept either but always emit kubernetes.io .. ? |
Good change! I would also like to see this in 1.4. Consistency with the other API groups (and future norms) should be done before anyone depends on this naming scheme. It may be a developer-centric opinion but, as someone who has typed these names frequently, I side with using .k8s.io. |
We need to make a decision on this. Going with kubernetes.io will require migrating 4 other api groups and we should do that before v1.4. I am not opinionated. |
@@ -14,6 +14,7 @@ See the License for the specific language governing permissions and | |||
limitations under the License. | |||
*/ | |||
|
|||
// +groupName=certificates.k8s.io |
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.
How did you change the staging area? It looks like you manually changed it?
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.
Anyway, the changes look fine.
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.
yes, was manual, found it in a search for the old name
Agree on being consistent. Since some of the suffixed groups existed in 1.3, switching to kubernetes.io would be pretty disruptive, not just for the 1.4 release. Without objection, I'll leave the PR as-is (and open a pick to the release-1.4 branch)
we could look into aliasing groups in future releases, but in the meantime, keeping things consistent seems ideal |
I agree with .k8s.io. Please no aliasing. It's confusing for users to see the multiple different forms in use and returning a different form than what the client expected won't work -- imagine accepting multiple apiversions but returning only 1. |
@k8s-bot test this [submit-queue is verifying that this PR is safe to merge] |
GCE e2e build/test passed for commit a869de6. |
Automatic merge from submit-queue |
we really need to get in from of the k8s.io vs kubernetes.io mess and lay On Fri, Sep 2, 2016 at 3:09 PM, Kubernetes Submit Queue <
|
Automatic merge from submit-queue Doc API group suffix, add test to catch new groups Spawned from discussion in #31887 Doc and add tests to ensure new API groups are suffixed. Also changed the doc to reference an API group containing the suffix as a starting point for new API groups.
Automatic merge from submit-queue Doc API group suffix, add test to catch new groups Spawned from discussion in kubernetes/kubernetes#31887 Doc and add tests to ensure new API groups are suffixed. Also changed the doc to reference an API group containing the suffix as a starting point for new API groups.
New API groups should follow best-practices for naming, including using DNS names within the k8s.io namespace
This change is