Helm is an abomination, as the whole idea of using a text template engine to generate YAML is. And this vulnerability adds insult to injury ;)
Sorry, just can't really recover from trauma of counting spaces and messing up newlines, etc. when writing Helm templates. You know, Lisp "sucks" because "you need to count parenthesis" (you actually don't), yet Helm is a widely accepted technology where you need to count spaces for (n)indent ;)
I'm a dev that jumped to devops and one of my pet peeves will always be the lengths devops engineers go to avoid using a real programming language. Instead of interacting with all these APIs through python, ruby, lua, go, whatever they would rather build hodgepodge systems in bash, coreutils, curl (or wget. or both!) and jq (which is the worst). Or in the case of helm, just creating a half yaml/half Go SDK for generating YAML.
Even the helm infrastructure that I work in is completely wrapped in custom shell scripts that call all sorts of other commands to populate helm variables.
But yeah it's silly that helm templates require all sorts of {{ indent | 4 }} type incantations when the final YAML output is just sent through some kind of toJSON anyway.
You'll often find that if you write ops scripts in, say Python, it's largely calling external commands.
When that's the case, bash if often the better choice, especially if you know it well. It has an excellent REPL, is easy to trace and is already installed everywhere.
> You'll often find that if you write ops scripts in, say Python, it's largely calling external commands.
That's a totally fine trade off for actual sane array/list functionality, robust string manipulation etc. I'd rather form shell commands in a programming language than in bash. People seem to love it.
I do not think for a second though that the average person that "knows bash well" can read and comprehend a multi hundred line bash script written by someone else as fast or even correctly has a seasoned python dev reading python written by someone else.
> the lengths devops engineers go to avoid using a real programming language
OK, but, you know... those tools were created by literal devs. Not in yaml, in a "real language"! So apparently devs thought they needed that.
The argument should be towards all people - we love creating new abstractions and "simplify things", but we suck at honest evaluation of the impact of our creations.
Still: I absolutely hate Helm templating and think that the very existence of "helpers" (even in a default chart!) is an abomination.
> OK, but, you know... those tools were created by literal devs.
All `kubectl` does is create REST API calls to the control plane. So to be fair, what I'm grousing about can be accomplished just fine by a developer like me constructing API calls from python to update objects in k8s.
The problem is I work in devops where tooling written in proper languages with standard libraries that have things like useful arrays or robust string manipulation or ergonomic concurrency is a non-starter for some reason. The argument against that being mostly "I have to install the interpereter first".
Now we get to the point - you are unhappy with how your org/team handles it. Would that be better description? Don't put all DevOps in one basket. It's a messy term anyway.
Many orgs and many teams allow that. That's why alternatives to Helm exist like cdk8s, or Pulumi for rest of infra.
For Kubernetes there is such a variety of tools, it's overwhelming. The only problem to tackle is that Helm/Argo is so popular, that alternatives are hard to sell regardless of real benefits.
Look at how big is a scene of Operators for k8s - this is where the programmable part of k8s went. You configure operators with their own CRDs (usually) that can be static/plain declarative text. Then you write actual code of the operator that deals with all the complexity of enforcing that state. For me this is where typically what you are talking about goes, while high level "non programmable" code sits in yaml in a other repo for others to maintain. Maybe this is where you should also go, standardize your work for others to consume in a form of operator?
I fully get neglect in adopting more complex tooling. sh, curl, sed, awk... those things are present almost everywhere and it's not that hard to get lucky and make a script that will run on almost everything your org has. And it actually might be fine for a decade or so.
I myself could not do code (even scripting) because one of my companies literally treated scripting in anything as development which was strictly regulated (so forbidden for any non dedicated dev role). Or an org that had not a single server in whole DC that has Python 3, years after it's release. Or more recent: some damn Ubuntu LTS that can't be easily upgraded to just 2-3 minor versions that this cool k8s library uses. Maintaining python versions on VMs is a pain in the ass, especially if your org has strict controls. Internet access to pip is not granted as well. UV gets the job done nowadays, if it's allowed, but long story short: that "fear of real language" can be as much lack of knowledge/skills as pragmatism that came from painful experiences.
Yeah, vi has supported % as "jump between matching parenthesis" since it's original release in the 1970s, and vim by default will do simple parenthesis matching and highlighting, I don't see why everyone is so scared of touching lisp for these reasons with modern editors (if your editor doesn't support either of the above... maybe it's not modern enough?)
… and I think I'd argue that the parent's argument against the tooling would apply equally as well to those "other things", too.
The alternative here is something that manipulates the data structure directly. E.g., it might permit me to say:
my_config_map.data["key"] = some_string_value
(This is in some pseudo-imperative language, vs. the parent's Lisp, but that distinction isn't particular relevant to the core of their argument, I think.)
And then at the end, the thing itself takes care of converting the resulting objects to YAML, thus preventing me from inadvertently turning what is meant to be a string into something like an accidental YAML-injection that results in terrible errors because I miscounted the number of spaces to indent something.
I wrote a small terraform wrapper around helm provider that basically does what you’re saying. official kubernetes + tf support is poor, but it’s been working well for me. I rarely if ever have to touch the yaml templates that I maintain.
however, this is usually true with working with helm in general if you are using charts other people maintain. That’s one of the strengths of helm. you just shove your values into the chart and it should work. Maintaining charts is not fun though which is why I wrote the wrapper for my purposes.
The funny thing is helm is as good or bad as what you make it. When folks complain about helm they are actually complaining about their own self created charts or poor selection of charts they install.
I don’t think there is a lot of overlap between people who say lisp sucks because of the parens and people who are fine with using a template to generate yaml.
I like wrapping with kapp for this. However kustomize still skips hooks if you inflate a chart that uses them and there is value in discoverability of helm apps installed with clear versioning
I used OpenMPTCPRouter to aggregate 3 LTE connections (via routers connected to directional antenna, with SIM cards from different operators) when I was living in a house in the woods before the war has started I had to leave Russia.
Worked like a charm, giving me up to 180 Mbps or so. May not be that good for aggregating different types of links together, but for using multiple cellular connections it's nearly a perfect solution.
BTW 5G 3GPP specs include MPTCP support, IIRC for aggregating connections going via different gNodeBs (base stations)
Common Lisp has CLOS (Common Lisp Object System), which is quite sophisticated object system with metaobject protocol and multiple dispatch, as a part of its spec. Not that it's smth people need to invent on their own each time
Well yes. The problem isn't people building their own implementation. The problems with Scala aren't with them inventing their own type system, or pattern matching, or whatever. It's the lack of agreement on what is the idiomatic subset of features to use in a given environment.
I would think that Scala is slightly more object-oriented than Common Lisp, given that one can mostly ignore OOP in some Common Lisp applications. Thus that part already (macros !) makes CL very flexible in expressing different ways of programming. CLOS without MOP has a range of possible use. I haven't thought about how consistent typical code actually is, using CLOS without MOP. My intuition would say that there is some common CLOS style, but maybe that's wrong. It would be an interesting question to look at, how CLOS code bases make use of its features and if they share common architecture principles. Actually there is not that many literature on software engineering principles for CLOS. For example see: "CLOS in Context: The Shape of the Design Space" by Bobrow&Gabriel&White.
The MOP itself was thought to make CLOS programmable and thus to support a wide range of different object-oriented styles in a single language framework. In practice there is use of that, but it's not that common and actually also a bit complicated/tricky/challenging to program the object system in itself for different behavior.
Others mention autonomous mode thing being overhyped somewhat.
But besides, that starts to remind me of home automation in Ray Bradbury's "There Will Come Soft Rains"... There was also a Soviet animation film based on that short story https://www.youtube.com/watch?v=5LNHYz89sNc
Yep. Many complain that with Lisp, you need to count parentheses (spoiler: you don't need to). And then proceed to count spaces for indent/nindent in the charts... That's somehow ok with almost everyone
I can't actually put it into production at my company, but for selfish catharsis, I ran datamodel-codegen over our cluster's jsonschema and generated Python pydantic models for all resources. I was able to rewrite all our helm using pure Python and Pydantic models, since Pydantic serializes to json and json is valid yaml. Felt pretty good
We don't have any CRD, but the approach would extend to those, plus you get auto complete. The k8s jsonachema isn't super easy to work directly with, though.
Not just helm. There are probably a half dozen tools for rendering manifests in our company, only some use text/template, and they all suck. Text replacements are bad. Declarative structured patches are bad. Control flow in JSON is bad. We've had a language for dealing with generating complex nested structured data for years!
Have you seen Jsonnet, Dhall, and Cue? They are configuration language that are more limited than general purpose languages, more powerful that static, and designed for config files unlike templates.
text/template is probably ok... For some version of text. ditto with jinja and most templating languages. The cardinal sin of DevOps is using text macros to produce structured data. It only exists because unfortunately there is no other lowest common denominator for every config file syntax.
Sure and that forgives its use in maybe, like, Salt and Ansible. Not in Kubernetes where everything is structured in the same way, even with API-available schemas, to begin with.
I grew up in Russia, and ES-1841 was my first computer, too.
Also with a printer, yet no HD.
That was 1990 and I was 10 y.o... Once printed a caricature of one of school bullies using (a Soviet clone of) Turbo Pascal and its turtle graphics facility, resulting in a fight.
My favorite pastime was writing DOS viruses in asm, though... I didn't spread them, just wrote some for fun.
Found some of my virus code written down a couple of years ago https://pbs.twimg.com/media/E-jP39nXEAAve0O?format=jpg&name=...
I guess I'm not the only kid who was into assembly! Impressive stuff. In 7th grade in 2001 I moved to the US, and got really into the whole TI-83 ecosystem. Got a sprite editor published to ticalc.org, and memorized the z80 opcodes in hex so I can write simple asm programs directly on the calculator.
In 8th grade I started socializing and lost the gift. Still can't believe I did all that.
My English is worse than yours, but still, if anybody is curious.
I'm really impressed with your documentation. I started at around 94 with Turbo Pascal and really struggled with absence of good books/reference materials and lack of English language knowledge, as I studied German in school.
Positioning (fn42h)
When pointer is moved [advanced?], take value of highest bit of CX register as special flag value. After jump? [hard to understand, the literal work is positioning], when pointer will point the code "LATRO", add or subtract from the pointer the value offset veryend [not exactly clear]. If pointer points after end of the file and MS DOS [interrupt?] is triggered decrease from DX:AX offest veryend (Elementary!)
Reading (fn 3Fh)
In case if current position < 1Ch, then, later remembering to restore current position, read necessary amount of bytes from the end of the file (eof - |offset veryend - offset save_area|) [it is not clear, but it really looks like there is modulo]. During capture of LATRO area, trim the read (SRF).
^ (curpos + numread) > (eof -offset veryend)
Let me guess. Питер Абель, Язык Ассемблера для IBM PC и программирования. ?
I remember when I first got on the Net in 1993, almost none of the sites I wanted to connect to had DNS entries so I had piles of notepaper filled with random IP addresses.
Well... I did more than I've described in the post (I'm the article's author). It just became too large, so I've decided to stop and publish a second part once I run more tests and fix some problems.
So far, I have yet to figure out all the problems and settings with Netronome (or give up on it). Still, it is Netronome-specific as I can easily get line rate over TCP single stream with Mellanox cards, and the CPU doesn't even break a sweat (however, I have relatively simple routing rules).
I want to try out programmable NIC, and as far as I understand, Netronome has some support there; I just wanted to get a simple setup running first and then optimise/improve it. I tend to perfect the setup, and if I let myself do more and more and more - I will always need more time to finish it.
The 1987 Brazilian accident in Goiânia was horrendous because the caesium-137 capsule was breached and there was widespread contamination by radioactive dust. I get chilled to the bone when I read the descriptions of people innocently playing with the curious glow-in-the-dark dust as a novelty, showing to their neighbors and friends.
> The apartment was fully settled in 1980. A year later, an 18-year-old woman who lived there suddenly died. In 1982, her 16-year-old brother followed, and then their mother. [All from leukemia]. [...] A new family moved into the apartment, and their son died from leukemia as well.
> A child's bed was located directly next to the wall containing the capsule.
Actually "haunted" locations are often linked to carbon monoxide and infrasound, IIRC. We generally don't blame ghosts for mysterious burns or other signs of radiation sickness.
It's possible that the apartment came furnished and that the bed being referred to was not a specific child's but rather a bed made for a child in which supposedly multiple children slept in before dying.
I find this syntax argument a bit strange nowadays.
There's this extremely popular Kubernetes tool called Helm, which uses go-templated YAML to generate Kubernetes resources.
The template syntax is nothing short of horrible. An endless maze of {{ ... }}s, where it's just too easy to shoot oneself in the foot by using {{- or -}} in wrong place, etc. And on top of that, you literally need to count spaces for nindent (mind you, you don't need to count parentheses while writing Lisp code).
I'd say Lisp syntax is clear as day when compared to your average Helm template.
Sorry, just can't really recover from trauma of counting spaces and messing up newlines, etc. when writing Helm templates. You know, Lisp "sucks" because "you need to count parenthesis" (you actually don't), yet Helm is a widely accepted technology where you need to count spaces for (n)indent ;)