Bug 670561

Additionally, internal code changes around configuration affect the following programs:

/usr/bin/cumin-admin
/usr/bin/cumin-bench
/usr/bin/cumin-smoketest

These changes are transparent to the end user -- the programs continue to reference the [web] and [data] sections in cumin.conf, but they do it a little differently.

Point 5) from the bug's Description is not met in cumin-0.1.4475-1.el5:

------------------------------------------------------------------------
# echo CUMIN_OPTIONS="-nonsense" > /etc/sysconfig/cumin 
# service cumin restart
Stopping cumin:                                            [  OK  ]
Starting cumin:                                            [  OK  ]
# usage: cumin [options]

cumin: error: no such option: -n

# echo CUMIN_OPTIONS="--webs=nonsense" > /etc/sysconfig/cumin 
# service cumin restart
Stopping cumin:                                            [FAILED]
Starting cumin:                                            [  OK  ]
# Traceback (most recent call last):
  File "/usr/bin/cumin-web", line 51, in ?
    main()
  File "/usr/bin/cumin-web", line 14, in main
    config, values, opts, args = get_configuration(CuminWebOptionParser(), CuminWebConfig)
  File "/usr/share/cumin/python/cumin/config.py", line 179, in get_configuration
    raise Exception("Section ["+opts.section+"] not present in configuration files.")
Exception: Section [nonsense] not present in configuration files.

# echo CUMIN_OPTIONS="--webs=web,web1,web2,web3" > /etc/sysconfig/cumin 
# service cumin restart
Stopping cumin:                                            [  OK  ]
Starting cumin:                                            [  OK  ]
------------------------------------------------------------------------

Otherwise it seems to be working, I am trying the loadbalancing with
NGINX, using following configuration (package nginx-0.8.53-1.el5 from
EPEL, not required) which I am pasting here for reference:

------------------------------------------------------------------------
http {
    upstream cumin {
        ip_hash;
        server 127.0.0.1:45672;
        server 127.0.0.1:45674;
        server 127.0.0.1:45675;
        server 127.0.0.1:45676;
    }

    server {
        listen       80;
        server_name  servername.domain;

        location / {
            proxy_pass http://cumin;
        }
    }
}
------------------------------------------------------------------------

On point 5:

Note, previous packages have the same problem, I discovered.  I thought this was a regression, but it's not.  If /usr/bin/cumin fails for some reason in 1.3, /sbin/service will still say "OK".

I think it's related to the fact that /usr/bin/cumin is spawned from init.d, and it is the return result from the spawn that is checked.

At this point, I don't think it's worth trying to fix.

On the load balancing:  nice, looks simple.  I wonder if we want to include this in the docs, as an unsupported solution?  Do we do such things?

> On the load balancing:  nice, looks simple.  I wonder if we want to include
> this in the docs, as an unsupported solution?  Do we do such things?

Note, Matt suggested this kind of content would be well-served by a knowledge base article.

OK, verified, spawning a new bug out of comment #5.
Verified also on cumin-0.1.4478-1.el5

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause
    At present, a single instance of cumin-web cannot meet performance goals for medium scale deployments under peak usage.

Change
    Multiple instances of cumin-web may be run on different ports to partition the work.  To make this accesible for end users, support was added for multiple sections in the cumin configuration file and the service startup script was modified to allow creation of multiple instances.  The new configuration options are covered in the MRG Management Console Installation Guide.

Result
    MRG Management Console installations may easily be configured to run multiple instances of cumin-web on different ports of the same host.  Users may select an instance manually by specifying a particular port number in the URL, or alternatively users may choose to set up a load balancing proxy server for cumin-web at a single URL.

Verified with cumin-0.1.4494-1.el5 as well

    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1,8 +1 @@
-Cause
+Running multiple instances of cumin-web on different ports of the same host in order to distribute the workload and increase scalability is now supported. In order to achieve this goal, the cumin configuration file was altered to allow for multiple sections, and the service startup script was modified to allow the creation of multiple instances. Instances can be manually selected by specifying a particular port number in the URL; alternatively, a load-balancing proxy server for cumin-web can be used. These new configuration options are covered in the MRG Management Console Installation Guide.-    At present, a single instance of cumin-web cannot meet performance goals for medium scale deployments under peak usage.
-
-Change
-    Multiple instances of cumin-web may be run on different ports to partition the work.  To make this accesible for end users, support was added for multiple sections in the cumin configuration file and the service startup script was modified to allow creation of multiple instances.  The new configuration options are covered in the MRG Management Console Installation Guide.
-
-Result
-    MRG Management Console installations may easily be configured to run multiple instances of cumin-web on different ports of the same host.  Users may select an instance manually by specifying a particular port number in the URL, or alternatively users may choose to set up a load balancing proxy server for cumin-web at a single URL.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0217.html