feature request: support custom content inside upgrade initramfs

[verdverm]

feature request: support custom content inside upgrade initramfs

[pirat89]

hi, thanks for sharing. well, it's a little bit mystery what is exactly the content of /custom-overlay in this context. Can you describe better how it helped you to resolve the problem?. Adding something like that would require also some documentation (like what to put inside, etc.) and if it should resolve somehow upgrades with LUKS, it would require also some detection that the directory contains expected data I would guess. adding just this, saying "you can set this envar to handle LUKS" is not something what would be helpful to people. I honestly do not know whether it's special terminology around LUKS when speaking about /custom-overlay. I hear about such a dir for the first time, so I expect that you did something more to make it useful for you.

however, adding additional custom files/dirs inside the initramfs is one of things that people can actually do without the need to modify our code, using custom actors. People can just create their custom actor to customize the initramfs content producing UpgradeInitramfsTasks and TargetUserSpaceUpgradeTasks messages (see definitions of these classes in models dir; I tried to describe them in details). The custom actor could look like this (I haven't tried the code, it's possible I did some mistakes when I wrote it now):

from leapp.actors import Actor
from leapp.models import (
    CopyFile,
    TargetUserSpaceUpgradeTasks,
    UpgradeInitramfsTasks
)
from leapp.tags import FactsPhaseTag, IPUWorkflowTag

class CustomizeUpgradeInitramfs(Actor):
    name = 'customize_upgrade_initramfs'
    consumes = ()
    produces = (TargetUserSpaceUpgradeTasks, UpgradeInitramfsTasks)
    tags = (IPUWorkflowTag, FactsPhaseTag)

    def process(self):
        # ... any other code to conditionalize produce of msgs below ... then
        self.produce(TargetUserSpaceUpgradeTasks(copy_files=[CopyFile(src="/root/overlay", dst="/custom-overlay")]))
        self.produce(UpgradeInitramfsTasks(include_files=['/custom-overlay'']))

OTOH, we expect to create/document templates for custom actors in future. Do you consider such type of template to be helpful? For now, this seems to me like an example we could use for the template. We hope to have restructuralized documentation during summer.

When you are trying to do some customisations, I suggest you to check defined models that contain Task / Tasks substring:

grep -r "Model" models | grep Task

these models are specially created to simplify or make possibly various actions (and customisations) during the upgrade.

[pirat89]

@verdverm ah, now I read your comment in #1239 (reply in thread) which is explaining little bit more how the directory helped you. Regarding that, I guess that would be helpful to have something like UpgradeKernelCmdlineArgTasks - analogy to TargetKernelCmdlineArgTasks.

[verdverm]

for some context, we are modifying the leapp files after installing the leapp packages

• we don't know what/how to modify to get things working, so this is an easy and fast iteration cycle
• applying a few patches is much lower effort than figuring out how to develop / package / install custom actors right now

The idea for the overlay is that a user can specify an arbitrary directory to overlay. It provides flexibility to the situation and doesn't require developing and shipping a custom actor. The ENV var would be super simple from our pov

[verdverm]

If there is a way / tutorial on how to drop some files into an existing leapp install that would effectively do the same thing, that would be helpful and ideally better align with how to modify leapp appropriately

[pirat89]

Thanks for the feedback. Well I see here two things we can do:

• provide documentation how to customize this using custom actors
• once the frameworks supports configurations for actors, make it possible to configure to configure this by a configuration file so no code is needed at all

I expect we can put it into the documentation this summer. We expect to implement support for configuration files in framework during this summer also, so I expect this case could be potentially covered till Feb.

I am not in favor of another envar so much honestl, as I have the feel that number of envars possible to use in this project is becoming large and the usability would be limitted. So I prefer to stay just with options I mentioned.

@abadger headsup ^ candidate for configuration
@matejmatuska headsup ^ candidate for template

[verdverm]

A configuration file would be even better!

I'd be happy to check out the template concept if you have some early docs / examples.

I sort of have a thing for templates, generally speaking... https://github.com/hofstadter-io/hof :]