Unable to look up a node based on mac address

I see two possible solutions to that problem:
a) we could add a "lookup" method to the API. The method would return a list of system IDs from a set of criteria (mac adress would be one of the possible criteria).
b) or, if we want to promote the mac address as an identifier, we could allow the mac to be used as an identifier when calling the API: e.g. the definition of the API url for a node handler would be: r'nodes/(?P<system_id_or_mac_address>[\w\-]+)/$'
Given the fact that the system id is auto-generated (and UUID-based) and that the mac address has a well defined format, there is no risk of conflict.

Can you explain why is this needed please? (so that I can set priority appropriately)

To clarify, why would someone "very likely would want to query by the mac address". What's the use case?

Thanks.

On Mon, Jul 23, 2012 at 11:50 AM, Julian Edwards
<email address hidden> wrote:
> To clarify, why would someone "very likely would want to query by the
> mac address". What's the use case?

If they are staring at a rack full of hardware, one of which has a
fault light lit, the only data they have at hand is the MAC address of
the ethernet card, which is (for servers) often printed on the card,
for exactly this reason.

-Rob

On Mon, 23 Jul 2012, Robert Collins wrote:

> On Mon, Jul 23, 2012 at 11:50 AM, Julian Edwards
> <email address hidden> wrote:
> > To clarify, why would someone "very likely would want to query by the
> > mac address". What's the use case?
>
> If they are staring at a rack full of hardware, one of which has a
> fault light lit, the only data they have at hand is the MAC address of
> the ethernet card, which is (for servers) often printed on the card,
> for exactly this reason.

Right, and if there is a database of information about systems, then it
contains MAC addresses.

The other thing is that if maas is not in charge of the dhcp and they're
doing static-dhcp, then they clearly *do* have a MAC address to system
database somewhere already.

basically, MAC is a unique id for a system that people already have and
use, and as Robert said, is often actually on a sticker on the hardware.
(ignore the known fact that there duplicate macs exist).

Great, thanks guys.

I've added a filter to the 'list' API method: /api/1.0/nodes/?op=list&mac_address=<MAC1>&mac_address=<MAC2>.