[JBoss JIRA] (WFCORE-1402) Add support for metaspacesize to jvm options and remove permgen
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1402?page=com.atlassian.jira.plugi... ]
Ken Wills commented on WFCORE-1402:
-----------------------------------
I'd experimented with this briefly, leaving permgen in all of the schemas and added metaspace only to 4.0.1. It appears to work OK, though I'd have to double check the merging you mention as I had only checked /host=/jvm values were as configured. It did look like some issues with the testsuite dropping the <metaspace> element in some transformer tests (I think the ones where it used the KernelService.build() test setup).
For display, I was assuming it would be in /host/jvm=* and /host=/server-config=/jvm
> Add support for metaspacesize to jvm options and remove permgen
> ---------------------------------------------------------------
>
> Key: WFCORE-1402
> URL: https://issues.jboss.org/browse/WFCORE-1402
> Project: WildFly Core
> Issue Type: Enhancement
> Reporter: Ken Wills
> Assignee: Ken Wills
> Fix For: 3.0.0.Alpha1
>
>
> We could display the configured Metaspace values, and we should remove the now deprecated permgen values.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFCORE-433) git backend for loading/storing the configuration XML for wildfly
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-433?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFCORE-433:
-----------------------------------------
As part of the application of the update to the Domain Controller, it rolls it out to all registered hosts/servers in the domain, rolling the update back if there are failures. The update request can include headers that let the user somewhat control the rollout, both in regards to concurrency of updating servers and in regards to tolerance of failures on individual servers (i.e. not rolling back.)
> git backend for loading/storing the configuration XML for wildfly
> -----------------------------------------------------------------
>
> Key: WFCORE-433
> URL: https://issues.jboss.org/browse/WFCORE-433
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: James Strachan
> Assignee: Jason Greene
>
> when working with wildfly in a cloud/paas environment (like openshift, fabric8, docker, heroku et al) it'd be great to have a git repository for the configuration folder so that writes work something like:
> * git pull
> * write the, say, standalone.xml file
> * git commit -a -m "some comment"
> * git push
> (with a handler to deal with conflicts; such as last write wins).
> Then an optional periodic 'git pull' and reload configuration if there is a change.
> This would then mean that folks could use a number of wildfly containers using docker / openshift / fabric8 and then have a shared git repository (e.g. the git repo in openshift or fabric8) to configure a group of wildfly containers. Folks could then reuse the wildfly management console within cloud environments (as the management console would, under the covers, be loading/saving from/to git)
> Folks could then benefit from git tooling when dealing with versioning and audit logs of changes to the XML; along with getting the benefit of branching, tagging.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFCORE-433) git backend for loading/storing the configuration XML for wildfly
by James Strachan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-433?page=com.atlassian.jira.plugin... ]
James Strachan commented on WFCORE-433:
---------------------------------------
[~ehugonnet] thanks! So the change is made to the containers as soon as the Save is done in the WildFly Admin Console right? If so we should trigger a 'pod refresh' on a git commit / Config Map update
> git backend for loading/storing the configuration XML for wildfly
> -----------------------------------------------------------------
>
> Key: WFCORE-433
> URL: https://issues.jboss.org/browse/WFCORE-433
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: James Strachan
> Assignee: Jason Greene
>
> when working with wildfly in a cloud/paas environment (like openshift, fabric8, docker, heroku et al) it'd be great to have a git repository for the configuration folder so that writes work something like:
> * git pull
> * write the, say, standalone.xml file
> * git commit -a -m "some comment"
> * git push
> (with a handler to deal with conflicts; such as last write wins).
> Then an optional periodic 'git pull' and reload configuration if there is a change.
> This would then mean that folks could use a number of wildfly containers using docker / openshift / fabric8 and then have a shared git repository (e.g. the git repo in openshift or fabric8) to configure a group of wildfly containers. Folks could then reuse the wildfly management console within cloud environments (as the management console would, under the covers, be loading/saving from/to git)
> Folks could then benefit from git tooling when dealing with versioning and audit logs of changes to the XML; along with getting the benefit of branching, tagging.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFCORE-433) git backend for loading/storing the configuration XML for wildfly
by James Strachan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-433?page=com.atlassian.jira.plugin... ]
James Strachan edited comment on WFCORE-433 at 2/23/16 12:29 PM:
-----------------------------------------------------------------
Incidentally using DomainController right now, if you added, say, a JDBC connection to the configuration via the WildFly Admin Console when you've a cluster of 3 wildfly containers - when do the containers update to get the new configuration? Is it a kinda manual step to roll the 3 containers forward to the new configuration?
When using git repo or ConfigMap with Kubernetes, if things don't automate immediately on the save the we probably need to have a similar trigger point when the user wants to use a specific new configuration (a new git commit or the newly updated ConfigMap value).
Typically that just means bouncing the pods in kubernetes. One exception could be in git repos;
http://kubernetes.io/v1.1/docs/user-guide/volumes.html#gitrepo
you can use a gitRepo volume in Kubernetes which you could fix at a specific revision; you could then use a Kubernetes Rolling Update to change the RC configuration to refer to the new git commit to make changes:
http://kubernetes.io/v1.1/docs/user-guide/update-demo/README.html
that gives you full control then of when you move forward to a new configuration change; or backwards again.
was (Author: jastrachan):
Incidentally using DomainController right now, if you added, say, a JDBC connection to the configuration via the WildFly Admin Console when you've a cluster of 3 wildfly containers - when do the containers update to get the new configuration? Is it a kinda manual step to roll the 3 containers forward to the new configuration?
When using git repo or ConfigMap with Kubernetes, if things don't automate immediately on the save the we probably need to have a similar trigger point when the user wants to use a specific new configuration (a new git commit or the newly updated ConfigMap value).
> git backend for loading/storing the configuration XML for wildfly
> -----------------------------------------------------------------
>
> Key: WFCORE-433
> URL: https://issues.jboss.org/browse/WFCORE-433
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: James Strachan
> Assignee: Jason Greene
>
> when working with wildfly in a cloud/paas environment (like openshift, fabric8, docker, heroku et al) it'd be great to have a git repository for the configuration folder so that writes work something like:
> * git pull
> * write the, say, standalone.xml file
> * git commit -a -m "some comment"
> * git push
> (with a handler to deal with conflicts; such as last write wins).
> Then an optional periodic 'git pull' and reload configuration if there is a change.
> This would then mean that folks could use a number of wildfly containers using docker / openshift / fabric8 and then have a shared git repository (e.g. the git repo in openshift or fabric8) to configure a group of wildfly containers. Folks could then reuse the wildfly management console within cloud environments (as the management console would, under the covers, be loading/saving from/to git)
> Folks could then benefit from git tooling when dealing with versioning and audit logs of changes to the XML; along with getting the benefit of branching, tagging.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFCORE-433) git backend for loading/storing the configuration XML for wildfly
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-433?page=com.atlassian.jira.plugin... ]
ehsavoie Hugonnet commented on WFCORE-433:
------------------------------------------
The update takes part in all the impacted containers. There is a global configuration model that gets translated and applied for each container.
> git backend for loading/storing the configuration XML for wildfly
> -----------------------------------------------------------------
>
> Key: WFCORE-433
> URL: https://issues.jboss.org/browse/WFCORE-433
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: James Strachan
> Assignee: Jason Greene
>
> when working with wildfly in a cloud/paas environment (like openshift, fabric8, docker, heroku et al) it'd be great to have a git repository for the configuration folder so that writes work something like:
> * git pull
> * write the, say, standalone.xml file
> * git commit -a -m "some comment"
> * git push
> (with a handler to deal with conflicts; such as last write wins).
> Then an optional periodic 'git pull' and reload configuration if there is a change.
> This would then mean that folks could use a number of wildfly containers using docker / openshift / fabric8 and then have a shared git repository (e.g. the git repo in openshift or fabric8) to configure a group of wildfly containers. Folks could then reuse the wildfly management console within cloud environments (as the management console would, under the covers, be loading/saving from/to git)
> Folks could then benefit from git tooling when dealing with versioning and audit logs of changes to the XML; along with getting the benefit of branching, tagging.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFCORE-433) git backend for loading/storing the configuration XML for wildfly
by James Strachan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-433?page=com.atlassian.jira.plugin... ]
James Strachan edited comment on WFCORE-433 at 2/23/16 12:26 PM:
-----------------------------------------------------------------
Incidentally using DomainController right now, if you added, say, a JDBC connection to the configuration via the WildFly Admin Console when you've a cluster of 3 wildfly containers - when do the containers update to get the new configuration? Is it a kinda manual step to roll the 3 containers forward to the new configuration?
When using git repo or ConfigMap with Kubernetes, if things don't automate immediately on the save the we probably need to have a similar trigger point when the user wants to use a specific new configuration (a new git commit or the newly updated ConfigMap value).
was (Author: jastrachan):
Incidentally using DomainController right now, if you added, say, a JDBC connection to the configuration via the WildFly Admin Console when you've a cluster of 3 wildfly containers - when do the containers update to get the new configuration? Is it a kinda manual update to roll forward to the new configuration?
When using git repo or ConfigMap with Kubernetes, if things don't automate immediately on the save the we probably need to have a similar trigger point when the user wants to use a specific new configuration (a new git commit or the newly updated ConfigMap value).
> git backend for loading/storing the configuration XML for wildfly
> -----------------------------------------------------------------
>
> Key: WFCORE-433
> URL: https://issues.jboss.org/browse/WFCORE-433
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: James Strachan
> Assignee: Jason Greene
>
> when working with wildfly in a cloud/paas environment (like openshift, fabric8, docker, heroku et al) it'd be great to have a git repository for the configuration folder so that writes work something like:
> * git pull
> * write the, say, standalone.xml file
> * git commit -a -m "some comment"
> * git push
> (with a handler to deal with conflicts; such as last write wins).
> Then an optional periodic 'git pull' and reload configuration if there is a change.
> This would then mean that folks could use a number of wildfly containers using docker / openshift / fabric8 and then have a shared git repository (e.g. the git repo in openshift or fabric8) to configure a group of wildfly containers. Folks could then reuse the wildfly management console within cloud environments (as the management console would, under the covers, be loading/saving from/to git)
> Folks could then benefit from git tooling when dealing with versioning and audit logs of changes to the XML; along with getting the benefit of branching, tagging.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFCORE-433) git backend for loading/storing the configuration XML for wildfly
by James Strachan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-433?page=com.atlassian.jira.plugin... ]
James Strachan edited comment on WFCORE-433 at 2/23/16 12:26 PM:
-----------------------------------------------------------------
Incidentally using DomainController right now, if you added, say, a JDBC connection to the configuration via the WildFly Admin Console when you've a cluster of 3 wildfly containers - when do the containers update to get the new configuration? Is it a kinda manual update to roll forward to the new configuration?
When using git repo or ConfigMap with Kubernetes, if things don't automate immediately on the save the we probably need to have a similar trigger point when the user wants to use a specific new configuration (a new git commit or the newly updated ConfigMap value).
was (Author: jastrachan):
Incidentally using DomainController right now, if you added, say, a JDBC connection to the configuration when you've a cluster of 3 wildfly containers - when do the containers update to get the new configuration? Is it a kinda manual update to roll forward to the new configuration?
When using git repo or ConfigMap with Kubernetes, if things don't automate immediately on the save the we probably need to have a similar trigger point when the user wants to use a specific new configuration (a new git commit or the newly updated ConfigMap value).
> git backend for loading/storing the configuration XML for wildfly
> -----------------------------------------------------------------
>
> Key: WFCORE-433
> URL: https://issues.jboss.org/browse/WFCORE-433
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: James Strachan
> Assignee: Jason Greene
>
> when working with wildfly in a cloud/paas environment (like openshift, fabric8, docker, heroku et al) it'd be great to have a git repository for the configuration folder so that writes work something like:
> * git pull
> * write the, say, standalone.xml file
> * git commit -a -m "some comment"
> * git push
> (with a handler to deal with conflicts; such as last write wins).
> Then an optional periodic 'git pull' and reload configuration if there is a change.
> This would then mean that folks could use a number of wildfly containers using docker / openshift / fabric8 and then have a shared git repository (e.g. the git repo in openshift or fabric8) to configure a group of wildfly containers. Folks could then reuse the wildfly management console within cloud environments (as the management console would, under the covers, be loading/saving from/to git)
> Folks could then benefit from git tooling when dealing with versioning and audit logs of changes to the XML; along with getting the benefit of branching, tagging.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFCORE-433) git backend for loading/storing the configuration XML for wildfly
by James Strachan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-433?page=com.atlassian.jira.plugin... ]
James Strachan commented on WFCORE-433:
---------------------------------------
Incidentally using DomainController right now, if you added, say, a JDBC connection to the configuration when you've a cluster of 3 wildfly containers - when do the containers update to get the new configuration? Is it a kinda manual update to roll forward to the new configuration?
When using git repo or ConfigMap with Kubernetes, if things don't automate immediately on the save the we probably need to have a similar trigger point when the user wants to use a specific new configuration (a new git commit or the newly updated ConfigMap value).
> git backend for loading/storing the configuration XML for wildfly
> -----------------------------------------------------------------
>
> Key: WFCORE-433
> URL: https://issues.jboss.org/browse/WFCORE-433
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: James Strachan
> Assignee: Jason Greene
>
> when working with wildfly in a cloud/paas environment (like openshift, fabric8, docker, heroku et al) it'd be great to have a git repository for the configuration folder so that writes work something like:
> * git pull
> * write the, say, standalone.xml file
> * git commit -a -m "some comment"
> * git push
> (with a handler to deal with conflicts; such as last write wins).
> Then an optional periodic 'git pull' and reload configuration if there is a change.
> This would then mean that folks could use a number of wildfly containers using docker / openshift / fabric8 and then have a shared git repository (e.g. the git repo in openshift or fabric8) to configure a group of wildfly containers. Folks could then reuse the wildfly management console within cloud environments (as the management console would, under the covers, be loading/saving from/to git)
> Folks could then benefit from git tooling when dealing with versioning and audit logs of changes to the XML; along with getting the benefit of branching, tagging.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (DROOLS-709) fuse-bxms-integ list of build/release issues
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-709?page=com.atlassian.jira.plugin... ]
Edson Tirelli closed DROOLS-709.
--------------------------------
Resolution: Out of Date
Closing this ticket as it is out-of-date now.
> fuse-bxms-integ list of build/release issues
> --------------------------------------------
>
> Key: DROOLS-709
> URL: https://issues.jboss.org/browse/DROOLS-709
> Project: Drools
> Issue Type: Bug
> Reporter: Geoffrey De Smet
> Assignee: Edson Tirelli
> Priority: Blocker
> Fix For: 6.4.0.Beta2
>
>
> Here's a summary of the issues discussed in e-mail so we can track them.
> 1) fuse-bxms-integ violates Red Hat naming:
> We can't use a product name ("Fuse", "bxms") for community code.
> The repository contains community glue code between camel and kie,
> so for example "camel-kie-integ" would be better.
> Is drools-camel open source?
> If yes, then we want the community to be able to use it and report issues before we release the product version.
> 2) The artifacts of fuse-bxms-integ all still use the groupId "org.kie",
> but supposedly have their a different version numbering than org.kie's artifacts.
> 2 artifacts in the same groupId must use the exact same version numbering and release lifecycle!
> So the groupId must be changed before its released.
> 3) fuse-bxms-integ will use it's own version numbering, so it should not use kie's "6.2.0.Final"
> Either it uses a neutral number, such as "1.0.0.Final"
> or it defines a pattern based on it's kie and it's camel dependency. For example "6.2.0.Final-2.14.1.Final" (bad example, violates OSGi guidelines).
> Calling it "6.2.0.Final" is just asking for confusion and trouble,
> because productization scripts will presume it's 100% equal to the kie version.
> 4) Now one seems to have the faintest idea how we'll handle branching: think camel 2.14.x, camel 2.13.x, kie 6.2.x, camel 2.12.x, kie 6.1.x, ...
> 5) // Not valid
> 6) Renaming the java packages according to the new groupId/artifactId we will choose (as we did in the past with all other projects) and also fix the OSGi manifest and features.xml files accordingly.
> 7) migrating the optaplanner-camel module in the new integration project.
> Note: ge0ffrey will migrate optaplanner-camel after the other issues in this list are solved to avoid breaking users now.
> 8) It's artifacts are currently:
> - no longer extending droolsjbpm-parent(-with-dependencies)
> - no longer in the kie-bom
> and that the repo is no longer in our github organization or git-clone-others script, but it is part of our release.
> So it's already quite different than in 6.1.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months