[ClusterLabs] kronosnet v1.26 released

2023-07-10 Thread Fabio M. Di Nitto

All,

We are pleased to announce the general availability of kronosnet v1.26

kronosnet (or knet for short) is the new underlying network protocol for 
Linux HA components (corosync), that features the ability to use 
multiple links between nodes, active/active and active/passive link 
failover policies, automatic link recovery, FIPS compliant encryption 
(nss and/or openssl), automatic PMTUd and in general better performance 
compared to the old network protocol.


Highlights in this release:

* Tx performance improvements by removing unnecessary and expensive
  memsets
* Add log TRACE facility and drop build time logging configuration
* Specfile: migrate to SPDX licence format
* Fix few minor build issues with the test suite

Known issues in this release:

* None

The source tarballs can be downloaded here:

https://www.kronosnet.org/releases/

Upstream resources and contacts:

https://kronosnet.org/
https://github.com/kronosnet/kronosnet/
https://ci.kronosnet.org/
https://projects.clusterlabs.org/project/board/86/ (TODO list and 
activities tracking)

https://goo.gl/9ZvkLS (google shared drive with presentations and diagrams)
IRC: #kronosnet on Libera
https://lists.kronosnet.org/mailman3/postorius/lists/users.lists.kronosnet.org/
https://lists.kronosnet.org/mailman3/postorius/lists/devel.lists.kronosnet.org/
https://lists.kronosnet.org/mailman3/postorius/lists/commits.lists.kronosnet.org/

Cheers,
The knet developer team
___
Manage your subscription:
https://lists.clusterlabs.org/mailman/listinfo/users

ClusterLabs home: https://www.clusterlabs.org/


Re: [ClusterLabs] Fence Agents Format

2023-07-10 Thread Oyvind Albrigtsen

On 10/07/23 12:00 +0300, Or Raz wrote:

Hi all,
My team has been working on a new operator which uses some of your Fence
Agents (FA, i.e. fence_aws, fence_ipmilan, and etc.) to remediate an
unhealthy Kubernetes node (see fence-agents-remediation
).
After looking on the recommended attributes for new FAs
,
and the valid *action *attribute values

,
I have some questions on the structure/format of the FAs command attributes
and their responses:

  1. Will running a fence-agent without mentioning the action field will
  always choose the *reboot* option (e.g. the following call will reboot
  the node "fence_aws --access-key ACCESS_KEY --secret-key SECRET_KEY --plug
  i-INSTANCE_ID --region AWS_REGION")?

That's the default, yeah. It's probably due to some earlier Pacemaker
versions not specifying action, so we avoid breaking the agents on
those versions by defaulting to the reboot-action.

  2. Are there any must-have fields which are shared between all the FAs
  that you support? I assume the answer is no, since I didn't see any must
  fields which are mutual between *fence_aws*, and *fence_ipmilan* for
  instance. A must field is a field which is required for running the FA
  (e.g. *access-key* for *fence_aws)*.

That depends on what kind of agent it is, so e.g. http(s) agents or
similar will require url and other parameters that are needed.

You can find a list of default/other groups of parameters depending on
agent when you add them via device_opt = [] here:
https://github.com/ClusterLabs/fence-agents/blob/main/lib/fencing.py.py#L492

and full list of common parameters:
https://github.com/ClusterLabs/fence-agents/blob/main/lib/fencing.py.py#L36

  3. Do the result responses to the FA are identical per action? E.g. For
  the *reboot* action, I have seen that on success I always receive
  `Success: Rebooted` for fence_aws, and fence_ipmilan. I am an
  uncertain whether that is correct for all the FAs.

They should, but you should use the return code to check the result.
https://github.com/ClusterLabs/fence-agents/blob/main/lib/fencing.py.py#L20-L32

You can run "echo $?" to show the result after running e.g. fence_aws
-o reboot manually to see which rc it returns, and use incorrect
credentials or similar to see the difference in rc when it fails.


Oyvind


Best regards,
*OR*



___
Manage your subscription:
https://lists.clusterlabs.org/mailman/listinfo/users

ClusterLabs home: https://www.clusterlabs.org/


___
Manage your subscription:
https://lists.clusterlabs.org/mailman/listinfo/users

ClusterLabs home: https://www.clusterlabs.org/


[ClusterLabs] Fence Agents Format

2023-07-10 Thread Or Raz
Hi all,
My team has been working on a new operator which uses some of your Fence
Agents (FA, i.e. fence_aws, fence_ipmilan, and etc.) to remediate an
unhealthy Kubernetes node (see fence-agents-remediation
).
After looking on the recommended attributes for new FAs
,
and the valid *action *attribute values

,
I have some questions on the structure/format of the FAs command attributes
and their responses:

   1. Will running a fence-agent without mentioning the action field will
   always choose the *reboot* option (e.g. the following call will reboot
   the node "fence_aws --access-key ACCESS_KEY --secret-key SECRET_KEY --plug
   i-INSTANCE_ID --region AWS_REGION")?
   2. Are there any must-have fields which are shared between all the FAs
   that you support? I assume the answer is no, since I didn't see any must
   fields which are mutual between *fence_aws*, and *fence_ipmilan* for
   instance. A must field is a field which is required for running the FA
   (e.g. *access-key* for *fence_aws)*.
   3. Do the result responses to the FA are identical per action? E.g. For
   the *reboot* action, I have seen that on success I always receive
   `Success: Rebooted` for fence_aws, and fence_ipmilan. I am an
   uncertain whether that is correct for all the FAs.

Best regards,
*OR*
___
Manage your subscription:
https://lists.clusterlabs.org/mailman/listinfo/users

ClusterLabs home: https://www.clusterlabs.org/