A little while ago Dean blogged on the Mobility Technical Preview here. There were a number of questions around our choice of platform support, so I wanted to spell out in more detail some of our decisions, as well as some of the roadmap.
For the first release we decided to ship it on SLES 11 64 bit only. There is a technical requirement for a newer version of Python than the one that ships in SLES 10, so we decided, for the time being at least, to go with SLES 11 only. To get Data Synchronizer to work on SLES 10 we need to include the version of Python that we required, which meant there were a couple of drawbacks:
1. There could be compatibility issues with other versions of Python installed on the server, or other applications that needed Python.
2. If we shipped our own Python we would also have to maintain it, including any security fixes. This means that if a security patch is needed for Python, and we had no Data Synchronizer patch planned, then customers would need to individually download and install the RPM.
3. The newer version of Python would not be included in the regular SLES updates.
We also decided to release this first version on Postgres. This helped us half the numbers of test cases that we needed to run. Adding another platform, or database, doubles the test cases. Adding both a platform and a database quadruples the test cases that we need to run. By simplifying the architecture we can release the product quicker.
Going forwards we will expand our platform support to include Windows, as well as other databases, like Oracle, MSSQL and MySQL. We need to confirm the timelines for these, and we may stagger support for each one – as I said we need to balance the platform support options with the time it would take to release the product.
The other question that arose from Dean’s blog was around the SLES entitlement. There was a lot of discussion around the OES entitlement to SLES, so I will clarify a couple of points. The current SLES entitlement in OES does include an entitlement to SLES 11, despite OES being installed on top of SLES 10. That entitlement, however, does not include the ability to run Data Synchronizer on top of it – it only covers OES workloads and services required to support OES users, like backup or antivirus.
In addition, Data Synchronizer is not a GroupWise component. Right now it supports GroupWise users, but, as the product moves forward, it will be licensed to work outside of the GroupWise space, so the GroupWise SLES entitlement won’t cover it either.
We have been working to include a SLES entitlement specifically for the Data Synchronizer product. That entitlement was approved this week. What that means is that Data Synchronizer customers will get a SLES entitlement for as many servers as are required to run the Data Synchronizer product. There are the standard caveats – the only workload on the server can be Data Synchronizer, and it is the core services only – so if you install some externally monitoring app it cannot consume the same entitlement (as an example).
I hope that explains things a little more clearly.
Disclaimer: As with everything else at Cool Solutions, this content is definitely not supported by Novell (so don't even think of calling Support if you try something and it blows up).
It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.