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

Add docs for naming conventions #51

Open
Arnavion opened this issue Sep 26, 2019 · 0 comments
Open

Add docs for naming conventions #51

Arnavion opened this issue Sep 26, 2019 · 0 comments

Comments

@Arnavion
Copy link
Owner

Arnavion commented Sep 26, 2019

These are common to spec-generated clients of all languages, but it helps Rust devs who haven't used the other languages' clients before.

  • Resource types are under api, etc, then under modules corresponding to the API group and version, like core/v1/Pod -> core::v1::Pod

  • Functions are associated with the relevant resource type. Eg functions dealing with pods are found in api::core::v1::Pod's docs.

    Exceptions: Subresources like Status or pod logs are returned by functions of the base resource, eq Foo::read_*_status or Pod::read_namespaced_pod_log.

    Exceptions to the exceptions: Some subresources like api::authentication::v1::TokenRequest and api::core::v1::Binding are created from functions associated with their own type (TokenRequest::create_namespaced_service_account_token and Binding::create_namespaced_pod_binding respectively) instead of the parent resource's type.

  • Create a resource with create_*. Get an existing resource with read_*. Update with patch_*. Delete with delete_*. Delete a collection with delete_collection_*. Get a list of resources with list_*. Watch with watch_*.

  • _namespaced_ in the function name is just a convention for resources that are namespaced. (Are there resources that have both _namespaced_ and non-_namespaced_ functions to compare with?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant