Summarizing all the reviews: Doug's proposed check in oslo_db.tests: https://review.openstack.org/#/c/545859/ Mark oslo_db internal fixtures private: https://review.openstack.org/545862 Cinder: https://review.openstack.org/545860 Neutron: https://review.openstack.org/545868 Ironic: https://review.openstack.org/545874 Glance: https://review.openstack.org/545878 Glare: https://review.openstack.org/545883
On Mon, Feb 19, 2018 at 11:32 AM, Doug Hellmann <d...@doughellmann.com> wrote: > Excerpts from Michael Bayer's message of 2018-02-19 10:55:52 -0500: >> wow that's heavy-handed. should that be in an oslo utility package of >> some kind ? > > I thought about that, but figured we should wait and see whether we > actually want to take the approach before polishing it. If we do we can > add a function in oslo.utils. > >> >> On Mon, Feb 19, 2018 at 10:52 AM, Doug Hellmann <d...@doughellmann.com> >> wrote: >> > Excerpts from Doug Hellmann's message of 2018-02-19 10:15:34 -0500: >> >> Excerpts from Michael Bayer's message of 2018-02-19 10:00:59 -0500: >> >> > Hi list - >> >> > >> >> > Apparently Cinder was misled by my deprecations within the >> >> > oslo_db.sqlalchemy.test_base package of DbFixture and DbTestCase, and >> >> > in https://review.openstack.org/#/c/522290/ the assumption was made >> >> > that these should be imported from oslo_db.tests.sqlalchemy. This >> >> > is an immense mistake on my part that I did not expect people to go >> >> > looking for the same names elsewhere in private packages and now we >> >> > have a serious downstream issue as these modules are not packaged, as >> >> > well as the possibility that the oslo_db.tests. package is now locked >> >> > in time and I have to add deprecations there also. >> >> > >> >> > If anyone knows of projects (or feels like helping me search) that are >> >> > importing *anything* from oslo_db.tests these must be reverted ASAP. >> >> > >> >> >> >> If we have modules or classes we don't expect people to be importing >> >> directly, we need to prefix the names with _ to comply with the naming >> >> conventions we have previously told everyone to look for to recognize >> >> private code. >> >> >> >> I think it's safe to treat "tests" as an exception (after resolving >> >> this case) but we should probably document that. >> >> >> >> Doug >> > >> > Once we resolve the current set of imports, we can land a patch like >> > https://review.openstack.org/545859 to prevent this from happening in >> > the future. >> > >> > Doug >> > >> > __________________________________________________________________________ >> > OpenStack Development Mailing List (not for usage questions) >> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev