Redhat admins, if a cookbook enables EPEL, is that a surprise?


#1

Would you be surprised if you ran a community cookbook for a piece of
software and it configured EPEL to do so?

It seems like getting most things done requires it, but we haven’t made a
global pattern yet to override the use of EPEL yet.

If everyone just uses EPEL, then it is a moot point.


Bryan McLellan | opscode | technical program manager, open source
© 206.607.7108 | (t) @btmspox | (b) http://blog.loftninjas.org


#2

Bryan,

Our application cookbooks will enable EPEL if they are attempting to retrieve a package which requires it. The same goes for any of our library cookbooks which have a package contained there. We always make these cookbooks configurable, though, so you can instead retrieve your package out of a self hosted repository.

EPEL is more of a sensible default for us.


Jamie Winsor
@resetexistence

On Friday, November 16, 2012 at 1:29 PM, Bryan McLellan wrote:

Would you be surprised if you ran a community cookbook for a piece of
software and it configured EPEL to do so?

It seems like getting most things done requires it, but we haven’t made a
global pattern yet to override the use of EPEL yet.

If everyone just uses EPEL, then it is a moot point.


Bryan McLellan | opscode | technical program manager, open source
© 206.607.7108 | (t) @btmspox | (b) http://blog.loftninjas.org


#3

i can’t get anything done w/out enabling epel. so for my part, not a
surprise

On Fri, Nov 16, 2012 at 10:29 PM, Bryan McLellan btm@opscode.com wrote:

Would you be surprised if you ran a community cookbook for a piece of
software and it configured EPEL to do so?

It seems like getting most things done requires it, but we haven’t made a
global pattern yet to override the use of EPEL yet.

If everyone just uses EPEL, then it is a moot point.


Bryan McLellan | opscode | technical program manager, open source
© 206.607.7108 | (t) @btmspox | (b) http://blog.loftninjas.org


#4

Bryan,

Most of our deployments require any number of packages that aren’t in
RHEL default, and EPL has them. So adding EPEL via “yum::epel” is one
of our first-called recipes.

-Mike

On Fri, Nov 16, 2012 at 4:36 PM, Jamie Winsor jamie@vialstudios.com wrote:

Bryan,

Our application cookbooks will enable EPEL if they are attempting to
retrieve a package which requires it. The same goes for any of our library
cookbooks which have a package contained there. We always make these
cookbooks configurable, though, so you can instead retrieve your package out
of a self hosted repository.

EPEL is more of a sensible default for us.


Jamie Winsor
@resetexistence
https://github.com/reset

On Friday, November 16, 2012 at 1:29 PM, Bryan McLellan wrote:

Would you be surprised if you ran a community cookbook for a piece of
software and it configured EPEL to do so?

It seems like getting most things done requires it, but we haven’t made a
global pattern yet to override the use of EPEL yet.

If everyone just uses EPEL, then it is a moot point.


Bryan McLellan | opscode | technical program manager, open source
© 206.607.7108 | (t) @btmspox | (b) http://blog.loftninjas.org


#5

I can’t speak for everyone on RHEL/CentOS, but I think there is at least
one-off package from EPEL on every one of our systems. When writing a
community cookbook, I never assume the end user has EPEL enabled, it
does need to be coded into the recipe (or at least included via
yum::epel). When I opened COOK-1772, the goal was to make that a
uniform pattern which makes use of the yum::repository LWRP.

Unfortunately I think there are still multiple issues with the yum
cookbook on Amazon Linux, thanks to their platform_version differences.
This isn’t directly related to your question, but shouldn’t EL family
platforms return a consistent version number (OHAI-321)?

Eric G. Wolfe
Senior Linux Administrator,
IT Infrastructure Systems

Marshall University Computing Services
Drinko Library 428-K
One John Marshall Dr.
Huntington, WV 25755
Phone: 304.942.3970
Email: eric.wolfe@marshall.edu

You will be recognized and honored as a community leader.

On 11/16/2012 04:29 PM, Bryan McLellan wrote:

Would you be surprised if you ran a community cookbook for a piece of
software and it configured EPEL to do so?

It seems like getting most things done requires it, but we haven’t made a
global pattern yet to override the use of EPEL yet.

If everyone just uses EPEL, then it is a moot point.


Bryan McLellan | opscode | technical program manager, open source
© 206.607.7108 | (t) @btmspox | (b) http://blog.loftninjas.org


#6

Most everything we try to do requires EPEL so we have it enabled on
anything in Redhat-land.

Tim Smith
Operations Engineer, SaaS Operations
M: +1 707.738.8132
TW: @tas50
webtrends http://www.webtrends.com/
Real-Time Relevance. Remarkable ROI.
London | Portland | San Francisco | Melbourne | Tokyo

On 11/16/12 1:51 PM, “Eric G. Wolfe” eric.wolfe@marshall.edu wrote:

I can’t speak for everyone on RHEL/CentOS, but I think there is at least
one-off package from EPEL on every one of our systems. When writing a
community cookbook, I never assume the end user has EPEL enabled, it
does need to be coded into the recipe (or at least included via
yum::epel). When I opened COOK-1772, the goal was to make that a
uniform pattern which makes use of the yum::repository LWRP.

Unfortunately I think there are still multiple issues with the yum
cookbook on Amazon Linux, thanks to their platform_version differences.
This isn’t directly related to your question, but shouldn’t EL family
platforms return a consistent version number (OHAI-321)?

Eric G. Wolfe
Senior Linux Administrator,
IT Infrastructure Systems

Marshall University Computing Services
Drinko Library 428-K
One John Marshall Dr.
Huntington, WV 25755
Phone: 304.942.3970
Email: eric.wolfe@marshall.edu

You will be recognized and honored as a community leader.

On 11/16/2012 04:29 PM, Bryan McLellan wrote:

Would you be surprised if you ran a community cookbook for a piece of
software and it configured EPEL to do so?

It seems like getting most things done requires it, but we haven’t made
a
global pattern yet to override the use of EPEL yet.

If everyone just uses EPEL, then it is a moot point.


Bryan McLellan | opscode | technical program manager, open source
© 206.607.7108 | (t) @btmspox | (b) http://blog.loftninjas.org


#7

Often I need things from EPEL but I also tend to create my own YUM mirror so I know what versions I am getting if I bring up a new box. In this case adding a repo would circumvent my controls.

Jeffrey Hulten
Principal Consultant at Automated Labs, LLC
jeffh@automatedlabs.com 206-853-5216
Skype: jeffhulten

On Nov 16, 2012, at 9:56 PM, Tim Smith wrote:

Most everything we try to do requires EPEL so we have it enabled on
anything in Redhat-land.

Tim Smith
Operations Engineer, SaaS Operations
M: +1 707.738.8132
TW: @tas50
webtrends http://www.webtrends.com/
Real-Time Relevance. Remarkable ROI.™
London | Portland | San Francisco | Melbourne | Tokyo

On 11/16/12 1:51 PM, “Eric G. Wolfe” eric.wolfe@marshall.edu wrote:

I can’t speak for everyone on RHEL/CentOS, but I think there is at least
one-off package from EPEL on every one of our systems. When writing a
community cookbook, I never assume the end user has EPEL enabled, it
does need to be coded into the recipe (or at least included via
yum::epel). When I opened COOK-1772, the goal was to make that a
uniform pattern which makes use of the yum::repository LWRP.

Unfortunately I think there are still multiple issues with the yum
cookbook on Amazon Linux, thanks to their platform_version differences.
This isn’t directly related to your question, but shouldn’t EL family
platforms return a consistent version number (OHAI-321)?

Eric G. Wolfe
Senior Linux Administrator,
IT Infrastructure Systems

Marshall University Computing Services
Drinko Library 428-K
One John Marshall Dr.
Huntington, WV 25755
Phone: 304.942.3970
Email: eric.wolfe@marshall.edu

You will be recognized and honored as a community leader.

On 11/16/2012 04:29 PM, Bryan McLellan wrote:

Would you be surprised if you ran a community cookbook for a piece of
software and it configured EPEL to do so?

It seems like getting most things done requires it, but we haven’t made
a
global pattern yet to override the use of EPEL yet.

If everyone just uses EPEL, then it is a moot point.


Bryan McLellan | opscode | technical program manager, open source
© 206.607.7108 | (t) @btmspox | (b) http://blog.loftninjas.org


#8

In that case, I’d fork the yum cookbook locally and override the epel recipe to do what I want with a local repo. For a cookbook, activating epel is the best general solution - if you’re one of the small percentage that won’t work for, it’s easy enough to replace without problem as long as the cookbook uses yum::epel.

I would do the same thing for anything involving rpmforge, for example. I have a few packages that I rebuilt/resigned locally, but I haven’t run in to that with a cookbook yet.

On Nov 17, 2012, at 9:11, Jeffrey Hulten jeffh@automatedlabs.com wrote:

Often I need things from EPEL but I also tend to create my own YUM mirror so I know what versions I am getting if I bring up a new box. In this case adding a repo would circumvent my controls.

Jeffrey Hulten
Principal Consultant at Automated Labs, LLC
jeffh@automatedlabs.com 206-853-5216
Skype: jeffhulten

On Nov 16, 2012, at 9:56 PM, Tim Smith wrote:

Most everything we try to do requires EPEL so we have it enabled on
anything in Redhat-land.

Tim Smith
Operations Engineer, SaaS Operations
M: +1 707.738.8132
TW: @tas50
webtrends http://www.webtrends.com/
Real-Time Relevance. Remarkable ROI.™
London | Portland | San Francisco | Melbourne | Tokyo

On 11/16/12 1:51 PM, “Eric G. Wolfe” eric.wolfe@marshall.edu wrote:

I can’t speak for everyone on RHEL/CentOS, but I think there is at least
one-off package from EPEL on every one of our systems. When writing a
community cookbook, I never assume the end user has EPEL enabled, it
does need to be coded into the recipe (or at least included via
yum::epel). When I opened COOK-1772, the goal was to make that a
uniform pattern which makes use of the yum::repository LWRP.

Unfortunately I think there are still multiple issues with the yum
cookbook on Amazon Linux, thanks to their platform_version differences.
This isn’t directly related to your question, but shouldn’t EL family
platforms return a consistent version number (OHAI-321)?

Eric G. Wolfe
Senior Linux Administrator,
IT Infrastructure Systems

Marshall University Computing Services
Drinko Library 428-K
One John Marshall Dr.
Huntington, WV 25755
Phone: 304.942.3970
Email: eric.wolfe@marshall.edu

You will be recognized and honored as a community leader.

On 11/16/2012 04:29 PM, Bryan McLellan wrote:

Would you be surprised if you ran a community cookbook for a piece of
software and it configured EPEL to do so?

It seems like getting most things done requires it, but we haven’t made
a
global pattern yet to override the use of EPEL yet.

If everyone just uses EPEL, then it is a moot point.


Bryan McLellan | opscode | technical program manager, open source
© 206.607.7108 | (t) @btmspox | (b) http://blog.loftninjas.org


#9

Internally, we’ve gone as far as writing an ohai plugin that determines
whether or not we’re in a restricted data center environment before
overriding yum repository sources and enabling/disabling repos.

On a related note, I can’t remember whether or not the yum_repo LWRP parses
existing files for options in its load_current_resource() or just checks to
see whether or not the file exists … I just remember that when I change a
Yum mirror I find that the mirrors don’t get updated on my nodes until I
nuke the repo file from /etc/yum.repos.d. But this is with an old fork…
is that behavior still around?

On Sat, Nov 17, 2012 at 9:11 AM, Joshua Buysse buysse@umn.edu wrote:

In that case, I’d fork the yum cookbook locally and override the epel
recipe to do what I want with a local repo. For a cookbook, activating epel
is the best general solution - if you’re one of the small percentage that
won’t work for, it’s easy enough to replace without problem as long as the
cookbook uses yum::epel.

I would do the same thing for anything involving rpmforge, for example. I
have a few packages that I rebuilt/resigned locally, but I haven’t run in
to that with a cookbook yet.

On Nov 17, 2012, at 9:11, Jeffrey Hulten jeffh@automatedlabs.com wrote:

Often I need things from EPEL but I also tend to create my own YUM
mirror so I know what versions I am getting if I bring up a new box. In
this case adding a repo would circumvent my controls.

Jeffrey Hulten
Principal Consultant at Automated Labs, LLC
jeffh@automatedlabs.com 206-853-5216
Skype: jeffhulten

On Nov 16, 2012, at 9:56 PM, Tim Smith wrote:

Most everything we try to do requires EPEL so we have it enabled on
anything in Redhat-land.

Tim Smith
Operations Engineer, SaaS Operations
M: +1 707.738.8132
TW: @tas50
webtrends http://www.webtrends.com/
Real-Time Relevance. Remarkable ROI.™
London | Portland | San Francisco | Melbourne | Tokyo

On 11/16/12 1:51 PM, “Eric G. Wolfe” eric.wolfe@marshall.edu wrote:

I can’t speak for everyone on RHEL/CentOS, but I think there is at
least

one-off package from EPEL on every one of our systems. When writing a
community cookbook, I never assume the end user has EPEL enabled, it
does need to be coded into the recipe (or at least included via
yum::epel). When I opened COOK-1772, the goal was to make that a
uniform pattern which makes use of the yum::repository LWRP.

Unfortunately I think there are still multiple issues with the yum
cookbook on Amazon Linux, thanks to their platform_version differences.
This isn’t directly related to your question, but shouldn’t EL family
platforms return a consistent version number (OHAI-321)?

Eric G. Wolfe
Senior Linux Administrator,
IT Infrastructure Systems

Marshall University Computing Services
Drinko Library 428-K
One John Marshall Dr.
Huntington, WV 25755
Phone: 304.942.3970
Email: eric.wolfe@marshall.edu

You will be recognized and honored as a community leader.

On 11/16/2012 04:29 PM, Bryan McLellan wrote:

Would you be surprised if you ran a community cookbook for a piece of
software and it configured EPEL to do so?

It seems like getting most things done requires it, but we haven’t
made

a
global pattern yet to override the use of EPEL yet.

If everyone just uses EPEL, then it is a moot point.


Bryan McLellan | opscode | technical program manager, open source
© 206.607.7108 | (t) @btmspox | (b) http://blog.loftninjas.org


#10

It appears that behavior still is there. I don’t quite understand the
reasoning for that either. Surely, if you wanted to manage a repo file
with a LWRP, wouldn’t you want it to wipe out the file, and place the
correct contents in there via template?

That is, if its managed via a template resource… Then, one would
expect the template resource to do the right thing and re-write it, or
check that the file is correct and then move on. If I needed to change
the baseurl, I want the template resource to correct that url on every
node, not skip over it if the file exists. Having to wipe out the file
on each node, just seems wrong.

Eric G. Wolfe
Senior Linux Administrator,
IT Infrastructure Systems

Marshall University Computing Services
Drinko Library 428-K
One John Marshall Dr.
Huntington, WV 25755
Phone: 304.942.3970
Email: eric.wolfe@marshall.edu

You will be recognized and honored as a community leader.

On 11/20/2012 06:13 PM, steve . wrote:

Internally, we’ve gone as far as writing an ohai plugin that
determines whether or not we’re in a restricted data center
environment before overriding yum repository sources and
enabling/disabling repos.

On a related note, I can’t remember whether or not the yum_repo LWRP
parses existing files for options in its load_current_resource() or
just checks to see whether or not the file exists … I just remember
that when I change a Yum mirror I find that the mirrors don’t get
updated on my nodes until I nuke the repo file from /etc/yum.repos.d.
But this is with an old fork… is that behavior still around?

On Sat, Nov 17, 2012 at 9:11 AM, Joshua Buysse <buysse@umn.edu
mailto:buysse@umn.edu> wrote:

In that case, I'd fork the yum cookbook locally and override the
epel recipe to do what I want with a local repo. For a cookbook,
activating epel is the best general solution - if you're one of
the small percentage that won't work for, it's easy enough to
replace without problem as long as the cookbook uses yum::epel.

I would do the same thing for anything involving rpmforge, for
example. I have a few packages that I rebuilt/resigned locally,
but I haven't run in to that with a cookbook yet.

On Nov 17, 2012, at 9:11, Jeffrey Hulten <jeffh@automatedlabs.com
<mailto:jeffh@automatedlabs.com>> wrote:

> Often I need things from EPEL but I also tend to create my own
YUM mirror so I know what versions I am getting if I bring up a
new box. In this case adding a repo would circumvent my controls.
> --
> Jeffrey Hulten
> Principal Consultant at Automated Labs, LLC
> jeffh@automatedlabs.com <mailto:jeffh@automatedlabs.com>
206-853-5216 <tel:206-853-5216>
> Skype: jeffhulten
>
> On Nov 16, 2012, at 9:56 PM, Tim Smith wrote:
>
>> Most everything we try to do requires EPEL so we have it enabled on
>> anything in Redhat-land.
>>
>> Tim Smith
>> Operations Engineer, SaaS Operations
>> M: +1 707.738.8132 <tel:%2B1%20707.738.8132>
>> TW: @tas50
>> webtrends <http://www.webtrends.com/>
>> Real-Time Relevance. Remarkable ROI.™
>> London | Portland | San Francisco | Melbourne | Tokyo
>>
>>
>>
>>
>>
>>
>> On 11/16/12 1:51 PM, "Eric G. Wolfe" <eric.wolfe@marshall.edu
<mailto:eric.wolfe@marshall.edu>> wrote:
>>
>>> I can't speak for everyone on RHEL/CentOS, but I think there
is at least
>>> one-off package from EPEL on every one of our systems.  When
writing a
>>> community cookbook, I never assume the end user has EPEL
enabled, it
>>> does need to be coded into the recipe (or at least included via
>>> yum::epel).  When I opened COOK-1772, the goal was to make that a
>>> uniform pattern which makes use of the yum::repository LWRP.
>>>
>>> Unfortunately I think there are still multiple issues with the yum
>>> cookbook on Amazon Linux, thanks to their platform_version
differences.
>>> This isn't directly related to your question, but shouldn't EL
family
>>> platforms return a consistent version number (OHAI-321)?
>>>
>>> Eric G. Wolfe
>>> Senior Linux Administrator,
>>> IT Infrastructure Systems
>>> --------------------------------------
>>> Marshall University Computing Services
>>> Drinko Library 428-K
>>> One John Marshall Dr.
>>> Huntington, WV 25755
>>> Phone: 304.942.3970 <tel:304.942.3970>
>>> Email: eric.wolfe@marshall.edu <mailto:eric.wolfe@marshall.edu>
>>>
>>> You will be recognized and honored as a community leader.
>>>
>>> On 11/16/2012 04:29 PM, Bryan McLellan wrote:
>>>> Would you be surprised if you ran a community cookbook for a
piece of
>>>> software and it configured EPEL to do so?
>>>>
>>>> It seems like getting most things done requires it, but we
haven't made
>>>> a
>>>> global pattern yet to override the use of EPEL yet.
>>>>
>>>> If everyone just uses EPEL, then it is a moot point.
>>>>
>>>> ---
>>>> Bryan McLellan | opscode | technical program manager, open source
>>>> (c) 206.607.7108 <tel:206.607.7108> | (t) @btmspox | (b)
http://blog.loftninjas.org
>>>>
>>>>
>>>
>>
>

#11

As of 0.8.2 the LWRP should now provide an update action. Shouldn’t be
necessary to nuke on disk files.
http://tickets.opscode.com/browse/COOK-1521

As to the original question, I wouldn’t be “suprised” to see this since its
already so common, but I do wish the pattern was more toward making it
configurable. We have internal repos, including internal mirrors of EPEL. I
don’t like when cookbooks blindly do a include_recipe "yum::epel" in
recipe.

I’d much rather see a boolean attribute of “use_public_epel” or something
with that intent. This way I have the option to use the external repo,
however I still have the flexibility to use an internal repo if your nodes
don’t have access to the public net, or if you just don’t want to traverse
the wan link on multiple nodes, when you’ve got the same package available
internally.

On Tue, Nov 20, 2012 at 6:28 PM, Eric G. Wolfe eric.wolfe@marshall.eduwrote:

It appears that behavior still is there. I don’t quite understand the
reasoning for that either. Surely, if you wanted to manage a repo file
with a LWRP, wouldn’t you want it to wipe out the file, and place the
correct contents in there via template?

That is, if its managed via a template resource… Then, one would expect
the template resource to do the right thing and re-write it, or check that
the file is correct and then move on. If I needed to change the baseurl, I
want the template resource to correct that url on every node, not skip over
it if the file exists. Having to wipe out the file on each node, just
seems wrong.

Eric G. Wolfe
Senior Linux Administrator,
IT Infrastructure Systems

Marshall University Computing Services
Drinko Library 428-K
One John Marshall Dr.
Huntington, WV 25755
Phone: 304.942.3970
Email: eric.wolfe@marshall.edu

You will be recognized and honored as a community leader.

On 11/20/2012 06:13 PM, steve . wrote:

Internally, we’ve gone as far as writing an ohai plugin that determines
whether or not we’re in a restricted data center environment before
overriding yum repository sources and enabling/disabling repos.

On a related note, I can’t remember whether or not the yum_repo LWRP
parses existing files for options in its load_current_resource() or just
checks to see whether or not the file exists … I just remember that when
I change a Yum mirror I find that the mirrors don’t get updated on my nodes
until I nuke the repo file from /etc/yum.repos.d. But this is with an old
fork… is that behavior still around?

On Sat, Nov 17, 2012 at 9:11 AM, Joshua Buysse buysse@umn.edu wrote:

In that case, I’d fork the yum cookbook locally and override the epel
recipe to do what I want with a local repo. For a cookbook, activating epel
is the best general solution - if you’re one of the small percentage that
won’t work for, it’s easy enough to replace without problem as long as the
cookbook uses yum::epel.

I would do the same thing for anything involving rpmforge, for example. I
have a few packages that I rebuilt/resigned locally, but I haven’t run in
to that with a cookbook yet.

On Nov 17, 2012, at 9:11, Jeffrey Hulten jeffh@automatedlabs.com wrote:

Often I need things from EPEL but I also tend to create my own YUM
mirror so I know what versions I am getting if I bring up a new box. In
this case adding a repo would circumvent my controls.

Jeffrey Hulten
Principal Consultant at Automated Labs, LLC
jeffh@automatedlabs.com 206-853-5216
Skype: jeffhulten

On Nov 16, 2012, at 9:56 PM, Tim Smith wrote:

Most everything we try to do requires EPEL so we have it enabled on
anything in Redhat-land.

Tim Smith
Operations Engineer, SaaS Operations
M: +1 707.738.8132 <%2B1%20707.738.8132>
TW: @tas50
webtrends http://www.webtrends.com/
Real-Time Relevance. Remarkable ROI.™
London | Portland | San Francisco | Melbourne | Tokyo

On 11/16/12 1:51 PM, “Eric G. Wolfe” eric.wolfe@marshall.edu wrote:

I can’t speak for everyone on RHEL/CentOS, but I think there is at
least

one-off package from EPEL on every one of our systems. When writing a
community cookbook, I never assume the end user has EPEL enabled, it
does need to be coded into the recipe (or at least included via
yum::epel). When I opened COOK-1772, the goal was to make that a
uniform pattern which makes use of the yum::repository LWRP.

Unfortunately I think there are still multiple issues with the yum
cookbook on Amazon Linux, thanks to their platform_version
differences.

This isn’t directly related to your question, but shouldn’t EL family
platforms return a consistent version number (OHAI-321)?

Eric G. Wolfe
Senior Linux Administrator,
IT Infrastructure Systems

Marshall University Computing Services
Drinko Library 428-K
One John Marshall Dr.
Huntington, WV 25755
Phone: 304.942.3970
Email: eric.wolfe@marshall.edu

You will be recognized and honored as a community leader.

On 11/16/2012 04:29 PM, Bryan McLellan wrote:

Would you be surprised if you ran a community cookbook for a piece of
software and it configured EPEL to do so?

It seems like getting most things done requires it, but we haven’t
made

a
global pattern yet to override the use of EPEL yet.

If everyone just uses EPEL, then it is a moot point.


Bryan McLellan | opscode | technical program manager, open source
© 206.607.7108 | (t) @btmspox | (b) http://blog.loftninjas.org


#12

Ohai,

On 11/20/12 6:30 PM, “David Petzel” davidpetzel@gmail.com wrote:

I’d much rather see a boolean attribute of “use_public_epel” or something
with that intent. This way I have the option to use the external repo,
however I still have the flexibility to use an internal repo if your
nodes don’t have access to the public net, or if you just don’t want to
traverse the wan link on multiple nodes, when you’ve got the same package
available internally.

The current version of the cookbook, 2.0.0, has an attribute for setting
the EPEL URL:

node['yum']['epel']['url']

By default its the appropriate mirror list URL from the Fedora project
site based on platform and platform version.

If you have an internal yum repository that you use for EPEL, or to
"mimic" EPEL, you can use that URL instead.


Opscode, Inc
Joshua Timberman, Technical Community Manager
IRC, Skype, Twitter, Github: jtimberman


#13

Joshua, because of COOK-1653, I don’t think he could do that unless he
actually provided a mirrorlist.

When that LWRP first got released, mirrorlist was a boolean. So if
mirrorlist was true, it sets the url as the mirrorlist in the template.
If mirrorlist was false, it places the url as baseurl, in the template.
Because EPEL uses a mirrorlist, if you passed in a baseurl of a local
mirror, it would probably not work with the mirrorlist keyword in the
rendered template. We don’t really have the logic to handle that in the
recipe, it passes in mirrorlist blindly without any sanity checking here.

The recipe as it stands.

yum_repository “epel” do
description "Extra Packages for Enterprise Linux"
key node[‘yum’][‘epel’][‘key’]
mirrorlist node[‘yum’][‘epel’][‘url’]
action platform?(‘amazon’) ? [:add, :update] : :add
end

If we were to revert to using a pure boolean (not a boolean -OR- a
string for mirrorlist), one could set the mirrorlist to false, set the
url to the baseurl of the local mirror, and let the template handle the
logic. On the other hand, you could set mirrorlist to true, and the url
attribute to the EPEL mirrorlist if you wanted to use the default
behavior. Again letting the template handle that url/mirrorlist
switching logic.

Eric G. Wolfe
Senior Linux Administrator,
IT Infrastructure Systems

Marshall University Computing Services
Drinko Library 428-K
One John Marshall Dr.
Huntington, WV 25755
Phone: 304.942.3970
Email: eric.wolfe@marshall.edu

You will be recognized and honored as a community leader.

On 11/20/2012 08:56 PM, Joshua Timberman wrote:

Ohai,

On 11/20/12 6:30 PM, “David Petzel” davidpetzel@gmail.com wrote:

I’d much rather see a boolean attribute of “use_public_epel” or something
with that intent. This way I have the option to use the external repo,
however I still have the flexibility to use an internal repo if your
nodes don’t have access to the public net, or if you just don’t want to
traverse the wan link on multiple nodes, when you’ve got the same package
available internally.
The current version of the cookbook, 2.0.0, has an attribute for setting
the EPEL URL:

 node['yum']['epel']['url']

By default its the appropriate mirror list URL from the Fedora project
site based on platform and platform version.

If you have an internal yum repository that you use for EPEL, or to
"mimic" EPEL, you can use that URL instead.


#14

To clarify, that logic could be handled in either the LWRP itself, or
the template. The calling recipe using the LWRP should be kept kludge
free, if possible. In other words, it should be clear to the end-user
(of the LWRP) that the LWRP will make the right decision to set a
mirrorlist or baseurl.

Eric G. Wolfe
Senior Linux Administrator,
IT Infrastructure Systems

Marshall University Computing Services
Drinko Library 428-K
One John Marshall Dr.
Huntington, WV 25755
Phone: 304.942.3970
Email: eric.wolfe@marshall.edu

You will be recognized and honored as a community leader.

On 11/20/2012 09:29 PM, Eric G. Wolfe wrote:

Joshua, because of COOK-1653, I don’t think he could do that unless he
actually provided a mirrorlist.

When that LWRP first got released, mirrorlist was a boolean. So if
mirrorlist was true, it sets the url as the mirrorlist in the
template. If mirrorlist was false, it places the url as baseurl, in
the template. Because EPEL uses a mirrorlist, if you passed in a
baseurl of a local mirror, it would probably not work with the
mirrorlist keyword in the rendered template. We don’t really have the
logic to handle that in the recipe, it passes in mirrorlist blindly
without any sanity checking here.

The recipe as it stands.

yum_repository “epel” do
description "Extra Packages for Enterprise Linux"
key node[‘yum’][‘epel’][‘key’]
mirrorlist node[‘yum’][‘epel’][‘url’]
action platform?(‘amazon’) ? [:add, :update] : :add
end

If we were to revert to using a pure boolean (not a boolean -OR- a
string for mirrorlist), one could set the mirrorlist to false, set the
url to the baseurl of the local mirror, and let the template handle
the logic. On the other hand, you could set mirrorlist to true, and
the url attribute to the EPEL mirrorlist if you wanted to use the
default behavior. Again letting the template handle that
url/mirrorlist switching logic.

Eric G. Wolfe
Senior Linux Administrator,
IT Infrastructure Systems

Marshall University Computing Services
Drinko Library 428-K
One John Marshall Dr.
Huntington, WV 25755
Phone: 304.942.3970
Email: eric.wolfe@marshall.edu

You will be recognized and honored as a community leader.

On 11/20/2012 08:56 PM, Joshua Timberman wrote:

Ohai,

On 11/20/12 6:30 PM, “David Petzel” davidpetzel@gmail.com wrote:

I’d much rather see a boolean attribute of “use_public_epel” or
something
with that intent. This way I have the option to use the external repo,
however I still have the flexibility to use an internal repo if your
nodes don’t have access to the public net, or if you just don’t want to
traverse the wan link on multiple nodes, when you’ve got the same
package
available internally.
The current version of the cookbook, 2.0.0, has an attribute for setting
the EPEL URL:

 node['yum']['epel']['url']

By default its the appropriate mirror list URL from the Fedora project
site based on platform and platform version.

If you have an internal yum repository that you use for EPEL, or to
"mimic" EPEL, you can use that URL instead.


#15

Any changes you make to the .repo files need to also trigger yum to clear out its local cache on your node. I don’t know of a better way to trigger yum to clear out its cache, except for an execute resource that runs “yum clean all” whose default action is set to :nothing. Obviously, your template resources that create the .repo files, should notify that execute resource that runs “yum clean all”.

execute “yum_clean_all” do
command "yum clean all"
action :nothing
end

template “/etc/yum.repos.d/blah.repo” do
notifies :run, "execute[yum clean all]"
end

Obviously, these are very simple examples, but you get the picture.

–Dang

On 11/20/12 3:28 PM, “Eric G. Wolfe” <eric.wolfe@marshall.edumailto:eric.wolfe@marshall.edu> wrote:

It appears that behavior still is there. I don’t quite understand the reasoning for that either. Surely, if you wanted to manage a repo file with a LWRP, wouldn’t you want it to wipe out the file, and place the correct contents in there via template?

That is, if its managed via a template resource… Then, one would expect the template resource to do the right thing and re-write it, or check that the file is correct and then move on. If I needed to change the baseurl, I want the template resource to correct that url on every node, not skip over it if the file exists. Having to wipe out the file on each node, just seems wrong.

Eric G. Wolfe
Senior Linux Administrator,
IT Infrastructure Systems

Marshall University Computing Services
Drinko Library 428-K
One John Marshall Dr.
Huntington, WV 25755
Phone: 304.942.3970
Email: eric.wolfe@marshall.edumailto:eric.wolfe@marshall.edu

You will be recognized and honored as a community leader.

On 11/20/2012 06:13 PM, steve . wrote:
Internally, we’ve gone as far as writing an ohai plugin that determines whether or not we’re in a restricted data center environment before overriding yum repository sources and enabling/disabling repos.

On a related note, I can’t remember whether or not the yum_repo LWRP parses existing files for options in its load_current_resource() or just checks to see whether or not the file exists … I just remember that when I change a Yum mirror I find that the mirrors don’t get updated on my nodes until I nuke the repo file from /etc/yum.repos.d. But this is with an old fork… is that behavior still around?

On Sat, Nov 17, 2012 at 9:11 AM, Joshua Buysse <buysse@umn.edumailto:buysse@umn.edu> wrote:
In that case, I’d fork the yum cookbook locally and override the epel recipe to do what I want with a local repo. For a cookbook, activating epel is the best general solution - if you’re one of the small percentage that won’t work for, it’s easy enough to replace without problem as long as the cookbook uses yum::epel.

I would do the same thing for anything involving rpmforge, for example. I have a few packages that I rebuilt/resigned locally, but I haven’t run in to that with a cookbook yet.

On Nov 17, 2012, at 9:11, Jeffrey Hulten <jeffh@automatedlabs.commailto:jeffh@automatedlabs.com> wrote:

Often I need things from EPEL but I also tend to create my own YUM mirror so I know what versions I am getting if I bring up a new box. In this case adding a repo would circumvent my controls.

Jeffrey Hulten
Principal Consultant at Automated Labs, LLC
jeffh@automatedlabs.commailto:jeffh@automatedlabs.com 206-853-5216tel:206-853-5216
Skype: jeffhulten

On Nov 16, 2012, at 9:56 PM, Tim Smith wrote:

Most everything we try to do requires EPEL so we have it enabled on
anything in Redhat-land.

Tim Smith
Operations Engineer, SaaS Operations
M: +1 707.738.8132tel:%2B1%20707.738.8132
TW: @tas50
webtrends http://www.webtrends.com/
Real-Time Relevance. Remarkable ROI.™
London | Portland | San Francisco | Melbourne | Tokyo

On 11/16/12 1:51 PM, “Eric G. Wolfe” <eric.wolfe@marshall.edumailto:eric.wolfe@marshall.edu> wrote:

I can’t speak for everyone on RHEL/CentOS, but I think there is at least
one-off package from EPEL on every one of our systems. When writing a
community cookbook, I never assume the end user has EPEL enabled, it
does need to be coded into the recipe (or at least included via
yum::epel). When I opened COOK-1772, the goal was to make that a
uniform pattern which makes use of the yum::repository LWRP.

Unfortunately I think there are still multiple issues with the yum
cookbook on Amazon Linux, thanks to their platform_version differences.
This isn’t directly related to your question, but shouldn’t EL family
platforms return a consistent version number (OHAI-321)?

Eric G. Wolfe
Senior Linux Administrator,
IT Infrastructure Systems

Marshall University Computing Services
Drinko Library 428-K
One John Marshall Dr.
Huntington, WV 25755
Phone: 304.942.3970tel:304.942.3970
Email: eric.wolfe@marshall.edumailto:eric.wolfe@marshall.edu

You will be recognized and honored as a community leader.

On 11/16/2012 04:29 PM, Bryan McLellan wrote:

Would you be surprised if you ran a community cookbook for a piece of
software and it configured EPEL to do so?

It seems like getting most things done requires it, but we haven’t made
a
global pattern yet to override the use of EPEL yet.

If everyone just uses EPEL, then it is a moot point.


Bryan McLellan | opscode | technical program manager, open source
© 206.607.7108tel:206.607.7108 | (t) @btmspox | (b) http://blog.loftninjas.org


#16

Changes made via the yum LWRP will trigger an immediate cache rebuild, even
in the Precambrian-era version of the cookbook that I’m using… :wink:

On Wed, Nov 21, 2012 at 10:07 AM, Nguyen, Dang Dang.Nguyen@disney.comwrote:

Any changes you make to the .repo files need to also trigger yum to clear
out its local cache on your node. I don’t know of a better way to trigger
yum to clear out its cache, except for an execute resource that runs “yum
clean all” whose default action is set to :nothing. Obviously, your
template resources that create the .repo files, should notify that execute
resource that runs “yum clean all”.

execute “yum_clean_all” do
command "yum clean all"
action :nothing
end

template “/etc/yum.repos.d/blah.repo” do
notifies :run, "execute[yum clean all]"
end

Obviously, these are very simple examples, but you get the picture.

–Dang

On 11/20/12 3:28 PM, “Eric G. Wolfe” eric.wolfe@marshall.edu wrote:

It appears that behavior still is there. I don’t quite understand the
reasoning for that either. Surely, if you wanted to manage a repo file
with a LWRP, wouldn’t you want it to wipe out the file, and place the
correct contents in there via template?

That is, if its managed via a template resource… Then, one would expect
the template resource to do the right thing and re-write it, or check that
the file is correct and then move on. If I needed to change the baseurl, I
want the template resource to correct that url on every node, not skip over
it if the file exists. Having to wipe out the file on each node, just
seems wrong.

Eric G. Wolfe
Senior Linux Administrator,
IT Infrastructure Systems

Marshall University Computing Services
Drinko Library 428-K
One John Marshall Dr.
Huntington, WV 25755
Phone: 304.942.3970
Email: eric.wolfe@marshall.edu

You will be recognized and honored as a community leader.

On 11/20/2012 06:13 PM, steve . wrote:

Internally, we’ve gone as far as writing an ohai plugin that determines
whether or not we’re in a restricted data center environment before
overriding yum repository sources and enabling/disabling repos.

On a related note, I can’t remember whether or not the yum_repo LWRP
parses existing files for options in its load_current_resource() or just
checks to see whether or not the file exists … I just remember that when
I change a Yum mirror I find that the mirrors don’t get updated on my nodes
until I nuke the repo file from /etc/yum.repos.d. But this is with an old
fork… is that behavior still around?

On Sat, Nov 17, 2012 at 9:11 AM, Joshua Buysse buysse@umn.edu wrote:

In that case, I’d fork the yum cookbook locally and override the epel
recipe to do what I want with a local repo. For a cookbook, activating epel
is the best general solution - if you’re one of the small percentage that
won’t work for, it’s easy enough to replace without problem as long as the
cookbook uses yum::epel.

I would do the same thing for anything involving rpmforge, for example. I
have a few packages that I rebuilt/resigned locally, but I haven’t run in
to that with a cookbook yet.

On Nov 17, 2012, at 9:11, Jeffrey Hulten jeffh@automatedlabs.com wrote:

Often I need things from EPEL but I also tend to create my own YUM
mirror so I know what versions I am getting if I bring up a new box. In
this case adding a repo would circumvent my controls.

Jeffrey Hulten
Principal Consultant at Automated Labs, LLC
jeffh@automatedlabs.com 206-853-5216
Skype: jeffhulten

On Nov 16, 2012, at 9:56 PM, Tim Smith wrote:

Most everything we try to do requires EPEL so we have it enabled on
anything in Redhat-land.

Tim Smith
Operations Engineer, SaaS Operations
M: +1 707.738.8132
TW: @tas50
webtrends http://www.webtrends.com/
Real-Time Relevance. Remarkable ROI.™
London | Portland | San Francisco | Melbourne | Tokyo

On 11/16/12 1:51 PM, “Eric G. Wolfe” eric.wolfe@marshall.edu wrote:

I can’t speak for everyone on RHEL/CentOS, but I think there is at
least

one-off package from EPEL on every one of our systems. When writing a
community cookbook, I never assume the end user has EPEL enabled, it
does need to be coded into the recipe (or at least included via
yum::epel). When I opened COOK-1772, the goal was to make that a
uniform pattern which makes use of the yum::repository LWRP.

Unfortunately I think there are still multiple issues with the yum
cookbook on Amazon Linux, thanks to their platform_version
differences.

This isn’t directly related to your question, but shouldn’t EL family
platforms return a consistent version number (OHAI-321)?

Eric G. Wolfe
Senior Linux Administrator,
IT Infrastructure Systems

Marshall University Computing Services
Drinko Library 428-K
One John Marshall Dr.
Huntington, WV 25755
Phone: 304.942.3970
Email: eric.wolfe@marshall.edu

You will be recognized and honored as a community leader.

On 11/16/2012 04:29 PM, Bryan McLellan wrote:

Would you be surprised if you ran a community cookbook for a piece of
software and it configured EPEL to do so?

It seems like getting most things done requires it, but we haven’t
made

a
global pattern yet to override the use of EPEL yet.

If everyone just uses EPEL, then it is a moot point.


Bryan McLellan | opscode | technical program manager, open source
© 206.607.7108 | (t) @btmspox | (b) http://blog.loftninjas.org


#17

I prefer writing small recipes in a yum cookbook that manages the .repo files for yum individually and have yum.conf “include” /etc/yum.repos.d/*.repo files. You can choose to manage your .repo files with a template or with static file resources at that point. Then, bubble up to the role to include/exclude whichever repos your nodes need. You could also have something that deletes extra .repo files from the directory if you care about a clean configuration. I find this much easier to navigate when a sys admin needs to look at the local yum configuration – they don’t need to search through a huge monolithic yum .repo file to find the one they need.

For my team, we’ve also got in-house developed RPMs for our internal services. We manage promotion of the RPMs throughout the SDLC, like so: 1) continuous build artifacts are dropped into a DEV repo, 2) promote to QA those builds that are ready for testing, 3) promote from QA when ready for UAT/production, 4) chef nodes get a different yum repo configuration based on their environment, as defined on the chef server. #1-3 are automated by our orchestration tool, and #4 is a recipe with some logic that ties into node.chef_environment to drop the right yum .repo file in place.

On 11/16/12 1:36 PM, “Jamie Winsor” <jamie@vialstudios.commailto:jamie@vialstudios.com> wrote:

Bryan,

Our application cookbooks will enable EPEL if they are attempting to retrieve a package which requires it. The same goes for any of our library cookbooks which have a package contained there. We always make these cookbooks configurable, though, so you can instead retrieve your package out of a self hosted repository.

EPEL is more of a sensible default for us.


Jamie Winsor
@resetexistence

On Friday, November 16, 2012 at 1:29 PM, Bryan McLellan wrote:

Would you be surprised if you ran a community cookbook for a piece of
software and it configured EPEL to do so?

It seems like getting most things done requires it, but we haven’t made a
global pattern yet to override the use of EPEL yet.

If everyone just uses EPEL, then it is a moot point.


Bryan McLellan | opscode | technical program manager, open source
© 206.607.7108 | (t) @btmspox | (b) http://blog.loftninjas.org


#18

I suppose I’m going against the grain here, but in our house I wrote a
different recipe yum::attribute_hash that parses a hash from attributes to
generate all of the .repo files, rather than having a separate recipe for
each one. This allows us to be consistent in placing the repo url locations
into our different environment files.

the hash looks like this:
:repo => {
:list => {
“CentOS-Base” => {
:url => “
http://yum-web.internal:8080/CentOS/$releasever/os/$basearch/”,
:enabled => true
}
}
}

Anything that isn’t in the list gets wiped out by the recipe, so someone
adding yum::epel to a recipe would cause chef to create the epel .repo
file, flush the yum cache, then wipe it out again and re-flush the cache,
for every run (unless it was also added to the attribute hash).

Not exactly ideal.

I can post the recipe for those interested.

-Jesse

On Fri, Nov 16, 2012 at 4:29 PM, Bryan McLellan btm@opscode.com wrote:

Would you be surprised if you ran a community cookbook for a piece of
software and it configured EPEL to do so?

It seems like getting most things done requires it, but we haven’t made a
global pattern yet to override the use of EPEL yet.

If everyone just uses EPEL, then it is a moot point.


Bryan McLellan | opscode | technical program manager, open source
© 206.607.7108 | (t) @btmspox | (b) http://blog.loftninjas.org