[JBoss JIRA] (WFCORE-3922) Support Maven staged repositories
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3922?page=com.atlassian.jira.plugi... ]
Jeff Mesnil updated WFCORE-3922:
--------------------------------
Description:
Supporting Maven staged repositories in WildFly Core allows its components to be tested without having to be released.
(see WFLY-10495 for a thorough description of the feature in WildFly)
was:
When WildFly Core is released, one of the step is to check that the Core releases can be downloaded from Nexus repositories to build WildFly.
However that step requires to release WildFly Core artifacts. If something went wrong, the release is out and there is nothing we can do except moving to the next release and restart the whole process.
We should instead ensure that WildFly can access Nexus staging repositories so that we can verify that WildFly can download and uses the Core artifcats before they are actually released.
If something goes wrong, we can redo the tag without any issue.
This simplifies the release of WildFly core:
1. the Core release is created as usual.
2. WildFly consumes the artifacts from the staging repository
3. If everything is fine, the last steps for Core releases are the Git tag and the actual release from the staging repository.
> Support Maven staged repositories
> ---------------------------------
>
> Key: WFCORE-3922
> URL: https://issues.jboss.org/browse/WFCORE-3922
> Project: WildFly Core
> Issue Type: Task
> Components: Build System
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
>
> Supporting Maven staged repositories in WildFly Core allows its components to be tested without having to be released.
> (see WFLY-10495 for a thorough description of the feature in WildFly)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFCORE-3922) Support Maven staged repositories
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3922?page=com.atlassian.jira.plugi... ]
Jeff Mesnil moved WFLY-10551 to WFCORE-3922:
--------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-3922 (was: WFLY-10551)
Component/s: Build System
(was: Build System)
Fix Version/s: (was: 14.0.0.CR1)
> Support Maven staged repositories
> ---------------------------------
>
> Key: WFCORE-3922
> URL: https://issues.jboss.org/browse/WFCORE-3922
> Project: WildFly Core
> Issue Type: Task
> Components: Build System
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
>
> When WildFly Core is released, one of the step is to check that the Core releases can be downloaded from Nexus repositories to build WildFly.
> However that step requires to release WildFly Core artifacts. If something went wrong, the release is out and there is nothing we can do except moving to the next release and restart the whole process.
> We should instead ensure that WildFly can access Nexus staging repositories so that we can verify that WildFly can download and uses the Core artifcats before they are actually released.
> If something goes wrong, we can redo the tag without any issue.
> This simplifies the release of WildFly core:
> 1. the Core release is created as usual.
> 2. WildFly consumes the artifacts from the staging repository
> 3. If everything is fine, the last steps for Core releases are the Git tag and the actual release from the staging repository.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10551) Support Maven staged repositories
by Jeff Mesnil (JIRA)
Jeff Mesnil created WFLY-10551:
----------------------------------
Summary: Support Maven staged repositories
Key: WFLY-10551
URL: https://issues.jboss.org/browse/WFLY-10551
Project: WildFly
Issue Type: Task
Components: Build System
Reporter: Jeff Mesnil
Assignee: Jeff Mesnil
Fix For: 14.0.0.CR1
When WildFly Core is released, one of the step is to check that the Core releases can be downloaded from Nexus repositories to build WildFly.
However that step requires to release WildFly Core artifacts. If something went wrong, the release is out and there is nothing we can do except moving to the next release and restart the whole process.
We should instead ensure that WildFly can access Nexus staging repositories so that we can verify that WildFly can download and uses the Core artifcats before they are actually released.
If something goes wrong, we can redo the tag without any issue.
This simplifies the release of WildFly core:
1. the Core release is created as usual.
2. WildFly consumes the artifacts from the staging repository
3. If everything is fine, the last steps for Core releases are the Git tag and the actual release from the staging repository.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (JGRP-2276) MERGE3: a dead member as merge leader will never trigger a merge
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2276?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2276 at 6/12/18 2:09 AM:
---------------------------------------------------------
It seems that ASYM_ENCRYPT somehow discards view 3|6 in member 7. NAKACK2 apparently doesn't retransmit that view (triggered by STABLE), so it must consider the view message _delivered_. Todo: investigate whether the VIEW message is indeed in member 7's digest.
was (Author: belaban):
It seems that ASYM_ENCRYPT somehow discards view 3|6 in member 7. NAKACK2 apparently doesn't retransmit that view (triggered by STABLE), so it must consider the view message _delivered_.
> MERGE3: a dead member as merge leader will never trigger a merge
> ----------------------------------------------------------------
>
> Key: JGRP-2276
> URL: https://issues.jboss.org/browse/JGRP-2276
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0.12
>
>
> When we have member(s) which have a view with a dead member as coordinator, when the dead member becomes part of the subgroup coordinators and _happens to be chosen as merge leader_, then a merge will never ensue.
> Example:
> * Member 2 (with view 2|5) was the previous coordinator and left the cluster, installing view 3|6 before stopping
> ** View 2|5=\{2,3,4,5,6,7\}; view 3|6=\{3,4,5,6,7\}
> * Member 7 didn't get view 3|6 and still has view 2|5
> * Everybody else has view 3|6
> * MERGE3 gets the following views:
> ** 2|5: 7 // member 7 has this view
> ** 3|6: 3,4,5,6 // members 3,4,5 and 6 have this view
> * 2 and 3 are added to a _sorted set_ and the first member of the set (2) is chose as merge leader. 3 doesn't take any action, as it notices it won't be the merge leader
> ** The reason 2 was first in the sorted set is that (possibly by coincidence) its UUID is *lower* than that of 3. If this wasn't the case, 3 would be merge leader and start (and successfully complete) a merge. However, with dead member 2 being picked as merge leader, a merge will never be triggered!
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (JGRP-2276) MERGE3: a dead member as merge leader will never trigger a merge
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2276?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2276:
--------------------------------
It seems that ASYM_ENCRYPT somehow discards view 3|6 in member 7. NAKACK2 apparently doesn't retransmit that view (triggered by STABLE), so it must consider the view message _delivered_.
> MERGE3: a dead member as merge leader will never trigger a merge
> ----------------------------------------------------------------
>
> Key: JGRP-2276
> URL: https://issues.jboss.org/browse/JGRP-2276
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0.12
>
>
> When we have member(s) which have a view with a dead member as coordinator, when the dead member becomes part of the subgroup coordinators and _happens to be chosen as merge leader_, then a merge will never ensue.
> Example:
> * Member 2 (with view 2|5) was the previous coordinator and left the cluster, installing view 3|6 before stopping
> ** View 2|5=\{2,3,4,5,6,7\}; view 3|6=\{3,4,5,6,7\}
> * Member 7 didn't get view 3|6 and still has view 2|5
> * Everybody else has view 3|6
> * MERGE3 gets the following views:
> ** 2|5: 7 // member 7 has this view
> ** 3|6: 3,4,5,6 // members 3,4,5 and 6 have this view
> * 2 and 3 are added to a _sorted set_ and the first member of the set (2) is chose as merge leader. 3 doesn't take any action, as it notices it won't be the merge leader
> ** The reason 2 was first in the sorted set is that (possibly by coincidence) its UUID is *lower* than that of 3. If this wasn't the case, 3 would be merge leader and start (and successfully complete) a merge. However, with dead member 2 being picked as merge leader, a merge will never be triggered!
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (JGRP-2276) MERGE3: a dead member as merge leader will never trigger a merge
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2276?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2276:
---------------------------
Description:
When we have member(s) which have a view with a dead member as coordinator, when the dead member becomes part of the subgroup coordinators and _happens to be chosen as merge leader_, then a merge will never ensue.
Example:
* Member 2 (with view 2|5) was the previous coordinator and left the cluster, installing view 3|6 before stopping
** View 2|5=\{2,3,4,5,6,7\}; view 3|6=\{3,4,5,6,7\}
* Member 7 didn't get view 3|6 and still has view 2|5
* Everybody else has view 3|6
* MERGE3 gets the following views:
** 2|5: 7 // member 7 has this view
** 3|6: 3,4,5,6 // members 3,4,5 and 6 have this view
* 2 and 3 are added to a _sorted set_ and the first member of the set (2) is chose as merge leader. 3 doesn't take any action, as it notices it won't be the merge leader
** The reason 2 was first in the sorted set is that (possibly by coincidence) its UUID is *lower* than that of 3. If this wasn't the case, 3 would be merge leader and start (and successfully complete) a merge. However, with dead member 2 being picked as merge leader, a merge will never be triggered!
was:
When we have member(s) which have a view with a dead member as coordinator, when the dead member becomes part of the subgroup coordinators and _happens to be chosen as merge leader_, then a merge will never ensue.
Example:
* Member 2 (with view 2|5) was the previous coordinator and left the cluster, installing view 3|6 before stopping
** View 2|5=\{2,3,4,5,6,7\}; view 3|6=\{3,4,5,6,7\}
* Member 7 didn't get view 3|6 and still has view 2|5
* Everybody else has view 3|6
* MERGE3 gets the following views:
** 2|5: 7 // member 7 has this view
** 3|6: 3,4,5,6 // members 3,4,5 and 6 have this view
* 2 and 3 are added to a _sorted set_ and the first member of the set (2) is chose as merge leader. 3 doesn't take any action, as it notices it won't be the merge leader
** The reason 2 was first in the sorted set is that (possibly by coincidence) its UUID is *lower* than that of 3. If this wan't the case, 3 would be merge leader and start (and successfully complete) a merge. However, with dead member 2 being picked as merge leader, a merge will never be triggered!
> MERGE3: a dead member as merge leader will never trigger a merge
> ----------------------------------------------------------------
>
> Key: JGRP-2276
> URL: https://issues.jboss.org/browse/JGRP-2276
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0.12
>
>
> When we have member(s) which have a view with a dead member as coordinator, when the dead member becomes part of the subgroup coordinators and _happens to be chosen as merge leader_, then a merge will never ensue.
> Example:
> * Member 2 (with view 2|5) was the previous coordinator and left the cluster, installing view 3|6 before stopping
> ** View 2|5=\{2,3,4,5,6,7\}; view 3|6=\{3,4,5,6,7\}
> * Member 7 didn't get view 3|6 and still has view 2|5
> * Everybody else has view 3|6
> * MERGE3 gets the following views:
> ** 2|5: 7 // member 7 has this view
> ** 3|6: 3,4,5,6 // members 3,4,5 and 6 have this view
> * 2 and 3 are added to a _sorted set_ and the first member of the set (2) is chose as merge leader. 3 doesn't take any action, as it notices it won't be the merge leader
> ** The reason 2 was first in the sorted set is that (possibly by coincidence) its UUID is *lower* than that of 3. If this wasn't the case, 3 would be merge leader and start (and successfully complete) a merge. However, with dead member 2 being picked as merge leader, a merge will never be triggered!
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (JGRP-2276) MERGE3: a dead member as merge leader will never trigger a merge
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2276?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2276:
---------------------------
Description:
When we have member(s) which have a view with a dead member as coordinator, when the dead member becomes part of the subgroup coordinators and _happens to be chosen as merge leader_, then a merge will never ensue.
Example:
* Member 2 (with view 2|5) was the previous coordinator and left the cluster, installing view 3|6 before stopping
** View 2|5=\{2,3,4,5,6,7\}; view 3|6=\{3,4,5,6,7\}
* Member 7 didn't get view 3|6 and still has view 2|5
* Everybody else has view 3|6
* MERGE3 gets the following views:
** 2|5: 7 // member 7 has this view
** 3|6: 3,4,5,6 // members 3,4,5 and 6 have this view
* 2 and 3 are added to a _sorted set_ and the first member of the set (2) is chose as merge leader. 3 doesn't take any action, as it notices it won't be the merge leader
** The reason 2 was first in the sorted set is that (possibly by coincidence) its UUID is *lower* than that of 3. If this wan't the case, 3 would be merge leader and start (and successfully complete) a merge. However, with dead member 2 being picked as merge leader, a merge will never be triggered!
was:
When we have member(s) which have a view with a dead member as coordinator, when the dead member becomes part of the subgroup coordinators and _happens to be chosen as merge leader_, then a merge will never ensue.
Example:
* Member 2 (with view 2|5) was the previous coordinator and left the cluster, installing view 3|6 before stopping
* Member 7 didn't get view 3|6 and still has view 2|5
* Everybody else has view 3|6
* MERGE3 gets the following views:
** 2|5: 7 // member 7 has this view
** 3|6: 3,4,5,6 // members 3,4,5 and 6 have this view
* 2 and 3 are added to a _sorted set_ and the first member of teh set (2) is chose as merge leader. 3 doesn't take any action, as it notices it won't be the merge leader
** The reason 2 was first in the sorted set is that (possibly by coincidence) its UUID is *lower* than that of 3. If this wan't the case, 3 would be merge leader and start (and successfully complete) a merge. However, with dead member 2 being picked as merge leader, a merge will never be triggered!
> MERGE3: a dead member as merge leader will never trigger a merge
> ----------------------------------------------------------------
>
> Key: JGRP-2276
> URL: https://issues.jboss.org/browse/JGRP-2276
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0.12
>
>
> When we have member(s) which have a view with a dead member as coordinator, when the dead member becomes part of the subgroup coordinators and _happens to be chosen as merge leader_, then a merge will never ensue.
> Example:
> * Member 2 (with view 2|5) was the previous coordinator and left the cluster, installing view 3|6 before stopping
> ** View 2|5=\{2,3,4,5,6,7\}; view 3|6=\{3,4,5,6,7\}
> * Member 7 didn't get view 3|6 and still has view 2|5
> * Everybody else has view 3|6
> * MERGE3 gets the following views:
> ** 2|5: 7 // member 7 has this view
> ** 3|6: 3,4,5,6 // members 3,4,5 and 6 have this view
> * 2 and 3 are added to a _sorted set_ and the first member of the set (2) is chose as merge leader. 3 doesn't take any action, as it notices it won't be the merge leader
> ** The reason 2 was first in the sorted set is that (possibly by coincidence) its UUID is *lower* than that of 3. If this wan't the case, 3 would be merge leader and start (and successfully complete) a merge. However, with dead member 2 being picked as merge leader, a merge will never be triggered!
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month