• 0 Posts
  • 22 Comments
Joined 1 year ago
cake
Cake day: July 8th, 2023

help-circle

  • If I see comments explaining every other line, especially describing “what” instead of “why”, I assume the code was written by a recent grad and is going to be bad. Describing what you are doing looks like you are doing a homework assignment.

    Like on that line, obviously we’re initializing a variable, but why 1 instead of 0? Could be relevant to a loop somewhere else, but I guess I’ll have to figure that out by reading the code anyways.



  • In all those scenarios though, the cert in question would be listed as something else. It’s not that I’m against Coursera or think it’s a bad platform.

    There are a lot of certs out there and most of them are worthless, and a lot of them happen to be on Coursera, I guess. I’ve talked to people who had AWS certs and couldn’t explain the difference between S3 and EBS. Certs just don’t mean much.


  • Once you get your first job, the certs of all kinds just become resume fluff, but since you are pursuing your first job, they might be useful.

    As an interviewer, I think that certs are only useful if you take the test with a different company than you studied with. So I don’t think I’d care if you have a coursera cert, because I’d assume it just meant you finished the course that you paid for.

    What certs are you thinking about doing, and more importantly, what are you looking to get out of them? I know “a job”, but what kind of job are you looking for?









  • There is a lot of complexity and overhead involved in either system. But, the benefits of containerizing and using Kubernetes allow you to standardize a lot of other things with your applications. With Kubernetes, you can standardize your central logging, network monitoring, and much more. And from the developers perspective, they usually don’t even want to deal with VMs. You can run something Docker Desktop or Rancher Desktop on the developer system and that allows them to dev against a real, compliant k8s distro. Kubernetes is also explicitly declarative, something that OpenStack was having trouble being.

    So there are two swim lanes, as I see it: places that need to use VMs because they are using commercial software, which may or may not explicitly support OpenStack, and companies trying to support developers in which case the developers probably want a system that affords a faster path to production while meeting compliance requirements. OpenStack offered a path towards that later case, but Kubernetes came in and created an even better path.

    PS: I didn’t really answer your question”capable” question though. Technically, you can run a kubernetes cluster on top of OpenStack, so by definition Kubernetes offers a subset of the capabilities of OpenStack. But, it encapsulates the best subset for deploying and managing modern applications. Go look at some demos of ArgoCD, for example. Go look at Cilium and Tetragon for network and workload monitoring. Look at what Grafana and Loki are doing for logging/monitoring/instrumentation.

    Because OpenStack lets you deploy nearly anything (and believe me, I was slinging OVAs for anything back in the day) you will never get to that level of standardization of workloads that allows you to do those kind of things. By limiting what the platform can do, you can build really robust tooling around the things you need to do.




  • You’re on the right track here. Longhorn kind of makes RAID irrelevant, but only for data stored in Longhorn. So anything on the host disk and not a PV is at risk. I tend to use MicroOS and k3s, so I’m okay with the risk, but it’s worth considering.

    For replicas, I wouldn’t jump straight to 3 and ignore 2. A lot of distributed storage systems use 3 so that they can resolve the “split brain” problem. Basically, if half the nodes can’t talk to each other, the side with quorum (2 of 3) knows that it can keep going while the side with 1 of 3 knows to stop accepting writes it can’t replicate. But Longhorn already does this in a Kubernetes native way. So it can get away with replica 2 because only one of the replicas will get the lease from the kube-api.


  • Longhorn is basically just acting like a fancy NFS mount in this configuration. It’s a really fancy NFS mount that will work well with kubernetes, for things like PVC resizing and snapshots, but longhorn isn’t really stretching its legs in this scenario.

    I’d say leave it, because it’s already setup. And someday you might add more (non-RAID) disks to those other nodes, in which case you can set Longhorn to replicas=2 and get some better availability.


  • Can you easily switch drives in your system? I’ll often do that on my computer because little m.2 SSDs are so darn cheap now. It’s easier and cheaper to pick up a little 64GB drive for one off projects than it is to do a proper backup and restore.

    Also, I’d just go with Tumbleweed. I don’t distro hop like I used to, but that’s because as everyone else is saying, most of the distros have gotten really good. Most of the time, my little projects are trying out specific features of a different distros. So I’ll just pop a new drive in, test drive it, then either switch back or not.