[JBoss JIRA] (WFWIP-306) Health check response contains default readiness data
by Fabio Burzigotti (Jira)
[ https://issues.redhat.com/browse/WFWIP-306?page=com.atlassian.jira.plugin... ]
Fabio Burzigotti reopened WFWIP-306:
------------------------------------
Assignee: (was: Jeff Mesnil)
> Health check response contains default readiness data
> -----------------------------------------------------
>
> Key: WFWIP-306
> URL: https://issues.redhat.com/browse/WFWIP-306
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP Health
> Reporter: Fabio Burzigotti
> Priority: Critical
>
> Starting from Wildfly 19 Beta 2 and with current feature branch for MP Health upgrade to 2.2 [1], some tests started to fail, reporting unexpected content in JSON response.
> When no _readiness_ health check procedures are defined for a given deployment - the returned JSON payload contains a "default" health check readiness object, conventionally named as "ready-deployment." + <archive-name>
> The same _does not_ happen when there's just one registered readiness procedure - i.e. when no annotated _liveness_ procedures exist.
> This change is not documented in the Analysis document: https://github.com/wildfly/wildfly-proposals/pull/284
> The following example uses an Arquillian deployment with a single HealthCheck implementation with _liveness_ health check procedure.
> 1. feature branch [1]
> {code}
> //health
> {
> "status": "UP",
> "checks": [
> {
> "name": "live",
> "status": "UP",
> "data": {
> "key": "value"
> }
> },
> {
> "name": "ready-deployment.HealthTest.war",
> "status": "UP"
> }
> ]
> }
> //live
> {
> "status": "UP",
> "checks": [
> {
> "name": "live",
> "status": "UP",
> "data": {
> "key": "value"
> }
> }
> ]
> }
> //ready
> {
> "status": "UP",
> "checks": [
> {
> "name": "ready-deployment.HealthTest.war",
> "status": "UP"
> }
> ]
> }
> {code}
> 2. here are the results for the same calls against Wildfly 19 Beta 1:
> {code}
> //health
> {
> "status": "UP",
> "checks": [
> {
> "name": "live",
> "status": "UP",
> "data": {
> "key": "value"
> }
> }
> ]
> }
> //live
> {
> "status": "UP",
> "checks": [
> {
> "name": "live",
> "status": "UP",
> "data": {
> "key": "value"
> }
> }
> ]
> }
> //ready
> {
> "status": "UP",
> "checks": []
> }
> {code}
> [1]
> https://github.com/jmesnil/wildfly
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFWIP-306) Health check response contains default readiness data
by Fabio Burzigotti (Jira)
[ https://issues.redhat.com/browse/WFWIP-306?page=com.atlassian.jira.plugin... ]
Fabio Burzigotti closed WFWIP-306.
----------------------------------
Resolution: Done
This will be tracked by https://issues.redhat.com/browse/WFLY-12952
> Health check response contains default readiness data
> -----------------------------------------------------
>
> Key: WFWIP-306
> URL: https://issues.redhat.com/browse/WFWIP-306
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP Health
> Reporter: Fabio Burzigotti
> Assignee: Jeff Mesnil
> Priority: Critical
>
> Starting from Wildfly 19 Beta 2 and with current feature branch for MP Health upgrade to 2.2 [1], some tests started to fail, reporting unexpected content in JSON response.
> When no _readiness_ health check procedures are defined for a given deployment - the returned JSON payload contains a "default" health check readiness object, conventionally named as "ready-deployment." + <archive-name>
> The same _does not_ happen when there's just one registered readiness procedure - i.e. when no annotated _liveness_ procedures exist.
> This change is not documented in the Analysis document: https://github.com/wildfly/wildfly-proposals/pull/284
> The following example uses an Arquillian deployment with a single HealthCheck implementation with _liveness_ health check procedure.
> 1. feature branch [1]
> {code}
> //health
> {
> "status": "UP",
> "checks": [
> {
> "name": "live",
> "status": "UP",
> "data": {
> "key": "value"
> }
> },
> {
> "name": "ready-deployment.HealthTest.war",
> "status": "UP"
> }
> ]
> }
> //live
> {
> "status": "UP",
> "checks": [
> {
> "name": "live",
> "status": "UP",
> "data": {
> "key": "value"
> }
> }
> ]
> }
> //ready
> {
> "status": "UP",
> "checks": [
> {
> "name": "ready-deployment.HealthTest.war",
> "status": "UP"
> }
> ]
> }
> {code}
> 2. here are the results for the same calls against Wildfly 19 Beta 1:
> {code}
> //health
> {
> "status": "UP",
> "checks": [
> {
> "name": "live",
> "status": "UP",
> "data": {
> "key": "value"
> }
> }
> ]
> }
> //live
> {
> "status": "UP",
> "checks": [
> {
> "name": "live",
> "status": "UP",
> "data": {
> "key": "value"
> }
> }
> ]
> }
> //ready
> {
> "status": "UP",
> "checks": []
> }
> {code}
> [1]
> https://github.com/jmesnil/wildfly
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (DROOLS-5084) grouping rules
by Werner Van Herrewegen (Jira)
[ https://issues.redhat.com/browse/DROOLS-5084?page=com.atlassian.jira.plug... ]
Werner Van Herrewegen updated DROOLS-5084:
------------------------------------------
Description:
As a business user I would like to have an easy way to +*visibly *+group certain rules together in the business central.
As a business user I want to have an intuitive way to afterwards find rules related to one of those groups.
constraints:
I don't want to use package (physical folder structure)
I don't want to use the current tags implementation as I don't use the left side 'developer' project/repository treeview
multiple rules can have the same group
some rules might fit under multiple groups and should thus be found under multiple 'groups'
workaround:
Currently I use my own naming convention to allow business people to search for rules having to do with a certain topic.
But it is tedious to maintain as rule names are free text and I have no way to force them to use the convention.
And also the user needs to currently guess the 'topic'-names in the rule search window instead of having a list of 'topics'
suggested solution:
I like the tags idea. this allows to have the many to many relationship of rules and 'rule groups'
But the way it is implemented in the UI is not user friendly enough to get business people to use it. I would also force them to put at least 1 tag.
And really important, tags must be forced to ALL_CAPITALS and no special signs but must ALLOW spaces (no underscores or hyphens for business users!).
When creating a rule (the popup dialog where you name the rule and select the package), that is the time to add tags to it. (and not hidden in the overview>metadata tab)
And afterwards they can be amended in this overview>metadata tab (though I would recommend to name it for business users 'rule info' tab, and make it easier to find) :-)
This will ensure that business people categorize their rules to keep track of them when the list gets longer. (and not get IT to find them for them)
For the second part ...
Now that business people have tagged their rules with 'business topics', they need to have an easy way to find all rules related to this 'business topic' (tag)
The rule filter window is an excellent place for this.
I would like an additional filter text box that allows a collection of tags that will be used to filter the rules list.
This text box is NOT 'free text' and should be fillable only with existing tags (think of the '+search +for labels' feature in jira)
->only allow valid tags (no free text)
->allow multiple tags (logic = OR/AND(perhaps also a NOT?) : use these words between selected tags iso just using a comma)
->drop down list sorted alphabetically with remaining valid tags
In the result set, it would be also nice to to have an indication of the tags that apply to the specific rules.
was:
As a business user I would like to have an easy way to +*visibly *+group certain rules together in the business central.
As a business user I want to have an intuitive way to afterwards find rules related to one of those groups.
constraints:
I don't want to use package (physical folder structure)
I don't want to use the current tags implementation as I don't use the left side 'developer' project/repository treeview
multiple rules can have the same group
some rules might fit under multiple groups and should thus be found under multiple 'groups'
workaround:
Currently I use my own naming convention to allow business people to search for rules having to do with a certain topic.
But it is tedious to maintain as rule names are free text and I have no way to force them to use the convention.
And also the user needs to currently guess the 'topic'-names in the rule search window instead of having a list of 'topics'
suggested solution:
I like the tags idea. this allows to have the many to many relationship of rules and 'rule groups'
But the way it is implemented in the UI is not user friendly enough to get business people to use it. I would also force them to put at least 1 tag.
And really important, tags must be forced to ALL_CAPITALS and no special signs but must ALLOW spaces (no underscores or hyphens for business users!).
When creating a rule (the popup dialog where you name the rule and select the package), that is the time to add tags to it. (and not hidden in the overview>metadata tab)
And afterwards they can be amended in this overview>metadata tab (though I would recommend to name it for business users 'rule info' tab, and make it easier to find) :-)
This will ensure that business people categorize their rules to keep track of them when the list gets longer. (and not get IT to find them for them)
For the second part ...
Now that business people have tagged their rules with 'business topics', they need to have an easy way to find all rules related to this 'business topic' (tag)
The rule filter window is an excellent place for this.
I would like an additional filter text box that allows a collection of tags that will be used to filter the rules list.
This text box is NOT 'free text' and should be fillable only with existing tags (think of the '+search +for labels' feature in jira)
->only allow valid tags (no free text)
->allow multiple tags (logic = OR/AND(perhaps also a NOT?) : use these words between selected tags iso just using a comma)
->drop down list sorted alphabetically with remaining valid tags
In the result set, it would be also nice to to have an indication of the labels that apply to the specific rules.
> grouping rules
> --------------
>
> Key: DROOLS-5084
> URL: https://issues.redhat.com/browse/DROOLS-5084
> Project: Drools
> Issue Type: Feature Request
> Components: tools
> Reporter: Werner Van Herrewegen
> Assignee: Mario Fusco
> Priority: Major
>
> As a business user I would like to have an easy way to +*visibly *+group certain rules together in the business central.
> As a business user I want to have an intuitive way to afterwards find rules related to one of those groups.
> constraints:
> I don't want to use package (physical folder structure)
> I don't want to use the current tags implementation as I don't use the left side 'developer' project/repository treeview
> multiple rules can have the same group
> some rules might fit under multiple groups and should thus be found under multiple 'groups'
> workaround:
> Currently I use my own naming convention to allow business people to search for rules having to do with a certain topic.
> But it is tedious to maintain as rule names are free text and I have no way to force them to use the convention.
> And also the user needs to currently guess the 'topic'-names in the rule search window instead of having a list of 'topics'
> suggested solution:
> I like the tags idea. this allows to have the many to many relationship of rules and 'rule groups'
> But the way it is implemented in the UI is not user friendly enough to get business people to use it. I would also force them to put at least 1 tag.
> And really important, tags must be forced to ALL_CAPITALS and no special signs but must ALLOW spaces (no underscores or hyphens for business users!).
> When creating a rule (the popup dialog where you name the rule and select the package), that is the time to add tags to it. (and not hidden in the overview>metadata tab)
> And afterwards they can be amended in this overview>metadata tab (though I would recommend to name it for business users 'rule info' tab, and make it easier to find) :-)
> This will ensure that business people categorize their rules to keep track of them when the list gets longer. (and not get IT to find them for them)
> For the second part ...
> Now that business people have tagged their rules with 'business topics', they need to have an easy way to find all rules related to this 'business topic' (tag)
> The rule filter window is an excellent place for this.
> I would like an additional filter text box that allows a collection of tags that will be used to filter the rules list.
> This text box is NOT 'free text' and should be fillable only with existing tags (think of the '+search +for labels' feature in jira)
> ->only allow valid tags (no free text)
> ->allow multiple tags (logic = OR/AND(perhaps also a NOT?) : use these words between selected tags iso just using a comma)
> ->drop down list sorted alphabetically with remaining valid tags
> In the result set, it would be also nice to to have an indication of the tags that apply to the specific rules.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (DROOLS-5084) grouping rules
by Werner Van Herrewegen (Jira)
[ https://issues.redhat.com/browse/DROOLS-5084?page=com.atlassian.jira.plug... ]
Werner Van Herrewegen updated DROOLS-5084:
------------------------------------------
Description:
As a business user I would like to have an easy way to +*visibly *+group certain rules together in the business central.
As a business user I want to have an intuitive way to afterwards find rules related to one of those groups.
constraints:
I don't want to use package (physical folder structure)
I don't want to use the current tags implementation as I don't use the left side 'developer' project/repository treeview
multiple rules can have the same group
some rules might fit under multiple groups and should thus be found under multiple 'groups'
workaround:
Currently I use my own naming convention to allow business people to search for rules having to do with a certain topic.
But it is tedious to maintain as rule names are free text and I have no way to force them to use the convention.
And also the user needs to currently guess the 'topic'-names in the rule search window instead of having a list of 'topics'
suggested solution:
I like the tags idea. this allows to have the many to many relationship of rules and 'rule groups'
But the way it is implemented in the UI is not user friendly enough to get business people to use it. I would also force them to put at least 1 tag.
And really important, tags must be forced to ALL_CAPITALS and no special signs but must ALLOW spaces (no underscores or hyphens for business users!).
When creating a rule (the popup dialog where you name the rule and select the package), that is the time to add tags to it. (and not hidden in the overview>metadata tab)
And afterwards they can be amended in this overview>metadata tab (though I would recommend to name it for business users 'rule info' tab, and make it easier to find) :-)
This will ensure that business people categorize their rules to keep track of them when the list gets longer. (and not get IT to find them for them)
For the second part ...
Now that business people have tagged their rules with 'business topics', they need to have an easy way to find all rules related to this 'business topic' (tag)
The rule filter window is an excellent place for this.
I would like an additional filter text box that allows a collection of tags that will be used to filter the rules list.
This text box is NOT 'free text' and should be fillable only with existing tags (think of the '+search +for labels' feature in jira)
->only allow valid tags (no free text)
->allow multiple tags (logic = OR/AND(perhaps also a NOT?) : use these words between selected tags iso just using a comma)
->drop down list sorted alphabetically with remaining valid tags
In the result set, it would be also nice to to have an indication of the labels that apply to the specific rules.
was:
As a business user I would like to have an easy way to +*visibly *+group certain rules together in the business central.
As a business user I want to have an intuitive way to afterwards find rules related to one of those groups.
constraints:
I don't want to use package (physical folder structure)
I don't want to use the current tags implementation as I don't use the left side 'developer' project/repository treeview
multiple rules can have the same group
some rules might fit under multiple groups and should thus be found under multiple 'groups'
workaround:
Currently I use my own naming convention to allow business people to search for rules having to do with a certain topic.
But it is tedious to maintain as rule names are free text and I have no way to force them to use the convention.
And also the user needs to currently guess the 'topic'-names in the rule search window instead of having a list of 'topics'
suggested solution:
I like the tags idea. this allows to have the many to many relationship of rules and 'rule groups'
But the way it is implemented in the UI is nog user friendly enough to get business people to use it. I would also force them to put at least 1 tag.
And really important, tags must be forced to ALL_CAPITALS and no special signs but must ALLOW spaces (no underscores or hyphens for business users!).
When creating a rule (the popup dialog where you name the rule and select the package), that is the time to add tags to it. (and not hidden in the overview>metadata tab)
And afterwards they can be amended in this overview>metadata tab (though I would recommend to name it for business users 'rule info' tab, and make it easier to find) :-)
This will ensure that business people categorize their rules to keep track of them when the list gets longer. (and not get IT to find them for them)
For the second part ...
Now that business people have tagged their rules with 'business topics', they need to have an easy way to find all rules related to this 'business topic' (tag)
The rule filter window is an excellent place for this.
I would like an additional filter text box that allows a collection of tags that will be used to filter the rules list.
This text box is NOT 'free text' and should be fillable only with existing tags (think of the '+search +for labels' feature in jira)
->only allow valid tags (no free text)
->allow multiple tags (logic = OR/AND(perhaps also a NOT?) : use these words between selected tags iso just using a comma)
->drop down list sorted alphabetically with remaining valid tags
In the result set, it would be also nice to to have an indication of the labels that apply to the specific rules.
> grouping rules
> --------------
>
> Key: DROOLS-5084
> URL: https://issues.redhat.com/browse/DROOLS-5084
> Project: Drools
> Issue Type: Feature Request
> Components: tools
> Reporter: Werner Van Herrewegen
> Assignee: Mario Fusco
> Priority: Major
>
> As a business user I would like to have an easy way to +*visibly *+group certain rules together in the business central.
> As a business user I want to have an intuitive way to afterwards find rules related to one of those groups.
> constraints:
> I don't want to use package (physical folder structure)
> I don't want to use the current tags implementation as I don't use the left side 'developer' project/repository treeview
> multiple rules can have the same group
> some rules might fit under multiple groups and should thus be found under multiple 'groups'
> workaround:
> Currently I use my own naming convention to allow business people to search for rules having to do with a certain topic.
> But it is tedious to maintain as rule names are free text and I have no way to force them to use the convention.
> And also the user needs to currently guess the 'topic'-names in the rule search window instead of having a list of 'topics'
> suggested solution:
> I like the tags idea. this allows to have the many to many relationship of rules and 'rule groups'
> But the way it is implemented in the UI is not user friendly enough to get business people to use it. I would also force them to put at least 1 tag.
> And really important, tags must be forced to ALL_CAPITALS and no special signs but must ALLOW spaces (no underscores or hyphens for business users!).
> When creating a rule (the popup dialog where you name the rule and select the package), that is the time to add tags to it. (and not hidden in the overview>metadata tab)
> And afterwards they can be amended in this overview>metadata tab (though I would recommend to name it for business users 'rule info' tab, and make it easier to find) :-)
> This will ensure that business people categorize their rules to keep track of them when the list gets longer. (and not get IT to find them for them)
> For the second part ...
> Now that business people have tagged their rules with 'business topics', they need to have an easy way to find all rules related to this 'business topic' (tag)
> The rule filter window is an excellent place for this.
> I would like an additional filter text box that allows a collection of tags that will be used to filter the rules list.
> This text box is NOT 'free text' and should be fillable only with existing tags (think of the '+search +for labels' feature in jira)
> ->only allow valid tags (no free text)
> ->allow multiple tags (logic = OR/AND(perhaps also a NOT?) : use these words between selected tags iso just using a comma)
> ->drop down list sorted alphabetically with remaining valid tags
> In the result set, it would be also nice to to have an indication of the labels that apply to the specific rules.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFWIP-306) Health check response contains default readiness data
by Fabio Burzigotti (Jira)
[ https://issues.redhat.com/browse/WFWIP-306?page=com.atlassian.jira.plugin... ]
Fabio Burzigotti commented on WFWIP-306:
----------------------------------------
Ok, thanks [~jmesnil]. The change was brought in by https://issues.redhat.com/browse/WFLY-12952, so it is not part of this RFE. Thanks for the link to the community doc, too.
> Health check response contains default readiness data
> -----------------------------------------------------
>
> Key: WFWIP-306
> URL: https://issues.redhat.com/browse/WFWIP-306
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP Health
> Reporter: Fabio Burzigotti
> Assignee: Jeff Mesnil
> Priority: Critical
>
> Starting from Wildfly 19 Beta 2 and with current feature branch for MP Health upgrade to 2.2 [1], some tests started to fail, reporting unexpected content in JSON response.
> When no _readiness_ health check procedures are defined for a given deployment - the returned JSON payload contains a "default" health check readiness object, conventionally named as "ready-deployment." + <archive-name>
> The same _does not_ happen when there's just one registered readiness procedure - i.e. when no annotated _liveness_ procedures exist.
> This change is not documented in the Analysis document: https://github.com/wildfly/wildfly-proposals/pull/284
> The following example uses an Arquillian deployment with a single HealthCheck implementation with _liveness_ health check procedure.
> 1. feature branch [1]
> {code}
> //health
> {
> "status": "UP",
> "checks": [
> {
> "name": "live",
> "status": "UP",
> "data": {
> "key": "value"
> }
> },
> {
> "name": "ready-deployment.HealthTest.war",
> "status": "UP"
> }
> ]
> }
> //live
> {
> "status": "UP",
> "checks": [
> {
> "name": "live",
> "status": "UP",
> "data": {
> "key": "value"
> }
> }
> ]
> }
> //ready
> {
> "status": "UP",
> "checks": [
> {
> "name": "ready-deployment.HealthTest.war",
> "status": "UP"
> }
> ]
> }
> {code}
> 2. here are the results for the same calls against Wildfly 19 Beta 1:
> {code}
> //health
> {
> "status": "UP",
> "checks": [
> {
> "name": "live",
> "status": "UP",
> "data": {
> "key": "value"
> }
> }
> ]
> }
> //live
> {
> "status": "UP",
> "checks": [
> {
> "name": "live",
> "status": "UP",
> "data": {
> "key": "value"
> }
> }
> ]
> }
> //ready
> {
> "status": "UP",
> "checks": []
> }
> {code}
> [1]
> https://github.com/jmesnil/wildfly
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (DROOLS-5086) undo button
by Werner Van Herrewegen (Jira)
[ https://issues.redhat.com/browse/DROOLS-5086?page=com.atlassian.jira.plug... ]
Werner Van Herrewegen updated DROOLS-5086:
------------------------------------------
Description:
As a business user using the business central webapp I don't know what git is and want to have my 'undo' button that rolls back the last commit on 'my branch' when I make a mistake.
tech:
make sure a diff is shown and explicit validation is requested with an explicit 'confirm' button
also take into account the case where a user deletes a file
or wants to reverse the renaming or a file
was:
As a business user using the business central webapp I don't know what git is and want to have my 'undo' button that rolls back the last commit on 'my branch' when I make a mistake.
tech:
make sure a diff is shown and explicit validation is requested with an explicit 'confirm' button
> undo button
> -----------
>
> Key: DROOLS-5086
> URL: https://issues.redhat.com/browse/DROOLS-5086
> Project: Drools
> Issue Type: Feature Request
> Components: tools
> Reporter: Werner Van Herrewegen
> Assignee: Mario Fusco
> Priority: Major
>
> As a business user using the business central webapp I don't know what git is and want to have my 'undo' button that rolls back the last commit on 'my branch' when I make a mistake.
> tech:
> make sure a diff is shown and explicit validation is requested with an explicit 'confirm' button
> also take into account the case where a user deletes a file
> or wants to reverse the renaming or a file
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (DROOLS-5090) enumeration values used in rules can be deleted
by Werner Van Herrewegen (Jira)
Werner Van Herrewegen created DROOLS-5090:
---------------------------------------------
Summary: enumeration values used in rules can be deleted
Key: DROOLS-5090
URL: https://issues.redhat.com/browse/DROOLS-5090
Project: Drools
Issue Type: Bug
Components: Enumerations Editor
Reporter: Werner Van Herrewegen
Assignee: Michael Anstis
As a rule creator,
whenever the value list of an enumeration gets modified, I want to make sure that no rules are broken because of it.
NOW IT IS BROKEN:
see steps to reproduce
solution suggestion:
prevent the deletion of an enumeration value when it is in use in a rule
The user should be made aware what rule(s) is/are blocking the removal of a value!
--> the user must first 'prepare' the rules and then come back to remove the value from the list
ATTENTION:
This logic only is valid for DELETION/RENAMING of enumeration values,
Rearranging values and adding values can happen without any problem.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-12952) MP Health returns UP when checks are expected but not installed yet.
by Ivan Straka (Jira)
[ https://issues.redhat.com/browse/WFLY-12952?page=com.atlassian.jira.plugi... ]
Ivan Straka updated WFLY-12952:
-------------------------------
Steps to Reproduce:
Get WildFly
run [a reproducer|https://github.com/istraka/eap-microprofile-test-suite/blob/mp...]
{code:java}
git clone git@github.com:istraka/eap-microprofile-test-suite.git -b mp-health-feature
cd eap-microprofile-test-suite
mvn clean install -DskipTests -Djboss.dist=FOO
mvn surefire:test@manual-test -pl microprofile-health/ -Dtest=NotReadyHealthCheckTest -Djboss.home=_path_to_wf_
{code}
was:
Get WildFly
run [a reproducer|https://github.com/istraka/eap-microprofile-test-suite/blob/mp...]
{code:java}
git clone git@github.com:istraka/eap-microprofile-test-suite.git -b mp-health-feature
cd eap-microprofile-test-suite
mvn clean install -DskipTests -Djboss.home=FOO
mvn surefire:test@manual-test -pl microprofile-health/ -Dtest=NotReadyHealthCheckTest -Djboss.home=_path_to_wf_
{code}
> MP Health returns UP when checks are expected but not installed yet.
> --------------------------------------------------------------------
>
> Key: WFLY-12952
> URL: https://issues.redhat.com/browse/WFLY-12952
> Project: WildFly
> Issue Type: Bug
> Components: MP Health
> Affects Versions: 18.0.0.Final
> Reporter: Ivan Straka
> Assignee: Jeff Mesnil
> Priority: Critical
> Fix For: 19.0.0.Beta2
>
>
> MicroProfile Health 2.0 specification [link|https://github.com/eclipse/microprofile-health/blob/2.0/spec/src/mai...] says:
> * A producer MUST support custom, application level health check procedures
> * A producer SHOULD support reasonable out-of-the-box procedures
> * A producer with no health check procedures expected or installed MUST return positive overall status (i.e. HTTP 200)
> * A producer with health check procedures expected but not yet installed MUST return negative overall status (i.e. HTTP 503)
> When I deploy and application with a readiness probe before WildFly is started, from my and namely OpenShift POV the health check procedure is expected from the very beginning.
> _Let me note that on OpenShift starting the served should mean starting the service._
> Hence I expect negative overall status till the probe is ready and is able to provide response.
> However WildFly with default setting responses with status UP:
> {code:bash}
> while true; do echo $(date +"%T.%3N") ; curl localhost:9990/health/ready; echo ""; done
> 17:17:56.438 curl: (7) Failed to connect to localhost port 9990: Connection refused
> 17:17:56.452 curl: (7) Failed to connect to localhost port 9990: Connection refused
> 17:17:56.466 {"status":"UP","checks":[]}
> ...
> 17:18:01.121 {"status":"UP","checks":[]}
> 17:18:01.133 {"status":"DOWN","checks":[{"name":"delayed-readiness","status":"DOWN"}]}
> {code}
> This violates (4) bullet in the specification.
> WildFly provides option to set global Status when probes are not defined ([documentation|https://doc-stage.usersys.redhat.com/documentation/en-us/re...])
> Which would mean the scenario would behave according to the specification. Yet the default state violates it.
> If the default value were _DOWN_ we would run into an issue if WildFly without deployment were used (for example as backup for AMQ). The status would be just DOWN:
> {noformat}
> 17:22:41.719
> {"status":"DOWN","checks":[]}
> {noformat}
> And that would violate (3) in the specification.
> TCK tests do not cover the scenario well.
> Is there a way to return _DOWN_ until WildFly scan a deployment and if no health check is found (thus not expected) then start to return _UP_ ? The scan should happen during MP Health initialization.
> If there is no deployment, the _UP_ it is.
> Setting the priority to blocker since WildFly 19 shall be EAP 7.3.0.CD19 which is supposed to run on OpenShift. With this behavior health check is not very useful because:
> * OpenShift starts the service wait some time and start asking for health status
> * WildFly responses _UP_ yet application helathcheck is not installed yet
> * With health status _UP_ OpenShift consider a pod ready
> * In this point application is installed, health status is _DOWN_ (a DB is down) however OpenShift flow is somewhere else
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (DROOLS-5089) enumeration reference iso value list
by Werner Van Herrewegen (Jira)
Werner Van Herrewegen created DROOLS-5089:
---------------------------------------------
Summary: enumeration reference iso value list
Key: DROOLS-5089
URL: https://issues.redhat.com/browse/DROOLS-5089
Project: Drools
Issue Type: Feature Request
Reporter: Werner Van Herrewegen
Assignee: Mario Fusco
In business central,
when creating an enumeration to use in my rules,
I find myself a lot copying the allowed value list to multiple fact-field-combinations
Can I refer for the value list for a fact-field-combination-enumeration to another existing fact-field-combination-enumeration.
That way I only need to maintain 1 value list
not an option:
use an enum from the java code
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFWIP-306) Health check response contains default readiness data
by Jeff Mesnil (Jira)
[ https://issues.redhat.com/browse/WFWIP-306?page=com.atlassian.jira.plugin... ]
Jeff Mesnil commented on WFWIP-306:
-----------------------------------
https://github.com/wildfly/wildfly/blob/master/docs/src/main/asciidoc/_ad...
(although I should also mention the mp.health.disable-default-procedures for a better explanation)
> Health check response contains default readiness data
> -----------------------------------------------------
>
> Key: WFWIP-306
> URL: https://issues.redhat.com/browse/WFWIP-306
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP Health
> Reporter: Fabio Burzigotti
> Assignee: Jeff Mesnil
> Priority: Critical
>
> Starting from Wildfly 19 Beta 2 and with current feature branch for MP Health upgrade to 2.2 [1], some tests started to fail, reporting unexpected content in JSON response.
> When no _readiness_ health check procedures are defined for a given deployment - the returned JSON payload contains a "default" health check readiness object, conventionally named as "ready-deployment." + <archive-name>
> The same _does not_ happen when there's just one registered readiness procedure - i.e. when no annotated _liveness_ procedures exist.
> This change is not documented in the Analysis document: https://github.com/wildfly/wildfly-proposals/pull/284
> The following example uses an Arquillian deployment with a single HealthCheck implementation with _liveness_ health check procedure.
> 1. feature branch [1]
> {code}
> //health
> {
> "status": "UP",
> "checks": [
> {
> "name": "live",
> "status": "UP",
> "data": {
> "key": "value"
> }
> },
> {
> "name": "ready-deployment.HealthTest.war",
> "status": "UP"
> }
> ]
> }
> //live
> {
> "status": "UP",
> "checks": [
> {
> "name": "live",
> "status": "UP",
> "data": {
> "key": "value"
> }
> }
> ]
> }
> //ready
> {
> "status": "UP",
> "checks": [
> {
> "name": "ready-deployment.HealthTest.war",
> "status": "UP"
> }
> ]
> }
> {code}
> 2. here are the results for the same calls against Wildfly 19 Beta 1:
> {code}
> //health
> {
> "status": "UP",
> "checks": [
> {
> "name": "live",
> "status": "UP",
> "data": {
> "key": "value"
> }
> }
> ]
> }
> //live
> {
> "status": "UP",
> "checks": [
> {
> "name": "live",
> "status": "UP",
> "data": {
> "key": "value"
> }
> }
> ]
> }
> //ready
> {
> "status": "UP",
> "checks": []
> }
> {code}
> [1]
> https://github.com/jmesnil/wildfly
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months