Remove CellMappingPayload database_connection and transport_url fields
Change I019e88fabd1d386c0d6395a7b1969315873485fd in Stein, which
is not yet officially released, exposes the unencrypted
database_connection URL and MQ transport_url to a CellMapping in
the select_destinations versioned notification CellMappingPayload.
While notifications are not meant to be consumed by end users of
the cloud but only internal services of the deployment, it still
seems like a bad idea to give the keys to the nova cell DB and MQ
to an external-to-nova service like ceilometer.
This change removes the fields from the CellMappingPayload and
bumps the major version to 2.0 to signal the change to consumers,
although I don't expect anything is consuming this yet but we should
follow standard versioning procedure anyway.
Note that notification consumers do not request a specific payload
version nor do they get a schema to perform their own backporting,
they just get what they get, so after this there should be no worry
about needing to support the 1.0 format for this payload.
Change-Id: Ib5edea32d15db01000e6730aebceaf119daf8c5c
Closes-Bug: #1823104
(cherry picked from commit 3301449e736af81fdbd96fd3f396dd01b02beaf2)
Reviewed: https:/ /review. openstack. org/650043 /git.openstack. org/cgit/ openstack/ nova/commit/ ?id=afe5f0d4de6 d30f119c89c2cfd 1bdf0f7c5b3de9
Committed: https:/
Submitter: Zuul
Branch: stable/stein
commit afe5f0d4de6d30f 119c89c2cfd1bdf 0f7c5b3de9
Author: Matt Riedemann <email address hidden>
Date: Wed Apr 3 22:09:52 2019 -0400
Remove CellMappingPayload database_connection and transport_url fields
Change I019e88fabd1d38 6c0d6395a7b1969 315873485fd in Stein, which connection URL and MQ transport_url to a CellMapping in
is not yet officially released, exposes the unencrypted
database_
the select_destinations versioned notification CellMappingPayload.
While notifications are not meant to be consumed by end users of
the cloud but only internal services of the deployment, it still
seems like a bad idea to give the keys to the nova cell DB and MQ
to an external-to-nova service like ceilometer.
This change removes the fields from the CellMappingPayload and
bumps the major version to 2.0 to signal the change to consumers,
although I don't expect anything is consuming this yet but we should
follow standard versioning procedure anyway.
Note that notification consumers do not request a specific payload
version nor do they get a schema to perform their own backporting,
they just get what they get, so after this there should be no worry
about needing to support the 1.0 format for this payload.
Change-Id: Ib5edea32d15db0 1000e6730aebcea f119daf8c5c fdbd96fd3f396dd 01b02beaf2)
Closes-Bug: #1823104
(cherry picked from commit 3301449e736af81