Rails versions for 0.25
Luke Kanies
As most of you know, we haven't been keeping up to date in our Rails
dependencies - until 0.25, Puppet only worked with Rails 2.0 or so.
As an attempt to fix this, we've made sure we're now compatible with
2.3, and I've set up the dependencies so that it *only* works with
2.3. I did this because it seems better to fail immediately than deal
with the stupidities resulting from incompatibilities.
It's been brought to my attention that, at the least, this change in
requirement should be listed on the release doc for 0.25 (which it
definitely should), but that also most distros are running far behind
2.3, and are more likely to be running something like 2.1.
Does anyone know enough about Rails to know whether we can reasonably
provide compatibility to a range of releases? Are we being too
restrictive by requiring a specific version?
--
It is odd, but on the infrequent occasions when I have been called upon
in a formal place to play the bongo drums, the introducer never seems
to find it necessary to mention that I also do theoretical physics.
-- Richard Feynman
---------------------------------------------------------------------
Luke Kanies -|- http://reductivelabs.com -|- +1(615)594-8199
Ryan Dooley
[*snip*]
> Does anyone know enough about Rails to know whether we can reasonably
> provide compatibility to a range of releases? Are we being too
> restrictive by requiring a specific version?
I'm not a 'rails guy' but in general I think that might be too
restrictive (at least for my production environment). In that case what
I would probably end up doing, because (for me) disk space is cheap,
would be to compile a custom version of ruby/rails/other dependencies
and point puppet at that tree.
Is the situation bad enough to say you need at least >=2.0?
I actually don't mind having the restriction I'll just need to hack
around it :)
Cheers,
Ryan
Stéphan Gorget
repositories if the dependencies aren't ?
--
Stéphan Gorget
Nicholas E. Hubbard
As far as distros being behind and around 2.1. This is mostly true, but at the same time, puppet in most distros is behind also. If you are installing puppet via gems it is not difficult also install rails via gems. If you are installing from source then the installing probably has the knowledge required to install rails 2.3 also.
So as a user I would actually prefer puppet being locked to the most recent supported version of rails. It would make life easier for me. As I currently have to have two separate rails profiles to handle rails on the puppet server and rails on a rails server.
Just my two cents on this.
Nicholas Hubbard
Ryan Dooley
dependencies in much the same way that a rails app would include a
vendor directory?
Might make it easier to just include what you need and not fall back on
external dependencies other than ruby.
Cheers,
Ryan
Luke Kanies
>
> How could puppet 0.25 be provided through standard package
> repositories if the dependencies aren't ?
>
> On Wed, May 13, 2009 at 8:58 PM, Ryan Dooley <ryan....@gmail.com>
> wrote:
>>
>> Luke Kanies wrote:
>>
>> [*snip*]
>>
>>> Does anyone know enough about Rails to know whether we can
>>> reasonably
>>> provide compatibility to a range of releases? Are we being too
>>> restrictive by requiring a specific version?
>>
>> I'm not a 'rails guy' but in general I think that might be too
>> restrictive (at least for my production environment). In that case
>> what
>> I would probably end up doing, because (for me) disk space is cheap,
>> would be to compile a custom version of ruby/rails/other dependencies
>> and point puppet at that tree.
>>
>> Is the situation bad enough to say you need at least >=2.0?
>>
>> I actually don't mind having the restriction I'll just need to hack
>> around it :)
>>
>> Cheers,
>> Ryan
>>
>>
>>>
>>
>
> >
I'm worried about Bart. Today, he's sucking people's blood,
tommorrow he might be smoking. -Marge Simpson
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com
Luke Kanies
>
> Actually I was curious if puppet could include it's own vendor
> dependencies in much the same way that a rails app would include a
> vendor directory?
>
> Might make it easier to just include what you need and not fall back
> on
> external dependencies other than ruby.
This is one of the things I hate most about the Rails community -- I
complain about it so loudly that some Rails dev friends of mine make a
shirt that says "I just put it in vendor!".
Basically, if you do this you're saying that you don't need or trust
packaging, which is the road to support nightmares.
I'd rather spend a bit of extra effort in Puppet trying to support
multiple versions than try to ship Rails (which is huge, relatively
speaking) as part of Puppet.
--
He is indebted to his memory for his jests and to his imagination for
his facts. --Richard Brinsley Sheridan
Luke Kanies
> I use puppet to manage my rails servers and can personally tell you
> it is a best practice with Rails applications to lock them to a
> specific version. This is because so much changes in the underlying
> versions.
>
> As far as distros being behind and around 2.1. This is mostly true,
> but at the same time, puppet in most distros is behind also. If you
> are installing puppet via gems it is not difficult also install
> rails via gems. If you are installing from source then the
> installing probably has the knowledge required to install rails 2.3
> also.
>
> So as a user I would actually prefer puppet being locked to the most
> recent supported version of rails. It would make life easier for me.
> As I currently have to have two separate rails profiles to handle
> rails on the puppet server and rails on a rails server.
Is there something about Rails discussions that suddenly makes people
top-reply? :)
We can handle gems requiring the correct version pretty easily, but
managing the distros is less easy.
Seems like we should either require an older version, or see if we can
support, say, 2.1-2.3.
Is anyone in a position to be able to test the current code (minus the
2.3 restriction) on these three versions of Rails?
--
Criminal: A person with predatory instincts who has not sufficient
capital to form a corporation. --Howard Scott
Micah Anderson
This is a bit of an older thread, but I found it because I was wandering
through the archives trying to find an answer to my question:
why specifically is rails 2.2.2 is a requirement for 0.25? The release
notes[0] say:
Rails versions up to 2.3.x are now supported. Rails version
2.2.2 or greater is required.
However, I cannot find anywhere that details why 2.2.2. Debian's stable
is at 2.1, and I'm wondering if installing 0.25.x on those stable
systems is asking for a problem, if so what are those problems?
Luke Kanies <lu...@madstop.com> writes:
>This is one of the things I hate most about the Rails community -- I
>complain about it so loudly that some Rails dev friends of mine make a
>shirt that says "I just put it in vendor!".
to re-explain why it is a bad thing, over and over again.
> On May 13, 2009, at 12:59 PM, Nicholas E. Hubbard wrote:
>
>> I use puppet to manage my rails servers and can personally tell you
>> it is a best practice with Rails applications to lock them to a
>> specific version. This is because so much changes in the underlying
>> versions.
does not give something much weight at all, there are a lot of best
practices with Rails that are absurd and this is one of them.
> Is there something about Rails discussions that suddenly makes people
> top-reply? :)
> Seems like we should either require an older version, or see if we can
> support, say, 2.1-2.3.
indication of why 2.2.2 was chosen somewhere?
thanks!
micah
0. http://reductivelabs.com/trac/puppet/wiki/ReleaseNotes
Luke Kanies
>
> This is a bit of an older thread, but I found it because I was
> wandering
> through the archives trying to find an answer to my question:
>
> why specifically is rails 2.2.2 is a requirement for 0.25? The release
> notes[0] say:
>
> Rails versions up to 2.3.x are now supported. Rails version
> 2.2.2 or greater is required.
>
> However, I cannot find anywhere that details why 2.2.2. Debian's
> stable
> is at 2.1, and I'm wondering if installing 0.25.x on those stable
> systems is asking for a problem, if so what are those problems?
the Rails feature in the code, which should be the final arbiter.
>
> You received this message because you are subscribed to the Google
> Groups "Puppet Developers" group.
> To post to this group, send email to puppe...@googlegroups.com.
> To unsubscribe from this group, send email to puppet-dev+...@googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en
> .
>
>
--
Writing is not necessarily something to be ashamed of, but do it in
private and wash your hands afterwards. --Robert Heinlein
Eric Gerlach
> On Dec 1, 2009, at 6:43 PM, Micah Anderson wrote:
>
> >
> > This is a bit of an older thread, but I found it because I was
> > wandering
> > through the archives trying to find an answer to my question:
> >
> > why specifically is rails 2.2.2 is a requirement for 0.25? The release
> > notes[0] say:
> >
> > Rails versions up to 2.3.x are now supported. Rails version
> > 2.2.2 or greater is required.
> >
> > However, I cannot find anywhere that details why 2.2.2. Debian's
> > stable
> > is at 2.1, and I'm wondering if installing 0.25.x on those stable
> > systems is asking for a problem, if so what are those problems?
>
> This is incorrect - 2.1 and later are supported, at least according to
> the Rails feature in the code, which should be the final arbiter.
to 2.2 to fix the problems I was having. See thread in puppet-users. Should I
file a bug?
Cheers,
--
Eric Gerlach, Network Administrator
Federation of Students
University of Waterloo
p: (519) 888-4567 x36329
e: eger...@feds.uwaterloo.ca
Luke Kanies
> On Tue, Dec 01, 2009 at 09:50:38PM -0800, Luke Kanies wrote:
>> On Dec 1, 2009, at 6:43 PM, Micah Anderson wrote:
>>
>>>
>>> This is a bit of an older thread, but I found it because I was
>>> wandering
>>> through the archives trying to find an answer to my question:
>>>
>>> why specifically is rails 2.2.2 is a requirement for 0.25? The
>>> release
>>> notes[0] say:
>>>
>>> Rails versions up to 2.3.x are now supported. Rails version
>>> 2.2.2 or greater is required.
>>>
>>> However, I cannot find anywhere that details why 2.2.2. Debian's
>>> stable
>>> is at 2.1, and I'm wondering if installing 0.25.x on those stable
>>> systems is asking for a problem, if so what are those problems?
>>
>> This is incorrect - 2.1 and later are supported, at least according
>> to
>> the Rails feature in the code, which should be the final arbiter.
>
> Except that Rails 2.1 + MySQL + no MQ = broken puppetmaster. I had
> to upgrade
> to 2.2 to fix the problems I was having. See thread in puppet-
> users. Should I
> file a bug?
Can you point me to the thread?
--
Consistency requires you to be as ignorant today as you were a year
ago. -- Bernard Berenson
Eric Gerlach
but I don't use one.
> Can you point me to the thread?
http://groups.google.com/group/puppet-users/browse_thread/thread/945f119c0f7eb450
Yannick Perret
I'm migrating my test master server to 0.25.1.
It works fine at this time with the following elements:
- ruby enterprise edition
- puppet-server (from sources) 0.25.1
- passenger 2.2.7
- httpd 2.2.3
All on a 64bit RHEL5-like distro.
As I have more than one master server, I plan to use a proxy-balancer on
top of passenger in order to balance the load over the machines.
So I created a balancer configuration for apache, on port 8140, and
moved the passenger configuration to port 8141.
The proxy-balancer owns only one "worker", the passenger port:
<Proxy balancer://puppetmaster>
BalancerMember http://localhost:8141
</Proxy>
If I run my client on port 8141 (directly on passenger) it works fine.
If I run my client on port 8140 I get strange result:
# puppetd --test
info: Loading facts in (...)
(...the list of facts...)
Could not run: Puppet::Resource::Catalog does not respond to from_s; can
not intern instances from text/plain
info: Loading facts in (...)
(...the list of facts...)
Could not run: Puppet::Resource::Catalog does not respond to from_s; can
not intern instances from text/plain
info: Loading facts in (...)
(...the list of facts...)
Could not run: Puppet::Resource::Catalog does not respond to from_s; can
not intern instances from text/plain
#
It is printed 3 times per run.
Is it a known problem to use a proxy-balancer in front of passenger?
I can join the apache config files if needed, but the passenger one
works fine alone, and the complete proxy-balancer one is the same than I
used previously with mongrel, which works fine to handle load-balancing
over my 3 master servers (I mean, it have all the SSL stuff in it).
Thanks for any help.
--
Yannick
Luke Kanies
Rails kept warning about it. Because they hate us.
I thought a ticket was opened for this, and that it was fixed, but I
can't seem to find one.
Am I crazy on this? Anyone else remember our decision to selectively
enable concurrency on older versions of Rails?
--
I used to get high on life but lately I've built up a resistance.
Todd Zullinger
> Ah; this was because we removed the concurrency setting. Because
> Rails kept warning about it. Because they hate us.
>
> I thought a ticket was opened for this, and that it was fixed, but I
> can't seem to find one.
>
> Am I crazy on this? Anyone else remember our decision to
> selectively enable concurrency on older versions of Rails?
Are you thinking of f0eaf20 (Fixing #2764 ActiveRecord 2.1 support)?
(Not that this proves you are _not_ crazy or anything.)
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I am in shape. Round is a shape.
Luke Kanies
> Luke Kanies wrote:
>> Ah; this was because we removed the concurrency setting. Because
>> Rails kept warning about it. Because they hate us.
>>
>> I thought a ticket was opened for this, and that it was fixed, but I
>> can't seem to find one.
>>
>> Am I crazy on this? Anyone else remember our decision to
>> selectively enable concurrency on older versions of Rails?
>
> Are you thinking of f0eaf20 (Fixing #2764 ActiveRecord 2.1 support)?
>
Ah, yeah, that would be it.
So looks like it'll be in 0.25.2.
--
In theory, there is no difference between theory and practice; in
practice, there is. -- Chuck Reid
Yannick Perret
>
> I'm migrating my test master server to 0.25.1.
> It works fine at this time with the following elements:
> - ruby enterprise edition
> - puppet-server (from sources) 0.25.1
> - passenger 2.2.7
> - httpd 2.2.3
> All on a 64bit RHEL5-like distro.
>
> As I have more than one master server, I plan to use a proxy-balancer on
> top of passenger in order to balance the load over the machines.
> So I created a balancer configuration for apache, on port 8140, and
> moved the passenger configuration to port 8141.
> The proxy-balancer owns only one "worker", the passenger port:
> <Proxy balancer://puppetmaster>
> BalancerMember http://localhost:8141
> </Proxy>
>
> If I run my client on port 8141 (directly on passenger) it works fine.
> If I run my client on port 8140 I get strange result:
>
after various modifications and the same number of fails, I used a
simple TCP proxy (transparent proxy, without any kind of SSL knowledge,
nor HTTP) and it works fine (until now).
So, if some are interrested, the lesson is: do not use a proxy-ssl in
front of puppetmaster/passenger, but a transparent proxy.
--
Y.
> # puppetd --test
> info: Loading facts in (...)
> (...the list of facts...)
> Could not run: Puppet::Resource::Catalog does not respond to from_s; can
> not intern instances from text/plain
> info: Loading facts in (...)
> (...the list of facts...)
> Could not run: Puppet::Resource::Catalog does not respond to from_s; can
> not intern instances from text/plain
> info: Loading facts in (...)
> (...the list of facts...)
> Could not run: Puppet::Resource::Catalog does not respond to from_s; can
> not intern instances from text/plain
> #
>
> It is printed 3 times per run.
>
> Is it a known problem to use a proxy-balancer in front of passenger?
>
> I can join the apache config files if needed, but the passenger one
> works fine alone, and the complete proxy-balancer one is the same than I
> used previously with mongrel, which works fine to handle load-balancing
> over my 3 master servers (I mean, it have all the SSL stuff in it).
>
> Thanks for any help.
>
> --
> Yannick
>