HN user

balou

293 karma

R&D at Wiredcraft, co-founder of http://devo.ps, zbal on github.

Posts20
Comments24
View on HN

OP here, the post is only a simple trick that may be of some use to some people.

Eventually we merged that logic in an in-house app we built back in the days when the containers orchestration tools were still "rare", if i recall https://github.com/toscanini/maestro had just launched but wasn't really usable yet...

I'm perfectly fine with the DNS/DHCP approach, just wondering what are the alternatives out there. That dnsmasq approach worked like a charm for several of our projects for 1+ year.

Always wondering of the extra round-trip on DNS request when we could have a hardcoded value in the host. We're talking local network so the latency ain't much of an issue but still. Then there is the possibility of a dnsmasq restart when a request occur, caching ala nscd could work, but then we're in for a lot more trouble when it comes to expire that cache !

I'd love to hear about other people's workflow when it comes to address that issue - are you simply re-provisoning the all shebang if a critical component is to be updated or change? or relying on etcd/zookeeper as mentioned? or ...

Really? I'm so surprised to see so many "Awesome! Go for it" answers to this.

While I admire the dedication and focus it takes to stay up to such routine, I am certainly concerned by the quality of life and the narrow mindedness of enforcing upon oneself to code on a daily basis. What about days off? Going out friends / family for a weekend or holidays? One would suggest to bring your laptop so you can stick to it? This is madness to me...

I love to code, contribute to OS projects, do code for a leaving and for myself - but for nothing in the world I'd even attempt such thing.

Setting yourself with goals is great and required to some extend but on a proper schedule. Going to the gym 3 times a week can be achieved without being complexed by the fact you didn't go there every single day - and yet you can substantially improve yourself. I don't envy those buffy dudes that stick to it.

I'll stick to enjoying evenings with my wife, do code maybe 1 or 2 times during the week days, spend an extra day on more complex issues on the week end, and rest for the last day. Just saying.

"Unlike manners, there isn’t a universally-agreed objective standard" :)

Manners aren't universally agreed either, they are very much tied to the culture people are evolving in. Burping in the middle-east is appropriate and a courtesy to your host, I doubt it'd be very much enjoyed in a White House dinner. Taking some (good?) wine as bottom's up is respectful to your boss/partners in China, yet I believe some of your guests in France would find this offensive ;)

Interesting read nevertheless.

That's a valid point, probably more brainstorming in the best approach to render the first landing on a repo as it is what effectively is at stake; instead of landing on a blank page the choice was made to display it all, letting you transform the kanban to a dashboard that best fits your need, later visits would re-use your pre-saved board.

I believe you can update what labels you wanna see by selecting them in the setting pane on the right (as well as re-ordering them).

As for the lightbox part, there's indeed a bit more work in representing the content of the issues.

Indeed, hence the numerous cheats in the playbook to make things work together. Still need some digging to figure out the perfect workflow; Dockerfile that runs some git clone vs. add of local code vs. deploy via ansible - the ansible approach still provides the flexibility to have a customized container per dev that includes one custom set of ssh keys for example to fetch code from github or alike...

Ultimately that is be the goal indeed.

At the same time all init script are not suitable upstream; keeping the balance between simplicity and features is a hard one. Not every use would require a 10 foot long scripts that cover some awkward features that is seen in 1% of the cases - yet having a repository of capable init scripts seems a good way to mitigate the issue.

The redis init-script in the repo is only a sample I hacked as an example; to avoid an empty repo :) I've tested and it's working, though I'll perform some more checks tmr and will gladely commit it back.

That's a valid point; mention that one should not reboot until proven otherwise.

Same idea for services restart; don't do it unless absolutely needed. While it may be doing the trick in some cases it can also generate its own set of new false symptoms.

Take the example of :

- mysql is "slow"

- let's restart ! ...

- mysql init script has been puking dots (.) for the last 30 minutes on shutdown

- let's kill -9 it ! ...

- mysql db is corrupted ! Hurray!