Adds logic which adds virtual fields resources. This allows these fields
to be sorted/filtered on when the SQL cache is enabled. Id and
metadata.state.name were added as the first two fields.
This uses SQLite-backed informers provided by Lasso with https://github.com/rancher/lasso/pull/65 to implement Steve API (/v1/) functionality.
This new functionality is available behind a feature flag to be specified at Steve startup
See https://confluence.suse.com/pages/viewpage.action?pageId=1359086083
Co-authored-by: Ricardo Weir <ricardo.weir@suse.com>
Co-authored-by: Michael Bolot <michael.bolot@suse.com>
Co-authored-by: Silvio Moioli <silvio@moioli.net>
Signed-off-by: Silvio Moioli <silvio@moioli.net>
Add a new query parameter to filter resources by their namespace or
their namespace's project. This parameter is separate from the existing
`filter` parameter.
Filter by a comma-separated list of projects and/or namespaces with:
?projectsornamespaces=p1,n1,n2
The result can be negated with the ! operator:
?projectsornamespaces!=p1,n1,n2
Without this change, the cache is checked if a revision is specified,
but the revision is ignored if the value is not found in the cache. This
is a problem if by chance sequential paginated requests land on separate
pods, because a different version number may be fetched on the sequent
request and cause the caches to be inconsistent with one another. This
change ensures that `revision` is passed as `resourceVersion` to the
Kubernetes request, since `revision` has no meaning to Kubernetes.
Cache filtered, sorted results for fast subsequent page retrieval.
Requests for cached queries need to include the list revision number
along with other queries. If no specific revision is requested, a new
fetch is done in order to get the latest revision. The revision is
included in the list response.
Example first request:
GET /v1/secrets?pagesize=10
Example subsequent page request:
GET /v1/secrets?pagesize=10&page=1&revision=107740
Extend the partition store to parse page and pagesize parameters and
return a subset of list results. The total number of pages is included
in the list response.
Request an initial page:
GET /v1/secrets?pagesize=10
or
GET /v1/secrets?pagesize=10&page=1
Request subsequent pages, or arbitrary pages:
GET /v1/secrets?pagesize=10&page=37
If a page number is out of bounds, an empty list is returned.
Extend the partition store to parse the "sort" query parameter as a
sorting condition. Dot notation is used to denote the object field.
Preceding the key with "-" denotes descending (reverse) order.
Example sorting by name:
GET /v1/secrets?sort=metadata.name
Reverse sorting by name:
GET /v1/secrets?sort=-metadata.name
All values are converted to strings and sorted lexicographically.
Extend the partition store to parse query params as list filters. Filter
keys use dot notation to denote the subfield of an object to filter on.
Example:
GET /v1/secrets?filter=metadata.name=foo
Filters are ANDed together, so an object must match all filters to be
included in the list. Example:
GET /v1/secrets?filter=metadata.name=foo&filter=metadata.namespace=bar
Arrays are searched for matching items. If any item in the array
matches, the item is included in the list. Example:
GET /v1/pods?filter=spec.containers.image=alpine
Filtering and sorting needs to operate on unstructured data. It also
needs to operate after the parallel partitioner, higher in the store
stack. This means that the proxy Store needs to return raw, unstructured
data up to the partitioner. This change moves all conversions from
unstructured Kubernetes types to apiserver objects up from the proxy
store into the partitioner.
