Red Hat Bugzilla – Bug 525802
RFE - Request configuration of new broadcast option of openais integrated into conga
Last modified: 2016-04-26 12:36:22 EDT
Description of problem:
openais now has a broadcast option instead of multicast. However, this is only configurable by manually modifying cluster.conf. Requesting that this be added into conga
Version-Release number of selected component (if applicable):
Steps to Reproduce:
No options/interface to broadcast configuration
Options to choose broadcast and then specify configuration (IPs, etc.)
Adding myself to this BZ, as I think it's an important update to Conga.
Please make this happen... I have run into many cases where not having/exposing broadcast as an option has soured customers on using our cluster technology.
Broadcast is not meant to be used in a production environment. We exposed the ability to configure broadcast only to make it easy to set up POC or demos. Exposing broadcast config via the admin UI will make it far too easy to be misinterpreted as a production quality option.
The problems with broadcast are:
1. you have to isolate your cluster network from any other nodes since you'll flood all other nodes on the network (via physically separate switches or VLANs)
2. you cannot have multiple clusters on the same network/VLAN
3. we have no idea how broadcast holds up when combined with bonding
4. we have no QE testing on broadcast
We also are focusing our efforts on using udpu. See bug # 568164 and fully supporting broadcast would overlap significantly with udpu, but have the additional restrictions mentioned above.
Given all of this, we explicitly do _not_ want to expose broadcast from luci, so I am going to close this as WONTFIX.
Instead of that, why don't we put text in the UI that says something like "Enable broadcast (unsupported/test only, not for production)"
The thing is, it *is* helpful, and we *do* need it, and there *are* cases where it absolutely should be exposed. We can pretty easily expose this functionality while making clear that it is not to be used in production.
(In reply to comment #3)
> Instead of that, why don't we put text in the UI that says something like
> "Enable broadcast (unsupported/test only, not for production)"
> The thing is, it *is* helpful, and we *do* need it, and there *are* cases where
> it absolutely should be exposed. We can pretty easily expose this
> functionality while making clear that it is not to be used in production.
What are the cases in which it should be exposed?
Actually, here's a good compromise...
We have an environment variable like LUCI_DEBUG that can be set prior to running the luci daemon. And the presence of this environment variable will cause luci to show some additional UI stuff that will be considered unsupported.
We can change the init script to source smth like /etc/sysconfig/luci in order to get the environment variable set.
So it would be a manual change to enable this debug/demo/POC mode, but it would make it very explicit since normal Luci startup would not be in this mode.
Would like to hear from feist and rmccabe on this to make sure the idea is not completely insane.
That actually sounds incredibly good. Very clearly defined debug state, I like it a lot! Thanks!
Added pm_ack+ based on the fact that Luci would need to be run in the demo mode to access the bcast option.
Created attachment 442290 [details]
fix for bug
verified in luci-0.12.2-21.el5
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.