Session information in info.md.erb

Get Help
1

Hi all,

I am pretty new to using OOD, but managed to create an interactive app (RStudio).
Now the question popped up, when a user creates several R Sessions on the cluster, how can she distinguish which session does what in the session overview?

I thought to just add an additional text-field “custom label” to the form.yml and then display that string in the info.md.erb. However I did not find it straightforward to access the information of form, I would have expected erb-variables like session.custom_label or context.slots, but all I seem to be able to access are: @id, @host, @created and a handful of variables.

Now by accident I discovered that I do have access to a variable called “user_context_file” which does contain the path to (you guessed it) the user_context.json in the session directory.
Which my erb now reads, parses and then displays.

This feels pretty convoluted, I am sure there must be a more straightforward way?

2

Hello and welcome!

I would first point out that we do have an rstudio app which may actually do quite a bit of what you are trying to accomplish. This app can be found below:

This allows a user to run many rstudio sessions, though I am a bit unsure if it is the exact solution you are hoping/looking for. Is the goal to have information display on the session card about this particular session of rstudio vs another?

3

Exactly! A user might start a session (with a specific R-Version) and start a long-running script. Then start another session with a different R-Version to work on a different task. It would be nice if the session-overview shows for each running session not only when and where it was started, but also which queue was selected, which R-Version, and in my case an arbitrary string, e.g. “my session to do this”.

All of this information was set on the initial form.yml.erb, I expected it to be available in all other erb files

4

Cool! I think we can figure this out.

Have you already looked at the docs over this? It sounds like you have since you mentioned the info.md.erb file but, just in case:
https://osc.github.io/ood-documentation/latest/app-development/interactive/view.html#adding-additional-information-to-the-panel

I think what you will find is you need to ensure you are including a conn_param to share the information across all pieces of the app so that the view knows things the form setup and handed off to the script ultimately to run.

If you read through this and go to the bottom of the page, you can read more about how to set those conn_params up to share info with the view and this should get you where you need to go:

https://osc.github.io/ood-documentation/latest/reference/files/submit-yml/basic-bc-options.html?highlight=connection%20yml

5

hmm, in my submit.yml.erb I didn’t specify a conn_file, so I do have the default connection.yml. I did specify (for similar purposes) a conn_param called “sif_container”:

conn_params: [ sif_container ]

my connection.yml:

 sif_container: 
 host: rivm-lsfsv-l01p
 port: 123
 password: ylGFfGzLrvvYs1ty

my added parameter is empty (unsurprisingly).
How to I read and write those parameters?

The documentation mentions “the_connect_api”, but should that be a link to additional information?

At some point I tried adding:

 script:
   [...]
   job_environment:
     sif_container: "something"

but no effect. I have to admit I am not sure why I tried this.

I try to follow the csrf_token in your app.

6

You can read and write those params by just treating them as new variables throughout the code.

Overview

Suppose we need to check the version of something an app is using and offering in a form, but I need that to then effect how something in the view renders.

So, I can set whatever variable I want in the conn_params, and then use that variable name in the form and setting its attributes being presented in the form (maybe it has various options, or in your case maybe a text_field) and then when the submit happens and the script runs it also may use that information to do some logic, which is typical.

But, the key is now when that view renders, it can use ERB to check the value of that form attribute we made up to then decide what to render and now we have the form and view interacting.

This problem

That’s abstract though. Let’s try a real example. So in the form let’s add a text field for the description.

I’d add an option in the form for a text field and call it something like r_session_description so you hae something like this:

---
...
attributes:
  r_session_description:
    label: "A text description of your R session"
      widget: text_field

So now we have the field rendering in the form and the user can input text.

To then get this to pop in the view, we need to add this r_session_description to the conn_params in the submit.yml.erb and also export the variable from the before.sh.erb file so that the field is available in the view.

In the submit.yml.erb:

attributes:
  r_session_description:
    label: "Session Description"
    widget: "text_field"
    cacheable: false

Then, in the before.sh.erb add:

export r_session_description="<%= context.r_session_description %>"

Now alter the app’s view to include this text_field like so:

<% if ! r_session_description.blank? %>
<%= r_session_description %>
<% end %>

And wherever that is inserted in the view will have the description render that was entered in the text_field if it was used, else nothing displays.

Hopefully that is a rough enough example to get you further. Please let me know if you have any more questions!

7

That sounded clear enough, but I am still stuck.

in my submit.yml.erb:

---
batch_connect:
  template: "basic"
  conn_params:
    - custom_label
    - r_version

and I fill those variables in my form.yml.erb:

attributes:
  custom_label:
    label: Label
    help: Label to distinguish different sessions
    widget: "text_field"
    required: false
  r_version:
    label: R Version
    help: Select the version of R to use
    widget: select
    options:
      - [ "4.2.1", "ood_database_rstudio_4.2.1.sif"]

after creating a session I get immediatly:

Error when rendering info view: NameError - undefined local variable or method custom_label’ for #BatchConnect::Session:0x00007f221c8c5998`

I have noticed the connect.yml doesn’t even exist while the job is still queued. However the file “user_defined_context.json” doies exists and contains those two variables with the correct value.
Even after the job is started the connection.yml exists but my two additional variables are empty:

custom_label: 
r_version: 
host: rivm-lsfsv-l01p.rivm.ssc-campus.nl
port: 64735
password: WeCicLTySIytB6tz

I used to have the following in my info.md.erb:

<%
data = File.read(user_defined_context_file)
udc = JSON.parse(data) %>

<% if !udc[“custom_label”].blank? %>
Label: <%= udc[“custom_label”] %>
<% end %>

8

I’m going to have to apologize for this one as I think I lead you on a wild goose chase and I’m really sorry about that.

Digging into this more last night and this morning I’m very surprised to find how locked down these cards have been designed. Previously I had thought you could do the above adjustment and customize the cards, that is just not true and I was unaware how locked down these cards are for customization.

That said, I’m opening an issue to fix this as you should be able to edit those cards either in the info.md.erb or the view and currently neither really let you do much. What is there is really just allowing you to check for changing the structure of the html that is served in some ways, but you can’t actually insert anything beyond logic to change the rendering. Something as simple as just inserting a string though can’t seem to be done, or at least it is not at all straightforward to do.

Looking at how this is all done, we seem to have hard coded what will be rendered, and left no options to supply some kind of list of attributes to then use in the info.md.erb to customize the session panels for reasons like you’ve asked.

So, I’m putting in an issue on GitHub for this exact feature as I really can’t understand why it isn’t there already aside from historical reasons. I’ll admit I’m also baffled why we allowed this to sort of work (to do things like pass a csrf_token) but didn’t just go the whole way and let you modify the card.

Again, I’m very sorry for the false hope that this could be done currently. The issue I’ve opened can be seen here: Customizing Session Cards · Issue #2342 · OSC/ondemand · GitHub

9

No worries!
In the end I do have a solution that seems to work, just not very elegant.

But I’m looking forward to see #2342 resolved :slight_smile:

10

Glad to hear. Curious, was your solution to just use the view with the description field from the form used there using the conn_params trick? That was the only solution I was able to get to work that roughly handled what you were looking for, but not the info.md.erb file unfortunately.

11

Reading through this I realized I forgot to include a step! I’m so sorry!

I’m going to edit the original post to include this step.

You will also need to open the before.sh.erb in the templates directory and include export description="<%= context.r_session_description %>" in that script.

You should be able to add fields to be rendered correctly with the view at least using this, though it still won’t work for the info.md.erb file.

12

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.