(Inlined) Thanks for chiming in! On 23 September 2014 11:59, Vinod Kone <vinodk...@gmail.com> wrote:
> Ok. I finally had a chance to read the design doc, go through the comments > on this thread and glance at the review. Here are my comments. > > I like the concept of dynamic loading of libraries when it comes to making > the lives of end users/operators easy, esp when they want to mix and match > the modules. > > I agree with Dominic though that we should make sure to minimize the > burden/overhead of core developers when it comes to dealing with modules. > FWIW, the implementation that I've seen seems easy enough to deal with and > doesn't look like it adds much of a performance overhead. > > That said, the versioning part seems a bit complicated, as BenH alluded to. > Can we come up with something that's simple as the first cut but still > extensible? Also, it would be great if interface breakage could be > automatically deduced at load time. But I guess we still need a module > version to deal with protocol changes without interface changes. To ensure > the devs update the versions in module manager, I suggest adding a comment > on top of the current components (Allocator, Isolator etc) mentioning that > there is a corresponding module that needs to be updated. Better yet, maybe > we could use a naming convention (e.g., s/Allocator/AllocatorModule/) for > easy visual cue. > Good point on naming explicitly. We can do that incrementally when we start wiring modules up. The easiest path forward (but a bit oversimplified and non-backwards compatible) is to enforce module X to be built against the same version of mesos as the one being loaded into. It is a minor change to the current patch and per-subsystem versioning can be reenabled later on, when we gain more confidence in the API stability of individual subsystems. I am not religious there; we can start out strict. > > More importantly, I would like to understand how we are going to ensure the > quality of modules being written. In other words how do we, as a community, > ensure that a badly written module doesn't leave a bad taste in users > adopting Mesos. Should we come up with a test suite (functional and > performance) that runs on CI that module writers are required to test > against? What is the contract for support when something in modules break? > Should the users/operators ask on #mesos and dev lists or module writer's > lists? Would the users even know where the problem lies? Would Mesos devs > always know? I think this is where most of the burden/overhead lies. Of > course, this is the same problem with frameworks, but I think this is much > more relevant for modules because they (could) fundamentally change the > behavior of Mesos. > The first module we planned to wire up would be isolator modules. The patch is going to include a modularized isolator, tested against our existing isolator unit tests. We can work on getting the necessary build tooling setup so module implementors can run relevant unit tests (and wire up their own). I like the idea of mesos modules mailing list, as it (like with other module / plugin systems) is on the users / module writers own responsibility to be compatible, hardened and tested. The is a disclaimer that is important to emphasize. > > Even more fundamentally, how are we going to ensure that Mesos core gets > better features vs having the cool features developed as (possibly paid) > modules? For example, should Kerberos auth and SSL transport be modules or > should they be integrated into the core? As an open source project, how do > we ensure that the community resources are properly utilized in a fair and > neutral manner to help Mesos core grow? Are we going to have > guidelines/opinions on what should/could be modularized or is everything > fair game? It would be great to understand how other successful open source > projects toe this line. Has anyone done any research regarding this? > I agree and I think we should document this in-depth. Like I mentioned above, using 3rd party modules are without _any_ guarantee or support from the Mesos developers. If we end up embracing / blessing modules, we can pull those into the source base and test it in our CI. Apache Webserver use this scheme and has graced modules ( http://httpd.apache.org/docs/current/mod/) and 3rd party / non-graced modules (https://modules.apache.org) The most commonly used (which I have been referring to): Apache Web Server. Apart from the Apache web server, the Linux loadable modules is a great example of big system that uses modules. See section 2.3 at http://www.tldp.org/HOWTO/Module-HOWTO/x73.html for the case for modules for linux. Lots of the advantages apply here as well (multiple ways to do something don't want to rebuilt the kernel all the time) As we go on and grow the capabilities of Mesos, I suspect we will need to be able to address specialized setups: custom fitted isolation mechanisms (which are going to be vastly different for cloud/VM environments to on-premise), authentication integrations, etc. where you can't have one solution that fits all (optimally). Niklas > > > On Tue, Sep 23, 2014 at 9:27 AM, George Sudarkoff <geo...@sudarkoff.com> > wrote: > > > Hello everybody! > > > > I'm new here. But why not jump in in the middle of the conversation and > > voice an opinion anyway, right? :) > > > > On 23 Sep 2014, at 09:17, Dominic Hamon <dha...@twopensource.com> wrote: > > > > > On Tue, Sep 23, 2014 at 5:57 AM, Tim St Clair <tstcl...@redhat.com> > > wrote: > > > > > >> > > >> > > >> ----- Original Message ----- > > >>> From: "Benjamin Hindman" <b...@eecs.berkeley.edu> > > >>> To: "dev" <dev@mesos.apache.org> > > >>> Sent: Tuesday, September 23, 2014 3:14:31 AM > > >>> Subject: Re: Mesos Modules Design > > >>> > > >>>> > > >>>> - create abstract classes to define interfaces to objects that > should > > >> be > > >>>> modular > > >>>> > > >>> > > >>> We're all in agreement here! > > >>> > > >>> - build modules as static libraries that can be assembled at link > time > > to > > >>>> create custom Mesos builds > > >>>> > > >>> > > >>> Okay, but unless I'm missing something here we'll still need a level > of > > >>> indirection to wire everything together. What would that look like? > > >>> > > >>> Also, why ask an operator to go through the extra step of relinking > > >> Mesos? > > >>> Asking the operator to relink means they'll need a Mesos build > > >> environment, > > >>> while most folks will likely just have Mesos installed via an RPM (or > > >>> similar). I'm not convinced that getting a link error will be a > better > > >> user > > >>> experience then getting a runtime error that cleanly prints out > > something > > >>> along the lines of "Version mismatch: the XXYYZZ module is not > > compatible > > >>> with this version of Mesos". > > >> > > >> To ask service operators to re-link and possibly re-deploy mesos is a > > >> non-starter imho. One of the goals of enabling "plugins" around key > > >> interfaces is to avoid this type of operation. > > >> > > > > > > ​What, concretely, does a service operator do if they have a bunch of > > > modules that give runtime version errors? What are there options to > get a > > > running version? > > > > "Runtime" doesn't necessarily mean "four days after you start it". What > > I'd expect from a piece of software with plugins is to load the plugins > and > > verify the versions/compatibility at launch time. If I drop a new plugin > in > > and restart a client, I know what to do when the client complains about > the > > incompatible versions. > > > > > > -- George > > > > > > > > > > > > > > > >> > > >> -- > > >> Cheers, > > >> Timothy St. Clair > > >> Red Hat Inc. > > >> > > > > > > > > > > > > -- > > > Dominic Hamon | @mrdo | Twitter > > > *There are no bad ideas; only good ideas that go horribly wrong.* > > > > >
