Hide Forgot
Description of problem: In general, 2 provider accounts (for same provider) can see different realms. When realms are rescanned by calling Realm.scan_for_new, this method fetches realms only from first provider account. All accounts should be used.
adding to ce-sprint-next
adding to ce-sprint
removing ce-sprint-next tracker
taking off ce-sprint-next..
"In general, 2 provider accounts (for same provider) can see different realms." Is this actually true? If this is the case, not only do we need to scan in each account, but we'll need to update our realm model to scope it to provider accounts (rather than providers) This will make the realm mappings even more confusing than it already is. If we do need this model change, we'll need to decide whether we just consider each provider account to have its own realm list (simpler model, but then realm mappings must be defined for each account separately), or do we keep the realm-to-provider association but also add a provider_accounts association to indicate what accounts they're valid for -- and add this to the matching algorithm. This would keep realm mapping UI as-is, but it will make it more confusing when a user chooses a realm that doesn't match due to provider account mappings.
So, if we decide to fix this now, we should do something like the following: 1) the fundamental association of provider realm to provider stays the same (i.e. we don't duplicate the list for each user) 2) the conductor -> provider realm mapping stays the same (since the notion of one realm list per provider doesn't change) 3) we add an additional association of Provider Realm to Provider Account -- the intention is that for each provider account, there's an association to realm for each one that the account has access to. 4) in instance.matches, we filter realm by provider account -- i.e. when getting realm match from conductor realm, and realm mappings that specify realms not linked to the provider account are filtered 5) fix scan_for_new to check all accounts and update overall Provider realm list _and_ account-realm list So, in effect, if we have only one provider account in a provider, every provider realm will be linked to both the provider and the one account. If we have 2 provider accounts, then the provider realm list is all realms that are listed for at least one provider account. When scan_for_new runs, it rebuilds the list -- scanning all provider accounts, updating both associations and removing a realm when it's no longer listed on any provider account. We also need to run scan_for_new when adding or removing a provider account.
(continuing task list) 6) add scan_for_new list prior to matching instance to handle permission changes since import
re 6): would be time expensive, because scan should done for all providers/provider accounts. Maybe we could just expose Realm.scan_for_new through API and admins can schedule refreshing of realms in cron themselves (for 1.0 release)
point 6) is related to this bug: https://bugzilla.redhat.com/show_bug.cgi?id=717987 automatic re-scan or scan before an instance launch will probably solve BZ 717987 too.
Patch on list here: https://fedorahosted.org/pipermail/aeolus-devel/2012-January/008273.html I'm not sure point 6) is resolved by re-scanning for realms unless we also add a 'status' field to realms -- i.e. we don't want to remove a realm from our database if it's only temporarily unavailable (which seems to be what 717987 is about) -- but this depends on deltacloud returning the full list of realms with temporarily unavailable ones tagged differently -- not sure if that's done, but if so that's another bug anyway.
*** Bug 717987 has been marked as a duplicate of this bug. ***
Patch pushed at commit d95ea3770bb0fb6126fb7eb9d2316d731516b2ad Also note that 717987 is not a duplicate of this -- it's already been reopened, so I'm not sure if there's anything else needed to do there, or if re-opening that bug removes its listing as a duplicate.
d95ea37 in aeolus-conductor-0.8.0-17
I cannot verify this with rhevm as there is no way to limit the view of realms on rhevm. Currently the rest api is only available to users with admin role (thus being able to see everything). I saw on the rhev-tech mailing list (although I can't find the post) that this apparently will be addressed soon, 3.0.2 maybe? Additionally, I also ran into these rhevm issues that feeling this out... bug 794906 -- no storagedomain status in rhevm rest api (eventually dc should query it when search for valid images) bug 752515 -- storage pool manager fails to fail over
cant test this.. rhevm and vsphere dont offer the ability to limit realms