Add FPGA, GRUB, ONIE platform types

[mrevang]

Change Scope

• Adds a new hardware component type: FPGA. This type will compliment INTEGRATED_CIRCUIT, which is widely used to represent a switching ASIC.
• Adds two new software component types: BOOT_LOADER_ONIE and BOOT_LOADER_GRUB. Given the generic BOOT_LOADER type already exists, adding a boot-loader-subtype leaf was considered. Ultimately that approach was rejected since it requires an additional leaf, and boot loader types aren't expected to proliferate.
• This change is backwards compatible.

Platform Implementations

• Implementation A: https://opencomputeproject.github.io/onie/overview/
• Implementation B: https://www.gnu.org/software/grub/

[dplore]

/gcbrun

[OpenConfigBot]

No major YANG version changes in commit 7039d25

[dplore]

/gcbrun

[dplore]

With only one leaf for component/bootloader (type), it's redundant to /components/component/state/type. If we had bootloader specific leaves, then I would strongly favor adding /components/component/bootloader. The only other leaf I can think to add is also covered as generic component leaves (/components/component/state/firmware-version)

What if we add the additional/more specific bootloader identities as children of OPENCONFIG_SOFTWARE_COMPONENT ?
ie:

identity BOOT_LOADER_GRUB {
    base OPENCONFIG_SOFTWARE_COMPONENT;

I think this is slightly simpler as it maintains the existing, single, flat identity tree for OPENCONFIG_SOFTWARE_COMPONENT. (I acknowledge @mrevang originally suggested this)

If we expected a large number (10+ ?) of bootloaders then a new, nested bootloader identity seems better. But there just aren't that many bootloaders for network devices and they are not rapidly changing.

On the whole, I don't see any of these suggestions as wrong. But I would like to not spend too much energy on this issue as I think this is a low impact change. 😉

[earies]

With only one leaf for component/bootloader (type), it's redundant to /components/component/state/type. If we had bootloader specific leaves, then I would strongly favor adding /components/component/bootloader. The only other leaf I can think to add is also covered as generic component leaves (/components/component/state/firmware-version)

What if we add the additional/more specific bootloader identities as children of OPENCONFIG_SOFTWARE_COMPONENT ? ie:

identity BOOT_LOADER_GRUB {
    base OPENCONFIG_SOFTWARE_COMPONENT;

I think this is slightly simpler as it maintains the existing, single, flat identity tree for OPENCONFIG_SOFTWARE_COMPONENT. (I acknowledge @mrevang originally suggested this)

If we expected a large number (10+ ?) of bootloaders then a new, nested bootloader identity seems better. But there just aren't that many bootloaders for network devices and they are not rapidly changing.

On the whole, I don't see any of these suggestions as wrong. But I would like to not spend too much energy on this issue as I think this is a low impact change. 😉

uboot, syslinux, lilo.... all additionals so now we are getting into flavors - so far identities have been mostly generic so if we choose to take this approach vs. put the detail within distinct leafs under a new container such as bootloader we will get into the semantics of potentially overloading the generic BOOT_LOADER identity until trying to propose another identity into the model set.

To draw another correlation, we could have all sorts of "flavors" of controller cards or linecards but we would find another means (another leaf) to describe the flavor of the generic types of CONTROLLER_CARD or LINECARD

[mrevang]

With only one leaf for component/bootloader (type), it's redundant to /components/component/state/type. If we had bootloader specific leaves, then I would strongly favor adding /components/component/bootloader. The only other leaf I can think to add is also covered as generic component leaves (/components/component/state/firmware-version)
What if we add the additional/more specific bootloader identities as children of OPENCONFIG_SOFTWARE_COMPONENT ? ie:

identity BOOT_LOADER_GRUB {
    base OPENCONFIG_SOFTWARE_COMPONENT;

I think this is slightly simpler as it maintains the existing, single, flat identity tree for OPENCONFIG_SOFTWARE_COMPONENT. (I acknowledge @mrevang originally suggested this)
If we expected a large number (10+ ?) of bootloaders then a new, nested bootloader identity seems better. But there just aren't that many bootloaders for network devices and they are not rapidly changing.
On the whole, I don't see any of these suggestions as wrong. But I would like to not spend too much energy on this issue as I think this is a low impact change. 😉

uboot, syslinux, lilo.... all additionals so now we are getting into flavors - so far identities have been mostly generic so if we choose to take this approach vs. put the detail within distinct leafs under a new container such as bootloader we will get into the semantics of potentially overloading the generic BOOT_LOADER identity until trying to propose another identity into the model set.

To draw another correlation, we could have all sorts of "flavors" of controller cards or linecards but we would find another means (another leaf) to describe the flavor of the generic types of CONTROLLER_CARD or LINECARD

I've introduced /components/component/boot-loader/state/type, to keep the component/type leaf generic.

[dplore]

/gcbrun

[dplore]

/gcbrun

[dplore]

/gcbrun

[dplore]

/gcbrun

[dplore]

/gcbrun

[dplore]

/gcbrun

[dplore]

/gcbrun

[dplore]

/gcbrun