mirror of
https://github.com/optim-enterprises-bv/kubernetes.git
synced 2025-12-01 05:43:54 +00:00
Catch up with all the latest stuff from gophercloud 4b7db606 - only try to reauth once d13755e6 - BlockStorage v3: Rename VolumeType PublicAccess to IsPublic 614da04d - Add UPDATE support in V3 volume types (#656) be3fd784 - Flavor Extra Specs Create c2cafb46 - Flavor Extra Specs: List / Get 7b1b8775 - Compute v2: Flavor Access Add cf81d92c - Add DELETE support in V3 volume types a879b375 - Fix incorrect variable name 2997913a - Add pagination support in snapshots a5c71868 - Support pagination in volume resources 1db0312e - TrivialFix incorrect variable name 69194d93 - Add basic CRUD acceptance testcases in snapshot V3 22c7abce - Add CREATE support in V3 volume types aed60e9f - Add basic CRUD acceptance in volume V3 7cbf4661 - BlockStorage v3: volumetype get/list acc test bcab0f79 - Update README with Thank Yous f85e7c0f - Docs: Updating Contributing and Style Guides be1b616c - Fix a small syntax error of TestShareTypeExtraSpecs test 3f38a1ee - Add List/Get support for volume type in volume V3 48a40399 - Support for setting availability_zone_hints to a router 747776a7 - Fix the undefined function error of TestPortsbindingCRUD test a7ec61ea - Fix the undefined function error of TestNetworksProviderCRUD test 25e18920 - Compute v2: Add the extended status information API b63d2fd3 - availability_zone_hints for network(s) 157d7511 - Add support for ipv6_address_mode and ipv6_ra_mode in subnets ed468967 - DBv1: configurations acceptance test 578e2aab - Configuration group time parsing error 669959f8 - Compute v2: attachinterfaces acceptance test 8113f0cb - Add Nova interface-detach support d6484abc - Add Nova interface-attach support 7883fd95 - fix reauth deadlock by not calling Token() during reauth 4d0f8253 - Add support to get interface of a server 7dc13e0d - AccTests: BlockStorage v2 ForceDelete 1e86e54d - Refactor blockstorage actionURL e30da231 - Feature/support force delete e193578c - add UseTokenLock method in ProviderClient to allow safe concurrent access e6a5f874 - ObjectStorage v1: Rename ExtractLastMarker to extractLastMarker c47bb004 - BlockStorage v2/v3: Reorder snapshot/volume ListOpts and update godoc 2c05d0e4 - Add 'tenant' support in volume&snapshot API 639d71fd - Networking v2: Port Security Extension 755794a7 - ObjectStorage v1: Subdir and Marker detection a043441f - fixed bug with endless loop when using delimiter on folded directory a4799293 - OpenStack: support OS_PROJECT_* variables
80 lines
3.7 KiB
Markdown
80 lines
3.7 KiB
Markdown
|
|
## On Pull Requests
|
|
|
|
- Please make sure to read our [contributing guide](/.github/CONTRIBUTING.md).
|
|
|
|
- Before you start a PR there needs to be a Github issue and a discussion about it
|
|
on that issue with a core contributor, even if it's just a 'SGTM'.
|
|
|
|
- A PR's description must reference the issue it closes with a `For <ISSUE NUMBER>` (e.g. For #293).
|
|
|
|
- A PR's description must contain link(s) to the line(s) in the OpenStack
|
|
source code (on Github) that prove(s) the PR code to be valid. Links to documentation
|
|
are not good enough. The link(s) should be to a non-`master` branch. For example,
|
|
a pull request implementing the creation of a Neutron v2 subnet might put the
|
|
following link in the description:
|
|
|
|
https://github.com/openstack/neutron/blob/stable/mitaka/neutron/api/v2/attributes.py#L749
|
|
|
|
From that link, a reviewer (or user) can verify the fields in the request/response
|
|
objects in the PR.
|
|
|
|
- A PR that is in-progress should have `[wip]` in front of the PR's title. When
|
|
ready for review, remove the `[wip]` and ping a core contributor with an `@`.
|
|
|
|
- Forcing PRs to be small can have the effect of users submitting PRs in a hierarchical chain, with
|
|
one depending on the next. If a PR depends on another one, it should have a [Pending #PRNUM]
|
|
prefix in the PR title. In addition, it will be the PR submitter's responsibility to remove the
|
|
[Pending #PRNUM] tag once the PR has been updated with the merged, dependent PR. That will
|
|
let reviewers know it is ready to review.
|
|
|
|
- A PR should be small. Even if you intend on implementing an entire
|
|
service, a PR should only be one route of that service
|
|
(e.g. create server or get server, but not both).
|
|
|
|
- Unless explicitly asked, do not squash commits in the middle of a review; only
|
|
append. It makes it difficult for the reviewer to see what's changed from one
|
|
review to the next.
|
|
|
|
- See [#583](https://github.com/gophercloud/gophercloud/issues/583) as an example of a
|
|
well-formatted issue which contains all relevant information we need to review and approve.
|
|
|
|
## On Code
|
|
|
|
- In re design: follow as closely as is reasonable the code already in the library.
|
|
Most operations (e.g. create, delete) admit the same design.
|
|
|
|
- Unit tests and acceptance (integration) tests must be written to cover each PR.
|
|
Tests for operations with several options (e.g. list, create) should include all
|
|
the options in the tests. This will allow users to verify an operation on their
|
|
own infrastructure and see an example of usage.
|
|
|
|
- If in doubt, ask in-line on the PR.
|
|
|
|
### File Structure
|
|
|
|
- The following should be used in most cases:
|
|
|
|
- `requests.go`: contains all the functions that make HTTP requests and the
|
|
types associated with the HTTP request (parameters for URL, body, etc)
|
|
- `results.go`: contains all the response objects and their methods
|
|
- `urls.go`: contains the endpoints to which the requests are made
|
|
|
|
### Naming
|
|
|
|
- For methods on a type in `results.go`, the receiver should be named `r` and the
|
|
variable into which it will be unmarshalled `s`.
|
|
|
|
- Functions in `requests.go`, with the exception of functions that return a
|
|
`pagination.Pager`, should be named returns of the name `r`.
|
|
|
|
- Functions in `requests.go` that accept request bodies should accept as their
|
|
last parameter an `interface` named `<Action>OptsBuilder` (eg `CreateOptsBuilder`).
|
|
This `interface` should have at the least a method named `To<Resource><Action>Map`
|
|
(eg `ToPortCreateMap`).
|
|
|
|
- Functions in `requests.go` that accept query strings should accept as their
|
|
last parameter an `interface` named `<Action>OptsBuilder` (eg `ListOptsBuilder`).
|
|
This `interface` should have at the least a method named `To<Resource><Action>Query`
|
|
(eg `ToServerListQuery`).
|