Interesting. I'm not sure how I missed this thread... I'll try to chime in
where I can, then. However, everything going on in here sounds like work for
post-4.3, but if we are adding revert volume snapshot to 4.3, we will need a
solution to that before then. It seems like the idea I've got for t
Kelven,
As I stated in my proposal, I think it is important to recognize the
distinction between components that control/interact with infrastructure and
components that represent orchestration abstractions/mechanisms within the
management server. Currently, these two concepts are conflated --
John,
I understand. The effort we did in 4.1 was mainly to free developers from
the needs to work at low-level plumbing layer, prior to 4.1, not every
developer knows how to modify ComponentLocator safely, switching to a
standard framework can let us focus on Cloud operating business logic.
Break
There has been much discussion recently on the board about
refactoring/rearchitecting. There are some great ideas being thrown
around, but I would like to see a focus on testing prior to any of
this work, so we can see what breaks after the major changes. It would
be nice if we could dedicate a wh
John,
I mentioned before I'd been thinking up some ideas that go along with
some of the things you've proposed here. I'm working through a lot of
different ideas right now, but I've thrown up some notes in a totally
random part of the CloudStack wiki. Take a look, this is a complete
work in
I could give inline answers, but let's not waste to much more time.
One point I would like to make is that the live-cycle functions that
driver writers implement take care of how (in what state) instances
are stopped.
Your point on restricting dependencies is valid and a real concern.
And to not
Kelven,
Please don't take my proposal as a criticism of the approach taken in 4.1. I
think the current model is a big improvement over the previous approach. Given
the time constraints and ambitions of that work, I think it was a solid,
pragmatic first step. I believe we are at a point to as
Daan,
I think I mentioned in my proposal to defer hot loading/unloading to a later
release. It is a hard issue, and not required to address the current pain
points.
Thanks,
-John
On Aug 25, 2013, at 7:43 AM, Daan Hoogland wrote:
> It seems I am the only one not sharing your reservations reg
Darren,
Please see my responses in-line below.
Thanks,
-John
On Aug 21, 2013, at 11:42 AM, Darren Shepherd
wrote:
> I also agree with this. Spring XML should always be treated as code not
> really configuration. It's not good to have a sysadmin touch spring config
> and frankly it's just
Prasanna,
Generally, Spring configuration files should be packaged in their associated
JARs with property substitution for configurable items (e.g. connection pool
min and max sizes). Unfortunately, Spring does not allow component wiring to
be modified through property files. Since plugins ar
Daan,
Please see my responses in-line below. The TL;DR is that I am extremely
skeptical of the complexity and flexibility of OSGi. My experience with it in
practice has not been positive. However, I want to focus on our requirements
for a driver mechanism, and then determine the best impleme
It seems I am the only one not sharing your reservations regarding
OSGi, so let's go for it, John.
I would personally try to not bother with the hot-loading and
-unloading of drivers and create a install and a drivers directory for
all running processes, where these will be checked upon starting
Spring is not meant to be used as a solution for run-time "plug-ins".
Darren is correct that Spring XML should be treated as code (ideal place
for it is the resource section inside the jar). Why we end up the way now
is mainly for practical reason. Since most of our current pluggable
features are n
I also agree with this. Spring XML should always be treated as code not really
configuration. It's not good to have a sysadmin touch spring config and
frankly it's just mean to force them to.
I would ideally like to see that registering a module is as simple as putting a
jar in a directory.
On Tue, Aug 20, 2013 at 05:43:17PM -0400, John Burwell wrote:
> Leaky Abstraction: Plugins are registered through a Spring
> configuration file. In addition to being operator unfriendly (most
> sysadmins are not Spring experts nor do they want to be), we expose
> the core bootstrapping mechanism
John,
You do want 'In-process Installation and Upgrade', 'Introspection' and
'Discoverability' says that you do want flexibility. You disqualify
Spring and OSGi on this quality however.
If we can restrict the use of bundles to those that adhere to some
interfaces we prescribe I don't think either
Daan,
I have the following issues with OSGi:
Complexity: Building OSGi components adds a tremendous amount of complexity to
both the building drivers and debugging runtime issues. Additionally, OSGi has
a much broader feature set than I think CloudStack needs to support.
Therefore, driver
Hi John,
This is really good thinking on the future of cloudstack driver/plugin
architecture.
I would be very happy if we can decouple the ACS releases from vendor
specific releases.
I also agree on the research & experiments (POCs, tools) that needs to be
undertaken to conclude if decoupled dri
John,
Nice work.
Given the maturity of OSGi, I'd say lets see how it fits. One criteria
would be can we limit the bundles that may be loaded based on what
Cloudstack supports (and not allow loading pydev) if not we need to
bake our own.
But though I think your work is valuable I disagree on desig
Sure, I fully understand how it theoretically works, but I'm saying from a
practical perspective it always seems to fall apart. What your describing is
done excellently in OSGI 4.2 Blueprint. It's a beautiful framework that allows
you to expose services that can be dynamically updated at runti
Darren,
My response does hand wave two important issues -- hot code reloading and
PermGen leakage. These are tricky, but well trod issues that can be solved in
variety of ways (e.g. instrumentation, class loaders, OSGi). It would require
a some research/experimentation to determine the best a
Darren,
Actually, loading and unloading aren't difficult if resource management and
drivers work within the following constraints/assumptions:
Drivers are transient and stateless
A driver instance is assigned per resource managed (i.e. no singletons)
A lightweight thread and mailbox (i.e. actor
I know this isn't terribly useful, but I've been drawing a lot of squares and
circles and lines that connect those squares and circles lately and I have a
lot of architectural ideas for CloudStack. At the rate I'm going it will take
me about two weeks to put together a discussion/proposal for t
I agree, John - let's get consensus first, then talk time tables.
On Tue, Aug 20, 2013 at 4:31 PM, John Burwell wrote:
> Mike,
>
> Before we can dig into timelines or implementations, I think we need to
> get consensus on the problem to solved and the goals. Once we have a
> proper understandi
Mike,
Before we can dig into timelines or implementations, I think we need to get
consensus on the problem to solved and the goals. Once we have a proper
understanding of the scope, I believe we can chunk the across a set of
development lifecycle. The subject is vast, but it also has a far re
Hey John,
I think this is some great stuff. Thanks for the write up.
It looks like you have ideas around what might go into a first release of
this plug-in framework. Were you thinking we'd have enough time to squeeze
that first rev into 4.3. I'm just wondering (it's not a huge deal to hit
that r
26 matches
Mail list logo
