Bug 819962 - RFE: Support upcoming releases of RHEL for instances in private and public providers before official RHEL release
RFE: Support upcoming releases of RHEL for instances in private and public pr...
Status: NEW
Product: CloudForms Cloud Engine
Classification: Red Hat
Component: oz (Show other bugs)
1.0.0
Unspecified Unspecified
medium Severity low
: 1.0.1
: ---
Assigned To: nobody nobody
Rehana
: FutureFeature, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-08 14:23 EDT by James Laska
Modified: 2015-08-02 20:02 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-05-08 23:00:18 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
0001-Fix-bug-819962.patch (651 bytes, patch)
2012-05-08 14:24 EDT, James Laska
no flags Details | Diff

  None (edit)
Description James Laska 2012-05-08 14:23:24 EDT
Description of problem:

Oz does not support building RHEL-6.3 at this time.

Version-Release number of selected component (if applicable):
 * oz-0.8.0-5.el6.noarch

How reproducible:


Steps to Reproduce:
1. Create a RHEL-6.3 system template, using the 6.3 Beta
2. Attempt to build an image
  
Actual results:

2012-05-08 14:19:49,420 DEBUG imgfac.builders.BaseBuilder.RHEL6_rhevm_Builder thread(e9c58c85) Message: Exception caught in ImageFactory
2012-05-08 14:19:49,421 DEBUG imgfac.builders.BaseBuilder.RHEL6_rhevm_Builder thread(e9c58c85) Message: Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/imgfac/builders/Fedora_rhevm_Builder.py", line 66, in build_image
    self.build_upload(build_id)
  File "/usr/lib/python2.6/site-packages/imgfac/builders/Fedora_rhevm_Builder.py", line 93, in build_upload
    guest = oz.GuestFactory.guest_factory(self.tdlobj, oz_config, None)
  File "/usr/lib/python2.6/site-packages/oz/GuestFactory.py", line 86, in guest_factory
    raise oz.OzException.OzException("Unsupported " + tdl.distro + " update " + tdl.update)
OzException: Unsupported RHEL-6 update 3

Expected results:

 * A successful image build

Additional info:
Comment 1 James Laska 2012-05-08 14:24:24 EDT
Created attachment 583055 [details]
0001-Fix-bug-819962.patch

Simple patch that fixes the immediate bug, but does not address the issue of future RHEL updates.
Comment 2 jrd 2012-05-08 16:09:08 EDT
Steve, this may have to wait for Ian, but can you take a look and render an opinion?
Comment 3 Steve Loranz 2012-05-08 16:41:51 EDT
This goes back to having implicit support for new versions rather than checking an explicit list.  It was discussed when the last update to RHEL5 was in beta, but I don't remember what the conclusion was. Is there a redmine feature/task related to changing this *known and currently expected* behavior? This is documented at the bottom of the "fully supported guests" section on the Oz project page at http://www.aeolusproject.org/oz.html

Also, remember that even if we implicitly support new versions of RHEL, that doesn't mean there will be a JEOS available on snapshot only configurations. This is especially true for BETA releases.
Comment 4 wes hayutin 2012-05-08 23:00:18 EDT
Agreeing w/ Steve here.
We can't fully support RHEL 6.3 as a client until there is an official ec2 ami for RHEL.

I did test the RHEL 6.3 beta ami and that worked w/ a build/push

Its not practical to have to have to update the jeos config for every beta ami we release.  We also can not support RHEL 6.3 beta on vsphere, but not rhevm or rhevm but ec2.  The current model is support it all or nothing.

That makes the following an accurate message: 
"    raise oz.OzException.OzException("Unsupported " + tdl.distro + " update " +
tdl.update)
OzException: Unsupported RHEL-6 update 3  " 
 
Which really begs the question.. is the model broken.  It sounds like a new model is still being proposed.  That is good.

RHEL 6.3 will be supported once RHEL 6.3 is released and there is a official RHEL ami.
Comment 5 wes hayutin 2012-05-08 23:03:15 EDT
I suggest an RFE be opened to cover what Steve was discussing..


" This goes back to having implicit support for new versions rather than checking
an explicit list.  It was discussed when the last update to RHEL5 was in beta,
but I don't remember what the conclusion was. Is there a redmine feature/task
related to changing this *known and currently expected* behavior? This is
documented at the bottom of the "fully supported guests" section on the Oz
project page at http://www.aeolusproject.org/oz.html "
Comment 6 wes hayutin 2012-05-08 23:35:31 EDT
OK.. changing this to an RFE myself.

The RFE is as follows.
1. Any customer or sane person would like to test out upcoming releases of RHEL before they are released.  The can include beta or RC's of RHEL.

2. New versions should be implicit rather than explicit

3. RHEL jeos ami's should default to the latest available version if the requested version is unreleased
  
  * If a customer builds a tdl for RHEL 6.3 and there was only a RHEL 6.2 ami in ec2. We could default back to RHEL 6.2 instead of throwing an "unsupported error"

  * If RHEL 6.3 was released and we did not have a RHEL 6.3 ami built and released yet, a customer could build a RHEL 6.2 ami and yum update the ami to RHEL 6.3 if the content was available in the cdn/rhui/katello

So.. I think we can get what we want if just make the "$next_version" implicit and doc the issue to have customers yum update their ami's to get to $next_version (if needed).
Comment 7 Hugh Brock 2012-05-09 10:12:24 EDT
Wes' solution is not a bad idea for an update fix -- Steve, Ian, let us know what you think, and if you think such a fix is a candidate for z-stream or is too disruptive.

In the meantime: We will continue to add support for new AMI versions and new RHEL versions by updating the config RPM with each z-stream release.

As I said to someone else the other day, customers clamoring for the ability to build the latest software with our tools is a problem I would love to have...
Comment 8 Steve Loranz 2012-05-09 10:24:37 EDT
(In reply to comment #6)
> OK.. changing this to an RFE myself.
> 
> The RFE is as follows.
> 1. Any customer or sane person would like to test out upcoming releases of RHEL
> before they are released.  The can include beta or RC's of RHEL.
> 
> 2. New versions should be implicit rather than explicit

What if we made this a configurable option? If you know what you're doing, you can turn off the check.

> 
> 3. RHEL jeos ami's should default to the latest available version if the
> requested version is unreleased
> 
>   * If a customer builds a tdl for RHEL 6.3 and there was only a RHEL 6.2 ami
> in ec2. We could default back to RHEL 6.2 instead of throwing an "unsupported
> error"
> 
>   * If RHEL 6.3 was released and we did not have a RHEL 6.3 ami built and
> released yet, a customer could build a RHEL 6.2 ami and yum update the ami to
> RHEL 6.3 if the content was available in the cdn/rhui/katello

If it was me building a template, I don't know that I'd want factory to fall back to a different version than I specified in the template. Give how long  it can take to build an image, I might be a bit upset that it just went ahead and built something I didn't actually want.

> So.. I think we can get what we want if just make the "$next_version" implicit
> and doc the issue to have customers yum update their ami's to get to
> $next_version (if needed).
Comment 9 Steve Loranz 2012-05-09 10:27:24 EDT
(In reply to comment #7)
> Wes' solution is not a bad idea for an update fix -- Steve, Ian, let us know
> what you think, and if you think such a fix is a candidate for z-stream or is
> too disruptive.
> 
> In the meantime: We will continue to add support for new AMI versions and new
> RHEL versions by updating the config RPM with each z-stream release.
> 
> As I said to someone else the other day, customers clamoring for the ability to
> build the latest software with our tools is a problem I would love to have...

Clamoring to build the latest software with older revisions of our tools?
(yes... I know... Just sayin')
Comment 10 wes hayutin 2012-05-09 10:41:04 EDT
> 
> If it was me building a template, I don't know that I'd want factory to fall
> back to a different version than I specified in the template. Give how long  it
> can take to build an image, I might be a bit upset that it just went ahead and
> built something I didn't actually want.
> 

If the official RHEL ami is not available what other choices do we/customers have?

  Scenario:  RHEL 6.3 GA's, the 6.3 AMI is not ready because it is a different release.  We wait two days to get the official RHEL 6.3 ami number. Then wait a couple more days to get an errata through with an updated jeos config.

 Results: Customer's are waiting over a week to be able to deploy 6.3 in ec2. W/ the current code base, any template w/ 6.3 pushed to ec2 will FAIL...

 Defensive Code:  Build/Push the previous version RHEL 6.2.  The customer can then run yum update on the running ami and get to 6.3 in the interim week.
Comment 11 Steve Loranz 2012-05-09 10:50:43 EDT
(In reply to comment #10)
> > 
> > If it was me building a template, I don't know that I'd want factory to fall
> > back to a different version than I specified in the template. Give how long  it
> > can take to build an image, I might be a bit upset that it just went ahead and
> > built something I didn't actually want.
> > 
> 
> If the official RHEL ami is not available what other choices do we/customers
> have?
> 
>   Scenario:  RHEL 6.3 GA's, the 6.3 AMI is not ready because it is a different
> release.  We wait two days to get the official RHEL 6.3 ami number. Then wait a
> couple more days to get an errata through with an updated jeos config.
> 
>  Results: Customer's are waiting over a week to be able to deploy 6.3 in ec2.
> W/ the current code base, any template w/ 6.3 pushed to ec2 will FAIL...
> 
>  Defensive Code:  Build/Push the previous version RHEL 6.2.  The customer can
> then run yum update on the running ami and get to 6.3 in the interim week.

I'll agree with endeavoring to find a better way to resolve the AMI id so that we can cut out the time that you would wait for a new RPM, but I still don't understand how building an image with a base OS one version back from what was specified is a good thing. If I say I want '6.3' I really want 6.3. If I say I want RHEL6.LATEST-RELEASE, then sure... what you're saying makes sense. But, we don't support that syntax in the TDL.  Maybe that should be the enhancement.
Comment 12 wes hayutin 2012-05-09 10:56:51 EDT
> I'll agree with endeavoring to find a better way to resolve the AMI id so that
> we can cut out the time that you would wait for a new RPM, but I still don't
> understand how building an image with a base OS one version back from what was
> specified is a good thing. If I say I want '6.3' I really want 6.3. If I say I
> want RHEL6.LATEST-RELEASE, then sure... what you're saying makes sense. But, we
> don't support that syntax in the TDL.  Maybe that should be the enhancement.

I agree, I guess my point is this would allow a customer to build for all providers.  Using the same template file a customer could build/push RHEL 6.3 on vshere,rhevm.. and default back to 6.2 for ec2.
Comment 13 Steve Loranz 2012-05-09 14:33:16 EDT
Just to clarify, it looks like the options we're considering are:

1) add a configurable option to implicitly support new OS versions, default to explicit support.

2) enhance the TDL syntax to allow specifying minimum, maximum, and I suppose a range of versions, with keywords for latest release and latest beta.

Both of these really require us to come up with a better way of resolving the image id on a cloud provider for JEOS snapshots.

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