kitallis's comments

kitallis | 2 years ago | on: Show HN: I built a tool to get "Your app was approved/rejected " alerts on Slack

We have around 10 users right now since we haven't marketed it too much. But would love to spread the word around.

We built this in about a week as it mostly piggybacks on a critical piece of infrastructure behind https://www.tramline.app, and hence kind of runs by itself.

So we didn't really care for adding pricing to it. Tramline is what we _really_ build :)

The service itself just currently happens to respond primarily as a Slackbot, but that's just an implementation detail and can be tweaked.

Would love to connect, let me ping you on telegram!

kitallis | 2 years ago | on: GitHub Actions could be so much better

> If I'm fixing CI I always put it on a feature branch and do a squash merge once I'm done. Because it's never just one quick fix, it's always 3-10 commits.

The problem is GA also does not allow you to commit a new workflow in a branch. It must first exist on your primary branch and then you may tweak it in another.

kitallis | 2 years ago | on: GitHub Actions could be so much better

One of my biggest gripes with Actions is that it doesn't allow you to trigger workflows for a specific SHA. Only the branch HEAD.

This is pretty much possible in all other CIs.

kitallis | 9 years ago | on: Deploying PostgreSQL Clusters Using StatefulSets

There's also https://github.com/staples-sparx/Agrajag which I've been working on. It is an abstraction on top of repmgr and repmgrd. It relies on repmgrd for quorum and uses zookeeper as a distributed store for who the new master is. This way your apps/bouncer/HAProxy can read off of it. It does not use zk for leader election and relies on repmgrd for that. It's a move away from the normal repmgrd style of push notifications to a pull + broadcast mechanism. This allows many nodes to broadcast the same information (increasing the surface area of success) and fencing old masters.

repmgr and repmgrd are written by core contributors of postgres and this is just an orchestration layer (with built-in monitoring) on top of it. It's very much under development at the moment.

More details are here: https://github.com/staples-sparx/Agrajag/blob/dev/doc/tradeo...

There are plans to add more lines of defense in cases where repmgrd dies. I'll be speaking about it a bit this week at pgconf.in if anyone's interested: http://pgconf.in/schedule/a-postgres-orchestra/

page 1