Bug 766687 - Update/Upgrade process needs to be addressed and documented for any zStream errata and for next release
Summary: Update/Upgrade process needs to be addressed and documented for any zStream ...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: doc-Identity_Management_Guide
Version: 6.3
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Deon Ballard
QA Contact: ecs-bugs
URL:
Whiteboard:
Depends On:
Blocks: 736854
TreeView+ depends on / blocked
 
Reported: 2011-12-12 15:03 UTC by Jenny Severance
Modified: 2012-06-21 23:17 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-06-21 23:17:46 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Jenny Severance 2011-12-12 15:03:55 UTC
Description of problem:

The process for yum update and upgrading to the next IPA server release needs to be addressed and documented.

Like "Does it / Should it require an 'ipactl restart'"?


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


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Rob Crittenden 2012-04-02 12:42:31 UTC
Pick one of your masters.

# yum update ipa-server

This in itself will update this IPA server instance
Restart of IPA services should be automatic
Schema upgrade should be automatic
It may take a minute to apply the package update while changes are applied

Enrolled clients do not need new packages installed. The only thing it might do is pull in any new dependencies, but it won't otherwise change enrollment. So, for example, it might pull in an updated certmonger that has fixes.

You can upgrade masters one at a time but new features will not be available on those masters not upgraded yet. The updated schema will appear on all masters, updated or not.

Our expectation is that customers will upgrade servers within a relatively short timeframe (not weeks). It does not however, need to be a tightly coordinated "ok, every press enter...NOW" sort of affair.

Comment 5 Deon Ballard 2012-06-21 23:17:46 UTC
Closing.


Note You need to log in before you can comment on or make changes to this bug.