Does OOD v1.8 still support our multiple instance setup?

Open OnDemand Get Help
#1

We have two OOD instances (prod and dev), each using a corresponding cluster (prod and dev), and sharing user home directories. (Each user accesses the same home directory from any cluster, both in and out of OOD.) With OOD 1.7, it was possible to run a given app (e.g. Matlab) in one of the OOD instances, and then run the same app in the other OOD instance. (Members of the dev team do this while creating/updating apps.) With OOD 1.8 (v1.8.18), this no longer works – after running in dev, when try to Launch the app in prod, we get this error:

ood1.8_submit
ood1.8_submit1011×180 20 KB

I think this is related to the file in the user’s home directory ondemand/data/sys/dashboard/batch_connect/sys/APP-NAME/context.json – manually deleting this file before attempting to Launch the app resolves the problem. I notice that this file contains the cluster name (in addition to remembering the user’s most recent selections for the app), and it appears that the cluster name here takes precedence over the cluster name defined in the app itself.

I understand that for some setups, cluster can be a user-selectable option, which explains why it would be in this file. It seems that some additional logic to check whether the cluster from this file is available, and if not then get the cluster from the app in the normal way, could resolve the issue we are having. Do you have any suggestions? Is there any way to resolve this with our configuration?

#2

Hey I’m looking to replicate. I think this may work for you, but since I haven’t replicated I also haven’t tested it - I just typed it out here.

There are a couple ways you can set the cluster attribute now, and one of them is by just creating a cluster form item like any other form item. In this way, you can force it to not be cachable (even though it’s hard coded).

form:
  - cluster
attributes:
  cluster: 
    value: "dev"
    cacheable: false
#3

Thanks for the information. I tried this for one app (with cluster being the last item listed under form). It had the effect of moving the position of cluster in context.json from being the first item to the last. It seems like the cachable: false attribute is being ignored. I confirmed that editing context.json and just removing the cluster item (rather than deleting the file) allows me to start the app on the other OOD instance, so preventing cluster from being included in this file will resolve my issue. Might there be a way to do this for all apps at once?

#4

Sorry! I think it’s cacheable with an e. I’ll also edit the post above this as it was false.

Also you’re right about order not mattering. Order of the form items only relate to how the UI is built.

#5

Thanks for the correction. I made it, but cluster was still included in context.json. Then I tried completely removing cluster from form.yml and instead put it in submit.yml.erb (just the one line cluster: dev). This seems to have worked – cluster no longer appears in context.json and the job is submitted to the correct cluster. I’m still not sure of a good way to manage this for all apps.

#6

There’s a bug on our side where we really shouldn’t be using the cached value in this case. I’ve submitted the fix so there could be an update for 1.8 shortly.