May 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-3785) The read-feature-description output should optionally provide package requirement information

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-3785: ---------------------------------------- Summary: The read-feature-description output should optionally provide package requirement information Key: WFCORE-3785 URL: https://issues.jboss.org/browse/WFCORE-3785 Project: WildFly Core Issue Type: Enhancement Components: Management Reporter: Brian Stansberry Assignee: ehsavoie Hugonnet If the presence of a resource implies the requirement for a module that is otherwise optional, the ManagementResourceRegistration and thus the read-feature-description output should be able to note that fact. This needs a bit of thought: 1) What data should be provided? Galleon package name? JBoss Modules module name? My guess is the former, as that is what is useful to the sole consumer of read-feature-description. Plus a dev team providing this data is going to end up needing to understand Galleon packages anyway. But I've only given it the amount of thought needed to type this paragraph. 2) Is simple presence/absence of a resource sufficient to control this. Any attribute involvement? (That is if foo==true, then we need package bar.) My instinct here again is attribute values are not relevant. This is conceptually related to capabilities -- an attribute is not allowed to provide a capability; only a resource can. A module provides the code necessary for a capability so there's no reason for a module dependency exist independent of a capability and therefore solely due to an attribute. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3784) Standard WildFly Core domain.xml is missing discovery and security-manager subsystems

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-3784: ---------------------------------------- Summary: Standard WildFly Core domain.xml is missing discovery and security-manager subsystems Key: WFCORE-3784 URL: https://issues.jboss.org/browse/WFCORE-3784 Project: WildFly Core Issue Type: Bug Components: Management Affects Versions: 5.0.0.Alpha4, 4.0.0.Final Reporter: Brian Stansberry Assignee: Brian Stansberry Priority: Minor See the title. :) It looks like these subsystems got added to the list for the standalone config but not for the domain profile. Those profiles should basically match, except for details related to some aspect of domain mode (e.g. there's some minor elytron subsystems diffs due to the location of files in a domain vs standalone server.) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

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

by Alexey Loubyansky (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3783?page=com.atlassian.jira.plugi... ] Alexey Loubyansky updated WFCORE-3783: -------------------------------------- Component/s: Management > 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 > Components: Management > 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)

7 years, 7 months

1
0
0 / 0

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

by Alexey Loubyansky (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3783?page=com.atlassian.jira.plugi... ] Alexey Loubyansky reassigned WFCORE-3783: ----------------------------------------- Assignee: Brian Stansberry > 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 > Components: Management > Reporter: Alexey Loubyansky > Assignee: Brian Stansberry > > Default module slot main should not be appearing in the provisioning package name. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[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)

7 years, 7 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)

7 years, 7 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)

7 years, 7 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)

7 years, 7 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)

7 years, 7 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)

7 years, 7 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