Leonardo Bianconi has posted comments on this change.
Change subject: core, engine, webadmin: Initial support for alternative
architectures
......................................................................
Patch Set 5:
(3 comments)
....................................................
File
backend/manager/modules/dal/src/main/java/org/ovirt/engine/core/dao/VdsGroupDAODbFacadeImpl.java
Line 210:
entity.setClusterPolicyName(rs.getString("cluster_policy_name"));
Line 211:
entity.setClusterPolicyProperties(SerializationFactory.getDeserializer()
Line 212:
.deserializeOrCreateNew(rs.getString("cluster_policy_custom_properties"),
LinkedHashMap.class));
Line 213:
entity.setEnableBallooning(rs.getBoolean("enable_balloon"));
Line 214:
entity.setArchitecture(ArchitectureType.forValue(rs.getInt("architecture")));
Initially we have done saving the enum name, but we changed due the search,
which needs an enum that implements an Identifiable and the data base value
need to be the ordinal, to reuse the class EnumValueAutoCompleter.
Line 215: return entity;
Line 216: }
Line 217: }
Line 218:
....................................................
File
backend/manager/modules/utils/src/main/java/org/ovirt/engine/core/utils/ovf/OvfTemplateReader.java
Line 46:
_vmTemplate.setOsId(osRepository.getOsIdByUniqueName(node.InnerText));
Line 47: }
Line 48:
Line 49: // Workaround until the support for OVF on POWER is implemented
Line 50: _vmTemplate.setArchitecture(ArchitectureType.x86_64);
I'm agree on "documenting" it during the export, but still need the
architecture when importing, because on this case, we need it to check in which
cluster this template can be imported, so we are using it. After all, this
architecture will be the same architecture of the cluster.
Line 51: }
Line 52:
Line 53: @Override
Line 54: protected void readHardwareSection(XmlNode section) {
....................................................
File packaging/dbscripts/upgrade/03_03_0900_add_architecture_name_column.sql
Line 4: -- Existent clusters with cpu_name are x86_64, since alternative
architectures are introduced after this upgrade
Line 5: UPDATE vds_groups SET architecture = 1 where cpu_name is not NULL and
architecture = 0;
Line 6:
Line 7: -- Update clusters
Line 8: create or replace FUNCTION __temp_update_vds_group()
The update above should have been removed, since the procedure bellow does the
job. We are using the procedure because there is a corner case, discussed on
the e-mail list. It's about the cluster without processor name, which need to
be setted to x86_64 or to undefined based on its VMs. I will remove the update
above, ok?
Line 9: returns void
Line 10: AS $procedure$
Line 11: declare
Line 12: r vds_groups%rowtype;
--
To view, visit http://gerrit.ovirt.org/18938
To unsubscribe, visit http://gerrit.ovirt.org/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: I1ecd642e2bc05067d55884c948bdaeb6e7838c26
Gerrit-PatchSet: 5
Gerrit-Project: ovirt-engine
Gerrit-Branch: master
Gerrit-Owner: Vitor de Lima <vitor.l...@eldorado.org.br>
Gerrit-Reviewer: Gustavo Frederico Temple Pedrosa
<gustavo.pedr...@eldorado.org.br>
Gerrit-Reviewer: Itamar Heim <ih...@redhat.com>
Gerrit-Reviewer: Leonardo Bianconi <leonardo.bianc...@eldorado.org.br>
Gerrit-Reviewer: Michael Pasternak <mpast...@redhat.com>
Gerrit-Reviewer: Michal Skrivanek <michal.skriva...@redhat.com>
Gerrit-Reviewer: Omer Frenkel <ofren...@redhat.com>
Gerrit-Reviewer: Roy Golan <rgo...@redhat.com>
Gerrit-Reviewer: Tomas Jelinek <tjeli...@redhat.com>
Gerrit-Reviewer: oVirt Jenkins CI Server
Gerrit-HasComments: Yes
_______________________________________________
Engine-patches mailing list
Engine-patches@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-patches
