[JBoss JIRA] (WFLY-4321) restart of http connector without restarting whole web container
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4321?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-4321:
--------------------------------------
You need to add the allow-resource-service-restart=true header to the remove op:
/subsystem=undertow/server=default-server/https-listener=https:remove(){allow-resource-service-restart=true}
> restart of http connector without restarting whole web container
> ----------------------------------------------------------------
>
> Key: WFLY-4321
> URL: https://issues.jboss.org/browse/WFLY-4321
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Affects Versions: 8.2.0.Final
> Reporter: Davide Gesino
> Assignee: Stuart Douglas
> Priority: Minor
> Labels: connector,, mbeans, ssl,
> Fix For: Awaiting Volunteers
>
>
> It would be great if Undertow provided a feature Tomcat has, namely the possibility to stop the http connector without restarting the whole container.
> It's useful for example in case when certificates for SSL communication change while the container is up and running.
> Tomcat has this feature setting the property "org.apache.tomcat.util.ENABLE_MODELER" to true: this turn on the MBeans management for Tomcat.
> Through these beans it's possible to start and stop the connectors.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-4321) restart of http connector without restarting whole web container
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4321?page=com.atlassian.jira.plugin.... ]
Stuart Douglas closed WFLY-4321.
--------------------------------
Resolution: Rejected
> restart of http connector without restarting whole web container
> ----------------------------------------------------------------
>
> Key: WFLY-4321
> URL: https://issues.jboss.org/browse/WFLY-4321
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Affects Versions: 8.2.0.Final
> Reporter: Davide Gesino
> Assignee: Stuart Douglas
> Priority: Minor
> Labels: connector,, mbeans, ssl,
> Fix For: Awaiting Volunteers
>
>
> It would be great if Undertow provided a feature Tomcat has, namely the possibility to stop the http connector without restarting the whole container.
> It's useful for example in case when certificates for SSL communication change while the container is up and running.
> Tomcat has this feature setting the property "org.apache.tomcat.util.ENABLE_MODELER" to true: this turn on the MBeans management for Tomcat.
> Through these beans it's possible to start and stop the connectors.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-4321) restart of http connector without restarting whole web container
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4321?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFLY-4321:
------------------------------------
Assignee: Stuart Douglas
> restart of http connector without restarting whole web container
> ----------------------------------------------------------------
>
> Key: WFLY-4321
> URL: https://issues.jboss.org/browse/WFLY-4321
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Affects Versions: 8.2.0.Final
> Reporter: Davide Gesino
> Assignee: Stuart Douglas
> Priority: Minor
> Labels: connector,, mbeans, ssl,
> Fix For: Awaiting Volunteers
>
>
> It would be great if Undertow provided a feature Tomcat has, namely the possibility to stop the http connector without restarting the whole container.
> It's useful for example in case when certificates for SSL communication change while the container is up and running.
> Tomcat has this feature setting the property "org.apache.tomcat.util.ENABLE_MODELER" to true: this turn on the MBeans management for Tomcat.
> Through these beans it's possible to start and stop the connectors.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (DROOLS-1355) a black box Approval appliance thats super easy to integrate into Jenkins Pipeline or Kubernetes
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1355?page=com.atlassian.jira.plugi... ]
Edson Tirelli commented on DROOLS-1355:
---------------------------------------
[~porcelli] can you please take a look at this and check how that relates to the work you are doing?
> a black box Approval appliance thats super easy to integrate into Jenkins Pipeline or Kubernetes
> ------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1355
> URL: https://issues.jboss.org/browse/DROOLS-1355
> Project: Drools
> Issue Type: Feature Request
> Components: integration
> Affects Versions: 7.0.0.Beta2
> Reporter: James Strachan
> Assignee: Alexandre Porcelli
>
> [Jenkins Pipelines|https://jenkins.io/doc/book/pipeline/] are the hot way to do Continuous Delivery. Its very common to need human approval before, say, releasing to production.
> Right now the Jenkinsfile can do all the various build, test, deploy steps really well. However the approval is kinda sucky - its a single button on the console right now :)
> https://jenkins.io/doc/pipeline/steps/pipeline-input-step/#input-wait-for...
> What would be awesome is if we could package up drools+jBPM as a black box "approval appliance". Then we could create a little Jenkinsfile step like this:
> {code}
> // lets wait for approval or timeout/fail if not
> droolsApprove(namespace = "cheese", project = "beer", environment = "production", action = "promote")
> // now promote to production
> ...
> }
> {code}
> then we totally decouple from the Jenkins Pipeline how approvals work, which people/roles/teams do it, what the escalation policy is, how many folks need to approve and so forth.
> The various key/value pairs can then be used to associate promoting a project of a certain name in a namespace to a specific environment with different workflow policies. e.g. no approval at all may be required for testing. But for production, most apps may want 1 approver but some may need 2.
> Then how we map the approval policies & workflows to teams, apps & environments can be left to drools/jbpm to figure out.
> I'm hoping 90% of all use cases can be catered for with a couple of simple optional BPM flows really - then a simple mapping of key/value pairs to the flow to use (if any) so that users typically don't need to do much in the way of BPM editing or anything to use the Approval engine - it just works OOTB with maybe a simple config file to define the mappings or something. Just then folks get started right away super easily.
> We can then, for example, package it all up as an appliance and ship it OOTB with fabric8 :)
> We're more than happy to help on the packaging/kubernetes side and the Jenkins side - we could just do with a really simple packaged "approval engine" with a really simple REST API to create new approvals and then have a way to watch/poll when it completes/fails/times out.
> e.g. POST to an approval endpoint the key/value strings to create an approval; you get back a URL to poll for when the approval has completed or if it fails/time out or is rejected. Then some little blob of YAML/JSON gives reasons the OK or the reasons for the fail.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (DROOLS-1355) a black box Approval appliance thats super easy to integrate into Jenkins Pipeline or Kubernetes
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1355?page=com.atlassian.jira.plugi... ]
Edson Tirelli updated DROOLS-1355:
----------------------------------
Component/s: integration
> a black box Approval appliance thats super easy to integrate into Jenkins Pipeline or Kubernetes
> ------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1355
> URL: https://issues.jboss.org/browse/DROOLS-1355
> Project: Drools
> Issue Type: Feature Request
> Components: integration
> Affects Versions: 7.0.0.Beta2
> Reporter: James Strachan
> Assignee: Alexandre Porcelli
>
> [Jenkins Pipelines|https://jenkins.io/doc/book/pipeline/] are the hot way to do Continuous Delivery. Its very common to need human approval before, say, releasing to production.
> Right now the Jenkinsfile can do all the various build, test, deploy steps really well. However the approval is kinda sucky - its a single button on the console right now :)
> https://jenkins.io/doc/pipeline/steps/pipeline-input-step/#input-wait-for...
> What would be awesome is if we could package up drools+jBPM as a black box "approval appliance". Then we could create a little Jenkinsfile step like this:
> {code}
> // lets wait for approval or timeout/fail if not
> droolsApprove(namespace = "cheese", project = "beer", environment = "production", action = "promote")
> // now promote to production
> ...
> }
> {code}
> then we totally decouple from the Jenkins Pipeline how approvals work, which people/roles/teams do it, what the escalation policy is, how many folks need to approve and so forth.
> The various key/value pairs can then be used to associate promoting a project of a certain name in a namespace to a specific environment with different workflow policies. e.g. no approval at all may be required for testing. But for production, most apps may want 1 approver but some may need 2.
> Then how we map the approval policies & workflows to teams, apps & environments can be left to drools/jbpm to figure out.
> I'm hoping 90% of all use cases can be catered for with a couple of simple optional BPM flows really - then a simple mapping of key/value pairs to the flow to use (if any) so that users typically don't need to do much in the way of BPM editing or anything to use the Approval engine - it just works OOTB with maybe a simple config file to define the mappings or something. Just then folks get started right away super easily.
> We can then, for example, package it all up as an appliance and ship it OOTB with fabric8 :)
> We're more than happy to help on the packaging/kubernetes side and the Jenkins side - we could just do with a really simple packaged "approval engine" with a really simple REST API to create new approvals and then have a way to watch/poll when it completes/fails/times out.
> e.g. POST to an approval endpoint the key/value strings to create an approval; you get back a URL to poll for when the approval has completed or if it fails/time out or is rejected. Then some little blob of YAML/JSON gives reasons the OK or the reasons for the fail.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (DROOLS-1355) a black box Approval appliance thats super easy to integrate into Jenkins Pipeline or Kubernetes
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1355?page=com.atlassian.jira.plugi... ]
Edson Tirelli updated DROOLS-1355:
----------------------------------
Affects Version/s: 7.0.0.Beta2
> a black box Approval appliance thats super easy to integrate into Jenkins Pipeline or Kubernetes
> ------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1355
> URL: https://issues.jboss.org/browse/DROOLS-1355
> Project: Drools
> Issue Type: Feature Request
> Components: integration
> Affects Versions: 7.0.0.Beta2
> Reporter: James Strachan
> Assignee: Alexandre Porcelli
>
> [Jenkins Pipelines|https://jenkins.io/doc/book/pipeline/] are the hot way to do Continuous Delivery. Its very common to need human approval before, say, releasing to production.
> Right now the Jenkinsfile can do all the various build, test, deploy steps really well. However the approval is kinda sucky - its a single button on the console right now :)
> https://jenkins.io/doc/pipeline/steps/pipeline-input-step/#input-wait-for...
> What would be awesome is if we could package up drools+jBPM as a black box "approval appliance". Then we could create a little Jenkinsfile step like this:
> {code}
> // lets wait for approval or timeout/fail if not
> droolsApprove(namespace = "cheese", project = "beer", environment = "production", action = "promote")
> // now promote to production
> ...
> }
> {code}
> then we totally decouple from the Jenkins Pipeline how approvals work, which people/roles/teams do it, what the escalation policy is, how many folks need to approve and so forth.
> The various key/value pairs can then be used to associate promoting a project of a certain name in a namespace to a specific environment with different workflow policies. e.g. no approval at all may be required for testing. But for production, most apps may want 1 approver but some may need 2.
> Then how we map the approval policies & workflows to teams, apps & environments can be left to drools/jbpm to figure out.
> I'm hoping 90% of all use cases can be catered for with a couple of simple optional BPM flows really - then a simple mapping of key/value pairs to the flow to use (if any) so that users typically don't need to do much in the way of BPM editing or anything to use the Approval engine - it just works OOTB with maybe a simple config file to define the mappings or something. Just then folks get started right away super easily.
> We can then, for example, package it all up as an appliance and ship it OOTB with fabric8 :)
> We're more than happy to help on the packaging/kubernetes side and the Jenkins side - we could just do with a really simple packaged "approval engine" with a really simple REST API to create new approvals and then have a way to watch/poll when it completes/fails/times out.
> e.g. POST to an approval endpoint the key/value strings to create an approval; you get back a URL to poll for when the approval has completed or if it fails/time out or is rejected. Then some little blob of YAML/JSON gives reasons the OK or the reasons for the fail.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (DROOLS-1355) a black box Approval appliance thats super easy to integrate into Jenkins Pipeline or Kubernetes
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1355?page=com.atlassian.jira.plugi... ]
Edson Tirelli reassigned DROOLS-1355:
-------------------------------------
Assignee: Alexandre Porcelli (was: Edson Tirelli)
> a black box Approval appliance thats super easy to integrate into Jenkins Pipeline or Kubernetes
> ------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1355
> URL: https://issues.jboss.org/browse/DROOLS-1355
> Project: Drools
> Issue Type: Feature Request
> Affects Versions: 7.0.0.Beta2
> Reporter: James Strachan
> Assignee: Alexandre Porcelli
>
> [Jenkins Pipelines|https://jenkins.io/doc/book/pipeline/] are the hot way to do Continuous Delivery. Its very common to need human approval before, say, releasing to production.
> Right now the Jenkinsfile can do all the various build, test, deploy steps really well. However the approval is kinda sucky - its a single button on the console right now :)
> https://jenkins.io/doc/pipeline/steps/pipeline-input-step/#input-wait-for...
> What would be awesome is if we could package up drools+jBPM as a black box "approval appliance". Then we could create a little Jenkinsfile step like this:
> {code}
> // lets wait for approval or timeout/fail if not
> droolsApprove(namespace = "cheese", project = "beer", environment = "production", action = "promote")
> // now promote to production
> ...
> }
> {code}
> then we totally decouple from the Jenkins Pipeline how approvals work, which people/roles/teams do it, what the escalation policy is, how many folks need to approve and so forth.
> The various key/value pairs can then be used to associate promoting a project of a certain name in a namespace to a specific environment with different workflow policies. e.g. no approval at all may be required for testing. But for production, most apps may want 1 approver but some may need 2.
> Then how we map the approval policies & workflows to teams, apps & environments can be left to drools/jbpm to figure out.
> I'm hoping 90% of all use cases can be catered for with a couple of simple optional BPM flows really - then a simple mapping of key/value pairs to the flow to use (if any) so that users typically don't need to do much in the way of BPM editing or anything to use the Approval engine - it just works OOTB with maybe a simple config file to define the mappings or something. Just then folks get started right away super easily.
> We can then, for example, package it all up as an appliance and ship it OOTB with fabric8 :)
> We're more than happy to help on the packaging/kubernetes side and the Jenkins side - we could just do with a really simple packaged "approval engine" with a really simple REST API to create new approvals and then have a way to watch/poll when it completes/fails/times out.
> e.g. POST to an approval endpoint the key/value strings to create an approval; you get back a URL to poll for when the approval has completed or if it fails/time out or is rejected. Then some little blob of YAML/JSON gives reasons the OK or the reasons for the fail.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (ELY-725) Add support for matching by purpose
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-725?page=com.atlassian.jira.plugin.sy... ]
David Lloyd resolved ELY-725.
-----------------------------
Fix Version/s: 1.1.0.Beta13
(was: 1.1.0.Beta14)
Resolution: Done
> Add support for matching by purpose
> -----------------------------------
>
> Key: ELY-725
> URL: https://issues.jboss.org/browse/ELY-725
> Project: WildFly Elytron
> Issue Type: Task
> Components: Authentication Client
> Reporter: David Lloyd
> Assignee: David Lloyd
> Fix For: 1.1.0.Beta13
>
>
> Support matching by purpose. Some purposes could include:
> * "connect" - the configuration is used to establish an outbound network connection
> * "operate" - the configuration is used to process an invocation/operation/request
> * "maintain" - the configuration is used to perform a maintenance operation
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months