I really really like Steampipe to do this kind of query: https://steampipe.io, which is essentially PostgreSQL (literally) to query many different kind of APIs, which means you have access to all PostgreSQL's SQL language can offer to request data.

They have a Kubernetes plugin at https://hub.steampipe.io/plugins/turbot/kubernetes and there are a couple of things I really like:

* it's super easy to request multiple Kubernetes clusters transparently: define one Steampipe "connection" for each of your clusters + define an "aggregator" connection that aggregates all of them, then query the "aggregator" connection. You will get a "context" column that indicates which Kubernetes cluster the row came from. * it's relatively fast in my experience, even for large result sets. It's also possible to configure a caching mechanism inside Steampipe to speed up your queries * it also understands custom resource definitions, although you need to help Steampipe a bit (explained here: https://hub.steampipe.io/plugins/turbot/kubernetes/tables/ku...)

Last but not least: you can of course join multiple "plugins" together. I used it a couple of times to join content exposed only in GCP with content from Kubernetes, that was quite useful.

The things I don't like so much but can be lived with:

* Several columns are just exposed a plain JSON fields ; you need to get familiar with PostgreSQL JSON operators to get something useful. There's a page in Steampipe's doc to explain how to use them better. * Be familiar also with PostgreSQL's common table expressions: there are not so difficult to use but makes the SQL code much easier to read * It's SQL, so you have to know which columns you want to pick before selecting the table they come from ; not ideal from autocompletion * the Steampipe "psql" client is good, but sometimes a bit counter intuitive ; I don't have specific examples but I have the feeling it behaves slightly differently than other CLI client I used.

All in all: I think Steampipe is a cool tool to know about, for Kubernetes but also other API systems.

Steampipe project lead here - thanks for the shout out & feedback multani!

I agree with your comment about JSON columns being more difficult to work with at times. On balance, we've found that approach more robust than creating new columns (names and formats) that effectively become Steampipe specific.

Our built-in SQL client is convenient, but it can definitely be better to run Steampipe in service mode and use any Postgres compatible SQL client you prefer [1].

You might also enjoy our open source mods for compliance scanning [2] and visualizing clusters [3]. They are Powerpipe [4] dashboards as code written in HCL + SQL that query Steampipe.

1 - https://steampipe.io/docs/query/third-party 2 - https://hub.powerpipe.io/mods/turbot/kubernetes_compliance 3 - https://hub.powerpipe.io/mods/turbot/kubernetes_insights 4 - https://github.com/turbot/powerpipe

I really like Steampipe too. Writing the plugins is quite fun.

I like Makefiles too :) I use them more or less as a command runner, not often to build new targets based on sources (sometimes still).

In particular, I like:

* The ubiquity: it's easily available almost everywhere I touch and if not, it's usually a package install away. * The auto completion: I often define variables with default values at the top, but they can be both easily discoverable and their values can be changed just by typing `make VAR<tab>=foobar ...` * Chaining commands: make targets can be chained with `make target1 target2 target3 ...`. They will execute in the order specified. If I run this too often, I can usually create a 'ew make target that chains them all.

Make is definitely not perfect and could be simpler. My biggest griefs are:

* The abscons list of built-in variable. I can only remember a few of them ("dollar duck `$<` being my favorite), but they are not great to search in the docs and my brain is limited. * The "one line = one shell" is a bit of a PITA for the use case I have. I usually move more complicated script put of Makefiles.

I thought I would have been bitten by the M4 indentation more often, but it's not really a problem for me anymore at this point (my editor _knows_ Makefiles since it's so ubiquitous and does the right thing)

I have Just on my list of things to check, one day...

"I usually move more complicated script put of Makefiles."

We probably all should. But it is valuable a few different ways to have everything in a single file.

Even though it's an ugly mess having a script within another script, with make variables mixed with shell variables mixed with make logic mixed with shell logic mixed with child proc output... the task at hand wants bits from both worlds at the same time, so the mess is also the value.

You can rig up alternative answers for each of those, but really it just means make should probably have a more generic scripting language itself so you don't have to leave it to get something done, like how you don't have to leave awk to do non-record-processing stuff. People don't, but you can basically write anything you want in awk just like in shell or python.

Or it should have less, be intentionally so limited that you can't embed any significant logic in the makefile and so it all lives somewhere else, either way, so long as it's all together, either all in the makefile or all in something the makefile runs.

Is there any announcement for this new Hyper disk feature? That's something I was interested for a long time and I would have missed it if not for this HN post :D

As a follow-up of the availability topic: what's the best to simulate a zone outage on GCP?

Typicality, for this kind of disks (or previously "regional persistent disks"), you want to test that whatever automation you have for failing over to the secondary zone works correctly. It would be great also to be able to test other kind of failures at the zone level.

What is the pattern to use on Lambda if you actually have to call out other services, which may, sometimes, take a long time to answer? Do you make requests with a shorter timeout and have your Lambda fail when it triggers? Do you delegate long calls to a non-Lambda service?

In a case where a dependency has a consistent high latency and you can’t avoid it, I’d run the numbers and see if it’s more worthwhile to just run your app on ECS or something instead.

I find that running your app on ECS is generally a great way to just do away with a whole class of problems. I’ve never found lambda to do away with any of the issues I encounter on ECS.

I don’t feel great about lambda (outside of jobs processing and such) as it sometimes feels like you took your application and broke it into a thousand little footguns where a mistake or bad actor can tank your business, but if your company experiences very spikey workloads or not enough income to pay for 24/7 ECS and such, I can see the appeal.

If you have enougu volume to warrant it, probably re-architecting the lambdas so the before/after part of the calls is a separate invocation, with an adapter service living on ECS that gets a call from the “before” lambda, handles the remote request and response, the calls the “after” lambda with the response.

The simpler solution is often to just lift the app from lambda to ECS without internal changes

It seems like Lambda is not suited for such "hanging" use cases. To me the best use case for Lambda is for an API call that might be made very infrequently, like say 50 times a day. Doing the same with a VM instance (remember, it has to be HA, secure etc) is probably not worth the effort.

There are AWS step functions that might fit this use case. Just another product AWS will charge you to use to perpetuate the serverless myth.

Xfce has libxfceui4, which should be equivalent to libadwaita (I never directly used it, but that was at least my understanding of it)

Separating compute and storage is one of the core idea behind Aurora. They talked about it in several places, for instance:

* https://www.amazon.science/publications/amazon-aurora-design... * https://d1.awsstatic.com/events/reinvent/2019/REPEAT_Amazon_...

Interesting discussion about `jj split` and how it opens up a GUI tool to select what changes you want to pick.

I'm using `git gui` a lot, I think about everydays, to pick up exact what I want to commit or amend my current work. It's not a very fancy tool, but it ships with git by default and I feel it's really underused and could actually make people's life easier for editing undergoing work...

This looks really cool!

I wrote a few applications using both the official Kubernetes client and the asyncio variant from Tomasz. Both have the same problems to me (that you exposed on the comparison page):

The documentation is really terrible (it's even non-existent for kubernetes-asyncio). For the official client, it's hidden deep inside the repository, across hundreds of files (592 at the moment); half the link cross doc don't work, there are rendering issues, etc. It's really a gigantic mess.

The API is extremely verbose, directly the underlying Kubernetes API exposed to Python. It gets the job done and it's better than shell script, but the verbosity + the total lack of a decent documentation (cf. above) makes it hard to use and see what you can do with it. Most of the time, you have to fire the REPL and try a bunch of calls until it makes sense. I like that most of the responses are proper objects, but they display as dict in the REPL and of course, the responses format are not documented in the doc :)

Last but not least: they both lack support for fancy authentication mechanism. We go to Kubernetes through a fancy proxy that require specific TLS settings + an external exec plugin to get the credentials. The official Kubernetes client should have the right support (for what we need at least) in the next major version but the asyncio variant not yet (I made a PR to fix this, but this requires a new version of aiohttp which is not released yet...) Both clients are very similar for the autogenerated code, but also subtly different for all the things around so you can't really expect 100% that what works on one will work on the other.

I'm not sure how kr8s works with this fancy auth system, but at least for the first 2 points, it seems like a huge win, I'll give it a try!

Awesome thanks! Kr8s supports the exec auth and TLS options. If you run into anything that’s missing though please raise an issue and we will get it added.

I'm surprised to see DigiCert name coming that often.

I know they are a major certificate player and that it really helped they supported (signed) Let's Encrypt intermediate certificate for instance (also others, as the article mention), but I don't really understand what do they gain from this? In th end, customers now have more choice, and possibly many free alternatives to DigiCert itself. I guess this kind of people may not all have created certificates through DigiCert in the first place, but I still feel I'm missing something here.

DigiCert did not cross-sign Let's Encrypt; Identrust did.

Python also has doctest https://docs.python.org/3/library/doctest.html since ... a long time now.

The documentation tools are not as advanced as Go's and as far as I know, there's no way to "run the examples" yourself.

It's a great way to write tests for some functions though, to me the sweet spot is for small, without side effects functions. It's totally possible for bigger functions but then all the initialization code and assertions can easily get in the way and make the documentation not super clear.

Dude doc tests are the one thing I really really miss when I moved over from working on python backend to a typescript backend…

Actually unittest as a whole, testing in ts/JS feels like a mess, everything is just fanned out everywhere, there has been such a lack of structure in our codebase. I’m sure there are examples of well organized testing suites, but I’ve yet to find them.

Thing is, most testing frameworks/libraries in JS gives you a lot of freedom to structure the overall testing architecture however you want, without being much picky about it. That means teams writing the tests have to carefully consider their testing architecture, treating it like production code. But most people don't consider testing code "production" code, they treat it like something they should be able to write once and then kind of forget about it.

So zero regard for architecture will lead to "everything is just fanned out everywhere" and "lack of structure", no matter what language you're using, not just JS. What you're talking about tells us more about your team's engineering practices than how messy the JS testing ecosystem is.

I agree 100% with the statement that it tells us more about our engineering team practices, but the question I have is, how to get it better? Python provides rich built ins, which make it easy to compose a rich suite.

It appears that no one else has an issue with it in my group, but I’m the oddball, these guys come from a TS/JS background. They don’t appear to express concern with it.

Are there resources that you can recommend that I can use to get better?

I was blown away this year when I realized Django REST Framework was reading comments from classes to generate docs, for example the welcome message on this page [0] comes from a comment in the code.

[0] https://govscent.org/api/

I've come to really love Python, in all its somewhat slow glory.

Since 2001, it seems: https://github.com/python/cpython/blob/3.11/Lib/doctest.py#L...

I don't know why you'd need to run an example apart from when running tests. After all, the examples have been tested to output what the example says.

That can be useful because the doc website turns into some kind of sandbox where you can tweak directly the test function and see the result without having to write the code yourself.