The point is that humans want a meeting's clock time to change when they travel to a new time zone, but not when their local time changes (either due to DST or a legal change).
Unless of course not everybody invited shares the same DST patterns, in which case it has to change for some of the participants (how do you choose which?).
Also, the relationship between the datetime the user chose and the UTC time you store can be retroactively changed by legislation.
Is it that awful? Each option is nicely explained, and the documentation is exactly where you need it, when you need it. I personally found it extremely helpful during my first interactive rebase, and still give it a glance from time to time when I forget the difference between squash and fixup.
Provided rewording, reordering and squashing (or fixing up, same thing really) are all you need I think you could argue this is true. Trying to do anything else tends to be a bit of a pain.
On another note, is it possible not to lose the commit description when trying to split a commit? I'm talking about
1) marking commit as `e` to edit it
2) git reset HEAD~ to move back
3) split the change however you want
4) commit again
whenever I do it I always lose the original commit message. I'm not sure if it's me being stupid or if there is just no simple way to do it.
> is it possible not to lose the commit description when trying to split a commit?
There's 2 cases: 1) extract changes into a commit that comes before the original commit, and 2) extract changes into a commit that comes after the original commit.
In both, instead of editing the commit you want to split, `break` before that commit, and then use `git checkout <hash_of_commit_to_edit> <path_to_files_of_interest>` to pull the changes of interest out into an new, earlier commit. `git checkout -p` is worth a look here. Alternatively if the changes are simple enough, you could use exec instead of break before the target commit.
For 1) you can commit those extracted changes with a new message and then `git rebase --continue`. The original commit will then lack the extracted changes, and have the original commit message. If you did want to adjust it, reword that commit.
For 2) reference the target commit's message as the new, earlier commit's message. Keep in mind that the git invocation in this exec here still supports git aliases so if this was something you do often, you could create an alias for retrieving the next commit message and that last part of the exec could just be `.. && git getnextcommitmessage`
Intuitively, I would have expected AWS to send back the EBS volume backing a powered-off machine into the Whatever Long-Term Storage Is Behind EBS, and therefore start-up time to be ~identical to a fresh start as the steps would be the same: retrieve data from long-term storage into a readable EBS volume, start VM etc.
It's very interesting that it is not the case, and that keeping the EBS volume around after a first boot makes a second boot so much faster.
If that were the case, then there would be absolutely no benefit from having a stop vs terminate. Unless you've written data to the EBS volume, but in these cases where the boot time is critical most of them are some sort of read-only volume anyways. The fact that an EC2 can be stopped or terminated should immediately suggest speed might be a difference in reaching the running state. In the EBS docs, it clearly states that if you keep an EBS volume around either attached to a stopped EC2 or detached and left in your pool of volumes, you will be charged for that volume.
That's very interesting, as a Frenchman I assumed it came from "brutal", like "brutalité", as the raw concrete and abundance of right angles tends to make these buildings feel, well, aggressive (to me at least).
I'm not sure there is a consensus on ice baths at this stage? Some athletes swear by it, some say it's useless, and last I looked at it the science was ambivalent (somewhere between small to no effect, either positive or negative).
Fwiw this is how I use Loki most of the time. Pick an app label, pick a time period, look at raw logs. The LogQL for this ends up something like `{app="workload-foo"}`. Loki is excellent at that.
Then if I know which pod I'll filter down to a specific pod with `{pod="workload-foo-1234"}`, sometimes I'll search for a specific term (error message etc) with `{pod="workload-foo-1234"} |= "error message"` then look at the logs around that. There's really no point writing complicated queries unless you need to.
That will, if I understand correctly, get the logs for one pod, not for one process. For example if the pod restarted 10 times you will not get 10 separate files from that query.
If you mean one instance in each pod, then each should be labelled differently and you can filter down to one instance.
If you mean running multiple instances in each pod (and container?), then the standard kubectl log output will also have them all joined together. For both of those, you would need to add another unique identifier to each line, or run each instance in a separate container so you can submit the logs with the pod name and container name combined being the unique identifier.
Why? If the pod is defined to spawn multiple containers, and each container runs the same application, then this seems true to me? Unless you would add an additional filter on the container name.
Well yes obviously you have to filter on container if you want a single container (just like kubectl logs -l <...>). The parent comment was phrased as a limitation of Loki, of course if you request all logs for an application you'll get all containers, or if you request all logs for an applications or a namespace you will get that.
Not being able to filter between multiple processes or multiple restart of a container was a genuine issue, not being able to filter between pods of a deployment is not.
I actually didn't understand it being phrased as a limitation. It could also be a feature - maybe one would prefer to look at logs for multiple services within a single query?
Anyhow, the nice thing about the system is that one can get anything that is preferable as long as the logs are annotated correctly (with pod and container id).
No, once again, the trouble is that you can't get the logs for a specific execution. If a container in your pod restarts, that is invisible to Loki, you have to look for whatever the container writes on startup and cut there manually. If you want a specific process in your container, it's mixed with the rest.
Yeah but Prometheus has a web ui where you can run PromQL queries and it'll give you basic graphs back, which is handy for throwing a quick query at it before putting it into something more long-term like a Grafana dashboard or an alerting rule.
wow I always thought that Prom UI was just a tacked-on part of alertmanager or something because it’s so rudimentary. In my experience, everyone just uses Grafana Explore since that’s what Grafana was originally purpose-built for and it’s crazy easy to set up. Just pull down a container or helm chart or whatever.
Since Grafana built Loki, it doesn't make any sense why Grafana would create a separate querying UI app for Loki when they already have Grafana Explore. Prometheus (and I assume its UI) was created by Google [edit: sorry, created by SoundCloud, inspired by a Google Borg tool] before Grafana became the de facto Prometheus query UI, so it’s not really analogous.
Gah! Brain, I was thinking about which player usually strikes the ball first (hooker) rather than who feeds the scrum (scrum-half). Point still stands though I don't think I've seen a straight feed in years, at least in the Six Nations matches.
It is indeed used quite a lot in France, and it's great but... For extra confusion my parent's street starts with straight numbers (1, 2, 3...), _then_ switches to distance-based count! So that on one side of the road, we get houses 43, 45, 47, then suddenly 947, and on the other side 64, 66, 68... then 920.
If you're interested in diving deeper, the History of Aotearoa New Zealand podcast ( https://historyaotearoa.com/ ) is a great resource, very well researched and engaging.
All good until summer time kicks in and your recurring 9am meeting now starts at 8am, oops.