[Openais] Sorry for noise on mailing list
The mailing list server had a short outage. Apologies for noise on the mailing list. Regards -steve ___ Openais mailing list Openais@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/openais
Re: [Openais] test 3
Steve It's working.. I got all three "test" emails, only 'test 3' had content, the other two were empty. Darren On Thu, 2011-09-01 at 09:08 -0700, Steven Dake wrote: > test 3 > ___ > Openais mailing list > Openais@lists.linux-foundation.org > https://lists.linux-foundation.org/mailman/listinfo/openais ___ Openais mailing list Openais@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/openais
Re: [Openais] Corosync 2.0 Feature Request: Notification of the status change for each rings via SNMP
On 08/31/2011 12:37 AM, Keisuke MORI wrote:
> Hi,
>
> We would like to be notified when a ring gets down or up to let them know
> when they need to check and repair which the network interfaces.
> The notification should be sent via SNMP traps to co-operate with
> various kinds of NMSs.
>
> A proposed implementation was included in the patch posted at March
> 2010 by Sato Yuki-san:
> https://lists.linux-foundation.org/pipermail/openais/2010-March/014036.html
>
> The following MIB item in the patch is related to this.
>
> +corosyncNoticeIfaceEntry ::= SEQUENCE {
> +corosyncNoticeIfaceIndexINTEGER,
> +corosyncNoticeIface OCTET STRING,
> +corosyncNoticeIfaceStatus OCTET STRING
> +}
>
> The notification should be sent when;
> 1) when one ring detect a failure (get in FAULTY state)
> 2) when the failed ring get recovered.
> 3) when the second (last) ring also detect a failure and no longer
> usable to communicate with others
> 3) when the second ring get recovered.
>
> It is also preferable that the current status can be checked by some
> command line tools or an user-customized service plug-in.
> The proposed patch above tried to store the status into the objdb to
> achieve this but the implementation details does not matter.
>
> It would be glad if you would be considering it.
>
Yup this seems reasonable. The way that data comes out now is through
corosync-notifyd vs a direct snmp integration into the corosync process.
As a result, the linked patch needs to be changed to match the new model.
Regards
-steve
> Regards,
> Keisuke MORI
>
> 2011/7/22 Steven Dake :
>> The Corosync flatiron 1.y series had many more features added then I
>> would have liked, but the development team feels the 1.y series
>> addresses any major gaps users of the software have had. As a result,
>> we are freezing any future feature development of the flatiron branch
>> permanently. We will continue to maintain z streams (1.4.z) bug fixes
>> for many years to come in a robust and aggressive fashion.
>>
>> Now that the flatiron chapter of Corosync is finished, we can move on to
>> new r&d work around Corosync 2.0. There are a few RFEs floating around
>> in bugzilla and the TODO list. This is your chance to provide feedback
>> about feature development you would like to see in Corosync.
>>
>> The overall theme for Corosync 2.0 is focused around trimming the fat
>> and simplifying the implementation without major performance regressions.
>>
>> The developers will take feature submission suggestions until Aug 31, at
>> which point we will prioritize features for 2.0 and close feature
>> submission requests.
>>
>> Regards
>> -steve
>> ___
>> Openais mailing list
>> Openais@lists.linux-foundation.org
>> https://lists.linux-foundation.org/mailman/listinfo/openais
>>
>
>
>
___
Openais mailing list
Openais@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/openais
[Openais] test 3
test 3 ___ Openais mailing list Openais@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/openais
[Openais] test
___ Openais mailing list Openais@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/openais
[Openais] test two
___ Openais mailing list Openais@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/openais
[Openais] Configuration Hash Table - API proposal
Included is API proposal for replacement of objdb/confdb API. It should
keep all good things there (triggers, ...), remove hard to use bits
(like whole object idea) and improve existing things (like typing)
Even I wrote it before, also configuration file will need change.
Proposed change is
ht_key value
ht_key. {
ht_subkey value2
}
which is (internally) converted to
ht_key value
ht_key.ht_subkey value2
Also value should become typed, so
value ~= ^-?[0-9]+$ = integer 32 bits, with modificators like l, ll, ...
value ~= ^-?[0-9]*.[0-9]*$ = float (or double) (also should handle all
variants with E .. basically C format)
value = "[:alpha:]*" = string
value = bin:base64 encoded binary data
Regards,
Honza
/*
* Configuration hash table - API DRAFT v1
*
* Public (service) API. Internal API has different names (beginning with i?)
and also function
* for set part of tree not vivisible and writable from service
*/
#ifndef COROSYNC_CHT_H_DEFINED
#define COROSYNC_CHT_H_DEFINED
#include
#include
#ifdef __cplusplus
extern "C" {
#endif
/**
* @addtogroup cht_corosync
*
* @{
*/
typedef uint64_t cht_handle_t;
typedef uint64_t cht_iter_handle_t;
typedef uint64_t cht_track_handle_t;
#define CHT_KEYNAME_MAXLEN 256
typedef enum {
CHT_VALUETYPE_INT16,
CHT_VALUETYPE_UINT16,
CHT_VALUETYPE_INT32,
CHT_VALUETYPE_UINT32,
CHT_VALUETYPE_INT64,
CHT_VALUETYPE_UINT64,
CHT_VALUETYPE_FLOAT,
CHT_VALUETYPE_DOUBLE,
CHT_VALUETYPE_STRING,
CHT_VALUETYPE_BINARY,
} cht_value_types_t;
#define CHT_TRACK_ADD1
#define CHT_TRACK_DELETE 2
#define CHT_TRACK_MODIFY 4
typedef enum {
CHT_RELOAD_NOTIFY_START,
CHT_RELOAD_NOTIFY_END,
CHT_RELOAD_NOTIFY_FAILED
} cht_reload_type_t;
typedef void (*cht_notify_fn_t) (
cht_track_handle_t handle,
unsigned int track_type,
const char *key_name);
typedef void (*cht_reload_notify_fn_t) (
cht_track_handle_t handle,
cht_reload_type_t reload_type);
/** @} */
/*
* Create a new cht connection
* @param handle will be filled with handle to be used for all following
* operations with cht.
* @param callbacks callbacks for cht or NULL
*/
cs_error_t cht_initialize (
cht_handle_t *handle);
/*
* Close the cht handle
* @param handle cht handle
*/
cs_error_t cht_finalize (
cht_handle_t handle);
/*
* Get a file descriptor on which to poll. cht_handle_t is NOT a
* file descriptor and may not be used directly.
* @param handle cht handle initialized by cht_initialize
* @param fd file descriptor for poll
*/
cs_error_t cht_fd_get (
cht_handle_t handle,
int *fd);
/*
* Dispatch changes
*/
cs_error_t cht_dispatch (
cgt_handle_t handle,
cs_dispatch_flags_t dispatch_types);
/*
* Manipulate keys.
*
* key_name is string ending by \0, which can contain characters
* [a-z][A-Z][0-9]._-/
* maximum key_name length is CHT_KEYNAME_MAXLEN
*/
/*
* Set value of cht. If key doesn't exist yet, it's created, otherwise it's
* replaced by new value.
* @param handle cht handle
* @param value pointer to value
* @param value_len length of value data
* @param type type to store.
*/
cs_error_t cht_set (
cht_handle_t handle,
const char *key_name,
const void *value,
size_t value_len,
cht_value_types_t type);
/*
* Shortcut for cht_set with int16 type
*/
cs_error_t cht_set_int16 (
cht_handle_t handle,
const char *key_name,
int16_t value);
/*
* Shortcut for cht_set with uint16 type
*/
cs_error_t cht_set_uint16 (
cht_handle_t handle,
const char *key_name,
uint16_t value);
/*
* Shortcut for cht_set with int32 type
*/
cs_error_t cht_set_int32 (
cht_handle_t handle,
const char *key_name,
int32_t value);
/*
* Shortcut for cht_set with uint32 type
*/
cs_error_t cht_set_uint32 (
cht_handle_t handle,
const char *key_name,
uint32_t value);
/*
* Shortcut for cht_set with int64 type
*/
cs_error_t cht_set_int64 (
cht_handle_t handle,
const char *key_name,
int64_t value);
/*
* Shortcut for cht_set with uint64 type
*/
cs_error_t cht_set_uint64 (
cht_handle_t handle,
const char *key_name,
uint64_t value);
/*
* Shortcut for cht_set with float type
*/
cs_error_t cht_set_float (
cht_handle_t handle,
const char *key_name,
float value);
/*
* Shortcut for cht_set with double type
*/
cs_error_t cht_set_double (
cht_handle_t handle,
const char *key_name,
double value);
/*
* Shortcut for cht_set with string type
*/
cs_error_t cht_set_string (
cht_handle_t handle,
const char *key_name,
char *value);
/*
* Delete key from cht
*/
cs_error_t cht_delete (
cht_handle_t handle,
const char *key_name);
/*
* Get value from cht. value_len is checked with real size of value in cht and
* if is smaller, e
[Openais] [PATCH] wt: Ignore memb_join messages during flush operations
Backport of corosync patch
a memb_join operation that occurs during flushing can result in an
entry into the GATHER state from the RECOVERY state. This results in the
regular sort queue being used instead of the recovery sort queue, resulting
in segfault.
Signed-off-by: Jan Friesse
---
branches/whitetank/exec/totemnet.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/branches/whitetank/exec/totemnet.c
b/branches/whitetank/exec/totemnet.c
index 154aa4f..7b618ec 100644
--- a/branches/whitetank/exec/totemnet.c
+++ b/branches/whitetank/exec/totemnet.c
@@ -77,6 +77,8 @@
#define BIND_STATE_REGULAR 1
#define BIND_STATE_LOOPBACK2
+#define MESSAGE_TYPE_MCAST 1
+
#define HMAC_HASH_SIZE 20
struct security_header {
unsigned char hash_digest[HMAC_HASH_SIZE]; /* The hash *MUST* be first
in the data structure */
@@ -633,6 +635,7 @@ static int net_deliver_fn (
int res = 0;
unsigned char *msg_offset;
unsigned int size_delv;
+ char *message_type;
if (instance->flushing == 1) {
iovec = &instance->totemnet_iov_recv_flush;
@@ -704,6 +707,16 @@ static int net_deliver_fn (
}
/*
+* Drop all non-mcast messages (more specifically join
+* messages should be dropped)
+*/
+ message_type = (char *)msg_offset;
+ if (instance->flushing == 1 && *message_type != MESSAGE_TYPE_MCAST) {
+ iovec->iov_len = FRAME_SIZE_MAX;
+ return (0);
+ }
+
+ /*
* Handle incoming message
*/
instance->totemnet_deliver_fn (
--
1.7.4.1
___
Openais mailing list
Openais@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/openais
[Openais] [PATCH] wt: Ignore memb_join messages during flush operations
Backport of corosync patch
a memb_join operation that occurs during flushing can result in an
entry into the GATHER state from the RECOVERY state. This results in the
regular sort queue being used instead of the recovery sort queue, resulting
in segfault.
Signed-off-by: Jan Friesse
---
branches/whitetank/exec/totemnet.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/branches/whitetank/exec/totemnet.c
b/branches/whitetank/exec/totemnet.c
index 154aa4f..7b618ec 100644
--- a/branches/whitetank/exec/totemnet.c
+++ b/branches/whitetank/exec/totemnet.c
@@ -77,6 +77,8 @@
#define BIND_STATE_REGULAR 1
#define BIND_STATE_LOOPBACK2
+#define MESSAGE_TYPE_MCAST 1
+
#define HMAC_HASH_SIZE 20
struct security_header {
unsigned char hash_digest[HMAC_HASH_SIZE]; /* The hash *MUST* be first
in the data structure */
@@ -633,6 +635,7 @@ static int net_deliver_fn (
int res = 0;
unsigned char *msg_offset;
unsigned int size_delv;
+ char *message_type;
if (instance->flushing == 1) {
iovec = &instance->totemnet_iov_recv_flush;
@@ -704,6 +707,16 @@ static int net_deliver_fn (
}
/*
+* Drop all non-mcast messages (more specifically join
+* messages should be dropped)
+*/
+ message_type = (char *)msg_offset;
+ if (instance->flushing == 1 && *message_type != MESSAGE_TYPE_MCAST) {
+ iovec->iov_len = FRAME_SIZE_MAX;
+ return (0);
+ }
+
+ /*
* Handle incoming message
*/
instance->totemnet_deliver_fn (
--
1.7.4.1
___
Openais mailing list
Openais@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/openais
[Openais] Corosync 2.0 Feature Request: Notification of the status change for each rings via SNMP
Hi,
We would like to be notified when a ring gets down or up to let them know
when they need to check and repair which the network interfaces.
The notification should be sent via SNMP traps to co-operate with
various kinds of NMSs.
A proposed implementation was included in the patch posted at March
2010 by Sato Yuki-san:
https://lists.linux-foundation.org/pipermail/openais/2010-March/014036.html
The following MIB item in the patch is related to this.
+corosyncNoticeIfaceEntry ::= SEQUENCE {
+corosyncNoticeIfaceIndexINTEGER,
+corosyncNoticeIface OCTET STRING,
+corosyncNoticeIfaceStatus OCTET STRING
+}
The notification should be sent when;
1) when one ring detect a failure (get in FAULTY state)
2) when the failed ring get recovered.
3) when the second (last) ring also detect a failure and no longer
usable to communicate with others
3) when the second ring get recovered.
It is also preferable that the current status can be checked by some
command line tools or an user-customized service plug-in.
The proposed patch above tried to store the status into the objdb to
achieve this but the implementation details does not matter.
It would be glad if you would be considering it.
Regards,
Keisuke MORI
2011/7/22 Steven Dake :
> The Corosync flatiron 1.y series had many more features added then I
> would have liked, but the development team feels the 1.y series
> addresses any major gaps users of the software have had. As a result,
> we are freezing any future feature development of the flatiron branch
> permanently. We will continue to maintain z streams (1.4.z) bug fixes
> for many years to come in a robust and aggressive fashion.
>
> Now that the flatiron chapter of Corosync is finished, we can move on to
> new r&d work around Corosync 2.0. There are a few RFEs floating around
> in bugzilla and the TODO list. This is your chance to provide feedback
> about feature development you would like to see in Corosync.
>
> The overall theme for Corosync 2.0 is focused around trimming the fat
> and simplifying the implementation without major performance regressions.
>
> The developers will take feature submission suggestions until Aug 31, at
> which point we will prioritize features for 2.0 and close feature
> submission requests.
>
> Regards
> -steve
> ___
> Openais mailing list
> Openais@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/openais
>
--
Keisuke MORI
___
Openais mailing list
Openais@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/openais
[Openais] [PATCH] Ignore memb_join messages during flush operations
a memb_join operation that occurs during flushing can result in an
entry into the GATHER state from the RECOVERY state. This results in the
regular sort queue being used instead of the recovery sort queue, resulting
in segfault.
Signed-off-by: Steven Dake
---
exec/totemudp.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/exec/totemudp.c b/exec/totemudp.c
index 96849b7..0c12b56 100644
--- a/exec/totemudp.c
+++ b/exec/totemudp.c
@@ -90,6 +90,8 @@
#define BIND_STATE_REGULAR 1
#define BIND_STATE_LOOPBACK2
+#define MESSAGE_TYPE_MCAST 1
+
#define HMAC_HASH_SIZE 20
struct security_header {
unsigned char hash_digest[HMAC_HASH_SIZE]; /* The hash *MUST* be first
in the data structure */
@@ -1172,6 +1174,7 @@ static int net_deliver_fn (
int res = 0;
unsigned char *msg_offset;
unsigned int size_delv;
+ char *message_type;
if (instance->flushing == 1) {
iovec = &instance->totemudp_iov_recv_flush;
@@ -1234,6 +1237,16 @@ static int net_deliver_fn (
}
/*
+* Drop all non-mcast messages (more specifically join
+* messages should be dropped)
+*/
+ message_type = (char *)msg_offset;
+ if (instance->flushing == 1 && *message_type != MESSAGE_TYPE_MCAST) {
+ iovec->iov_len = FRAME_SIZE_MAX;
+ return (0);
+ }
+
+ /*
* Handle incoming message
*/
instance->totemudp_deliver_fn (
--
1.7.6
___
Openais mailing list
Openais@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/openais
