mirror of
https://github.com/k8snetworkplumbingwg/whereabouts.git
synced 2025-06-03 06:42:26 +00:00

* build: generate ip pool clientSet/informers/listers
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* vendor: update vendor stuff
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: vendor net-attach-def-client types
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* config: look for the whereabouts config file in multiple places
The reconciler controller will have access to the whereabouts
configuration via a mount point. As such, we need a way to specify its
path.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* reconcile-loop: requires the IP ranges in normalized format
The IP reconcile loop also requires the IP ranges in a normalized
format; as such, we export it into a function, which will be used in a
follow-up commit.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* config: allow IPAM config parsing from a NetConfList
Currently whereabouts is only able to parse network configurations in
the strict [0] format - i.e. **do not accept** a plugin list - [1].
The `ip-control-loop` must recover the full plugin configuration, which
may be in the network configuration format.
This commit allows whereabouts to now understand both formats.
Furthermore, the current CNI release - v1.0.Z - removed the support for
[0], meaning that only the configuration list format is now supported
[2].
[0] - https://github.com/containernetworking/cni/blob/v0.8.1/SPEC.md#network-configuration
[1] - https://github.com/containernetworking/cni/blob/v0.8.1/SPEC.md#network-configuration-lists
[2] - https://github.com/containernetworking/cni/blob/master/SPEC.md#released-versions
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* reconcile-loop: add a controller
Listen to pod deletion, and for every deleted pod, assure their IPs
are gone.
The rough algorithm goes like this:
- for every network-status in the pod's annotations:
- read associated net-attach-def from the k8s API
- extract the range from the net-attach-def
- find the corresponding IP pool
- look for allocations belonging to the deleted pod
- delete them using `IPManagement(..., types.Deallocate, ...)`
All the API reads go through the informer cache, which is kept updated
whenever the objects are updated on the API.
The dockerfiles are also updated, to ship this new binary.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* e2e tests: remove manual cluster reconciliation
This would leave the `ip-control-loop` as the reconciliation tool.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* unit tests: assure stale IPAllocation cleanup
This commit adds a unit where it is checked that the pod deletion leads
to the cleanup of a stale IP address.
This commit features the automatic provisioning of the controller informer cache
with the data present on the fake clientset tracker (the "fake" datastore).
This way, users can just create the client with provisioned data, and
that'll trickle down to the informer cache of the pod controller.
Because the `network-attachment-definitions` resources feature dashes,
the heuristic function that guesses - yes, guesses. very deterministic
... - the name of the resource can't be used - [0]. As such, it was
needed to create an alternate `newFakeNetAttachDefClient` where it is
possible to specify the correct resource name.
[0] - 2fd7267afc/vendor/k8s.io/client-go/testing/fixture.go (L331)
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* unit tests: move helper funcs to other files
The helper files are tagged with the `test` build tag, to prevent them
from being shipped on the production code binary.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* control loop, queueing: use a rate-limiting queue
Using a queue allows us to re-queue errors.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* control loop: add IPAllocation cleanup related events
Adds two new events related to garbage collection of the whereabouts IP
addresses:
- when an IP address is garbage collected
- when a cleanup operation fails and is not re-queued
The former event looks like:
```
116s Normal IPAddressGarbageCollected pod/macvlan1-worker1 \
successful cleanup of IP address [192.168.2.1] from network \
whereabouts-conf
```
The latter event looks like:
```
10s Warning IPAddressGarbageCollectionFailed failed to garbage \
collect addresses for pod default/macvlan1-worker1
```
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* e2e tests: check out statefulset scenarios
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* e2e tests: test different scale up/down order and instance deltas
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* ci: test e2e bash scripts last
These ugly tests do not cleanup after themselves; this way, the golang
based tests (which **do** cleanup after themselves) will not be impacted by
these left-overs.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* ip control loop, unit tests: test negative scenarios
Check the event thrown when a request is dropped from the queue, and
assure reconciling an allocation is impossible without having access to
the attachment configuration data.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* e2e tests: test fix for issue #182
Issue [0] reports an error when a pod associated to a `StatefulSet`
whose IPPool is already full is deleted. According to it, the new pod -
scheduled by the `StatefulSet` - cannot run because the IPPool is
already full, and the old pod's IP cannot be garbage collected because
we match by pod reference - and the "new" pod is stuck in `creating`
phase.
[0] - https://github.com/k8snetworkplumbingwg/whereabouts/issues/182
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* ip-control-loop: strip pod before queueing it
The ip reconcile loop only requires the pod metadata and its network
status annotatations to garbage collect the stale IP addresses.
As such, we remove the status and spec parameters from the pod before
queueing it.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* reconcile-loop: focus on networks w/ whereabouts IPAM type
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
4.4 KiB
4.4 KiB
go-restful
package for building REST-style Web Services using Google Go
REST asks developers to use HTTP methods explicitly and in a way that's consistent with the protocol definition. This basic REST design principle establishes a one-to-one mapping between create, read, update, and delete (CRUD) operations and HTTP methods. According to this mapping:
- GET = Retrieve a representation of a resource
- POST = Create if you are sending content to the server to create a subordinate of the specified resource collection, using some server-side algorithm.
- PUT = Create if you are sending the full content of the specified resource (URI).
- PUT = Update if you are updating the full content of the specified resource.
- DELETE = Delete if you are requesting the server to delete the resource
- PATCH = Update partial content of a resource
- OPTIONS = Get information about the communication options for the request URI
Example
ws := new(restful.WebService)
ws.
Path("/users").
Consumes(restful.MIME_XML, restful.MIME_JSON).
Produces(restful.MIME_JSON, restful.MIME_XML)
ws.Route(ws.GET("/{user-id}").To(u.findUser).
Doc("get a user").
Param(ws.PathParameter("user-id", "identifier of the user").DataType("string")).
Writes(User{}))
...
func (u UserResource) findUser(request *restful.Request, response *restful.Response) {
id := request.PathParameter("user-id")
...
}
Features
- Routes for request → function mapping with path parameter (e.g. {id}) support
- Configurable router:
- (default) Fast routing algorithm that allows static elements, google custom method, regular expressions and dynamic parameters in the URL path (e.g. /resource/name:customVerb, /meetings/{id} or /static/{subpath:*})
- Routing algorithm after JSR311 that is implemented using (but does not accept) regular expressions
- Request API for reading structs from JSON/XML and accesing parameters (path,query,header)
- Response API for writing structs to JSON/XML and setting headers
- Customizable encoding using EntityReaderWriter registration
- Filters for intercepting the request → response flow on Service or Route level
- Request-scoped variables using attributes
- Containers for WebServices on different HTTP endpoints
- Content encoding (gzip,deflate) of request and response payloads
- Automatic responses on OPTIONS (using a filter)
- Automatic CORS request handling (using a filter)
- API declaration for Swagger UI (go-restful-openapi, see go-restful-swagger12)
- Panic recovery to produce HTTP 500, customizable using RecoverHandler(...)
- Route errors produce HTTP 404/405/406/415 errors, customizable using ServiceErrorHandler(...)
- Configurable (trace) logging
- Customizable gzip/deflate readers and writers using CompressorProvider registration
How to customize
There are several hooks to customize the behavior of the go-restful package.
- Router algorithm
- Panic recovery
- JSON decoder
- Trace logging
- Compression
- Encoders for other serializers
- Use jsoniter by build this package using a tag, e.g.
go build -tags=jsoniter .
TODO: write examples of these.
Resources
- Example posted on blog
- Design explained on blog
- sourcegraph
- showcase: Zazkia - tcp proxy for testing resiliency
- showcase: Mora - MongoDB REST Api server
Type git shortlog -s
for a full list of contributors.
© 2012 - 2018, http://ernestmicklei.com. MIT License. Contributions are welcome.