Javier Palacios wrote:
>>> I've been revisiting the previous import code, and I'm working in a
>>> small refactoring that will probably re-enable importing of multiple
>>> distros at the same time, at the price of all of them sharing a single
>>> breed specified at command line, and will also make easier to add
>>> other distros.
>>>
>>>
>
> Actually recover the multi-import has been much easier than I
> expected. The
> patch attached works, at least for me.
>
> I can import three distros as
> cobbler import --mirror=/media/distros/rhas/4.6 --name=rhas
> cobbler import --path=/media/distros/Fedora9/i386/ --name=f9_32
> cobbler import --mirror=/media/distros/Fedora9/x86_64 --name=f9_64
>
> or issue a single command
> cobbler import --mirror=/media/distros --name=allinone --breed=redhat
>
> and all of them work.
>
> Regarding the patch itself, a couple of comments. I've moved
> distro_adder method
> close to the distro add related method, but there is no change there.
> I have also
> modified item_distro.py, to remove breed and arch defaults. It was
> difficult to know
> why (and where) was the distro flavor set without os version until I
> realize that the
> redhat flavor was given on instantiation. It might be safer not to
> move that change
> into HEAD, but at least for devel branch I believe it is a good idea
> to have no such
> hardcoded defaults.
> The remaining changes are mostly intended as a first step to the real
> refactor, to
> make easier understand the changes than submitting the patch in the
> final form
>
> Javier Palacios
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> cobbler mailing list
> cobbler(a)lists.fedorahosted.org
>
https://fedorahosted.org/mailman/listinfo/cobbler
Thanks very much for the interest in this. A few small problems:
(A) This patch breaks "make test" on my machine as it tries to call
"distro.set_arch()" with a value of None.
(B) Having a default for the item_distro.py values is a good thing,
because if no argument is passed to "distro add" it can assume a
reasonable default. At least for now redhat based distros constitute
at least 95% of all cobbler usage. Yes, we do want this to change,
but I don't believe we should require "--breed=redhat" on every distro
add command. We could perhaps decide to be clever and choose the
default based on the platform on which cobbler was running if we were
concerned about that being a confusing feature on the other side of
the fence. The changes to item_distro.py should not be applied,
having arch defaults and breed defaults is there for usability
reasons. If someone forgets to set them, they can set them later with
an "edit" command, but this ensures there is always a valid value for
these fields.
(C) Can you explain why the get_pxe_arch function, which was there
to return the architecture of a specific point in the directory tree
where the kernel+initrd is found, now returns a list? Are these
architecture guesses? I can't see any ability for sharing of kernels
between arches.
FYI: as for policy of what goes into HEAD, this is definitely
something that we're looking at for devel, but we only roll bugfixes
into HEAD. As this is new feature development devel will roll into
head once 1.3.X is complete.
If you can take care of A, B, and C, I can look at applying this, as I
think being able to process and import containing a mix of
distribution trees on NFS is definitely useful. We just want to make
extra sure everything that is currently there stays working.
I think I'm much more interested in seeing that we get fully automated
answer file templates set up first, before we look at adding
additional capabilities to the import code or look at refactoring.
If we have the audience and the features, we can worry about code
cleanup, but the main feature this needs (to have fully automated
kickstarts straight out of the import) is still missing -- that is the
main thing that "cobbler import" is intended to do.
--Michael
Correction:
(A) was my fault, running "make eraseconfig" removed the objects that
were causing that problem.
Other comments still apply.
Sorry for the confusion!
--Michael