diff --git a/.gitattributes b/.gitattributes
new file mode 100644
index 0000000..dfe0770
--- /dev/null
+++ b/.gitattributes
@@ -0,0 +1,2 @@
+# Auto detect text files and perform LF normalization
+* text=auto
diff --git a/.github/LICENSE-BOOTSTRAP.md b/.github/LICENSE-BOOTSTRAP.md
new file mode 100644
index 0000000..6ed32f9
--- /dev/null
+++ b/.github/LICENSE-BOOTSTRAP.md
@@ -0,0 +1,7 @@
+Copyright 2017 - Present Stuart Yamartino (@StuYam)
+
+Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..9dd8f76
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,3 @@
+/_site
+/.sass-cache
+.DS_Store
diff --git a/404.html b/404.html
new file mode 100644
index 0000000..c472b4e
--- /dev/null
+++ b/404.html
@@ -0,0 +1,24 @@
+---
+layout: default
+---
+
+
+
+
+
404
+
+
Page not found :(
+
The requested page could not be found.
+
diff --git a/CNAME b/CNAME
new file mode 100644
index 0000000..9a75399
--- /dev/null
+++ b/CNAME
@@ -0,0 +1 @@
+converged-computing.org
diff --git a/Gemfile b/Gemfile
new file mode 100644
index 0000000..dbbfc4b
--- /dev/null
+++ b/Gemfile
@@ -0,0 +1,21 @@
+source "https://rubygems.org"
+
+# Hello! This is where you manage which Jekyll version is used to run.
+# When you want to use a different version, change it below, save the
+# file and run `bundle install`. Run Jekyll with `bundle exec`, like so:
+#
+# bundle exec jekyll serve
+#
+# This will help ensure the proper Jekyll version is running.
+# Happy Jekylling!
+# gem 'jekyll', '>= 3.6.3'
+
+# If you want to use GitHub Pages, remove the "gem "jekyll"" above and
+# uncomment the line below. To upgrade, run `bundle update github-pages`.
+gem "github-pages", group: :jekyll_plugins
+gem "webrick"
+
+# If you have any plugins, put them here!
+group :jekyll_plugins do
+ gem 'jekyll-feed', '~> 0.6'
+end
diff --git a/README.md b/README.md
index fc9b407..ee4309e 100644
--- a/README.md
+++ b/README.md
@@ -4,17 +4,13 @@
> A Best-of-Both-Worlds of HPC and Cloud
-This is a [CiSE Special Issue Proposal](https://www.authorea.com/users/34995/articles/430859-cise-guest-editors-guide) and
-the repository where we will write and document our whitepaper to introduce it.
-
-## Important Dates
-
-- Anticipated for 2023-2023
+This is the Converged Computing working space. It includes definitions, projects, and eventually will also include a [CiSE Special Issue](https://www.authorea.com/users/34995/articles/430859-cise-guest-editors-guide) on converged computing.
## Overview
-Major trends have brought the cloud and high performance computing (HPC) communities closer together: the maturation of cloud technologies has shifted focus toward running workloads efficiently, and composite scientific workflows and resource heterogeneity and dynamism have revealed the limitations of traditional HPC resource and workflow management. It has become clear that the initially disparate communities have much to benefit in working together. This special issue aims to bridge the gap between HPC and cloud to discuss work in converged computing – the collaborative space between these traditionally separate communities – to develop novel technologies and applications. These hybrid technologies might span the gamut from automation, workflows, containerization, to software development and deployment and testing. This is a timely topic as collaborative work is happening to a greater degree that combines approaches from high performance computing with cloud-native computing.
+> Special Issue Anticipated for mid 2024
+Major trends have brought the cloud and high performance computing (HPC) communities closer together: the maturation of cloud technologies has shifted focus toward running workloads efficiently, and composite scientific workflows and resource heterogeneity and dynamism have revealed the limitations of traditional HPC resource and workflow management. It has become clear that the initially disparate communities have much to benefit in working together. This special issue aims to bridge the gap between HPC and cloud to discuss work in converged computing – the collaborative space between these traditionally separate communities – to develop novel technologies and applications. These hybrid technologies might span the gamut from automation, workflows, containerization, to software development and deployment and testing. This is a timely topic as collaborative work is happening to a greater degree that combines approaches from high performance computing with cloud-native computing.
## Guest Editors
@@ -24,3 +20,7 @@ Major trends have brought the cloud and high performance computing (HPC) communi
- Jakob Luettgau, University of Tennessee Knoxville
- Evan Bollig, Amazon Web Services
- Bill Magro, Google
+
+## Thank you
+
+This site is based on [this template](https://bootstrapemail.com/) that is covered under the MIT license. The license is included [here](.github/LICENSE-BOOTSTRAP.md).
diff --git a/_config.yml b/_config.yml
new file mode 100644
index 0000000..a126725
--- /dev/null
+++ b/_config.yml
@@ -0,0 +1,53 @@
+# Welcome to Jekyll!
+#
+# This config file is meant for settings that affect your whole blog, values
+# which you are expected to set up once and rarely edit after that. If you find
+# yourself editing this file very often, consider using Jekyll's data files
+# feature for the data you need to update frequently.
+#
+# For technical reasons, this file is *NOT* reloaded automatically when you use
+# 'bundle exec jekyll serve'. If you change this file, please restart the server process.
+
+# Site settings
+# These are used to personalize your new site. If you look in the HTML files,
+# you will see them accessed via {{ site.title }}, {{ site.email }}, and so on.
+# You can create any custom variable you would like, and they will be accessible
+# in the templates via {{ site.myvariable }}.
+title: Converged Computing
+email: sochat1@llnl.gov
+description: >- # this means to ignore newlines until "baseurl:"
+ The best of both worlds for cloud and HPC
+baseurl: "" # the subpath of your site, e.g. /blog
+url: "https://converged-computing.org" # the base hostname & protocol for your site, e.g. http://example.com
+permalink: /docs/:title
+
+# Build settings
+markdown: kramdown
+plugins:
+ - jekyll-feed
+kramdown:
+ auto_id_prefix: 'doc-'
+
+# Collections
+collections:
+ docs:
+ output: true
+ permalink: /:collection/:title/
+
+# Defaults
+defaults:
+ -
+ scope:
+ path: ""
+ type: "docs"
+ values:
+ layout: "docs"
+
+
+# Exclude from processing.
+# The following items will not be processed, by default. Create a custom list
+# to override the default setting.
+exclude:
+ - Gemfile
+ - Gemfile.lock
+ - vendor
\ No newline at end of file
diff --git a/_data/border_radiuses.csv b/_data/border_radiuses.csv
new file mode 100644
index 0000000..25556ce
--- /dev/null
+++ b/_data/border_radiuses.csv
@@ -0,0 +1,10 @@
+name,radius
+,4
+-none,0
+-sm,2
+-md,6
+-lg,8
+-xl,12
+-2xl,16
+-3xl,24
+-full,9999
diff --git a/_data/border_widths.csv b/_data/border_widths.csv
new file mode 100644
index 0000000..5870a9c
--- /dev/null
+++ b/_data/border_widths.csv
@@ -0,0 +1,7 @@
+name,width
+,1
+-2,2
+-3,3
+-4,4
+-5,5
+-0,0
diff --git a/_data/displays.json b/_data/displays.json
new file mode 100644
index 0000000..87a5bfa
--- /dev/null
+++ b/_data/displays.json
@@ -0,0 +1 @@
+['inline','inline-block','block','table','none']
diff --git a/_data/font_sizes.csv b/_data/font_sizes.csv
new file mode 100644
index 0000000..dfc8ffb
--- /dev/null
+++ b/_data/font_sizes.csv
@@ -0,0 +1,12 @@
+name,size
+xs,12
+sm,14
+base,16
+lg,18
+xl,20
+2xl,24
+3xl,30
+4xl,36
+5xl,48
+6xl,64
+7xl,80
diff --git a/_data/font_weights.json b/_data/font_weights.json
new file mode 100644
index 0000000..fdf2c27
--- /dev/null
+++ b/_data/font_weights.json
@@ -0,0 +1 @@
+[100, 200, 300, 400, 500, 600, 700, 800, 900]
diff --git a/_data/grid_cols.csv b/_data/grid_cols.csv
new file mode 100644
index 0000000..848e3b6
--- /dev/null
+++ b/_data/grid_cols.csv
@@ -0,0 +1,13 @@
+name,width
+1,8.333333%
+2,16.666667%
+3,25%
+4,33.333333%
+5,41.666667%
+6,50%
+7,58.333333%
+8,66.666667%
+9,75%
+10,83.333333%
+11,91.666667%
+12,100%
diff --git a/_data/line_heights.csv b/_data/line_heights.csv
new file mode 100644
index 0000000..37a423b
--- /dev/null
+++ b/_data/line_heights.csv
@@ -0,0 +1,5 @@
+name,size
+1,1
+sm,1.25
+base,1.5
+lg,2
diff --git a/_data/palette_colors.csv b/_data/palette_colors.csv
new file mode 100644
index 0000000..54085b4
--- /dev/null
+++ b/_data/palette_colors.csv
@@ -0,0 +1,103 @@
+name,color
+black,#000000
+white,#ffffff
+transparent,transparent
+gray-100,#f8f9fa
+gray-200,#e9ecef
+gray-300,#dee2e6
+gray-400,#ced4da
+gray-500,#adb5bd
+gray-600,#6c757d
+gray-700,#495057
+gray-800,#343a40
+gray-900,#212529
+blue-100,#cfe2ff
+blue-200,#9ec5fe
+blue-300,#6ea8fe
+blue-400,#3d8bfd
+blue-500,#0d6efd
+blue-600,#0a58ca
+blue-700,#084298
+blue-800,#052c65
+blue-900,#031633
+indigo-100,#e0cffc
+indigo-200,#c29ffa
+indigo-300,#a370f7
+indigo-400,#8540f5
+indigo-500,#6610f2
+indigo-600,#520dc2
+indigo-700,#3d0a91
+indigo-800,#290661
+indigo-900,#140330
+purple-100,#e2d9f3
+purple-200,#c5b3e6
+purple-300,#a98eda
+purple-400,#8c68cd
+purple-500,#6f42c1
+purple-600,#59359a
+purple-700,#432874
+purple-800,#2c1a4d
+purple-900,#160d27
+pink-100,#f7d6e6
+pink-200,#efadce
+pink-300,#e685b5
+pink-400,#de5c9d
+pink-500,#d63384
+pink-600,#ab296a
+pink-700,#801f4f
+pink-800,#561435
+pink-900,#2b0a1a
+red-100,#f8d7da
+red-200,#f1aeb5
+red-300,#ea868f
+red-400,#e35d6a
+red-500,#dc3545
+red-600,#b02a37
+red-700,#842029
+red-800,#58151c
+red-900,#2c0b0e
+orange-100,#ffe5d0
+orange-200,#fecba1
+orange-300,#feb272
+orange-400,#fd9843
+orange-500,#fd7e14
+orange-600,#ca6510
+orange-700,#984c0c
+orange-800,#653208
+orange-900,#331904
+yellow-100,#fff3cd
+yellow-200,#ffe69c
+yellow-300,#ffda6a
+yellow-400,#ffcd39
+yellow-500,#ffc107
+yellow-600,#cc9a06
+yellow-700,#997404
+yellow-800,#664d03
+yellow-900,#332701
+green-100,#d1e7dd
+green-200,#a3cfbb
+green-300,#75b798
+green-400,#479f76
+green-500,#198754
+green-600,#146c43
+green-700,#0f5132
+green-800,#0a3622
+green-900,#051b11
+teal-100,#d2f4ea
+teal-200,#a6e9d5
+teal-300,#79dfc1
+teal-400,#4dd4ac
+teal-500,#20c997
+teal-600,#1aa179
+teal-700,#13795b
+teal-800,#0d503c
+teal-900,#06281e
+cyan-100,#cff4fc
+cyan-200,#9eeaf9
+cyan-300,#6edff6
+cyan-400,#3dd5f3
+cyan-500,#0dcaf0
+cyan-600,#0aa2c0
+cyan-700,#087990
+cyan-800,#055160
+cyan-900,#032830
diff --git a/_data/sizings.json b/_data/sizings.json
new file mode 100644
index 0000000..bc0789d
--- /dev/null
+++ b/_data/sizings.json
@@ -0,0 +1 @@
+[0,1,2,3,4,5,6,7,8,9,10,12,16,20,24,32,40,48,56,64,80,96,112,128,144,150]
diff --git a/_data/spacings.json b/_data/spacings.json
new file mode 100644
index 0000000..c966fce
--- /dev/null
+++ b/_data/spacings.json
@@ -0,0 +1 @@
+[0,1,2,3,4,5,6,7,8,9,10,12,16,20,24,32,40]
diff --git a/_data/terms.yaml b/_data/terms.yaml
new file mode 100644
index 0000000..3f91d97
--- /dev/null
+++ b/_data/terms.yaml
@@ -0,0 +1,24 @@
+getting-started:
+- name: Introduction
+ url: /docs/introduction
+- name: About
+ url: /about
+# - name: Goals
+# url: /docs/goals
+comparisons:
+- name: HPC vs HTC
+ url: /docs/hpc-vs-htc
+
+patterns:
+- name: jobs
+ url: /docs/job-patterns
+- name: workflows
+ url: /docs/workflow-patterns
+#- section: Projects
+# items:
+# - name: Journal Special Issue
+# url: /docs/journal
+# - name: Kubernetes
+# url: /docs/kubernetes
+# - name: HPC Schedulers
+# url: /docs/hpc
diff --git a/_data/theme_colors.csv b/_data/theme_colors.csv
new file mode 100644
index 0000000..beaad4a
--- /dev/null
+++ b/_data/theme_colors.csv
@@ -0,0 +1,9 @@
+name,color
+primary,#0d6efd
+secondary,#6c757d
+success,#198754
+info,#0dcaf0
+warning,#ffc107
+danger,#dc3545
+light,#f8f9fa
+dark,#212529
diff --git a/_docs/accounting.md b/_docs/accounting.md
new file mode 100644
index 0000000..4009ada
--- /dev/null
+++ b/_docs/accounting.md
@@ -0,0 +1,14 @@
+---
+layout: docs
+title: "Accounting"
+sections:
+ - Example
+---
+
+Keeping track of resource usage time, usually on the level of a user or group. This information can be stored in a database and used for making future decisions about scheduling or priority. In terms of units of resource usage, this can vary.
+
+## Example
+
+HPC uses core-hours (time spent doing the compute). One core-hour equals one CPU core being used for the duration of one hour of execution time. The time is measured as the jobs elapsed wall-clock time from start to finish. [[ref](https://help.itc.rwth-aachen.de/en/service/rhr4fjjutttf/article/090b27dc31484f3c833957978b039b55/), [ref](https://slurm.schedmd.com/accounting.html)]. Cloud does not have the same need for multi-tenancy as HPC, and so accounting to track resource usage is typically associated with cost. Cloud accounts for resources to bill projects, and charges based on data usage or instance cost.
+
+In Flux, accounting is separate from scheduling (flux-sched) as a design choice to make them swappable (e.g., install a different scheduler) however in many HPC managers they are built together, meaning accounting is part of the scheduler.
diff --git a/_docs/allocation.md b/_docs/allocation.md
new file mode 100644
index 0000000..3ef6a6c
--- /dev/null
+++ b/_docs/allocation.md
@@ -0,0 +1,12 @@
+---
+layout: docs
+title: "Allocation"
+#sections:
+# - Example
+---
+
+The actual set of physical resources that an application is running on. There are two types of allocations: shared and exclusive.
+
+ - *Exclusive allocation*: jobs have dedicated physical resources (e.g., nodes, cores, memory). Multiple users cannot share a physical resource, and resources are not shared between jobs. This setup is common in HPC.
+ - *Shared allocation*: jobs share underlying physical resources (e.g., nodes, cores, memory). Multiple users can run on the same physical resources. This setup is common in cloud.
+
diff --git a/_docs/application-programming-interface.md b/_docs/application-programming-interface.md
new file mode 100644
index 0000000..d298dff
--- /dev/null
+++ b/_docs/application-programming-interface.md
@@ -0,0 +1,8 @@
+---
+layout: docs
+title: "Application Programming Interface"
+#sections:
+# - Example
+---
+
+Programmatic interface for interacting with components. In Kubernetes this might be the kube-apiserver, and in Flux it could be a socket (connected via flux proxy) or the flux restful API.
diff --git a/_docs/batch-system.md b/_docs/batch-system.md
new file mode 100644
index 0000000..63b155b
--- /dev/null
+++ b/_docs/batch-system.md
@@ -0,0 +1,18 @@
+---
+layout: docs
+title: "Batch System"
+#sections:
+# - What is Converged Computing
+# - Why do we need to work together
+---
+
+A batch system provides the interface to manage resources and schedule workloads. Due to the complexity, batch systems often manifest as a combination of components or modules, and we can see this for both HPC systems and Kubernetes.
+
+Advanced / developer note: the modularity afforded by these systems often makes them very flexible / pluggable for integrating components from one into the other, etc. Batch systems can be nested in other batch systems, if the technology allows for it.
+
+
+{% include example.html prefix="Flux:" text="We might consider the combination of flux-core, flux-sched, and flux-security as a combined set of modules that manifest in a batch system, deployed on either bare metal or a virtual machine (or pod)." %}
+
+
+
+{% include example.html prefix="Kubernetes:" text="We might consider the Kubernetes default scheduler combined with control-plane(s) and one or more kubelet a basic batch system, with the addition of Kueue to add a queue. In both cases, the batch systems can receive some specification for a unit of work (e.g., a job)." %}
diff --git a/_docs/batch.md b/_docs/batch.md
new file mode 100644
index 0000000..cbfbe24
--- /dev/null
+++ b/_docs/batch.md
@@ -0,0 +1,9 @@
+---
+layout: docs
+title: "Batch"
+#sections:
+# - What is Converged Computing
+# - Why do we need to work together
+---
+
+When someone says "batch" they are very generally referring to the combined system to manage resources and schedule workloads. The root of the term originates from "batch processing" - a sequence of programs and input data that would be processed in serial on a computer [[ref](https://en.wikipedia.org/wiki/Batch_processing)]. In Kubernetes, batch refers to the [working group](https://github.com/kubernetes/community/blob/master/wg-batch/README.md) and set of APIs (Job and CronJob abstractions) concerned with submitting jobs, which are fundamentally different than other Kubernetes objects because they have state, and are intended to be created and at some point complete. There is also a Cloud Native Compuing Foundation (CNCF) [batch working group](https://tag-runtime.cncf.io/wgs/bsi/charter/) that is interested in similar abstractions, and takes a stronger research standpoint. A very simple idea of "batch" (often used in Kubernetes) is to describe jobs running in parallel. This can be done both for Kubernetes and HPC. However, the coupling of the jobs is often very different between the spaces, with HPC being tightly coupled and Kubernetes batch more loosely. These ideas can be further expanded later.
diff --git a/_docs/cluster.md b/_docs/cluster.md
new file mode 100644
index 0000000..079b531
--- /dev/null
+++ b/_docs/cluster.md
@@ -0,0 +1,12 @@
+---
+layout: docs
+title: "Cluster"
+sections:
+ - Example
+---
+
+A cluster is a group of resources that collectively run applications or provide services or storage. Clusters exist to serve the needs of multiple users and/or multiple applications with resource requirements that are greater than what is provided by a single machine. The complexity of the cluster generally reflects the needs of its users, and often reflects the economic decisions of a center providing the resource.
+
+## Example
+
+As an example, owning a cluster (common in HPC communities) presents a different cost model than renting resources (common for cloud) that providers/centers must choose between. The nodes can be co-located (close by in terms of communication latency) or far apart (regions or zones in a cloud provider). Generally speaking, co-location can have a huge influence on network latency and thus application performance. If we consider all the compute in the world, we can consider a cluster akin to a cluster in a graph - a set of vertices that are more highly connected to one another than other nodes. A cluster could be a set of nodes running a resource manager on bare metal of an HPC cluster, or a set of nodes running Kubernetes and applications via pods on those nodes. While cloud and HPC are predominant now, the first distributed clusters came by way of grid computing in the early 1990s.
diff --git a/_docs/compute.md b/_docs/compute.md
new file mode 100644
index 0000000..b4ec798
--- /dev/null
+++ b/_docs/compute.md
@@ -0,0 +1,14 @@
+---
+layout: docs
+title: "Compute"
+sections:
+ - Example
+# - Why do we need to work together
+---
+
+Computing is changing information (i.e., bits) in time. Compute resources can be connected to each other via a network, and can transmit the results of computation to storage.
+
+## Example
+
+A computing processor such as a general-purpose CPU executes instructions to transform bits. The rate at which instructions can transform bits is a fundamental measure of computing performance. Specialized computing processors such as GPUs, FPGAs, ASICs, and others are designed to sacrifice general-purpose performance for higher performance on more specialized instructions or types of bit transformations. Access to computing resources can be physical or virtual.
+
diff --git a/_docs/database.md b/_docs/database.md
new file mode 100644
index 0000000..7676a9a
--- /dev/null
+++ b/_docs/database.md
@@ -0,0 +1,14 @@
+---
+layout: docs
+title: "Database"
+sections:
+ - Example
+---
+
+An organized collection of data, typically optimized to support receiving or querying certain information efficiently.
+
+## Example
+
+Any kind of key value store (e.g., etcd in Kubernetes, or kvs the "key value store" in Flux) that can store some component of state for a cluster, resource, or application.
+
+
diff --git a/_docs/hpc-vs-htc.md b/_docs/hpc-vs-htc.md
new file mode 100644
index 0000000..26a18cc
--- /dev/null
+++ b/_docs/hpc-vs-htc.md
@@ -0,0 +1,17 @@
+---
+layout: docs
+title: "HPC vs HTC"
+#sections:
+# - What is Converged Computing
+# - Why do we need to work together
+---
+
+Although HPC is mentioned heavily within k8s-batch, HTC is not covered as extensively.
+
+HPC, or "High Performance Computing," refers to the deployment and use of supercomputers and parallel processing techniques for solving complex computational problems. HPC systems are designed to deliver high performance by aggregating computing power in a way that enables higher processing speed and throughput for tasks that require significant computational resources.
+
+Whereas HTC, or "High Throughput Computing," focuses on the efficient execution of a large number of loosely coupled or independent tasks over long periods of time. HTC systems are optimized not for the raw speed of any single computation, but for the overall volume of computations that can be performed over a given time period.
+
+K8s is not constructed for HTC workloads, and there are [no plans to support it natively](https://github.com/kubernetes-sigs/kueue/blob/main/keps/693-multikueue/README.md?plain=1#L56). The main players trying to support k8s-HTC are [HTCondor](https://htcondor.org/) (both in k8s and out) as well as [Armada](https://github.com/armadaproject/armada).
+
+There is also MTC, “Many Task Computing”, which tries to bridge the two, but that term is used significantly less. See these [notes](https://en.wikipedia.org/wiki/High-throughput_computing#High-throughput_vs._high-performance_vs._many-task) on Wikipedia to learn more.
diff --git a/_docs/introduction.md b/_docs/introduction.md
new file mode 100644
index 0000000..eb5e084
--- /dev/null
+++ b/_docs/introduction.md
@@ -0,0 +1,23 @@
+---
+layout: docs
+title: "Introduction"
+sections:
+ - What is Converged Computing
+ - Why do we need to work together
+---
+
+### What is Converged Computing?
+
+We have vision for a future where the cloud and high performance computing communities are working together, and learning from one another to build new technologies that combine the best of both worlds. If you think about it, the area between cloud and HPC is muddled at best, akin to a “fog of war” in your favorite computer game. We aim to shed some light on this fog, and map out the landscape that will make it possible to easily move workloads between cloud and HPC environments. We plan to tackle issues that range from:
+
+- job orchestration and management
+- resource management
+- scheduling
+- ensembles
+
+and more! This is a living document that should be updated when needed and represent a current state of thinking.
+
+### Why do we need to work together?
+
+This is a collaboration between the HPC and cloud native (industry) communities to derive definitions for converged computing. We are starting with high level definitions that will populate a website on converged computing (hosted at our converged-computing GitHub, branded professionally) and associated videos on YouTube. We will present the landscape of these terms, first at a high level, and then drill down into each with details about what it means for HPC vs. Kubernetes. This work is an important collaborative effort to present definitions and concepts that account for the experience of both communities!
+
diff --git a/_docs/job-manager.md b/_docs/job-manager.md
new file mode 100644
index 0000000..bdbd5b4
--- /dev/null
+++ b/_docs/job-manager.md
@@ -0,0 +1,8 @@
+---
+layout: docs
+title: "Job Manager"
+#sections:
+# - Example
+---
+
+The job manager receives new jobs, and is in charge of moving them through states. As an example, the Flux Framework job manager defines states new, depend, priority, sched, run, and cleanup. Each state might trigger events or connections to other components of the batch system.
diff --git a/_docs/job.md b/_docs/job.md
new file mode 100644
index 0000000..18e1f02
--- /dev/null
+++ b/_docs/job.md
@@ -0,0 +1,11 @@
+---
+layout: docs
+title: "Job"
+#sections:
+# - What is Converged Computing
+# - Why do we need to work together
+---
+
+A job is a unit of work that runs to completion, and is typically the combination of input data, environment variables, description of resources needed, an application, and output directives. On a high level a single job can be replicated into an array (multiple of the same job run in parallel) or assembled like legos into a workflow to manifest in more complex application logic. It's common to refer to a grouping of jobs, where they are non-interactive and submitting to use a complex set of resources, as a batch job. A job is typically akin to one step or task in a workflow, or run on its own.
+
+{% include example.html text="In Flux, a batch job can be defined by way of a script that can create one or more flux jobs or even allocations. In Kubernetes, a batch job could be a Job, or a JobSet." %}
\ No newline at end of file
diff --git a/_docs/jobspec.md b/_docs/jobspec.md
new file mode 100644
index 0000000..4986c58
--- /dev/null
+++ b/_docs/jobspec.md
@@ -0,0 +1,9 @@
+---
+layout: docs
+title: "Job Specification"
+#sections:
+# - Example
+---
+
+An abstraction that describes the resources, applications, task configuration, and amount of time needed by a job. This includes (on a high level) everything from executables to environment to resources needed. In Kubernetes a jobspec might look like a YAML specification for a pod or batch/v1 job, and on a traditional HPC system it might look like a bash script that runs an executable with directives for resources and other parameters. Flux has a form definition of a JobSpec that populates a resource graph.
+
diff --git a/_docs/monitoring.md b/_docs/monitoring.md
new file mode 100644
index 0000000..a2c364c
--- /dev/null
+++ b/_docs/monitoring.md
@@ -0,0 +1,8 @@
+---
+layout: docs
+title: "Monitoring"
+#sections:
+# - Example
+---
+
+Tools and methods to keep track of the status/state of a system and/or applications running on it. Likely, strategies for monitoring of systems are different from those that monitor applications. This definition might be handled based on "SRE" type questions - what happens when a node goes down? A node vs. a pod vs. an application? What happens if there is a security vulnerability?
diff --git a/_docs/network.md b/_docs/network.md
new file mode 100644
index 0000000..d7c3adf
--- /dev/null
+++ b/_docs/network.md
@@ -0,0 +1,15 @@
+---
+layout: docs
+title: "Network"
+sections:
+ - Example
+# - Why do we need to work together
+---
+
+Networking is transportation of bits through space. A network should support connectivity of nodes (and components within) and ideally have low latency, high bandwidth, high reliability, and concurrent connections. The needs of the network should support the needs of the applications that users want to run.
+
+## Example
+
+In high performance computing a network might be an Infiniband fabric, and in a simple local network you might just have ethernet, or on cloud something like elastic fiber adapted (EFA on AWS). Often networks are optimized for specific hardware resources (e.g., Google TPU) with preference placed to a particular customer base or application need.
+
+
diff --git a/_docs/nodes.md b/_docs/nodes.md
new file mode 100644
index 0000000..1ac778b
--- /dev/null
+++ b/_docs/nodes.md
@@ -0,0 +1,19 @@
+---
+layout: docs
+title: "Nodes"
+sections:
+ - Example
+---
+
+> Synonyms: virtual machine (VM) instances, server
+
+A node is a server resource, an addressable compute or storage unit (often supporting an ip-address). A node can either be:
+
+- virtual: an abstraction to virtualize system resources. A node that is virtual can be a virtual machine, which uses some hypervisor technology, or even a linux container.
+- physical: no virtualization, and often called "bare metal"
+
+A node can exclusively be for storage or compute, or can serve both purposes.
+
+## Example
+
+A [Kubernetes node](https://kubernetes.io/docs/concepts/architecture/nodes/) is typically intended for compute, as the unit for storage would be called a [volume](https://kubernetes.io/docs/concepts/storage/). A node deployed for HPC typically takes on one role or a hybrid approach. Nodes can be shared or exclusive (see allocation type). At a high level, a "node" might refer to an instance on a cloud provider, a "node" in Kubernetes [[ref](https://kubernetes.io/docs/concepts/architecture/nodes/)], or a bare metal machine. It is an abstraction for a base machine.
diff --git a/_docs/pod.md b/_docs/pod.md
new file mode 100644
index 0000000..d285bb5
--- /dev/null
+++ b/_docs/pod.md
@@ -0,0 +1,13 @@
+---
+layout: docs
+title: "Pod"
+sections:
+ - Example
+# - Why do we need to work together
+---
+
+A slice of a node that provides a layer of abstraction for defining a scoped piece of work, including (but not limited to) providing an operating system, or a grouping of resources. A pod typically makes a request for resources, and is intended to run one or more units of work (e.g., containers). Pods are exclusive to Kubernetes and the term is not used in HPC, however we might consider the HPC equivalent to be anything that represents a "unit of computing" that is schedulable for units of work (some number of containers or applications).
+
+## Example
+
+For Kubernetes, a unit of computing is referred to as a Pod, which explicitly is a group of containers with shared storage and network resources. A pod is a logical node. It is the smallest unit of work you can deploy. The closest thing we have in HPC would be like a scheduling script or a resource request - a packaged set of work that requires some set of resources. A key difference is that pods are designed to well support services, while batch work on HPC is not.
diff --git a/_docs/queueing.md b/_docs/queueing.md
new file mode 100644
index 0000000..0907b10
--- /dev/null
+++ b/_docs/queueing.md
@@ -0,0 +1,13 @@
+---
+layout: docs
+title: "Scheduling"
+sections:
+ - Example
+---
+
+A means to take requests for work and order them in a way by priority (fair share or other algorithms) and availability. Queuing systems are interested in attributes such as satisfiability, reservations, and backfilling.
+
+## Example
+
+In Kubernetes, a tool like Kueue [[ref](https://kueue.sigs.k8s.io/docs/tasks/administer_cluster_quotas/)] might create simple job requests for users and assign them to be run based on priority settings. In an HPC resource manager like SLURM [[ref](https://slurm.schedmd.com/quickstart.html)], it's more likely that groups of nodes (called partitions) are allocated to user jobs based on an algorithm like fair share.
+
diff --git a/_docs/reservation.md b/_docs/reservation.md
new file mode 100644
index 0000000..e3d76ef
--- /dev/null
+++ b/_docs/reservation.md
@@ -0,0 +1,8 @@
+---
+layout: docs
+title: "Reservation"
+#sections:
+# - Example
+---
+
+An assurance of availability for a quantity and quality of resources for a future time-point. If resources are unavailable at this point in time for a job, we reserve an allocation (physical resources) for that job in the future. There can be variance between how the reservation is done (e.g., very specific resources vs. matching a particular flavor) as well as guarantees, as different environments make different assumptions about resource availability. In an environment where there are essentially unlimited resources, a reservation may not be a relevant or widely used term.
diff --git a/_docs/resource-manager.md b/_docs/resource-manager.md
new file mode 100644
index 0000000..c864912
--- /dev/null
+++ b/_docs/resource-manager.md
@@ -0,0 +1,8 @@
+---
+layout: docs
+title: "Resource Manager"
+#sections:
+# - Example
+---
+
+The resource manager is in charge of tracking and monitoring hardware resources.
diff --git a/_docs/resources.md b/_docs/resources.md
new file mode 100644
index 0000000..2f65417
--- /dev/null
+++ b/_docs/resources.md
@@ -0,0 +1,15 @@
+---
+layout: docs
+title: "Resources"
+sections:
+ - Example
+---
+
+
+Hardware (nodes, storage, accelerators) or flow transports (network, power) that make up a system (that can be logically partitioned for tasks) and can be consumed by its users. Each resource type has a unit of abstraction, and is finite and thus needs to be managed.
+
+
+## Example
+
+Hardware typically provides compute or storage for a job, and the scale can vary from a socket or CPU to an entire node. The finite nature of resources in the context of some number of tasks or users requires intelligent scheduling. On cloud, there is a perception that resources are unlimited, and only bounded by the amount of money allowed to be spent. This is typically not the truth. For high performance computing, the entire set of resources is more transparent. In both cases, the resources are finite, however the perception is different.
+
diff --git a/_docs/scheduling.md b/_docs/scheduling.md
new file mode 100644
index 0000000..b9a5cfe
--- /dev/null
+++ b/_docs/scheduling.md
@@ -0,0 +1,12 @@
+---
+layout: docs
+title: "Scheduling"
+sections:
+ - Example
+---
+
+Taking a resource request and performing a mapping such that units of work are mapped to resources. A scheduler is a function that takes as input a triple (resource shape, requested start time, requested time interval) and outputs a four tuple (resources, start time of guarantee, end time guarantee, binding guarantee) to map the units of work to said resources. For a graph scheduler, this means that a job is translated to a resource request, and the resource request is a subgraph of the entire graph of resources known to the scheduler. If it's the case that a subgraph is mapped to a job id because of a reservation, we search a smaller search space. The unit of time is a variable here, as different schedulers will honor different units.
+
+## Example
+
+In Kubernetes, “scheduling” is the finding a node that can satisfy your resource request. Unlike in HPC, it is specific to scheduling pods (resource groups with containers) to physical nodes. In simple terms - "What runs next and where."
diff --git a/_docs/services.md b/_docs/services.md
new file mode 100644
index 0000000..9bac013
--- /dev/null
+++ b/_docs/services.md
@@ -0,0 +1,15 @@
+---
+layout: docs
+title: "Services"
+sections:
+ - Example
+# - Why do we need to work together
+---
+
+A persistent interface that exposes a needed functionality. It is one or more processes that do not have a stop time.
+
+## Example
+
+In high performance computing, a service is typically a task manager, application programming interface, or database. HPC systems sometimes have protected or isolated environments explicitly for services. Services typically run alongside applications that interact via client APIs or web interfaces. In Kubernetes, a service describes exposing a network interface of a pod. This is a prime example of the same term meaning fundamentally different things.
+
+
diff --git a/_docs/storage.md b/_docs/storage.md
new file mode 100644
index 0000000..fc7228b
--- /dev/null
+++ b/_docs/storage.md
@@ -0,0 +1,22 @@
+---
+layout: docs
+title: "Storage"
+sections:
+ - Example
+---
+
+> Synonyms: volumes
+
+Storage is transportation of information (i.e., bits) through time [^1]. It is a means to maintain a state of data. While both cloud and HPC provide underlying nodes for storing data, the extent to which the user is able to access and have awareness of the underlying structure varies. Generally speaking, locations vary in the following attributes:
+
+- Frequency of access (frequent vs. infrequent for an archive)
+- Permanency of access (temporal or ephemeral for analyses vs. long term archives)
+- Permissions (read, write, read/write)
+- Cost of storage and operations/access
+
+
+## Example
+
+For high performance computing, a shared filesystem is provided, and the shared nature is transparent. This means that users are aware of having ownership over a personal space (typically called "home" or a working space called "scratch") or a group space, and are provided tools to allow them to change how data is shared. For cloud, although data storage might have a similar design, the user is presented with a view of sole ownership of a set of locations for storing data. Associated filesystem or object buckets can vary in permissions, node access, and read/write. High performance computing will almost always have shared, often localized storage (a filesystem that supports multiple users with read-write) and in cloud this is almost an anti-pattern. The default (and easiest) setup is usually just read for a single user, and at most read for multiple. Setting up RWX is challenging. For high performance computing, we are interested in supporting a shared filesystem for several kinds of applications, and one with RWX across nodes for applications to share.
+
+[^1]: Feynman's Lectures in Computation (4.1 p. 95) ""Now this isn't exactly the same situation as with memory - which is like sending a message through time rather than space - but you can see the similarities. We store something in memory and at a later time we read it backout - in the interim the stored "message" is subject to noise."
diff --git a/_docs/user-priority-and-fairness.md b/_docs/user-priority-and-fairness.md
new file mode 100644
index 0000000..90bb82e
--- /dev/null
+++ b/_docs/user-priority-and-fairness.md
@@ -0,0 +1,13 @@
+---
+layout: docs
+title: "Application Programming Interface"
+#sections:
+# - Example
+---
+
+We don't keep a historical record, but rather give resources based on who deserves what at any particular instant. This is an instantaneous measurement rather than one tracked over time. [[ref](https://cs.stanford.edu/~matei/papers/2011/nsdi_drf.pdf)]
+
+An example comes from [Slurm](https://slurm.schedmd.com/priority_multifactor.html)
+
+Both priority and fairness impact how queueing is done.
+
diff --git a/_docs/workflow.md b/_docs/workflow.md
new file mode 100644
index 0000000..d4c7422
--- /dev/null
+++ b/_docs/workflow.md
@@ -0,0 +1,17 @@
+---
+layout: docs
+title: "Workflow"
+#sections:
+# - What is Converged Computing
+# - Why do we need to work together
+---
+
+A workflow is a set of tasks with dependencies that need to be executed in a specific order for proper handling of exchanging inputs and outputs of data. Workflows typically have two components: data and applications, and workflow tools must decide the granularity at which to map tasks to execution workload units. Workflow steps can map into workloads, e.g.,
+
+```
+workflow -> DAG -> scheduler -> workload
+```
+
+{% include example.html prefix="" text="A workflow tool might generate a directed acyclic graph (DAG) of individual tasks that can be handed to a scheduler." %}
+
+
diff --git a/_docs/workload.md b/_docs/workload.md
new file mode 100644
index 0000000..3ae8ead
--- /dev/null
+++ b/_docs/workload.md
@@ -0,0 +1,9 @@
+---
+layout: docs
+title: "Workload"
+#sections:
+# - What is Converged Computing
+# - Why do we need to work together
+---
+
+A workload is a set of jobs or tasks scheduled by a scheduler and managed by a resource manager. In the simplest terms, it could be as a single job tasked to do some computation using a defined set of resources. In more realistic terms, it is a data-intensive task that is spread across nodes and runs in parallel where each part uses a subset of CPU/GPU. A workload is not a workflow that has a directed acyclic graph (DAG) but rather the units of work in the graph. A vertex in a workflow DAG is a workload. If you find yourself saying Step A THEN B, you likely are not in a workload (step) but thinking about a workflow (DAG).
diff --git a/_includes/citation.html b/_includes/citation.html
new file mode 100644
index 0000000..beb172d
--- /dev/null
+++ b/_includes/citation.html
@@ -0,0 +1,6 @@
+
+
+
+Suggested Citation:
+
+Converged Computing Authors. "{{ page.title }}." Converged Computing Community Space {{ site.time | date_to_string }}, {{ site.url }}{{ page.url }} (accessed {{ site.time | date: '%d %b %y' }}). [doi]
diff --git a/_includes/close-html.html b/_includes/close-html.html
new file mode 100644
index 0000000..3cb1c3f
--- /dev/null
+++ b/_includes/close-html.html
@@ -0,0 +1,10 @@
+
+
+
+
+
+
+
+
+