Conversation
98817b8 to
6c39ef5
Compare
|
6c39ef5 to
8c2fbe4
Compare
resolved |
8c2fbe4 to
37c481d
Compare
and trailing whitespace |
4beceef to
8befce2
Compare
|
I think when replica promoted, the old dns record will still work because readable replica is enabled. And dns record should be updated to the new active replica. Potentially this might break share mounting. Honestly idk how to handle this correctly. Maybe simply forbid creating replica for shares with dns metadata, and forbid adding dns metadata for shares with replica. But this would make the feature less usable. |
Carthaca
left a comment
There was a problem hiding this comment.
Sorry, I did not find much time, so I'll only gave it a quick AI-assisted glance now.
Look at the inline comments.
And in general, some remarks of identified things:
Would this work for CIFS or non-NetApp backends?
Efficiency: designateclient(context) and _get_zone_id are called per operation — cache the client and memoize dns_domain → zone_id
Critical-path blocking: Designate calls sit on the share-create / share-delete critical path; a Designate outage stalls every share for the full HTTP timeout window. Move to async / short timeout + best-effort reconcile.
Reuse: Hardcoded {'dns_name','dns_domain'} set duplicates the purpose of CONF.driver_updatable_metadata
Lifecycle gap: Renaming dns_name while dns_domain is unchanged leaves the old DNS export-location row and old A record behind (the branch condition not dns_export_locs is false, so no cleanup runs).
8befce2 to
4f66927
Compare
79174c0 to
d484b97
Compare
- Creates a DNS A record in OpenStack Designate pointing to the preferred export location IP - Adds an extra export location with the DNS path - Solved the problem of NFS clients needing to update mount configurations when a share server is recreated and gets a different IP — the DNS name stays stable even if the underlying IP changes Change-Id: I6f7ff44c3a8fe0aad2a6b93124e3beb5151a7876
d484b97 to
6ce9192
Compare
Change-Id: I6f7ff44c3a8fe0aad2a6b93124e3beb5151a7876