On Sat, Oct 2, 2010 at 12:35, seth vidal <[email protected]> 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 > [email protected] > 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 _______________________________________________ epel-devel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/epel-devel-list
