Bug #4967

Warn user (or throw error) when VNET does not exist when instantiating

Added by Stefan Kooman over 4 years ago. Updated over 3 years ago.

Status:ClosedStart date:01/05/2017
Priority:NormalDue date:
Assignee:Juan Jose Montiel Cano% Done:

0%

Category:Core & System
Target version:Release 5.4.3
Resolution:worksforme Pull request:
Affected Versions:OpenNebula 5.0, OpenNebula 5.2

Description

If a VM template gets instantiated with references to non-existing VNETS (because they haven been renamed or deleted) the VM instantiates without warning or error. The resulting VM instance will simply be created without the specified nics. Especially when a VM template gets only slightly updated (change to capital, add a dash somewhere) it might not be obvious for the end user (or admin) the referenced VNET changed. In sunstone the name of the VNET is blue (You selected the following network: VNET-NAME-IN-BLUE), this could be changed to RED when VNET is non-existing. Besides that at least a warning should be issued at instantiate time. And perhaps it should not be possible at all to instantiate a template with non-existing resource references and throw an error.

History

#1 Updated by Ruben S. Montero over 3 years ago

  • Category set to Core & System
  • Assignee set to Juan Jose Montiel Cano
  • Target version set to Release 5.4.3

#2 Updated by Juan Jose Montiel Cano over 3 years ago

Hi Stefan.

I'm trying to reproduce this bug on OpenNebula 5.4, but i cant reproduce its, when i try to instantiate a VM with removed nets, OpenNebula returns an error.

Regards!

#3 Updated by Ruben S. Montero over 3 years ago

  • Status changed from Pending to Closed
  • Resolution set to worksforme

Will reopen if needed

Also available in: Atom PDF