Remove Capsule Images from Upgrade

[jyejare]

Yes! You read that subject right!

I know its hard to digest the $subject because of this path-breaking issue. But, there are a few reasons behind:

1. The capsule is nothing but just a content host to balance the load.
2. The Content-Host/VM/Capsule can be created on the fly during Upgrade through snap-guest/libvirt python library using the rhel7 image on libvirt1. (Just as robottelo doing for capsule testing)
3. The current implementation of keeping capsule images in RHEVM eating almost the same quantity of resources as the satellite does. (ram, disk etc)
4. Remove capsule dependency on RHEVM will save good quantity of RHEVM resources, to be utilized by needy.
5. Creating instances from libvirt images should be time-consuming. (subject to capsule scenario, described below).

To support and verify the 5th point, the capsule scenario needs to be / will be added in Upgrade Scenarios which should clear the statistics(of using libvirt capsule on the fly) once we run it in Jenkins.

Capsule Upgrade Scenario:

Scenarios:
  Steps:
    1. Before Upgrade, Register and install capsule VM spawned on libvirt1.
    2. Push TO_VERSION contents to the capsule.
    3. Upgrade Satellite.
    4. Post Upgrade, Upgrade the capsule.
    5. Verify if the capsule has the latest version.

[ntkathole]

I think, we can miss some issues such as capsule sync or capsule update/upgrade.

• It can be possible that capsule sync may not work due to old repositories synced before in previous satellite versions but now deleted.

• Number of packages are dependant on RHSCL/tools repo. There are chances that packing issues may not face from 6.4 -> 6.5 upgrade only, some are reproducible only when upgrade path is 6.3 -> 6.4 -> 6.5.

• Some issues may only face due to enabling some features on capsule. ex: https://bugzilla.redhat.com/show_bug.cgi?id=1621134

[vijay8451]

• Agree with Nikhil's on point , as some are the issue only reproducible/occur when upgrade path is 6.3 -> 6.4 -> 6.5.

[jyejare]

I think, we can miss some issues such as capsule sync or capsule update/upgrade.

* It can be possible that capsule sync may not work due to old repositories synced before in previous satellite versions but now deleted.

Isnt that a bug ? There are higher chances of that happening everytime we upgrade and has repositories deleted.

* Number of packages are dependant on RHSCL/tools repo. There are chances that packing issues may not face from 6.4 -> 6.5 upgrade only, some are reproducible only when upgrade path is 6.3 -> 6.4 -> 6.5.

Looks reasonable. Still how much gain we have over the implementation of this issue?
If the packaging issue is known and repeatable, can we overshadow this ?

* Some issues may only face due to enabling some features on capsule. ex: https://bugzilla.redhat.com/show_bug.cgi?id=1621134

I dont see how it is related having a capsule on the fly, Need more info.

[san7ket]

NACK , writing multiple test cases is unnecessary , if we have a single image ready with contents, features.

[jyejare]

Let's forget about the test-case, we can replace the current implementation with on-the-fly capsule this way.

Remember, this will save resources on RHEVM1 where we are struggling now.

Note: This is just a debate and 'No Hard Feeling'. Lets keep talking.