Looking at the payload from an addon

[Pat Riehecky]

I'm working on an addon where I'd like to do a bit more introspection on
the payload within the addon itself.

So I started working on the kickstart aspect and ran into a bit of
confusion.

For what I'm doing I need to act a bit differently if the payload is yum
vs dnf vs ostree. However, I don't see a way for me to look at the
payload object from within the kickstart functions.

Did I miss where I can get to it? Any suggestions?

Pat

[Chris Lumens]

I'm working on an addon where I'd like to do a bit more introspection on the
payload within the addon itself.
So I started working on the kickstart aspect and ran into a bit of
confusion.
For what I'm doing I need to act a bit differently if the payload is yum vs
dnf vs ostree. However, I don't see a way for me to look at the payload
object from within the kickstart functions.
Did I miss where I can get to it? Any suggestions?

Can you post the code you've got so far somewhere? Also, what release
is this?

From brief looking around, I don't see a great way of getting at payload

from without a subclass of AddonData. To me, that seems like an
oversight that we could take care of. We are passing around storage,
ksdata, and instClass after all.

- Chris

[Pat Riehecky]

Post by Chris Lumens

I'm working on an addon where I'd like to do a bit more introspection on the
payload within the addon itself.
So I started working on the kickstart aspect and ran into a bit of
confusion.
For what I'm doing I need to act a bit differently if the payload is yum vs
dnf vs ostree. However, I don't see a way for me to look at the payload
object from within the kickstart functions.
Did I miss where I can get to it? Any suggestions?

Can you post the code you've got so far somewhere? Also, what release
is this?

My release is EL7.2, anaconda-21.48.22.56-1

As for code, I'm a bit light on worthwhile bits.... I can share what
I've got, but mostly it is just a hacked up version of
org_fedora_hello_world with me logging the content random things.

From the comments in pyanaconda/addons.py ( line 117 and following )
I'm looking at my options from within the addon's setup function. It
seems the most direct place as the install isn't started.

Post by Chris Lumens

From brief looking around, I don't see a great way of getting at payload

from without a subclass of AddonData. To me, that seems like an
oversight that we could take care of. We are passing around storage,
ksdata, and instClass after all.

Ultimately, I'm trying to get access to whatever implements
pyanaconda.packaging.Payload in the installing system. From my reading
of pyanaconda.install ( around line 260 ) it doesn't look like payload
is exposed to the addons.

I'm not overly familiar with the code base or data model, but as you
said it does feel like a bit of an oversight. With that in mind, fixes
without breaking things may be an issue as the setup function args would
have to change or gain an additional property.......

Pat

[Chris Lumens]

Post by Pat Riehecky
Ultimately, I'm trying to get access to whatever implements
pyanaconda.packaging.Payload in the installing system. From my reading of
pyanaconda.install ( around line 260 ) it doesn't look like payload is
exposed to the addons.
I'm not overly familiar with the code base or data model, but as you said it
does feel like a bit of an oversight. With that in mind, fixes without
breaking things may be an issue as the setup function args would have to
change or gain an additional property.......

Yeah, I think you are out of luck with how the code is currently set up.
I don't see that the payload is passed to the addon at any point, nor
does it appear to be an attribute on any of the things that are passed
to the addon. I think you should file a bug about this. It will
require adding arguments, but we can do that with *args, **kwargs to not
break things.

Anyway, you might be able to figure out what payload is in use by
examining the system. For example if there's a /tmp/anaconda-yum.conf,
we are probably using the yum payload. If there are an awful lot of
bind mounts present with very hash-looking names, it's probably the
ostree payload. I think if you look around in the payload classes,
you'll be able to find identifying marks to look for.

You might also be able to look at the log files - we might log what
payload class is being instantiated.

It's going to take some trial and error, but I think it's the best you
can do for now until we get the bug fixed (which would be at least 7.3
at this point, ugh).

- Chris

[Pat Riehecky]

Post by Chris Lumens

Post by Pat Riehecky
Ultimately, I'm trying to get access to whatever implements
pyanaconda.packaging.Payload in the installing system. From my reading of
pyanaconda.install ( around line 260 ) it doesn't look like payload is
exposed to the addons.
I'm not overly familiar with the code base or data model, but as you said it
does feel like a bit of an oversight. With that in mind, fixes without
breaking things may be an issue as the setup function args would have to
change or gain an additional property.......

Yeah, I think you are out of luck with how the code is currently set up.
I don't see that the payload is passed to the addon at any point, nor
does it appear to be an attribute on any of the things that are passed
to the addon. I think you should file a bug about this. It will
require adding arguments, but we can do that with *args, **kwargs to not
break things.
Anyway, you might be able to figure out what payload is in use by
examining the system. For example if there's a /tmp/anaconda-yum.conf,
we are probably using the yum payload. If there are an awful lot of
bind mounts present with very hash-looking names, it's probably the
ostree payload. I think if you look around in the payload classes,
you'll be able to find identifying marks to look for.
You might also be able to look at the log files - we might log what
payload class is being instantiated.
It's going to take some trial and error, but I think it's the best you
can do for now until we get the bug fixed (which would be at least 7.3
at this point, ugh).
- Chris

For list archival purposes: I've opened
https://bugzilla.redhat.com/show_bug.cgi?id=1288636