On 09/20/2011 09:56 AM, brett lentz wrote:
On Tue, Sep 20, 2011 at 8:43 AM, Bill Peck<bpeck(a)redhat.com>
wrote:
> On 09/19/2011 05:44 PM, Jonathan Underwood wrote:
>> On 19 September 2011 20:29, Jörgen Maas<jorgen.maas(a)gmail.com> wrote:
>>> On Mon, Sep 19, 2011 at 9:19 PM, Konrad Scherer
>>> <konrad.scherer(a)windriver.com> wrote:
>>>> As a happy and grateful user of cobbler I have noticed that the cobbler
project
>>>> is not as active as it used to be. Is it time for me to move on?
>>>>
>>> Unfortunately I have come to the same conclusions.
>>> The cobbler project looks like it's dying a slow death.
>>>
>>> So yes, I guess it's time to move on ;).
>>>
>> I think if you were to look at the activity in the source code
>> repository, you might draw a different conclusion. Also, you might
>> want to look at this:
>>
>>
http://michaeldehaan.net/2011/05/14/about-that-scaling-thing/
> Unless I'm mistaken the solution Michael gives for the scaling issue is
> to use the backend couchDB. The problem is that doesn't solve anything
> since it still loads *everything* into ram. And that gets back to the
> real problem, cobbler wasn't designed to scale, simple as that.
>
The whole "not designed to scale" comment, while a nice sound bite, is
meaningless and a bit of a red herring.
As the saying goes, "If you can't measure it, it's not science." The
same is true here. Performance is defined by a rate (i.e. some value
that changes with respect to some other value). Who cares if couchDB
loads everything into RAM? How many bytes does "everything" take up?
Is there enough RAM to hold it? Without any numbers, the statement is
pure FUD.
Its not pure fud. Slapping a DB on the backend just to use as a file
store does nothing for you. It doesn't enforce data integrity and it
doesn't speed anything up either. We have bz's filed about the
integrity issues where the in memory version of the dataset gets
confused and has profiles referencing other profiles that don't exist
any more. These errors cause cobbler to fall down quite badly, no other
profile operations can continue because cobbler wants to re-write all
the pxe records when you update one.
We have hundreds of systems in cobbler which isn't much, but we do have
thousands of distro/profile records and this is an area where cobbler
doesn't scale. cobbler sync takes almost 10 minutes to complete which
may not seem like much but during that time you can't be sure systems
will pxe boot correctly since a file or record may be missing. This is
better now that a .link_cache directory is used but then we have to
worry about that directory having old stale data which needs to be cleaned.
Don't get me wrong, cobbler has helped us tremendously but its reached
its limit for us and the above issues have been resolved in foreman.
I'm sure we will experience other pain points in foreman but at this
point it looks like a more solid foundation to stand on.
If cobbler works for you then great.
None of the detractors has yet really mentioned any specific numbers
around what their requirements really are (or whether Cobbler meets
those requirements). Mike's post mentions a few cases of a few
installs running upwards of 20k systems. I'd be interested to know how
cobbler performs in those settings; how quickly it can serve a
rendered kickstart; how quickly it can lookup a particular system
record; how much time it takes an admin to work with the whole system.
I have my own gripes with Cobbler's UI and data model, especially with
respect to how it integrates with puppet. Personally, I think there is
enough room for improvement in those areas that vague hand-waving
about performance is unnecessary.
If there's a likely reason for why the Satellite folks are moving away
from Cobbler, it's probably less about performance and got more to do
with the fact that Foreman was built with integrating with Puppet/Chef
in mind. (That's just a guess.) In Cobbler, that integration is quite
obviously an after-thought (and a poorly implemented one at that).
Life of a system doesn't stop when the installer exits, yet Cobbler
doesn't seem to consider any of those areas. There's little to no
consideration given to issues of inventory, life cycle, or config
management.
If all you care about is installing an OS, Cobbler is a great tool. It
does that job very very well. The problem is, Satellite, Foreman, and
other similar tools are thinking about more than just OS installation.
---Brett.
_______________________________________________
cobbler-devel mailing list
cobbler-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler-devel