Is there a way to block arbitrary nodes being reported/discovered/red-status in rundeck? With all the sources feeding in (GCP plugin, resources.xml, etc.) I have often found a job status which applies to "all" is red since the individual instance isn't yet configured, giving a red status to the job.
Would be great if there were a way to do an easy block from the GUI and CLI for all resources for the given node.
You can use custom node-filters rules based on nodes status using health check status (also you can filter by name, tags, ip address, regex, etc). Take a look at this (at "Saving filters" section you've a good example).
Do a .hostnamepattern. in the exclude filter in the job and hit Save.
Simplify-simplify-simplify.
I created a custom resource definition (CRD) and its controller in my cluster, now I can create custom resources, but how do I validate update requests to the CR? e.g., only certain fields can be updated.
The Kubernetes docs on Custom Resources has a section on Advanced features and flexibility (never mind that validating requests should be considered a pretty basic feature 😉). For validation of CRDs, it says:
Most validation can be specified in the CRD using OpenAPI v3.0 validation. Any other validations supported by addition of a Validating Webhook.
The OpenAPI v3.0 validation won't help you accomplish what you're looking for, namely ensuring immutability of certain fields on your custom resource, it's only helpful for stateless validations where you're looking at one instance of an object and determining if it's valid or not, you can't compare it to a previous version of the resource and validate that nothing has changed.
You could use Validating Webhooks. It feels like a heavyweight solution, as you will need to implement a server that conforms to the Validating Webhook contract (responding to specific kinds of requests with specific kinds of responses), but you will have the required data at least to make the desired determination, e.g. knowing that it's an UPDATE request and knowing what the old object looked like. For more details, see here. I have not actually tried Validating Webhooks, but it feels like it could work.
An alternative approach I've used is to store the user-provided data within the Status subresource of the custom resource the first time it's created, and then always look at the data there. Any changes to the Spec are ignored, though your controller can notice discrepancies between what's in the Spec and what's in the Status, and embed a warning in the Status telling the user that they've mutated the object in an invalid way and their specified values are being ignored. You can see an example of that approach here and here. As per the relevant README section of that linked repo, this results in the following behaviour:
The AVAILABLE column will show false if the UAA client for the team has not been successfully created. The WARNING column will display a warning if you have mutated the Team spec after initial creation. The DIRECTOR column displays the originally provided value for spec.director and this is the value that this team will continue to use. If you do attempt to mutate the Team resource, you can see your (ignored) user-provided value with the -o wide flag:
$ kubectl get team --all-namespaces -owide
NAMESPACE NAME DIRECTOR AVAILABLE WARNING USER-PROVIDED DIRECTOR
test test vbox-admin true vbox-admin
If we attempt to mutate the spec.director property, here's what we will see:
$ kubectl get team --all-namespaces -owide
NAMESPACE NAME DIRECTOR AVAILABLE WARNING USER-PROVIDED DIRECTOR
test test vbox-admin true API resource has been mutated; all changes ignored bad-new-director-name
Bellow is the how I watch kubernetes to get deployments status(include added\modified\delete ......)
[boomer#bzha kubernetes]$ curl http://10.110.200.24:8080/apis/extensions/v1beta1/watch/namespaces/kube-system/deployments
{"type":"ADDED","object":{"kind":"Deployment","apiVersion":"extensions/v1beta1","metadata":{"name":"influxdb","namespace":"kube-system","selfLink":"/apis/extensions/v1beta1/namespaces/kube-system/deployments/influxdb","uid":"37a07ded-6a25-11e8-b67e-0050568ddfc2","resourceVersion":"6896550","generation":2,"creationTimestamp":"2018-06-07T07:34:31Z","labels":{"k8s-app":"influxdb","task":"monitoring"},"annotations":{"deployment.kubernetes.io/revision":"2"}},"spec":{"replicas":1,"selector":{"matchLabels":{"k8s-app":"influxdb","task":"monitoring"}},"template":{"metadata":{"creationTimestamp":null,"labels":{"k8s-app":"influxdb","task":"monitoring"}},"spec":{"volumes":[{"name":"tz-config","hostPath":{"path":"/usr/share/zoneinfo/Asia/Shanghai","type":""}}],"containers":[{"name":"influxdb","image":"hub.skyinno.com/google_containers/heapster-influxdb-amd64:v1.3.3","resources":{"limits":{"cpu":"4","memory":"4Gi"},"requests":{"cpu":"100m","memory":"128Mi"}},"volumeMounts":[{"name":"tz-config","mountPath":"/etc/localtime"}],"terminationMessagePath":"/dev/termination-log","terminationMessagePolicy":"File","imagePullPolicy":"IfNotPresent"}],"restartPolicy":"Always","terminationGracePeriodSeconds":30,"dnsPolicy":"ClusterFirst","securityContext":{},"schedulerName":"default-scheduler"}},"strategy":{"type":"RollingUpdate","rollingUpdate":{"maxUnavailable":1,"maxSurge":1}}},"status":{"observedGeneration":2,"replicas":1,"updatedReplicas":1,"readyReplicas":1,"availableReplicas":1,"conditions":[{"type":"Available","status":"True","lastUpdateTime":"2018-06-07T07:34:31Z","lastTransitionTime":"2018-06-07T07:34:31Z","reason":"MinimumReplicasAvailable","message":"Deployment has minimum availability."}]}}}
{"type":"ADDED","object":{"kind":"Deployment","apiVersion":"extensions/v1beta1","metadata":{"name":"prometheus-core","namespace":"kube-system","selfLink":"/apis/extensions/v1beta1/namespaces/kube-system/deployments/prometheus-core","uid":"fa7b06da-6a2a-11e8-9521-0050568ddfc2","resourceVersion":"8261846","generation":6,"creationTimestamp":"2018-06-07T08:15:45Z","labels":{"app":"prometheus","component":"core"},"annotations":{"deployment.kubernetes.io/revision":"6"}},"spec":{"replicas":1,"selector":{"matchLabels":{"app":"prometheus","component":"core"}},"template":{"metadata":{"name":"prometheus-main","creationTimes
......
when I first start curl to watch the deployment api, I notice that it will return all deployments list first (which type is ADDED), my question is that:
Is it always list deployments first when I watch the api?
When I watch something else, like service or ingress, does it
show the same behavior?
Where could I find document or code about this?
Yes, watching without a resourceVersion specified first sends ADDED events for all existing objects.
It is more common to perform a list operation first to obtain all existing objects, then start a watch passing the resourceVersion from the returned list result to watch for changes from that point.
I see that Sentry has an API to list the events in a project: https://docs.sentry.io/api/events/get-project-events/
But there doesn't seem to be any filter for start and end times here to get say, the events that occurred in the last one hour.
Is there any such filter available that I'm missing?
I think what you want is to first search by issues using https://docs.sentry.io/api/events/get-project-group-index/, and then get the latest event for each issue (if you need the level of detail) using https://docs.sentry.io/api/events/get-group-events-latest/
The first endpoint allows you to add ?query= at the end to use the search queries you're used from the UI. You can filter by timerange over lastSeen there.
It is related to this feature request:
Show only events which match filter in Issues screen. (also event &
user count)
https://github.com/getsentry/sentry/issues/15189
Is there any way when using the REST API to get the summary of operations that have completed without returning the nodes.
When using the web admin console after doing an operation I get a summary like
1 node inserted
2 relationships inserted
1 node deleted.
In the examples here I notice there is no example of summary information sent back to the client. I would have to return the nodes inserted to know the insert had occurred.
When doing a request over the network often it is a good idea to minimize the data response size. A quick summary would help with this. is it possible to get one from the REST endpoint?
I'm pretty sure this is not possible. It would be a nice addition, though. Have you filed a feature request?