should be able to set default arch for unknown hardware

Can you give a concrete reason for wanting this behaviour? I see a lot of "should" and "I'd like" but no actual use case :)

We believe that MAAS will be able to identify all hardware types properly by the time we have finished the next round of hardware enablement infrastructure so it would make this moot.

Additionally, I'd like it to be considered a bug where MAAS cannot determine the hardware type before first boot. Where it really isn't possible to detect ahead of time, we should demand the manual selection of an arch (well, driver, which covers more than just arch) before we accept a machine into MAAS.

"We believe that MAAS will be able to identify all hardware types properly by the time we have finished the next round of hardware enablement infrastructure so it would make this moot."

I'm willing to make a considerable wager that you're wrong.

There will never be a case when maas is able to correctly enumerate all hardware systems prior to their existence. That is simply unrealistic, and would require that *all* hardware manufactures hold hardware release until Canonical says "it looks good".

I'm just requesting a simple setting, that already exists.
Right now, if maas gets a pxe boot request for a MAC address it doesn't know, it sends i386/generic.
I'm just saying you should let me configure it to send $ARCH/$SUBARCH.

On Wednesday 19 Feb 2014 18:09:33 you wrote:
> "We believe that MAAS will be able to identify all hardware types
> properly by the time we have finished the next round of hardware
> enablement infrastructure so it would make this moot."
>
> I'm willing to make a considerable wager that you're wrong.
>
> There will never be a case when maas is able to correctly enumerate all
> hardware systems prior to their existence. That is simply unrealistic,
> and would require that *all* hardware manufactures hold hardware release
> until Canonical says "it looks good".

Obviously I mean "where you have a hardware driver" in place. Enumerating all
hardware is patently silly :)

> I'm just requesting a simple setting, that already exists.
> Right now, if maas gets a pxe boot request for a MAC address it doesn't
> know, it sends i386/generic. I'm just saying you should let me configure it
> to send $ARCH/$SUBARCH.

We'll come back to this when the driver work is done after our sprint in
March.

As far as I can tell, this is also a problem with subarch.
For enlisting or commissionging systems, I may very well need to use amd64/hwe-v but maas will boot amd64/hwe-t (latest lts with GA kernel).

Please bump this higher than wishlist. We believe this is what is blocking the Power8 certs with PXE issues.

Because we are unable to default to HWE-U or later for the Power8 systems, PXE booting new P8 hardware is dodgy at best, sometimes it works, most times it seems to kernel panic when trying to enlist.

To work around this, we have replaced the default Power8 boot files with HWE-U boot files. We should be able to, at the least, be able to set the default kernel series for unknown hardware.

So while I don't think the initial problem is actually an issue here, the P8s do seem to be trying to boot, Scott's comment #5 does seem to apply to certification.

as Mike points out, it actually makes a lot of sense to also have MAAS just default to the latest HWE kernel for enlistment and commissioning.

MAAS should be, IMO, smart enough to see that Trusty has a HWE-U kernel and boot media and start using that for enlistment and commissioning to ensure that newly discovered systems are enlisted and commissioned properly (all their hardware is addressed by the right drivers and probed successfully).

Setting a default kernel as noted in previous comments is also a helpful thing to have, but really, MAAS should be defaulting to whatever is the most recent kernel it has for a given release.p

MAAS 1.9 will have the ability of selecting the HWE kernel to be used for enlistment/commissioning, but it won't have the ability to select the architecture. This should solve the problems being experienced, and as such, I'm marking this as a wishlist for1.9, although this won't be fixed.