Re: [ovirt-devel] [DB] Diffrent UUIDs for inserted data per installation
- Original Message - Hi I am trying to cleanup all the data insertion to the engine DB and make it more general The main drive to that is DB version squashing that was done manually and therefor was error prone ... I know that both storage_pool_id (a.k.a DC) and vds_group_id (a.k.a Cluster) needs to get a different UUID per installation. But I had found that UUIDs are generated per installation for also : table | column/s [cpu_profiles] : id [gluster_services] : id [mac_pools] : id [permissions] : id, object_id They are generated for instance-types. id doesn't have to be different per installation object_id doesn't have to be different either since it points to id of default instance-type that can be static [vm_device]: device_id, vm_id device_id - generated when adding virtio-serial devices. It doesn't have to be different per installation I didn't find where vm_id is generated.. [vm_static] : vm_guid Generated when inserting default instance-types. It doesn't have to be different per installation [vnic_profiles] : id Please let me know if any of the above should be generated using the uuid_generate_v1() function on each installation or we can have static IDs for those. Thanks Eli Mesika ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [engine-devel] Turn Blank template into defaults
On Jan 22, 2015, at 13:15 , Sven Kieske s.kie...@mittwald.de wrote: On 22/01/15 11:28, Tomas Jelinek wrote: Hi All, I have started to work on a new feature[1] which will make it possible to edit the Blank template. The proposal is available on the feature page[2] Any comments are more than welcome, Tomas [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1130174 [2]: http://www.ovirt.org/Features/Blank_to_Defaults Well you can't just rename the blank template to default. You would break any upgrade from 3.5. if you did. At least you could not run any pre 3.6. cluster level vms on this 3.6. engine. it's not really that many changes in fact. existing VMs are not affected as on create VM the fields are being copied to the new VM db entry and the association to the Blank template is no longer needed/useful. Further edits of Default wouldn't affect existing VMs…so I think we can make it work for all cluster levels right away Thanks, michal Is it intended to break compatibility in this release or not? 3.5 cluster level vms (e.g. new created vms) need afaik the blank template. how do you want to handle that? could you instead add this default template just for cluster/dc level 3.6, so just 3.6 vms use it? In general I think this is a much anticipated and needed feature, so I'm looking forward to the 3.6 release! :) -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Adding support for 3.6 in engine database
On 14/01/15 17:27, Alon Bar-Lev wrote: - Original Message - From: Oved Ourfali ov...@redhat.com To: Dan Kenigsberg dan...@redhat.com Cc: engine-de...@ovirt.org devel@ovirt.org Sent: Wednesday, January 14, 2015 5:19:03 PM Subject: Re: [ovirt-devel] Adding support for 3.6 in engine database - Original Message - From: Dan Kenigsberg dan...@redhat.com To: Oved Ourfali ov...@redhat.com Cc: engine-de...@ovirt.org devel@ovirt.org Sent: Wednesday, January 14, 2015 5:03:12 PM Subject: Re: [ovirt-devel] Adding support for 3.6 in engine database On Wed, Jan 14, 2015 at 08:19:00AM -0500, Oved Ourfali wrote: - Original Message - From: Dan Kenigsberg dan...@redhat.com To: Oved Ourfali ov...@redhat.com, fsimo...@redhat.com Cc: engine-de...@ovirt.org devel@ovirt.org Sent: Wednesday, January 14, 2015 3:15:02 PM Subject: Re: [ovirt-devel] Adding support for 3.6 in engine database On Thu, Jan 08, 2015 at 08:46:09AM -0500, Oved Ourfali wrote: - Original Message - From: Eli Mesika emes...@redhat.com To: Lior Vernia lver...@redhat.com, Oved Ourfali oourf...@redhat.com Cc: engine-de...@ovirt.org devel@ovirt.org, Dan Kenigsberg dan...@redhat.com, Yaniv Bronheim ybron...@redhat.com Sent: Thursday, January 8, 2015 3:41:31 PM Subject: Re: [ovirt-devel] Adding support for 3.6 in engine database - Original Message - From: Lior Vernia lver...@redhat.com To: Eli Mesika emes...@redhat.com Cc: engine-de...@ovirt.org devel@ovirt.org, Dan Kenigsberg dan...@redhat.com, Yaniv Bronheim ybron...@redhat.com Sent: Thursday, January 8, 2015 3:08:24 PM Subject: Re: [ovirt-devel] Adding support for 3.6 in engine database Tried to work with it, and noticed that: 1. The engine doesn't list 4.17 as a supported vdsm version. 2. 4.17 vdsm doesn't report 3.6 as a supported engine version. This basically means that no host could be operational in a 3.6 cluster, as to my understanding 4.17 is exactly the version supporting 3.6 functionality. May I send a fix for (1), or is there any argument against? And who could take care of (2)? I had understood deom Oved that this is 4.16 see patch http://gerrit.ovirt.org/#/c/36511/ Oved ??? I don't know when we should add 4.17. I remember there is some policy for that. Dan? Yes, there is. Vdsm would like to declare its support of clusterLevel 3.6 only when it actually does. This is not yet the case, as we are not yet in 3.6 feature freeze (heck, we're not yet in feature definition). To test cluster level 3.6 on the master branch, someone has to lie. It may be Vdsm (by claiming that it supports 3.6 while it does not) or Engine (by allowing vdsm 4.17 into cluster 3.6, even though it does not). I prefer the latter, as the Engine-side hack is eaiser to undo on a distributed system. If today's Vdsm claims that it already support 3.6, future Engines would add it to their cluster, only to find that random APIs fails. If the hack is Engine-side, it would be gone when 3.6 reaches feature freeze. We don't have a mechanism to allow specific version of VDSM to a specific cluster level. For this we only rely on the reported supported cluster levels. I know. I'm asking Engine to add it. The logic in the engine is complex and confusing enough, without adding any other configuration to it, so I prefer to leave it as is. I don't see why we can't add the cluster levels to the supported VDSM cluster levels, as we didn't release any official VDSM version yet, so what's the issue with that? The fact that engine master has 3.6 cluster level doesn't mean it is supported either. It will be once 3.6 is released. this is old discussion... if master work toward a release or version is determine near release. there are two policies in our project, one for vdsm - determine versions near release, and the other is to all other components which is working toward a release. I believe that working toward a release is a better approach especially when components are a coupled. The current state, where merged code can't be used, is definitely out of the question. Dan - sounds like Oved is against adding this temporary code (and you can understand why), and that Alon also supports early reporting of version compatibility. How strongly do you feel about your position? ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ovirt-users] [ANN] oVirt 3.5.1 Final Release is now available
- Original Message - From: Sandro Bonazzola sbona...@redhat.com To: annou...@ovirt.org, us...@ovirt.org, devel@ovirt.org Sent: Wednesday, January 21, 2015 6:09:45 PM Subject: [ovirt-users] [ANN] oVirt 3.5.1 Final Release is now available -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The oVirt team is pleased to announce that the oVirt 3.5.1 Final Release is now available as of Jan 21st 2015. The release candidate is available now for Fedora 20, Red Hat Enterprise Linux 6.6, CentOS 6.6, (or similar) and Red Hat Enterprise Linux 7, CentOS 7 (or similar). This release of oVirt includes numerous bug fixes. See the release notes [1] for a list of the new features and bugs fixed. Please refer to release notes [1] for Installation / Upgrade instructions. A new oVirt Live and oVirt Node ISO will be available soon as well[2]. Please note that mirrors[3] may need usually one day before being synchronized. Please refer to the release notes for known issues in this release. [1] http://www.ovirt.org/OVirt_3.5.1_Release_Notes [2] http://resources.ovirt.org/pub/ovirt-3.5/iso/ ovirt-live-el6-3.5.1.iso is now there. -- Didi ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] [engine-devel] Turn Blank template into defaults
Hi All, I have started to work on a new feature[1] which will make it possible to edit the Blank template. The proposal is available on the feature page[2] Any comments are more than welcome, Tomas [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1130174 [2]: http://www.ovirt.org/Features/Blank_to_Defaults ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [Spice-devel] spice proxy support in govirt
On Thu, Jan 15, 2015 at 02:04:37PM +0100, Christophe Fergeau wrote: I quickly cooked/compile-tested the attached patch, if you have time to test it, let me know how it works, otherwise I'll get back to that later (need to get lot of email under control first ;) Christophe diff --git a/govirt/ovirt-vm-display.c b/govirt/ovirt-vm-display.c index a8a0942..0a8adc6 100644 --- a/govirt/ovirt-vm-display.c +++ b/govirt/ovirt-vm-display.c @@ -141,6 +146,9 @@ static void ovirt_vm_display_set_property(GObject *object, case PROP_ALLOW_OVERRIDE: display-priv-allow_override = g_value_get_boolean(value); break; +case PROP_PROXY_URL: +g_free(display-priv-proxy_url); +display-priv-proxy_url = g_value_dup_string(value); Missing break; here Apart from this, this is working fine, I've pushed it upstream: https://git.gnome.org/browse/libgovirt/commit/?id=e2f4e6ae0975b24d4d4cb521ff1a2948e91af0e3 Christophe pgpt7JEElUH8f.pgp Description: PGP signature ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
