Client refactor broke all object entrypoints

Adam, are there any patches up for review to fix this in the broken projects or links to the code that is broken by the recent python-barbicanclient relese? Can you post links to them?

The part in the report above about castellan being broken is not true, as was figured out in the comments on https://review.openstack.org/#/c/487721/1 .

Also, as far as I'm aware, the python-barbicanclient documentation does not recommend importing objects directly: "from barbicanclient import secrets", it recommends using the object managers that are created as part of the client as castellan does. Yes, it was bad to break backwards-compatibility without warning, but we also weren't aware that projects were using python-barbicanclient in a way that was not documented. Apologies for the trouble.

Kaitlin, may i request a quick review of http://codesearch.openstack.org/?q=%5E(from%7Cimport).*castellan&i=nope&files=&repos= by the barbican team?

Also, can one of you please log a block for 4.5.0 in the global requirements

Thanks,
Dims

So, the docs at https://docs.openstack.org/python-barbicanclient/latest/cli/usage.html which recommend this type of usage are newer than our code by a bit. Remember that I *wrote* most of the current v1 client, and was the first user of it, with Octavia... At the time, this method of access *was* the recommended way.

I would bet that some other services used Octavia's implementation as an example, so that is why they are doing it that way as well. Heat is the other example I'm directly aware of that uses it like we do.
We have a bug in our launchpad to migrate: https://bugs.launchpad.net/octavia/+bug/1707091

Reviewed: https://review.openstack.org/487721
Committed: https://git.openstack.org/cgit/openstack/python-barbicanclient/commit/?id=49505b9aec05ec42e0a809ec51935c2324d5f3a6
Submitter: Jenkins
Branch: master

commit 49505b9aec05ec42e0a809ec51935c2324d5f3a6
Author: Jeremy Liu <email address hidden>
Date: Thu Jul 27 15:08:54 2017 +0800

    Workaround for importing objects from old path

    Many projects are importing secrets and containers from barbicanclient,
    the refactor change needs to keep compatiable for this.

    This is workaround for that and marked as deprecation.

    Change-Id: Ibc9b525f1abe0a7627759e438977a6bf6b86bed6
    Closes-bug: #1706841

This issue was fixed in the openstack/python-barbicanclient 4.5.1 release.

The issue still exists. Before the refactor patch, secrets module could be imported either from barbicanclient.secrets or barbicanclient.client.secrets. The refactor patch removed secrets module from both places. Octavia is using both mothods to import secrets/containers modules [1][2].

[1] https://github.com/openstack/octavia/blob/master/octavia/certificates/common/barbican.py#L35
[2] https://github.com/openstack/octavia/blob/master/octavia/tests/unit/certificates/manager/test_barbican.py#L18

Fix proposed to branch: master
Review: https://review.openstack.org/489518

Reviewed: https://review.openstack.org/489518
Committed: https://git.openstack.org/cgit/openstack/python-barbicanclient/commit/?id=714fce222816ad3348d4ba4c3baaa721308158e2
Submitter: Jenkins
Branch: master

commit 714fce222816ad3348d4ba4c3baaa721308158e2
Author: Jeremy Liu <email address hidden>
Date: Tue Aug 1 15:47:48 2017 +0800

    Support import modules from barbicanclient.client module

    Before refactor patch, modules could be imported either from
    barbicanclient.<module> or barbicanclient.client.<module>, octavia
    is using both methods. We need to support that.

    Change-Id: Ib5b7c2ae50d30e85685c20cfabc188f46c0c947b
    Closes-bug: #1706841

This issue was fixed in the openstack/python-barbicanclient 4.5.2 release.