Any pulls doing this become zero cost for docker hub
Any sort of cache you put between docker hub and your own infra would probably be S3 backed anyway, so adding another cache in between could be mostly a waste
1,508 karma · joined February 4, 2011
Any pulls doing this become zero cost for docker hub
Any sort of cache you put between docker hub and your own infra would probably be S3 backed anyway, so adding another cache in between could be mostly a waste
The pod delete event is sent out, and the load balancer and the pod itself both receive and react to it at the same time.
So unless the LB switchover is very quick, or the pod shutdown is slow - you get dropped requests - usually 502s.
Try googling for graceful k8s deploys and every article will say you have to put a preStop sleep in
This is how all pre-k8s rolling deployment systems I've used have worked.
So instead we move the logic to the application, and put a sleep in the shutdown phase to account for the time it takes for the load balancer to process/acknowledge the shutdown and stop routing new traffic to that node.
We had perfectly good rolling deploys before k8s came on the scene, but k8s insistence on a single-phase deployment process means we end up with this silly workaround.
I yelled into the void about this once and I was told that this was inevitable because it's an eventually consistent distributed system. I'm pretty sure it could still have had a 2 phase pod shutdown by encoding a timeout on the first stage. Sure, it would have made some internals require more complex state - but isn't that the point of k8s? Instead everyone has to rediscover the sleep hack over and over again.
Generally in my book projects should only be assigned to teams, and managing that project to completion should be part of that team's way of working.
Doing this in an agile manner generally means smaller projects, one at a time.
The thing I found most surprising about this article was this phrasing:
> We instruct half the team (2 engineers) at a given point to work on long-running tasks in 2-4 week blocks. This could be refactors, big features, etc. During this time, they don’t have to deal with any support tickets or bugs. Their only job is to focus on getting their big PR out.
This suggests that this pair of people only release 1 big PR for that whole cycle - if that's the case this is an extremely late integration and I think you'd benefit from adopting a much more continuous integration and deployment process.
The approach I’ve seen flyway take is to allow detecting / opting out of transactions on specific migrations
As long as you always apply migrations before deploying and abort the deploy if they time out or fail, then this approach is perfectly safe.
On the whole I think flyway does a decent job of making the easy things easy and the harder things possible - it just unfortunately comes with a bunch JVM baggage - so a Go based tool seems like a good alternative
The go tools for managing DB schema migrations have always felt lacking to me, and it seems like your tool ticks all of the boxes I had.
Except for one: lack of support for CREATE INDEX CONCURRENTLY (usually done by detecting that and skipping the transaction for that migration). How do you handle creating indexes without this?
In TS the `Omit<T, K>` type can be used to remove stuff, and intersection can be used to add stuff
So I would look into where they're losing time because they need to deal with repeated or inconsistent UI stuff, and make those the priority for the library to deal with first.
If you're forcing work on them for no benefit, then you're not going to get any takeup - so I would also budget plenty of time for the kit-owning team to do a lot of the initial rollout until you can get enough of a critical mass.
This can be thought of as duck typing.
Examples can be found here: https://blog.merovius.de/posts/2017-07-30-the-trouble-with-o...
Whereas if we start from a point of view of "What semantics and performance guarantees do we desire?", we might end up with a more coherent user-facing interface (even if internally that leads to something more complex).
Personally, my mental model is often influenced by Python - where a name is distinct from a variable, but this distinction doesn't seem to appear in many other languages.
Does the author of this piece post their dataset? That would allow people to cross-check the results from GPT and see to what extent they think it got it right or wrong.
Categorizing 200 films based on ~10 attributes by reading their wikipedia overviews feels like it would be not significantly more work than building the fancy scrolling visualisation itself.
If there were 1000 films being analysed then I'd definitely be looking for some sort of tooling to help (or crowd sourcing the analysis)
Standardization, like almost anything, has costs and benefits and tradeoffs and so on.
So when you're pushing to standardize something - consider what it is you're gaining and what it is you're losing, and decide whether that's a tradeoff you're ok with.
And the world runs on Excel files.
Great to see this sort of thing!
Surely the standard unit for this sort of thing is multiples of well known large lakes or seas?
Identity in particular is a complex subject, AIUI the original Verify project had to exist in the shadow of the No2ID campaign, which led them to avoid a centralised ID system. This then led to a much more complicated approach that was unable to cater for the needs of some of the departments.
For example, HMRC needed individuals and companies to be able to log in, and for whatever reason this was deemed unworkable with Verify, and thus they build the grandly titled "goverment gateway" auth system - and then I would assume that other depts saw this and decided that meant they could or should build their own auth systems too.
It’s usually much better ROI to publicly acknowledge an issue if the resolution is not going to be single digit minutes, as it massively reduces the incoming query/support burden
Is there a good way to analyse a query and be informed of what sort of lock it will take?
I’ve always resorted to re-reading docs when I’m unsure.