Support custom PVC, default domain home and default log home

[doxiao]

1. Default domainHome to /shared/domains/domainUID
2. Default logHome to /shared/logs/domainUID
3. Support custom pvc
4. Support shared pv/vpc - added a new input property for pv/pvc base name
5. Decouple the output location of the pv/pvc, domain, and load balancer scripts
6. Modify the integration test code to work with the new samples - did not change the test logic, which means we still have one pv per domain.

Note: currently there is an intermittent issue in the integration test with the changes.

Item #1 and #2 are based on the following summary in the slack channel on 10/12/2018.

Tom Moreau [11:35 AM]

Here's a summary of our domain pv decisions (I ran this by Ryan this morning):

1. the architectural statement (which does not imply large amounts of work for 2.0): previously, we were focused on one pv per domain. now we're going to shift the focus - instead of encouraging one pv per domain, we're going to say that the customer creates a pv and can put one or more domains on it (just like the customer can create a namespace and put a bunch of domains in it) that is, we're going to say that it's a common use case for domains to share a pv, and we should change the operator runtime and samples to reflect this.
2. this has implications in the default values on the domain resource domain home - if the domain home is on a pv (we have a switch for this), then the default domain home path will be /shared/domains/<domain-uid> (instead of /shared/domain) log home - the default will be /shared/logs/<domain-uid> (instead of /shared/logs)
3. this has implications on the create domain samples today we have one sample for creating the pv and other samples to put a domain home on the pv. they currently put the domain uid in the pv name (i.e. encourage one domain per pv). instead, we should modify the sample for creating the pv to not put the domain uid in its name. if a tire kicking customer wants one pv per domain, then they just run the sample to create the pv, and then a sample to create the domain home - they don't change any of the input values. if the customer want to add more sample domains to the sample pv, then the customer just runs the create domain sample script again, passing in an inputs file that changes the domain uid
4. use case wiki (that I'm working on) - I'll separate out the use cases for creating the pvs from the use cases for creating domains that use them.

@anpanigr @vanajamukkara @maggiehe00

[vanajamukkara]

Please see the note, this change has to wait until the intermittent issue is resolved.
Note: currently there is an intermittent issue in the integration test with the changes.

[tbarnes-us]

The overall change LGTM.

I'm OK with it is now, but wonder if there should be additional discussion about:

• Whether the 's' should be added to /shared/domain to make it /shared/domains. I just don't recall there was general agreement there.
• Whether a sample domain-home path should end with the domain-uid or with domain-uid/domain-name. The WL convention seems to be that the top level directory of a domain tends to match the domain name. I know it seems redundant, but I wonder if we should keep doing it for clarity? In this change /shared/domain/ becomes /shared/domain/<domain-uid>/<domain-name>. OTOH, we hope to someday provide the ability to override the domain-name, in which case it'd be confusing to put the name in the path...

[doxiao]

The overall change LGTM.

I'm OK with it is now, but wonder if there should be additional discussion about:

* Whether the 's' should be added to /shared/domain to make it /shared/domains.   I just don't recall there was general agreement there.

See the newly added notes in the description.

* Whether a sample domain-home path should end with the domain-uid or with domain-uid/domain-name.   The WL convention seems to be that the top level  directory of a domain tends to match the domain name.   I know it seems redundant, but I wonder if we should keep doing it for clarity?  In this change /shared/domain/ becomes /shared/domain/<domain-uid>/<domain-name>.   OTOH, we hope to someday provide the ability to override the domain-name, in which case it'd be confusing to put the name in the path...

Just to be clear. The change in this PR defaults the domain home to /shared/domains/domainUID (no /domainName). I believe you are proposing adding /domainName to the path. I believe that this has been brought up and discarded in the slack channel when the proposal (in the description) was discussed.

[doxiao]

There are problems after sync up with the latest develop branch. Looking.

[doxiao]

There are problems after sync up with the latest develop branch. Looking.

The new issue in integration test has been resolved.

[doxiao]

Passed the full Java integration test locally and on Jenkins http://****/job/weblogic-kubernetes-operator-javatest/224/.