Re: [Puppet Users] Re: Announce: Dashboard 1.2.0 is available now

2011-08-31 Thread Alexander Fortin

On 08/27/2011 08:07 PM, Ramin K wrote:

ruby 1.8.5, released Apr 2006
ruby 1.8.7, released May 2008
ruby 1.9.2, released Oct 2010

Not exactly bleeding edge though I suppose anything released in the
last four years could be considered that when compared to RHEL 5.:-)

FWIW, if you think of the releases as Ruby 1.0.x, 1.5.x, and 2.0.x
respectively the differences in capabilities will make more sense.


For my environment, having puppet agents = 2.6.4 is the only blocking 
issue, because I'd like to stay with Debian/Ubuntu packages and so far 
the most I can get from stable versions are 2.6.2 (the only exception 
being FreeBSD 8.2 shipping 2.6.7)


Argh... I just can't wait to see the new Dashboard! :D

--
Alexander Fortin
http://about.me/alexanderfortin/

--
You received this message because you are subscribed to the Google Groups Puppet 
Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



[Puppet Users] Re: Announce: Dashboard 1.2.0 is available now

2011-08-30 Thread David Thompson

 basically anyone attempting to do anything reasonable with ruby on RHEL 5.x 
 (or any of the free repackaged distributions of RHEL 5.x) knows that 1.8.5 
 version is just short of useless and has implemented other fixes.

Some comments on this thread, and current software development trends
in general.

Craig, the version of ruby that ships with RHEL 5 was good enough for
many things, including dashboard = 1.1.  So, while it may have
problems and limitations,  I think you overstate things to say it is
just short of useless.

Also, long in the tooth is subjective; RHEL 5 (and the derivative
works) are currently supported distributions with significant
installed user bases.  Many environments, for many different reasons,
have decided that EL is the best choice for them.  It's important to
respect those decisions.  As a system administrator, I see people
ignore compatibility with the EL distros regularly, and it's
unfortunate that many people wave their hands with phrases like 'long
in the tooth,' 'next to useless,' or 'any modern linux
distribution' (from another project I was asked to install recently),
which don't mesh well with the realities of significant parts of the
installed linux base.

In this case, as was pointed out, there are fairly simple ways to get
ruby 1.8.5 onto an EL 5 system.  But when someone writes an app
against the lastest and greatest libgtk and friends, and uses the most
recent versions of everything because that's what's available on their
latest ubuntu release, it simply cuts them off from many potential
users, for perhaps very little developer gain.  Developers should
consider carefully the run-time requirements vs. the target audience
as part of the development process.

I agree with Ramin that a different numbering scheme for ruby versions
would have made more sense.  A tiny version change (e.g. 1.8.5 to
1.8.7) would be understood in many release contexts to contain bug-
fixes only and introduce no higher-level incompatibilities (a very
broad simplification, but still true).  Version numbers mean something
very different to the ruby development team than they do to many other
knowledgeable people.

All that being said, if the dashboard development folks have decided
that 1.8.7 is needed, then 1.8.7 it is.  Perhaps pointers to suitable
ruby builds could be included in the release notes (or on the download
page, etc., etc.) as an aid to those who will need to upgrade.

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Re: Announce: Dashboard 1.2.0 is available now

2011-08-30 Thread Christopher McCrory
+1 for all of it.


On Tue, 2011-08-30 at 08:15 -0700, David Thompson wrote:
  basically anyone attempting to do anything reasonable with ruby on RHEL 5.x 
  (or any of the free repackaged distributions of RHEL 5.x) knows that 1.8.5 
  version is just short of useless and has implemented other fixes.
 
 Some comments on this thread, and current software development trends
 in general.
 
 Craig, the version of ruby that ships with RHEL 5 was good enough for
 many things, including dashboard = 1.1.  So, while it may have
 problems and limitations,  I think you overstate things to say it is
 just short of useless.
 
 Also, long in the tooth is subjective; RHEL 5 (and the derivative
 works) are currently supported distributions with significant
 installed user bases.  Many environments, for many different reasons,
 have decided that EL is the best choice for them.  It's important to
 respect those decisions.  As a system administrator, I see people
 ignore compatibility with the EL distros regularly, and it's
 unfortunate that many people wave their hands with phrases like 'long
 in the tooth,' 'next to useless,' or 'any modern linux
 distribution' (from another project I was asked to install recently),
 which don't mesh well with the realities of significant parts of the
 installed linux base.
 
 In this case, as was pointed out, there are fairly simple ways to get
 ruby 1.8.5 onto an EL 5 system.  But when someone writes an app
 against the lastest and greatest libgtk and friends, and uses the most
 recent versions of everything because that's what's available on their
 latest ubuntu release, it simply cuts them off from many potential
 users, for perhaps very little developer gain.  Developers should
 consider carefully the run-time requirements vs. the target audience
 as part of the development process.
 
 I agree with Ramin that a different numbering scheme for ruby versions
 would have made more sense.  A tiny version change (e.g. 1.8.5 to
 1.8.7) would be understood in many release contexts to contain bug-
 fixes only and introduce no higher-level incompatibilities (a very
 broad simplification, but still true).  Version numbers mean something
 very different to the ruby development team than they do to many other
 knowledgeable people.
 
 All that being said, if the dashboard development folks have decided
 that 1.8.7 is needed, then 1.8.7 it is.  Perhaps pointers to suitable
 ruby builds could be included in the release notes (or on the download
 page, etc., etc.) as an aid to those who will need to upgrade.
 


-- 
Christopher McCrory
To the optimist, the glass is half full.
To the pessimist, the glass is half empty.
To the engineer, the glass is twice as big as it needs to be.

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Re: Announce: Dashboard 1.2.0 is available now

2011-08-30 Thread Matt Robinson
On Tue, Aug 30, 2011 at 8:15 AM, David Thompson
dthomp...@waisman.wisc.edu wrote:

 basically anyone attempting to do anything reasonable with ruby on RHEL 5.x 
 (or any of the free repackaged distributions of RHEL 5.x) knows that 1.8.5 
 version is just short of useless and has implemented other fixes.

 Some comments on this thread, and current software development trends
 in general.

 Craig, the version of ruby that ships with RHEL 5 was good enough for
 many things, including dashboard = 1.1.  So, while it may have
 problems and limitations,  I think you overstate things to say it is
 just short of useless.

 Also, long in the tooth is subjective; RHEL 5 (and the derivative
 works) are currently supported distributions with significant
 installed user bases.  Many environments, for many different reasons,
 have decided that EL is the best choice for them.  It's important to
 respect those decisions.  As a system administrator, I see people
 ignore compatibility with the EL distros regularly, and it's
 unfortunate that many people wave their hands with phrases like 'long
 in the tooth,' 'next to useless,' or 'any modern linux
 distribution' (from another project I was asked to install recently),
 which don't mesh well with the realities of significant parts of the
 installed linux base.

 In this case, as was pointed out, there are fairly simple ways to get
 ruby 1.8.5 onto an EL 5 system.  But when someone writes an app
 against the lastest and greatest libgtk and friends, and uses the most
 recent versions of everything because that's what's available on their
 latest ubuntu release, it simply cuts them off from many potential
 users, for perhaps very little developer gain.  Developers should
 consider carefully the run-time requirements vs. the target audience
 as part of the development process.

 I agree with Ramin that a different numbering scheme for ruby versions
 would have made more sense.  A tiny version change (e.g. 1.8.5 to
 1.8.7) would be understood in many release contexts to contain bug-
 fixes only and introduce no higher-level incompatibilities (a very
 broad simplification, but still true).  Version numbers mean something
 very different to the ruby development team than they do to many other
 knowledgeable people.

 All that being said, if the dashboard development folks have decided
 that 1.8.7 is needed, then 1.8.7 it is.  Perhaps pointers to suitable
 ruby builds could be included in the release notes (or on the download
 page, etc., etc.) as an aid to those who will need to upgrade.

It's not just Dashboard that decided not to support older versions of
Ruby, Rails (the framework Dashboard uses) doesn't support older
version of Ruby.

http://rubyonrails.org/download
We recommend Ruby 1.8.7 or Ruby 1.9.2 for use with Rails. Ruby
1.8.6 and earlier are not supported, neither is version 1.9.1.

While it's true this statement applies explicitly to Rails 3.x rather
than Rails 2.3.x (which Dashboard is still based on), there is nowhere
we could find that explicitly says that Rails 2.3.x *supports* Ruby
1.8.5, so there's no guarantee that security fixes (of which there
were a few applied recently) will support Ruby 1.8.5.

It's probably a good idea to briefly mention a few ways (numerous were
mentioned in this thread) to get newer Rubies in the Dashboard manual
(http://docs.puppetlabs.com/dashboard/manual/1.2/bootstrapping.html#installing-dependencies).
 I've included our excellent documentation writer on this thread.

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



[Puppet Users] Re: Announce: Dashboard 1.2.0 is available now

2011-08-29 Thread jcbollinger

On Aug 28, 7:07 am, Toni Birrer t...@memonic.ch wrote:
 While I agree that it's annoying that the puppet dashboard doesn't run
 with the ruby included in RHEL, i suggest you have a look at the Ruby
 Version Manager (RVM)http://beginrescueend.com/
 Makes running the latest 1.8.x and 1.9.x versions of Ruby a breeze on
 any OS you might use.

 I'm running puppet on hundreds of CentOS 5 hosts using rvm.

Personally, I wouldn't touch RVM with a ten-foot pole.  For one thing,
I insist on installing software only from native packages.  For
another, RVM requires manually switching among various Ruby versions
-- useful for developers, I'm sure, but not so much for running system
software.

But one could, indeed, package a more recent Ruby oneself.  In this
particular case, it is likely that the RHEL or CentOS 6 source RPM for
Ruby 1.8.7 will build with little or no change on CentOS 5.


John

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Re: Announce: Dashboard 1.2.0 is available now

2011-08-29 Thread R.I.Pienaar


- Original Message -
 
 On Aug 28, 7:07 am, Toni Birrer t...@memonic.ch wrote:
  While I agree that it's annoying that the puppet dashboard doesn't
  run
  with the ruby included in RHEL, i suggest you have a look at the
  Ruby
  Version Manager (RVM)http://beginrescueend.com/
  Makes running the latest 1.8.x and 1.9.x versions of Ruby a breeze
  on
  any OS you might use.
 
  I'm running puppet on hundreds of CentOS 5 hosts using rvm.
 
 Personally, I wouldn't touch RVM with a ten-foot pole.  For one
 thing,
 I insist on installing software only from native packages.  For
 another, RVM requires manually switching among various Ruby versions
 -- useful for developers, I'm sure, but not so much for running
 system
 software.
 
 But one could, indeed, package a more recent Ruby oneself.  In this
 particular case, it is likely that the RHEL or CentOS 6 source RPM
 for Ruby 1.8.7 will build with little or no change on CentOS 5.

As has already been done by the CentOS maintainer:

http://centos.karan.org/el5/ruby187/

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Re: Announce: Dashboard 1.2.0 is available now

2011-08-29 Thread Michael Stahnke
Ruby 1.8.7 is unfortunately required to support modernish Rails, etc.
To include security fixes, we had to be 1.8.7.

1.  There are ways to get 1.8.7 onto enterprise platforms these days.
Also, EL6 has been out a while now which ships with 1.8.7.
2.  If you purchase puppet enterprise, ruby 1.8.7 is included


There was a minor bug in an init script on EL based platforms for
puppet-dashboard-workers.  That is fixed in -2 of the package.

http://downloads.puppetlabs.com/dashboard/puppet-dashboard-1.2.0-2.el6.noarch.rpm

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



[Puppet Users] Re: Announce: Dashboard 1.2.0 is available now

2011-08-28 Thread Toni Birrer
While I agree that it's annoying that the puppet dashboard doesn't run
with the ruby included in RHEL, i suggest you have a look at the Ruby
Version Manager (RVM) http://beginrescueend.com/
Makes running the latest 1.8.x and 1.9.x versions of Ruby a breeze on
any OS you might use.

I'm running puppet on hundreds of CentOS 5 hosts using rvm.

--
Toni Birrer

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



[Puppet Users] Re: Announce: Dashboard 1.2.0 is available now

2011-08-28 Thread Xavier Normand
Hi Tim,

Correct me if i'm getting this wrong, but you can grab the source of
ruby and compile it as you need on all kind of linux disto! So there
is no need for you to move your server on RHEL6 just to get ruby
1.8.7.

Xavier

On 26 août, 16:38, Michael Stahnke stah...@puppetlabs.com wrote:
 It's here.  Puppet Labs Announces Puppet Dashboard version 1.2.0.

 This is a significant upgrade over the 1.1.x series, with new
 features, prettier views and some all-in-all awesomeness.   Thanks to
 those who filed bugs, submitted patches and helped with the RC
 process.

 Major Highlights:
 --
 *  Dashboard now processes workloads asynchronously with a delayed_job
 worker.  The worker is controlled either through Rake in the RAILSROOT
 or through init scripts (puppet-dashboard-workers) on rpm and deb
 based systems.
 * License change to Apache Software License version 2.0
 * Upgraded version of Rails stack components
 * Export most views to CSV
 * Dashboard now requires Ruby 1.8.7 to operate
 * Puppet agents should be at 2.6.4 or higher

 This release is available for download 
 at:http://downloads.puppetlabs.com/dashboard/

 We have included Debian and RPM packages as well as a tarball.

 See the Verifying Puppet Download section 
 at:http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet

 Please report feedback via the Puppet Labs Redmine site, using an
 affected version of 1.2.0http://projects.puppetlabs.com/projects/dashboard

 Documentation is available at:http://docs.puppetlabs.com/dashboard/index.html

 CHANGELOG since 1.1.1

 v1.2.0
 ===
 9c32431 (#8228) Reports fail to upload with spool directory
 0bfa755 (#9101) Dashboard workers should not be enabled by default
 3abc596 (#9103) Remove invalid files from git repo
 f52b0ee (#9182) Fix ability to add classes and groups on creation
 e924586 (#9195) Use a shorter date format for the report status graph
 2e85b8d Apply security patch for XSS Vulnerability in the escaping
 function in Ruby on Rails
 d3bfcf5 Apply security patch for XSS Vulnerability in strip_tags helper
 107f101 Apply security patch for SQL Injection Vulnerability in 
 quote_table_name
 0a73593 (#7934) Improve wording to filebucket error
 fa8d27c (#7934) Give a better error message when filebucket contents don't 
 exist
 7b742e9 (#7934) Don't link md5s for new content
 735925f (#9032) Update Debian package to ensure VERSION is packaged
 620de4e (#8251 and #8042) Don't use our own logger
 a2a97ab (#8796) Re-write misleading 500 error message
 6b525b1 (#5845) Changed host to node in UI.
 90f5ce0 (#8488) Move tfoot before tbody in reports table
 ee1f182 (#8488) Make columns consistent between report views
 e54ecb8 (#8790) Fix reports page column display and alignment
 947dcee (#8748) Put sensible umask on pids and logs that delayed_job creates
 4ef96b6 (#8785) Close a directory that we open
 0bfbbf6 (#8785) - Revert (#8748) Upgrade vendored daemons gem to fix
 umask on pids
 3f88c7f (#8748) Fix my forgetting to add a vendored gem
 2f636a9 Allow setting of RUBY for the workers on redhat systems
 651511c (#8748) Upgrade vendored daemons gem to fix umask on pids
 3a65fd0 (#8694) Add backtrace info to DelayedJobFailure
 bf22939 Add document outlining preferred contribution methods
 49cca0b Add document outlining preferred contribution methods
 803be4f (#8745) Update gitignore to not exlucde tmp during tarball creation
 e45338a (#8691) Fix the order of changed and unchanged resources on
 the report summary
 7653800 Provide clearer error message when report host, kind and time
 are not unique
 e86526f (#8686) Handle concurrent DelayedJob workers importing for same node
 88771ec (#8589) Report events are now ordered by name.
 8bd0ffb (#8544) Make empty inspected resources red.
 d036276 (#8505) Update the default date stringification.
 bb99ed9 Properly Quote RAILS_ROOT in get_app_version method
 08717e1 (#8508) Add delayed job worker script for debian/ubuntu package
 2eef4f4 (#8529) Remove unneeded a print statement from sass.rb
 af8b6e9 (#8500) Replace README with a smaller one
 dff2256 (#8499) Update the usage of mktemp in Rakefile to work on mac
 3f0afca (#8484) Nodes for this group heading now appears correctly
 d389d8b (#7568) Relicense to Apache-2.0 License
 82eeea7 (#7567) Refactor dashboard packaging to allow for nightly builds
 a58f3e0 (#6840) Remove need for VERSION file in puppet-dashboard
 d9a384f (#8316) Ruby sorting for ResourceEvents.
 57d0122 (#8276) Remove MaRuKu dependency
 a44d9ff (#8262) Show node groups even when node classification is disabled
 3996b29 (#8262) Create callbacks for each section of node_classification 
 partial
 8f7da94 Remove unused node_groups/_node_groups partial
 5dac13a (#8199) Move 'failed' resources to the top when viewing report events
 2a3a73c (#7967) Improved user-facing design for delayed job warnings
 c78b85a (#8266) Back-end logic for splitting read and unread DJ failures.
 15bba31 (#8121) Properly generate CSS from SASS in 

[Puppet Users] Re: Announce: Dashboard 1.2.0 is available now

2011-08-27 Thread Ramin K
ruby 1.8.5, released Apr 2006
ruby 1.8.7, released May 2008
ruby 1.9.2, released Oct 2010

Not exactly bleeding edge though I suppose anything released in the
last four years could be considered that when compared to RHEL 5. :-)

FWIW, if you think of the releases as Ruby 1.0.x, 1.5.x, and 2.0.x
respectively the differences in capabilities will make more sense.

Ramin

On Aug 27, 4:36 am, Tim Connors tim.w.conn...@gmail.com wrote:
 On Fri, 26 Aug 2011, Michael Stahnke wrote:
  * Dashboard now requires Ruby 1.8.7 to operate

 I've always found it odd that sysadmins would opt for such an unstable
 language.  One where minor revisions are often backwards incompatible
 changes to the language.  The ruby design seems to this particular
 sysadmin, to be contraindicative of something that can be well
 sysadminned.  So it seems odd that it's the backbone of such an important
 sysadmin tool.

 All distributions have a reasonable method of including a good selection
 of perl modules.  And perl is pretty stable over time.  But this choice of
 not debugging the problems with ruby 1.8.5 leads to it being impossible to
 host dashboard on redhat 5 entirely.

 I don't have the freedom of not chosing rhel at work.  If I provisioned a
 new rhel6 server for the new puppet infrastructure, then I'd just be
 pushing back the problem until next year when dashboard decided to come
 out with ruby dependencies of  1.8.7.

 Is there a great need for choosing bleeding edge features of an unstable
 language for a sysadmin tool that's meant to be around for a long time
 because of the amount of investment required in setting it up?

 /rant, part question

 --
 Tim Connors

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.