Skip to content

Commit 968e5b6

Browse files
authored
Merge pull request #1282 from dmesser/readme-update
mention OLMs features in the introduction
2 parents 06695ca + 1585297 commit 968e5b6

File tree

1 file changed

+13
-10
lines changed

1 file changed

+13
-10
lines changed

README.md

Lines changed: 13 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -7,22 +7,25 @@
77

88
## Overview
99

10-
This project is a component of the [Operator Framework](https://github.com/operator-framework), an open source toolkit to manage Kubernetes native applications, called Operators, in an effective, automated, and scalable way. Read more in the [introduction blog post](https://coreos.com/blog/introducing-operator-framework).
10+
This project is a component of the [Operator Framework](https://github.com/operator-framework), an open source toolkit to manage Kubernetes native applications, called Operators, in an effective, automated, and scalable way. Read more in the [introduction blog post](https://operatorhub.io/what-is-an-operator).
1111

12-
OLM extends Kubernetes to provide a declarative way to install, manage, and upgrade operators and their dependencies in a cluster.
12+
OLM extends Kubernetes to provide a declarative way to install, manage, and upgrade Operators and their dependencies in a cluster. It provides the following features:
1313

14-
It also enforces some constraints on the components it manages in order to ensure a good user experience.
14+
### Over-the-Air Updates and Catalogs
15+
Kubernetes clusters are being kept up to date using elaborate update mechanisms today, more often automatically and in the background. Operators, being cluster extensions, should follow that. OLM has a concept of catalogs from which Operators are available to install and being kept up to date. In this model OLM allows maintainers granular authoring of the update path and gives commercial vendors a flexible publishing mechanism using channels.
1516

16-
This project enables users to do the following:
17+
### Dependency Model
18+
With OLMs packaging format Operators can express dependencies on the platform and on other Operators. They can rely on OLM to respect these requirements as long as the cluster is up. In this way, OLMs dependency model ensures Operators stay working during their long lifecycle across multiple updates of the platform or other Operators.
1719

18-
* Define applications as a single Kubernetes resource that encapsulates requirements and metadata
19-
* Install applications automatically with dependency resolution or manually with nothing but `kubectl`
20-
* Upgrade applications automatically with different approval policies
20+
### Discoverability
21+
OLM advertises installed Operators and their services into the namespaces of tenants. They can discover which managed services are available and which Operator provides them. Administrators can rely on catalog content projected into a cluster, enabling discovery of Operators available to install.
2122

22-
This project does not:
23+
### Cluster Stability
24+
Operators must claim ownership of their APIs. OLM will prevent conflicting Operators owning the same APIs being installed, ensuring cluster stability.
25+
26+
### Declarative UI controls
27+
Operators can behave like managed service providers. Their user interface on the command line are APIs. For graphical consoles OLM annotates those APIs with descriptors that drive the creation of rich interfaces and forms for users to interact with the Operator in a natural, cloud-like way.
2328

24-
* Replace [Helm](https://github.com/kubernetes/helm)
25-
* Turn Kubernetes into a [PaaS](https://en.wikipedia.org/wiki/Platform_as_a_service)
2629

2730
## Prerequisites
2831

0 commit comments

Comments
 (0)