Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Etcd, or, why modern software makes me sad

roguelazer.com

Post reply on HN
Print view View original

261–270 of 648 posts

Re: Etcd, or, why modern software makes me sad

#261

Post by atombender »

regularfry wrote: post #98
jonfw wrote: post #70

Earlier quoted context omitted.

What's wrong with the YAML? It's easy to read and write, concise, and generally has sane defaults meaning you don't have to be overly verbose.

Spending 6 hours tracking down a `loadBalancerIp` that should have been a `loadBalancerIP` feels like a problem that shouldn't have happened.

YAML can be validated using JSON Schema/OpenAPI, and somebody does maintain Kubernetes schema definitions, including Kustomize, which can then be used in an IDE for live validation. For example, the Kubernetes extension for VSCode does this.

If you use Helm, writing and validating schemas for Helm value files is trickier, and not something I believe anyone is doing. It should be easier to do. Ideally you should simply put this at the top of a value file:

  $schema: ./schema.yaml
But from what I know, there's no editor/extension, that supports validating through such a declaration. Secondly, Helm doesn't have a way to statically analyze value access. Something like {{ .Values.missTypedKey }} will only be caught when you generate the manifests.

Re: Etcd, or, why modern software makes me sad

#262

Post by atombender »

aliswe wrote: post #175
tapoxi wrote: post #122

Earlier quoted context omitted.

In the Kubernetes and Ansible/Salt world it's frequently templatized, and then you need to worry about indentation that you place or your template engine places. Every day I pray that Helm will incorporate support for jsonnet so I never need to touch YAML again.

I made a script for expressing similar deployments (ie homepage-en, homepage-de) in a variety of contexts (test, prod) and their permutations in a single, succinct json file. It's a bash script though. Example json: { "deployments": [ { "name": "site-en", "env": { "hello": "world" } } ], "targets": [ { "name": "dev", "context": "aks-dev", "env": { "ipsum": "dolor" } } ] }

You should look into Kustomize. It's built into Kubectl, and lets you do something like this in a much more modular way.

Re: Etcd, or, why modern software makes me sad

#263

Post by vorpalhex »

jonfw wrote: post #70
ixtli wrote: post #47

I run k8s in production and I think this is a really bizarre axe to grind that sort of smells like someone who got upset by how steep the kubernetes learning curve is. Which, in a way, is understandable. > 1) Add hundreds of new failure modes to your software In my entirely anecdotal experience, it removes error modes. It turns out that just because k8s offers a feature (it offers many!) doesn't mean you're required…

What's wrong with the YAML? It's easy to read and write, concise, and generally has sane defaults meaning you don't have to be overly verbose.

YAML is easy to read and write in tutorial documents. It becomes a complete mess in real life and whitespace based syntax is horrendous to debug. We have had endless heartaches due to minor yaml issues and today employ tooling to minimize the amount of yaml engineers write to avoid these issues.

Re: Etcd, or, why modern software makes me sad

#264

Post by jazzyjackson »

flatline wrote: post #233
IggleSniggle wrote: post #186

Earlier quoted context omitted.

TypeScript is a funny one. I love the language, but at the same time, I totally agree with the premise that it is unnecessary complexity! And yet I swear by it. I can't explain why there's not more cognitive dissonance there. JavaScript taught me to love async, then functional programming, and TypeScript taught to me to love static types. I'm now desperately wishing for a world of OCaml/Haskell, but where are you goi…

What is unnecessarily complex about TypeScript? It's JavaScript, with static typing plus type inference, and pretty nice generics. The ecosystem of modern JS surrounding it is horribly complex but TypeScript itself seems like a fairly straightforward programming language.

It hasn't been a big detriment for me as someone learning Typescript on their own, but it is another moving target for looking up "how do I do x..." and finding most of the forum posts are a little outdated and the latest version of Typescript has a different/better way of doing things than just a year or two ago. I find myself scrolling through github issues comparing my tsconfig to figure out why my stack behaves differently than someone else.

Re: Etcd, or, why modern software makes me sad

#265

Post by wahern »

Florin_Andrei wrote: post #198
mvanga wrote: post #133

This is one weird comment section. There are people attacking the author for a statement made about CoreOS, and for some hate towards Kubernetes. The key point of the article is not really being addressed here: vested interests from large companies are able to introduce huge complexity into simple, well-designed projects. While the complexity may be good for some end that said vested interest has in mind, they are al…

But that's just the "circle of life" no matter what. Things start very simple, and then inevitably get ambitious and try to add new gizmos. Sooner or later you end up with a monster. Over and over again.

Historically FOSS has been far more resistant to this cycle; not all FOSS projects, but many. It's much easier for FOSS projects to just say no, and they can spend years or even decades refining things. In the commercial world you can never say no. Not only that, but you have to constantly add features.

Now that corporate interests dominate in many corners of the FOSS sphere, this benefit of FOSS is diminishing. Which is a shame, because it's a big reason why FOSS was so successful, and why so many old commercial projects collapsed under their own weight, even though they always had more features than their FOSS counterparts and thus theoretically should have only grown their user base.

Re: Etcd, or, why modern software makes me sad

#266

Post by wh-uws »

jrockway wrote: post #72

As far as I can tell, the only thing this article is saying is that the author doesn't like gRPC, preferring hand-rolled APIs. (The rest of the rant doesn't really talk enough about the problems to respond to. The author doesn't like Kubernetes. The author doesn't like systemd. The author doesn't like software-defined networking. No reason is given as to why, so there is really no way to have a constructive conversat…

thanks for the succinct explanation of gGRPC over HTTP / REST / whatever.

I've been trying to figure that out for a while.

Think your analysis is spot on overall.

The author strikes me as the person who was saying "why can't I just keep writing Assembly?" in the 90s .

The answer is you can keep using .

But don't be mad when people are using the new abstraction layer to build interesting stuff because they don't have to worry about the lower level as much.

Re: Etcd, or, why modern software makes me sad

#267

Post by sercand »

brabel wrote: post #246
alpb wrote: post #189

Earlier quoted context omitted.

First of all etcd API is still available on a JSON interface. https://github.com/etcd-io/etcd/blob/master/Documentation/de... and some historical discussion here: https://github.com/etcd-io/etcd/issues/1980 Many reasons to switch from JSON to gRPC: * gRPC uses HTTP/2 which means you can concurrently make multiple requests on a single TCP connection, while on a typical JSON API which probably uses http/1.1, you can't.…

> gRPC uses HTTP/2 ... while on a typical JSON API which probably uses http/1.1, you can't. What are you actually talking about? An HTTP API by itself doesn't actually care about which http version is used, that's something only the HTTP server that serves the API should care about (nowadays, pretty much any http server in any language supports HTTP/2 and 1.1). > Bi-directional streaming e.g. Kubernetes controllers u…

By using gRPC, we get much more without thinking too much. Also, bi-directional streaming is instantaneous and it is not like afterthought long polling.

For example, whole etcd API is located at https://github.com/etcd-io/etcd/blob/4c6881ffe4b3bae257c0720...

It is pretty straightforward and not too hard to understand the API. Designing APIs with protobuf makes things convenient and it brings lots of already written tools with it.

Since gRPC built on top of HTTP/2, we thought gRPC as easiest and performant way of writing a HTTP API with good defaults.

Re: Etcd, or, why modern software makes me sad

#268

Post by chrisweekly »

derefr wrote: post #217
KaiserPro wrote: post #190

Earlier quoted context omitted.

HTTP2 fails for mobile clients. it shoves everything down a single TCP connection. This means that if you loose a packet (and 4g is lossy) it stalls the _entire_ queue. Instead of addressing the main complaint (that multiplexing everything down a single TCP connection is a fundamentally stupid idea) they come up with an entirely _new_ protocol. It also fails to understand what HTTP2 has turned into: a file transport…

To be clear, it's not like there are any HTTP/2- only servers in the world. HTTP/2 is something a client connection upgrades to. One might think of HTTP/2 and HTTP/3 not precisely as versions of HTTP, but rather as variants —HTTP/2 is "optimized binary HTTP, fixed-station profile" and HTTP/3 is "optimized binary HTTP, mobile-station profile." (Mind you, they are versions relative to each-other , because HTTP/3 is str…

Bravo! Fantastic comment. So many people get this wrong, and you've articulated it clearly. Thank you!

Re: Etcd, or, why modern software makes me sad

#269

Post by blixtra »

dharmab wrote: post #61
alpb wrote: post #35

Author is really good at discrediting themselves straight off the bat in one sentence: > for a ~~bullshit~~ unsuccessful project called CoreOS Container Linux that was EOL'd several years ago CoreOS was actually quite successful to me as an outside observer. It had decent paid user base as well as people using it without paying. It has showed people that Chrome OS can be used to build atomically updating host OS with…

My team ran about 50% of a Fortune 500 software company on CoreOS up until a few months ago when we migrated to Flatcar. We even paid a lucrative support contract while we ran it. I can count the number of major OS issues we had with it over several years on one hand- and we've had even better success with Flatcar so far. Calling CoreOS unsuccessful is a massive misunderstanding of the market.

Chris from Kinvolk here. Happy to see you're having success with Flatcar. We, of course, agree that CoreOS Container Linux was a huge success. The uptake that we've seen in Flatcar usage, especially since the CoreOS EOL date on May 26th, has been extraordinary. So from what we a can see, the market is there for a minimal Linux for containers and and we're happy to continue filling that need with Flatcar.
Post reply on HN