121–130 of 142 posts
Earlier quoted context omitted.
Oracle.
In fairness, Oracle keeps developing JVM and Java rather nicely, and keeps it open enough. I had expected worse.
Earlier quoted context omitted.
I knew this would happen eventually. The images always looked nice, but were so hopelessly entangled in the Bitnami world there was no chance of forking them, or easily migrating away. Good thing I dodged that bullet… never trust a commercial vendor that trades you convenience for interoperability.
To me the images always looked overly complex, to the point where I frequently felt more at ease just doing an image from scratch myself. They never felt like a good fit for production systems. I also know a ton of people and project who are now sort of screwed, because they can not possibly maintain a fork do to the Bitnami complexity, but there's also a reason why they didn't just do their own image. This did feel…
Earlier quoted context omitted.
Broadcom is just private equity buying products to bleed dry. Nobody thinks VMware is the future, but the folks that use it are enterprises with deep pockets who are slow and reluctant to change so you can multiply the price by big numbers and get paid big while your dying acquired product meets its end.
VMware's lock on enterprise virtualization simultaneously made it essentially impossible for anyone else to compete like-for-like using a different platform and probably also doomed VMware's attempt to start pivoting to containers.
Earlier quoted context omitted.
I’ve never used Helm charts. I learned K8S in a shop in which kustomize is the standard and helm is a permitted exception to the standard, but I just never felt any reason to learn helm. Am I missing out? Sometimes the limitations of kustomize annoy me, but we find ways to live with them
Kustomize is nice but you’re missing out on objects lifecycle management. Kustomize had the issue that it would leave objects dangling in the cluster and you had to manually clean them up of you removed them from your kustomization file.
Earlier quoted context omitted.
VMware's lock on enterprise virtualization simultaneously made it essentially impossible for anyone else to compete like-for-like using a different platform and probably also doomed VMware's attempt to start pivoting to containers.
We were pretty successful moving to proxmox. They dont have the support some companies want but xcpng does. There are half decent options out there for corp use.
Earlier quoted context omitted.
Ah, I must have met some lazy charts then. Thanks for the correction. Still, it seems like that schema would end up a little inconvenient to integrate into your editor for writing the templates...
> a little inconvenient to integrate into your editor for writing the templates... Another way that JetBrains tooling shines, because it automatically turns on JSON Schema support for the chart when it has one, no extra # schema=file://... dumbness required
I was talking about the go templates that make up the actual chart. Ensuring they only use string values for annotations for example seems like a hard problem to solve. Even just showing the type and description from the schema seems nontrivial.
Earlier quoted context omitted.
We were pretty successful moving to proxmox. They dont have the support some companies want but xcpng does. There are half decent options out there for corp use.
There are. I worked for a company that had a good KVM-based enterprise virtualization alternative with support. But they never had great commercial success with it displacing VMware. I understand they're having a lot more luck with a kubevirt-based option today post Broadcom acquisition of VMware.
Earlier quoted context omitted.
> a little inconvenient to integrate into your editor for writing the templates... Another way that JetBrains tooling shines, because it automatically turns on JSON Schema support for the chart when it has one, no extra # schema=file://... dumbness required
That is when you are writing the values when using the chart though, right? Yeah that's not too hard. I was talking about the go templates that make up the actual chart. Ensuring they only use string values for annotations for example seems like a hard problem to solve. Even just showing the type and description from the schema seems nontrivial.
---
As for the "only string values for annotations," I think you mean patternProperties:
{
"$schema": "http://json-schema.org/draft-07/schema",
"type": "object",
"properties": {
"annotations": {
"type": "object",
"description": "this is the description of the annotations key itself",
"additionalProperties": false,
"patternProperties": {
"^[a-z][a-z0-9./]+$": {
"type": "string",
"description": "holds the value of the annotation"
}
}
}
}
}
annotations:
alpha: 123
annotations:
_: xxx
0xcafebabe: denied
If you mean schema checking on the output, that is checked by the OpenAPI built into Kubernetes itself, so yes, doing something silly in golang templates will not, by itself, check the result - that's one of the major limitations of Helm's moronic choice of using a text templating language for a structured file format
Earlier quoted context omitted.
In fairness, Oracle keeps developing JVM and Java rather nicely, and keeps it open enough. I had expected worse.
Java has a much stronger open source community with lots of corporate players. If Oracle tried to close the doors on it, everybody can pivot away in much shorter time than Vmware.
The large majority of work done in OpenJDK is by Oracle employees.
Had it been for most of those players, Java 6 would have been the last version.