SLATE blog

JupyterLab is a great tool for data analysis, visualization, machine learning and much more. It allows users to run code interactively via its web notebook interface and thus iterate changes quickly. Often users need to scale up their work and thus require submission to a backend cluster from the notebook. We show how this can be done with HTCondor using SLATE.

An OSG Compute Element (CE) is an application that allows a site to contribute HPC or HTC compute resources to the Open Science Grid. The CE is responsible for receiving jobs from the grid and routing them to your local cluster(s). Jobs from the Open Science Grid are preemptible, and can be configured to run only when resources would have otherwise been idle. Resource providers can use OSG to backfill their cluster(s) to efficiently utilize resources and contribute to the shared national cyberinfrastructure.

The simplest way to start contributing resources to the OSG, for many sites, is via the “Hosted” CE. In the hosted case, installation and setup of the Compute Element is done by the OSG team, usually on a machine outside of your cluster, and uses standard OpenSSH as a transport for submitting jobs to your resources. With SLATE, we have simplified Hosted CE installation and made a shared operations model possible. Now the Compute Element can be hosted on your Kubernetes infrastructure on-prem and cooperatively managed by OSG and your local team. In this article, we’ll go through the steps for connecting a SLURM cluster to the Open Science Grid with our newly stabilized OSG Hosted CE Helm Chart.

Sometimes when we run containerized applications, we want a little more than the usual stdout/stderr log aggregation that Kubernetes or SLATE gives us by default. For many applications, logs may be exceptionally verbose, or split across many files corresponding to different parts of the software, necessitating some other mechanism by which to retrieve logs. In this post we’ll show you how to add a logging sidecar to your Helm chart, complete with HTTP basic auth and ingress for ease of access.

Kubernetes (K8s) is a powerful container orchestration tool. k3s is a lightweight distribution of Kubernetes that strips away a number of features while remaining fully compliant with up-stream Kubernetes. It allows easier deployment when compared to kubeadm and all in a binary less than 40MB. k3s is a fantastic solution for deploying Kubernetes with SLATE on smaller devices, older hardware, and even IOT. In this blog post, we explain how a k3s and SLATE can provide a tidy, lightweight edge federation.

Software Defined Networking (SDN) is an emerging technology that allows network administrators to programmatically manage network devices in a dynamic and cloud-like manner. Faucet is an SDN controller that utilizes the OpenFlow protocol to enable managing devices in such a way. We have been working on packaging Faucet as a SLATE application to empower sites to experiment with this exciting new technology. In this post, we’ll explain the process of configuring, deploying and connecting a Faucet controller through the SLATE platform.

This is the first in our series of roughly quarterly release notes for activities in the SLATE project. We have a whole slew of changes across all aspects of SLATE, including a revamped web experience, client/server improvements, better tooling, more applications, and new sites added to the Federation.

Kubernetes supports multiple container runtimes through its Container Runtime Interface (CRI). As a result, besides the typical default choice of Docker (containerd) one can also use a variety of other drop-in replacements, such as cri-o. This article will discuss another option, namely Singularity.