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

[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)

[mandre]

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.

[tmmorin]

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)