Skip to content
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

Document Podman limitations #6653

Merged
merged 4 commits into from
Mar 21, 2023
Merged

Document Podman limitations #6653

Changes from 2 commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
a4de0d8
Document Podman limitations
feloy Mar 10, 2023
3b322b9
More limitations + Tomas review
feloy Mar 10, 2023
8ee1d42
Review
feloy Mar 10, 2023
c49150d
review
feloy Mar 20, 2023
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
61 changes: 61 additions & 0 deletions docs/website/docs/development/architecture/podman-support-limitations.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,61 @@
---
title: Podman Support limitations
sidebar_position: 40
---

The `odo dev` command is able to work either on Podman or on a Kubernetes cluster.

The motivation behind the support for the Podman platform is to lower the learning curve
for developers working on containerized applications, and to limit the physical resources
necessary for development.

As a matter of fact, Podman is simpler to apprehend, install and maintain than a Kubernetes cluster, and can run with a minimal overhead on the developer machine.

Thanks to the support for the **Kubernetes Pod** abstraction by Podman, `odo`, and
the user, can work on both Podman and Kubernetes on top of this abstraction.

Here are a list of limitations when `odo` is working on Podman:
rm3l marked this conversation as resolved.
Show resolved Hide resolved

## Commands working on Podman

- `odo dev --platform podman`

This command will run the component in development mode on Podman. If you omit to use the `--platform` flag, `odo dev` works on cluster.

- `odo logs --platform podman`

This command will display the component's logs from Podman. If you omit to use the `--platform` flag, `odo logs` get the logs from cluster.

- `odo list component [--platform podman]`

This command without the `--platform` flag will list components from both the cluster and Podman. You can use the `--platform` flag to limit the search from a specific platform, either `cluster` or `podman`.

- `odo describe component [--platform podman]`

This command without the `--platform` flag will describe a component from both the cluster and Podman. You can use the `--platform` flag to limit the search from a specific platform, either `cluster` or `podman`.

- `odo delete component [--platform podman]`

This command without the `--platform` flag will delete components from both the cluster and Podman. You can use the `--platform` flag to limit the deletion from a specific platform, either `cluster` or `podman`.


Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe you can add a section here instead of directly starting with the limitations. Or convert the section "Commands working with Podman" to a normal list.

## Apply command are not supported
rm3l marked this conversation as resolved.
Show resolved Hide resolved

A Devfile `Apply` command gives the possibility to "apply" any Kubernetes resource to the cluster. As Podman only supports a limited number of Kubernetes resources, `Apply` commands are not executed by `odo` when running on Podman.

## Component listening on localhost not forwarded

When working on a cluster, `odo dev` forwards the ports opened by the application to the developer's machine. This port forwarding works when the application is listening either on localhost or on `0.0.0.0` address.
rm3l marked this conversation as resolved.
Show resolved Hide resolved

Podman is natively not able to forward ports bound to localhost. In this situation, you may have two solutions:
rm3l marked this conversation as resolved.
Show resolved Hide resolved
- you can change your application to listen on `0.0.0.0`. This will be necessary for the ports giving access to the application or, in Production, this port would not be available (this port will most probably be exposed through an Ingress or a Route in Production, and these methods need the port to be bound to `0.0.0.0`),
- you can keep the port bound to `localhost`. This is the best choice for the Debug port, to restrict access to this Debug port. In this case, you can use the flag `--forward-localhost` when running `odo dev` on Podman. This way, you keep the Debug port secure on cluster.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This part is not very clear to me.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I might have been biased when I read this as I worked on --forward-localhost, but just curious: what did you find not very clear?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will be necessary for the ports giving access to the application or

This. Does it mean that this will be necessary to allow application access on the certain ports?

This is the best choice for the Debug port, to restrict access to this Debug port.

What does it mean to restrict access to this debug port?

Copy link
Member

@rm3l rm3l Mar 20, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will be necessary for the ports giving access to the application or

This. Does it mean that this will be necessary to allow application access on the certain ports?

It is more about reaching the port opened by the application from the outside. If you want the port to be reachable from outside of the container/pod, the application needs to bind the port to 0.0.0.0 (or more specifically to an interface that is connected to an outside network).

This is the best choice for the Debug port, to restrict access to this Debug port.

What does it mean to restrict access to this debug port?

Same point, about not making this port accessible from outside of the container/pod. It is generally recommended to restrict access to this Debug port by not exposing it. So here we are saying that --forward-localhost allows users to reach such ports on Podman while still keeping them unreachable on the cluster.


## Pod not updated when Devfile changes

When running `odo dev` on cluster, if you make changes to the Devfile affecting the definition of the deployed Pod (for example the memory or CPU requests or limits), the Pod will be recreated with its new definition. This behaviour is not supported yet for Podman.

## Pre-Stop events not supported

Pre-Stop events defined in the Devfile are not triggered when running `odo dev` on Podman.