Skip to content

gophercloud >= 2.7 breaks on parsing security group time (with some Neutron configuration) #3492

Description

@tmmorin

Issue

We recently ran into a situation where the following error was raised by CAPO (Cluster API OpenStack provider) which uses gophercloud:

E0807 12:12:22.404583       1 controller.go:324] "Reconciler error" 
   err="failed to reconcile security groups: parsing time \"2024-11-26T11:03:35.521964\" 
            as \"2006-01-02T15:04:05Z07:00\": cannot parse \"\" as \"Z07:00\"" 
...

Observations

This error started to appear when upgrading CAPO from 0.11.3 to 0.11.6, which among other changes upgrades gophercloud from 2.2.0 and 2.7.0.

I have observed this:

  • gophercloud has code to let it accept two time formats for security groups updated_at/created_at fields here: the standard ISO8601 format and the "older neutron time format" (called RFC3339NoZ in gophercloud code)
  • in this OpenStack tenant the SG groups used by CAPO indeed have such timestamp that match the RFC3339NoZ format (both for the SG updated_at/created_at fields, and for the fields of the SG rules that it includes):
    +------------+----------------------------+
    | Field      | Value                      |
    +------------+----------------------------+
    | created_at | 2023-03-09T14:51:27.533307 |
    | updated_at | 2025-08-06T14:48:16.792728 |
    +------------+----------------------------+
    
  • between gophercloud 2.2.0 and 2.7.0, there was one addition (in 99b0a51) that added support for updated_at/created_at for Security Group Rules, but without anything to accept the "older neutron time format"

Analysis

Based on the observations above, it seems that the explanation is the following:

  • gophercloud 2.2.0 parses our SGs successfully because gophercloud accepts the "older neutron time format" for Security Groups updated_at/created_at, and does not attempt to read the updated_at/created_at fields of the SG Rules that are embedded in Security Group resources
  • gophercloud 2.7.0 breaks on parsing our SGs because it attempt to read the updated_at/created_at fields of the SG Rules that are embedded in Security Group resources, but without support for the "older neutron time format" for these SG rules fields

Context

The cluster on which this happens is using OpenStack Neutron from RedHat OSP16, with Contrail Neutron Core Plugin, which seems to be the reason for those 2023-03-09T14:51:27.533307 timestamps. Those timestamps are not exactly like the "older neutron time format" (RFC3339NoZ) since they have the additional .<microseconds>, but they are compatible with it (Go will successfully parse 2023-03-09T14:51:27.533307 with RFC3339NoZ format, as can be seen in this sandbox example)

Version

v2 (current)

Activity

  1. added theissue type on Aug 13, 2025
  2. changed the title [-]gophercloud >= 2.7 breaks on parsing security group time[/-] [+]gophercloud >= 2.7 breaks on parsing security group time (with some Neutron configuration)[/+] on Aug 13, 2025
  3. mandre commented on Aug 13, 2025

    @mandre
    Contributor

    Apologies, I wrongly assumed that the older neutron time format was legacy and we could not find any more OpenStack in the wild using this time format. I didn't realize RHOSP 16 (based on OpenStack Train) was still using it. The proposed patch is exactly how we should do it, thanks for the great bug report and the provided fix.

  4. tmmorin commented on Aug 13, 2025

    @tmmorin
    ContributorAuthor

    Apologies, I wrongly assumed that the older neutron time format was legacy and we could not find any more OpenStack in the wild using this time format. I didn't realize RHOSP 16 (based on OpenStack Train) was still using it. The proposed patch is exactly how we should do it, thanks for the great bug report and the provided fix.

    no apologies needed, this format is indeed legacy ...

    (we just have this need on this very specific corner case platform)

  5. added a commit that references this issue on Aug 13, 2025
  6. added a commit that references this issue on Aug 13, 2025
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

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions