Dan and David, I see your concerns. Let me explain what I mean by modular and how we can address dependency.
Assume you have base ACS 4.2 Then you would have plugins like Nicira 4.2.x, VMware 4.2.x, NetScaler 4.2.x etc.. Goes without saying, but you cannot use a plugin from 4.3.x family on ACS 4.2.x base... We can aslo introduce dependcy checks, such that if Nicira plugin is enabled, we need VMware plugin enabled as well. Why would we consider this? You can update modules more rapidly that include bug fixes (and perhaps minor non impacting enhacements) without waiting for the entire release cycle, you testing should be less as well, as you would only be testing affected modules, unless they strongly tie with another plugin. If properly architected, CloudStack wont suffer OpenStack's faith - which is what they go through now - of only specific version x.y.z module can work with another x.y.z module. Regards ilya > -----Original Message----- > From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] > Sent: Thursday, September 26, 2013 4:57 AM > To: dev > Subject: Re: [PROPOSAL] move away from time-based releases and/or > revamp release process > > Some more remarks on this: > > Another model is of keeping quality high is controlling what gets in per > release. This would go against the opensource model somewhat. You would > need e release manager like me and I strongly advice against that. > > Giving users more control on what goes into their system is a good thing. it > must not become a 'university degree required' hurdle though. It would > allow them to have a narrower view on what is good software, functionality - > and quality wise. That would lead to better quality of quality control. I > know I > am no good at that aspect right now because of the load of code I need to > know about. > > <on the side> > hear hear, David. You are pointing at some of the challenges OSGi deals with. > Ours is a little simpler; As we don't need run-time control, our plugins can > have a strict hierarchical requirements tree which is somewhat easier to > handle. Still you might end up with a system with two hypervisor (versions) > that require a different storage or network version to work. or vice versa. I > think we should be happy at first if we get a static system where 3rd party > plugins work with version x till y. Note that then the plugin interface is to > be > stable through a (semantically versioned) major release. > > challenge i like, :) > </straight on again> > > On Thu, Sep 26, 2013 at 6:21 AM, David Nalley <da...@gnsa.us> wrote: > > On Wed, Sep 25, 2013 at 11:26 AM, Musayev, Ilya > <imusa...@webmd.net> wrote: > >> We can still use scheduled release as we do now and yet have some > agility. > >> > >> An idea was passed around before if we can modularize ACS in future > releases VS being it monolithic. > >> > >> We can still have a core as is, but additional components/plugins can be > loaded adhoc pm the need base. As an example, there is no need to bake in > vmware support into release if a customer has not need for it. You cant just > upgrade vmware code unless you upgrade from version X.y.1 to X.y.2. > >> > >> Same applies to all other "plugins", that are not truly pluggable. > >> > >> Splitting components as separate "plugins" (or whatever the proper term > is) would ease the release cycle and give us flexibility in my opinion. > >> > > > > Can you imagine the complexity of that model? Core version 4.3.x has > > to work with VMware plugin 7.2.3, 7.1.5, and 7.0.2 and also has to > > work with Nicira plugin version 3.4.1, 3.5.2, and 3.6.0 - except that > > both of those plugins interact with each other as well as the core > > orchestration platform. We struggle to test well now, the additional > > combinations there boggle the mind. > > > > --David
