Run level as a factor for capabilities and requirements?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Run level as a factor for capabilities and requirements?

Brian Stansberry
Something the current capabilities/requirements stuff doesn't handle is the fact that some capabilities can be configured but won't be turned on in some situations (i.e. admin-only). Which means other capabilities that might require them and that are present in admin-only will pass configuration consistency checks but will fail at runtime.

I'm not sure what to do about this. Some off the top of my head thoughts:

1) The capability description data on wildly-capabilities includes something about this, so people who want to require the capability understand whether it can be required.

This is easy, and helps avoids future bugs. It's just documentation so it does nothing about the actual server behavior.

2) The registration for capabilities could include "minimal running-mode" data, and then the capability resolution could check that and fail if it finds a mismatch in the current running mode.

This is more work obviously. It may help surface problems earlier, i.e. make it more likely that a testsuite catches a mismatch in time to correct it before a .Final release. It would also have the minor benefit of perhaps providing a better error message for a user who configures a mismatch.

3) The management layer could somehow makes this data available to subsystems so they could utilize it. So, the requiror sees the required cap is not available in the current run level so it in turn doesn't try and install its own cap. Instead logs a WARN or something.

This is the most work, and I have huge doubts about its wisdom. The software no longer is reasonably predictable, where something is on or off in a given run level; now it's or off depending on whether something else is on or off.

For any of these we'll need to formalize our existing concepts into a solid run-level concept. I don't think that should be too hard.


--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Run level as a factor for capabilities and requirements?

David Lloyd-2
On Tue, Dec 12, 2017 at 11:15 AM, Brian Stansberry
<[hidden email]> wrote:

> Something the current capabilities/requirements stuff doesn't handle is the
> fact that some capabilities can be configured but won't be turned on in some
> situations (i.e. admin-only). Which means other capabilities that might
> require them and that are present in admin-only will pass configuration
> consistency checks but will fail at runtime.
>
> I'm not sure what to do about this. Some off the top of my head thoughts:
>
> 1) The capability description data on wildly-capabilities includes something
> about this, so people who want to require the capability understand whether
> it can be required.
>
> This is easy, and helps avoids future bugs. It's just documentation so it
> does nothing about the actual server behavior.
>
> 2) The registration for capabilities could include "minimal running-mode"
> data, and then the capability resolution could check that and fail if it
> finds a mismatch in the current running mode.

I'm inclined towards this option.  But...

> This is more work obviously. It may help surface problems earlier, i.e. make
> it more likely that a testsuite catches a mismatch in time to correct it
> before a .Final release. It would also have the minor benefit of perhaps
> providing a better error message for a user who configures a mismatch.

It'd be best if we can detect this more up front if possible.  If this
kind of mismatch occurs, I think it would never be the user's fault.

--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Run level as a factor for capabilities and requirements?

Darran Lofthouse
Before a change to capabilities and requirements I think this idea of a running mode is something to consider in general.

As we talk about which modes a runtime handler is going to execute within we generally seem to be able to talk in terms of named modes - but when it comes to code within the application server we have some utility methods e.g. isNormalServer but then in other cases we have more complex boolean expressions to test the 'mode'.  Sometimes it feels like we could use a better way for this test.

Regards,
Darran Lofthouse.


On Tue, 12 Dec 2017 at 22:26 David Lloyd <[hidden email]> wrote:
On Tue, Dec 12, 2017 at 11:15 AM, Brian Stansberry
<[hidden email]> wrote:
> Something the current capabilities/requirements stuff doesn't handle is the
> fact that some capabilities can be configured but won't be turned on in some
> situations (i.e. admin-only). Which means other capabilities that might
> require them and that are present in admin-only will pass configuration
> consistency checks but will fail at runtime.
>
> I'm not sure what to do about this. Some off the top of my head thoughts:
>
> 1) The capability description data on wildly-capabilities includes something
> about this, so people who want to require the capability understand whether
> it can be required.
>
> This is easy, and helps avoids future bugs. It's just documentation so it
> does nothing about the actual server behavior.
>
> 2) The registration for capabilities could include "minimal running-mode"
> data, and then the capability resolution could check that and fail if it
> finds a mismatch in the current running mode.

I'm inclined towards this option.  But...

> This is more work obviously. It may help surface problems earlier, i.e. make
> it more likely that a testsuite catches a mismatch in time to correct it
> before a .Final release. It would also have the minor benefit of perhaps
> providing a better error message for a user who configures a mismatch.

It'd be best if we can detect this more up front if possible.  If this
kind of mismatch occurs, I think it would never be the user's fault.

--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Run level as a factor for capabilities and requirements?

Darran Lofthouse
In reply to this post by Brian Stansberry
Is this discussion triggered by the recent JDBC realm issue that has been reported?  

The problem in this case is I think it depends on the running mode requirements of a specific instance of a capability not all capabilities of that type so the impact becomes transitive.

If we have: -

SecurityDomain -> JDBC Realm -> DataSource

This chain only makes sense in modes where a DataSource can be started.

But we also have: -

SecurityDomain -> PropertiesRealm

This last one makes sense in all modes.

So the overall effect is the minimum running mode of the DataSource affects the minimum running mode of the SecurityDomain.

Regards,
Darran Lofthouse.


On Tue, 12 Dec 2017 at 19:40 Brian Stansberry <[hidden email]> wrote:
Something the current capabilities/requirements stuff doesn't handle is the fact that some capabilities can be configured but won't be turned on in some situations (i.e. admin-only). Which means other capabilities that might require them and that are present in admin-only will pass configuration consistency checks but will fail at runtime.

I'm not sure what to do about this. Some off the top of my head thoughts:

1) The capability description data on wildly-capabilities includes something about this, so people who want to require the capability understand whether it can be required.

This is easy, and helps avoids future bugs. It's just documentation so it does nothing about the actual server behavior.

2) The registration for capabilities could include "minimal running-mode" data, and then the capability resolution could check that and fail if it finds a mismatch in the current running mode.

This is more work obviously. It may help surface problems earlier, i.e. make it more likely that a testsuite catches a mismatch in time to correct it before a .Final release. It would also have the minor benefit of perhaps providing a better error message for a user who configures a mismatch.

3) The management layer could somehow makes this data available to subsystems so they could utilize it. So, the requiror sees the required cap is not available in the current run level so it in turn doesn't try and install its own cap. Instead logs a WARN or something.

This is the most work, and I have huge doubts about its wisdom. The software no longer is reasonably predictable, where something is on or off in a given run level; now it's or off depending on whether something else is on or off.

For any of these we'll need to formalize our existing concepts into a solid run-level concept. I don't think that should be too hard.


--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev