Bug 819962
| Summary: | RFE: Support upcoming releases of RHEL for instances in private and public providers before official RHEL release | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Retired] CloudForms Cloud Engine | Reporter: | James Laska <jlaska> | ||||
| Component: | oz | Assignee: | Nobody <nobody> | ||||
| Status: | CLOSED EOL | QA Contact: | Rehana <aeolus-qa-list> | ||||
| Severity: | low | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 1.0.0 | CC: | athomas, cpelland, hbrock, morazi, srevivo, whayutin | ||||
| Target Milestone: | 1.0.1 | Keywords: | FutureFeature, Triaged | ||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Enhancement | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2020-03-27 19:10:10 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
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.
Steve, this may have to wait for Ian, but can you take a look and render an opinion? 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. 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.
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 " 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). 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... (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). (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')
>
> 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.
(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.
> 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.
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. |
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: