Open-source News

Start Here When Things Go Wrong on Your Linux System  TechNewsWorld

Start Here When Things Go Wrong on Your Linux System  LinuxInsider.com

How to Zip and Unzip Files With Gzip on Linux  How-To Geek

How to Install Flatpak Apps on Linux  BollyInside

AnyDesk vs. TeamViewer vs. Splashtop vs. LogMeIn: Battle of the Remote Desktop Apps  Online Tech Tips

Merged in Linux 5.18 is the AMD HSMP driver for enabling the "Host System Management Port" usage under Linux as an interface for enabling additional system management functionality on AMD EPYC 7003 servers. For Linux 5.19 this AMD HSMP driver is set to be extended with additional features coming with next-generation AMD EPYC servers...

9to5Linux Weekly Roundup: May 1st, 2022  9to5Linux

The Trinity Desktop Environment (TDE) on Sunday released version 14.0.12 as the newest version of this open-source, cross-platform desktop that started out as a fork of KDE 3.5 from a decade ago and continues seeing advancements from its small but dedicated developer crew...

Intel's latest high profile hire is recruiting Brendan Gregg from Netflix...

How to make community recognition more inclusive Ray Paik Mon, 05/02/2022 - 03:00 1 reader likes this 1 reader likes this

Giving recognition to someone for a job well done is one of my favorite duties as a community manager. Not only do I get to thank someone, but I also have a chance to highlight a role model for the rest of the community. Recognition also provides an opportunity to celebrate an achievement, like someone helping new community members with onboarding, reducing technical debt, or contributing an exciting new feature.

More great content Free online course: RHEL technical overview Learn advanced Linux commands Download cheat sheets Find an open source alternative Explore open source resources

However, the methods used to identify contributions and recognize them can have unintended consequences. For example, sometimes community managers use charts like the following during recognitions, emphasizing pull requests (PRs) and contributions to code repositories.

Image by:

(Ray Paik, CC BY-SA 4.0)

Image by:

(Ray Paik, CC BY-SA 4.0)

Three problems arise with using these types of data for recognition. First, there's too much focus on contributions in code repositories. In the early days, open source projects attracted mostly developers, so naturally a lot of collaboration was done around code. Now, an increasing number of nondevelopers are participating in communities (for example, through user groups, meetups, user-generated content), and they will be doing most of their work outside repositories. Those contributions don't register on a chart like Annual Merged PRs.

Second, with too much focus on metrics (that is, things that can be measured quantitatively), you may end up rewarding quantity over quality—or even impact. In the Top Contributing Orgs chart above, larger organizations have a clear advantage over smaller organizations, as they have more people available. By recognizing larger organizations for their volume of work or contributions, you may inadvertently make people from smaller organizations feel disenfranchised.

Finally, even though it's not the intent, some people may view these data as a ranking of the importance of individual community members or organizations.

For all these reasons, it's best to avoid relying solely on metrics for community recognition.

Make recognition more meaningful

What are some more inclusive ways to approach community recognition and acknowledge a variety of contribution types? Communication channels like Discord, Internet Relay Chat (IRC), mailing lists, or Slack provide good clues as to which community members are active and what they're passionate about. For example, I'm always amazed to find members who are very generous in answering others' questions and helping newcomers. These contributions don't show up in community dashboards, but it's important to recognize this work and let everyone know that this contribution is valued.

Speaking of community dashboards, they're certainly important tools in open source communities. However, I caution against spending too much time building dashboards. Sooner or later, you will find that not everything is easily measurable, and even if you find a way to quantify something, it often lacks context.

One of the things I do to get more context around the contributions is to schedule coffee chats with community members. These conversations give me an opportunity to learn about why they decided to make the contribution, how much work was involved, others who were also involved, and so on.

When I talk to these members for the first time, I often hear that they feel it's important to find ways to give back to the community, and they're looking for ways to help. Some are even apologetic because they cannot contribute code, and I have to reassure them that code is no longer the only thing that matters in open source. Sometimes these conversations allow me to make connections among community members in the same city or industry, or to find other common interests. Fostering these connections helps strengthen a sense of belonging.

Make recognition more impactful

In addition to finding more activities to recognize, you can also present recognition in ways that have a bigger effect. For example, be timely with kudos when you see a good contribution. A quick DM with a simple thank you can be more effective than something more formal a month or two later. Many people, myself included, tend to stress over sending the right merchandise with recognition, but it's important to remember that swag is not the main motivator for community members' contributions. Recognizing good work and making an effort to reach out goes a long way in making people feel appreciated.

It's also a good idea to give members an opportunity to participate in the recognition process. Once a community reaches a certain size, it's difficult to know everything that's happening. Having a simple nomination form that community members can submit will raise awareness of good contributions that others may not have been aware of. If your community has formal awards for members—for example, awards presented at an annual conference or meetups—involve members in the nomination and voting process. This not only provides an opportunity for more people to participate in the process, but the awards will also be more meaningful to recipients since they come from their peers.

Finally, giving recognition is a vital opportunity to get to know community members and build relationships. Sometimes the recognition process can feel almost transactional: "You did X, so we're going to award you with Y." Taking the time to do personal outreach along with the award will make community members feel more appreciated and strengthen their sense of belonging.

Recognitions build community health

There's a lot of work to be done to improve diversity, inclusion, and belonging in open source communities. Better community recognitions play an essential role in these efforts. Ensuring that all contributions are valued and that everyone feels like they have a home where they're appreciated will encourage members to stay engaged in the community.

Look beyond metrics to ensure that all contributions are valued. When everyone feels like they have a home where they're appreciated, community members will be encouraged to stay engaged.

Image by:

Opensource.com

Community management Diversity and inclusion What to read next This work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License. Register or Login to post a comment.

10 Argo CD best practices I follow Noaa Barki Mon, 05/02/2022 - 03:00 Register or Login to like Register or Login to like

My DevOps journey kicked off when I started developing Datree, an open source command that aims to help DevOps engineers to prevent Kubernetes misconfigurations from reaching production. One year later, seeking best practices and more ways to prevent misconfigurations became my way of life.

This is why when I first learned about Argo CD, the thought of using Argo without knowing its pitfalls and complications simply didn't make sense to me. After all, it's probable that configuring it incorrectly can easily cause the next production outage.

In this article, I'll explore some of the best practices of Argo that I've found, and show you how to validate custom resources against these best practices.

More on Kubernetes What is Kubernetes? Free online course: Containers, Kubernetes and Red Hat OpenShift technical over… eBook: Storage Patterns for Kubernetes Test drive OpenShift hands-on An introduction to enterprise Kubernetes How to explain Kubernetes in plain terms eBook: Running Kubernetes on your Raspberry Pi homelab Kubernetes cheat sheet eBook: A guide to Kubernetes for SREs and sysadmins Latest Kubernetes articles Disallow providing an empty retryStrategy

Project: Argo Workflows

Best practice: A user can specify a retryStrategy that dictates how errors and failures are retried in a workflow. Providing an empty retryStrategy (retryStrategy: {}) causes a container to retry until completion, and eventually causes out-of-memory (OOM) issues.

Ensure that Workflow pods are not configured to use the default service account

Project: Argo Workflows

Best practice: All pods in a workflow run with a service account, which can be specified in the workflow.spec.serviceAccountName. If omitted, Argo uses the default service account of the workflow's namespace. This provides the workflow (the pod) the ability to interact with the Kubernetes API server. This allows attackers with access to a single container to abuse Kubernetes by using the AutomountServiceAccountToken. If by any chance, the option for AutomountServiceAccountToken was disabled, then the default service account that Argo uses won't have any permissions, and the workflow fails.

It's recommended to create dedicated user-managed service accounts with the appropriate roles.

Set the label 'part-of: argocd' in ConfigMaps

Project: Argo CD

When installing Argo CD, its atomic configuration contains a few services and configMaps. For each specific kind of ConfigMap and Secret resource, there is only a single supported resource name (as listed in the above table). If you need to merge things, do it before creating them. It's important to annotate your ConfigMap resources using the label app.kubernetes.io/part-of: argocd, otherwise, Argo CD isn't able to use them.

Disable 'FailFast=false' in DAG

Project: Argo Workflows

Best practice: As an alternative to specifying sequences of steps in Workflow, you can define the workflow as a directed-acyclic graph (DAG) by specifying the dependencies of each task. The DAG logic has a built-in fail fast feature to stop scheduling new steps, as soon as it detects that one of the DAG nodes has failed. Then it waits until all DAG nodes are completed before failing the DAG itself. The FailFast flag default is true. If set to false, it allows a DAG to run all branches of the DAG to completion (either success or failure), regardless of the failed outcomes of branches in the DAG.

Ensure Rollout pause step has a configured duration

Project: Argo Rollouts

Best practice: For every Rollout, you can define a list of steps. Each step can have one of two fields: setWeight and pause. The setWeight field dictates the percentage of traffic that should be sent to the canary, and the pause literally instructs the rollout to pause.

Under the hood, the Argo controller uses these steps to manipulate the ReplicaSets during the rollout. When the controller reaches a pause step for a rollout, it adds a PauseCondition struct to the .status.PauseConditions field. If the duration field within the pause struct is set, the rollout does not progress to the next step until it has waited for the value of the duration field. However, if the duration field has been omitted, the rollout might wait indefinitely until the added pause condition is removed.

Specify Rollout's revisionHistoryLimit

Project: Argo Rollouts

Best practice: The .spec.revisionHistoryLimit is an optional field that indicates the number of old ReplicaSets, which should be retained in order to allow rollback. These old ReplicaSets consume resources in etcd and crowd the output of kubectl get rs. The configuration of each Deployment revision is stored in its ReplicaSets; therefore, once an old ReplicaSet is deleted, you lose the ability to roll back to that revision of Deployment.

By default, 10 old ReplicaSets are kept. However, it's ideal value depends on the frequency and stability of new Deployments. More specifically, setting this field to zero means that all old ReplicaSets with 0 replicas are removed. In this case, a new Deployment rollout cannot be undone, because its revision history is removed.

Set scaleDownDelaySeconds to 30s

Project: Argo Rollouts

Best practice: When the rollout changes the selector on service, there's a propagation delay before all the nodes update their IP tables to send traffic to the new pods instead of the old. Traffic is directed to the old pods if the nodes have not been updated yet during this delay. In order to prevent packets from being sent to a node that killed the old pod, the rollout uses the scaleDownDelaySeconds field to give nodes enough time to broadcast the IP table changes. If omitted, the Rollout waits 30 seconds before scaling down the previous ReplicaSet.

It's recommended to set scaleDownDelaySeconds to a minimum of 30 seconds in order to ensure that the IP table propagates across the nodes in a cluster. The reason is that Kubernetes waits for a specified time called the termination grace period. By default, this is 30 seconds.

Ensure retry on both Error and TransientError

Project: Argo Workflows

Best practice: retryStrategy is an optional field of the Workflow CRD, that provides controls for retrying a workflow step. One of the fields of retryStrategy is _retryPolicy, which defines the policy of NodePhase statuses to be retried (NodePhase is the condition of a node at the current time). The options for retryPolicy can be either: Always, OnError, or OnTransientError. In addition, the user can use an expression to control more of the retries.

What's the catch?

• retryPolicy=Always is too much: Letting the user retry on system-level errors (for instance, the node dying or being preempted), but not on errors occurring in user-level code since these failures indicate a bug. In addition, this option is more suitable for long-running containers than workflows which are jobs.
• retryPolicy=OnError doesn't handle preemptions: Using retryPolicy=OnError handles some system-level errors like the node disappearing or the pod being deleted. However, during graceful Pod termination, the kubelet assigns a Failed status and a Shutdown reason to the terminated Pods. As a result, node preemptions result in node status Failure instead of Error, so preemptions aren't retried.
• retryPolicy=OnError doesn't handle transient errors: Classifying a preemption failure message as a transient error is allowed. However, this requires retryPolicy=OnTransientError. (see also TRANSIENT_ERROR_PATTERN).

I recommend setting retryPolicy: "Always" and use the following expression:

lastRetry.status == "Error" or (lastRetry.status == "Failed" and asInt(lastRetry.exitCode) not in [0])Ensure progressDeadlineAbort set to true

Project: Argo Rollouts

Best practice: A user can set progressDeadlineSeconds, which states the maximum time in seconds in which a rollout must make progress during an update before it is considered to be failed.

If rollout pods get stuck in an error state (for example, image pull back off), the rollout degrades after the progress deadline is exceeded but the bad replica set or pods aren't scaled down. The pods would keep retrying and eventually the rollout message would read ProgressDeadlineExceeded: The replicaset has timed out progressing. To abort the rollout, set both progressDeadlineSeconds and progressDeadlineAbort, with progressDeadlineAbort: true.

Ensure custom resources match the namespace of the ArgoCD instance

Project: Argo CD

Best practice: In each repository, all Application and AppProject manifests should match the same metadata.namespace. If you deployed Argo CD using the typical deployment, Argo CD creates two ClusterRoles and ClusterRoleBinding, that reference the argocd namespace by default. In this case, it's recommended not only to ensure that all Argo CD resources match the namespace of the Argo CD instance, but also to use the argocd namespace. Otherwise, you need to make sure to update the namespace reference in all Argo CD internal resources.

However, if you deployed Argo CD for external clusters (in Namespace Isolation Mode), then instead of ClusterRole and ClusterRoleBinding, Argo creates Roles and associated RoleBindings in the namespace where Argo CD was deployed. The created service account is granted a limited level of access to manage, so for Argo CD to be able to function as desired, access to the namespace must be explicitly granted. In this case, you should make sure all resources, including Application and AppProject, use the correct namespace of the ArgoCD instance.

Now What?

I'm a GitOps believer, and I believe that every Kubernetes resource should be handled exactly the same as your source code, especially if you are using Helm or Kustomize. So, the way I see it, you should automatically check your resources on every code change.

You can write your policies using languages like Rego or JSONSchema and use tools like OPA ConfTest or different validators to scan and validate our resources on every change. Additionally, if you have one GitOps repository, then Argo plays a great role in providing a centralized repository for you to develop and version control your policies.

[ Download the eBook: Getting GitOps: A practical platform with OpenShift, Argo CD, and Tekton ]

How Datree works

The Datree CLI runs automatic checks on every resource that exists in a given path. After the check is complete, Datree displays a detailed output of any violation or misconfiguration it finds, with guidelines on how to fix it:

Scan your cluster with Datree $ kubectl datree test -- -n argocd

You can use the Datree kubectl plugin to validate your resources after deployments, get ready for future version upgrades and monitor the overall compliance of your cluster.

Scan your manifests in the CI

In general, Datree can be used in the CI, as a local testing library, or even as a pre-commit hook. To use datree, you first need to install the command on your machine, and then execute it with the following command:

$ datree test -.datree/k8s-demo.yaml >> File: .datree/k8s-demo.yaml
[V] YAML Validation
[V] Kubernetes schema validation
[X] Policy check

X Ensure each container image has a pinned (tag) version [1 occurrence]
- metadata.name: rss-site (kind: Deployment)
!! Incorrect value for key 'image' - specify an image version
X Ensure each container has a configured memory limit [1 occurrence]
- metadata.name: rss-site (kind: Deployment)
!! Missing property object 'limits.memory' - value should be within the accepter

X Ensure workload has valid Label values [1 occurrence]
- metadata.name: rss-site (kind: Deployment)
!! Incorrect value for key(s) under 'labels' - the vales syntax is not valid

X Ensure each container has a configured liveness probe [1 occurrence]
- metadata.name: rss-site (kind: Deployment)
!! Missing property object 'livenessProbe' - add a properly configured livenessP:

[...]

As I mentioned above, the way the CLI works is that it runs automatic checks on every resource that exists in the given path. Each automatic-check includes three steps:

1. YAML validation: Verifies that the file is a valid YAML file.
2. Kubernetes schema validation: Verifies that the file is a valid Kubernetes/Argo resource.
3. Policy check: Verifies that the file is compliant with your Kubernetes policy (Datree built-in rules by default).

Summary

In my opinion, governing policies are only the beginning of achieving reliability, security, and stability for your Kubernetes cluster. I was surprised to find that centralized policy management might also be a key solution for resolving the DevOps and Development deadlock once and for all.

Check out the Datree open source project. I highly encourage you to review the code and submit a PR, and don't hesitate to reach out.

This article originally appeared on the Datree blog and has been republished with permission. 

I'll show you how to validate custom resources against these Argo best practices for DevOps engineers.

Kubernetes DevOps What to read next Prevent Kubernetes misconfigurations during development with this open source tool This work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License. Register or Login to post a comment.

How to recruit and hire a video game quest writer  TechRepublic

The post How to Install Icinga2 Monitoring Tool on Debian first appeared on Tecmint: Linux Howtos, Tutorials & Guides .

Originally created as a fork of the Nagios monitoring tool, Icinga is a free and open-source infrastructure monitoring and alerting solution that monitors your entire infrastructure and provides feedback about the availability and performance

The post How to Install Icinga2 Monitoring Tool on Debian first appeared on Tecmint: Linux Howtos, Tutorials & Guides.

Microsoft has joined the Open 3D Foundation that was started by the Linux Foundation when Amazon's Lumberyard game engine went on to form the Open 3D Engine. Microsoft is now backing the Open 3D Foundation and the Open 3D Engine for promoting open-source 3D game and simulation development...

Earlier today, we announced the winners of the 2022 Red Hat Innovation Awards, recognizing our customers’ achievements with open source technology. Each year, we have many strong entries that showcase what innovative thinking, open culture, and transformative uses of Red Hat technology can do for business and society.

For the 16th year, the Red Hat Innovation Awards are recognizing the technological achievements of Red Hat customers around the world who demonstrate creative problem-solving to make a positive impact on the business world and on society. This year’s winners are the Canadian Imperial Bank of Commerce (CIBC), the Center of Computing and Information Systems, Telefónica Colombia, the Department for Work and Pensions, and Washington Health Benefit Exchange.

Released on Sunday was GDB 12.1 as the newest version of the GNU Debugger...

Generation 4 Kubuntu Focus M2 Linux laptop now available with 12th gen Core i7  BetaNews

While Linux 5.18 had been trending on the lighter/calmer side, Linux 5.18-rc5 was just released and it comes in "a very tiny bit larger" than usual...

Open source 'Package Analysis' tool finds malicious npm, PyPI packages  BleepingComputer