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

Switch to new compose library #63

Closed
k9withabone opened this issue Feb 19, 2024 · 6 comments · Fixed by #73
Closed

Switch to new compose library #63

k9withabone opened this issue Feb 19, 2024 · 6 comments · Fixed by #73
Labels
enhancement New feature or request
Milestone

Comments

@k9withabone
Copy link
Member

I'm currently developing a new Rust library which does a better job of conforming to the compose-spec. The library can be found at k9withabone/compose_spec_rs. For podlet, it will replace the docker-compose-types library currently used.

The new library will be completely documented, conform only to the compose-spec, fully parse and validate each part of compose files, and adhere to semantic versioning. That last part is especially important as I plan to turn all the conversion logic of podlet into a library so that it can be used to create a web version of podlet.

This issue is blocked until the compose_spec library is ready and published.

@k9withabone k9withabone added enhancement New feature or request blocked Waiting on something else to resolve labels Feb 19, 2024
@k9withabone k9withabone added this to the v0.3.0 milestone Feb 19, 2024
@k9withabone
Copy link
Member Author

An initial version of the library should be ready to be published once k9withabone/compose_spec_rs#1 is completed. Podlet can then switch to it as the other features (merging, interpolation, etc.) are not a requirement.

@k9withabone
Copy link
Member Author

compose_spec v0.1.0 has been published! Time to start working on the migration.

@k9withabone k9withabone removed the blocked Waiting on something else to resolve label Apr 6, 2024
@k9withabone
Copy link
Member Author

I'm a bit stuck on figuring out how a service Dependency (from the depends_on long syntax) should be converted to a systemd unit dependency. My thinking is currently this:

  • Only support the service_started condition, suggesting to use, in the dependency's definition, Notify=healthy under [Container] for service_healthy and Type=oneshort under [Service] for service_completed_successfully.
  • If restart is true require that required is also true and add the service to PartOf=. Otherwise, add the service to Requires= or Wants= depending on required.
  • Add the service to After=.

Is it correct to use PartOf= for restart or should something like ReloadPropagatedFrom= along with Requires= or Wants= be used instead? Also, maybe StopPropagatedFrom= should always be used for a dependency?

I'm not sure who the best person to ask about this is, but @cdrage, since you worked on kompose, what do you think about this?

@cdrage
Copy link

cdrage commented Apr 8, 2024

I'm a bit stuck on figuring out how a service Dependency (from the depends_on long syntax) should be converted to a systemd unit dependency. My thinking is currently this:

  • Only support the service_started condition, suggesting to use, in the dependency's definition, Notify=healthy under [Container] for service_healthy and Type=oneshort under [Service] for service_completed_successfully.
  • If restart is true require that required is also true and add the service to PartOf=. Otherwise, add the service to Requires= or Wants= depending on required.
  • Add the service to After=.

Is it correct to use PartOf= for restart or should something like ReloadPropagatedFrom= along with Requires= or Wants= be used instead? Also, maybe StopPropagatedFrom= should always be used for a dependency?

I'm not sure who the best person to ask about this is, but @cdrage, since you worked on kompose, what do you think about this?

To be honest, we never found an answer and did not incorporate it with Kompose :( See: https://kompose.io/conversion/

There's no equivalent for it within Kubernetes.

We instead just have to explain to others that your application should be built-in with retry methods / retrying if it cannot connect to something / timeout instead of having to implement depends_on in a hacky way.

@k9withabone
Copy link
Member Author

Since I haven't been able to find help for this I'm going to go with what I outlined above (using PartOf=) for now. It can always be changed later if someone has a better idea.

@k9withabone
Copy link
Member Author

Actually, looking at the systemd.unit docs again, it seems I actually want BindsTo= instead of PartOf=.

@k9withabone k9withabone linked a pull request Apr 24, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants