Preferred pattern for a Python/OCI app (Industrial-AIOps)? container-launcher recipe vs Managed Containers

[zw008]

Hi IGEL Community 👋 — I'd like to contribute a recipe and want to check the preferred pattern first, since my app doesn't fit the usual "native binary → /usr/bin" shape.

The app: Industrial-AIOps (iaiops, MIT, on PyPI + the MCP Registry) — a vendor-neutral, read-first OT diagnostics tool: a governed tap across ~14 field protocols (OPC-UA, Modbus, S7comm, EtherNet/IP, PROFINET-DCP, BACnet/IP, MTConnect, MQTT-Sparkplug, HART-IP, …) plus a cross-protocol root-cause "brain", all exposed as governed MCP tools (audit / budget / risk-tier / undo). It's a Python workload, shipped as a hardened OCI image (non-root, read-only rootfs, outbound-only, no inbound ports).

The fit question: the existing recipes (e.g. 7zip) download a native Linux binary and copy it into /usr/bin. iaiops isn't a single binary — it's a Python/container app. So I see two options:

1. A thin container-launcher recipe — install.json drops a small podman-based launcher into /usr/bin that runs the neutral iaiops OCI image (image pulled from a registry, e.g. ghcr.io). thirdparty.json would reference the image + MIT license.
2. Or is the community steering containerized workloads to IGEL OS 12 Managed Containers rather than recipes in this repo?

Questions:

• Are container-based / launcher recipes welcome here, or is this repo native-binaries only?
• If welcome, is a podman-launcher pattern acceptable — and is there a reference recipe already doing something similar I should model on?

Happy to open a working PR (with a published OCI image) once I know the preferred shape. Thanks for steering me right! 🙏

[rneher-igel]

Cool.

Let's put it here in https://github.com/IGEL-Community/IGEL-OS-APP-RECIPES/tree/main/APP_Source/Apps/iaiops

My Notes on Containers -- https://igel-community.github.io/IGEL-Docs-v02/Docs/HOWTO-Docker/

Samples to look at:

https://github.com/IGEL-Community/IGEL-OS-APP-RECIPES/tree/main/APP_Source/Apps/vmwarerc
https://github.com/IGEL-Community/IGEL-OS-APP-RECIPES/tree/main/APP_Source/Apps/sapgui

Plan to keep everything in /services/iaiops and /services_rw/iaiops and do not copy anything into filesystem. You can have a service that links into the filesystem as needed.

https://github.com/IGEL-Community/IGEL-OS-APP-RECIPES/tree/main#how-to-add-links-to-servicesapplication_name

[rneher-igel]

I'm on vacation and will be back in the office on 17 July.

[zw008]

Thanks @rneher-igel, appreciate the pointers! The recipe is up as #520, following your notes — it's a container-launcher (pulls the published, hardened OCI image via Podman), nothing copied into the rootfs, all app files + writable state under /services/iaiops and /services_rw/iaiops, with the systemd unit as the only link in. Modeled on vmwarerc / sapgui. No rush — I know you're back on the 17th, happy to iterate on the conventions.

One companion note, in case it's useful: iaiops runs on the endpoint (governed, read-first OT diagnostics). Its management-side sibling, endpoint-aiops, manages the endpoint fleet itself — it can be pointed at a UMS via a small config "dialect" (resource paths + field mapping), so the two together cover both layers: OT diagnostics on the device, and fleet management from UMS. That UMS side is still preview (IMI auth is on the to-do list). Both are vendor-neutral and open source — glad to share more if helpful. Enjoy the vacation!