November 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SWSQE-996) Jenkins Job For Disconnected OCP Configurtation

by Tiago Moreira Vieira (Jira)

[ https://issues.jboss.org/browse/SWSQE-996?page=com.atlassian.jira.plugin.... ] Tiago Moreira Vieira updated SWSQE-996: --------------------------------------- Description: There is a need to test in Disconnected Configurations. Create Jenkins job to build Disconnected 4.x clusters. References: * [Installing Restricted Network Preparations|https://docs.openshift.com/container-platform/4.2/installing...] * [Disconnected Installation for Operators|https://docs.google.com/document/d/1n4MJgVk8g254s_X6oOgzC1z44Rc...] * [Your Operator and Disconnected Clusters|https://docs.google.com/document/d/1P4vsuf_yQ8Pl0Fpd1ZQMbHEL2bvt...] was: There is a need to test in Disconnected Configurations. Create Jenkins job to build Disconnected 4.x clusters. References: * [Disconnected Installation for Operators|https://docs.google.com/document/d/1n4MJgVk8g254s_X6oOgzC1z44Rc...] * [Your Operator and Disconnected Clusters|https://docs.google.com/document/d/1P4vsuf_yQ8Pl0Fpd1ZQMbHEL2bvt...] > Jenkins Job For Disconnected OCP Configurtation > ----------------------------------------------- > > Key: SWSQE-996 > URL: https://issues.jboss.org/browse/SWSQE-996 > Project: Kiali QE > Issue Type: QE Task > Reporter: Matthew Mahoney > Priority: Critical > Labels: infrastructure > > There is a need to test in Disconnected Configurations. Create Jenkins job to build Disconnected 4.x clusters. > References: > * [Installing Restricted Network Preparations|https://docs.openshift.com/container-platform/4.2/installing...] > * [Disconnected Installation for Operators|https://docs.google.com/document/d/1n4MJgVk8g254s_X6oOgzC1z44Rc...] > * [Your Operator and Disconnected Clusters|https://docs.google.com/document/d/1P4vsuf_yQ8Pl0Fpd1ZQMbHEL2bvt...] -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-996) Jenkins Job For Disconnected OCP Configurtation

by Tiago Moreira Vieira (Jira)

[ https://issues.jboss.org/browse/SWSQE-996?page=com.atlassian.jira.plugin.... ] Tiago Moreira Vieira updated SWSQE-996: --------------------------------------- Description: There is a need to test in Disconnected Configurations. Create Jenkins job to build Disconnected 4.x clusters. References: * [Disconnected Installation for Operators|https://docs.google.com/document/d/1n4MJgVk8g254s_X6oOgzC1z44Rc...] * [Your Operator and Disconnected Clusters|https://docs.google.com/document/d/1P4vsuf_yQ8Pl0Fpd1ZQMbHEL2bvt...] was:There is a need to test in Disconnected Configurations. Create Jenkins job to build Disconnected 4.x clusters. > Jenkins Job For Disconnected OCP Configurtation > ----------------------------------------------- > > Key: SWSQE-996 > URL: https://issues.jboss.org/browse/SWSQE-996 > Project: Kiali QE > Issue Type: QE Task > Reporter: Matthew Mahoney > Priority: Critical > Labels: infrastructure > > There is a need to test in Disconnected Configurations. Create Jenkins job to build Disconnected 4.x clusters. > References: > * [Disconnected Installation for Operators|https://docs.google.com/document/d/1n4MJgVk8g254s_X6oOgzC1z44Rc...] > * [Your Operator and Disconnected Clusters|https://docs.google.com/document/d/1P4vsuf_yQ8Pl0Fpd1ZQMbHEL2bvt...] -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-997) Update OLM Job to Openshift 4.3

by Guilherme Baufaker Rêgo (Jira)

[ https://issues.jboss.org/browse/SWSQE-997?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo updated SWSQE-997: ------------------------------------------ Sprint: Kiali Sprint #30 > Update OLM Job to Openshift 4.3 > -------------------------------- > > Key: SWSQE-997 > URL: https://issues.jboss.org/browse/SWSQE-997 > Project: Kiali QE > Issue Type: QE Task > Reporter: Guilherme Baufaker Rêgo > Priority: Major > > OLM Pipelines will need to adapt for Openshift 4.3 requirements -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-997) Update OLM Job to Openshift 4.3

by Guilherme Baufaker Rêgo (Jira)

Guilherme Baufaker Rêgo created SWSQE-997: --------------------------------------------- Summary: Update OLM Job to Openshift 4.3 Key: SWSQE-997 URL: https://issues.jboss.org/browse/SWSQE-997 Project: Kiali QE Issue Type: QE Task Reporter: Guilherme Baufaker Rêgo OLM Pipelines will need to adapt for Openshift 4.3 requirements -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-996) Jenkins Job For Disconnected OCP Configurtation

by Matthew Mahoney (Jira)

Matthew Mahoney created SWSQE-996: ------------------------------------- Summary: Jenkins Job For Disconnected OCP Configurtation Key: SWSQE-996 URL: https://issues.jboss.org/browse/SWSQE-996 Project: Kiali QE Issue Type: QE Task Reporter: Matthew Mahoney There is a need to test in Disconnected Configurations. Create Jenkins job to build Disconnected 4.x clusters. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-1898) ServiceFactory<Credential> used in API is too strict

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ELY-1898?page=com.atlassian.jira.plugin.s... ] Tristan Tarrant updated ELY-1898: --------------------------------- Priority: Blocker (was: Major) > ServiceFactory<Credential> used in API is too strict > ---------------------------------------------------- > > Key: ELY-1898 > URL: https://issues.jboss.org/browse/ELY-1898 > Project: WildFly Elytron > Issue Type: Bug > Components: API / SPI > Affects Versions: 1.11.0.CR1 > Reporter: Tristan Tarrant > Priority: Blocker > > In several places in the API, `SecurityFactory<Credential>` is used, but its bound is too strict, disallowing passing in specific instances, e.g. `SecurityFactory<GSSKerberosCredential>`. > These should all be replaced with `SecurityFactory<? extends Credential>`. > An example of code that doesn't work: > {code:java} > SecurityFactory<GSSKerberosCredential> ksf = ...; > CredentialSource cs = CredentialSource.fromSecurityFactory(ksf); // Compiler error: required SecurityFactory<Credential> provided SecurityFactory<GSSCredential> > {code} > Similar issue in the following method: > {code:java} > MechanismConfiguration.setServerCredential(SecurityFactory<Credential> credentialFactory) > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-1898) ServiceFactory<Credential> used in API is too strict

by Tristan Tarrant (Jira)

Tristan Tarrant created ELY-1898: ------------------------------------ Summary: ServiceFactory<Credential> used in API is too strict Key: ELY-1898 URL: https://issues.jboss.org/browse/ELY-1898 Project: WildFly Elytron Issue Type: Bug Components: API / SPI Affects Versions: 1.11.0.CR1 Reporter: Tristan Tarrant In several places in the API, `SecurityFactory<Credential>` is used, but its bound is too strict, disallowing passing in specific instances, e.g. `SecurityFactory<GSSKerberosCredential>`. These should all be replaced with `SecurityFactory<? extends Credential>`. An example of code that doesn't work: {code:java} SecurityFactory<GSSKerberosCredential> ksf = ...; CredentialSource cs = CredentialSource.fromSecurityFactory(ksf); // Compiler error: required SecurityFactory<Credential> provided SecurityFactory<GSSCredential> {code} Similar issue in the following method: {code:java} MechanismConfiguration.setServerCredential(SecurityFactory<Credential> credentialFactory) {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2394) Provide an overloaded JmxConfigurator.registerChannel that takes an ObjectName to be used as prefix instead of the domain

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2394?page=com.atlassian.jira.plugin.... ] Bela Ban reopened JGRP-2394: ---------------------------- > Provide an overloaded JmxConfigurator.registerChannel that takes an ObjectName to be used as prefix instead of the domain > ------------------------------------------------------------------------------------------------------------------------- > > Key: JGRP-2394 > URL: https://issues.jboss.org/browse/JGRP-2394 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 4.1.6 > Reporter: Nistor Adrian > Assignee: Bela Ban > Priority: Major > Fix For: 4.1.8 > > > The JmxConfigurator.registerChannel variant that takes a domain is not enough for use cases where multiple apps running in a jvm join the same JGroups cluster and also share the same jmx domain. In this case the channel MBean object names will collide. The de-duplication mechanism using random number suffixes does not provide predictable results. Avoiding jmx domain sharing is also not possible due to the nature of the use case. > So we propose adding someting like this: > JmxConfigurator.registerChannel(JChannel channel, MBeanServer server, ObjectName namePrefix, String cluster_name, boolean register_protocols) > which would allow the application using JGroups to have greater control of the generated object names for channel and protocols. The namePrefix will provide the domain and also a key-value list that will serve as the prefix for all ObjectNames internally generated by JGroups. It will be the caller's task to ensure this leads to generation of unique names. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3580) [DMN Designer] Decision Table: Add support for merged view

by Edson Tirelli (Jira)

[ https://issues.jboss.org/browse/DROOLS-3580?page=com.atlassian.jira.plugi... ] Edson Tirelli commented on DROOLS-3580: --------------------------------------- [~manstis] can I ask you please to clone/link a ticket for this in BAPL for product tracking. Definitively not for 7.6, but we should look into 7.7 timeframe. > [DMN Designer] Decision Table: Add support for merged view > ---------------------------------------------------------- > > Key: DROOLS-3580 > URL: https://issues.jboss.org/browse/DROOLS-3580 > Project: Drools > Issue Type: Enhancement > Components: DMN Editor > Affects Versions: 7.17.0.Final > Reporter: Edson Tirelli > Assignee: Michael Anstis > Priority: Minor > Labels: drools-tools > > Add support for viewing the {{DecisionTableGrid}} in _merged_ mode. > The underlying widget supports merging however I need to check about model synchronisation and where how we'd add a button to toggle merged/unmerged.. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2394) Provide an overloaded JmxConfigurator.registerChannel that takes an ObjectName to be used as prefix instead of the domain

by Nistor Adrian (Jira)

[ https://issues.jboss.org/browse/JGRP-2394?page=com.atlassian.jira.plugin.... ] Nistor Adrian commented on JGRP-2394: ------------------------------------- [~belaban] Unfortunately I realized just now we also need the same treatment for unregistration, so I made a quick PR https://github.com/belaban/JGroups/pull/445 This PR also adds the type=channel/type=protocol ObjectName keys internally so the resulting names will match the previous conventions and do not rely on the user to provide them. > Provide an overloaded JmxConfigurator.registerChannel that takes an ObjectName to be used as prefix instead of the domain > ------------------------------------------------------------------------------------------------------------------------- > > Key: JGRP-2394 > URL: https://issues.jboss.org/browse/JGRP-2394 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 4.1.6 > Reporter: Nistor Adrian > Assignee: Bela Ban > Priority: Major > Fix For: 4.1.8 > > > The JmxConfigurator.registerChannel variant that takes a domain is not enough for use cases where multiple apps running in a jvm join the same JGroups cluster and also share the same jmx domain. In this case the channel MBean object names will collide. The de-duplication mechanism using random number suffixes does not provide predictable results. Avoiding jmx domain sharing is also not possible due to the nature of the use case. > So we propose adding someting like this: > JmxConfigurator.registerChannel(JChannel channel, MBeanServer server, ObjectName namePrefix, String cluster_name, boolean register_protocols) > which would allow the application using JGroups to have greater control of the generated object names for channel and protocols. The namePrefix will provide the domain and also a key-value list that will serve as the prefix for all ObjectNames internally generated by JGroups. It will be the caller's task to ensure this leads to generation of unique names. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2019