Open Stack

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?

Thanks,
Brandon
________________________________________
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

-----BEGIN PGP SIGNED MESSAGE-----
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.

[1]:
https://github.com/openstack/neutron-lbaas/blob/master/neutron_lbaas/common/cert_manager/__init__.py#L36
[2]: https://review.openstack.org/172357

/Ihar
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVJ5uEAAoJEC5aWaUY1u574Y0IAMYTAZXr1SYlSZvZzwaP0uZN
gyRruqY2qj8PRE+ARxROrAXt4ItLvmdxUoBpcME2Pve/xQps/P3m89VLqhiFD3eu
ctodZxu95e9Wl3x1VLnk5yIgq1STpTERbltYYNw0OTYxf+F2WBCqKQSrPtRGZLsM
/2pYRZdfteJm9TTvMT42g6g+QCQDAPlXzS7IaK5D+/gyW9JMW79mpOhYz2XyysVo
WGIS3i4PefiG//vFh5SP5aqeMB/xxfUv3dRDmbriRg9rJMuptWuYXJRsctEtsodR
1PjbcgzaPRdZxdhCOelAn6sVQiEBHmg5TVIxehytgV3FYAEWuDDVPKfGrACOKy0=
=qkib
-----END PGP SIGNATURE-----

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev