On Sat, Oct 2, 2010 at 12:35, seth vidal <skvidal(a)fedoraproject.org> wrote:
On Sat, 2010-10-02 at 13:11 -0500, Michael Stahnke wrote:
> One issue with this is that when managing systems, often times you
> manage multiple releases (e.g. RHEL 4/5/6). If cfengine3 is available
> on 6, I either have to build cfengine3 on 4/5 or get cfengine2 working
> on 6 in order to truly manage the environment. This is the same issue
> we have with the puppet packages as well. To me, I want them the same
> on all releases, but as per the EPEL policy, you'll probably have
> increasingly antiquated versions that probably are not compatible with
> each other. I wanted to bring this up in the EPEL meeting last week,
> but I forgot.
> What are the thoughts on system management tools where a centralized
> master is required and is often used to manage multiple versions of
> the operating system?
> I am sure there are examples other than cfengine and puppet, also.
If the tools mgmt server is going to break in incompatible ways then the
mgmt server should be able to install and run on multiple ports w/o
stepping on each other.
ie: cfengine2 on port foo cfgengine3 on port foo+1
and co-installable pkgs.
Sadly they use the same ports and like puppet look enough alike at
times you think they are the same thing. I would package them up as
incompatible with each other... or alternatives of each other.
if that is a goal.
epel-devel-list mailing list
Stephen J Smoogen.
“The core skill of innovators is error recovery, not failure avoidance.”
Randy Nelson, President of Pixar University.
"We have a strategic plan. It's called doing things.""
— Herb Kelleher, founder Southwest Airlines