Bug 1392919 - [RFE] api/v2/discovered_hosts/facts does not return mac address
Summary: [RFE] api/v2/discovered_hosts/facts does not return mac address
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Discovery Plugin
Version: Unspecified
Hardware: x86_64
OS: Linux
unspecified
medium vote
Target Milestone: Unspecified
Assignee: Lukas Zapletal
QA Contact: Katello QA List
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-11-08 13:35 UTC by Djebran Lezzoum
Modified: 2017-04-11 13:04 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-04-11 13:04:50 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Djebran Lezzoum 2016-11-08 13:35:40 UTC
Description of problem:
 api/v2/discovered_hosts/facts does not return mac address

Version-Release number of selected component (if applicable):
6.2.z - 6.3 

How reproducible:
Always

Steps to Reproduce:
1. call /api/v2/discovered_hosts/facts providing all required parameters
2.
3.

Actual results:
the actual results does not contain mac address

Expected results:
mac address should be returned along side with other values

Additional info:

Comment 1 Lukas Zapletal 2017-03-06 13:50:40 UTC
Djebran,

I don't understand, can you specify what output you get and what exactly is missing? On my system, I can reach the endpoint and see all facts:

$ curl-foreman api/v2/discovered_hosts/41
{
    "facts_hash": {
        "discovery_version": "3.0.2",
        "interfaces": "fake1,fake2,fake3",
        "macaddress_fake1": "52:54:00:97:a0:25",
        "macaddress_fake2": "52:54:00:92:87:06",
        "macaddress_fake3": "52:54:00:16:04:29",
        "ipaddress_fake1": "10.228.235.145",
        "ipaddress_fake2": "192.168.122.239",
        "ipaddress_fake3": "10.180.132.199",
        "macaddress": "52:54:00:16:04:29",
        "ipaddress": "10.180.132.199",
        "discovery_bootif": "52:54:00:92:87:06",
        "ipmi_enabled": "true",
        "ipmi_1_gateway": "10.1.1.1",
        "ipmi_1_ipaddress": "10.60.184.232",
        "ipmi_1_ipaddress_source": "DHCP Address",
        "ipmi_1_macaddress": "52:54:00:53:dc:4c",
        "ipmi_1_subnet_mask": "255.0.0.0",
        "ipmi_gateway": "10.1.1.1",
        "ipmi_ipaddress": "10.60.184.232",
        "ipmi_ipaddress_source": "DHCP Address",
        "ipmi_macaddress": "52:54:00:53:dc:4c",
        "ipmi_subnet_mask": "255.0.0.0",
        "physicalprocessorcount": "3",
        "memorysize_mb": "900",
        "blockdevice.sda_size": "1234567890",
        "blockdevice.sdb_size": "123456700",
        "Xforeman_organization": "TestOrg1",
        "Xforeman_location": "Olomouc",
        "discovery_test_a": "A",
        "discovery_test_b": "B",
        "hardwaremodel": "Fake Host FH420"
    },
    "ip": "192.168.122.239",
    "mac": "52:54:00:92:87:06",
    "last_report": "2017-03-03 15:53:45 UTC",
    "subnet_id": null,
    "subnet_name": null,
    "hardware_model_name": null,
    "memory": 900,
    "disk_count": 2,
    "disks_size": 1296,
    "cpus": 3,
    "organization_id": 1,
    "organization_name": "MyOrg",
    "location_id": 2,
    "location_name": "MyLoc",
    "name": "mac525400928706",
    "id": 41
}

Comment 3 Lukas Zapletal 2017-04-11 13:04:50 UTC
Hey, you are making POST instead GET request. This is correct behavior. Please reopen if you think this is a bug.


Note You need to log in before you can comment on or make changes to this bug.