sap_control_exec - add local socket support

[nbttmbrg]

Add support for local socket connection in sap_control_exec when hostname is localhost and sysnr is provided without username/password

[nbttmbrg]

Sorry for all these commits, if squashing is allowed it might be cleaner to do so.

Current version has been tested on my side and should be OK with CI.

[marcelmamula]

@nbttmbrg Squash is not the best, but some of your changes broke tests so if you changed structure of python module, you have to update sanity test as well. When I do troubleshooting like this, I will just re-create PR afresh to get rid of debugging commits.

CI Workflow in dev and main works fine so issue is with your PR.

[marcelmamula]

@nbttmbrg You can configure your environment to use ansible-test locally as it will make your debugging much quicker, because it removes need to commit and wait for CI workflow. It has some limitations, but it is good starting point.

[nbttmbrg]

It finally looks ok ! I'm used to develop locally and we are currently not testing things thoroughly enough, it seems...

I learnt a lot with all this, so thank you very much for your help 👍

I would still appreciate a human to have a look at the code of the module and its test though !

[marcelmamula]

@nbttmbrg That is good that it was learning experience. You can bet on that I will not randomly approve it so give me few days to get time to review it and test it out.

[marcelmamula]

LGTM. I have tested this change and it works on SLES 16.
Without change: fatal: [localhost]: FAILED! => {"changed": false, "error": "(401, 'Unauthorized')", "msg": "Something went wrong connecting to the SAPCONTROL SOAP API.", "out": {}}

With change: Function GetVersionInfo correctly works.

Thank you @nbttmbrg . Can you check if you can merge this PR yourself (Merge with Merge Commit, not squash)?

[nbttmbrg]

Can you check if you can merge this PR yourself (Merge with Merge Commit, not squash)?

Sadly I don't have the necessary permissions to Merge on this repo.

[kksat]

@marcelmamula @nbttmbrg
I am not stating but asking. Was this code in any way influence (derivative) of https://github.com/redhat-sap/rh_operations/blob/galaxy/plugins/module_utils/saphost.py (from 2023)?

I see quite some similarities in some classes and variables names (for instance):
LocalSocketHttpAuthenticated
LocalSocketHttpConnection

If so, I encourage you to correctly reflect this in the license of this repo, because mentioned code is GPL3.0 not Apache2.

Thank you

[nbttmbrg]

@marcelmamula @nbttmbrg I am not stating but asking. Was this code in any way influence (derivative) of https://github.com/redhat-sap/rh_operations/blob/galaxy/plugins/module_utils/saphost.py (from 2023)?

I see quite some similarities in some classes and variables names (for instance): LocalSocketHttpAuthenticated LocalSocketHttpConnection

If so, I encourage you to correctly reflect this in the license of this repo, because mentioned code is GPL3.0 not Apache2.

Thank you

It was in fact influenced by this repo, I wanted to reproduce the same behavior so that's why some parts of the code are similar.

I will let @marcelmamula edit the license file (or delete these changes if it's somehow better).

Edit : And I apologize for this, I didn't meant no harm but I understand that re-using parts of code shouldn't be done. Lesson learned.

[marcelmamula]

@nbttmbrg We will not be adjusting any license files because having more than one license in repo will create much more issues. @kksat does not want to give permission to use this code to this project outside of GPL-3 from what I heard.

You can look at that code and think how to achieve same result, but differently like not using classes, but instantiating inside of functions, etc. If you dont have any solution how to replace, we can do revert to previous commit and remove this PR from dev branch.

[nbttmbrg]

I will work on this and make another PR.
I'm (obviously) not very aware of the implications of this, will the current changes stay on dev branch until fixed ?

Thanks to both of you.

[marcelmamula]

Changes can remain in dev as they are not merged to main yet, and you can branch of current dev. Socket check functionality requires socket library and you have to inherit its classes and functions, so essentially these parts will remain in some shape or form. It just have to be achieved differently.

I will not be available next week so I will not be able to respond.

[marcelmamula]

If there is no other solution, then we can discuss making this module (and only this module) as GPL-3 or reverting back.

[sean-freeman]

@kksat The following is speaking personally, as I no longer represent any company, or have any professional allegiances, or have any direct involvements to these projects - I am an observer with personal pride in this little segment of the wider open-source community.

---

Firstly, stop stalking the PR contributions and creating combative commentary that does not provide value to the community.

This is not the first time various members of the community or your own leadership have had discussions with you about this, including but not limited to - this is not the first time you have parachuted into GitHub Issues/PRs to start throwing grenades without any contributions (or even testing the code).

We have a welcoming community-first space, where competing companies work together to create something that has a meaningful impact to other companies in this space. That's rare to have such harmony, and it is to be protected. As you've repeatedly demonstrated over many years, you do not act in accordance with the values and spirit of this initiative. Within your company, others contribute to the community and you act in isolation.

Plainly speaking, enough is enough - I wish you the best in your professional career and code projects, but I ask that you please leave this community and never return.

---

Secondly, the SLL-OSI has always been community-first with code governed under the permissive Apache licence so as to allow derivative works by other vendors without Intellectual Property (IP) concerns.

This is explicitly stated from the beginning in all internal documents prior to SLL-OSI launch. Bluntly speaking the permissive licence was in the business interest (of Red Hat, who monetised this code first via RHEL System Roles and RHT AAP) by removing legal licence impediments/restrictions so that adoption would be greater across customers/partners who would consume the code, extend it, sell their own product/service based on it - and hopefully sometimes contribute bug fixes etc back to the community. This approached allowed for extension with their own IP, based upon a common foundation provided by the community. A win-win scenario for everyone involved, where the code could be sold with support + extended with IP.

Your failed attempts sap-linuxlab/community.sap_operations#12 and sap-linuxlab/community.sap_operations#14 to dump code into the community space (for community members to maintain on your behalf) without integrating/cleaning your code into pre-existing code was rude; especially given you maliciously used a duplicate name (what was wrong with sap.sap_maintenance hmmm? you didn't have to duplicate the name) to deliberately confuse end-users, which had a side effect that most of the community coders were reluctant to work on sap_operations because of the politics / ugliness that you instigated.

Back to the matter at hand. When you created these PRs, it constituted acknowledgement that the code is gifted to the community by you under the initiative's and project's firm rule to use Apache licence. Your acceptance of this can be seen in your code contribution, where you amended licence files to Apache and metadata to Apache. The code contribution includes the aforementioned classes.

In addition there was even an internal email about this various years ago, where the licence was supposed to be altered in the sap.sap_operations repository and you did not take this action for whatever reason. More recently (Q4-2024) you attempted to transfer development/maintenance responsibilities of your repository to the various community members while you would retain ownership so as to just delegate fixes to your code which was again... rude.

At various occasions, in the past few years, community members wanted to resolve this divide you created. We all thought about the effort to merge your (bluntly again, rogue) code to create a combined code line where there is genuinely valuable features you have, tied into features that exist under community.sap_operations and community.sap_libs while omitting code that was subpar (stuff like the 13 line sap.sap_operations.is_container etc) that was just bloat to help your reports back to leadership about how many Ansible Modules you created in the past X months. Everyone backed away from the huge task, because you have only ever shown animosity towards the community.

Plainly speaking once more, you already gave this code to the community in the PR - please drop your absurd complaint and never return.

[sean-freeman]

@nbttmbrg I am very sorry your first PR had to contain this historic ugliness. Our community is very grateful to have you and your colleagues, we thank you for your contribution and look forward to more in the future as your usage increases 🙂