Cobbler drops errors on the floor during a replicate

[tremble]

We've an old installation which has lots of subtly broken distros profiles and systems. While trying to sync up a new slave I noticed that various bits and pieces weren't syncing across. No errors, just objects that didn't appear on the slave.

I tracked it down to collection.py which is catching an exception, returning false and not logging anything.

A simple error level log call would have made my life much simpler...

    try:
        ref.check_if_valid()
    except CX, error:
        return False

[mpdehaan]

"add" in cobbler is used in two places, one in creating in-memory objects (save=False), another in saving them to disk. I don't think we want to log in this particular place because this would produce logging on invalid command line executions. Rather, I think it's more likely that when running replicate (did you mean replicate? It seems to make more sense here) we'd want to ensure it reported on the things it could not transfer.

[tremble]

mpdehaan - sorry for the delay, yes I did mean during replicate

Yes, reporting is some way that things didn't transfer would be good.

[tremble]

jimi, while that would improve matters, the one issue is that because the exception was dropped on the floor in add you don't know why it was dropped on the floor. Allowing the exception to fall back up to the caller would probably be the cleaner option, with the command line executions then being responsible for catching what is ultimately a mistake in the command line options... That's MHO anyway...

[jimi-c]

True, but at least knowing that it failed is important, and lets you start debugging. I plan on this being more of a stop-gap anyway, as replicate needs some work. For example, doing a full data sync does not respect distro filters right now, so there's no way to do a selective replicate. That means if you do replicate systems or profiles, you HAVE to do a full data sync or the distros won't be brought over due to the fact that the initrd/kernel pairs are not available on the replicated system. That is probably the source of the original failures, to be honest.

[tremble]

jimi, What was actually catching us out was the fact that the systems pointed to profiles/distros that just didn't exist any more, and somewhere in the past the logic hadn't caught this.

[tremble]

but I'm fine with your point about it being a stop gap, if more work is planned.

[viper233]

I'm wondering if I've come across this bug also. I had an issue where cobblerd wouldn't restart on a slave. I tracked it down to an extra '}' /var/lib/cobbler/config/repos.d/rpmforge-el6.json at the end of the file. During the replication process /var/www/cobbler/repo_mirror filled up also though I don't see how this could have caused my issue.