[JBoss JIRA] (JBIDE-22515) Deploying/Pushing an updated docker image causes an error because of conflicting resources
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22515?page=com.atlassian.jira.plugi... ]
Fred Bricon reassigned JBIDE-22515:
-----------------------------------
Assignee: Jeff Cantrill
> Deploying/Pushing an updated docker image causes an error because of conflicting resources
> ------------------------------------------------------------------------------------------
>
> Key: JBIDE-22515
> URL: https://issues.jboss.org/browse/JBIDE-22515
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Reporter: Fred Bricon
> Assignee: Jeff Cantrill
>
> After a docker image has been successfully deployed to OpenShift, if the image has been updated to a new version in the daemon, performing a second Deploy to OpenShift command will effectively update the image but an error will popup about resources already existing.
> I believe that, when we're about to create the openshift resources, we should
> - detect if there's already a matching deployment config for the same project/resource name)
> - if the deployment config links to an imagestream matching the docker image being deployed, then it's an update, then bail without creating any resources, else resource conflict checks should happen.
> Ideally, this should probably happen at the wizard level, so we don't need to show the resource pages and go straight to finish, but that can be implemented later
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (JBIDE-22515) Deploying/Pushing an updated docker image causes an error because of conflicting resources
by Fred Bricon (JIRA)
Fred Bricon created JBIDE-22515:
-----------------------------------
Summary: Deploying/Pushing an updated docker image causes an error because of conflicting resources
Key: JBIDE-22515
URL: https://issues.jboss.org/browse/JBIDE-22515
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: openshift
Reporter: Fred Bricon
After a docker image has been successfully deployed to OpenShift, if the image has been updated to a new version in the daemon, performing a second Deploy to OpenShift command will effectively update the image but an error will popup about resources already existing.
I believe that, when we're about to create the openshift resources, we should
- detect if there's already a matching deployment config for the same project/resource name)
- if the deployment config links to an imagestream matching the docker image being deployed, then it's an update, then bail without creating any resources, else resource conflict checks should happen.
Ideally, this should probably happen at the wizard level, so we don't need to show the resource pages and go straight to finish, but that can be implemented later
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (JBIDE-22515) Deploying/Pushing an updated docker image causes an error because of conflicting resources
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22515?page=com.atlassian.jira.plugi... ]
Fred Bricon updated JBIDE-22515:
--------------------------------
Sprint: devex #115 May 2016
> Deploying/Pushing an updated docker image causes an error because of conflicting resources
> ------------------------------------------------------------------------------------------
>
> Key: JBIDE-22515
> URL: https://issues.jboss.org/browse/JBIDE-22515
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Reporter: Fred Bricon
>
> After a docker image has been successfully deployed to OpenShift, if the image has been updated to a new version in the daemon, performing a second Deploy to OpenShift command will effectively update the image but an error will popup about resources already existing.
> I believe that, when we're about to create the openshift resources, we should
> - detect if there's already a matching deployment config for the same project/resource name)
> - if the deployment config links to an imagestream matching the docker image being deployed, then it's an update, then bail without creating any resources, else resource conflict checks should happen.
> Ideally, this should probably happen at the wizard level, so we don't need to show the resource pages and go straight to finish, but that can be implemented later
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (JBTIS-729) Teiid Designer depends on bundle in JBT/devstudio TP which no longer exists
by Nick Boldt (JIRA)
Nick Boldt created JBTIS-729:
--------------------------------
Summary: Teiid Designer depends on bundle in JBT/devstudio TP which no longer exists
Key: JBTIS-729
URL: https://issues.jboss.org/browse/JBTIS-729
Project: JBoss Tools Integration Stack
Issue Type: Bug
Components: target-platform, teiid
Affects Versions: 4.4.0.Alpha1-TP, 4.4.0.Alpha1
Reporter: Nick Boldt
org.eclipse.core.runtime.compatibility was removed from the JBT and devstudio target platforms because nothing in JBT/devstudio requires it any more.
As a result, when you try to install Teiid Designer into the staged JBT 4.4.0.Final or devstudio 10.0.0.GA via Central, you get this error:
{code}
!MESSAGE Missing requirement: Teiid DataTools Connectivity 10.0.0.Beta3-v20160218-1807-B4076 (org.teiid.datatools.connectivity.feature.feature.group 10.0.0.Beta3-v20160218-1807-B4076) requires 'org.eclipse.core.runtime.compatibility [3.2.200,4.0.0)' but it could not be found
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (JBDS-3739) Docker connection does not work after cdk restart
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBDS-3739?page=com.atlassian.jira.plugin.... ]
Fred Bricon commented on JBDS-3739:
-----------------------------------
[~rgrunber] the BZ you mentioned is about an IIOBE caused by empty tags. The NPE is a side effect. It's unclear whether [~mlabuda] hit that NPE caused by a similar IIOBE. Anyway, I think the DockerConnection.listImages implementation still leaves some way to end up with null value. It should prolly be fixed by initializing the images variable to an empty list, to ensure it's never ever null.
> Docker connection does not work after cdk restart
> -------------------------------------------------
>
> Key: JBDS-3739
> URL: https://issues.jboss.org/browse/JBDS-3739
> Project: Red Hat Developer Studio (DevStudio)
> Issue Type: Bug
> Components: cdk, upstream
> Affects Versions: 9.1.0.CR1
> Reporter: Martin Malina
> Assignee: Xavier Coulon
> Priority: Blocker
> Labels: havoc
> Attachments: docker-frozen.txt
>
>
> When you set up cdk and start it for the first time, docker connection is properly set up and functioning. But when you restart cdk in the servers view, docker connection will no longer work.
> This is caused by a bug in vagrant-service-manager 0.0.4:
> https://github.com/projectatomic/vagrant-service-manager/issues/80
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (JBIDE-22514) Unable to build the workspace
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22514?page=com.atlassian.jira.plugi... ]
James Perkins commented on JBIDE-22514:
---------------------------------------
I can't seem to unassign myself here, but this looks like a JBoss Tools issue and was filed under the Maven plugin JIRA.
> Unable to build the workspace
> -----------------------------
>
> Key: JBIDE-22514
> URL: https://issues.jboss.org/browse/JBIDE-22514
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Environment: Eclipse
> Reporter: Megha Kesharwani
> Assignee: James Perkins
> Priority: Trivial
> Attachments: .log
>
>
> I am using eclipse Kepler with plugins JBOSS(wildfly-8.2.0.Final) and ClearCase, while building the workspace i am getting the following error "ENTRY org.eclipse.core.jobs 4 2 2016-06-02 11:07:19.724
> !MESSAGE An internal error occurred during: "Building workspace".
> !STACK 0
> java.lang.StackOverflowError"
> Attached logs.
> We have tried the following solutions:
> 1. We tried increasing the memory size in eclipse.ini file as below but it doesn't seems to work:
> --launcher.XXMaxPermSize
> 1024M
> -showsplash
> org.eclipse.platform
> --launcher.XXMaxPermSize
> 1024m
> --launcher.appendVmargs
> -vm "C:\Program Files\Java\jre7"
> -Dosgi.requiredJavaVersion=1.7
> -Xms2048m
> -Xmx2048m
> 2. When the RAM was checked using task manager eclipse was taking 365MB of memory.
> Please guide us some other workaround to resolve the issue.
> thanks,
> Megha
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (JBIDE-22514) Unable to build the workspace
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22514?page=com.atlassian.jira.plugi... ]
James Perkins updated JBIDE-22514:
----------------------------------
Project: Tools (JBoss Tools) (was: JBoss AS Maven Plugins)
Key: JBIDE-22514 (was: JBASMP-82)
Component/s: build
(was: build)
> Unable to build the workspace
> -----------------------------
>
> Key: JBIDE-22514
> URL: https://issues.jboss.org/browse/JBIDE-22514
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Environment: Eclipse
> Reporter: Megha Kesharwani
> Assignee: James Perkins
> Priority: Trivial
> Attachments: .log
>
>
> I am using eclipse Kepler with plugins JBOSS(wildfly-8.2.0.Final) and ClearCase, while building the workspace i am getting the following error "ENTRY org.eclipse.core.jobs 4 2 2016-06-02 11:07:19.724
> !MESSAGE An internal error occurred during: "Building workspace".
> !STACK 0
> java.lang.StackOverflowError"
> Attached logs.
> We have tried the following solutions:
> 1. We tried increasing the memory size in eclipse.ini file as below but it doesn't seems to work:
> --launcher.XXMaxPermSize
> 1024M
> -showsplash
> org.eclipse.platform
> --launcher.XXMaxPermSize
> 1024m
> --launcher.appendVmargs
> -vm "C:\Program Files\Java\jre7"
> -Dosgi.requiredJavaVersion=1.7
> -Xms2048m
> -Xmx2048m
> 2. When the RAM was checked using task manager eclipse was taking 365MB of memory.
> Please guide us some other workaround to resolve the issue.
> thanks,
> Megha
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months