May 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-3783) read-feature-description: remove the default module slot main from the provisioning package name

by Alexey Loubyansky (JIRA)

Alexey Loubyansky created WFCORE-3783: ----------------------------------------- Summary: read-feature-description: remove the default module slot main from the provisioning package name Key: WFCORE-3783 URL: https://issues.jboss.org/browse/WFCORE-3783 Project: WildFly Core Issue Type: Task Reporter: Alexey Loubyansky Default module slot main should not be appearing in the provisioning package name. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10315) Restore legacy (not "graceful") startup mode

by Vladimir Grabarchuk (JIRA)

[ https://issues.jboss.org/browse/WFLY-10315?page=com.atlassian.jira.plugin... ] Vladimir Grabarchuk commented on WFLY-10315: -------------------------------------------- No, this is not about rejecting requests with an error until the full startup; neither rejecting nor blocking will do us any good here. This is a request to restore (make possible) the legacy, pre-WF11 behavior where the use case in hand was working perfectly. Here are some more details. The config service is set to deploy first and must be able to serve requests from other components being deployed in the same container. These other components depend on the configuration data from the above service, which they try to acquire at their deployment time (that is, while the container is still starting) and fail to deploy altogether without it. The only way to satisfy this requirement post WF10 is to deploy the configuration service into a server of its own, which is wasteful and prohibitively expensive. I hope that clarifies the situation somewhat. Please consider bringing back the legacy behavior to accommodate cases like that. I don't pretend to know much about the WildFly innards, but hoping that it might be some kind of a "switch" not to block HTTP requests while the server is still in the deployment mode. Naturally, those who chose to enable this mode, should it become available, will be responsible for the correct component deployment order and would have to deal with 404 and/or other errors. > Restore legacy (not "graceful") startup mode > -------------------------------------------- > > Key: WFLY-10315 > URL: https://issues.jboss.org/browse/WFLY-10315 > Project: WildFly > Issue Type: Feature Request > Reporter: Vladimir Grabarchuk > Assignee: Jason Greene > > Please allow a configurable legacy startup mode which was the default before WF11, when components can service HTTP requests as soon as they are deployed, not when the container deploys all components. > The use case for this is the following: there is a configuration service component upon which other components depend for configuration data, requested and served via a HTTP request. With the new "graceful startup" this scenario no longer seems possible, as it results in read timeouts, mis-configured artifacts, and failed deployments altogether. > If generally feasible, another value of the *--start-mode=legacy* seems appropriate to accommodate the original (legacy) behavior. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-194) ISTIOOC Client

by Matt Mahoney (JIRA)

[ https://issues.jboss.org/browse/SWSQE-194?page=com.atlassian.jira.plugin.... ] Matt Mahoney updated SWSQE-194: ------------------------------- Description: [ Jenkins ISTIO Install] script doesn't use the istiooc client that Kevin has been building. Right now there are issues with the ansible-installer that cause few errors - I don't know what exactly the issues are, but Kevin is aware and has it in his to-do list to patch and send a PR very soon. was: [ISTIO Jenkins Install] script doesn't use the istiooc client that Kevin has been building. Right now there are issues with the ansible-installer that cause few errors - I don't know what exactly the issues are, but Kevin is aware and has it in his to-do list to patch and send a PR very soon. Team: Infrastructure (was: Infrastructure) > ISTIOOC Client > --------------- > > Key: SWSQE-194 > URL: https://issues.jboss.org/browse/SWSQE-194 > Project: Kiali QE > Issue Type: Story > Reporter: Matt Mahoney > Assignee: Michael Foley > > [ Jenkins ISTIO Install] script doesn't use the istiooc client that Kevin has been building. > Right now there are issues with the ansible-installer that cause few errors - I don't know what exactly the issues are, but Kevin is aware and has it in his to-do list to patch and send a PR very soon. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-194) ISTIOOC Client

by Matt Mahoney (JIRA)

[ https://issues.jboss.org/browse/SWSQE-194?page=com.atlassian.jira.plugin.... ] Matt Mahoney commented on SWSQE-194: ------------------------------------ User journey do (customers being pointed to this doc) https://github.com/openshift-istio/istio-docs/blob/master/user-journey.adoc How to get istiooc: https://github.com/openshift-istio/istio-docs/blob/master/user-journey.ad... > ISTIOOC Client > --------------- > > Key: SWSQE-194 > URL: https://issues.jboss.org/browse/SWSQE-194 > Project: Kiali QE > Issue Type: Story > Reporter: Matt Mahoney > Assignee: Michael Foley > > [ISTIO Jenkins Install] script doesn't use the istiooc client that Kevin has been building. > Right now there are issues with the ansible-installer that cause few errors - I don't know what exactly the issues are, but Kevin is aware and has it in his to-do list to patch and send a PR very soon. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-196) Refactor Pipeline To Use IstioOC Client

by Matt Mahoney (JIRA)

Matt Mahoney created SWSQE-196: ---------------------------------- Summary: Refactor Pipeline To Use IstioOC Client Key: SWSQE-196 URL: https://issues.jboss.org/browse/SWSQE-196 Project: Kiali QE Issue Type: Sub-task Reporter: Matt Mahoney Assignee: Michael Foley Refactor the Pipeline to use IstioOC Client -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-195) Explore and learn IstioOC Client

by Matt Mahoney (JIRA)

Matt Mahoney created SWSQE-195: ---------------------------------- Summary: Explore and learn IstioOC Client Key: SWSQE-195 URL: https://issues.jboss.org/browse/SWSQE-195 Project: Kiali QE Issue Type: Sub-task Reporter: Matt Mahoney Assignee: Michael Foley -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-194) ISTIOOC Client

by Matt Mahoney (JIRA)

Matt Mahoney created SWSQE-194: ---------------------------------- Summary: ISTIOOC Client Key: SWSQE-194 URL: https://issues.jboss.org/browse/SWSQE-194 Project: Kiali QE Issue Type: Story Reporter: Matt Mahoney Assignee: Michael Foley [ISTIO Jenkins Install] script doesn't use the istiooc client that Kevin has been building. Right now there are issues with the ansible-installer that cause few errors - I don't know what exactly the issues are, but Kevin is aware and has it in his to-do list to patch and send a PR very soon. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10316) Upgrade WildFly Transaction Client to 1.0.3.Final

by David Lloyd (JIRA)

David Lloyd created WFLY-10316: ---------------------------------- Summary: Upgrade WildFly Transaction Client to 1.0.3.Final Key: WFLY-10316 URL: https://issues.jboss.org/browse/WFLY-10316 Project: WildFly Issue Type: Component Upgrade Components: Transactions Reporter: David Lloyd Assignee: David Lloyd -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2253) FD_SOCK is not working in AWS environment

by Sibin Karnavar (JIRA)

[ https://issues.jboss.org/browse/JGRP-2253?page=com.atlassian.jira.plugin.... ] Sibin Karnavar commented on JGRP-2253: -------------------------------------- I am sorry I am late on this. I will provide the requested information before end of tomorrow. > FD_SOCK is not working in AWS environment > ----------------------------------------- > > Key: JGRP-2253 > URL: https://issues.jboss.org/browse/JGRP-2253 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.10 > Environment: AWS - EC2 > Reporter: Sibin Karnavar > Assignee: Bela Ban > Fix For: 4.0.12 > > > We have our failure detection defined like below. > <FD_SOCK external_port="7804" /> > <FD timeout="3000" max_tries="3" /> > <VERIFY_SUSPECT timeout="3000" /> > Please note that we have used FD instead of FD_ALL in AWS. We will be changing it to FD_ALL later after detailed testing. > In my local, this is working perfect. As soon as I kill my node, I was able to see that view change was happening immediately with FD_SOCK. > We were not mentioning the external_port in the FD_SOCK but later I thought it may be an issue with the port and defined it as 7804 and added the same port to the security group that allows to access this port among all the nodes. So no issue with the port. > Can you please let us know if we need any additional configurations to make FD_SOCK works well in AWS. > Thanks, > Sibin -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3782) DNS-SD/mDNS service discovery support

by David Lloyd (JIRA)

David Lloyd created WFCORE-3782: ----------------------------------- Summary: DNS-SD/mDNS service discovery support Key: WFCORE-3782 URL: https://issues.jboss.org/browse/WFCORE-3782 Project: WildFly Core Issue Type: Enhancement Components: Discovery Reporter: David Lloyd Assignee: David Lloyd This covers support for service discovery configurations using DNS-SD and/or mDNS. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2018