Solaris community pinboard

[dagwieers]

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:

• test, review and add shipits to existing Solaris-related PRs
• work collectively on the Solaris roadmap
• provide a single-point-of-contact for interested Solaris contributors
• collaborate on a Solaris-specific Wiki
• have a $team_solaris in BOTMETA.yml for auto-notifying team members (team_solaris: Add auto-labeling for solaris ansible#50730)
• implement auto-labeling Solaris issues and PRs (team_solaris: Add auto-labeling for solaris ansible#50730)

Since we don't have any Solaris infrastructure for automated testing, collaborating on modules like this is important for the quality of the modules.

[dagwieers]

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:

• https://github.com/ansible/ansible/pulls?q=is:pr+is:open+label:solaris (4 open PRs)
• https://github.com/ansible/ansible/issues?q=is:issue+is:open+label:solaris (13 open issues)

PS If you no longer want to receive any messages from this pinboard, feel free to unsubscribe from this issue ticket.

[dagwieers]

Wake up call for potentially interested Solaris parties ;-)

[jpdasma]

Illumos also belongs here right? If so I'll look into implementing some tests for the modules listed in the wiki :)

[dagwieers]

@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 shipits to other PRs and get notifications for anything related to Solaris.

[jasperla]

@jpdasma it certainly does belong here. A considerable amount of recent contribution have been for for illumos and it's derivatives, primarily SmartOS.

[fishman]

Show your support in this ticket means what exactly? I think SmartOS and Illumos would definitely benefit from a more active Ansible community.

[dagwieers]

@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.

[mator]

adding myself

[dagwieers]

So it has been a month since we started this, and compared to some other WGs there is not a lot of activity here. Is there anything I can do to help?

All members have shipit rights on open PRs, and I also added information related to reviewing and roles to the Wiki.

[mator]

@dagwieers not so fast =)
give me some more time...

[tomww]

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).
ansible 2.7.6 packages are currently available for X86 on Solaris 11.3 and OmniOSce.

If there is a pointer to already exisiting test runs where I can see examples, that would be of help.

@tomww

[dagwieers]

@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.

[dagwieers]

@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.

[tomww]

@dagwieers Two views on that.
a) I would ask if there is already at least some knowledge about Solaris-style OS in the team doing the CI instances. That would help a lot, as there is quite some difference.
What would be needed is a KVM to run X86 OS and supported network-drivers (e.g. e1000) and disk drivers (fallback would be IDE). 6-8Gbyte RAM and 2 virtual CPUs.
b) if a) is too much work or needs too long to setup, then a first step in the right direction would be running basic tests "in the outside CI".

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?

[tomww]

About X86 CI instances, to be complete there would be the need to run these instances:
SmartOS (expected to be tricky, as it is more like a firmware image running the hypervisor)
OmniOSce
OpenIndiana Hipster
Solaris 11.3
Solaris 11.4
Optional: the remaining other Distros like tribblix, dilos, any maybe others.

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?

[dagwieers]

@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

[mavit]

What would be needed is a KVM to run X86 OS and supported network-drivers (e.g. e1000) and disk drivers (fallback would be IDE). 6-8Gbyte RAM and 2 virtual CPUs.

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.

[tomww]

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
Solaris 11.3 / 11.4 instances on X86
or
OmniOSce / OpenIndiana Hipster.

The Solaris type instances can't run in a docker environment.
But the concept of Solaris Zones can be used to roll back the zone to the empty state or spawn a completely new zone for each run. The CI agent would log in by ssh, load the files and run the tests.

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.

[tomww]

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.

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.

[mattclay]

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.

[mavit]

But we could do a poll and see what OS is voted most.

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.

[mator]

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.
Thanks.

[dagwieers]

@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.

[danowar2k]

I'll copy my comments from my PR (#54284)...

I'm trying to get a feeling for this. If I'm really trying to show that the module works as intended I think I need a generated Solaris VM to test on. I don't yet understand what I have to do to integrate a Solaris VM in your testing suite. Shippable looks like it generates a lot of VMs each with a different OS version. I wonder if and how I could integrate a Solaris VM into this.

Meanwhile, I surely can restructure more of my code into OS-independent functions, leaving only the functions containing the run_command calls untested. I can mock output generated by pkg list etc. and then feed the functions this output. Would that be good for a start?

If I understand this right, you have a Shippable CI configuration which runs unit tests, sanity tests, etc. . It also declares tests on certain systems which seem to be using Docker containers. Solaris and Docker doesn't seem to work together, so no Docker image for Solaris exists. So I can't add that.

I'm developing playbooks for Solaris x86 machines using a pipeline of
Packer generated VirtualBox ISO + Vagrant box -> running the Vagrant box in VirtualBox -> applying Ansible playbooks to the VM / developing applications in the VM

If there is a CI provider that can run VirtualBox images and Vagrant, one could generate a second configuration for that CI provider to run Solaris specific tests on the started Solaris VirtualBox VM.

What do you think?

Gitlab can use VirtualBox:
https://docs.gitlab.com/runner/executors/virtualbox.html

Gitlab can be activated with Github:
https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos/github_integration.html

Maybe a way to facilitate testing with Solaris VMs?

[danowar2k]

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...

[danowar2k]

I added myself to the wiki. A few questions though:

• The table says "Supporter", the text below "Member". Are they the same thing?
• What encompasses a "Supporter"? (I should learn to click on things, although "Supporter" isn't mentioned on that page)
• Are there other roles? (see above)
• I have a job where part of it is managing Solaris 11 non-global zones which run on Oracle hardware. Does that mean I have "HW"? (In other words, you should probably define "HW" (which I guess means access to Oracle-approved hardware?)

[danowar2k]

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...

[kalsto]

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!

[gundalow]

@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
Feel free to edit that page and add yourself to the list of Community members.

[guillermomolina]

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?

[mator]

@guillermomolina

take current code (git) and submit PR with your changes and explanations

[guillermomolina]

@guillermomolina

take current code (git) and submit PR with your changes and explanations

Ok, I've done that, FYI it's PR #65607.

[noengo]

I've added myself to the group for the same reasons as @guillermomolina.
I would like to contribute with modules related to SMF as well.
I haven't found any modules managing SMF properties. Would it be some interests in such a module ?

[moljnir]

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..

[mavit]

@moljnir You can go ahead and submit a pull request for the zfs_facts issue without joining the
Solaris Working Group, but if you wanted to join the working group too you simply edit the wiki page to add your name.