[openstack-dev] [neutron][lbaas][barbican] default certificate manager

Brandon Logan brandon.logan at RACKSPACE.COM
Fri Apr 10 19:18:49 UTC 2015

Hi Ihar,
I'm not against the lazy loading solution, just wondering what the real issue is here.  Is your problem with this that python-barbicanclient needs to be in the requirements.txt?  Or is the problem that v1 will import it even though it isn't used?

From: Ihar Hrachyshka <ihrachys at redhat.com>
Sent: Friday, April 10, 2015 4:44 AM
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [neutron][lbaas][barbican] default certificate manager

Hash: SHA1

On 04/09/2015 10:51 PM, Brandon Logan wrote:
> Hi Ihar, So that decision was indeed hastily done but I still think
> it was the right one.  Let me break down the reasons:
> 1) To use the local cert manager, the API would have to accept the
> raw secrets (certificate, private key, etc).  We'd have to store
> that some place, but it would have been explicitly documented that
> the local cert manager was an insecure option and should not be
> used in a production environment.  So that's not a huge deal, but
> still a factor.  Without these fields, the local cert manager is
> useless because a user can't store anything.
> 2) If #1 was allowed then the listener would have to accept those
> fields along with a tls_container_id.  That in itself can be
> confusing, but it could be overcome with documentation.
> 3) If barbican was in use then it would be expected that the
> neutron-lbaas API would accept the raw secrets, and then its up to
> the system to store those secrets in barbican.  Who should those
> secrets be owned by? a) If we make them owned by the user then you
> run into the issue of them re-using the secrets in some other
> system.  What happens when the user deletes the listener that
> the secrets were originally created for? b) If we make them owned
> by the system then a user can't reuse the same secrets, which is a
> big reason to use barbican.
> 4) Time.  The options above could definitely have been done, but
> along with not being clear as to which is the best option (if there
> is one), there wasn't much time to actually implement them.
> So given all of that, I think defaulting to barbican was the lesser
> of many evils.  LBaaS v2 is marked as experimental in the docs so
> that gives us some leeway to make some backwards incompatible
> changes, though the options above wouldn't be backwards
> incompatible.  It's still a signal to users/operators that its
> experimental.

OK, so it means that it's for LBaaSv2 only, correct? The default value
makes it a requirement to add python-barbicanclient as a dependency
for neutron-lbaas package even when only lbaas v1 agent is used. And
that's my problem with the choice. It would be better if importing
cert_manager didn't mean barbicanclient import is issued [1].

I suppose some kind of lazy loading would suit here better? I've sent
a lazy loader patch for review [2], please take a look.

[2]: https://review.openstack.org/172357

Version: GnuPG v1


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe

More information about the OpenStack-dev mailing list