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.
-sv
_______________________________________________
epel-devel-list mailing list
epel-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-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