Request #5299

Use IMAGE_ID in templates instead of IMAGE

Added by Strahinja Kustudic about 3 years ago. Updated about 3 years ago.

Status:PendingStart date:08/02/2017
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Sunstone
Target version:-
Pull request:

Description

When you create a template in Sunstone and select an image, that image is saved in the template in "IMAGE = image_name" format. The problem with this is that if you rename the image, the template will become invalid. It would be a lot better that instead of using IMAGE, IMAGE_ID is used. Because the image ID is unique, that means changing the name won't affect the template, only deleting the image would, but that is fine.

Also IMAGE_UNAME should replaced with IMAGE_UID.

History

#1 Updated by Anton Todorov about 3 years ago

As the core accept both name and ID i think that it should be a configuration option what to use, or when an image is renamed to rename all references to it too?

BR,
Anton

#2 Updated by Strahinja Kustudic about 3 years ago

I don't think it this should be complicated. Using a name instead of the ID has many drawbacks because of renaming of images, etc, while the only drawback of using an ID is that in the advanced view you won't know which image it is until you lookup the ID.

I guess the idea behind supporting both name and ID is so it is easier when a user manually types the template in the advanced view and that she can see exactly why image it is. When doing everything from a web interface that doesn't make sense, because you can easily do everything by ID and just display the name.

#3 Updated by Anton Todorov about 3 years ago

IMO the suggestion is changing the current user experience. And the proper fix should be when renaming an image to rename the relevant references too. Which I agree has other complications...

Also, for example if there are already defined values with names the updated Wizard should not replace them auto-magically :)

BR,
Anton

#4 Updated by Strahinja Kustudic about 3 years ago

If IMAGE is already used and it's not changed when updating a template, it's hard to replace it, because it would need to do a name to ID lookup, which could fail (which probably isn't bad if it reported that). But for new templates, or if you select a different image, there is no downside to replace it with IMAGE_ID.

#5 Updated by Ruben S. Montero about 3 years ago

Yes this is Big-Endian/Little-Endian war.

Actually, the first versions of OpenNebula used IMAGE_ID, but there was a request (backed by many people) to use the name instead, because if you want to update the image and keep the same name the template will not break. For example, remove your "CentOS 7" image and create a new one (different ID), all the templates using "CentOS 7" will still work.

Basically there are people that want to preserve the image and other the name. Probably, as suggested by Anton probably a flag on what the admin prefer is better.

#6 Updated by EOLE Team about 3 years ago

Ruben S. Montero wrote:

Yes this is Big-Endian/Little-Endian war.

Actually, the first versions of OpenNebula used IMAGE_ID, but there was a request (backed by many people) to use the name instead, because if you want to update the image and keep the same name the template will not break. For example, remove your "CentOS 7" image and create a new one (different ID), all the templates using "CentOS 7" will still work.

We were backing the use of NAME instead of ID (#2472) to ease the images update process, the templates reference a fixed name like Debian Stretch amd64.img, then to create a new version of that image:

  1. Create a new version of OS image named with a TIMESTAMP (for example) like Debian Stretch 2017-08-21 amd64.img
  2. Rename the old image to include it's creation time in the image name
  3. Rename the new image to Debian Stretch amd64.img

Then new instances will use the updated image, we don't need to update all templates.

Basically there are people that want to preserve the image and other the name. Probably, as suggested by Anton probably a flag on what the admin prefer is better.

+1

Regards.

Also available in: Atom PDF