: OpenStack Development Mailing List (not for usage questions);
d...@danplanet.com
Subject: Re: [openstack-dev] [Nova] What is the currently accepted way to do
plugins
And sorry, as to your original problem, the loadables approach is kinda messy
since only the classes that are loaded when *that* module
(HP Cloud Services)
Cc: OpenStack Development Mailing List (not for usage questions);
d...@danplanet.com Subject: Re: [openstack-dev] [Nova] What is the
currently accepted way to do plugins
And sorry, as to your original problem, the loadables approach is
kinda messy since only the classes
Hi All,
One of my patches has a query asking if I am using the agreed way to load
plugins: https://review.openstack.org/#/c/71557/
I followed the same approach as filters/weights/metrics using nova.loadables.
Was there an agreement to do it a different way? And if so, what is the agreed
way
On 03/04/2014 06:27 AM, Murray, Paul (HP Cloud Services) wrote:
One of my patches has a query asking if I am using the agreed way to
load plugins: https://review.openstack.org/#/c/71557/
I followed the same approach as filters/weights/metrics using
nova.loadables. Was there an agreement to
management/package metadata) it brings.
CMV,
-S
From: Russell Bryant [rbry...@redhat.com]
Sent: Tuesday, March 04, 2014 1:29 PM
To: Murray, Paul (HP Cloud Services); OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Nova] What is the currently
March 2014 17:50
To: OpenStack Development Mailing List (not for usage questions); Murray, Paul
(HP Cloud Services)
Subject: RE: [openstack-dev] [Nova] What is the currently accepted way to do
plugins
This brings up something that's been gnawing at me for a while now ... why use
entry-point based
In a chat with Dan Smith on IRC, he was suggesting that the important
thing was not to use class paths in the config file. I can see that
internal implementation should not be exposed in the config files -
that way the implementation can change without impacting the nova
users/operators.
On Tue, 2014-03-04 at 12:11 -0800, Dan Smith wrote:
Now, the actual concern is not related to any of that, but about whether
we're going to open this up as a new thing we support. In general, my
reaction to adding new APIs people expect to be stable is no. However,
I understand why things like
How about using 'unstable' as a component of the entrypoint group?
E.g., nova.unstable.events…
Well, this is a pretty heavy way to ensure that the admin gets the
picture, but maybe appropriate :)
What I don't think we want is the in-tree plugins having to hook into
something called unstable.
And sorry, as to your original problem, the loadables approach is kinda
messy since only the classes that are loaded when *that* module are
loaded are used (vs. explicitly specifying them in a config). You may
get different results when the flow changes.
Either entry-points or config would give
On 03/04/2014 05:00 PM, Kevin L. Mitchell wrote:
On Tue, 2014-03-04 at 12:11 -0800, Dan Smith wrote:
Now, the actual concern is not related to any of that, but about whether
we're going to open this up as a new thing we support. In general, my
reaction to adding new APIs people expect to be
On Tue, 2014-03-04 at 17:31 -0400, Sandy Walsh wrote:
How about using 'unstable' as a component of the entrypoint group?
E.g., nova.unstable.events…
Wouldn't that defeat the point of entry points ... immutable
endpoints? What happens when an unstable event is deemed stable?
Actually, the
12 matches
Mail list logo
