Re: [Engine-devel] [oVirt 3.3 Localization Question #6] Up and Down in CommonApplicationConstants
Hi Yuko, this are VM statuses: up: vm is running down: vm is not running Tomas - Original Message - From: Yuko Katabami ykata...@redhat.com To: engine-devel@ovirt.org Sent: Friday, August 2, 2013 6:33:32 AM Subject: [Engine-devel] [oVirt 3.3 Localization Question #6] Up and Down in CommonApplicationConstants Hi all, I have another question, I would like to ask for your help. File: CommonApplicationConstants Resource IDs: up and down String: Up and Down Question: Could anyone tell me how (and where) these newly added strings are used? Resource IDs only state down and up, which does not really help. I would like to know if these are referring to the status, or for moving an item up and down in a list. Thank you. Yuko -- Regards, Yuko Katabami (方波見裕子) Technical Translator II NAATI Accredited Professional Translator (English into Japanese) #28138 RHCSA #111-119-244 Mobile: +61 415 847 352 Email: ykata...@redhat.com Red Hat, Asia-Pacific Pty Ltd Level 1, 193 North Quay Brisbane 4000 Office: +61 7 3514 8100 Fax: +61 7 3514 8199 Website: www.redhat.com Facebook: Red Hat APAC | Red Hat Japan | Red Hat Korea | JBoss APAC Twitter: Red Hat APAC | Red Hat ANZ LinkedIn: Red Hat APAC | JBoss APAC ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] failed to add host into cluster
Hi, Failed to add a node into cluster. I saw follow hints, but still don't know how to fix it. OS is fedora 19 both for node and engine, anyone can help me? Host *** does not comply with the cluster *** emulated machines. The Hosts emulated machines are clipper,none and the cluster is [rhel6.4.0, pc-1.0]} Best Regards, Dave Chen smime.p7s Description: S/MIME cryptographic signature ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [oVirt 3.3 Localization Question #6] Up and Down in CommonApplicationConstants
Thank you Tomas for your prompt response. I share this info with other translators and we will translate these strings accordingly. Kind regards, Yuko On 08/02/2013 04:03 PM, Tomas Jelinek wrote: Hi Yuko, this are VM statuses: up: vm is running down: vm is not running Tomas - Original Message - From: "Yuko Katabami" ykata...@redhat.com To: engine-devel@ovirt.org Sent: Friday, August 2, 2013 6:33:32 AM Subject: [Engine-devel] [oVirt 3.3 Localization Question #6] "Up" and "Down" in CommonApplicationConstants Hi all, I have another question, I would like to ask for your help. File: CommonApplicationConstants Resource IDs: "up" and "down " String: "Up" and "Down" Question: Could anyone tell me how (and where) these newly added strings are used? Resource IDs only state "down" and "up", which does not really help. I would like to know if these are referring to the status, or for moving an item up and down in a list. Thank you. Yuko -- Regards, Yuko Katabami (方波見裕子) Technical Translator II NAATI Accredited Professional Translator (English into Japanese) #28138 RHCSA #111-119-244 Mobile: +61 415 847 352 Email: ykata...@redhat.com Red Hat, Asia-Pacific Pty Ltd Level 1, 193 North Quay Brisbane 4000 Office: +61 7 3514 8100 Fax: +61 7 3514 8199 Website: www.redhat.com Facebook: Red Hat APAC | Red Hat Japan | Red Hat Korea | JBoss APAC Twitter: Red Hat APAC | Red Hat ANZ LinkedIn: Red Hat APAC | JBoss APAC ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel -- Regards, Yuko Katabami (方波見裕子) Technical Translator II NAATI Accredited Professional Translator (English into Japanese) #28138 RHCSA #111-119-244 Mobile: +61 415 847 352 Email: ykata...@redhat.com Red Hat, Asia-Pacific Pty Ltd Level 1, 193 North Quay Brisbane 4000 Office: +61 7 3514 8100 Fax: +61 7 3514 8199 Website: www.redhat.com Facebook: Red Hat APAC | Red Hat Japan | Red Hat Korea | JBoss APAC Twitter: Red Hat APAC | Red Hat ANZ LinkedIn: Red Hat APAC | JBoss APAC ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Join us in a deep dive into the oVirt-Neutron integration
On 08/02/2013 08:14 AM, Deepak C Shetty wrote: Is it possible to share the slide deck for this pls ? thanx, deepak ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel its in http://www.ovirt.org/OVirt_3.3_release_notes ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] server/api/ full_version tag stability
On 08/01/2013 11:27 AM, Alon Bar-Lev wrote: - Original Message - From: Antoni Segura Puimedon asegu...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Thursday, August 1, 2013 11:24:18 AM Subject: [Engine-devel] server/api/ full_version tag stability Hello list, In order to smarten up the ovirt-node registration flow I will ask the engine via rest API for it's version number, so that I can take decisions about capabilities for networking. I found that https:/server/api/ provides an xml document with a full_version tag that suits my purposes and I wanted to make sure that the stability of such element can be depended upon by asking you about it. IMHO, it could be nice instead that we would have an api endpoint (if it is not there and I missed it) that would provide capability tags information such as: bridgeless_nets, vm_live_snapshot, etc. It also should be anonymous API. iirc, the rest api doesn't support yet anonymous access. i think the api should allow getting the version anonymously. other possible places are the registration servlet or the health servlet, both anonymous today. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] direct manipulation of libvirt
A broad question here, perhaps not a possibility but I figured I would toss it out there anyway. VDSM is great at what it does, however there are those times when direct manipulation of libvirt or libvirt VM configuration would be very handy. The safe defaults and tested VM configurations that VDSM/ovirt provides are great. However at times it would be nice to simply connect to a hypervisor managed by ovirt/vdsm and make a couple changes to a VM (via virt-manager or directly via virsh). This could be enabling a new feature that has made it's way into QEMU/libvirt/KVM or tweaking a VM configuration for whatever reason. Now there is nothing stopping someone from doing this now either directly or via VDSM hooks. Hooks are a pain along with the custom properties to jack them into engine. Direct manipulation of libvirt since it has been upstarted by vdsm results in an unhappy VDSM/engine. Thoughts? - DHC ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
