Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   EPEL Development (http://www.linux-archive.org/epel-development/)
-   -   System Management Tools and versions (http://www.linux-archive.org/epel-development/434727-system-management-tools-versions.html)

seth vidal 10-02-2010 06:35 PM

System Management Tools and versions
 
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.

if that is a goal.

-sv


_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

Stephen John Smoogen 10-02-2010 06:56 PM

System Management Tools and versions
 
On Sat, Oct 2, 2010 at 12:35, seth vidal <skvidal@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@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

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

seth vidal 10-02-2010 07:18 PM

System Management Tools and versions
 
On Sat, 2010-10-02 at 12:56 -0600, Stephen John Smoogen wrote:
> 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.

In the above situatiuon you'd think upstream would want to know they're
hurting the users they are targeting.

-sv



_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

Michael Stahnke 10-02-2010 10:02 PM

System Management Tools and versions
 
On Sat, Oct 2, 2010 at 2:18 PM, seth vidal <skvidal@fedoraproject.org> wrote:
> On Sat, 2010-10-02 at 12:56 -0600, Stephen John Smoogen wrote:
>> 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.
>
> In the above situatiuon you'd think upstream would want to know they're
> hurting the users they are targeting.
>
> -sv

I'm not sure it's upstream hurting users. EPEL won't move the
version of cfengine or puppet (although we have moved puppet in the
past) for the EL4/5 systems. Thus the choice is either get the latest
from epel and rebuild the latest on the older systems, or the opposite
try and build the old package on the newer EL version. Either way,
it's a dis-service to everybody involved because the packages are not
in step with each other across distros. This often leads to people
complaining about EPEL and then rolling their own packages or tarball
or gem installations into their environment.

The reason EPEL normally doesn't move these packages is that they
often times do introduce API/ABI breakage, so I'm not sure what the
best answer is, but I know I would still want all of my servers to be
managed through the same policies and at the same client version so I
have the same features available to everything inside my
infrastructure.

stahnma

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

Todd Zullinger 10-02-2010 10:40 PM

System Management Tools and versions
 
Michael,

Thanks for bringing up this subject. I've been thinking about it a
bit lately.

Michael Stahnke wrote:
> I'm not sure it's upstream hurting users. EPEL won't move the
> version of cfengine or puppet (although we have moved puppet in the
> past) for the EL4/5 systems.

Puppet has pretty much always been updated to the latest release.
While it was still at 0.x versions, it could arguably be treated as
"it's not stable, so expect a few changes here and there." Now that
upstream has bumped the version scheme to reflect that puppet is more
stable and mature, that seems a little tougher to justify. It's also
harder as more folks adopt it.

I'm still unsure if updating from 0.25.x to 2.6.x will be reasonable.
The changes should be backward compatible, and a few places where
behavior changed from 0.25.x to 2.6.x have been fixed as bugs
upstream. But it's always tough to test all the various ways in which
people put puppet to use.

I've held back updating in Fedora as well, because quite often people
are using RHEL/CentOS as the puppet master and clients being newer
than the master isn't generally supported.

I've tried to get input from Fedora/EPEL users in the puppet
community, to gauge whether the update has or has not been a smooth
one for users. Not a lot of feedback so far.

--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~
I have not failed. I've just found 10,000 ways that won't work.
-- Thomas Alva Edison (1847-1931)

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

Jeff Sheltren 10-02-2010 11:29 PM

System Management Tools and versions
 
On Sat, Oct 2, 2010 at 3:02 PM, Michael Stahnke <mastahnke@gmail.com> wrote:
> I'm not sure it's upstream hurting *users. *EPEL won't move the
> version of cfengine or puppet (although we have moved puppet in the
> past) for the EL4/5 systems. *Thus the choice is either get the latest
> from epel and rebuild the latest on the older systems, or the opposite
> try and build the old package on the newer EL version. *Either way,
> it's a dis-service to everybody involved because the packages are not
> in step with each other across distros. *This often leads to people
> complaining about EPEL and then rolling their own packages or tarball
> or gem installations into their environment.
>
> The reason EPEL normally doesn't move these packages is that they
> often times do introduce API/ABI breakage, so I'm not sure what the
> best answer is, but I know I would still want all of my servers to be
> managed through the same policies and at the same client version so I
> have the same features available to everything inside my
> infrastructure.
>
> stahnma
>

In the case of cfengine, v2 vs. v3: v2 is no longer supported at all
from upstream. However, I'm pretty sure that v2 clients will work
fine with a v3 server (someone please correct me if I'm wrong).
Because v2 is no longer supported upstream I'm hard pressed to find a
reason to support it in EPEL6 onwards.

A very unscientific survey (me talking to some random subset of
cfengine users) has led me to believe that many in the community are
assessing their options before making the move the v3 and are still
using v2 in the meantime. In this case upstream has not left people
with many choices: it's either move to v3, continue with v2 without
any support or security fixes, or move to another configuration
management system. If upstream were to continue to support v2, I
would gladly build v2 and v3 versions for all supported EPEL releases,
but this is purely hypothetical as it has already been decided
upstream to drop v2 completely.

-Jeff

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

Stephen John Smoogen 10-03-2010 03:15 AM

System Management Tools and versions
 
On Sat, Oct 2, 2010 at 17:29, Jeff Sheltren <jeff@osuosl.org> wrote:
> On Sat, Oct 2, 2010 at 3:02 PM, Michael Stahnke <mastahnke@gmail.com> wrote:
>> I'm not sure it's upstream hurting *users. *EPEL won't move the
>> version of cfengine or puppet (although we have moved puppet in the
>> past) for the EL4/5 systems. *Thus the choice is either get the latest
>> from epel and rebuild the latest on the older systems, or the opposite
>> try and build the old package on the newer EL version. *Either way,
>> it's a dis-service to everybody involved because the packages are not
>> in step with each other across distros. *This often leads to people
>> complaining about EPEL and then rolling their own packages or tarball
>> or gem installations into their environment.
>>
>> The reason EPEL normally doesn't move these packages is that they
>> often times do introduce API/ABI breakage, so I'm not sure what the
>> best answer is, but I know I would still want all of my servers to be
>> managed through the same policies and at the same client version so I
>> have the same features available to everything inside my
>> infrastructure.
>>
>> stahnma
>>
>
> In the case of cfengine, v2 vs. v3: *v2 is no longer supported at all
> from upstream. *However, I'm pretty sure that v2 clients will work
> fine with a v3 server (someone please correct me if I'm wrong).
> Because v2 is no longer supported upstream I'm hard pressed to find a
> reason to support it in EPEL6 onwards.

No they are completely different in the same way that usually puppet
breaks support. A v2 box is not going to understand 'promises' or
other syntax. I doubt very much v2 will get any more support.
Cfengine 3 is where Mark Burgess is wanting to get corporate support
as he has a business behind it. The C2 code is a mess.. listening to
Luke Kanies it was the reason that he didn't fork it but just went
with a fresh start with puppet.



--
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
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

Jeff Sheltren 10-03-2010 07:06 PM

System Management Tools and versions
 
On Sat, Oct 2, 2010 at 8:15 PM, Stephen John Smoogen <smooge@gmail.com> wrote:
>> In the case of cfengine, v2 vs. v3: *v2 is no longer supported at all
>> from upstream. *However, I'm pretty sure that v2 clients will work
>> fine with a v3 server (someone please correct me if I'm wrong).
>> Because v2 is no longer supported upstream I'm hard pressed to find a
>> reason to support it in EPEL6 onwards.
>
> No they are completely different in the same way that usually puppet
> breaks support. A v2 box is not going to understand 'promises' or
> other syntax. *I doubt very much v2 will get any more support.
> Cfengine 3 is where Mark Burgess is wanting to get corporate support
> as he has a business behind it. The C2 code is a mess.. listening to
> Luke Kanies it was the reason that he didn't fork it but just went
> with a fresh start with puppet.
>

Perhaps I wasn't being clear. I'm not trying to say that cf2 supports
cf3 language updates. I'm trying to say that the v2 and v3
client/servers can interoperate. Here's a quote from the
documentation:
"The daemons and support services are fully interoperable between
cfengine 2 and cfengine 3, so it does not matter whether you run
cfservd (cf2) together with cf-agent (cf3) or cf-serverd (cf3)
together with cfagent (cf2). You can change the servers at your own
pace."

-Jeff

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

Stephen John Smoogen 10-03-2010 08:00 PM

System Management Tools and versions
 
On Sun, Oct 3, 2010 at 13:06, Jeff Sheltren <jeff@osuosl.org> wrote:
> On Sat, Oct 2, 2010 at 8:15 PM, Stephen John Smoogen <smooge@gmail.com> wrote:
>>> In the case of cfengine, v2 vs. v3: *v2 is no longer supported at all
>>> from upstream. *However, I'm pretty sure that v2 clients will work
>>> fine with a v3 server (someone please correct me if I'm wrong).
>>> Because v2 is no longer supported upstream I'm hard pressed to find a
>>> reason to support it in EPEL6 onwards.
>>
>> No they are completely different in the same way that usually puppet
>> breaks support. A v2 box is not going to understand 'promises' or
>> other syntax. *I doubt very much v2 will get any more support.
>> Cfengine 3 is where Mark Burgess is wanting to get corporate support
>> as he has a business behind it. The C2 code is a mess.. listening to
>> Luke Kanies it was the reason that he didn't fork it but just went
>> with a fresh start with puppet.
>>
>
> Perhaps I wasn't being clear. *I'm not trying to say that cf2 supports
> cf3 language updates. *I'm trying to say that the v2 and v3
> client/servers can interoperate. *Here's a quote from the
> documentation:
> "The daemons and support services are fully interoperable between
> cfengine 2 and cfengine 3, so it does not matter whether you run
> cfservd (cf2) together with cf-agent (cf3) or cf-serverd (cf3)
> together with cfagent (cf2). You can change the servers at your own
> pace."
>

Oh sorry. i misread some emails on the mailing list when I was subscribed to it.

How hard would it be to repackage the both of them as

cfengine2 < replaces cfengine < 3
cfengine3 < replaces cfengine >= 3 < 4

that way both can be packaged for sites? I am not asking this as "make
work" but will help out as needed with you on this.

--
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
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list


All times are GMT. The time now is 08:52 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.