Project

General

Profile

Actions

Feature #177

closed

Add an Operatingsystem Family concept

Added by Paul Kelly about 14 years ago. Updated about 14 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
Difficulty:
Triaged:
Fixed in Releases:
Found in Releases:

Description

The logic that describes some of the features of Debian and Ubuntu should be factored out. The Debian family of OS'es should inherit behaviour from a OS family superclass. The same is true of Fedora, RedHat and Centos.


Related issues 3 (0 open3 closed)

Blocks Foreman - Feature #24: Generate via templating systeme pxelinux.cfg entryClosedOhad Levy09/19/2009Actions
Blocks Foreman - Feature #13: improve debian integerationClosedPaul KellyActions
Blocks Foreman - Feature #178: Automate populating the TFTP directoryClosedPaul Kelly03/14/2010Actions
Actions #1

Updated by Paul Kelly about 14 years ago

  • Status changed from New to Ready For Testing

This has been implemented as a module that is extended into the OS object after initialization.

The code is based on edge and collapsed and on branch family at my github.

Actions #2

Updated by Ohad Levy about 14 years ago

  • Target version set to 0.1-5
Actions #3

Updated by Paul Kelly about 14 years ago

  • Branch set to feature/177

I have rebuilt this against develop and added some extras like pagination and searching and no AS
This needs refactor/193 before applying family concept to the host controller
Look on branch feature/177

Actions #4

Updated by Paul Kelly about 14 years ago

It is not clear in my mind what it is that the family concept is used for so these are my thoughts
A family encapsulates the concept of groups of related OSes such as Debian and Ubunto and Centos and RedHat

This allows puppetclasses, which are currently associated with Operating systems to refer to a family.

Wrong. These are ratified on arch/os combination via the mux code

This allows operatingsystems to be associated with a family.

True. It is then not possible to write os.architectures, even using through:, unless the family is converted to an ActiveRecord.

This allows medias, which are currently associated with OSes to refer to a family. (You were right about the paths for fedora being the same structure.)

Examine these four paths

This allows architectures, which are currently associated with OSes, to refer to a family.

Wrong. The binding between an operating system and an architecture is used to enable or disable the selection of a puppetclass in the GUI. (Though this code has not been committed.)

This allows partition tables, which are currently associated with OSes, to refer to a family.

Wrong. The partition tables for a sol 8 and sol 10 host are very different. It may be possible to ask the family for a template into which it is possible to insert sizing information but this does not seem worth while to me.

It looks like the family concept is useful for dealing with the parsing of media paths and is handling the construction of the {kick,jump,etc}start files. In the current implementation the family only provides behavioral changes, if something is set per-family and needs to be tracked then the family needs to be converted to an ActiveRecord Table.

Maybe you could add your thoughts on this

Actions #5

Updated by Paul Kelly about 14 years ago

There is a new branch on my github that implements just the os/family changes in the os settings page(no AS) + the mods to the operating system model to inherit from the lib/family.rb modules. The kickstart mediapath is a virtual method.

Actions #6

Updated by Paul Kelly about 14 years ago

  • % Done changed from 0 to 100
Actions #7

Updated by Ohad Levy about 14 years ago

  • Status changed from Ready For Testing to Closed
Actions

Also available in: Atom PDF