On Wed, Aug 18, 2021 at 09:45:40AM -0500, John W. Himpel wrote:
> All,
>
> I am putting this out there as a strawman for discussion purposes. It does reflect
my current efforts to install
> Wildfly which is not available via rpm.
>
> Comments and criticisms are welcome:
>
>
>
> I would propose the following:
> 1. Ansible Repository.
> 1. The Fedora Server Working Group create and maintain a repository of
Ansible playbooks to download and
> install
> various applications that are specifically aimed at the server community.
> 2. Investigate possible use of ansible-galaxy.
I suppose it might make sense to make a collection for fedora specific
things. That said, it would be better if we could just contribute to
existing collections and get it to work more generically...
> 2. The playbooks should use Fedora provided rpms for applications and their
components wherever possible.
> 3. The use of ansible roles is strongly encouraged.
> 4. In the case of certain java applications, downloading of
sources/binaries/jars from trusted repositories
> (i.e.
>
wildfly.org,
mvnrepository.com, etc) inside of Ansible playbooks be allowed when
Fedora rpms are not available.
> 5. In accordance with Fedora Open Source policy, only software with Fedora
approved licenses may be downloaded.
> 6. Unless dictated by Fedora policy, the playbook should install non-rpm
artifacts under the /opt directory.
> 7. Where possible, services should be controlled via systemd.
> 8. Playbooks should be developed to install, configure, start, stop, enable,
disable, open firewall, close
> firewall
> and remove (with or without application data) an application or service.
> 9. Applications with many add-ons, extensions or cooperating services should
have each add-on, extension or
> cooperating service managed in a separate playbook.
>
> Use case:
> 1. Wildfly
I've not been active lately and I don't want to tell the people doing
the work what to do, but that said, perhaps wildfly is a bit large of a
thing to start with?
In the previous iteration of fedora server, we had a custom thing called
'rolekit' that would deploy a few things on fedora server, but I think
the only ones we had working/testable were: database server (postgres)
and freeipa server.
I wonder if it might be easier to start with to try and get deployments
of those working and testable.
But thats just my thought on it, don't let me block anyone from what
they want to work on!
kevin
Kevin,
Upstream does not seem to have a way to communicate with him. So I am forking his
efforts. I am more than glad to keep
the existing RHEL configuration intact.
I can get the role to install standalone, domain controller and domain slave instances. I
have been testing quickstarts
against the resulting instances, it they all work fine so far.
But my knowledge of Wildfly is very limited. I am familiar with Websphere and Weblogic.
So I need to find a subject
matter expert on configuring Wildfly. Questions that I have:
1) There are lots of when statements that check the version of RHEL. Is there any reason
to try and support RHEL
versions prior to RHEL 7?
2) The ansible tasks that connects to Wildfly and tries to establish Wildfly Vault, fails
to connect. It appears as
though wildfly is not opening the requested port. I assume it's a configuration error
in Wildfly, but I have no idea
where to look.
3) Wildfly Vault has been depreciated and will go away in the next major release of
Wildfly. It is being replaced by
Elytron. I get very lost trying to decipher the installation docs for Elytron. I'm
not a security expert and get lost
in the jargon.
4) The ansible role assumes dedicated log files for wildfly. Should I migrate the
logging to use systemd-journal?
I'm afraid these types of questions are above my knowledge of wildfly. Any pointers
on where a newbie to wildfly can go
to seek help on these types of issues would be greatly appreciated. Or better yet, a
living and breathing mentor would
be greatly appreciated.
If you have any pointers to the repository of previous efforts to install postgresql
server roles, please pass them
along. I would like any work that I do to follow any "best practices" that may
be exhibited by this earlier work.
Thanks.
John