Javier Palacios wrote:
> Hi,
>
> I've started to work in order to allow debian provisioning with
> cobbler. I send attached two patches.
>
> The first on is actually not strictly related to debian, and it's a
> reorganization of the archs management,
> to simplify it and ease smooth addition of other distros: debian calls
> amd64 to x86_64, and the idea is
> to keep the RedHat names as canonical ones.
>
> The second one does actually allow to import the content of a debian
> CD/DVD and create the corresponding
> distro. It also creates the profile breeded as debian, although it
> might not be usable yet.
>
> There are a couple of open questions that might affect other parts of
> cobbler or where just ideas are required.
>
> - the kickstarts for debian. They are called "preseed", and are by far
> much more complex than a standard
> kickstart. Although not strictly required, it might be better to
> have new names for both ks files and directories,
> but I think that they can be easyly added to PXE boot options. To
> make things worst, ubuntu does allow both
> the standard debian preseed and kickstart files.
>
> - the package repositories. Debian follows a quite different approach,
> and a single tree can hold many versions
> and different architectures. Allowing a cobbler distro to have
> multiple architectures might reduce the disk usage
> and simplify the repository updating. Due to this fact, a single
> debian media can install multiple archs, complexing
> a little bit to import the media.
>
> These are the only two points I see on the close horizon, but there
> are probably more. It anyone has concerns
> or ideas, they are welcome. And if anyone can actually test the
> deployment (when it matures a little bit), much better.
>
> Javier Palacios
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> cobbler mailing list
> [email protected]
> https://fedorahosted.org/mailman/listinfo/cobbler
First off, thanks very much for the patch. The first one is going to
need a minor bit of tweaking to put the constants back to the way
Cobbler used them, though the generalized code cleanup is a good in
priciple -- I do not want the constants renumbered or mapped to provide
aliases for one another. I'll explain why. I had thought you were
wanting to rewrite this more than what you had submitted.
Ok, so the reason we have consolidated on x86 and x86_64 (not i386 or
i686) is to ensure that we don't break things unexpectedly with respect
to yum. There i386 is incorrect there as it will not pull in i686
kernel packages, so there we need i686, which is why the internal
represenation is stored as x86. And since we sometimes compare the
arches of distros with the arches of repo objects they should be stored
the same way.
We would also never have "bsd_x86_64" as an arch, so remove that
suggestion from the comments so that does not confuse someone reading
the code. The way we do that is with the "--breed" parameter, which is
seperate from arch, we don't combine them. This is the way we do SuSE
and debian already today:
cobbler distro add --name=foo --arch=x86_64 ... # implies redhat based
cobbler distro add --name=foo --breed=debian --arch=x86_64 ...
cobbler distro add --name=foo --breed=suse --arch=x86_64 ...
I am also confused by:
+ if os.path.realpath(fullname) == os.path.realpath(dirname):
+ print _("- found self-refering link, probably debian
based distro")
+ self.breed_guess = "debian"
+ continue
This seems to be a kind of strange way to detect that a tree is Debian
based. A better route is probably to have two seperate importer
classes, which I believe someone might have been working on, and require
when importing non-redhat distributions that we specify that is what
they are.
For instance, add a new "--breed" parameter to import.
This may take some refactoring of the import code but would be better
than further complicating it, as already it has to deal with a lot of
variance between different EL and Fedora distributions. Having that
become /more/ complex is really not a good option.
So ideally I think what we want is to see action_import.py become a
switchboard, and then based on the value of --breed given to the import
call, choose the right importer_*.py out of "modules" -- that way we can
arbitrarily support other distributions without having to keep adding
the code to the same importer, which will likely become more complicated
to follow as we add more and more code to it.
--Michael
_______________________________________________
cobbler mailing list
[email protected]
https://fedorahosted.org/mailman/listinfo/cobbler
