age-
> From: Sandy Walsh [mailto:sandy.wa...@rackspace.com]
> Sent: 04 March 2014 21:25
> To: Murray, Paul (HP Cloud Services)
> Cc: OpenStack Development Mailing List (not for usage questions);
> d...@danplanet.com Subject: Re: [openstack-dev] [Nova] What is the
> currently ac
s)
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 that are loaded when *that* m
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?
Actu
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
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 re
> 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 "unstabl
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
> 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.
t: 04 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-p
for the added pain (entry-point
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: [op
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
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 of
12 matches
Mail list logo
