Ilya, I think you are in line with my 'on the side' notice. It is a promise I like with one downside. You risk a successful 3rd party plugin writer still and only supporting 5.6.5 whilst we are already at 7.3.x, hence the last few lines of that remark.
So does not allowing a plugin 4.3 on a 4.2 instance also mean not allowing a 4.2 on 4.3? Can a developer build for 10.3 and up? And how are we ensuring that at version 13 we disallow this plugin before it is revisited by the author because we know of some quirk in our plugin mechs that we created or fixed? Rhetoric question, that last one. The answer being of course some extra numbering scheme or table under the hood. It must be devised in my opinion as allowing the plugin to load will hurt the user and the rep of ACS. So answering the first two questions defines how much work this will be. Daan On Thu, Sep 26, 2013 at 8:15 PM, Musayev, Ilya <imusa...@webmd.net> wrote: > 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 > > >
