-
Notifications
You must be signed in to change notification settings - Fork 144
Solaris community pinboard #422
Comments
This comment has been minimized.
This comment has been minimized.
If you want to actively lead or are interested to be part of this Working Group, add your name to the Wiki page ! If we have a large enough group, we can start our own Solaris Working Group. I started labeling all the Solaris related issues and PRs so we can more easily track them:
PS If you no longer want to receive any messages from this pinboard, feel free to unsubscribe from this issue ticket. |
Wake up call for potentially interested Solaris parties ;-) |
Illumos also belongs here right? If so I'll look into implementing some tests for the modules listed in the wiki :) |
@jpdasma If you like, you can add yourself as a team member to the Wiki. And I can also add you to $team_solaris so you can add |
@jpdasma it certainly does belong here. A considerable amount of recent contribution have been for for illumos and it's derivatives, primarily SmartOS. |
Show your support in this ticket means what exactly? I think SmartOS and Illumos would definitely benefit from a more active Ansible community. |
@fishman Add your name to the Wiki, that's what we recommend these days ;-) Being a reviewer in the Solaris WG means you will be involved with every Solaris-related issue/PR and you will have 'shipit' rights, so you can discuss about issues and voice your opinion on open PRs or newly contributed modules. |
adding myself |
@dagwieers not so fast =) |
Automated testing. As all solaris/Illumos/... derivates may not immediately fit into existing continuos integration, I can offer to run simple tests on the automated build VMs I'm runing for the packaging project http://sfe.opencsw.org (not OpenCSW, just friends and hosted there). If there is a description which small/simple tests could be used on freshly packetized ansible releases, then this would be welcome. The available VMs have OpenIndiana Hipster, OmniosCE (r151022 LTS), Solaris 11.3 (GA) and Solaris 11.4 (GA, aka Solaris 12, the name it used to have during development). If there is a pointer to already exisiting test runs where I can see examples, that would be of help. |
@tomww I have some information written down in the Wiki at Reviewing, and I have also written some of it in this comment. There is a lot of information in the official development documentation about integration tests. |
@tomww We could look at integrating a Solaris-environment in our CI, so if you can make a proposal on what would make the most sense (especially considering we may want to test the max. number of modules possible) I think that would be really useful going forward. Relying on outside help to ensure a PR properly works will be an impediment to this WG. |
@dagwieers Two views on that. The above for the X86 world. But there is also the SPARC world for Solaris 11.3 and 11.4. Is there a chance to have a SPARC CPU in the CI instances? |
About X86 CI instances, to be complete there would be the need to run these instances: For both Solaris versions, if there can't be a SPARC environment, then testing on X86 only would give a partial coverage. For instance the detection of the environment/hardware-type might fail on SPARC and would not be detected during CI testing. There should be a separate way to verify the new code. Does the CI team have an idea? |
@tomww That's quite a lot, if we would have to reduce it, could you order them from most important to least important based on relevance and scope? CI infrastructure is always build from scratch (i.e. using Docker images or VMs e.g. Windows). Not sure if we can/will do this, but knowing the requirements would help assess. cc @mattclay |
I don't know whether things have moved on since then, but a year or two back Solaris 11.3 didn't work reliably on KVM. |
I personally can't set a preference (I'm running all of them). But we could do a poll and see what OS is voted most. The minimum would be to run one of the The Solaris type instances can't run in a docker environment. To run Solaris / OmniOS one would need a bare metal machine or a fully virtualized X86 machine e.g. in Virtualbox guest, KVM guest in Linux or BSD or SmartOS or a VMware guest. |
There may be some troubles with Solaris 11.3 and CPU-Speed detection (microfind too fast) and storage should not have too much latency (driver would retire the disk), but Solaris 11.4 and 11.3 run stable under SmartOS KVMs I use for automatic package builds. |
With our existing CI infrastructure we could potentially run tests on OmniOS using available AMIs: https://omniosce.org/setup/aws While other virtualization options or bare metal servers may be technically feasible, we would need to secure resources to implement, run and support those. We have had internal discussions on testing various platforms not currently in our CI matrix. However, none of them have received enough priority to see them implemented, including ones that would likely be easier than some form of Solaris. |
In the enterprise Solaris deployments that I've encountered, Solaris 10 SPARC is still the most common flavour in use, even though it's now in extended support. Even older versions are not uncommon. I think it's fair, though, to tell people that such environments are not well tested. |
If we care about solaris ansible support , there should be at least one host in CI with solaris 11 (could be solaris 10, but better 11 - and it should probably easy, since there's x86 version of solaris) and please add hosts from "solaris" family which would be actively supported, like as @tomww suggested. |
@mator I agree, but at the moment we don't have any integration tests for the Solaris-specific modules. That would be the first thing to tackle as Working Group. I already started with integration tests fo pkgutil. Help testing/reviewing/writing would be appreciated. |
I'll copy my comments from my PR (#54284)...
|
In other words, a working group is fine, but maybe it would be interesting to just try out Gitlab, at least for a single Solaris 11.4 x86 VM at first? Build a VM into Gitlab (however that works with VirtualBox), build one or two integration tests, like my pkg5 module and pkgutil above), then try to run that on Gitlab. What do you say? EDIT: I see the pkgutil integration test issue and as I have a Solaris 11.4 VM I will try to test the ...tests on my machine... |
I added myself to the wiki. A few questions though:
|
Oh man, I should have read the Gitlab docs more carefully, it seems I still have to have VirtualBox and Gitlab Runner installed on my host which just sends the result data back to Gitlab... So, back to square one, it seems? Well, one can do integration tests this way, but one would have to manually start those everytime they are necessary. Or a Oracle hardware machine would have to be connected to the Internet and Gitlab Runner would run on that... |
I've never written on a github project before... where can I see what's being worked on so I can look at ways I might be able to assist? I'm working in a large Solaris Sparc environment and would love some additional ansible modules to support it! |
@kalsto Welcome. You can find all the existing Solaris Issues and PRs via https://github.com/ansible/ansible/labels/solaris There are also various notes on https://github.com/ansible/community/wiki/Solaris |
I've added myself to the group, What I would like to contribute with some changes to the user module to support RBAC (just roles actually). What would be the steps to share that? |
take current code (git) and submit PR with your changes and explanations |
Ok, I've done that, FYI it's PR #65607. |
I've added myself to the group for the same reasons as @guillermomolina. |
How does one add one's self? I am intrigued that the zfs_facts module does not work on Solaris (I can see why too ; there's no -t to zfs get.. |
We could collectively benefit from forming a Working Group related to Solaris integration. We have quite some contributors on Github and users on IRC that are interested in improving this integration.
So this issue is a wake-up call to potential interested parties (earlier and existing contributors to Ansible). The benefits of having a Working Group is that members of the Working Group can:
Since we don't have any Solaris infrastructure for automated testing, collaborating on modules like this is important for the quality of the modules.
The text was updated successfully, but these errors were encountered: