Description of problem: The process of unregistered entities reads the OVF xml of a VM/Template and try to map it to a BE and register it to the DB. As part of the registration process we validate the existence of each attribute and on any failure validation we continue/stop the process based on the partial_import flag retrieved from the client. We should unify the process of register unregistered entities to work the same also for vnic profile mapping. The process should work as follow: 1. Validate vnic profile for VM/Template 2. If the validation fails: 2.1 Check if partial_flag is true 2.1.1 If true, add the information about the failing vnic profile to be part of an audit log which will be presented to the user as a warning, and continue the operation without this vnic profile (or nic?) 2.1.2 If false, return a validation error and stop the operation The same functionality can be used as we do for external LUN disks or regular disks Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Should be similar behavior as https://gerrit.ovirt.org/#/c/84864/
If the user sets allow_partial_import, you are asking us to import a VM even though the user supplied a partial vnic mapping. According to ylavi and https://www.ovirt.org/develop/release-management/features/network/import-vm-net-changes/ this is already the case: A missing “target_network_profile” element would mean the target profile is an “empty” profile Please correct me if I misunderstood your request, Maor, because as it stand I do not think we should do anything here.
(In reply to Dan Kenigsberg from comment #2) > If the user sets allow_partial_import, you are asking us to import a VM even > though the user supplied a partial vnic mapping. Not only partial but also if the source vnic mentioned in the OVF does not exists. > > According to ylavi and > https://www.ovirt.org/develop/release-management/features/network/import-vm- > net-changes/ this is already the case: > > A missing “target_network_profile” element would mean the > target profile is an “empty” profile > > Please correct me if I misunderstood your request, Maor, because as it stand > I do not think we should do anything here. What happens if the source and destination mapping does not exists? We want that the VM will still be registered simply without the network, will that be done like this?
(In reply to Maor from comment #3) > > What happens if the source and destination mapping does not exists? I do not understand the question. there is only one mapping - from source network/vnic to target. If a network/vnic exists in source, but is missing from both target and mapping, it would be mapped to Empty. > We want that the VM will still be registered simply without the network, > will that be done like this? Eitan can verify that with his in-the-works test suite.
(In reply to Dan Kenigsberg from comment #4) > (In reply to Maor from comment #3) > > > > What happens if the source and destination mapping does not exists? > > I do not understand the question. there is only one mapping - from source > network/vnic to target. If a network/vnic exists in source, but is missing > from both target and mapping, it would be mapped to Empty. > Sorry for the misunderstanding, I will try to rephrase, The OVF of the entity, which contains the network/vnic, mapped to a destination network/vnic which does not exists in the setup, and also the source network/vnic does not exists as well. This is how the flow should go: In the init phase of the command ---------------------------------- 1. Read the VM source network/vnic from the entity's OVF 2. Search if there is a mapping for the network/vnic in the mapping parameter 3.1 If there is a mapping for that network, check if the target network exists 3.1.1 If target network exists, set the entity Object with that network instead of the source network that was before 3.1.2 If target network does not exists, use the network indicated in the entity's OVF 3.2 If there is no mapping for that network/vnic, leave the network in the OVF as it was before In the validate phase of the command: 1. Validate the network/vnic of the entity, If the the network validation fails for some reason (Not sure what type of validations are done), then: 1.1 If the partial flag is true, print an audit log indicating there was a problem and map the network to empty 1.2. If the partial flag is false, return a validation error message and fail the operation. In the execute phase of the command: 1. Insert the vnic mapping to the DB (No extra validation is needed) This is how the rest of the mapping attributes are being managed today, that is why I thought that it could be great that this behavior will be unified with the rest of the mapping attributes. If you think that the same code implemented today provides this solution then I don't mind this bug to be closed, but I assume it is the network team decision. > > We want that the VM will still be registered simply without the network, > > will that be done like this? > > Eitan can verify that with his in-the-works test suite.
After I talked with Dan and Yaniv, we have decided not to use the allow_partial_map flag. If the entity will not be found it will not be added to the VM/Template
(In reply to Dan Kenigsberg from comment #2) > If the user sets allow_partial_import, you are asking us to import a VM even > though the user supplied a partial vnic mapping. > > According to ylavi and > https://www.ovirt.org/develop/release-management/features/network/import-vm- > net-changes/ this is already the case: > > A missing “target_network_profile” element would mean the > target profile is an “empty” profile Dan, after testing the scenario with the DR it seems that the engine fail the register operation in case the target vnic/network entity is not valid. Correct me if I'm wrong but the desired behavior should be to register the VM with an "empty" profile instead of failing it. In that case, should I re-open this bug?
Re-open the bug (Reason explained in comment 7). We should not block registration of VM/Template in case there are missing target network, the engine should print a warning audit log (and possibly a log) and register the entity with an "empty" profile. p.s. A suggested (future) solution might be to use a proper flag (Same like partial_import) which will indicate whether to be tolerant to missing target network of fail the operation
If we get demand to do this, we will reconsider. For now closing.