Bug 773403

+++ This bug was initially created as a clone of Bug #767382 (which is now a documentation bug) +++

Description of problem:
======================================
This has been around for a while and is related to the following bugs:
    bug 747645 
    bug 752460

I incorrectly discerned that this was caused by mapping a realm to a provider realm and a provider itself.  I was thinking the issue was bug 752460 but after further testing, that is not the case.

The issue, for whatever reason, causes deployments to fail when a realm for a rhevm provider is created, mapped back to the provider, and then mapped to a (rhevm cluster) realm.

If you change the sequence, which is how I was configuring my realms, you do not see this error on deployment... create a realm, map it to a (rhevm cluster) realm, and then (optionally, usually I did not) map it back to the provider itself.

--- Additional comment from dajohnso on 2011-12-13 17:39:14 EST ---

Created attachment 546430 [details]
ss error

--- Additional comment from jprovazn on 2011-12-19 10:52:19 EST ---

It's not necessary to set mapping both to backend realm and provider. If there are multiple mappings, conductor chooses first possible - this is the reason, why it works if you define firstly mapping to data center and then to provider and why it doesn't work if provider is defined first.

If realm is mapped to a provider, Conductor sends empty realm to DC API which should choose valid default value. ATM DC API chooses first one, which is not always valid in all cases.

For release 1.0 conductor user (admin) only mappings to backend realms are valid (not mappings to providers). I updated "rhevm setup" wiki page where were wrong instructions.

--- Additional comment from slinaber on 2012-01-10 17:03:05 EST ---

Blindly setting this to ON_QA in the belief that a fix is included in the latest aeolus packages.

--- Additional comment from dajohnso on 2012-01-11 09:03:44 EST ---

Re-opening this...per Jan's comment 2...'For release 1.0 conductor user (admin) only mappings to backend realms are valid (not mappings to providers)'

If its not supported then it shouldn't be a enabled button because it has caused a bunch of confusion.

--- Additional comment from whayutin on 2012-01-11 09:35:47 EST ---

Angus we need to get on the phone regarding this bug.. need some sanity around front end realms

--- Additional comment from sseago on 2012-01-11 12:08:08 EST ---

It sounds like from the bug description that we're still mapping to RHEV providers without realm -- this only works for RHEV if the RHEV datacenter is configured with a sane default cluster. In practice, I understand that we shouldn't expect this -- and as such, for RHEV we should always map to a back-end Realm (i.e. clustet), _not_ to just a datacenter/provider.

From the description:

    The issue, for whatever reason, causes deployments to fail when a realm for a
    rhevm provider is created, mapped back to the provider, and then mapped to a
    (rhevm cluster) realm.

    If you change the sequence, which is how I was configuring my realms, you do
    not see this error on deployment... create a realm, map it to a (rhevm 
    cluster) realm, and then (optionally, usually I did not) map it back to the  
    provider itself.

So the way realm mappings work, you can either map to a provider in general (i.e. let the provider pick its local realm), or to a provide realm (i.e. launch on a particular provider with a particular realm (cluster for RHEV) specified.

So there are two problems here:
1) you're creating two mappings -- one to the provider in general (i.e. I want this provider, don't care about cluster) and one to a specific cluster. This is not doing what you expect it to do. This is telling conductor that these are two valid paths -- conductor is free to pick one for you -- either the "datacenter; no cluster specified" mapping, or the "datacenter; this particular cluster specified" mapping.
2) for RHEV, we always want to specify a cluster (unless you know the provider has a default set) -- so when you choose a mapping without specifying a cluster (and a default isn't set), launches will fail if conductor uses this mapping to launch.

So, from what I understand from the way this was set up, what you're trying to do is set a realm mapping to a particular RHEV cluster -- so the solution is to do _just that_ -- i.e. map to the cluster you want to map to. Don't create an additional non-cluster-specific mapping because, for RHEV at least, it won't work.

For ec2, you have a choice -- if you map to a provider (us-east-1), then when conductor uses this mapping, no realm (availability zone) will be specified. If you map to a realm (us-east-1/availability zone us-east-1a), then the us-east-1a availability zone will be chosen on launch. But again, you probably don't want to choose overlapping mappings this way, as this will result in, potentially, some instances launched with the realm set, and some without.

--- Additional comment from sseago on 2012-01-11 12:12:36 EST ---

One further comment:

   If its not supported then it shouldn't be a enabled button because it has
   caused a bunch of confusion.

It's enabled because it may sometimes be valid (if RHEV is configured with a sane default cluster), and it's enabled because other providers _do_ support this sort of thing.

A longer-term fix is in the works where the UI will make the workflow clearer (even when mapping to provider without realm is supported, creating overlapping mappings like this -- i.e. one mapping to realm and another to the provider -- is probably not what you want.

It's been decided that for now, we should handle this via documentation.

--- Additional comment from athomas on 2012-01-11 12:32:17 EST ---

Wes,

Do Scott's updates provide the required information?

For 1.0, the expected functionality should be defined in docs.

--- Additional comment from sseago on 2012-01-11 12:48:08 EST ---

One additional bit of information. In talking to mfojtik, it looks like we may be able to solve the problems associated with launching in RHEV without specifying a cluster. If we can solve this at the deltacloud level, the errors seen in this bug won't happen.

However, even doing that, the original situation of defining a mapping to provider and a _second_ mapping to cluster won't produce the  desired result. Conductor will probably use the first-defined mapping to provider (which, after the deltacloud fix will work rather than causing an error), and the cluster mapping will not be used (since an earlier match was found) -- the end result is the instance won't launch in the cluster identified in the cluster mapping. If it's important to launch in a specific cluster, then you should define _only_ the cluster mapping, not the provider mapping.