Skip to content

Add support for Ironic baremetal API #1429

Description

@stbenjam

There is currently no support for Ironic baremetal API in gophercloud. I'm working on it, and will have a PR open shortly for Nodes to get some early feedback, and will then continue on to the rest of the resources.

Categorized by the groupings under https://developer.openstack.org/api-ref/baremetal/

API

Clients

Nodes

Basic CRUD

Node Management

Node Vendor Passthru

  • Node Vendor Passthru: List
  • Node Vendor Passthru: Call

Node Traits

Virtual Interfaces

Portgroups

Ports

Volumes

Volume Connector

  • Volume Connectors: List
  • Volume Connectors: Get
  • Volumes Connectors: Create
  • Volumes Connectors: Update
  • Volumes Connectors: Delete

Volume Targets

  • Volume Connectors: List
  • Volume Connectors: Get
  • Volumes Connectors: Create
  • Volumes Connectors: Update
  • Volumes Connectors: Delete

Drivers

Drivers vendor passthru

  • Drivers vendor passthru: List
  • Drivers vendor passthru: Call

Conductors

Allocation

Allocation: Node

  • Node Allocation: Get
  • Node Allocation: Delete

Chassis

  • Chassis: List
  • Chassis: Get
  • Chassis: Update
  • Chassis: Delete
  • Chassis: Create

Activity

  1. juliakreger commented on Feb 15, 2019

    @juliakreger

    One minor note: The chassis functionality in the OpenStack Baremetal API is essentially unused and could likely be disregarded.

  2. joy717 commented on Feb 25, 2019

    @joy717

    Good job!! I love u guys. haha.
    Thanks!

  3. dtantsur commented on Feb 25, 2019

    @dtantsur
    Contributor

    Would be nice to throw the newly introduced Conductors and Allocations on the list. On the other hand, as Julia mentioned, Chassis are pretty useless.

  4. stbenjam commented on Feb 26, 2019

    @stbenjam
    ContributorAuthor

    Thanks @dtantsur, updated the list to include those. Is Chassis worth including at all for anyone or should I just remove it entirely from the list?

  5. dtantsur commented on Feb 28, 2019

    @dtantsur
    Contributor

    I would make it absolutely lowest priority. Literally the last thing to get done (and only for completeness).

  6. jtopjian commented on Mar 12, 2019

    @jtopjian
    Contributor

    @stbenjam One thing I just noticed is that Ports created_at and updated_at are set to string. They should be time.Time:

    https://github.com/gophercloud/gophercloud/blob/master/openstack/baremetal/v1/ports/results.go#L61-L66

    If you run into JSON decoding issues with the time, then you'll need to implement a custom UnmarshalJSON method. This is quite common because the suite of OpenStack projects use so many different time formats. For example:

    results.go already has a wide array of time formats. It's doubtful you'll need to define a new one.

    Let me know if you need any help with this.

  7. stbenjam commented on Mar 13, 2019

    @stbenjam
    ContributorAuthor

    @iurygregory ^ FYI, if you have time to look

  8. iurygregory commented on Mar 13, 2019

    @iurygregory
    Contributor

    @stbenjam going to look

  9. iurygregory commented on Mar 13, 2019

    @iurygregory
    Contributor

    @jtopjian according to the Ironic API docs they we handle as string see https://developer.openstack.org/api-ref/baremetal/?expanded=#ports-ports (Create Port Response, List Detailed Ports Response, Show Port Details Response, Update a Port Response)

    created_at | body | string | The UTC date and time when the resource was created, ISO 8601 format.
    updated_at | body | string | The UTC date and time when the resource was updated, ISO 8601 format. May be “null”.

    So its still necessary to change?

  10. stbenjam commented on Mar 13, 2019

    @stbenjam
    ContributorAuthor

    I think so. You’ll still interact with the API using strings but it should be marshalled/unmarshalled as a native time type in go.

  11. jtopjian commented on Mar 13, 2019

    @jtopjian
    Contributor

    @stbenjam is correct. API references and JSON samples will always have dates as strings because JSON doesn't have a native "date" type. Converting them to a real date-type in Go will allow code to use date-specific methods/actions.

    There are lots examples throughout Gophercloud on how to handle this (just search for UnmarshalJSON), but please let me know if you need help - I don't mean for this to cause a large amount of time.

  12. EmilienM commented on Dec 15, 2021

    @EmilienM
    Contributor

    @iurygregory would you be able to check the TODO items in the bug description and see what's actually left to do (and maybe prioritize it?).

    Thanks

  13. juliakreger commented on Dec 15, 2021

    @juliakreger

    @EmilienM @iurygregory is on PTO this month, so I wouldn't expect a reply before sometime in January.

  14. EmilienM commented on Dec 15, 2021

    @EmilienM
    Contributor

    (...) so I wouldn't expect a reply before sometime in January.

    Thanks. This is not urgent at all! Trying to make sure we keep this issue updated and at some point we close it.

  15. dtantsur commented on Apr 20, 2022

    @dtantsur
    Contributor

    Maintenance API: #2384

  16. Sharpz7 commented on Dec 31, 2024

    @Sharpz7
    Contributor

    Hey Folks,

    I recently(ish) contributed #3228, and am now looking to contribute more to baremetal. I will read everything up to now and make my own judgement on what to tackle next, but if anyone has features they are interested in being covered first, let me know.

    There are also some updates to this list. If I can be given permissions to edit the above post I am happy to do all those updates.
    #2722 (Conductors is completed)

    Portgroups seems like a good start from there?

    Cheers :)

  17. dtantsur commented on Dec 31, 2024

    @dtantsur
    Contributor

    @Sharpz7 thanks! It's worth checking which features of the list above are actually implemented or not: I think it's outdated. Of all items marked as not done, I think the port groups and the VIF API are the most important, followed by vendor passthru (but I'm quite sure we already have at least some passthru support) and the rest of the allocation API.

    Conductors API seems to have been implemented by #2722 (but please double-check it for completeness).

  18. Sharpz7 commented on Dec 31, 2024

    @Sharpz7
    Contributor

    @dtantsur you responded too quickly! I was just editing my comment since spotting the conductors change. Thank you though, I agree with you and I think that priority list is good :)

  19. mandre commented on Mar 20, 2025

    @mandre
    Contributor

    FYI, I've updated the list with completed work. Let me know if I missed anything.

  20. Sharpz7 commented on Jun 1, 2026

    @Sharpz7
    Contributor

    I don't think there is much left now. Maybe volumes?

  21. dtantsur commented on Jun 1, 2026

    @dtantsur
    Contributor

    @Sharpz7 do we have runbooks?

  22. Sharpz7 commented on Jun 1, 2026

    @Sharpz7
    Contributor

    @dtantsur no I do not think so, I will add that to do. @mandre would you be against me creating a new issue so I can take ownership of maintaining the EPIC?

  23. Sharpz7 commented on Aug 11, 2026

    @Sharpz7
    Contributor

    Okay... I think this issue is nearly entirely covered.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions