[JBoss JIRA] (JBIDE-22362) Server Adapter: Static changes done to nodejs application are not visible
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22362?page=com.atlassian.jira.plugi... ]
Andre Dietisheim edited comment on JBIDE-22362 at 10/25/16 1:46 PM:
--------------------------------------------------------------------
[~ibuziuk] JBIDE-23412 is duplicate to JBIDE-23030, but the solution in JBIDE-23030 wont fix what we can see in this issue. The reason is the same though. But we'll need a separate fix in here.
was (Author: adietish):
[~ibuziuk] JBIDE-23412 is duplicate to JBIDE-23030, but the solution in JBIDE-23030 wont fix what we can see in this issue. We'll need a separate fix in here.
> Server Adapter: Static changes done to nodejs application are not visible
> -------------------------------------------------------------------------
>
> Key: JBIDE-22362
> URL: https://issues.jboss.org/browse/JBIDE-22362
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: javascript, openshift
> Affects Versions: 4.4.0.Alpha2
> Reporter: Marián Labuda
> Assignee: Ilya Buziuk
> Priority: Critical
> Labels: openshift_v3, server_adapter
> Fix For: 4.4.2.AM3
>
> Attachments: enabling-dev-mode-has-encountered-an-error.png
>
>
> I am having an OpenShift application based either on nodejs-example or nodejs-mongodb-example template. Once application is up and running I create a new server adapter and perform changes in index.html. These changes are static and should be (?) immediately visible on OpenShift server, but they are not. I have checked whether changes were published, but rsync in console shows expected output also changes done manually on the server side to index.html are not visible in browser (even when cache overwritten is triggered - so there is no caching problem in browser). This seems to be upstream issues, but requires investigating.
> So far I have tried it on CDK OpenShift. It would be nice to test it on other OpenShift instances, also on templates using different base docker image.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 5 months
[JBoss JIRA] (JBIDE-22362) Server Adapter: Static changes done to nodejs application are not visible
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22362?page=com.atlassian.jira.plugi... ]
Andre Dietisheim commented on JBIDE-22362:
------------------------------------------
[~ibuziuk] JBIDE-23412 is duplicate to JBIDE-23030, but the solution in JBIDE-23030 wont fix what we can see in this issue. We'll need a separate fix in here.
> Server Adapter: Static changes done to nodejs application are not visible
> -------------------------------------------------------------------------
>
> Key: JBIDE-22362
> URL: https://issues.jboss.org/browse/JBIDE-22362
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: javascript, openshift
> Affects Versions: 4.4.0.Alpha2
> Reporter: Marián Labuda
> Assignee: Ilya Buziuk
> Priority: Critical
> Labels: openshift_v3, server_adapter
> Fix For: 4.4.2.AM3
>
> Attachments: enabling-dev-mode-has-encountered-an-error.png
>
>
> I am having an OpenShift application based either on nodejs-example or nodejs-mongodb-example template. Once application is up and running I create a new server adapter and perform changes in index.html. These changes are static and should be (?) immediately visible on OpenShift server, but they are not. I have checked whether changes were published, but rsync in console shows expected output also changes done manually on the server side to index.html are not visible in browser (even when cache overwritten is triggered - so there is no caching problem in browser). This seems to be upstream issues, but requires investigating.
> So far I have tried it on CDK OpenShift. It would be nice to test it on other OpenShift instances, also on templates using different base docker image.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 5 months
[JBoss JIRA] (JBIDE-23030) Scaling a service changes the wrong deployment
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23030?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-23030:
-------------------------------------
Issue Type: Bug (was: Feature Request)
> Scaling a service changes the wrong deployment
> ----------------------------------------------
>
> Key: JBIDE-23030
> URL: https://issues.jboss.org/browse/JBIDE-23030
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.4.1.AM3
> Reporter: Fred Bricon
> Assignee: Jeff Cantrill
> Priority: Critical
> Fix For: 4.4.2.AM3
>
> Attachments: scale-to-shows-old-rc.ogv
>
>
> In openshift explorer, when scaling a service that has 2 deployments, it deploys pod from the oldest deployment instead of the latest. Eventually, these pods are killed by openshift.
> The workaround is to open the properties view and issue a scale command on a deployment directly.
> However, because scaling is such a front-and-center feature from the explorer, I believe it's critical we fix it ASAP
> (copied from JBIDE-23412)
> The following steps can be seen in the following screencast:
> [^scale-to-shows-old-rc.ogv]
> # ASSERT: have an app running (ex. nodejs-example)
> # ASSERT: In OpenShift Explorer: make sure it has at least 1 pod: pick "Scale To" in the context menu of the service. Dialog shows that there's at least 1 pod currently
> # ASSERT: in OpenShift Explorer: there 1 pod shown as child to the service.
> # ASSERT: in Properties view, pick "Deployments" tab and see that there's at least 1 deployment (aka replication controller)
> # EXEC: in OpenShift explorer: select Service pick "Deploy Latest"
> # ASSERT: in Properties view: "Deployments" now shows 2 Deployments
> # ASSERT: in OpenShift Explorer you now see 2 children/pods
> # EXEC: in OpenShift Explorer: pick "Scale To..." in the context menu of the service
> Result:
> The current number of pods is shown as 0.
> !replicas-0.png!
> But it's very sure that this is not true. Behind the scenes a new replication controller was created which deployed a new pod:
> !rc2-replicas-1.png!
> The old replication controller was turned to have 0 pods. The "Scale To" dialog shows the number of replcas for the old replication controller.
> !rc-1-replicas-0.png!
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 5 months
[JBoss JIRA] (JBIDE-23030) Scaling a service changes the wrong deployment
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23030?page=com.atlassian.jira.plugi... ]
Andre Dietisheim edited comment on JBIDE-23030 at 10/25/16 1:26 PM:
--------------------------------------------------------------------
this is identical to what I found in JBIDE-23412.
was (Author: adietish):
I believe that this is very closely related or even the same as JBIDE-23412
> Scaling a service changes the wrong deployment
> ----------------------------------------------
>
> Key: JBIDE-23030
> URL: https://issues.jboss.org/browse/JBIDE-23030
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: openshift
> Affects Versions: 4.4.1.AM3
> Reporter: Fred Bricon
> Assignee: Jeff Cantrill
> Priority: Critical
> Fix For: 4.4.2.AM3
>
> Attachments: scale-to-shows-old-rc.ogv
>
>
> In openshift explorer, when scaling a service that has 2 deployments, it deploys pod from the oldest deployment instead of the latest. Eventually, these pods are killed by openshift.
> The workaround is to open the properties view and issue a scale command on a deployment directly.
> However, because scaling is such a front-and-center feature from the explorer, I believe it's critical we fix it ASAP
> (copied from JBIDE-23412)
> The following steps can be seen in the following screencast:
> [^scale-to-shows-old-rc.ogv]
> # ASSERT: have an app running (ex. nodejs-example)
> # ASSERT: In OpenShift Explorer: make sure it has at least 1 pod: pick "Scale To" in the context menu of the service. Dialog shows that there's at least 1 pod currently
> # ASSERT: in OpenShift Explorer: there 1 pod shown as child to the service.
> # ASSERT: in Properties view, pick "Deployments" tab and see that there's at least 1 deployment (aka replication controller)
> # EXEC: in OpenShift explorer: select Service pick "Deploy Latest"
> # ASSERT: in Properties view: "Deployments" now shows 2 Deployments
> # ASSERT: in OpenShift Explorer you now see 2 children/pods
> # EXEC: in OpenShift Explorer: pick "Scale To..." in the context menu of the service
> Result:
> The current number of pods is shown as 0.
> !replicas-0.png!
> But it's very sure that this is not true. Behind the scenes a new replication controller was created which deployed a new pod:
> !rc2-replicas-1.png!
> The old replication controller was turned to have 0 pods. The "Scale To" dialog shows the number of replcas for the old replication controller.
> !rc-1-replicas-0.png!
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 5 months
[JBoss JIRA] (JBIDE-23030) Scaling a service changes the wrong deployment
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23030?page=com.atlassian.jira.plugi... ]
Andre Dietisheim edited comment on JBIDE-23030 at 10/25/16 1:22 PM:
--------------------------------------------------------------------
The PR in this issues fixes the issue I could observe in JBIDE-23412.
Rebased it and created new PR at [#1356|https://github.com/jbosstools/jbosstools-openshift/pull/1356]. [~rhopp] [~mlabuda] can you please review and +1 this critical fix as soon as possible?
was (Author: adietish):
The PR in this issues fixes the issue I could observe in JBIDE-23412.
Rebased and merged it.
> Scaling a service changes the wrong deployment
> ----------------------------------------------
>
> Key: JBIDE-23030
> URL: https://issues.jboss.org/browse/JBIDE-23030
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: openshift
> Affects Versions: 4.4.1.AM3
> Reporter: Fred Bricon
> Assignee: Jeff Cantrill
> Priority: Critical
> Fix For: 4.4.2.AM3
>
> Attachments: scale-to-shows-old-rc.ogv
>
>
> In openshift explorer, when scaling a service that has 2 deployments, it deploys pod from the oldest deployment instead of the latest. Eventually, these pods are killed by openshift.
> The workaround is to open the properties view and issue a scale command on a deployment directly.
> However, because scaling is such a front-and-center feature from the explorer, I believe it's critical we fix it ASAP
> (copied from JBIDE-23412)
> The following steps can be seen in the following screencast:
> [^scale-to-shows-old-rc.ogv]
> # ASSERT: have an app running (ex. nodejs-example)
> # ASSERT: In OpenShift Explorer: make sure it has at least 1 pod: pick "Scale To" in the context menu of the service. Dialog shows that there's at least 1 pod currently
> # ASSERT: in OpenShift Explorer: there 1 pod shown as child to the service.
> # ASSERT: in Properties view, pick "Deployments" tab and see that there's at least 1 deployment (aka replication controller)
> # EXEC: in OpenShift explorer: select Service pick "Deploy Latest"
> # ASSERT: in Properties view: "Deployments" now shows 2 Deployments
> # ASSERT: in OpenShift Explorer you now see 2 children/pods
> # EXEC: in OpenShift Explorer: pick "Scale To..." in the context menu of the service
> Result:
> The current number of pods is shown as 0.
> !replicas-0.png!
> But it's very sure that this is not true. Behind the scenes a new replication controller was created which deployed a new pod:
> !rc2-replicas-1.png!
> The old replication controller was turned to have 0 pods. The "Scale To" dialog shows the number of replcas for the old replication controller.
> !rc-1-replicas-0.png!
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 5 months
[JBoss JIRA] (JBIDE-23030) Scaling a service changes the wrong deployment
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23030?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-23030:
-------------------------------------
Git Pull Request: https://github.com/openshift/openshift-restclient-java/pull/205, https://github.com/jbosstools/jbosstools-openshift/pull/1294, https://github.com/jbosstools/jbosstools-openshift/pull/1356 (was: https://github.com/openshift/openshift-restclient-java/pull/205, https://github.com/jbosstools/jbosstools-openshift/pull/1294)
> Scaling a service changes the wrong deployment
> ----------------------------------------------
>
> Key: JBIDE-23030
> URL: https://issues.jboss.org/browse/JBIDE-23030
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: openshift
> Affects Versions: 4.4.1.AM3
> Reporter: Fred Bricon
> Assignee: Jeff Cantrill
> Priority: Critical
> Fix For: 4.4.2.AM3
>
> Attachments: scale-to-shows-old-rc.ogv
>
>
> In openshift explorer, when scaling a service that has 2 deployments, it deploys pod from the oldest deployment instead of the latest. Eventually, these pods are killed by openshift.
> The workaround is to open the properties view and issue a scale command on a deployment directly.
> However, because scaling is such a front-and-center feature from the explorer, I believe it's critical we fix it ASAP
> (copied from JBIDE-23412)
> The following steps can be seen in the following screencast:
> [^scale-to-shows-old-rc.ogv]
> # ASSERT: have an app running (ex. nodejs-example)
> # ASSERT: In OpenShift Explorer: make sure it has at least 1 pod: pick "Scale To" in the context menu of the service. Dialog shows that there's at least 1 pod currently
> # ASSERT: in OpenShift Explorer: there 1 pod shown as child to the service.
> # ASSERT: in Properties view, pick "Deployments" tab and see that there's at least 1 deployment (aka replication controller)
> # EXEC: in OpenShift explorer: select Service pick "Deploy Latest"
> # ASSERT: in Properties view: "Deployments" now shows 2 Deployments
> # ASSERT: in OpenShift Explorer you now see 2 children/pods
> # EXEC: in OpenShift Explorer: pick "Scale To..." in the context menu of the service
> Result:
> The current number of pods is shown as 0.
> !replicas-0.png!
> But it's very sure that this is not true. Behind the scenes a new replication controller was created which deployed a new pod:
> !rc2-replicas-1.png!
> The old replication controller was turned to have 0 pods. The "Scale To" dialog shows the number of replcas for the old replication controller.
> !rc-1-replicas-0.png!
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 5 months
[JBoss JIRA] (JBIDE-23030) Scaling a service changes the wrong deployment
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23030?page=com.atlassian.jira.plugi... ]
Andre Dietisheim commented on JBIDE-23030:
------------------------------------------
The PR in this issues fixes the issue I could observe in JBIDE-23412.
Rebased and merged it.
> Scaling a service changes the wrong deployment
> ----------------------------------------------
>
> Key: JBIDE-23030
> URL: https://issues.jboss.org/browse/JBIDE-23030
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: openshift
> Affects Versions: 4.4.1.AM3
> Reporter: Fred Bricon
> Assignee: Jeff Cantrill
> Priority: Critical
> Fix For: 4.4.2.AM3
>
> Attachments: scale-to-shows-old-rc.ogv
>
>
> In openshift explorer, when scaling a service that has 2 deployments, it deploys pod from the oldest deployment instead of the latest. Eventually, these pods are killed by openshift.
> The workaround is to open the properties view and issue a scale command on a deployment directly.
> However, because scaling is such a front-and-center feature from the explorer, I believe it's critical we fix it ASAP
> (copied from JBIDE-23412)
> The following steps can be seen in the following screencast:
> [^scale-to-shows-old-rc.ogv]
> # ASSERT: have an app running (ex. nodejs-example)
> # ASSERT: In OpenShift Explorer: make sure it has at least 1 pod: pick "Scale To" in the context menu of the service. Dialog shows that there's at least 1 pod currently
> # ASSERT: in OpenShift Explorer: there 1 pod shown as child to the service.
> # ASSERT: in Properties view, pick "Deployments" tab and see that there's at least 1 deployment (aka replication controller)
> # EXEC: in OpenShift explorer: select Service pick "Deploy Latest"
> # ASSERT: in Properties view: "Deployments" now shows 2 Deployments
> # ASSERT: in OpenShift Explorer you now see 2 children/pods
> # EXEC: in OpenShift Explorer: pick "Scale To..." in the context menu of the service
> Result:
> The current number of pods is shown as 0.
> !replicas-0.png!
> But it's very sure that this is not true. Behind the scenes a new replication controller was created which deployed a new pod:
> !rc2-replicas-1.png!
> The old replication controller was turned to have 0 pods. The "Scale To" dialog shows the number of replcas for the old replication controller.
> !rc-1-replicas-0.png!
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 5 months
[JBoss JIRA] (JBIDE-23030) Scaling a service changes the wrong deployment
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23030?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-23030:
-------------------------------------
Attachment: scale-to-shows-old-rc.ogv
> Scaling a service changes the wrong deployment
> ----------------------------------------------
>
> Key: JBIDE-23030
> URL: https://issues.jboss.org/browse/JBIDE-23030
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: openshift
> Affects Versions: 4.4.1.AM3
> Reporter: Fred Bricon
> Assignee: Jeff Cantrill
> Priority: Critical
> Fix For: 4.4.2.AM3
>
> Attachments: scale-to-shows-old-rc.ogv
>
>
> In openshift explorer, when scaling a service that has 2 deployments, it deploys pod from the oldest deployment instead of the latest. Eventually, these pods are killed by openshift.
> The workaround is to open the properties view and issue a scale command on a deployment directly.
> However, because scaling is such a front-and-center feature from the explorer, I believe it's critical we fix it ASAP
> (copied from JBIDE-23412)
> The following steps can be seen in the following screencast:
> [^scale-to-shows-old-rc.ogv]
> # ASSERT: have an app running (ex. nodejs-example)
> # ASSERT: In OpenShift Explorer: make sure it has at least 1 pod: pick "Scale To" in the context menu of the service. Dialog shows that there's at least 1 pod currently
> # ASSERT: in OpenShift Explorer: there 1 pod shown as child to the service.
> # ASSERT: in Properties view, pick "Deployments" tab and see that there's at least 1 deployment (aka replication controller)
> # EXEC: in OpenShift explorer: select Service pick "Deploy Latest"
> # ASSERT: in Properties view: "Deployments" now shows 2 Deployments
> # ASSERT: in OpenShift Explorer you now see 2 children/pods
> # EXEC: in OpenShift Explorer: pick "Scale To..." in the context menu of the service
> Result:
> The current number of pods is shown as 0.
> !replicas-0.png!
> But it's very sure that this is not true. Behind the scenes a new replication controller was created which deployed a new pod:
> !rc2-replicas-1.png!
> The old replication controller was turned to have 0 pods. The "Scale To" dialog shows the number of replcas for the old replication controller.
> !rc-1-replicas-0.png!
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 5 months