[JBoss JIRA] (JBDS-3282) Screencasts: OpenShift v3
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBDS-3282?page=com.atlassian.jira.plugin.... ]
Alexey Kazakov updated JBDS-3282:
---------------------------------
Fix Version/s: 10.0.0.GA
(was: 10.0.1.AM1)
> Screencasts: OpenShift v3
> -------------------------
>
> Key: JBDS-3282
> URL: https://issues.jboss.org/browse/JBDS-3282
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Feature Request
> Components: documentation, openshift, requirements
> Reporter: Burr Sutter
> Assignee: Fred Bricon
> Priority: Critical
> Labels: screencast
> Fix For: 10.0.0.GA
>
>
> A series of short (5 minutes), educational videos to illustrate the new capabilities of JBDS associated with OpenShift.
> Including:
> - OpenShift's new web UI
> - OpenShift Explorer in the context of v3
> - perhaps an overview of Kubernetes, depends on how "pods" become visible to our end-user
> - an overview of Docker, depends on how 'containers" become visible to our end-user
> and all the typical start, stop, add, delete/remove, view logs, set env vars, etc.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBDS-3282) Screencasts: OpenShift v3
by CDW Engine (JIRA)
[ https://issues.jboss.org/browse/JBDS-3282?page=com.atlassian.jira.plugin.... ]
CDW Engine reassigned JBDS-3282:
--------------------------------
> Screencasts: OpenShift v3
> -------------------------
>
> Key: JBDS-3282
> URL: https://issues.jboss.org/browse/JBDS-3282
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Feature Request
> Components: documentation, openshift, requirements
> Reporter: Burr Sutter
> Assignee: Fred Bricon
> Priority: Critical
> Labels: screencast
> Fix For: 10.0.0.GA
>
>
> A series of short (5 minutes), educational videos to illustrate the new capabilities of JBDS associated with OpenShift.
> Including:
> - OpenShift's new web UI
> - OpenShift Explorer in the context of v3
> - perhaps an overview of Kubernetes, depends on how "pods" become visible to our end-user
> - an overview of Docker, depends on how 'containers" become visible to our end-user
> and all the typical start, stop, add, delete/remove, view logs, set env vars, etc.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBDS-3282) Screencasts: OpenShift v3
by CDW Engine (JIRA)
[ https://issues.jboss.org/browse/JBDS-3282?page=com.atlassian.jira.plugin.... ]
CDW Engine updated JBDS-3282:
-----------------------------
> Screencasts: OpenShift v3
> -------------------------
>
> Key: JBDS-3282
> URL: https://issues.jboss.org/browse/JBDS-3282
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Feature Request
> Components: documentation, openshift, requirements
> Reporter: Burr Sutter
> Assignee: Fred Bricon
> Priority: Critical
> Labels: screencast
> Fix For: 10.0.0.GA
>
>
> A series of short (5 minutes), educational videos to illustrate the new capabilities of JBDS associated with OpenShift.
> Including:
> - OpenShift's new web UI
> - OpenShift Explorer in the context of v3
> - perhaps an overview of Kubernetes, depends on how "pods" become visible to our end-user
> - an overview of Docker, depends on how 'containers" become visible to our end-user
> and all the typical start, stop, add, delete/remove, view logs, set env vars, etc.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBDS-3282) Screencasts: OpenShift v3
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBDS-3282?page=com.atlassian.jira.plugin.... ]
Alexey Kazakov resolved JBDS-3282.
----------------------------------
Resolution: Done
We now have a few screencasts. Resolving.
> Screencasts: OpenShift v3
> -------------------------
>
> Key: JBDS-3282
> URL: https://issues.jboss.org/browse/JBDS-3282
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Feature Request
> Components: documentation, openshift, requirements
> Reporter: Burr Sutter
> Assignee: Fred Bricon
> Priority: Critical
> Labels: screencast
> Fix For: 10.0.1.AM1
>
>
> A series of short (5 minutes), educational videos to illustrate the new capabilities of JBDS associated with OpenShift.
> Including:
> - OpenShift's new web UI
> - OpenShift Explorer in the context of v3
> - perhaps an overview of Kubernetes, depends on how "pods" become visible to our end-user
> - an overview of Docker, depends on how 'containers" become visible to our end-user
> and all the typical start, stop, add, delete/remove, view logs, set env vars, etc.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-22578) Publishing sometimes recursively deletes parent to deploy directory
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22578?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-22578:
-------------------------------------
[~datallah] This is great feedback! I will run some tests and see what I can find, but this is 100% a great lead. Thanks!
> Publishing sometimes recursively deletes parent to deploy directory
> -------------------------------------------------------------------
>
> Key: JBIDE-22578
> URL: https://issues.jboss.org/browse/JBIDE-22578
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.3.1.Final
> Environment: Eclipse Mars.2 Release (4.5.2)
> Java 1.8.0_91
> Windows 7 64-bit
> JBoss EAP 6.4.0
> Reporter: Daniel Atallah
> Assignee: Rob Stryker
> Priority: Blocker
> Fix For: 4.4.1.AM1
>
> Attachments: jboss_deployment.jpg, servers.xml
>
>
> For a number of weeks we've had a number of occurrences where a eclipse workspace will get corrupted due to the deletion of all files in it.
> It seems to have started happening at the time we updated to the 4.3.1 JBoss Tools from the 4.3.0 JBoss Tools.
> We've been able to track the process doing the deleting to the Eclipse process by using Sysinternals Process Monitor tool (https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx).
> Our workspaces are structured as follows:
> {noformat}
> WORKSPACEROOT=$DEVROOT\workspacename
> # Custom deploy folder (as specified in the "Deployment" settings for the configured "Red Hat JBoss Enterprise Application Platform 6.1+") Server
> $WORKSPACEROOT\deploy
> # Version Control (Mercurial) working directory containing various Eclipse projects that get published to the Server by the tooling
> $WORKSPACEROOT\src
> # value specified as a "jboss.server.data.dir" property in the Server launch configuration VM arguments
> $WORKSPACEROOT/server/data
> # value specified as a "jboss.server.temp.dir" property in the Server launch configuration VM arguments
> $WORKSPACEROOT/server/tmp
> {noformat}
> The Server is configured to "Automatically publish when resources change".
> What we're seeing is that occasionally when the Server is running and the Mercurial working copy receives updates, the Incremental Publishing that results from these updates somehow tries to recursively delete $WORKSPACEROOT.
> The eclipse log includes the following:
> {noformat}
> !ENTRY org.eclipse.core.resources 4 1 2016-06-07 16:05:57.795
> !MESSAGE Problems occurred refreshing resources
> !SUBENTRY 1 org.eclipse.core.resources 4 1 2016-06-07 16:05:57.795
> !MESSAGE Problem finding next change, code: 5
> !ENTRY org.jboss.ide.eclipse.as.core 4 1644298244 2016-06-07 16:06:09.207
> !MESSAGE Incremental publish failed for module $MODULENAME
> !SUBENTRY 1 org.jboss.ide.eclipse.as.wtp.core 4 1644298251 2016-06-07 16:06:09.207
> !MESSAGE Could not delete $WORKSPACEROOT. May be locked by another process.
> {noformat}
> Any idea what might be happening?
> Is there some debug logging we can enable to get better visibility to what's going on?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-22608) Support scenario when cdk is stopped from cli and then in devstudio
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22608?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-22608:
-------------------------------------
[~mmalina] I'm not able to replicate this.
Code for the shutdown controller is as follows:
{code}
@Override
public void stop(boolean force) {
getBehavior().setServerStopping();
IStatus state = PollThreadUtils.isServerStarted(getServer(), new VagrantPoller());
boolean started = state.isOK();
if( !started ) {
if( state.getSeverity() == IStatus.ERROR ) {
// server is stopped, cancel the poller
cancelPoller();
getBehavior().setServerStopped();
return;
}
}
try {
shutdownViaExternalTools();
} catch(CoreException ce) {
CDKCoreActivator.getDefault().getLog().log(
new Status(IStatus.ERROR, CDKCoreActivator.PLUGIN_ID, "Error shutting down server", ce));
getBehavior().setServerStarted();
}
}
{code}
When the cdk is asked to stop, we first do a vagrant status. When we see it is already stopped, we just market it as stopped and take no action.
Is there some difference between what build you're using and my devenv?
> Support scenario when cdk is stopped from cli and then in devstudio
> -------------------------------------------------------------------
>
> Key: JBIDE-22608
> URL: https://issues.jboss.org/browse/JBIDE-22608
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: cdk
> Affects Versions: 4.4.0.Final
> Reporter: Martin Malina
> Assignee: Rob Stryker
>
> Assume your cdk is started and it's shown as started in devstudio, now what if you stop cdk from cli for whatever reason? Currently the tooling can't handle such situation.
> If you then try to stop cdk in devstudio, you get an error pop-up:
> Server Container Development Environment failed to stop.
> And the console will just say:
> ==> default: VM not created. Moving on...
> But most importantly, the server adapter will stay in the Started state.
> We should probably support this scenario - it's quite likely that it will happen to users.
> Right now there are several ways out of this situation:
> a) Start cdk from cli again and everything will probably work as expected
> b) Restart your IDE
> So I suggest we improve the tooling in such a way that when you stop cdk, it will be able to detect that it's actually not running and just change the state to Stopped. It may be still ok to pop up the error saying it failed to stop. But at least you can now start it again from the IDE.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-22630) bzira/jiralint fails often because of missing pip install
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22630?page=com.atlassian.jira.plugi... ]
Nick Boldt updated JBIDE-22630:
-------------------------------
Fix Version/s: 4.4.1.M1
> bzira/jiralint fails often because of missing pip install
> ---------------------------------------------------------
>
> Key: JBIDE-22630
> URL: https://issues.jboss.org/browse/JBIDE-22630
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Reporter: Max Rydahl Andersen
> Fix For: 4.4.1.M1
>
>
> bzia/jiralint oftenn fails because pip are missing from the servers it runs on.
> shuold limit the nodes it runs on or get pip installed more generally.
> error from build mails
> {code}
> + pip install --upgrade --user bugzilla bugzillatools python-bugzilla jira pytz
> Traceback (most recent call last):
> File "/qa/services/hudson/.local/bin/pip", line 7, in <module>
> from pip import main
> ImportError: No module named pip
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-22630) bzira/jiralint fails often because of missing pip install
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22630?page=com.atlassian.jira.plugi... ]
Nick Boldt reassigned JBIDE-22630:
----------------------------------
Assignee: Nick Boldt
> bzira/jiralint fails often because of missing pip install
> ---------------------------------------------------------
>
> Key: JBIDE-22630
> URL: https://issues.jboss.org/browse/JBIDE-22630
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Reporter: Max Rydahl Andersen
> Assignee: Nick Boldt
> Fix For: 4.4.1.M1
>
>
> bzia/jiralint oftenn fails because pip are missing from the servers it runs on.
> shuold limit the nodes it runs on or get pip installed more generally.
> error from build mails
> {code}
> + pip install --upgrade --user bugzilla bugzillatools python-bugzilla jira pytz
> Traceback (most recent call last):
> File "/qa/services/hudson/.local/bin/pip", line 7, in <module>
> from pip import main
> ImportError: No module named pip
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months