Skip to content
This repository has been archived by the owner on Nov 16, 2021. It is now read-only.

rfc-183 Cloud Scope for preferences #27

Open
bjhargrave opened this issue Oct 27, 2016 · 6 comments
Open

rfc-183 Cloud Scope for preferences #27

bjhargrave opened this issue Oct 27, 2016 · 6 comments
Assignees
Labels
publiccomment Public comment

Comments

@bjhargrave
Copy link
Member

Original bug ID: BZ#196
From: @juergen-albert
Reported version: unspecified

@bjhargrave
Copy link
Member Author

Comment author: @juergen-albert

In a cluster/cloud globally available preferences become necessary. These can be used to e.g. configure database connections that are available to everybody in the cloud.

It might also be nice to provide a kind of filter mechanisms, so I can add a property and make sure, that is only visible to nodes with a certain tag. This can e.g. be useful if we have a cluster providing services to different tenets. So you can make sure, that the preferences are only available on nodes, the tenet is allowed to use and don't and on the node used by somebody else.

@bjhargrave
Copy link
Member Author

Comment author: @tverbele

It actually is possible to attach other, custom properties to a NodeStatus service, however currently only by creating your own NodeStatus provider implementation that has those properties.

Question is whether we need a mechanism that any bundle can add properties to a NodeStatus service, or whether this bundle just needs to publish his own NodeStatus service with the (extra) properties he wants to publish?

Filtering is hard - if not impossible? - to include in the spec. You can probably provide your own filtering mechanism using service hooks that hide certain NodeStatus services for other tenants.

@bjhargrave
Copy link
Member Author

Comment author: @maho7791

This bug is related to the PreferenceService.
There are currently two scopes defined, system and user.
I think what Juergen meant, was to introduce another scope 'cloud', two store cloud related preferences.

This could also mean to have a different storage for these kinds of preferences.

@bjhargrave
Copy link
Member Author

Comment author: @juergen-albert

As discussed: We have to take a closer look in the OSGi Preferences Service. We obviously messed this up with the Eclipse Preferences Service. Thus a Cloud Preference Service appears to be an RFP in and of itself.

@bjhargrave
Copy link
Member Author

Comment author: Castro B <[email protected]>

Hi Jürgen Albert is this issue has been solve already?
about the SYSTEM and user.

Castro B,
http://webtrafficgeeks.org

@bjhargrave
Copy link
Member Author

Comment author: @juergen-albert

@ Castor B No, we never took a deeper look into this topic.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
publiccomment Public comment
Projects
None yet
Development

No branches or pull requests

2 participants