Oracle Big Data Compute Service: Unable to create service

When creating a new instance of the Oracle Big Data Compute Service I faced the following error message:

Unable to create service, please check log file to get the real cause.

So far the reason is unknown. The same request was working using another account (provisioned in Europe, not in the US), so I assume it is somehow related to the account settings.

I escalated this issue to Oracle and they are working on it. Once there will be more news of course I will post the solution here.

When implementing a PaaS service you should make make sure:

  • to provide meaningful error messages. Tell the user WHY something is not working.
  • make sure people if your PaaS really provides a log file and how to access it

Application Container Cloud Service (ACCS): Invalid Subscription. Please contact oracle support.

This error messages shows up with the Application Container Cloud Service (ACCS) if you did not set the replication policy for the Oracle Storage Cloud Service. Actually I remember that there was a time when the solution how to fix the issue was not included.

ACC Error. Oracle Cloud

Now we are better off, just read the documentation included in the error message link, or see below:

Should this happen? Here is my take (in progress).

Good news is, that you can fix it easily by setting the replication policy for the Storage Service.

Storage Container Name: Conflicting Syntax for Storage Container Names in Oracle Big Data Service Compute Edition

I already presented and published how to get Oracle Java Cloud Service to work, but it seems that a little help for Big Data Service Compute Edition can be useful as well.

One showstopper is the Storage Container Name. If you check the documentation it says you have to provide the REST URL:

Storage Container Syntax (Big Data Cloud Service Compute Edition)

On the cloud console however it says that you should use the Syntax that is known from JCS or DB as a Service:

Name of an Oracle Storage Cloud Service container of the form Storage-IDDomain/yourChoiceOfContainerName. e.g: storagesvc999-usoracleaccoutrial00999 /backupContainer; If not already created, you must create the container following the Oracle Cloud Storage documentation.

In this case the documentation is wrong. The following format is correct:

Storage-IDDomain/yourChoiceOfContainerName

Oracle Storage Service: Geo Replication – you must set this!

Configuring the Oracle Storage replication policy should be step number zero if you start in the Oracle cloud with any service. I cannot stress this often enough. Many services such as DB as a service or Java Cloud service will not work without it. Even ACCS – a much newer and higher level PaaS service – will not work unless you set this storage policy.

  • For now: go and set the policy. I got into all kind of trouble trying without. Trust me, you won’t have the time for this.
  • To make cloud services such as JCS or ACCS work it is not so much important how you set the replication policy, it it just important that you set it. Functionally of course, there is a big difference if you data will be replicated asynchronously to another data center or not.
  • IMHO this could be improved by Oracle to improve the overall OPC customer experience. There is no reason why there could not be a default value, that makes other PaaS services work correctly.

Oracle Cloud: Set Storage Replication Policy

From the official Documentation

Guidelines for Selecting a Replication Policy
Read these guidelines before selecting a replication policy.

Oracle provides several replication policies. Broadly, they belong to one of the following types:

  • Policies that have no georeplication: These policies specify only the primary data center (DC) that hosts your service instance.All read and write requests go to the primary DC, always. If the primary DC is unavailable, then the requests fail. Such a policy may be adequate if you have standard data-durability requirements and if an occasional failure of read requests (when the primary DC is down) is acceptable.
  • Georeplication policies: These policies specify a primary DC that hosts your service instance as well as a geographically distant, georeplication DC.Write requests that you send to the global namespace URL are routed to the primary DC. Data that you write is replicated automatically, but asynchronously, to the georeplication DC. The primary and secondary DCs are eventually consistent. If the primary DC is unavailable, then write requests fail with the 403 — Forbidden error, but read requests are routed to the georeplication DC. When the primary DC is available again, requests to the global namespace URL are routed to the primary DC. You’ll be billed for the sum of the capacities used in both DCs and for the data transfer from the primary to the georeplication DC. A policy that has a georeplication DC is ideal if you have advanced durability requirements for your data or if read requests must succeed always regardless of the state of the primary DC.

For faster data transfer between your other Oracle Cloud services and Oracle Storage Cloud Service, consider selecting a policy with a primary DC that hosts your other services that use Oracle Storage Cloud Service the most. When selecting the replication policy for your service instance, keep in mind any security, legal, and regulatory requirements that may apply to your data.

OSB 12c (12.2.1.2) More Maven Issues and Solutions

Existing Bugs and Issues with Maven and OSB 12.2.1.2 and How to Fix Them

It is a well known fact that Maven in OSB 12.2.1.1 came with glitches that required manual fixes as described in Robert Patrick’s blog posting and in the Oracle support notes Doc ID 2186338.1. However, this article is centered around the latest OSB 12.2.1.2, its particular Maven issues and how to fix them. Same as version OSB 12.2.1.1 also 12.2.1.2 suffers from various maven glitches, however in a more subtle way.

[Note, that I usually don’t post references to MOS, since not everybody has access to it. Anyway, if you cannot access to Doc ID 2186338.1 don’t worry. It basically describes what Robert writes about in his blog. In addition it recommends actually not to fix it manually, but instead wait for a patch. I actually I agree. Also note that as of OSB 12.2.1.2 this issue is not marked as fixed although the behavior of the newest version is different.]

The current situation with OSB 12.2.1.2 and Maven is “interesting”, to put it mildly:

  • mvn with OSB 12.2.1.2 and the maven push plugin only will not work out of the box. This means the official documentation won’t help you in this case. The good news – despite the fact that mvn with OSB 12.2.1.2 is not working correctly – is that it is rather easy to fix manually (see below, Fix 1: Maven with OSB 12.2.1.2 and the mvn push plugin).
  • Also mvn with OSB 12.2.1.2 and maven.oracle.com will not work (as of Jan 7, 2017). Since the required .pom and .jar files are pulled over from maven.oracle.com and several of them are missing it is obviously not easy to fix it yourself.
  • Here comes the crazy part (well, crazy on an IT scale): if you configure both, i.e. first use the OSB Maven plugin to push from an OSB 12.2.1.2 ORACLE_HOME into the .m2 repository, and then in addition configure the maven.oracle.com repository, then it is done twice. Yet then also both issues cancel each other out.

 

Here are the fixes, as promised

Fix 1:Maven with OSB 12.2.1.2 and the mvn push plugin

a) easy manual fix, updating two lines in two files:

After usign the push plugin, in .m2 Repository, e.g. D:\Users\frank\.m2\repository\com\oracle\servicebus\sbar-system-common\12.2.1-2-0 change the file sbar-system-common-12.2.1.2.pom as follows:

under

    <parent>
         <groupId>com.oracle.maven</groupId>
         <artifactId>oracle-common</artifactId>
         <version>12.2.1-1-0</version>
     </parent>

change the version tag to <version>12.2.1-2-0</version>

also for the file sbar-project-common-12.2.1.2.pom in the directory
.m2\repository\com\oracle\servicebus\sbar-project-common\12.2.1-2-0 change the version number the same way.

b.) Install patch 22392646

This is the second, alternative option to fix the issue. Install patch 22392646 from My Oracle Support. After a lengthy and tiring discussion I had with support it is now also applicable to OSB 12.2.1.2. – voilà! Depending on your provisioning approach this might be the easier fix, but actually you could just copy over the files (or even run sed on those two files).

 

Issue 2: Maven with OSB 12.2.1.2 and the maven.oracle.com

There is no known fix at the moment, maven.oracle.com is missing a whole lot of files (again) and also some of those delivered are wrong again. Bug 23698828 describes a very similar issue, yet reports it as fixed for 12.2.1.1. Oracle support knows about it, so let’s hope it will be fixed soon in maven.oracle.com. I will keep you posted, promised.

Update: After the first round with support their “solution” did not work. The issue is still not fixed. If you think about it for a second, how hard can it be to push a patched .m2 repo to maven.oracle.com? Stay tuned 🙂

To conclude

You are lucky if you simply retyped all the instructions available and configured both ways to use Maven with OSB 12.2.1.2 (although I somehow guess you would have not read this article then).

As soon as you follow a clear path and either go for the push plugin on a machine with OSB installed, or maven.oracle.com on a build server without an OSB installation, you will run into issues. It is obvious that Oracle would do good with automatically testing this functionality for future releases. Not being able to browse the maven.oracle.com repo makes it more difficult for customers to debug those issues, so it might be a good idea to use a local proxy / cache.

Let me know your feedback!