On 6/2/10 10:56, Guillaume Nodet wrote:
On Wed, Jun 2, 2010 at 16:50, Richard S. Hall<he...@ungoverned.org>  wrote:
On 6/2/10 10:29, Guillaume Nodet wrote:
Wouldn't that be a problem to have ConfigAdmin pushing config updates
automatically ?

  I don't understand this question.
I mean the specs does not really assume that ConfigAdmin updates the
configuration itself, does it ?
I'm not sure if that would cause any problem.

ConfigAdmin provides an API for setting configuration data. Nothing prevents a ConfigAdmin impl from providing multiple APIs for setting the configuration data, so the zookeeper API would just be another API provided by a zookeeper-aware ConfigAdmin impl for setting configuration data, no?

The current implementation has a pluggable backend storage, but it
can't be used to push changes.  Maybe if the interface of the store is
enhanced, it would be more usable.

I thought that it did, but I am not too familiar with it. If it cannot
handle a case like this, then it should definitely be improved.
No, there's no way for the backend store to inform config admin that
some configuration has been changed in the back end store and have
config admin to propagate those changes accordingly.

Admittedly, doing this generically is probably a little trickier than just implementing a zookeeper-specific ConfigAdmin impl, but still possible.

-> richard

->  richard

On Wed, Jun 2, 2010 at 16:24, Richard S. Hall<he...@ungoverned.org>
  wrote:

Just wondering, rather than creating a bridge, wouldn't it make more
sense
to just create a new Configuration Admin implementation that uses
Zookeeper
as its back end? Or is there some other benefit to creating a bridge?

->    richard

On 6/2/10 5:17, Leen Toelen wrote:

Hi,

there are several uses cases for zookeeper, but my two goals are
- publish a service existence and parameters in zookeeper so other
services can find it (mostly an ephemeral znode is used here)
- configure service parameters centrally

I don't think zookeeper has the idea of default values, so what you
can do is create a 'default tree' with all the default values and then
a per-service tree with overrides for the defaults. This has to be
coded in however.

Zookeeper comes with a shell tool that can be used to create nodes, I
don't know if a bulk insert tool exists. There is also an eclipse
plugin that I am using at


http://www.massedynamic.org/mediawiki/index.php?title=Eclipse_Plug-in_for_ZooKeeper.

I am more than willing to contribute the initial code, where should I
put the jira ticket?

Regards,
Leen

On Wed, Jun 2, 2010 at 8:21 AM, Guillaume Nodet<gno...@gmail.com>
  wrote:


I actually find the idea very interesting.  For some time I was
considering writing an LDAP back-end but never got the time to
actually do it.
If you intend to contribute it, it might make sense to raise a JIRA
and attach it there.

I actually have hardly used zookeeper, so I have a few questions (bear
with me if they are dumb).
I guess one of the use case I have in mind is the following:  you have
several nodes, each of those is configured roughly with the same set
of things, but you want to override some values for each node if
needed.  The question is, can zookeper be used to somehow share some
data, or do you need to duplicate all the configurations.
Another question: is there any tool that could help pushing some
initial data into zookeeper ?

On Tue, Jun 1, 2010 at 13:40, Leen Toelen<toe...@gmail.com>      wrote:


Hi,

I have created a proof of concept bridge between zookeeper and the
configurationadmin service, and allows for a centralized configuration
of an osgi system. If anyone is interested in giving it a try, please
go ahead.

The managed service is created with this PID:
"org.apache.zookeeper.configurationadminbridge" and needs the
following properties
- zookeeper.hostname
- zookeeper.port
- znode

A ZooKeeper session is created on the given znode, and every znode
child is treated as a key-value pair which is synced with the
configurationadmin, much like fileinstall does. When a pid contains
'-', it is treated as a factory config.


Zookeeper structure:

/com/worlddomination/           ->      znode
- myservicepid                          ->      child service pid, with
child znodes
     - property1: value
     - property2: value
- myfactoryservicepid-test              ->      factory child service
pid,
with child znodes
     - property1: value
     - property2: value

The synchronization is one-way so every zookeeper change is pushed to
configurationadmin, but changes to configurationadmin directly are
ignored.

Regards,
Leen


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org



--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org





---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org





---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Reply via email to