I’m trying to setup a new interactive app. I’m looking at using Open VSCode Server rather than the code-server app. Open VSCode seems to work better with extensions than code-server.
Server bound to 0.0.0.0:4567 (IPv4)
Extension host agent listening on 4567
[09:35:37]
Web UI available at http://localhost:4567/?tkn=test
[09:35:37] Extension host agent started.
If I run the singularity server start command on the command line, it starts and I can connect as expected, but for some reason it doesn’t change from the “starting” status when I run it through ood.
So I make sure I understand, the app will launch but never show a connect button, however if you run from the command line you can connect? Is that right?
The way those cards are handled is a bit tricky, but basically they are generated dynamically by a controller. That controller does in fact check for a session.running? || session.starting? to then change the job to “running” based on some logic which relies on a call to OodCore::Job:Info to figure out what state things are in.
I’m thinking that the call is never returning the info and so OOD doesn’t think the connection is ready, but I want to make sure I understand the flow here first.
Also, does your app have a view file? That should be what populates the actual connect button itself, while the above logic I mentioned handles the status in the upper right corner.
For instance, here’s the view for the bc_osc_codeserver:
Thanks for the response. This is a problem I caused and not your fault, so no need to apologize for the trouble . Thanks for taking the time to help.
The app doesn’t launch, it just sits at “starting”. But the job is running on the server and the “Time remaining” value on the card is ticking down.
I’m thinking that the call is never returning the info and so OOD doesn’t think the connection is ready, but I want to make sure I understand the flow here first.
I think you’re correct. I’m not sure why the call isn’t returning the info to OOD.
Also, does your app have a view file? That should be what populates the actual connect button itself, while the above logic I mentioned handles the status in the upper right corner.
Yes it does. I modified the original view that you posted, but I believe I changed four lines which I mentioned in the code below -
<%
require 'digest'
# Generate form id, based on host and port
form_id = Digest::SHA1.hexdigest("--" + host.to_s + "--" + port.to_s + "--")
# Generate SHA256 digest of Code Server Password
cookieValue = Digest::SHA256.hexdigest(password)
%>
<script type="text/javascript">
(function () {
let date = new Date()
date.setTime(date.getTime() + (7*24*60*60*1000))
let expires = "expires=" + date.toUTCString()
//let cookiePath = "path=/rnode/" + "<%= host.to_s %>" + "/" + "<%= port.to_s %>/";
// Note from Brandon - The path to the Open VSCode is a little different. it's host.example.com:PORT/tkn=PASSWORD
let cookiePath = "path=/rnode/" + "<%= host.to_s %>" + ":" + "<%= port.to_s %>/";
/**
We have to use "key" as the cookie name since upstream in cdr/code-server
the authentication cookie is hard coded "key"
*/
// Commented these out since I didn't think we needed to set a cookie for this different application?
//let cookie = `key=<%= cookieValue %>;${expires};${cookiePath};secure`;
//document.cookie = cookie;
})();
</script>
// Changed the below line
<!--<form id="<%= form_id %>" action="/rnode/<%= host %>/<%= port %>/" method="get" target="_blank">-->
<form id="<%= form_id %>" action="/rnode/<%= host %>:<%= port %>/?tkn=test" method="get" target="_blank">
<button class="btn btn-primary" type="submit">
<i class="fa fa-cogs"></i> Connect to VS Code
</button>
</form>
You’re issue is that you’ve never exported your port.
In your before.sh.erb add
export port=4567
Then use the $port environment variable in your command to boot the container.
OOD goes from Starting → Running based on the connection.yml file. Basically if there’s not enough information here in the connection.yml OOD won’t create the buttons to connect to it.
We’re not going to change the state to Running because we don’t know how to connect to the application.
So it’s a simple fix - export the port variable in your before.sh.erb such that the connection.yml does actually get populated with the correct information.
@jeff.ohrstrom Sorry one more question. Once I exported port I can launch the app, but the new issue I’m running into is the app not being able to access css/javascript. The css/javascript is trying to source example.com/stable-5e932f3b43c571637a183861652b0909ef6da48c/static/out/vs/loader.js
I tried comparing this to Jupyter. Jupyter’s path is example.com/node/compute_node/port/lab and when I inspect the page, the css/javascript is sourced from /node/compute_node/port/static/lab/main....
How does OnDemand fix these paths for CSS/JS? I’m also getting an error about manifest.json not being found? Not sure if that’s related or not?
Yes this has to do with /rnode and /node configurations.
In the one case - /rnode (relative node) - the origin server (the application, code server in this case) doesn’t know it’s behind a proxy server. So apache eats the URL’s relative location. So a request from the client like /rnode/somehost/1234/cool.css gets chewed up and the origin server only sees the request path as /cool.css.
Rstudio is an example of this.
The other - /node - the origin server (the application, code server in this case) does in fact know that it’s behind proxy and the URL paths remain unchanged because the app knows that it has a base path that’s not it’s own.
Juypter does this through a configuration, base_url.
. Thanks for taking the time to help.
