RFC: create development dir - move [setup], [qm-settings-support] to development dir

[dougsland]

@alexlarsson is looking for have a single solution for deployment (at least for now) and move the setup and qm-settings-support to a development dir and remove both from rpm/qm.spec. If users/developers would like to use it, need to clone the repo and run manually.

Pros:

• Single solution for: deployment and configuring files, via sample-images project, it supports out of box regular and ostree images.

Possible Cons:

• single machines or laptops cannot use anymore the setup script shipped via RPM but can use similar containered approaches like the script auto-image-builder to run sample-images as container + QM OR manually git clone the qm repo and run the tools removed.
• qm-settings-storage will be moved to development dir (qm-settings-storage was a script called after ostree and regular installation was completed via sample-images or setup script to adjust storage config settings which could be expandable for others qm specific tasks without touching in the sample-images repo. i.e: 01-qm-storage-hook, 02-qm-network-hook, etc.). However, this will be converted to sample-images changes and hooks mechanism removed.
• How to deploy QM in cases don't need automotive bits embedded, let's imagine a Electronic drum kits that EACH pad could be a nested container independently. In such embedded case, will sample-images only cover the scenario? or could (sample-images/setup) address such case better?

Example:
sample-images could care of software be installed/loaded into the "brain device of the drum" but how to solve cases where users need baremetal integration too like: "plug the drums into the PC to play and simulate the drums via (usb/usb-c)?

Could be: As soon the user connect the USB cable into the PC, udev rules triggers QM/podman (or similar solution) to bring the nested containers apps for each pad independently into the user PC." (sorry for the analogy, probably there many others examples out there but I am a drummer enthusiast). :)

• Ensure our CI/CD pipelines don't trust in the qm setup script in github actions
• Revisit in the future this issue in case we need to bring setup or hooks back to QM to support such scenario.

Question raised now:
What's the point of keeping the packaged in Fedora/CentOS if all setup/settings will be executed in sample-images project only and the setup facilitator removed? Maybe QM should be a sub-project of sample-images only in this case? Keep the RPMs in CentOS Automotive repo for sample-images get during install still make sense but Fedora, EL9?

[dougsland]

cc @Yarboa @rhatdan @pbrilla-rh @ericcurtin

[Yarboa]

Thanks @dougsland AFAIU, those setup scripts, are only for regular images like, running on your desktop of vm So, I suggest to update docs with this explanation, The rpm scope is for AutoSD tools for building images

[ericcurtin]

QM is not really a desktop tool, @alexlarsson is right, write it in a osbuild format so it's preconfigured on OSTree and non-OSTree images.

Sometimes we write scripts to be run interactively because it's useful for demos.

QM was written for Automotive, I wouldn't worry too much about use-cases outside AutoSD right now.

[rhatdan]

I am fine with this change. The script should not be installed in the final system.

[pypingou]

On Thu, May 09, 2024 at 02:47:41AM -0700, Eric Curtin wrote:

QM is not really a desktop tool, @.*** is right, write it in a osbuild format so it's preconfigured on OSTree and non-OSTree images.

Sometimes we write scripts to be run interactively because it's useful for demos.

QM was written for Automotive, I wouldn't worry too much about use-cases outside AutoSD right now.

+1 for me with everything Eric said :)

[dougsland]

On Thu, May 09, 2024 at 02:47:41AM -0700, Eric Curtin wrote: QM is not really a desktop tool, @.*** is right, write it in a osbuild format so it's preconfigured on OSTree and non-OSTree images. Sometimes we write scripts to be run interactively because it's useful for demos. QM was written for Automotive, I wouldn't worry too much about use-cases outside AutoSD right now. +1 for me with everything Eric said :)

Thanks everyone, going to prepare a patch and add it to a fresh release soon.

[alexlarsson]

I think qm could support other installation methods, like someone could have their own way to install an image that is not sample-images, and then install qm in that image. However, I don't think we should spend serious engineering manpower on supporting that. The main target for qm is the automotive usecase and sample-images, so lets focus on that.

That said, for development, the setup script is nice, so we still want to keep it around in git.

[Yarboa]

One question not answered here.

Question raised now:
What's the point of keeping the packaged in Fedora/CentOS if all setup/settings will be executed in sample-images project only and the setup facilitator removed? Maybe QM should be a sub-project of sample-images only in this case? Keep the RPMs in CentOS Automotive repo for sample-images get during install still make sense but Fedora, EL9?

So based on the above, there is an answer for the quote,

It is good to maintain setup script for non automotive deployments. It also assist with the health of qm github testing.

@ericcurtin @alexlarsson @pypingou Another question, not answered, Is there a way we could avoid, the code duplication of environments build?

[ericcurtin]

One question not answered here.

Question raised now:
What's the point of keeping the packaged in Fedora/CentOS if all setup/settings will be executed in sample-images project only and the setup facilitator removed? Maybe QM should be a sub-project of sample-images only in this case? Keep the RPMs in CentOS Automotive repo for sample-images get during install still make sense but Fedora, EL9?

No strong opinions.

So based on the above, there is an answer for the quote,

It is good to maintain setup script for non automotive deployments. It also assist with the health of qm github testing.

Yeah sure, the interactive script doesn't have to be purged from existence or anything if it's helpful.

Keep in mind though the one built by osbuild is the one most accurate to the real-life use case and there's no reason we can't run osbuild in GitHub CI in fact I tested this only a few days ago.

@ericcurtin @alexlarsson @pypingou Another question, not answered, Is there a way we could avoid, the code duplication of environments build?

Again, yes sure, feel free to de-duplicate but of course there's a balance between de-duplication and making things overly complex. osbuild manifests are just python scripts so they can run/call almost anything, but we have to be careful of putting square pegs in round holes also.