Bug 126152

One can kickstart a system through an RHN Proxy only if the system is
previously registered and going through an RHN Proxy. If you try to
kickstart a box you should see a checkbox that says: "Preserve RHN
Proxy Config". If the box did not previously go through an RHN Proxy
you will not see this option.

There is a bug/feature opened for a dropdown box to choose/change the
hostname/IP a box connects to.

So... the question I have is: Did this machine previously go through
an RHN Proxy?

Wow... this bug is 3.5 months old. Sorry Greg. I will make a point of
abusing someone for you.

Changing this bug to be the bug referred to in comment #1 (a dropdown
bug didn't already exist).

It appears that the underlying problem is that the user isn't able to
choose which proxy to kickstart off of.

If the org has RHN proxies, a dropdown list for RHN proxies should
come up during the kickstart process for a particular system:
Systems-><machine link>->kickstart->Continue

(https://rhn.redhat.com/network/systems/details/kickstart/options.pxt)

The dropdown should show up regardless of whether or not the system
itself was registered through a proxy.

Bear in mind that only newer (>3.2?) proxies report the information
required for us to do this.

Fixed in CVS.

Test plan:

1) Test this feature with an org that has provisioning and at least
two proxies.
*Note*  It is probably wise to test this with an org with a 'proxy
chain' - ie, client -> proxy1 -> proxy2 -> hosted or sat

2) Kickstart a system.  You will notice that instead of the 'preserve
proxy configuration' checkbox, there will be an 'RHN Proxy' selectbox.
 It should default to whatever proxy the system is currently using, or
'None' if the system is not currently connecting through a proxy.

3) Check to ensure that the system connects through the specified
proxy after kickstartting.

4) Repeat steps 2-3 with various selections to ensure that systems
kickstart properly (ie, 'no proxy', a specific proxy, a proxy that is
part of a chain, etc)

5) Kickstart several systems via the SSM.

Notice that the RHN Proxy Configuration section has a pair of radio
buttons: 
o Preserve RHN Proxy Configuration
and
o Use RHN Proxy

The 'Use RHN Proxy' option has a selectbox next to it, very similar to
the single-system case.

The 'Preserve' option should keep each system's proxy configuration
individually - ie, if a given system connects through a proxy
pre-kickstart, it should connect to the same proxy post-kickstart.  If
it does not connect through a proxy, then it won't post-kickstart.

The 'Use RHN Proxy' option works like the one for a single system,
except that we default to 'None', since the various systems will
probably have different proxy configurations.

Doc notes:

The single system and SSM cases work as described in the test plan. 
The key thing to note about the single system option is that the
systems current proxy server, if any, should be selected by default.

The key thing to note about the SSM case is that since not all systems
will necessarily have the same proxy configuration to begin with, we
have the 'Preserve existing proxy configuration' option to keep each
system configured as it was to begin with.  The 'Use RHN Proxy' sets
the proxy for *all* the systems being kickstarted.  If the user wants
to use (for instance) two different proxies specifically for a group
of 50 systems, then he should perform two different kickstart actions
via the SSM.

Ooops - didn't notice the new documentation process until after I
wrote the above - creating bug #147144 to track the docs for this bug.

Created attachment 110649 [details]
A view of the SDC with this enhancement, no proxy selected

Created attachment 110651 [details]
A view of the SDC, a proxy is selected

Created attachment 110653 [details]
A view of the SSM, 'Preserve existing configuration'

Created attachment 110655 [details]
A viewof the SSM, with a proxy selected

There is some broken stuff here, which will be filed soon as new bugs
that block this one.

the associated docs bug was punted to the next release, RHN 400.
bug 147144

Moving this back to 'MODIFIED', because the only outstanding issue is the link
to the CA SSL cert docs, and taw was complaining about this bug still being in
FAILSQA.

This bug and it's children are all 'ON_QA', *except* for the caveat that the
links to the docs page does not yet exist.

Initial setup:

rhnblade4 -> rhnblade3 (proxy) -> webqa
rlx-2-14 -> webqa

Tests performed:

0.  Verify that kickstarts through the Proxy require the SSL key to be
    associated in the kickstart profile -- PASS

1.  kickstart rhnblade4, through the proxy -- PASS 
2.  kickstart rlx-2-14, through the proxy -- PASS
3.  verify that the kickstarts are touching the proxy -- PASS

4.  make sure both systems have proper upstream connections post-kick
-- PASS
5.  verify that rlx-2-14 is now going through the proxy for everything
-- PASS

5.  kickstart both simulatenously through the SSM, through the proxy
-- PASS
6.  verify upstream connections are correct post-kick -- PASS

modify the configuration so that one box goes through the proxy and
the other
doesn't

8.  use SSM to kickstart, testing the Preserve Configuration option --
FAIL

9.  schedule the installation of a second proxy -- PASS
10. verify that both RHN-ORG-TRUSTED-SSL-CERTs are in hosted -- PASS

Note that test #8 failed -- another bug will be opened on this that
blocks this bug.

another item verified working:

system registered directly to webqa
choose to kickstart, selecting to kick through a proxy
system comes back connected to the proxy, able to talk through the
proxy to hosted.

Children are all PROD_READY again, all the tests above (in comment
#15) now pass, along with a two-level proxy chain to a satellite.

PROD_READY

mass move: PROD_READY --> CLOSED:CURRENTRELEASE