On Tue, Nov 18, 2008 at 3:53 PM, James Laska jlaska@redhat.com wrote:
The included changes add support for a new architecture 'ppc64'. Any cobbler imports on a ppc tree will detect and add the appropriate distro's and profiles for the ppc32 or ppc64 if applicable. For example:
$ cobbler import --name rawhide --path /mnt/rawhide/nightly/rawhide-20081113/ppc/os --available-as http://gromit.redhat.com/pub/fedora/linux/development/ppc/os [...] ---------------- (associating kickstarts)
- found content (breed=redhat) at /mnt/rawhide/nightly/rawhide-20081113/ppc/os/ppc/ppc32
--os-version for breed redhat must be one of rhel2.1, rhel3, rhel4, rhel5, fedora5, fedora6, fedora7, fedora8, fedora9, fedora10, generic24, generic26, other, given was rhel9
I don't believe it is related to your problem, but rawhide could produce problems. There are two sets of files matching *release-*, and in any case you probably need to add something to codes.py.
I cannot do anything with RedHat, but I will try the fedora9/rawhide. It looks that there is something now working well in the import code, and I wanted to check a debian powerpc import in any case.
Javier Palacios
On Tue, 2008-11-18 at 21:34 +0100, Javier Palacios wrote:
On Tue, Nov 18, 2008 at 3:53 PM, James Laska jlaska@redhat.com wrote:
The included changes add support for a new architecture 'ppc64'. Any cobbler imports on a ppc tree will detect and add the appropriate distro's and profiles for the ppc32 or ppc64 if applicable. For example:
$ cobbler import --name rawhide --path /mnt/rawhide/nightly/rawhide-20081113/ppc/os --available-as http://gromit.redhat.com/pub/fedora/linux/development/ppc/os [...] ---------------- (associating kickstarts)
- found content (breed=redhat) at /mnt/rawhide/nightly/rawhide-20081113/ppc/os/ppc/ppc32
--os-version for breed redhat must be one of rhel2.1, rhel3, rhel4, rhel5, fedora5, fedora6, fedora7, fedora8, fedora9, fedora10, generic24, generic26, other, given was rhel9
I don't believe it is related to your problem, but rawhide could produce problems. There are two sets of files matching *release-*, and in any case you probably need to add something to codes.py.
Sorry, coming up to speed on this now. So it appears that the fedora-release and generic-release packages (each with different version :( ) are confusing cobbler during import.
For example (with debugging enabled):
# cobbler import --name rawhide --path /mnt/rawhide/nightly/rawhide-20081113/i386/os --available-as http://gromit.redhat.com/pub/fedora/linux/development/i386/os ---------------- (adding distros) - found content (breed=redhat) at /mnt/rawhide/nightly/rawhide-20081113/i386/os/images/pxeboot - creating new distro: rawhide-i386 - creating new profile: rawhide-i386 - creating new profile: rescue-rawhide-i386 ---------------- (associating kickstarts) - found content (breed=redhat) at /mnt/rawhide/nightly/rawhide-20081113/i386/os/images/pxeboot - processing rpm : fedora-release-10-1.noarch.rpm
- finding default kickstart template for fedora 10.0 fedora10, /etc/cobbler/sample_end.ks = importer.set_variance(fedora, 10.0, 1.0, i386)
- processing rpm : generic-release-9.91-2.noarch.rpm - finding default kickstart template for redhat 9.0 rhel9, /etc/cobbler/sample.ks = importer.set_variance(redhat, 9.0, 91.0, i386)
--os-version for breed redhat must be one of rhel2.1, rhel3, rhel4, rhel5, fedora5, fedora6, fedora7, fedora8, fedora9, fedora10, generic24, generic26, other, given was rhel9
I'm not sure of the best approach here. Should cobbler interpret generic-release as a fedora release? Alternatively, should we stop scanning "*release*rpm" packages once we find a good one (e.g. redhat-release or fedora-release)?
Thanks, James
I cannot do anything with RedHat, but I will try the fedora9/rawhide. It looks that there is something now working well in the import code, and I wanted to check a debian powerpc import in any case.
Javier Palacios _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
- finding default kickstart template for fedora 10.0
fedora10, /etc/cobbler/sample_end.ks = importer.set_variance(fedora, 10.0, 1.0, i386)
- processing rpm : generic-release-9.91-2.noarch.rpm
- finding default kickstart template for redhat 9.0
rhel9, /etc/cobbler/sample.ks = importer.set_variance(redhat, 9.0, 91.0, i386)
--os-version for breed redhat must be one of rhel2.1, rhel3, rhel4, rhel5, fedora5, fedora6, fedora7, fedora8, fedora9, fedora10, generic24, generic26, other, given was rhel9
I'm not sure of the best approach here. Should cobbler interpret generic-release as a fedora release? Alternatively, should we stop scanning "*release*rpm" packages once we find a good one (e.g. redhat-release or fedora-release)?
Probably is just to modify the glob in get_release_file to match self.breed + "*release*" instead of just "*release*". I'm trusting in memory, so maybe a proper self.breed needs to be created at ImporterXXX class. And I'm sure than the release glob has a '-' somewhere. If you understand my explanation and check successfully, great. If not, I will be able to check that in a few hours.
Javier Palacios
I'm not sure of the best approach here. Should cobbler interpret generic-release as a fedora release? Alternatively, should we stop scanning "*release*rpm" packages once we find a good one (e.g. redhat-release or fedora-release)?
Here it is, was more or less as simple as expected, although longer. I have subclassed the RedHatImporter into a fedora and centos specific, as the self.breed is somewhat hardcoded. As a side effect the distro guessing is more specific (hopefully).
My only concern is about which distro has a 'Server' directory under the media topdir. I've left as "redhat", but if that is not the case, it might produce errors and require a change.
Javier Palacios
Javier Palacios wrote:
I'm not sure of the best approach here. Should cobbler interpret generic-release as a fedora release? Alternatively, should we stop scanning "*release*rpm" packages once we find a good one (e.g. redhat-release or fedora-release)?
Here it is, was more or less as simple as expected, although longer. I have subclassed the RedHatImporter into a fedora and centos specific, as the self.breed is somewhat hardcoded. As a side effect the distro guessing is more specific (hopefully).
My only concern is about which distro has a 'Server' directory under the media topdir. I've left as "redhat", but if that is not the case, it might produce errors and require a change.
Javier Palacios
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
I don't see the need for the explicit Fedora and CentOS breeds when they share very much in common (all now are born from Fedora and share the same structures).
What is the reason for introducing this?
Also, your patch likely breaks Scientific Linux.
--Michael
I don't see the need for the explicit Fedora and CentOS breeds when they share very much in common (all now are born from Fedora and share the same structures).
What is the reason for introducing this?
Besides the particular fixing of this double *release* file, the same reasons behind the ubuntu importer. Although the three are quite similar, they have slight differences. For example, you will have no repodata on RHEL media, or can do a more specific search for some items, such as the kernel packages in match_kernelarch_file. And remove the if fedora elif redhat that exists along the code.
Also, your patch likely breaks Scientific Linux.
More than likely. To really be backwards compatible, the get_release_files from the RedHatImporter should not be touched, and the new one should be copied to the fedora and centos importers.
Javier Palacios
Javier Palacios wrote:
I don't see the need for the explicit Fedora and CentOS breeds when they share very much in common (all now are born from Fedora and share the same structures).
What is the reason for introducing this?
Besides the particular fixing of this double *release* file, the same reasons behind the ubuntu importer. Although the three are quite similar, they have slight differences. For example, you will have no repodata on RHEL media, or can do a more specific search for some items, such as the kernel packages in match_kernelarch_file. And remove the if fedora elif redhat that exists along the code.
I don't want this. The initial reason for --breed's creation is to handle distributions that require slightly different kernel arguments.
Existing users will have --breed=redhat and will be confused when they search and find some imports tagged redhat and some fedora/centos.
These are all Red Hat rederived distributions so things can stay as is, and we can specifically handle the generic-release by ignoring it.
Also, your patch likely breaks Scientific Linux.
More than likely. To really be backwards compatible, the get_release_files from the RedHatImporter should not be touched, and the new one should be copied to the fedora and centos importers.
I'm not going to apply this, so things should stay working. I think this keeps things simple and we should not be introducing major changes to the importer at this time. A simple workaround to ignore generic-release is sufficient.
Javier Palacios _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
James Laska wrote:
On Tue, 2008-11-18 at 21:34 +0100, Javier Palacios wrote:
On Tue, Nov 18, 2008 at 3:53 PM, James Laska jlaska@redhat.com wrote:
The included changes add support for a new architecture 'ppc64'. Any cobbler imports on a ppc tree will detect and add the appropriate distro's and profiles for the ppc32 or ppc64 if applicable. For example:
$ cobbler import --name rawhide --path /mnt/rawhide/nightly/rawhide-20081113/ppc/os --available-as http://gromit.redhat.com/pub/fedora/linux/development/ppc/os [...] ---------------- (associating kickstarts)
- found content (breed=redhat) at /mnt/rawhide/nightly/rawhide-20081113/ppc/os/ppc/ppc32
--os-version for breed redhat must be one of rhel2.1, rhel3, rhel4, rhel5, fedora5, fedora6, fedora7, fedora8, fedora9, fedora10, generic24, generic26, other, given was rhel9
I don't believe it is related to your problem, but rawhide could produce problems. There are two sets of files matching *release-*, and in any case you probably need to add something to codes.py.
Sorry, coming up to speed on this now. So it appears that the fedora-release and generic-release packages (each with different version :( ) are confusing cobbler during import.
For example (with debugging enabled):
# cobbler import --name rawhide --path /mnt/rawhide/nightly/rawhide-20081113/i386/os --available-as http://gromit.redhat.com/pub/fedora/linux/development/i386/os ---------------- (adding distros)
- found content (breed=redhat) at /mnt/rawhide/nightly/rawhide-20081113/i386/os/images/pxeboot
- creating new distro: rawhide-i386
- creating new profile: rawhide-i386
- creating new profile: rescue-rawhide-i386
---------------- (associating kickstarts)
found content (breed=redhat) at /mnt/rawhide/nightly/rawhide-20081113/i386/os/images/pxeboot
processing rpm : fedora-release-10-1.noarch.rpm
finding default kickstart template for fedora 10.0
fedora10, /etc/cobbler/sample_end.ks = importer.set_variance(fedora, 10.0, 1.0, i386)
- processing rpm : generic-release-9.91-2.noarch.rpm
- finding default kickstart template for redhat 9.0
rhel9, /etc/cobbler/sample.ks = importer.set_variance(redhat, 9.0, 91.0, i386)
--os-version for breed redhat must be one of rhel2.1, rhel3, rhel4, rhel5, fedora5, fedora6, fedora7, fedora8, fedora9, fedora10, generic24, generic26, other, given was rhel9
I'm not sure of the best approach here. Should cobbler interpret generic-release as a fedora release? Alternatively, should we stop scanning "*release*rpm" packages once we find a good one (e.g. redhat-release or fedora-release)?
Thanks, James
Possibly. I also think we should not respond to generic-release at all.
--Michael
cobbler@lists.fedorahosted.org