[JBoss JIRA] (WFWIP-359) Server can get to state, where XP2 manager thinks both XP1 and XP2 streams are active
by Oleksiy Lubyanskyy (Jira)
[ https://issues.redhat.com/browse/WFWIP-359?page=com.atlassian.jira.plugin... ]
Oleksiy Lubyanskyy commented on WFWIP-359:
------------------------------------------
When multiple patch stream support was implemented, there was no way to discover what the original installation included. So any patch from any stream was accepted as long as it did not result in a content (hash) conflict.
> Server can get to state, where XP2 manager thinks both XP1 and XP2 streams are active
> -------------------------------------------------------------------------------------
>
> Key: WFWIP-359
> URL: https://issues.redhat.com/browse/WFWIP-359
> Project: WildFly WIP
> Issue Type: Bug
> Reporter: Martin Svehla
> Assignee: Kabir Khan
> Priority: Major
>
> If I run setup first, manager activates XP2 stream. However, if I then use patch-apply to apply XP1 patch, manager lets this action to happen and then thinks both streams are active.
> {code}
> $ java -jar manager.jar status --jboss-home=jboss-eap-73
> Starting JBoss EAP XP manager (2.0.0.Final-redhat-20200911).
> The JBoss EAP XP patch stream is enabled. You may apply patches both from the JBoss EAP and the JBoss EAP XP patch streams. While enabled the following support policy applies:
> [snip]
> You are currently on JBoss EAP XP 2.
> Enabled patch streams and their cumulative patch ids:
> - Patch stream: 'JBoss EAP'; Cumulative patch id: 'base'
> - Patch stream: 'jboss-eap-xp-2.0'; Cumulative patch id: 'base'
> Available commands in this state are: [remove]
> {code}
> {code}
> $ java -jar manager.jar patch-apply --jboss-home=jboss-eap-7.3 --patch=jboss-eap-xp-1.0.2.GA-redhat-20200911-patch.zip
> {code}
> {code}
> $ java -jar manager.jar status --jboss-home=jboss-eap-7.3
> Starting JBoss EAP XP manager (2.0.0.Final-redhat-20200911).
> The JBoss EAP XP patch stream setup in the JBoss EAP server seems broken.
> Enabled patch streams and their cumulative patch ids:
> - Patch stream: 'JBoss EAP'; Cumulative patch id: 'base'
> - Patch stream: 'jboss-eap-xp-2.0'; Cumulative patch id: 'base'
> - Patch stream: 'jboss-eap-xp-1.0'; Cumulative patch id: 'jboss-eap-xp-1.0.2.CP'
> Available commands in this state are: [remove]
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (WFWIP-359) Server can get to state, where XP2 manager thinks both XP1 and XP2 streams are active
by Oleksiy Lubyanskyy (Jira)
[ https://issues.redhat.com/browse/WFWIP-359?page=com.atlassian.jira.plugin... ]
Oleksiy Lubyanskyy commented on WFWIP-359:
------------------------------------------
It's been awhile since I looked into that. Sound like we need to be able to detect the layer id and the patch stream id for that layer and fail in case there is an attempt to mix different streams from the same layer in the same installation. E.g. instead of `$JBOSS_HOME/.installation/<patch-stream-name>.conf` we could have had `$JBOSS_HOME/.installation/<layer-id>/<patch-stream-id>.conf`. Not yet sure how difficult it would be to implement that.
A possible quick workaround could be to introduce some basic content that is incompatible between xp1 and xp2, which would make patching fail in case a patch from the wrong stream is applied.
> Server can get to state, where XP2 manager thinks both XP1 and XP2 streams are active
> -------------------------------------------------------------------------------------
>
> Key: WFWIP-359
> URL: https://issues.redhat.com/browse/WFWIP-359
> Project: WildFly WIP
> Issue Type: Bug
> Reporter: Martin Svehla
> Assignee: Kabir Khan
> Priority: Major
>
> If I run setup first, manager activates XP2 stream. However, if I then use patch-apply to apply XP1 patch, manager lets this action to happen and then thinks both streams are active.
> {code}
> $ java -jar manager.jar status --jboss-home=jboss-eap-73
> Starting JBoss EAP XP manager (2.0.0.Final-redhat-20200911).
> The JBoss EAP XP patch stream is enabled. You may apply patches both from the JBoss EAP and the JBoss EAP XP patch streams. While enabled the following support policy applies:
> [snip]
> You are currently on JBoss EAP XP 2.
> Enabled patch streams and their cumulative patch ids:
> - Patch stream: 'JBoss EAP'; Cumulative patch id: 'base'
> - Patch stream: 'jboss-eap-xp-2.0'; Cumulative patch id: 'base'
> Available commands in this state are: [remove]
> {code}
> {code}
> $ java -jar manager.jar patch-apply --jboss-home=jboss-eap-7.3 --patch=jboss-eap-xp-1.0.2.GA-redhat-20200911-patch.zip
> {code}
> {code}
> $ java -jar manager.jar status --jboss-home=jboss-eap-7.3
> Starting JBoss EAP XP manager (2.0.0.Final-redhat-20200911).
> The JBoss EAP XP patch stream setup in the JBoss EAP server seems broken.
> Enabled patch streams and their cumulative patch ids:
> - Patch stream: 'JBoss EAP'; Cumulative patch id: 'base'
> - Patch stream: 'jboss-eap-xp-2.0'; Cumulative patch id: 'base'
> - Patch stream: 'jboss-eap-xp-1.0'; Cumulative patch id: 'jboss-eap-xp-1.0.2.CP'
> Available commands in this state are: [remove]
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (WFWIP-359) Server can get to state, where XP2 manager thinks both XP1 and XP2 streams are active
by Kabir Khan (Jira)
[ https://issues.redhat.com/browse/WFWIP-359?page=com.atlassian.jira.plugin... ]
Kabir Khan commented on WFWIP-359:
----------------------------------
As discussed with [~msvehla] we will leave this as-is. I will enhance the message to make it more obvious how the user could have ended up in this state, and try to enhance the manager patch-apply command to inspect the target patch stream of the passed in patch.
> Server can get to state, where XP2 manager thinks both XP1 and XP2 streams are active
> -------------------------------------------------------------------------------------
>
> Key: WFWIP-359
> URL: https://issues.redhat.com/browse/WFWIP-359
> Project: WildFly WIP
> Issue Type: Bug
> Reporter: Martin Svehla
> Assignee: Kabir Khan
> Priority: Major
>
> If I run setup first, manager activates XP2 stream. However, if I then use patch-apply to apply XP1 patch, manager lets this action to happen and then thinks both streams are active.
> {code}
> $ java -jar manager.jar status --jboss-home=jboss-eap-73
> Starting JBoss EAP XP manager (2.0.0.Final-redhat-20200911).
> The JBoss EAP XP patch stream is enabled. You may apply patches both from the JBoss EAP and the JBoss EAP XP patch streams. While enabled the following support policy applies:
> [snip]
> You are currently on JBoss EAP XP 2.
> Enabled patch streams and their cumulative patch ids:
> - Patch stream: 'JBoss EAP'; Cumulative patch id: 'base'
> - Patch stream: 'jboss-eap-xp-2.0'; Cumulative patch id: 'base'
> Available commands in this state are: [remove]
> {code}
> {code}
> $ java -jar manager.jar patch-apply --jboss-home=jboss-eap-7.3 --patch=jboss-eap-xp-1.0.2.GA-redhat-20200911-patch.zip
> {code}
> {code}
> $ java -jar manager.jar status --jboss-home=jboss-eap-7.3
> Starting JBoss EAP XP manager (2.0.0.Final-redhat-20200911).
> The JBoss EAP XP patch stream setup in the JBoss EAP server seems broken.
> Enabled patch streams and their cumulative patch ids:
> - Patch stream: 'JBoss EAP'; Cumulative patch id: 'base'
> - Patch stream: 'jboss-eap-xp-2.0'; Cumulative patch id: 'base'
> - Patch stream: 'jboss-eap-xp-1.0'; Cumulative patch id: 'jboss-eap-xp-1.0.2.CP'
> Available commands in this state are: [remove]
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (WFWIP-359) Server can get to state, where XP2 manager thinks both XP1 and XP2 streams are active
by Kabir Khan (Jira)
[ https://issues.redhat.com/browse/WFWIP-359?page=com.atlassian.jira.plugin... ]
Kabir Khan commented on WFWIP-359:
----------------------------------
[~msvehla] This actually seems like a bug in patching:
I have a vanilla (faked to be 7.3.4) server, which I start and then try to apply patches via the CLI:
{code:java}
[standalone@localhost:9990 /] patch apply ../xp-patching/jboss-eap-xp-1.0.0-patch.zip
WFLYPAT0013: There is no layer called microprofile installed
[standalone@localhost:9990 /] patch apply ../xp-patching/jboss-eap-xp-2.0.0-patch.zip
WFLYPAT0013: There is no layer called microprofile installed
{code}
Next I run the setup command and enable the 2.0.0 patch stream, then in CLI I can apply the wrong patch as you did using the patch-apply command:
{code:java}
[standalone@localhost:9990 /] patch apply ../xp-patching/jboss-eap-xp-1.0.0-patch.zip
{
"outcome" : "success",
"response-headers" : {
"operation-requires-restart" : true,
"process-state" : "restart-required"
}
}
{code}
The manager status command results in the same output you showed. I see it has created a $JBOSS_HOME/.installation/jboss-eap-xp-1.0.conf in addition to the $JBOSS_HOME/.installation/jboss-eap-xp-2.0.conf that was created by the manager setup command. These $JBOSS_HOME/.installation/<patch-stream-name>.conf files are part of the setup of each patch stream.
So it seems that patching checks for the layer rather than the presence of the jboss-eap-xp-1.0.conf file. Now, I am not sure how to fix this as this seems to be a deeper issue in patching, for which I don't know the history.
The issue is (ignoring the XP streams) that if you download EAP 7.3.0, the .installation/ directory is empty. Once you apply the first base patch you end up with a .installation/JBoss\ EAP.conf ("JBoss EAP" is the name of the main patch stream), as well as the .installation/layers/ and .installation/patches directories containing some more information.
I deduce from this that:
1. The main check when applying the patches is the presence of the layers affected by the patch.zip
2. The .installation/<patch-stream-name>.conf is created on demand if not there
I don't know how safe it is to update patching to change 2. to enforce the presence of the .installation/XXX.conf file as it could have unforeseen consequences for layered projects etc.
CC [~aloubyansky] [~brian.stansberry]
I can try to inspect the patch in the patch-apply command to make sure it is valid for the patch stream. But that still does not stop users from running CLI to apply patches from the wrong XP stream.
> Server can get to state, where XP2 manager thinks both XP1 and XP2 streams are active
> -------------------------------------------------------------------------------------
>
> Key: WFWIP-359
> URL: https://issues.redhat.com/browse/WFWIP-359
> Project: WildFly WIP
> Issue Type: Bug
> Reporter: Martin Svehla
> Assignee: Kabir Khan
> Priority: Major
>
> If I run setup first, manager activates XP2 stream. However, if I then use patch-apply to apply XP1 patch, manager lets this action to happen and then thinks both streams are active.
> {code}
> $ java -jar manager.jar status --jboss-home=jboss-eap-73
> Starting JBoss EAP XP manager (2.0.0.Final-redhat-20200911).
> The JBoss EAP XP patch stream is enabled. You may apply patches both from the JBoss EAP and the JBoss EAP XP patch streams. While enabled the following support policy applies:
> [snip]
> You are currently on JBoss EAP XP 2.
> Enabled patch streams and their cumulative patch ids:
> - Patch stream: 'JBoss EAP'; Cumulative patch id: 'base'
> - Patch stream: 'jboss-eap-xp-2.0'; Cumulative patch id: 'base'
> Available commands in this state are: [remove]
> {code}
> {code}
> $ java -jar manager.jar patch-apply --jboss-home=jboss-eap-7.3 --patch=jboss-eap-xp-1.0.2.GA-redhat-20200911-patch.zip
> {code}
> {code}
> $ java -jar manager.jar status --jboss-home=jboss-eap-7.3
> Starting JBoss EAP XP manager (2.0.0.Final-redhat-20200911).
> The JBoss EAP XP patch stream setup in the JBoss EAP server seems broken.
> Enabled patch streams and their cumulative patch ids:
> - Patch stream: 'JBoss EAP'; Cumulative patch id: 'base'
> - Patch stream: 'jboss-eap-xp-2.0'; Cumulative patch id: 'base'
> - Patch stream: 'jboss-eap-xp-1.0'; Cumulative patch id: 'jboss-eap-xp-1.0.2.CP'
> Available commands in this state are: [remove]
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (ELY-1950) FORM authentication not working for URL encoded session IDs
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/ELY-1950?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse resolved ELY-1950.
-----------------------------------
Fix Version/s: 1.12.0.CR1
1.11.4.Final
1.10.7.Final
(was: 1.14.0.CR1)
Resolution: Done
> FORM authentication not working for URL encoded session IDs
> -----------------------------------------------------------
>
> Key: ELY-1950
> URL: https://issues.redhat.com/browse/ELY-1950
> Project: WildFly Elytron
> Issue Type: Bug
> Components: HTTP
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 1.12.0.CR1, 1.11.4.Final, 1.10.7.Final
>
>
> The session IDs are encoded as: -
> {code}
> /secure/j_security_check;jsessionid=kVzsBG9c3XxcOlzpa65ohiMeMNqXdSNQuOdvdpR3.flame
> {code}
> However the code that checks if this is a submission to j_security_check is: -
> {code:java}
> request.getRequestURI().getPath().endsWith(postLocation)
> {code}
> This code needs to trim the path at ';'
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (JGRP-2502) If the KUBERNETES_NAMESPACE is not set the default value is the "default" namespace
by Filippe Spolti (Jira)
[ https://issues.redhat.com/browse/JGRP-2502?page=com.atlassian.jira.plugin... ]
Filippe Spolti commented on JGRP-2502:
--------------------------------------
I can open there. (https://github.com/jgroups-extras/jgroups-kubernetes/issues/109)
About the warning message, I am ok with it,m since this message is printed only once on the logs, not every X seconds as it is happening today.
And would be very great was well to provide a way to disable clustering configuration, most of the time we just scale up standalone apps that does not need to have this feature enabled. they way it is done today, I didn't find a way to totally disable clustering.
> If the KUBERNETES_NAMESPACE is not set the default value is the "default" namespace
> ------------------------------------------------------------------------------------
>
> Key: JGRP-2502
> URL: https://issues.redhat.com/browse/JGRP-2502
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 5.0.4
> Reporter: Filippe Spolti
> Assignee: Bela Ban
> Priority: Minor
>
> If no namespace is set it defaults to the "default" ocp namespace which will case the warn as described in the log message below:
>
> {code:java}
> WARN [org.jgroups.protocols.kubernetes.KUBE_PING] (thread-9,ee,hdm78-kieserver-1-nggcf) failed getting JSON response from Kubernetes Client[masterUrl=https://172.30.0.1:443/api/v1, headers={Authorization=#MASKED:937#}, connectTimeout=5000, readTimeout=30000, operationAttempts=3, operationSleep=1000, streamProvider=org.jgroups.protocols.kubernetes.stream.TokenStreamProvider@69991c01] for cluster [ee], namespace [default], labels [null]; encountered [java.lang.Exception: 3 attempt(s) with a 1000ms sleep to execute [OpenStream] failed. Last failure was [java.io.IOException: Server returned HTTP response code: 403 for URL: https://172.30.0.1:443/api/v1/namespaces/default/pods]]
> {code}
> IMHO the default namespace should not be used in this case since this namespace should not be used to deploy applications.
>
> If the namespace is not set it means that we do not want to enable the clustering feature, as the namespace is set if the namespace is not set, this condition [1] is not satisfied and the configuration will proceed.
>
> Another problem found in the tests is that, if we do set the KUBERNETES_NAMESPACE with no value, it will detect that the env has an value and will try to use a blank namespace:
>
> {code:java}
> failed getting JSON response from Kubernetes Client[masterUrl=https://172.30.0.1:443/api/v1 , headers={Authorization=#MASKED:874#}, connectTimeout=5000, readTimeout=30000, operationAttempts=3, operationSleep=1000, streamProvider=org.jgroups.protocols.kubernetes.stream.TokenStreamProvider@17978314] for cluster [ee], namespace [], labels [null]; encountered [java.lang.Exception: 3 attempt(s) with a 1000ms sleep to execute [OpenStream] failed. Last failure was [java.io.IOException: Server returned HTTP response code: 403 for URL: https://172.30.0.1:443/api/v1/pods ]]
> {code}
>
> [1] - https://github.com/jgroups-extras/jgroups-kubernetes/blob/master/src/main/java/org/jgroups/protocols/kubernetes/KUBE_PING.java#L145
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (JGRP-2502) If the KUBERNETES_NAMESPACE is not set the default value is the "default" namespace
by Filippe Spolti (Jira)
[ https://issues.redhat.com/browse/JGRP-2502?page=com.atlassian.jira.plugin... ]
Filippe Spolti edited comment on JGRP-2502 at 9/24/20 8:59 AM:
---------------------------------------------------------------
I can open there. ([https://github.com/jgroups-extras/jgroups-kubernetes/issues/109])
About the warning message, I am ok with it,m since this message is printed only once on the logs, not every X seconds as it is happening today.
And would be very great was well to provide a way to disable clustering configuration, most of the time we just scale up standalone apps that does not need to have this feature enabled. the way it is done today, I didn't find a way to totally disable clustering.
was (Author: filippe.spolti):
I can open there. (https://github.com/jgroups-extras/jgroups-kubernetes/issues/109)
About the warning message, I am ok with it,m since this message is printed only once on the logs, not every X seconds as it is happening today.
And would be very great was well to provide a way to disable clustering configuration, most of the time we just scale up standalone apps that does not need to have this feature enabled. they way it is done today, I didn't find a way to totally disable clustering.
> If the KUBERNETES_NAMESPACE is not set the default value is the "default" namespace
> ------------------------------------------------------------------------------------
>
> Key: JGRP-2502
> URL: https://issues.redhat.com/browse/JGRP-2502
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 5.0.4
> Reporter: Filippe Spolti
> Assignee: Bela Ban
> Priority: Minor
>
> If no namespace is set it defaults to the "default" ocp namespace which will case the warn as described in the log message below:
>
> {code:java}
> WARN [org.jgroups.protocols.kubernetes.KUBE_PING] (thread-9,ee,hdm78-kieserver-1-nggcf) failed getting JSON response from Kubernetes Client[masterUrl=https://172.30.0.1:443/api/v1, headers={Authorization=#MASKED:937#}, connectTimeout=5000, readTimeout=30000, operationAttempts=3, operationSleep=1000, streamProvider=org.jgroups.protocols.kubernetes.stream.TokenStreamProvider@69991c01] for cluster [ee], namespace [default], labels [null]; encountered [java.lang.Exception: 3 attempt(s) with a 1000ms sleep to execute [OpenStream] failed. Last failure was [java.io.IOException: Server returned HTTP response code: 403 for URL: https://172.30.0.1:443/api/v1/namespaces/default/pods]]
> {code}
> IMHO the default namespace should not be used in this case since this namespace should not be used to deploy applications.
>
> If the namespace is not set it means that we do not want to enable the clustering feature, as the namespace is set if the namespace is not set, this condition [1] is not satisfied and the configuration will proceed.
>
> Another problem found in the tests is that, if we do set the KUBERNETES_NAMESPACE with no value, it will detect that the env has an value and will try to use a blank namespace:
>
> {code:java}
> failed getting JSON response from Kubernetes Client[masterUrl=https://172.30.0.1:443/api/v1 , headers={Authorization=#MASKED:874#}, connectTimeout=5000, readTimeout=30000, operationAttempts=3, operationSleep=1000, streamProvider=org.jgroups.protocols.kubernetes.stream.TokenStreamProvider@17978314] for cluster [ee], namespace [], labels [null]; encountered [java.lang.Exception: 3 attempt(s) with a 1000ms sleep to execute [OpenStream] failed. Last failure was [java.io.IOException: Server returned HTTP response code: 403 for URL: https://172.30.0.1:443/api/v1/pods ]]
> {code}
>
> [1] - https://github.com/jgroups-extras/jgroups-kubernetes/blob/master/src/main/java/org/jgroups/protocols/kubernetes/KUBE_PING.java#L145
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (DROOLS-4605) DMN alpha network
by Luca Molteni (Jira)
[ https://issues.redhat.com/browse/DROOLS-4605?page=com.atlassian.jira.plug... ]
Luca Molteni updated DROOLS-4605:
---------------------------------
Sprint: 2020 Week 34-36 (from Aug 17), 2020 Week 40-42 (from Sep 28) (was: 2020 Week 34-36 (from Aug 17), 2020 Week 37-39 (from Sep 7))
> DMN alpha network
> -----------------
>
> Key: DROOLS-4605
> URL: https://issues.redhat.com/browse/DROOLS-4605
> Project: Drools
> Issue Type: Story
> Components: dmn engine
> Reporter: Matteo Mortari
> Assignee: Luca Molteni
> Priority: Major
>
> *Motivation*: a DMN decision table can be evaluated faster than naive algorithm by translating it into a Rete/Phreak, but the current kie7 approach is suffering from performance bottleneck artificially induced by use of kie7 rule units, which provide more harm than benefit to perfomance (performance is actually worst for most "realistic" cases).
> *Goals*: a POC to understand what’s need to be done to support the alpha network compiler (wihout kie7 rule units) in DMN. We currently estimate it will take us 1 to 2 summer sprints and the output will be more epics to implement this feature.
> *Impact*: alpha network compiler code refactors for the better use of.
> One part of the POC was to hard-code the alpha network for a specific table ([DROOLS-4566]) the remained of the poc is to generalize the approach further to fully assess the impacts thanks to the poc.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (DROOLS-4606) DMN alpha network POC
by Luca Molteni (Jira)
[ https://issues.redhat.com/browse/DROOLS-4606?page=com.atlassian.jira.plug... ]
Luca Molteni updated DROOLS-4606:
---------------------------------
Sprint: 2019 Week 41-43 (from Okt 7), 2019 Week 44-46 (from Okt 28), 2019 Week 47-49 (from Nov 18), 2020 Week 31-33 (from Jul 27), 2020 Week 34-36 (from Aug 17), 2020 Week 40-42 (from Sep 28) (was: 2019 Week 41-43 (from Okt 7), 2019 Week 44-46 (from Okt 28), 2019 Week 47-49 (from Nov 18), 2020 Week 31-33 (from Jul 27), 2020 Week 34-36 (from Aug 17), 2020 Week 37-39 (from Sep 7))
> DMN alpha network POC
> ---------------------
>
> Key: DROOLS-4606
> URL: https://issues.redhat.com/browse/DROOLS-4606
> Project: Drools
> Issue Type: Task
> Components: dmn engine
> Reporter: Matteo Mortari
> Assignee: Luca Molteni
> Priority: Major
>
> Start refactoring work to support alpha network
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years