OOD parses and executes ALL form.yml.erb for ALL interactive applications no matter what action

Ondemand seems to be processing the form.yml.erb for every interactive app we have, even if the user isn’t using them.

For example, I have a piece of code in some of our applications forms that grabs all the partitions available for the user, and populates a form field with that data. If I am tailing the nginx error.log for that PUN, I will see the execve call on every one of those applications without doing anything.

It looks like everything in OOD causes this parse to happen. Logging into the dashboard, using the file app, every link clicked will cause these to trigger.

This is a big issue:

  • As our list of applications gets bigger, even single calls in each one that would not be taxing to the system, now cause delays.
  • Because these are compiled/parsed no matter what page you are on, if you have an application with ruby code that is broken, ALL of OOD is now broken, as that code is executed and causes failures no matter what part of the application you are using.
  • This affects our production environment from a users sandbox. Any user that has something in their sandbox that is broken like this, will cause that user to no longer be able to access the OOD application until it is fixed.

Should I open this as an issue on the ondemand github?

Generally speaking - yes. But in this case, there’s already a ticket for the same. We know it’s an issue, just no work has been put into it yet, though I’d like to remedy that. You’re right in that it should work easily and simply and not break every app when one app fails to render.

Jeff,

Thank you for the link to the issue. I for one had made the assumption that the manifest.yml was the only thing read/processed unless you specifically were launching that application. My personal suggestion would be something along this line as a fix.

I understand that there is a lot more implication to that fix than just making it happen, but it does seem the easiest for sites to adjust their current applications to, as they would only have to verify their manifest.yml is present and formatted correctly. As a transition OOD might try to use the manifest.yml if it exists and only parse the rest of the directory (form.yml.erb, etc… ) if the manifest is unreadable.

Our site was prepping to move from our internal staging to production for user access at the end of Sept. but this issue is starting to already causing slow downs with 8 applications and a couple users due to some custom attribute data generated in the applications form.yml.erb files. As an example, we are doing something similar to Use a Local Dynamic List — Open OnDemand 1.3.0 documentation to generate partition/queue drop downs for the forms. I noticed in the newer documentation this section was changed to reflect calling local/global static lists, which defeats the purpose of displaying only a list of the partitions the logged in user has access to.

If you have suggestions for work-arounds in the meantime until OOD can resolve this issue I would gladly look into them. Currently I am looking at offloading all the dynamic generation from the form.yml.erb to form.js, but I am not sure if the form.js is processed at the same times the form.yml.erb would be, which would just move the problem from one file, to another.

Thanks for any help/updates,

Bruce

If you have suggestions for work-arounds in the meantime until OOD can resolve this issue I would gladly look into them. Currently I am looking at offloading all the dynamic generation from the form.yml.erb to form.js, but I am not sure if the form.js is processed at the same times the form.yml.erb would be, which would just move the problem from one file, to another.

Since the javascript is run on the client-side I don’t think this will help me overcome my current issues. I will open a new discourse topic for suggestions.

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