gophercloud
neutron: add more quotas members
coverage: 63.704%. remained the same when pulling b5851c14f243b6af13ffafbfb78addf8eb0b17bd on kayrus:new-neutron-quota into 992e8b74d2f7b1bb936a07cf2451ce34f946305f on gophercloud:main.
To be honest I don't know. Existing support for rbac policies extension already resides in the quota package.
@mandre I think once these new struct members are pointers, it is ok to keep them here. They will be ignored if they're not defined.
I'm not sure either. Let's ask the other maintainers. @gophercloud/core any opinion on where the quota fields for neutron extensions should live?
Should we add them to openstack/networking/v2/extensions/fwaas_v2 for fwaas quota similar to what we're doing for MTU, or add them directly to openstack/networking/v2/extensions/quotas/ like we've already done for RBAC policy?
I'd be personally in favour of the former, if this is possible, seeing as these are quotas for an extension. Any extension can define its own quota, so this could quickly get out of hand otherwise. My 2c
For context, networing-bgpvpn, neutron-fwaas and networking-sfc all register resource quotas. tap-as-a-service does not.
I shared my thoughts on moving this into a new extension in https://github.com/gophercloud/gophercloud/pull/3447#issue-3192330597. Using pointers for these struct members should be safe and should not introduce issues. Creating separate packages for each individual option, however, could add unnecessary complexity and negatively impact the developer experience for SDK users.