You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
gophercloud >= 2.7 breaks on parsing security group time (with some Neutron configuration) #3492
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)
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
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.
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)
Activity
[-]gophercloud >= 2.7 breaks on parsing security group time[/-][+]gophercloud >= 2.7 breaks on parsing security group time (with some Neutron configuration)[/+]Networking v2: Support two time formats for subnet, router, SG rules (g…
mandre commentedon Aug 13, 2025
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.
Networking v2: Support two time formats for subnet, router, SG rules (g…
Networking v2: Support two time formats for subnet, router, SG rules (g…
Networking v2: Support two time formats for subnet, router, SG rules (g…
tmmorin commentedon Aug 13, 2025
no apologies needed, this format is indeed legacy ...
(we just have this need on this very specific corner case platform)
Merge pull request #3493 from tmmorin/fix-3492
Networking v2: Support two time formats for subnet, router, SG rules (#…
Merge pull request #3494 from gophercloud/bp-v2-e852df2