> Can you recommend some resources for building and sourcing a solar setup like this?
A lot of people like Will Prowse on YouTube[1]. I've watched a few of his battery test videos and it's influenced what I'll end up buying. I haven't watched any of his solar videos.
I've been lurking in r/SolarDIY[2] as well.
I'm buying a bunch of Victron[3] gear. They have forums, HOWTOs, some videos, plus the various product sheets. They have some circuit diagrams too.
The rest is Google and reading blog posts, DIY articles, price comparisons, etc. There are books, but I haven't read any.
I've got basic electronics chops and tinker with things a bit. I'm by no means an expert.
I like https://www.redmine.org/. It’s stable, contains all features I expect from issue tracking, fast, easy to export and configure. And if you must, very easy to go into the code or database and change.
Basically, if we are soon able to accelerate at 5000g, then interstellar flight is quite possible.
In which case I would like to see the suns set on a world orbiting binary stars, please.
Well to be fair, in my country (Denmark), that is mostly the case. For normal purchases, using cash is very much not the norm.
But paying a carpenter, cleaner or similar, who will give a lower rate (and not pay income tax and VAT), that is very much the norm (though socially frowned upon). Also drugs I guess.
Love the return to text based chords/tabs (without all the other crap on top). That is all that is needed really.
This guitar/tab space is ripe for disruption if you ask me.
Yup, we need more data, and it appears the ball is somewhat rolling on this.
And meanwhile we need to try to not jump to conclusions, even though it is so very tempting for believers and sceptics alike.
But interesting is the field or subject of ufology (though I hate that word). It is so mixed with crazy people, very reasonable people, grifters, those who are maybe grifters, disinformation (maybe or just the crazy people or grifters again?) and maybe some real interesting stuff among it all.
If the issues we're talking about stem from claims David Grusch (or people in that circle) made, then enough has been disclosed already to draw some conclusions: when your key witnesses discredit themselves, that is itself a form of evidence.
I agree, it seems like there should be a traditional program on top that's filtering responses for known company secrets, conversations that go against published company guidelines, etc.
An operator operates something, e.g. it actively makes changes. If you want to deploy an application, a Helm Chart is the correct way. It will allow you to have deterministic deployment, that you can duplicate multiple times in your cluster, and you can dry-run it and see the generated manifests.
An operator is needed when you can't just deploy and forget about it. An example is the Prometheus operator, which will track annotations created by users to configure the scraping configuration of your Prometheus instances. Another example is cert-manager, which gets certificates into secrets based on Certificate and Ingress objects, renews them automatically before expiry, and does that by creating ingresses picked up by your ingress controller.
The advantage of an operator is that it will react to stuff happening in the cluster. The drawback is that it reacts to stuff happening, potentially doing unexpected things because changes happen at any time and you can't dry-run them. Another drawback is that they are usually global, so you can't run multiple versions at the same time for different namespaces (mainly because custom resource definitions are global).
Unfortunately many people think packaging an application = creating an operator, and that operator does nothing a chart couldn't do.
The CockRoach DB example in the article is a perfect example of an unnecessary CRD. Acquiring certificates within an Kubernetes cluster is a common requirement for lots of applications and there are lots of solutions out there. Is it really necessary to spend time writing your own operator? Now you have a second helm chart and an operator to maintain. Now you have to explain to people which chart to use. You could get rid of the non-operator chart but now I have operators within the cluster acquiring certificates in 5 or 6 different ways. Do I have to configure the credentials for 6 operators so they can make Route53 DNS challenge records?
Edit: maybe we could shift left and ask the app developers to add certificate acquisition directly into the app source.
That’s true. The actual process of granting a pod access to edit route53 TXT records is pretty easy.
The problem is duplication of functionality within the cluster and increased complexity in the configuration of deployments. I want to configure a certificate acquisition process once, and plug those certificates into pods using a generic process based on annotations. I don’t want to configure it 6 times because each operator does things slightly differently. Each CRD introduces new complexity to the cluster. More opportunities for things to break. More stuff to read and learn about.
I think CRDs should be used to extend the platform functionality, not as a tool to simplify deployments. It feels a little like reworking the plumbing in your house to make the sink easier to install instead of using a wrench.
Or is can be actively harmful when they don't do any error checking whatsoever, causing it to be less accurate that `helm template` would be. Related, it's also one more thing to monitor because it can decide to start vomiting errors for whatever random reason
Neither of those cases really need an operator -- Prometheus and cert-manager both have code that watches for changes on ingresses/services/custom resources and reacts to changes (using permissions granted via RBAC). I've used both without an operator and still use Prometheus without one.
Everyone else commenting is missing the point, because as you've said, Prometheus can discover targets via k8s endpoints/pods dynamically already, and you can run a sidecar to reload the config file.
The main point of Prometheus operator is to federate access to Prometheus configuration so teams can manage configuration that the built-in Kubernetes service discovery doesn't let you control from an application side. Things like scrape interval, recording rules and alerts, etc. ServiceMonitors, PrometheusRule CRDs basically let app owners ship these aspects of monitoring with their applications, instead of having to have a hand-off between the service owners and the SRE teams managing the monitoring infrastructure.
Pronetheus does not change its config if not asked to do it… and in most cases scrape config is stored in a configmap that does not change by itself magically.
So yes -> you need an operator to dynamically change config of prometheus. If not -> all your changes wont matter because they will be not reflected in prom.
There are several Prometheus helm charts out there. The one I use runs a sidecar container that watches for config changes and tells Prometheus to reload the config. So you don't need the operator - there are other approaches.
Wdym the configmap doesn't change by itself? I don't want my configurations changing "magically" without my say so
The two features I need (and can get without the provider) are:
1. If I (manually, explicitly) change the configmap, prometheus can pick it up without being restarted. This is provided by the side-car container.
2. If new pods come online they are automatically detected and scraped by Prometheus. As long as they have the annotations saying: a) this pod should be scraped, b) scrape on this port, and c) scrape at this URL - then they will be scraped.
I dunno what to tell ya, I see pods come and go from Prometheus all the time, including those from newly added Service objects with Prometheus annotations. I'm using kubernetes_sd_configs.
You don't NEED an operator, but there are benefits.
If all of your pods have the same scrape settings, there's not much benefit to the operator. But if each pod or set of pods needs custom scrape settings - say different scrape intervals or custom tag re-writes, the operator will let you define each set of scrape configs separately as kubernetes resources. You can store the definitions alongside the resources they scrape instead of having a single large complex config in your prometheus deployement. This would be especially beneficial if you have multiple projects owned by multiple teams, all scraped by the same Prometheus.
Granted I also don't use the operator, but I've looked into it. With complex enough deployments it would simplify things.
I worked on an operator that manages Kafka in K8s. If you want to upgrade the brokers in a Kafka cluster, you generally do a rolling upgrade to ensure availability.
The operator will do this for you, you just update the version of the broker in the CR spec, it notices, and then applies the change.
Likewise, some configuration options can be applied at runtime, some need the broker to be restarted to be applied, the operator knows which are which, and will again manage the process of a rolling restart if needed to apply the change.
You can also define topics and users as custom resources, so have a nice Gitops approach to declaring resources.
i know what you mean, but i am doing this for more than 20 years now. From bare-metal over openstack to serverless, i have pretty much provisioned all of them.
Kubernetes is more like a way of doing things than a technology. Basically APIs all the way down. and thus the operators and controllers do deserve love.
Im not saying that you need an operator to change the dipers of a baby, but as far as a stack goes, k8s is the best i have ever worked with.
A good example from my perspective is when you are delivering an application as 3rd party vendor and you wish to automate lot of operational stuff like backup, scaling based on events, automating stuff based on cluster events. It starts becoming very valuable. I am sure there are many more use cases for.
I would not write an operator to do any of these things. To me an "operator" strongly implies the existence of a CRD and the need to manage it. So for autoscaling, HPA/VPA are built into k8s. Backups should be an application-level feature; when the "take a backup" RPC or time arrives, take a backup and dump it in configured object storage. Automating stuff based on cluster events also doesn't require an operator; call client.V1().Whatever().Watch and do what you need to do.
The only moderately justifiable operator I've ever seen is cert-manager. Even then, one wonders what it would be like if it just updated a Secret every 3 months based on a hard-coded config passed to it, and skipped the CRDs.
Operators make sense when you need to automatically modify resources in response to changes in the cluster's state.
An example that has come up for me is an operator for a Kafka Schema Registry. This is a service that needs some credentials in a somewhat obscure format so it can communicate very directly with a Kafka broker. If the broker's certificates (or CA) are modified, then the Schema Registry needs to have new credentials generated, and needs to be restarted. But the registry shouldn't (obviously) have direct access to the broker's certificates. Instead, there's a more-privileged subsystem which orchestrates that dance; that's the operator.
kubernetes itself is a collection of controllers/operators. It takes manifests like pods and uses that information to create the workload in your container runtime on a node with the resources it needs.
