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
