The original report did not highlight that this requires the P computes to be using a modified [cinder]catalog_info specifically looking for a cinderv2 type endpoint, as is default in TripleO:
You could argue that this is a config issue but IMHO the fact this is possible in P means we should continue to provide the type in the request context service catalog in Q, allowing any P computes to LM instances and eventually upgrade to Q where the default has now changed in TripleO:
The original report did not highlight that this requires the P computes to be using a modified [cinder] catalog_ info specifically looking for a cinderv2 type endpoint, as is default in TripleO:
https:/ /github. com/openstack/ tripleo- heat-templates/ blob/351c320c19 1252c496f6911f9 72d31390469585b /puppet/ services/ nova-base. yaml#L226
You could argue that this is a config issue but IMHO the fact this is possible in P means we should continue to provide the type in the request context service catalog in Q, allowing any P computes to LM instances and eventually upgrade to Q where the default has now changed in TripleO:
https:/ /github. com/openstack/ tripleo- heat-templates/ blob/3570a94a69 e05af23cee11fbf af3822538f75023 /puppet/ services/ nova-base. yaml#L228