Add support for image lists to portals without an IMS

duerig [1:51 PM]
Do you have an IMS database?
And you are sure it is populated?

leigh [1:51 PM]
No, no one else has an IMS database.
And UKY is federated with us and uses our IMS.
And ORNL is neither federated or using the image tracker (IMS).

hussam_nasir [1:53 PM]
and neither can see the images in Jacks

duerig [1:53 PM]
Yeah.
Ok. So Do_GetImageList() in instantiate.ajax seems like the place that needs to change. Right now it looks for a local ims database and generates a list accordingly.
But now it needs three branches? One for the mothership case, one for the federated-with-mothership case, and one for a solo case?

hussam_nasir [1:55 PM]
yes

duerig [1:56 PM]
Ok. Let's take that one at a time then. For the federated-with-mothership case, how do I check whether it is federated with the mothership? And if it is, how do I get image lists from the mothership?
For the solo case, what should be returned here? Just a complete list of local images from tbdb?

leigh [1:57 PM]
Lets not worry about the middle case, just worry about the no IMS case.

hussam_nasir [1:57 PM]
aggreed

leigh [1:57 PM]
Assume that if you want to use the local Portal on a federated cluster, you give up the convenience you get by using the Mother Portal. (edited)

duerig [1:58 PM]
I know how to test for mothership-or-not. Is there a more general test for has-IMS that should be used instead?
TBMAINSITE.

leigh [1:59 PM]
That will do for now! 🙂

duerig [1:59 PM]
Ok. And if it is not the mothership, what do I return?

leigh [1:59 PM]
Local images.

duerig [1:59 PM]
Ok. Let me look at the schema.

duerig [2:18 PM]
So it looks like I can select from image_versions, look for an imagename and pid to make a URN, and use the 'global' and 'released' flags to populate a 'system' and 'public' list respectively. No such thing as deprecation. Then creator_urn for populating 'my-images'.