On Tue, Dec 4, 2018 at 12:31 PM Martin Choma <mchoma(a)redhat.com> wrote:
A few thoughts:
Real Time Updates
- Runtime changes in era of OpenShift become less and less important
as configuration should be immutable. Runtime changes should be
addressed on OpenShift level. At least in past some of my "runtime
changes" issues were denied with this argument.
This is certainly something to consider when considering any new management
Another thing to consider is what services are going to utilize any
real-time update? Are there many resources that respond to a credential
attribute value change (e.g. write-attribute) without triggering
reload-required? If they do trigger reload-required it seems likely that's
because making a new value take effect was considered to be too difficult
compared to the gain. In an immutable world the gain is likely even less.
- If this will be decided to accomplish I think it is enough when
updates take in action on explicit administrator command.
Support for Expressions
- Really question here is if vault wasn't misused as external
configuration storage for standalone.xml holding environment
properties on one place. Which could be more convenient as specifying
bunch of system properties. If so we should address this feature
separately - way to specify configuration property file for server
I hope people aren't using a vault just for that. If you want to group
together properties you can use bin/standalone.sh -P. On OpenShift you can
mount a ConfigMap as a source of env var values, and env vars are used in
I could imagine people sticking a username in a vault just because they put
the password in the vault and administratively it was simpler to manage the
two related values together. No idea if that's really done; I just can
imagine it. ;)
- If purpose is to really treat different arguments as security
sensitive then proposed encryption/decryption way seems promising to
On Wed, Sep 26, 2018 at 3:22 PM Darran Lofthouse
> During WildFly 15 and WildFly 16 I am looking at the next stages for
credential store development based on a few feature requests we have not
> We are at the stage where this development is likely to affect multiple
areas of the application server, additionally we need to consider these
requests as a set so we don't take a decision for one that prevents us
working on the remainder.
> I have put together a blog post describing some of the general issues we
want to look into: -
> Some of these changes will have an impact on any subsystem currently
referencing the credential store.
> Other changes we will need to decide if the solution lies within WildFly
Elytron, the management tier of the server, or the admin tools - or
possibly a combination of all three.
> I am also going to share this link in the community forums to try and
obtain some additional feedback from end users.
> Darran Lofthouse.
> wildfly-dev mailing list
wildfly-dev mailing list
Manager, Senior Principal Software Engineer