Skip to content

DOCS.md #226

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Nov 17, 2020
Merged

DOCS.md #226

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 6 additions & 6 deletions docs/DOCS.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -56,16 +56,16 @@ TODO: explain running operator locally against a cluster

### Run Single Instance

There should be always just one instance of an operator running at a time (think process). If there there would be
There should be always just one instance of an operator running at a time (think process). If there would be
two ore more, in general it could lead to concurrency issues. Note that we are also doing optimistic locking when we update a resource.
In this way the operator is not highly available. However for operators this not necessary an issue,
In this way the operator is not highly available. However for operators this is not necessarily an issue,
if the operator just gets restarted after it went down.

### At Least Once

To implement controller logic, we have to override two methods: `createOrUpdateResource` and `deleteResource`.
These methods are called if a resource is create/changed or marked for deletion. In most cases these methods will be
called just once, but in some rare cases can happen that are called more then once. In practice this means that the
These methods are called if a resource is created/changed or marked for deletion. In most cases these methods will be
called just once, but in some rare cases, it can happen that they are called more then once. In practice this means that the
implementation needs to be **idempotent**.

### Smart Scheduling
Expand All @@ -77,11 +77,11 @@ a customizable retry mechanism to deal with temporal errors.

When an operator is started we got events for every resource (of a type we listen to) already on the cluster. Even if the resource is not changed
(We use `kubectl get ... --watch` in the background). This can be a huge amount of resources depending on your use case.
So it could be a good case just have a status field on the resource which is checked, if there anything needs to be done.
So it could be a good case to just have a status field on the resource which is checked, if there is anything needed to be done.

### Deleting a Resource

During deletion process we use [Kubernetes finalizers](https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/#finalizers
"Kubernetes docs") finalizers. This is required, since it can happen that the operator is not running while the delete
of resource is executed (think `oc delete`). In this case we would not catch the delete event. So we automatically add a
finalizer first time we update the resource if its not there.
finalizer first time we update the resource if it's not there.