On Mon, Apr 07, 2008 at 12:13:46PM -0400, Michael DeHaan wrote: > Ideally one wouldn't be assigning specific packages to specific systems, > as the point of a profile is to make a configuration available to all > things that look "like" something. Can you explain your use case for > assigning specific packages to specific systems? I can: I have two 'workstations' that run on power from a single UPS. Only one of them, however, is actually connected to the UPS' communications port - the other one talks via TCP/IP to the first to determine UPS status. All workstations have nut-client installed, but only the workstation connected to the UPS' communications port has nut installed. Granted, I could probably have a 'with-ups' profile based on the standard workstation profile, but it hardly seems worth it to me. :-) Actually, relevant question: If I have a 'workstation-with-ups' profile based on a 'workstation' profile, and add packages to the 'workstation' profile, will the packages also be automatically added to the 'workstation-with-ups' profile? (Note: I have not (yet) set up either of the aforementioned workstations with Cobbler, but they do exist and they are on a UPS via nut - it's just a valid use-case that I think bears inclusion.) On Mon, Apr 07, 2008 at 10:56:43AM -0700, Sandor W. Sklar wrote: > I'm sure there are holes in that logic (one is, I actually consider the > "disk partitioning" a separate section, but it "officially" is just a > part of the "command" section. Doubtless there are other holes that > I'm not seeing right now. The original logic seems to me that you get to choose only one snippet (system, profile, or default), but how about additive? (Perhaps a better term is inheritance...) For example, with my little workstations-on-a-UPS example, the workstation that is on the UPS will need the nut package added, but will otherwise be identical to any other workstation (I would want the UPS-connected workstation to inherit the same package list and configuration as the other workstations). Regards, Msquared... _______________________________________________ et-mgmt-tools mailing list et-mgmt-tools@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/et-mgmt-tools
