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.

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

feat(podman): support add podman envs in the wizard [r8s-20] #12056

Open
wants to merge 21 commits into
base: develop
Choose a base branch
from

Conversation

testA113
Copy link
Contributor

Fixes: r8s-20

@testA113 testA113 force-pushed the feat/r8s-17/r8s-20/add-podman-env-wizard branch from 0a82581 to 09fca56 Compare July 30, 2024 05:17
@testA113
Copy link
Contributor Author

I decided to go with a new container engine field instead of a new environment type.

The container engine field as of now can be 'docker' or 'podman'

I decided to go with this because of docker and podman both following the OCI interface. This means there are more cases where docker and podman environments are similar, than different.

Another option that I considered was to create new Endpoint.Type enums for podman environments. I decided to go against this because it would require unnecessary environment type checking project wide, to follow the same logic as docker environments

Copy link
Member

@deviantony deviantony left a comment

Choose a reason for hiding this comment

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

After discussing this with Ali, we've considered the following approaches:

  • A simple boolean to state whether the environment is based on the Podman runtime or not
  • A new enum type for the container runtime
  • A string based implementation that is supported by constants

We've decided to go with the 3rd option that gives enough flexibility for future enhancements without the rigidity and constraints of the first two options.

api/http/handler/endpoints/endpoint_create.go Show resolved Hide resolved
api/http/handler/endpoints/endpoint_create.go Outdated Show resolved Hide resolved
api/portainer.go Show resolved Hide resolved
Copy link
Member

@deviantony deviantony left a comment

Choose a reason for hiding this comment

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

Minor changes required otherwise LGTM

@testA113 testA113 force-pushed the feat/r8s-17/r8s-20/add-podman-env-wizard branch 2 times, most recently from ea8aff7 to c944813 Compare July 30, 2024 21:22
Copy link
Member

@deviantony deviantony left a comment

Choose a reason for hiding this comment

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

Backend LGTM

@@ -168,6 +172,8 @@ export enum EnvironmentCreationTypes {
KubeConfigEnvironment,
}

export type ContainerEngine = 'docker' | 'podman';
Copy link
Member

Choose a reason for hiding this comment

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

Use an enum that can be used for comparison in the app, like PlatformType

export enum ContainerEngine {
  Docker = 'docker',
  Podman = 'podman',
}

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I have a slight preference for unions for being able to use values directly, still getting typescript lint errors as guard rails, and not requiring importing. If you still want enum, I can update it though

app/portainer/filters/filters.js Outdated Show resolved Hide resolved
app/portainer/views/endpoints/edit/endpointController.js Outdated Show resolved Hide resolved
import azure from '@/assets/ico/vendor/azure.svg';
import docker from '@/assets/ico/vendor/docker.svg';

import { Icon } from '@@/Icon';

interface Props {
type: EnvironmentType;
containerEngine?: ContainerEngine;
Copy link
Member

Choose a reason for hiding this comment

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

Don't make it optional as it won't be (always defaults to docker in the backend).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It defaults to docker when creating a new environment, but there's no guarantee (yet) that existing environments have the container engine set.

I'll look into doing a migration that either sets all existing environments to 'docker' or a post init migration that checks the info from environments to determine 'podman' or 'docker' environments.

app/react/portainer/environments/ListView/columns/type.tsx Outdated Show resolved Hide resolved
@@ -207,7 +224,8 @@ async function createEnvironment(
};

if (options) {
const { groupId, tagIds = [] } = options.meta || {};
const { tls, azure, meta, containerEngine = 'docker' } = options;
Copy link
Member

Choose a reason for hiding this comment

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

If containerEngine is mandatory in the backend, don't make it optional in the frontend with a default value but enforce it along the entire call chain (in EnvironmentOptions and its callers)

If containerEngine is optional in the backend, don't use a default value.

This comment applies to all the containerEngine related parameters of this PR.

Copy link
Contributor Author

@testA113 testA113 Aug 1, 2024

Choose a reason for hiding this comment

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

Fair point!

I think that containerEngine should be optional, for the following reasons

  • we shouldn't set the containerEngine for kubernetes environments (it's specific for only docker or podman envs)
  • there are existing environments that won't be migrated to have a containerEngine field

I've removed the default 'docker' value

Comment on lines 55 to 61
const isPodmanEnabledQuery = useFeatureFlag('podman');
// for the stepper, assume isPodmanEnabled is enabled, until shown otherwise
const isPodmanEnabled =
isPodmanEnabledQuery.data === undefined ? true : isPodmanEnabledQuery.data;
const environmentTypes = getEnvironmentTypes(isPodmanEnabled);
Copy link
Member

Choose a reason for hiding this comment

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

In this case we should probably assume that the flag is disabled and not enabled by default. The purpose of a feature flag is to hide feature by default and only enable them on demand.

Also, use FeatureId.PODMAN or a custom hook (see above)

  const { data: isPodmanEnabled } = useFeatureFlag(FeatureId.PODMAN);
  const environmentTypes = getEnvironmentTypes(!!isPodmanEnabled);

OR

  const isPodmanEnabled = useIsPodmanEnabled();
  const environmentTypes = getEnvironmentTypes(isPodmanEnabled);

Copy link
Contributor Author

Choose a reason for hiding this comment

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

There's a weird exception where isPodmanEnabledQuery is still loading. I updated the comment and code to hopefully reflect this case better

@testA113 testA113 force-pushed the feat/r8s-17/r8s-20/add-podman-env-wizard branch 3 times, most recently from 2c7d8b9 to 85c3cc5 Compare August 4, 2024 23:37
@testA113 testA113 force-pushed the feat/r8s-17/r8s-20/add-podman-env-wizard branch from e8cfe74 to c10e1ce Compare September 16, 2024 03:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants