RFE Request

Guess I should be more specific. On the "systems" page, if a given system has at least 1 update available that requires a restart. An icon there would tell me a general "this system needs to be patched AND rebooted". I think on a "system" level, not really a patch level.

Patch sets that we can build ourselves would be really nice as well. Create a patch set called "nfs" or something, then place only nfs related patches in there. Or a set called "no reboot required" then place patches in that set and apply to a given set of systems.

dyoung2 at 2007-7-6 13:29:26 >

Sort of.. Filters like that would certainly be nice. Perhaps product related (directory, messaging, etc) or patch specific (C library, LDAP client, 108993-*, etc). In this case, I'm thinking of more of a collection of patches.

Say I have 4 systems, 2 test and 2 production. Let's also assume that these 4 systems are either exactly the same, or extremely close (all loaded with SUNWCall let's say).

At a given point in time all of these system need a given number of patches. On a certain day, "capture" the patches required on all the systems and group them into what I've called a "patch set". I can then apply this "set" to the test systems first and let the QA people run the apps through the works.

Now, say this takes 2 weeks at which time the production systems would need newer patches. Technically, I should only install the patches that have been through test into my production environment. I could then take that previous "set" that is known to be working and simply apply it to production. The next step would be to take the test systems, create a newer set and start the process all over.

Really comes down to an easy way to group, approve, test and apply a given patch (or several patches). Ideally, I only want patches that have been tested applied to production systems.

dyoung2 at 2007-7-6 13:29:26 >

If you have dissimilar systems but all with the same cluster , OS, and update you can still use this methodology to accomplish your goals while they are working on a feature in update connection.

You should be aware that even HW of the same model can have dissimilar components within so this works well for all boxes to assure each is fully patched.

smpatch download on all your dev/test/prod systems the same day. This should use the same patchdb so all your revisions will be the same across all the boxes.

then patch each set of boxes on the dates you desire using the patch list provided by the download (already ordered for you).

this will assure your boxes are patched with HW specific patches and still assure common patches are the same revision across all boxes.

I use this effectively in our environment and without issue.

jwbledsoe at 2007-7-6 13:29:26 >

I beleive that this thread was actually for a different issue and that the one in which you meant to post in is linked below -

http://forum.sun.com/thread.jspa?threadID=25524

However, looking over the CR indicates that there are on-going discussions as to whether it will be possible to include this functionality or not but that there are concerns over how it will impact performance and bandwidth upstream. As such no decision has been made as of yet on whether it will be introduced or not.

ForumModerator at 2007-7-6 13:29:26 >

To clarify my previous post -

CR 6305782 is for an issue that was discussed in the following thread - http://forum.sun.com/thread.jspa?threadID=25524

This thread was discussing the issue of how patches are marked as requiring reboot and how it would be usefuly to have this represented at the system level. For this RFE 6326553 was raised.

Currently RFE 6326553 is with the development team for consideration to be inculded in future releases.

ForumModerator at 2007-7-6 13:29:26 >