Bug 1314714

Description of problem:
When having a Manager foreman Host that is also a Content Host, an attempt to update content view (and quite expected-ably also lifecycle environment) really updates content view / l.e. for the katello_system. But it does _not_ update the same for candlepin.

This leaves candlepin and foreman DBs (or it's katello part) out of sync, having fatal consequences following this user scenario:

- have some managed hosts in some content view
- wanting to migrate them to a new CV
- doing so via foreman Hosts
- this updates katello_systems in foreman DB but leaves candlepin consumers in old environment(*)
- deleting old content view
  - this passes since katello has no content host there
  - candlepin environemnt is deleted - including all consumers it has
    - more nasty is, due to bz1306628, you wont see details about deleted consumers
- now you have systems with a record in katello but not in candlepin
- getting 410 gone errors
- the usual reaction is to call clean_backend_objects rake script that deletes the systems also from katello

(*) explanatory note: candlepin environment is a pair lifecycle env. and content view, i.e. cp environment 3-15 means l.e. of id 3 and c.v. of id 15. cp environment 1 stands for 1-1.

Version-Release number of selected component (if applicable):
Sat 6.1.7

How reproducible:
100%


Steps to Reproduce:
1. Have a Managed Host being also a Content Host (just register it via subscription-manager) - ideally ensure the Host is crated in some nondefault content view and lifecycle environment
2. Use this trivial script to check:

name=pmoravec-test2.sysmgmt.lan

if [ $# -gt 0 ]; then
	echo "using name $1"
	name=$1
fi

su - postgres -c "psql foreman -c \"select uuid,name,environment_id,content_view_id from katello_systems where name = '${name}'\""
su - postgres -c "psql candlepin -c \"select uuid,name,environment_id from cp_consumer where name = '${name}'\""

3. Call the script with argument of FQDN of the Host
4. Edit Host and update Content View (alternativelly, update lifecycle environment)
5. Call the script again
6. Optionally, delete the old content view and try to update the Content Host (i.e. enable some another repo).


Actual results:
3. shows matching katelo and candlepin info about content view / l.e., like:

                 uuid                 |            name            | environment_id | content_view_id 
--------------------------------------+----------------------------+----------------+-----------------
 b66408f6-afd7-4f82-9595-024e8cd16a7f | pmoravec-test2.sysmgmt.lan |              2 |               3
(1 row)

                 uuid                 |            name            | environment_id 
--------------------------------------+----------------------------+----------------
 b66408f6-afd7-4f82-9595-024e8cd16a7f | pmoravec-test2.sysmgmt.lan | 2-3
(1 row)

5. shows a difference - candlepin DB _not_ updated!

                 uuid                 |            name            | environment_id | content_view_id 
--------------------------------------+----------------------------+----------------+-----------------
 b66408f6-afd7-4f82-9595-024e8cd16a7f | pmoravec-test2.sysmgmt.lan |              2 |               4
(1 row)

                 uuid                 |            name            | environment_id 
--------------------------------------+----------------------------+----------------
 b66408f6-afd7-4f82-9595-024e8cd16a7f | pmoravec-test2.sysmgmt.lan | 2-3
(1 row)

6. (optional): candlepin 410 gone error seen, cp_consumers lacking the Content Host (run the script again to see)


Expected results:
5. to show "2-4" or whatever to match pair environment_id - content_view_id

6. no candlepin error, cp_consumers having the Content Host


Additional info:
workaround:
whenever updating a Host that way, update the content host the same - via hammer since webui does not this ability. I.e. updating host to content view id 6, call:

hammer> content-host update --content-view-id 6 --organization-id 1 --name pmoravec-test2.sysmgmt.lan

Reasoning: though it seems to be a redundant step (since katello has updated its db already that way), the routine behind that _will_ call also candlepin udate properly.

This workaround can not be done via WebUI since WebUI will show you proper content view already - and it cant force overriding the _same_ values here.