Re: [kura-dev] Presentation of the Kura ConfigurationService situation

[Jens Reimann <jreimann@xxxxxxxxxx>]

So that may solve this single one issue, having duplicate services instances. It does not solve the other issues. It does not solve the issue that a Karaf user will configure stuff using the OSGi ConfigAdmin, which will then still create an inconsistent system. And it will create even more legacy code. Making the ConfigurationService even more complex.

But this could be a super-short-term solution in order to have something ready for one of the milestones.

In the end we have to make Kura more OSGi friendly. And re-implementing the whole ConfigurationAdmin (as the ConfigurationService does) because the Equinox implementation cannot be trusted is not OSGi friendly. And causes a set of issues.

So I think the correct approach is not to add more complexity in order to fix issues created by that approach in the first place. But to get rid of this complexity by sticking to the core functionality (the OSGi ConfigAdmin).

We can start this improvement during the 3.0 cycle (as the Kura configuration bundle is already a separate bundle) and work on this in parallel.

On Wed, Jan 18, 2017 at 12:25 AM, De Alti, Cristiano <Cristiano.DeAlti@xxxxxxxxxxxx> wrote:

Hi Jens,

  I've take a look to the presentation and it looks really good. It helps a lot in understanding how the Configuration Service works.

The Configuration Service is not perfect but maybe I can help to understand some of its early design decisions.

1. We didn't trust the OSGi (at least the Equinox implementation) storage area for embedded applications. I don't have a direct experience but what I've been told by the original contributors is that it can become messy or corrupted and could prevent the framework to start.

Hence the decision to always start OSGi in a clean state (osgi.clean=true).

2. This led us to find a way to persist the configurations outside of OSGi in snapshot files.

3. An special snapshot file, snapshot_0.xml, is used to provide an initial configuration which is useful also if the framework was started with osgi.clean=false but there is no configuration yet in the OSGi storage area, for example at the very first boot.

The snapshot 0 can be different for every platform and allows to not hardcode a default configuration in the components.

The Configuration Service has evolved since then to support new features and not always in the right direction. Everything can be improved.

Nonetheless I believe that reimplementing it would be an under-estimated effort.

I've discussed the Karaf issues with Marco and we can provide the following suggestions to make the Configuration Service compatible with the Karaf requirement of starting OSGi with osgi.clean=false.

 

The Configuration Service will read the value of the osgi.clean property:

a. If set to true, the Confgiuration Service nothing changes

b. If set to false and snapshot 0 is the only snapshot, the Configuration Service will behave as above but it will save a new snapshot identical to snapshot 0

c. Otherwise, if snapshot 0 is not the only snapshot, the Configuration Service will not read the latest snapshot and will assume that the configuration will be restored by the Configuration Admin from the OSGi storage area. Please note that typically Kura configures the storage area in a temporary filesystem that may be wiped out on reboot.

The path of the storage area is configurable.

The above should work in the following cases:

i. Very first boot when the OSGi storage area is clean and snapshot 0 is the only snapshot

ii. Subsequent boots when the OSGi storage area has been populated and another snapshot exists (see b above)

iii. If it happens that the storage area gets corrupted, you can set osgi.clean=true and the Configuration Service will load the configuration from the latest snapshot which should be in sync with the last working configuration of the Configuration Admin.

All this has a chance to work and maybe could be a reasonable short term solution to overcome the Karaf problems.

Ciao,

  Cristiano

---

Da: kura-dev-bounces@xxxxxxxxxxx <kura-dev-bounces@xxxxxxxxxxx> per conto di Jens Reimann <jreimann@xxxxxxxxxx>
Inviato: martedì 17 gennaio 2017 18.27.58
A: Kura Developers mailing list
Oggetto: [kura-dev] Presentation of the Kura ConfigurationService situation

 

Hi,

As agreed in today's call I am sharing the presentation of the Kura ConfigurationService situation.

This is written down as best as I could. The Karaf issue described last week is indeed an issue of the ConfigurationService and I think is well understood and discussed in today's call. So I think we can start discussions about possible solutions here.

https://docs.google.com/presentation/d/1kbb8Br8DCt_dEX43hEYDQHk_TZyeUN3M0JmRd5Zsdkg

Any additional feedback, corrections or ideas are welcome.

Some of those issues are already reported in GitHub, but I did not look up them up. I can add that later on.

Cheers

Jens

--

Jens Reimann
Senior Software Engineer / EMEA ENG Middleware
Werner-von-Siemens-Ring 14
85630 Grasbrunn
Germany
phone: +49 89 2050 71286
_____________________________________________________________________________

Red Hat GmbH, www.de.redhat.com,
Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill

_______________________________________________
kura-dev mailing list
kura-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/kura-dev

--

Jens Reimann
Senior Software Engineer / EMEA ENG Middleware
Werner-von-Siemens-Ring 14
85630 Grasbrunn
Germany
phone: +49 89 2050 71286
_____________________________________________________________________________

Red Hat GmbH, www.de.redhat.com,
Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill