(12) Ode to an Outage | LinkedIn

July 22, 2024 at 11:56AM

via Instapaper

From Boring to Productive: Customize Your Shell Prompt with Starship

Discover how a simple, customizable Shell prompt can boost your productivity! This video explores the power of Starship, a lightning-fast and highly customizable Shell prompt. Learn how to set up Starship, apply various presets, and tailor it to fit your workflow. Whether you're using Zsh or another shell, we'll guide you through creating a prompt that provides essential information at a glance. From Git branches to Kubernetes clusters, see how Starship can transform your terminal experience.

StarshipShell #ProductivityHacks #CustomShellPrompt #TerminalTips

Consider joining the channel: https://www.youtube.com/c/devopstoolkit/join

▬▬▬▬▬▬ 🔗 Additional Info 🔗 ▬▬▬▬▬▬ ➡ Transcript and commands: https://devopstoolkit.live/terminal/from-boring-to-productive-customize-your-shell-prompt-with-starship 🔗 Starship: https://starship.rs/

▬▬▬▬▬▬ 💰 Sponsorships 💰 ▬▬▬▬▬▬ If you are interested in sponsoring this channel, please use https://calendar.app.google/Q9eaDUHN8ibWBaA7A to book a timeslot that suits you, and we'll go over the details. Or feel free to contact me over Twitter or LinkedIn (see below).

▬▬▬▬▬▬ 👋 Contact me 👋 ▬▬▬▬▬▬ ➡ Twitter: https://twitter.com/vfarcic ➡ LinkedIn: https://www.linkedin.com/in/viktorfarcic/

▬▬▬▬▬▬ 🚀 Other Channels 🚀 ▬▬▬▬▬▬ 🎤 Podcast: https://www.devopsparadox.com/ 💬 Live streams: https://www.youtube.com/c/DevOpsParadox

▬▬▬▬▬▬ ⏱ Timecodes ⏱ ▬▬▬▬▬▬ 00:00 Shell Prompts with Starship 02:17 Starship Presets 04:02 Starship Configuration 06:35 Starship In Action

via YouTube https://www.youtube.com/watch?v=VLzc1iSDe9A

Data Provenance Initiative

July 22, 2024 at 10:26AM

via Instapaper

How to block AI Crawler Bots using robots.txt file

User-agent: GPTBot Disallow: / User-agent: ChatGPT-User Disallow: /

July 22, 2024 at 10:17AM

via Instapaper

How to manually block common AI crawlers

User-agent: anthropic-ai Disallow: / User-agent: Claude-Web Disallow: / User-agent: CCbot Disallow: / User-agent: FacebookBot Disallow: / User-agent:…

July 22, 2024 at 10:16AM

via Instapaper

Let’s Open Ag-Tech

https://anonymoushash.vmbrasseur.com/2024/07/hello-semios.html

If you follow my Mastodon feed at all, you’ll know that I post and share a lot of articles about climate change and facets of our food systems (among other things, of course). These are topics that are near and dear to my heart. I even use an agriculture-related company—Bees4Less 🐝—in all the examples in my latest book.

So when I received an email asking for a chat with Semios—a successful ag-tech that helps improve sustainability in our food systems—it would be an understatement to say I was interested in talking to them. I really liked what I heard, and thankfully they did as well.

I’m excited to announce that as of today I’ve joined Semios to lead open source strategy and start an open source program office (OSPO)!

Yes, I know that everyone says “I’m excited!” when they announce a new job. It’s just That Thing You Do. But in this case, it’s also very much true.

While there have been a few initiatives to bring FOSS to ag-tech (AgStack for one, with which I’ll be spending a lot of time), in general it’s still a literal green field. There’s a lot of potential here, which Semios sees and understands. Together, we’re going to open ag-tech. It’s gonna be great, but it ain’t gonna be easy. Eventually I’ll be building a team to help us, once I get settled in and see where we’ll be starting.

But first, I’ve a lot of onboarding and learning to do from my new Semios colleagues. 🤩

via {anonymous => 'hash'}; https://anonymoushash.vmbrasseur.com/

July 22, 2024 at 03:00AM

Luna wishes you all a happy Monday #corgi #dog

July 22, 2024 at 10:08AM

via Instagram https://instagr.am/p/C9uk-lDuijP/

Amazon ECS now provides enhanced stopped task error messages for easier troubleshooting - AWS

Posted on: Jul 11, 2024 Amazon Elastic Container Services (Amazon ECS) now makes it easier to troubleshoot task launch failures with enhanced stopped task error…

July 22, 2024 at 09:21AM

via Instapaper

Widespread IT Outage Due to CrowdStrike Update | CISA

An official website of the United States government Here’s how you know Official websites use .gov A .gov website belongs to an official government organization…

July 19, 2024 at 02:44PM

via Instapaper

Kubernetes Removals and Major Changes In v1.31

https://kubernetes.io/blog/2024/07/19/kubernetes-1-31-upcoming-changes/

As Kubernetes develops and matures, features may be deprecated, removed, or replaced with better ones for the project's overall health. This article outlines some planned changes for the Kubernetes v1.31 release that the release team feels you should be aware of for the continued maintenance of your Kubernetes environment. The information listed below is based on the current status of the v1.31 release. It may change before the actual release date.

The Kubernetes API removal and deprecation process

The Kubernetes project has a well-documented deprecation policy for features. This policy states that stable APIs may only be deprecated when a newer, stable version of that API is available and that APIs have a minimum lifetime for each stability level. A deprecated API has been marked for removal in a future Kubernetes release. It will continue to function until removal (at least one year from the deprecation), but usage will display a warning. Removed APIs are no longer available in the current version, so you must migrate to using the replacement.

Generally available (GA) or stable API versions may be marked as deprecated but must not be removed within a major version of Kubernetes.

Beta or pre-release API versions must be supported for 3 releases after the deprecation.

Alpha or experimental API versions may be removed in any release without prior deprecation notice.

Whether an API is removed because a feature graduated from beta to stable or because that API did not succeed, all removals comply with this deprecation policy. Whenever an API is removed, migration options are communicated in the documentation.

A note about SHA-1 signature support

In go1.18 (released in March 2022), the crypto/x509 library started to reject certificates signed with a SHA-1 hash function. While SHA-1 is established to be unsafe and publicly trusted Certificate Authorities have not issued SHA-1 certificates since 2015, there might still be cases in the context of Kubernetes where user-provided certificates are signed using a SHA-1 hash function through private authorities with them being used for Aggregated API Servers or webhooks. If you have relied on SHA-1 based certificates, you must explicitly opt back into its support by setting GODEBUG=x509sha1=1 in your environment.

Given Go's compatibility policy for GODEBUGs, the x509sha1 GODEBUG and the support for SHA-1 certificates will fully go away in go1.24 which will be released in the first half of 2025. If you rely on SHA-1 certificates, please start moving off them.

Please see Kubernetes issue #125689 to get a better idea of timelines around the support for SHA-1 going away, when Kubernetes releases plans to adopt go1.24, and for more details on how to detect usage of SHA-1 certificates via metrics and audit logging.

Deprecations and removals in Kubernetes 1.31

Deprecation of status.nodeInfo.kubeProxyVersion field for Nodes (KEP 4004)

The .status.nodeInfo.kubeProxyVersion field of Nodes is being deprecated in Kubernetes v1.31, and will be removed in a later release. It's being deprecated because the value of this field wasn't (and isn't) accurate. This field is set by the kubelet, which does not have reliable information about the kube-proxy version or whether kube-proxy is running.

The DisableNodeKubeProxyVersion feature gate will be set to true in by default in v1.31 and the kubelet will no longer attempt to set the .status.kubeProxyVersion field for its associated Node.

Removal of all in-tree integrations with cloud providers

As highlighted in a previous article, the last remaining in-tree support for cloud provider integration will be removed as part of the v1.31 release. This doesn't mean you can't integrate with a cloud provider, however you now must use the recommended approach using an external integration. Some integrations are part of the Kubernetes project and others are third party software.

This milestone marks the completion of the externalization process for all cloud providers' integrations from the Kubernetes core (KEP-2395), a process started with Kubernetes v1.26. This change helps Kubernetes to get closer to being a truly vendor-neutral platform.

For further details on the cloud provider integrations, read our v1.29 Cloud Provider Integrations feature blog. For additional context about the in-tree code removal, we invite you to check the (v1.29 deprecation blog).

The latter blog also contains useful information for users who need to migrate to version v1.29 and later.

Removal of kubelet --keep-terminated-pod-volumes command line flag

The kubelet flag --keep-terminated-pod-volumes, which was deprecated in 2017, will be removed as part of the v1.31 release.

You can find more details in the pull request #122082.

Removal of CephFS volume plugin

CephFS volume plugin was removed in this release and the cephfs volume type became non-functional.

It is recommended that you use the CephFS CSI driver as a third-party storage driver instead. If you were using the CephFS volume plugin before upgrading the cluster version to v1.31, you must re-deploy your application to use the new driver.

CephFS volume plugin was formally marked as deprecated in v1.28.

Removal of Ceph RBD volume plugin

The v1.31 release will remove the Ceph RBD volume plugin and its CSI migration support, making the rbd volume type non-functional.

It's recommended that you use the RBD CSI driver in your clusters instead. If you were using Ceph RBD volume plugin before upgrading the cluster version to v1.31, you must re-deploy your application to use the new driver.

The Ceph RBD volume plugin was formally marked as deprecated in v1.28.

Deprecation of non-CSI volume limit plugins in kube-scheduler

The v1.31 release will deprecate all non-CSI volume limit scheduler plugins, and will remove some already deprected plugins from the default plugins, including:

AzureDiskLimits

CinderLimits

EBSLimits

GCEPDLimits

It's recommended that you use the NodeVolumeLimits plugin instead because it can handle the same functionality as the removed plugins since those volume types have been migrated to CSI. Please replace the deprecated plugins with the NodeVolumeLimits plugin if you explicitly use them in the scheduler config. The AzureDiskLimits, CinderLimits, EBSLimits, and GCEPDLimits plugins will be removed in a future release.

These plugins will be removed from the default scheduler plugins list as they have been deprecated since Kubernetes v1.14.

Looking ahead

The official list of API removals planned for Kubernetes v1.32 include:

The flowcontrol.apiserver.k8s.io/v1beta3 API version of FlowSchema and PriorityLevelConfiguration will be removed. To prepare for this, you can edit your existing manifests and rewrite client software to use the flowcontrol.apiserver.k8s.io/v1 API version, available since v1.29. All existing persisted objects are accessible via the new API. Notable changes in flowcontrol.apiserver.k8s.io/v1beta3 include that the PriorityLevelConfiguration spec.limited.nominalConcurrencyShares field only defaults to 30 when unspecified, and an explicit value of 0 is not changed to 30.

For more information, please refer to the API deprecation guide.

Want to know more?

The Kubernetes release notes announce deprecations. We will formally announce the deprecations in Kubernetes v1.31 as part of the CHANGELOG for that release.

You can see the announcements of pending deprecations in the release notes for:

Kubernetes v1.30

Kubernetes v1.29

Kubernetes v1.28

Kubernetes v1.27

via Kubernetes Blog https://kubernetes.io/

July 18, 2024 at 08:00PM