Certainly that would be better than reinventing things, but from our conversations with the Infinispan people, I was under the impression that they were looking to drift more toward Cassandra and other NoSQL databases rather than drifting toward stronger consistency. I'm actually think we should be exploring the opposite.
It's possible that we could drive Infinispan in a different direction, but color me skeptical based on their past and current APIs and positioning.
--Colin
Giovanni Meo <gmeo@...> wrote on 10/30/2013 03:15:34 AM:
> From: Giovanni Meo <gmeo@...>
> To: Colin Dixon/Austin/IBM@IBMUS
> Cc: "dev (controller-dev@...)" <controller-
> dev@...>, controller-dev-
> bounces@..., "Bainbridge, David"
> <dbainbri@...>, "'integration-dev@...'"
> <integration-dev@...>
> Date: 10/30/2013 03:15 AM
> Subject: Re: [controller-dev] Clustering question
>
> Hi Colin,
>
> i would love to see an alternative implementation, so to really
> weights pro and
> cons. On the point of doing a raw implementation over Jgroups well i
> suspect it
> will end up looking very much like Infinispan. Maybe in the spirit
> of opensource
> it would be better to contribute enhancements to Infinispan if there
> are issues
> that should be addressed there.
>
> My 2 cents,
> Giovanni
>
> On 29-Oct-13 21:56, Colin Dixon wrote:
> > Presumably it would be pretty easy to wire up ZooKeeper so that
> each controller
> > instance ran a ZooKeeper server as an OSGi bundle and the only
> "clients" were
> > people calling into that bundle.
> >
> > I think that after the hydrogen release, it might be good to try to build an
> > implementation using ZooKeeper or possibly build something based on JGroups
> > rather than Infinispan. JGroups is the reliable multicast layer on
> top of which
> > Infinispan is built.
> >
> > I'd love to spend some more time explaining what some of the
> interesting bits
> > and reasons for this would be, but given the upcoming release, it seems more
> > fruitful to do this starting sometime in January.
> >
> > --Colin
> >
> > controller-dev-bounces@... wrote on 10/29/2013
> 05:24:29 AM:
> > > From: Giovanni Meo <gmeo@...>
> > > To: "Bainbridge, David" <dbainbri@...>
> > > Cc: "dev \(controller-dev@...\)" <controller-
> > > dev@...>, "'integration-
> > > dev@...'" <integration-dev@...>
> > > Date: 10/29/2013 05:24 AM
> > > Subject: Re: [controller-dev] Clustering question
> > > Sent by: controller-dev-bounces@...
> > >
> > > Hi David,
> > >
> > > yes i have looked at ZooKeeper, so the reason why i didn't pick it
> > > was because
> > > the Zookeeper to my knowledge implements its functionality using a
> > > server-client
> > > architecture:
> > >
> > > http://zookeeper.apache.org/doc/r3.1.2/zookeeperOver.html
> > >
> > > that means that depending on how you deploy your cluster you
> may have to add
> > > more zookeper server because else the system may run in bottlenecks. That
> > > translates in a deployment issue because when you deploy it you need to
> > > dimension the number of zookeper servers to deploy as well, and
> take care to
> > > where you connect in order to avoid to overload any of them.
> > > Now starting from this points i looked around and run into
> infinispan which
> > > allow to deploy your cluster as a P2P network because beside the
> > > meet and greet
> > > phase the other communications happens on a full mesh.
> > > This is a bit of history, that said if folks have a good zookeeper
> > > experience i
> > > encourage to create an alternative clustering.services-
> > > implementation based on
> > > it so we can actually weight the pro and cons on real code, which is
> > > always eye
> > > opening.
> > >
> > > Thanks,
> > > Giovanni
> > >
> > > On 28-Oct-13 18:00, Bainbridge, David wrote:
> > > > Giovanni,
> > > >
> > > > Thanks for this pointer. I was wondering if any thought was
> given to use
> > > > something like Zookeeper to maintain the cluster information as
> > > opposed to the
> > > > supernode construct?
> > > >
> > > > I understand that structurally this doesn't significantly change
> > > how clustering
> > > > operates (i.e. something needs to be started and used for
> > > coordination before
> > > > controllers are started), but using something like ZK would
> > > provide a separation
> > > > of concerns between controller cluster management and other
> > > controller functions
> > > > as well as potentially provide a mechanism to coordinate
> between controllers
> > > > when ODL is not the only controller deployed in a network.
> > > >
> > > > Just thinking out loud ...
> > > >
> > > >
> > > > mahalo,
> > > > /david
> > > >
> > > > On 10/28/2013 03:56 AM, Giovanni Meo wrote:
> > > >> Hi Luis,
> > > >>
> > > >> apologize for it, create a wiki page with the information:
> > > >>
> > > >> https://wiki.opendaylight.org/view/
> OpenDaylight_Controller:Clustering:HowTo
> > > >>
> > > >> Please let me know if you run into issues.
> > > >>
> > > >> Thanks,
> > > >> Giovanni
> > > >>
> > > >> On 28-Oct-13 04:04, Luis Gomez wrote:
> > > >>> Hi again,
> > > >>>
> > > >>> I am looking for a procedure to do system test on a controller
> > > cluster. However
> > > >>> I do not find any instruction on how to setup and verify a
> > > cluster, any idea?
> > > >>>
> > > >>> Thanks in advance
> > > >>>
> > > >>> Luis
> > > >>>
> > > >>>
> > > >>>
> > > >>> _______________________________________________
> > > >>> controller-dev mailing list
> > > >>> controller-dev@...
> > > >>> https://lists.opendaylight.org/mailman/listinfo/controller-dev
> > > >>>
> > > >
> > > >
> > > > --
> > > > *David Bainbridge* |Principal Architect |<www.ciena.com>
> > > > _dbainbri@... <mailto:dbainbri@...>_ | 3939 North 1st
> > > Street |San
> > > > Jose, CA 95134 USA
> > > > Direct +1.408.904.2103 |Mobile +1.978.835.0771 |Fax +1.408.904.2103
> > >
> > > --
> > > Giovanni Meo
> > > Via del Serafico, 200 Telephone: +390651644000
> > > 00142, Roma Mobile: +393480700958
> > > Italia Fax: +390651645917
> > > VOIP: 8-3964000
> > > “The pessimist complains about the wind;
> > > the optimist expects it to change;
> > > the realist adjusts the sails.” -- Wm. Arthur Ward
> > > IETF credo: "Rough consensus and running code"
> > > _______________________________________________
> > > controller-dev mailing list
> > > controller-dev@...
> > > https://lists.opendaylight.org/mailman/listinfo/controller-dev
> > >
> >
>
> --
> Giovanni Meo
> Via del Serafico, 200 Telephone: +390651644000
> 00142, Roma Mobile: +393480700958
> Italia Fax: +390651645917
> VOIP: 8-3964000
> “The pessimist complains about the wind;
> the optimist expects it to change;
> the realist adjusts the sails.” -- Wm. Arthur Ward
> IETF credo: "Rough consensus and running code"
>