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
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
On 12/03/2015 03:13 PM, Chris Lumens wrote:
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.
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
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
On 12/04/2015 01:53 PM, Chris Lumens wrote:
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
anaconda-devel@lists.fedoraproject.org
-
Chris Lumens -
Pat Riehecky