From dfediuck at redhat.com Tue May 1 07:30:34 2012 From: dfediuck at redhat.com (Doron Fediuck) Date: Tue, 01 May 2012 10:30:34 +0300 Subject: [Engine-devel] [vdsm] vdsm on openSuSE In-Reply-To: <4F9EBC9C.2020201@redhat.com> References: <201204301337.32798.sascha.littel@aiges.de> <4F9EA578.9020201@redhat.com> <201204301745.59783.sascha.littel@aiges.de> <4F9EBC9C.2020201@redhat.com> Message-ID: <4F9F911A.3040302@redhat.com> On 30/04/12 19:23, Itamar Heim wrote: > On 04/30/2012 06:45 PM, Sascha Littel wrote: >> Am Montag, 30. April 2012, 16:45:12 schrieben Sie: >>> Hi Sasha, >>> This may be an issue of SSH authentication method. >>> Can you please check you SSH server in the host- >>> Password auth should be password and not Keyboard-interactive. >>> This may lead to SSH auth failure as you engine log indicates. >> Thanks dude this was the hint I need. I changed the PasswordAuthentication in >> /etc/ssh/sshd_config. Now I can add the vdsm into the oVirt engine host. Now >> the real work can beginn. > > Doron - can we catch this error and give this hint to users as something worth checking? > (added engine-devel, as this extends to the engine side). AFAICT, we get auth failure, with no reason. In order to handle it we can go in to ways (need to decide)- 1. Add the keyboard-interactive auth to Mina SSHD. There's a guy who added it[a] and we may try and ask for hints from him. I know that patches are welcomed there as well ;) 2. Try to diagnose the failure we get, or scan Mina's err / debug stream. I suspect we should be able to see something like: debug1: Authentications that can continue: password,publickey ... debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password So if server does not report 'password' as an option we could give a better auth-failure message. It will be nice if someone from our community could pick this up, and if not this would be a nice feature for one of the coming versions. [a] http://mail-archives.apache.org/mod_mbox/mina-dev/201112.mbox/%3CCACPdTxMmwEQtq+As+fQzwPGXcXdAY4HZxk0jARVCzkYnTFw2VA at mail.gmail.com%3E >>> >>>> Am Montag, 30. April 2012, 13:09:25 schrieben Sie: >>>>> On 04/30/2012 02:07 PM, Sascha Littel wrote: >>>>>> Am Montag, 30. April 2012, 05:04:09 schrieben Sie: >>>>>>> On 04/29/2012 10:24 PM, S. Littel wrote: >>>>>>>> Hi everybody, I'm working currently on a running version of vdsm >>>>>>>> 4.9.1 for openSuSE 11.3. I'm changing many lines in the start/stop >>>>>>>> scripts e.g. paths, rc commands. Most of this work looks fine but >>>>>>>> if I try to get a connection between the oVirt engine (runs on a >>>>>>>> openSuSE 12.1) and the vdsm host I get a ssl error. Also after >>>>>>>> setting ssl in vdsm.conf to false and changing the settings in >>>>>>>> oVirt engine database I still get this error. >>>>>>> >>>>>>> which settings are you changing in the db? >>>>>> >>>>>> I changed the seetings in the database with this 2 commands: >>>>> did you restart engine after changing these? >>>> >>>> Yes. I found this page in the oVirt Wiki: >>>> http://ovirt.org/w/index.php?title=OVirt_- >>>> _disable_SSL_in_VDSM&diff=3036&oldid=prev >>>> >>>>>> psql engine -U postgres -c "UPDATE vdc_options set option_value = >>>>>> 'false' where option_name = 'SSLEnabled'" >>>>>> >>>>>> psql engine -U postgres -c "UPDATE vdc_options set option_value = >>>>>> 'false' where option_name = 'UseSecureConnectionWithServers'" >>>>>> >>>>>>> UseSecureConnectionWithServers? >>>>>> >>>>>> Yes. >>>>>> >>>>>>>> So the general question, is there someone working on a openSuSE 11.3 >>>>>>>> or 11.4 version of vdsm? Or someone who has experience how to get >>>>>>>> it work? >>>>>>>> >>>>>>>> Regards >>>>>>>> >>>>>>>> Sascha Littel >>>>>> >>>>>> Here is the failure massage from the vdsm-reg.log I get on the vdsm >>>>>> host: >>>>>> >>>>>> SSLError: [Errno 185090050] _ssl.c:328: error:0B084002:x509 >>>>>> certificate routines:X509_load_cert_crl_file:system lib >>>>>> MainThread::DEBUG::::deployUtil::1413::root::getRemoteFile end. >>>>>> MainThread::DEBUG::::deployUtil::621::root::handleSSHKey start >>>>>> MainThread::ERROR::::deployUtil::614::root::restorecon >>>>>> /root/.ssh/authorized_keys failed >>>>>> >>>>>> And this is the failure message from engine.log on the oVirt engine >>>>>> host: >>>>>> >>>>>> ERROR [org.ovirt.engine.core.utils.hostinstall.MinaInstallWrapper] >>>>>> (http--0.0.0.0-8443-1) Could not connect to server >>>>>> xen007.f1.aiges.net: Failed connecting >>>>>> >>>>>> to xen007.f1.aiges.net using given password! Please verify your >>>>>> password is >>>>>> >>>>>> correct and that the host accepts password-based authentication >>>>>> WARN [org.ovirt.engine.core.bll.AddVdsCommand] (http--0.0.0.0-8443-1) >>>>>> CanDoAction of action AddVds failed. >>>>>> Reasons:VDS_CANNOT_CONNECT_TO_SERVER,VAR__ACTION >>>>>> __ADD,VAR__TYPE__HOST >>>>>> >>>>>> Regards >>>>>> >>>>>> Sascha Littel >> >> > -- /d Never say "OOPS!" always say "Ah, Interesting!" From iheim at redhat.com Tue May 1 08:23:30 2012 From: iheim at redhat.com (Itamar Heim) Date: Tue, 01 May 2012 11:23:30 +0300 Subject: [Engine-devel] [vdsm] vdsm on openSuSE In-Reply-To: <4F9F911A.3040302@redhat.com> References: <201204301337.32798.sascha.littel@aiges.de> <4F9EA578.9020201@redhat.com> <201204301745.59783.sascha.littel@aiges.de> <4F9EBC9C.2020201@redhat.com> <4F9F911A.3040302@redhat.com> Message-ID: <4F9F9D82.5010707@redhat.com> On 05/01/2012 10:30 AM, Doron Fediuck wrote: > On 30/04/12 19:23, Itamar Heim wrote: >> On 04/30/2012 06:45 PM, Sascha Littel wrote: >>> Am Montag, 30. April 2012, 16:45:12 schrieben Sie: >>>> Hi Sasha, >>>> This may be an issue of SSH authentication method. >>>> Can you please check you SSH server in the host- >>>> Password auth should be password and not Keyboard-interactive. >>>> This may lead to SSH auth failure as you engine log indicates. >>> Thanks dude this was the hint I need. I changed the PasswordAuthentication in >>> /etc/ssh/sshd_config. Now I can add the vdsm into the oVirt engine host. Now >>> the real work can beginn. >> >> Doron - can we catch this error and give this hint to users as something worth checking? >> > (added engine-devel, as this extends to the engine side). > > AFAICT, we get auth failure, with no reason. > In order to handle it we can go in to ways (need to decide)- > > 1. Add the keyboard-interactive auth to Mina SSHD. > There's a guy who added it[a] and we may try and ask for hints from him. > I know that patches are welcomed there as well ;) > > 2. Try to diagnose the failure we get, or scan Mina's err / debug stream. > I suspect we should be able to see something like: > > debug1: Authentications that can continue: password,publickey > ... > debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password > > So if server does not report 'password' as an option we could give a better > auth-failure message. > > It will be nice if someone from our community could pick this up, > and if not this would be a nice feature for one of the coming versions. indeed. Sascha - care to document this issue and details in a bug to begin with? thanks, Itamar > > [a] http://mail-archives.apache.org/mod_mbox/mina-dev/201112.mbox/%3CCACPdTxMmwEQtq+As+fQzwPGXcXdAY4HZxk0jARVCzkYnTFw2VA at mail.gmail.com%3E > >>>> >>>>> Am Montag, 30. April 2012, 13:09:25 schrieben Sie: >>>>>> On 04/30/2012 02:07 PM, Sascha Littel wrote: >>>>>>> Am Montag, 30. April 2012, 05:04:09 schrieben Sie: >>>>>>>> On 04/29/2012 10:24 PM, S. Littel wrote: >>>>>>>>> Hi everybody, I'm working currently on a running version of vdsm >>>>>>>>> 4.9.1 for openSuSE 11.3. I'm changing many lines in the start/stop >>>>>>>>> scripts e.g. paths, rc commands. Most of this work looks fine but >>>>>>>>> if I try to get a connection between the oVirt engine (runs on a >>>>>>>>> openSuSE 12.1) and the vdsm host I get a ssl error. Also after >>>>>>>>> setting ssl in vdsm.conf to false and changing the settings in >>>>>>>>> oVirt engine database I still get this error. >>>>>>>> >>>>>>>> which settings are you changing in the db? >>>>>>> >>>>>>> I changed the seetings in the database with this 2 commands: >>>>>> did you restart engine after changing these? >>>>> >>>>> Yes. I found this page in the oVirt Wiki: >>>>> http://ovirt.org/w/index.php?title=OVirt_- >>>>> _disable_SSL_in_VDSM&diff=3036&oldid=prev >>>>> >>>>>>> psql engine -U postgres -c "UPDATE vdc_options set option_value = >>>>>>> 'false' where option_name = 'SSLEnabled'" >>>>>>> >>>>>>> psql engine -U postgres -c "UPDATE vdc_options set option_value = >>>>>>> 'false' where option_name = 'UseSecureConnectionWithServers'" >>>>>>> >>>>>>>> UseSecureConnectionWithServers? >>>>>>> >>>>>>> Yes. >>>>>>> >>>>>>>>> So the general question, is there someone working on a openSuSE 11.3 >>>>>>>>> or 11.4 version of vdsm? Or someone who has experience how to get >>>>>>>>> it work? >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> >>>>>>>>> Sascha Littel >>>>>>> >>>>>>> Here is the failure massage from the vdsm-reg.log I get on the vdsm >>>>>>> host: >>>>>>> >>>>>>> SSLError: [Errno 185090050] _ssl.c:328: error:0B084002:x509 >>>>>>> certificate routines:X509_load_cert_crl_file:system lib >>>>>>> MainThread::DEBUG::::deployUtil::1413::root::getRemoteFile end. >>>>>>> MainThread::DEBUG::::deployUtil::621::root::handleSSHKey start >>>>>>> MainThread::ERROR::::deployUtil::614::root::restorecon >>>>>>> /root/.ssh/authorized_keys failed >>>>>>> >>>>>>> And this is the failure message from engine.log on the oVirt engine >>>>>>> host: >>>>>>> >>>>>>> ERROR [org.ovirt.engine.core.utils.hostinstall.MinaInstallWrapper] >>>>>>> (http--0.0.0.0-8443-1) Could not connect to server >>>>>>> xen007.f1.aiges.net: Failed connecting >>>>>>> >>>>>>> to xen007.f1.aiges.net using given password! Please verify your >>>>>>> password is >>>>>>> >>>>>>> correct and that the host accepts password-based authentication >>>>>>> WARN [org.ovirt.engine.core.bll.AddVdsCommand] (http--0.0.0.0-8443-1) >>>>>>> CanDoAction of action AddVds failed. >>>>>>> Reasons:VDS_CANNOT_CONNECT_TO_SERVER,VAR__ACTION >>>>>>> __ADD,VAR__TYPE__HOST >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> Sascha Littel >>> >>> >> > > From lpeer at redhat.com Tue May 1 12:35:11 2012 From: lpeer at redhat.com (Livnat Peer) Date: Tue, 01 May 2012 15:35:11 +0300 Subject: [Engine-devel] [vdsm] reserve virtio-balloon device created by libvirt In-Reply-To: <4F9F120D.2050201@redhat.com> References: <20120429111909.GE21973@redhat.com> <8e526e7d-9d98-4d20-923e-f259c43a172a@zmail07.collab.prod.int.phx2.redhat.com> <20120429131901.GM21973@redhat.com> <4F9EBE19.2000409@redhat.com> <4F9F120D.2050201@redhat.com> Message-ID: <4F9FD87F.2030306@redhat.com> On 01/05/12 01:28, Dor Laor wrote: > On 04/30/2012 07:30 PM, Itamar Heim wrote: >> On 04/29/2012 04:19 PM, Dan Kenigsberg wrote: >>> On Sun, Apr 29, 2012 at 07:24:52AM -0400, Andrew Cathrow wrote: >>>> >>>> >>>> ----- Original Message ----- >>>>> From: "Dan Kenigsberg" >>>>> To: "Gal Hammer" >>>>> Cc: vdsm-devel at lists.fedorahosted.org >>>>> Sent: Sunday, April 29, 2012 7:19:10 AM >>>>> Subject: Re: [vdsm] reserve virtio-balloon device created by libvirt >>>>> >>>>> On Mon, Apr 23, 2012 at 04:00:55PM +0300, Gal Hammer wrote: >>>>>> On 23/04/2012 12:26, Mark Wu wrote: >>>>>>> Hi guys, >>>>>>> >>>>>>> I saw that an option to create balloon device was added by Gal in >>>>>>> http://gerrit.ovirt.org/1573 >>>>>>> I have a question about it. Why don we preserve the old default >>>>>>> behaviour? I know it's not supported by ovirt-engine now, but I >>>>>>> can't >>>>>>> figure out what will break if it's not disabled explicitly. So do >>>>>>> you >>>>>>> think we can just make use of the balloon device added by libvirt? >>>>>> >>>>>> We didn't change the old behavior. >>>>>> >>>>>> Libvirt creates by default a memory-balloon device, so vdsm >>>>>> defaults >>>>>> was to disable it by adding a "none"-type device. This was done >>>>>> because vdsm didn't include an option to add such device. >>>>>> >>>>>> My patch added an option to create a memory-balloon through vdsm. >>>>>> If >>>>>> the user didn't request to add the device, the behavior is same as >>>>>> before, disabling the memory-balloon. >>>>> >>>>> I feel that it would be best not to flip Vdsm's default at the >>>>> moment, >>>>> even though it is the opposite of libvirt's. I would consider to flip >>>>> them only after your (Mark's) patches are in, tested, and proven >>>>> worthwhile for the common case. >>>>> >>>>> Currently, without any management for the balloon, reserving a guest >>>>> PCI >>>>> device was deemed wasteful. >>>> >>>> On the other side of the fence >>>> - We know that we do need to do ballooning >>>> - In the (next?) release we'll end up adding this support >>>> - There's no harm (see next point) in adding the device now in fact >>>> it saves a config change on upgrade. >>> >>> Well, there is a surprise factor, for someone running a guest generated > > surprise == another minor reason for windows guest to re-activate. > >>> in a previous version. Suddenly, after Vdsm upgrade, it would see an >>> additional device. At the least, I would like Vdsm to have a >>> configurable option to keep the old behavior. > > In qemu we have a compatibility level controlled by -M flag. > VDSM should have a similar compatibility level and defaults shouldn't > normally change in minor releases. > >> >> please take into consideration engine has an algorithm testing max >> number of devices and it should be aware of newly introduced devices by >> vdsm or it will overflow. > > It is good timing to change the algorithm too. IIRC the algorithm has > some hard coded assumptions about qemu. Instead, it would be better to > consult w/ qemu in run time and get the free pci slots number and any > other limits. The engine uses the hard coded limitation for example when adding a disk (using a pci slot) to a VM when the VM is down (no qemu to consult with). > Soon qemu will support pci bridges and this will increase > the number of pci devices and virtio-scsi will insert some other > calculation factor. > The engine will have to adjust to that. >> >>> >>>> - While it takes up a PCI slot it's going to be very, very rare >>>> deployments that will ever see the limit, >>>> libvirt/virtmanager/virt-install has done this forever without seeing >>>> push back. >>> >>> >>> _______________________________________________ >>> vdsm-devel mailing list >>> vdsm-devel at lists.fedorahosted.org >>> https://fedorahosted.org/mailman/listinfo/vdsm-devel >> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From atal at redhat.com Tue May 1 12:58:35 2012 From: atal at redhat.com (avi tal) Date: Tue, 01 May 2012 15:58:35 +0300 Subject: [Engine-devel] Logical network Usages collection problematic approach Message-ID: <4F9FDDFB.5090509@redhat.com> Hi, The new design of logical network 'usages' collection came out a bit problematic or shall i say annoying. The idea is to send the entire collection elements every time a user wants to update a single usage otherwise the missing elements will be automatically removed from the collection. Example: having VM 1. in order to add 'display' usage to the collection i must send 'vm' as well. 2. to remove an element from the collection, i must send the entire collection without the desired element (note: in this case it is only one extra element for every update but in other cases it could be much more) The solution should be: truefalse That way we can send a single usage having different boolean text without including the entire collection elements. From oliel at redhat.com Tue May 1 13:27:00 2012 From: oliel at redhat.com (Ori Liel) Date: Tue, 01 May 2012 09:27:00 -0400 (EDT) Subject: [Engine-devel] Logical network Usages collection problematic approach In-Reply-To: <4F9FDDFB.5090509@redhat.com> Message-ID: <8e0c83f4-4674-4843-8007-a19913706fd3@zmail17.collab.prod.int.phx2.redhat.com> >----- Original Message ----- >From: "avi tal" >To: "Ori Liel" >Cc: "michael pasternak" , engine-devel at ovirt.org >Sent: Tuesday, May 1, 2012 3:58:35 PM >Subject: Logical network Usages collection problematic approach > >Hi, >The new design of logical network 'usages' collection came out a bit >problematic or shall i say annoying. >The idea is to send the entire collection elements every time a user >wants to update a single usage otherwise the missing elements will be >automatically removed from the collection. > >Example: >having VM >1. in order to add 'display' usage to the collection i must send 'vm' as >well. >2. to remove an element from the collection, i must send the entire >collection without the desired element >(note: in this case it is only one extra element for every update but in >other cases it could be much more) > > >The solution should be: >truefalse >That way we can send a single usage having different boolean text >without including the entire collection elements. The question is, how flexible should usages be. If we don't expect more usages to be added in the future, then the hard-coded modelling that you suggest is ok, and I have no problem with it. If more usages are expected to be added, then there's added value to keeping it generic. Ori From shuming at linux.vnet.ibm.com Tue May 1 15:14:40 2012 From: shuming at linux.vnet.ibm.com (Shu Ming) Date: Tue, 01 May 2012 23:14:40 +0800 Subject: [Engine-devel] Updating ovirt engine from 3.0 to the 3.1.0 version In-Reply-To: <36C82119-0445-49AD-98E2-B6A240E73D2F@redhat.com> References: <8faf07bc-015d-439d-b403-8d3d216b58ad@zmail14.collab.prod.int.phx2.redhat.com> <4F9EBC6A.5090803@linux.vnet.ibm.com> <36C82119-0445-49AD-98E2-B6A240E73D2F@redhat.com> Message-ID: <4F9FFDE0.9040800@linux.vnet.ibm.com> Oops. Actually, I deleted the engine.ear.failed and engine.ear was there untouched. Her is the directory hierarchy now in jboss deployment directory. [root at ovirt-engine-112 deployments]# pwd /usr/share/jboss-as-7.1.0.Beta1b/standalone/deployments [root at ovirt-engine-112 deployments]# ls -l total 16 lrwxrwxrwx. 1 root root 34 Apr 28 01:14 engine.ear -> /usr/share/ovirt-engine/engine.ear -rw-r--r--. 1 jboss-as jboss-as 8868 Dec 2 05:10 README.txt lrwxrwxrwx. 1 root root 48 Apr 28 01:14 ROOT.war -> /usr/share/ovirt-engine/resources/jboss/ROOT.war -rw-rw-r--. 1 jboss-as jboss-as 8 Apr 28 01:14 ROOT.war.deployed [root at ovirt-engine-112 deployments]# On 2012-5-1 4:11, Ofer Schreiber wrote: > Please re create the link to engine.ear. > That's the base java code that contains webadmin. > > If it doesn't deploy, create also engine.ear.dodeploy > > Ofer. > > > > On 30 Apr 2012, at 19:23, Shu Ming > wrote: > >> After deleting the engine.ear in >> /usr/share/jboss-as-7.1.0.Beta1b/standalone/deployments, I can access >> the page now. Thanks for you suggestions. >> >> However, when I tried to access "Administrator Portal(no SSL)". The >> following errors were encountered. >> >> >> HTTP Status 404 - /webadmin >> >> ------------------------------------------------------------------------ >> >> *type* Status report >> >> *message* _/webadmin_ >> >> *description* _The requested resource (/webadmin) is not available._ >> >> ------------------------------------------------------------------------ >> >> >> JBoss Web/7.0.3.Final >> >> >> >> On 2012-4-30 15:22, Ofer Schreiber wrote: >>> Looks like something went wrong with the .ear deployment. (already saw such an issue inhttp://lists.ovirt.org/pipermail/engine-devel/2012-January/000483.html) >>> >>> Can you please: >>> 1. Stop JBoss >>> 2. Make sure jboss deployment directory contain a single engine.ear >>> - Remove engine.ear.failed (or similar files if exists) >>> 3. Start JBoss again >>> >>> ----- Original Message ----- >>>> On 2012-4-29 19:33, Ofer Schreiber wrote: >>>>> I need more info about this: >>>>> 1. It looks like a clean install (DB created from scratch). why do >>>>> you call it an upgrade? >>>> Sorry for confusion here. I used engine-cleanup and ran engine-setup >>>> again after the 3.1 RPM package were installed. >>>> >>>>> 2. Do you see any error in JBoss/engine logs? (/var/log/jboss-as >>>>> and /var/log/ovirt-engine usually) >>>> [root at ovirt-engine-112 ~]# cat /var/log/jboss-as/console.log >>>> >>>> 01:15:16,901 INFO [org.jboss.as] (Controller Boot Thread) JBoss AS >>>> 7.1.0.Beta1b "Tesla" started in 2405ms - Started 140 of 203 services >>>> (61 >>>> services are passive or on-demand) >>>> 01:15:17,207 INFO [org.jboss.as.server.deployment.scanner] >>>> (DeploymentScanner-threads - 1) JBAS015014: Re-attempting failed >>>> deployment engine.ear >>>> 01:15:17,431 INFO [org.jboss.as.server.deployment.scanner] >>>> (DeploymentScanner-threads - 1) JBAS015014: Re-attempting failed >>>> deployment ROOT.war >>>> 01:15:17,432 INFO [org.jboss.as.server.deployment.scanner] >>>> (DeploymentScanner-threads - 1) JBAS015003: Found ROOT.war in >>>> deployment >>>> directory. To trigger deployment create a file called >>>> ROOT.war.dodeploy >>>> 01:15:17,432 INFO [org.jboss.as.server.deployment.scanner] >>>> (DeploymentScanner-threads - 1) JBAS015003: Found engine.ear in >>>> deployment directory. To trigger deployment create a file called >>>> engine.ear.dodeploy >>>> 01:15:17,478 ERROR [org.jboss.as.controller] >>>> (DeploymentScanner-threads >>>> - 2) JBAS014612: Operation ("add") failed - address: ([("deployment" >>>> => >>>> "engine.ear")]): java.lang.IllegalStateException: JBAS014666: >>>> Duplicate >>>> resource [("deployment" => "engine.ear")] >>>> at >>>> org.jboss.as.controller.OperationContextImpl.addResource(OperationContextImpl.java:503) >>>> [jboss-as-controller-7.1.0.Beta1b.jar:] >>>> at >>>> org.jboss.as.controller.OperationContextImpl.createResource(OperationContextImpl.java:471) >>>> [jboss-as-controller-7.1.0.Beta1b.jar:] >>>> at >>>> org.jboss.as.server.deployment.DeploymentAddHandler.execute(DeploymentAddHandler.java:170) >>>> .... >>>> >>>> at java.util.concurrent.FutureTask.run(FutureTask.java:166) >>>> [:1.6.0_24] >>>> at >>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165) >>>> [:1.6.0_24] >>>> at >>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266) >>>> [:1.6.0_24] >>>> at >>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) >>>> [:1.6.0_24] >>>> at >>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) >>>> [:1.6.0_24] >>>> at java.lang.Thread.run(Thread.java:679) [:1.6.0_24] >>>> at org.jboss.threads.JBossThread.run(JBossThread.java:122) >>>> [jboss-threads-2.0.0.GA.jar:] >>>> >>>> 01:15:17,482 ERROR [org.jboss.as.server.deployment.scanner] >>>> (DeploymentScanner-threads - 1) JBAS014654: Composite operation was >>>> rolled back >>>> 01:15:17,483 ERROR [org.jboss.as.server.deployment.scanner] >>>> (DeploymentScanner-threads - 1) JBAS014654: Composite operation was >>>> rolled back >>>> 01:15:17,483 ERROR [org.jboss.as.server.deployment.scanner] >>>> (DeploymentScanner-threads - 1) {"JBAS014653: Composite operation >>>> failed >>>> and was rolled back. Steps that failed:" => {"Operation step-1" => >>>> "JBAS014749: Operation handler failed: JBAS014666: Duplicate resource >>>> [(\"deployment\" => \"engine.ear\")]"}} >>>> 01:15:17,483 ERROR [org.jboss.as.server.deployment.scanner] >>>> (DeploymentScanner-threads - 1) undefined >>>> >>>> >>>> >>>>> 3. Any error in the httpd log? >>>> [root at ovirt-engine-112 ~]# cat /var/log/httpd/access_log >>>> 9.181.193.205 - - [30/Apr/2012:00:28:27 +0800] "GET / HTTP/1.0" 404 - >>>> "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.28) >>>> Gecko/20120306 Firefox/3.6.28 ( .NET CLR 3.5.30729)" >>>> 9.181.193.205 - - [30/Apr/2012:00:28:44 +0800] "GET /favicon.ico >>>> HTTP/1.0" 404 - "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; >>>> rv:1.9.2.28) Gecko/20120306 Firefox/3.6.28 ( .NET CLR 3.5.30729)" >>>> 9.181.193.205 - - [30/Apr/2012:00:28:44 +0800] "GET /favicon.ico >>>> HTTP/1.0" 404 - "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; >>>> rv:1.9.2.28) Gecko/20120306 Firefox/3.6.28 ( .NET CLR 3.5.30729)" >>>> 9.181.193.205 - - [30/Apr/2012:00:28:54 +0800] "GET / HTTP/1.0" 404 - >>>> "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.28) >>>> Gecko/20120306 Firefox/3.6.28 ( .NET CLR 3.5.30729)" >>>> 9.181.193.205 - - [30/Apr/2012:00:28:55 +0800] "GET /favicon.ico >>>> HTTP/1.0" 404 - "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; >>>> rv:1.9.2.28) Gecko/20120306 Firefox/3.6.28 ( .NET CLR 3.5.30729)" >>>> [root at ovirt-engine-112 ~]# >>>> >>>> [root at ovirt-engine-112 ~]# cat /var/log/httpd/error_log >>>> [Sun Apr 29 03:36:02 2012] [notice] Digest: generating secret for >>>> digest >>>> authentication ... >>>> [Sun Apr 29 03:36:02 2012] [notice] Digest: done >>>> [Sun Apr 29 03:36:02 2012] [notice] SSL FIPS mode disabled >>>> [Sun Apr 29 03:36:02 2012] [notice] Apache/2.2.22 (Unix) DAV/2 >>>> mod_ssl/2.2.22 OpenSSL/1.0.0h-fips configured -- resuming normal >>>> operations >>>> [root at ovirt-engine-112 ~]# >>>> >>>> >>>> >>>>> 4. What happens if you stop iptables and access your server with >>>>> :8080? >>>> The same as before. >>>> >>>>> Thanks, >>>>> Ofer >>>>> >>>>> ----- Original Message ----- >>>>>> Hi, >>>>>> I built a set of ovirt engine RPM packages from near the >>>>>> latest >>>>>> ovirt >>>>>> engine source code. However, when I try to access the engine >>>>>> server >>>>>> with URL"http://ovirt-engine-112:80", the browser displayed a >>>>>> blank >>>>>> page without http error returned. Any clue about what is going on >>>>>> here? >>>>>> Why didn't the engine administrator home page be shown? >>>>>> >>>>>> >>>>>> And the packages were also installed successfully in my target >>>>>> system, >>>>>> checked this by "rpm -q -a|grep engine". >>>>>> I) upgraded the packages to the 3.1 >>>>>> >>>>>> [root at ovirt-engine-112 ~]# rpm -q -a |grep engine >>>>>> ovirt-engine-restapi-3.1.0_0001-1.8.fc16.x86_64 >>>>>> ovirt-engine-dbscripts-3.1.0_0001-1.8.fc16.x86_64 >>>>>> ovirt-engine-log-collector-3.0.0_0001-1.6.fc16.x86_64 >>>>>> ovirt-engine-genericapi-3.1.0_0001-1.8.fc16.x86_64 >>>>>> ovirt-engine-backend-3.1.0_0001-1.8.fc16.x86_64 >>>>>> ovirt-engine-setup-3.1.0_0001-1.8.fc16.x86_64 >>>>>> ovirt-engine-jbossas-1.2-2.fc16.x86_64 >>>>>> ovirt-engine-jboss-deps-3.1.0_0001-1.8.fc16.x86_64 >>>>>> ovirt-engine-config-3.1.0_0001-1.8.fc16.x86_64 >>>>>> ovirt-engine-3.1.0_0001-1.8.fc16.x86_64 >>>>>> ovirt-engine-webadmin-portal-3.1.0_0001-1.8.fc16.x86_64 >>>>>> ovirt-engine-userportal-3.1.0_0001-1.8.fc16.x86_64 >>>>>> ovirt-engine-tools-common-3.1.0_0001-1.8.fc16.x86_64 >>>>>> ovirt-engine-image-uploader-3.1.0_0001-1.8.fc16.x86_64 >>>>>> ovirt-engine-notification-service-3.1.0_0001-1.8.fc16.x86_64 >>>>>> ovirt-engine-iso-uploader-3.1.0_0001-1.8.fc16.x86_64 >>>>>> gtk2-engines-2.20.2-2.fc15.x86_64 >>>>>> >>>>>> Step II) >>>>>> Then I used "engine-setup" to setup the engine. It seems >>>>>> that >>>>>> everything is ok, see the log below. >>>>>> >>>>>> ------------- >>>>>> [root at ovirt-engine-112 ~]# engine-setup >>>>>> Welcome to oVirt Engine setup utility >>>>>> HTTP Port [80] : >>>>>> HTTPS Port [443] : >>>>>> Host fully qualified domain name, note that this name should be >>>>>> fully >>>>>> resolvable [ovirt-engine-112] : >>>>>> ERROR: domain is not a valid domain name >>>>>> User input failed validation, do you still wish to use it? >>>>>> (yes|no): >>>>>> yes >>>>>> Password for Administrator (admin at internal) : >>>>>> Warning: Weak Password. >>>>>> Confirm password : >>>>>> Organization Name for the Certificate: cstl >>>>>> The default storage type you will be using ['NFS'| 'FC'| 'ISCSI'] >>>>>> [NFS] : >>>>>> Enter DB type for installation ['remote'| 'local'] [local] : >>>>>> Local database password : >>>>>> Warning: Weak Password. >>>>>> Confirm password : >>>>>> Should the installer configure NFS share on this server to be used >>>>>> as >>>>>> an >>>>>> ISO Domain? ['yes'| 'no'] [yes] : >>>>>> Mount point path: /iso-dom >>>>>> ERROR: mount point already exists in /etc/exports >>>>>> Mount point path: /iso-dom >>>>>> Display name for the ISO Domain: iso-domains >>>>>> Firewall ports need to be opened. >>>>>> You can let the installer configure iptables automatically >>>>>> overriding >>>>>> the current configuration. The old configuration will be backed >>>>>> up. >>>>>> Alternately you can configure the firewall later using an example >>>>>> iptables file found under >>>>>> /usr/share/ovirt-engine/conf/iptables.example >>>>>> Configure iptables ? ['yes'| 'no']: yes >>>>>> >>>>>> oVirt Engine will be installed using the following configuration: >>>>>> ================================================================= >>>>>> http-port: 80 >>>>>> https-port: 443 >>>>>> host-fqdn: ovirt-engine-112 >>>>>> auth-pass: ******** >>>>>> org-name: cstl >>>>>> default-dc-type: NFS >>>>>> db-remote-install: local >>>>>> db-local-pass: ******** >>>>>> nfs-mp: /iso-dom >>>>>> iso-domain-name: iso-domains >>>>>> config-nfs: yes >>>>>> override-iptables: yes >>>>>> Proceed with the configuration listed above? (yes|no): yes >>>>>> >>>>>> Installing: >>>>>> Configuring oVirt-engine... [ DONE ] >>>>>> Creating CA... [ DONE ] >>>>>> Editing JBoss Configuration... [ DONE ] >>>>>> Setting Database Configuration... [ DONE ] >>>>>> Setting Database Security... [ DONE ] >>>>>> Creating Database... [ DONE ] >>>>>> Updating the Default Data Center Storage Type... [ DONE ] >>>>>> Editing oVirt Engine Configuration... [ DONE ] >>>>>> Editing Postgresql Configuration... [ DONE ] >>>>>> Configuring the Default ISO Domain... [ DONE ] >>>>>> Configuring Firewall (iptables)... [ DONE ] >>>>>> Starting JBoss Service... [ DONE ] >>>>>> Handling HTTPD... [ DONE ] >>>>>> >>>>>> **** Installation completed successfully ****** >>>>>> >>>>>> (Please allow oVirt Engine a few moments to start up.....) >>>>>> >>>>>> >>>>>> Additional information: >>>>>> * SSL Certificate fingerprint: >>>>>> C6:01:83:93:4B:2C:2A:38:65:C8:49:C9:17:34:FE:4B:1C:10:D5:FF >>>>>> * SSH Public key fingerprint: >>>>>> 69:8c:bd:05:43:17:0a:43:a3:cc:62:7e:f7:be:0c:42 >>>>>> * A default ISO share has been created on this host. >>>>>> If IP based access restrictions are required, please edit >>>>>> /iso-dom >>>>>> entry in /etc/exports >>>>>> * The firewall has been updated, the old iptables configuration >>>>>> file >>>>>> was saved to >>>>>> /usr/share/ovirt-engine/conf/iptables.backup.011513-04282012_2225 >>>>>> * The installation log file is available at: >>>>>> /var/log/ovirt-engine/engine-setup_2012_04_28_01_13_01.log >>>>>> * Please use the user "admin" and password specified in order >>>>>> to >>>>>> login >>>>>> into oVirt Engine >>>>>> * To configure additional users, first configure authentication >>>>>> domains using the 'engine-manage-domains' utility >>>>>> * To access oVirt Engine please go to the following URL: >>>>>> http://ovirt-engine-112:80 >>>>>> [root at ovirt-engine-112 ~]# >>>>>> >>>>>> >>>>>> -- >>>>>> Shu Ming >>>>>> IBM China Systems and Technology Laboratory >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Engine-devel mailing list >>>>>> Engine-devel at ovirt.org >>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>> >>>> -- >>>> Shu Ming >>>> IBM China Systems and Technology Laboratory >>>> >>>> >>>> >> >> >> -- >> Shu Ming >> IBM China Systems and Technology Laboratory -- Shu Ming IBM China Systems and Technology Laboratory -------------- next part -------------- An HTML attachment was scrubbed... URL: From oschreib at redhat.com Tue May 1 16:50:50 2012 From: oschreib at redhat.com (Ofer Schreiber) Date: Tue, 01 May 2012 12:50:50 -0400 (EDT) Subject: [Engine-devel] Updating ovirt engine from 3.0 to the 3.1.0 version In-Reply-To: <4F9FFDE0.9040800@linux.vnet.ibm.com> References: <8faf07bc-015d-439d-b403-8d3d216b58ad@zmail14.collab.prod.int.phx2.redhat.com> <4F9EBC6A.5090803@linux.vnet.ibm.com> <36C82119-0445-49AD-98E2-B6A240E73D2F@redhat.com> <4F9FFDE0.9040800@linux.vnet.ibm.com> Message-ID: <9F20D9B5-DFE3-44BE-836B-DFACCEEB0C3B@redhat.com> What about creating the engine.ear.dodeploy file as suggested earlier? On 1 May 2012, at 18:15, Shu Ming wrote: > Oops. Actually, I deleted the engine.ear.failed and engine.ear was there untouched. > Her is the directory hierarchy now in jboss deployment directory. > > [root at ovirt-engine-112 deployments]# pwd > /usr/share/jboss-as-7.1.0.Beta1b/standalone/deployments > [root at ovirt-engine-112 deployments]# ls -l > total 16 > lrwxrwxrwx. 1 root root 34 Apr 28 01:14 engine.ear -> /usr/share/ovirt-engine/engine.ear > -rw-r--r--. 1 jboss-as jboss-as 8868 Dec 2 05:10 README.txt > lrwxrwxrwx. 1 root root 48 Apr 28 01:14 ROOT.war -> /usr/share/ovirt-engine/resources/jboss/ROOT.war > -rw-rw-r--. 1 jboss-as jboss-as 8 Apr 28 01:14 ROOT.war.deployed > [root at ovirt-engine-112 deployments]# > > > > On 2012-5-1 4:11, Ofer Schreiber wrote: >> >> Please re create the link to engine.ear. >> That's the base java code that contains webadmin. >> >> If it doesn't deploy, create also engine.ear.dodeploy >> >> Ofer. >> >> >> >> On 30 Apr 2012, at 19:23, Shu Ming wrote: >> >>> After deleting the engine.ear in /usr/share/jboss-as-7.1.0.Beta1b/standalone/deployments, I can access the page now. Thanks for you suggestions. >>> >>> However, when I tried to access "Administrator Portal(no SSL)". The following errors were encountered. >>> >>> HTTP Status 404 - /webadmin >>> >>> type Status report >>> >>> message /webadmin >>> >>> description The requested resource (/webadmin) is not available. >>> >>> JBoss Web/7.0.3.Final >>> >>> >>> >>> On 2012-4-30 15:22, Ofer Schreiber wrote: >>>> >>>> Looks like something went wrong with the .ear deployment. (already saw such an issue in http://lists.ovirt.org/pipermail/engine-devel/2012-January/000483.html) >>>> >>>> Can you please: >>>> 1. Stop JBoss >>>> 2. Make sure jboss deployment directory contain a single engine.ear >>>> - Remove engine.ear.failed (or similar files if exists) >>>> 3. Start JBoss again >>>> >>>> ----- Original Message ----- >>>>> On 2012-4-29 19:33, Ofer Schreiber wrote: >>>>>> I need more info about this: >>>>>> 1. It looks like a clean install (DB created from scratch). why do >>>>>> you call it an upgrade? >>>>> Sorry for confusion here. I used engine-cleanup and ran engine-setup >>>>> again after the 3.1 RPM package were installed. >>>>> >>>>>> 2. Do you see any error in JBoss/engine logs? (/var/log/jboss-as >>>>>> and /var/log/ovirt-engine usually) >>>>> [root at ovirt-engine-112 ~]# cat /var/log/jboss-as/console.log >>>>> >>>>> 01:15:16,901 INFO [org.jboss.as] (Controller Boot Thread) JBoss AS >>>>> 7.1.0.Beta1b "Tesla" started in 2405ms - Started 140 of 203 services >>>>> (61 >>>>> services are passive or on-demand) >>>>> 01:15:17,207 INFO [org.jboss.as.server.deployment.scanner] >>>>> (DeploymentScanner-threads - 1) JBAS015014: Re-attempting failed >>>>> deployment engine.ear >>>>> 01:15:17,431 INFO [org.jboss.as.server.deployment.scanner] >>>>> (DeploymentScanner-threads - 1) JBAS015014: Re-attempting failed >>>>> deployment ROOT.war >>>>> 01:15:17,432 INFO [org.jboss.as.server.deployment.scanner] >>>>> (DeploymentScanner-threads - 1) JBAS015003: Found ROOT.war in >>>>> deployment >>>>> directory. To trigger deployment create a file called >>>>> ROOT.war.dodeploy >>>>> 01:15:17,432 INFO [org.jboss.as.server.deployment.scanner] >>>>> (DeploymentScanner-threads - 1) JBAS015003: Found engine.ear in >>>>> deployment directory. To trigger deployment create a file called >>>>> engine.ear.dodeploy >>>>> 01:15:17,478 ERROR [org.jboss.as.controller] >>>>> (DeploymentScanner-threads >>>>> - 2) JBAS014612: Operation ("add") failed - address: ([("deployment" >>>>> => >>>>> "engine.ear")]): java.lang.IllegalStateException: JBAS014666: >>>>> Duplicate >>>>> resource [("deployment" => "engine.ear")] >>>>> at >>>>> org.jboss.as.controller.OperationContextImpl.addResource(OperationContextImpl.java:503) >>>>> [jboss-as-controller-7.1.0.Beta1b.jar:] >>>>> at >>>>> org.jboss.as.controller.OperationContextImpl.createResource(OperationContextImpl.java:471) >>>>> [jboss-as-controller-7.1.0.Beta1b.jar:] >>>>> at >>>>> org.jboss.as.server.deployment.DeploymentAddHandler.execute(DeploymentAddHandler.java:170) >>>>> .... >>>>> >>>>> at java.util.concurrent.FutureTask.run(FutureTask.java:166) >>>>> [:1.6.0_24] >>>>> at >>>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165) >>>>> [:1.6.0_24] >>>>> at >>>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266) >>>>> [:1.6.0_24] >>>>> at >>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) >>>>> [:1.6.0_24] >>>>> at >>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) >>>>> [:1.6.0_24] >>>>> at java.lang.Thread.run(Thread.java:679) [:1.6.0_24] >>>>> at org.jboss.threads.JBossThread.run(JBossThread.java:122) >>>>> [jboss-threads-2.0.0.GA.jar:] >>>>> >>>>> 01:15:17,482 ERROR [org.jboss.as.server.deployment.scanner] >>>>> (DeploymentScanner-threads - 1) JBAS014654: Composite operation was >>>>> rolled back >>>>> 01:15:17,483 ERROR [org.jboss.as.server.deployment.scanner] >>>>> (DeploymentScanner-threads - 1) JBAS014654: Composite operation was >>>>> rolled back >>>>> 01:15:17,483 ERROR [org.jboss.as.server.deployment.scanner] >>>>> (DeploymentScanner-threads - 1) {"JBAS014653: Composite operation >>>>> failed >>>>> and was rolled back. Steps that failed:" => {"Operation step-1" => >>>>> "JBAS014749: Operation handler failed: JBAS014666: Duplicate resource >>>>> [(\"deployment\" => \"engine.ear\")]"}} >>>>> 01:15:17,483 ERROR [org.jboss.as.server.deployment.scanner] >>>>> (DeploymentScanner-threads - 1) undefined >>>>> >>>>> >>>>> >>>>>> 3. Any error in the httpd log? >>>>> [root at ovirt-engine-112 ~]# cat /var/log/httpd/access_log >>>>> 9.181.193.205 - - [30/Apr/2012:00:28:27 +0800] "GET / HTTP/1.0" 404 - >>>>> "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.28) >>>>> Gecko/20120306 Firefox/3.6.28 ( .NET CLR 3.5.30729)" >>>>> 9.181.193.205 - - [30/Apr/2012:00:28:44 +0800] "GET /favicon.ico >>>>> HTTP/1.0" 404 - "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; >>>>> rv:1.9.2.28) Gecko/20120306 Firefox/3.6.28 ( .NET CLR 3.5.30729)" >>>>> 9.181.193.205 - - [30/Apr/2012:00:28:44 +0800] "GET /favicon.ico >>>>> HTTP/1.0" 404 - "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; >>>>> rv:1.9.2.28) Gecko/20120306 Firefox/3.6.28 ( .NET CLR 3.5.30729)" >>>>> 9.181.193.205 - - [30/Apr/2012:00:28:54 +0800] "GET / HTTP/1.0" 404 - >>>>> "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.28) >>>>> Gecko/20120306 Firefox/3.6.28 ( .NET CLR 3.5.30729)" >>>>> 9.181.193.205 - - [30/Apr/2012:00:28:55 +0800] "GET /favicon.ico >>>>> HTTP/1.0" 404 - "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; >>>>> rv:1.9.2.28) Gecko/20120306 Firefox/3.6.28 ( .NET CLR 3.5.30729)" >>>>> [root at ovirt-engine-112 ~]# >>>>> >>>>> [root at ovirt-engine-112 ~]# cat /var/log/httpd/error_log >>>>> [Sun Apr 29 03:36:02 2012] [notice] Digest: generating secret for >>>>> digest >>>>> authentication ... >>>>> [Sun Apr 29 03:36:02 2012] [notice] Digest: done >>>>> [Sun Apr 29 03:36:02 2012] [notice] SSL FIPS mode disabled >>>>> [Sun Apr 29 03:36:02 2012] [notice] Apache/2.2.22 (Unix) DAV/2 >>>>> mod_ssl/2.2.22 OpenSSL/1.0.0h-fips configured -- resuming normal >>>>> operations >>>>> [root at ovirt-engine-112 ~]# >>>>> >>>>> >>>>> >>>>>> 4. What happens if you stop iptables and access your server with >>>>>> :8080? >>>>> The same as before. >>>>> >>>>>> Thanks, >>>>>> Ofer >>>>>> >>>>>> ----- Original Message ----- >>>>>>> Hi, >>>>>>> I built a set of ovirt engine RPM packages from near the >>>>>>> latest >>>>>>> ovirt >>>>>>> engine source code. However, when I try to access the engine >>>>>>> server >>>>>>> with URL "http://ovirt-engine-112:80", the browser displayed a >>>>>>> blank >>>>>>> page without http error returned. Any clue about what is going on >>>>>>> here? >>>>>>> Why didn't the engine administrator home page be shown? >>>>>>> >>>>>>> >>>>>>> And the packages were also installed successfully in my target >>>>>>> system, >>>>>>> checked this by "rpm -q -a|grep engine". >>>>>>> I) upgraded the packages to the 3.1 >>>>>>> >>>>>>> [root at ovirt-engine-112 ~]# rpm -q -a |grep engine >>>>>>> ovirt-engine-restapi-3.1.0_0001-1.8.fc16.x86_64 >>>>>>> ovirt-engine-dbscripts-3.1.0_0001-1.8.fc16.x86_64 >>>>>>> ovirt-engine-log-collector-3.0.0_0001-1.6.fc16.x86_64 >>>>>>> ovirt-engine-genericapi-3.1.0_0001-1.8.fc16.x86_64 >>>>>>> ovirt-engine-backend-3.1.0_0001-1.8.fc16.x86_64 >>>>>>> ovirt-engine-setup-3.1.0_0001-1.8.fc16.x86_64 >>>>>>> ovirt-engine-jbossas-1.2-2.fc16.x86_64 >>>>>>> ovirt-engine-jboss-deps-3.1.0_0001-1.8.fc16.x86_64 >>>>>>> ovirt-engine-config-3.1.0_0001-1.8.fc16.x86_64 >>>>>>> ovirt-engine-3.1.0_0001-1.8.fc16.x86_64 >>>>>>> ovirt-engine-webadmin-portal-3.1.0_0001-1.8.fc16.x86_64 >>>>>>> ovirt-engine-userportal-3.1.0_0001-1.8.fc16.x86_64 >>>>>>> ovirt-engine-tools-common-3.1.0_0001-1.8.fc16.x86_64 >>>>>>> ovirt-engine-image-uploader-3.1.0_0001-1.8.fc16.x86_64 >>>>>>> ovirt-engine-notification-service-3.1.0_0001-1.8.fc16.x86_64 >>>>>>> ovirt-engine-iso-uploader-3.1.0_0001-1.8.fc16.x86_64 >>>>>>> gtk2-engines-2.20.2-2.fc15.x86_64 >>>>>>> >>>>>>> Step II) >>>>>>> Then I used "engine-setup" to setup the engine. It seems >>>>>>> that >>>>>>> everything is ok, see the log below. >>>>>>> >>>>>>> ------------- >>>>>>> [root at ovirt-engine-112 ~]# engine-setup >>>>>>> Welcome to oVirt Engine setup utility >>>>>>> HTTP Port [80] : >>>>>>> HTTPS Port [443] : >>>>>>> Host fully qualified domain name, note that this name should be >>>>>>> fully >>>>>>> resolvable [ovirt-engine-112] : >>>>>>> ERROR: domain is not a valid domain name >>>>>>> User input failed validation, do you still wish to use it? >>>>>>> (yes|no): >>>>>>> yes >>>>>>> Password for Administrator (admin at internal) : >>>>>>> Warning: Weak Password. >>>>>>> Confirm password : >>>>>>> Organization Name for the Certificate: cstl >>>>>>> The default storage type you will be using ['NFS'| 'FC'| 'ISCSI'] >>>>>>> [NFS] : >>>>>>> Enter DB type for installation ['remote'| 'local'] [local] : >>>>>>> Local database password : >>>>>>> Warning: Weak Password. >>>>>>> Confirm password : >>>>>>> Should the installer configure NFS share on this server to be used >>>>>>> as >>>>>>> an >>>>>>> ISO Domain? ['yes'| 'no'] [yes] : >>>>>>> Mount point path: /iso-dom >>>>>>> ERROR: mount point already exists in /etc/exports >>>>>>> Mount point path: /iso-dom >>>>>>> Display name for the ISO Domain: iso-domains >>>>>>> Firewall ports need to be opened. >>>>>>> You can let the installer configure iptables automatically >>>>>>> overriding >>>>>>> the current configuration. The old configuration will be backed >>>>>>> up. >>>>>>> Alternately you can configure the firewall later using an example >>>>>>> iptables file found under >>>>>>> /usr/share/ovirt-engine/conf/iptables.example >>>>>>> Configure iptables ? ['yes'| 'no']: yes >>>>>>> >>>>>>> oVirt Engine will be installed using the following configuration: >>>>>>> ================================================================= >>>>>>> http-port: 80 >>>>>>> https-port: 443 >>>>>>> host-fqdn: ovirt-engine-112 >>>>>>> auth-pass: ******** >>>>>>> org-name: cstl >>>>>>> default-dc-type: NFS >>>>>>> db-remote-install: local >>>>>>> db-local-pass: ******** >>>>>>> nfs-mp: /iso-dom >>>>>>> iso-domain-name: iso-domains >>>>>>> config-nfs: yes >>>>>>> override-iptables: yes >>>>>>> Proceed with the configuration listed above? (yes|no): yes >>>>>>> >>>>>>> Installing: >>>>>>> Configuring oVirt-engine... [ DONE ] >>>>>>> Creating CA... [ DONE ] >>>>>>> Editing JBoss Configuration... [ DONE ] >>>>>>> Setting Database Configuration... [ DONE ] >>>>>>> Setting Database Security... [ DONE ] >>>>>>> Creating Database... [ DONE ] >>>>>>> Updating the Default Data Center Storage Type... [ DONE ] >>>>>>> Editing oVirt Engine Configuration... [ DONE ] >>>>>>> Editing Postgresql Configuration... [ DONE ] >>>>>>> Configuring the Default ISO Domain... [ DONE ] >>>>>>> Configuring Firewall (iptables)... [ DONE ] >>>>>>> Starting JBoss Service... [ DONE ] >>>>>>> Handling HTTPD... [ DONE ] >>>>>>> >>>>>>> **** Installation completed successfully ****** >>>>>>> >>>>>>> (Please allow oVirt Engine a few moments to start up.....) >>>>>>> >>>>>>> >>>>>>> Additional information: >>>>>>> * SSL Certificate fingerprint: >>>>>>> C6:01:83:93:4B:2C:2A:38:65:C8:49:C9:17:34:FE:4B:1C:10:D5:FF >>>>>>> * SSH Public key fingerprint: >>>>>>> 69:8c:bd:05:43:17:0a:43:a3:cc:62:7e:f7:be:0c:42 >>>>>>> * A default ISO share has been created on this host. >>>>>>> If IP based access restrictions are required, please edit >>>>>>> /iso-dom >>>>>>> entry in /etc/exports >>>>>>> * The firewall has been updated, the old iptables configuration >>>>>>> file >>>>>>> was saved to >>>>>>> /usr/share/ovirt-engine/conf/iptables.backup.011513-04282012_2225 >>>>>>> * The installation log file is available at: >>>>>>> /var/log/ovirt-engine/engine-setup_2012_04_28_01_13_01.log >>>>>>> * Please use the user "admin" and password specified in order >>>>>>> to >>>>>>> login >>>>>>> into oVirt Engine >>>>>>> * To configure additional users, first configure authentication >>>>>>> domains using the 'engine-manage-domains' utility >>>>>>> * To access oVirt Engine please go to the following URL: >>>>>>> http://ovirt-engine-112:80 >>>>>>> [root at ovirt-engine-112 ~]# >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Shu Ming >>>>>>> IBM China Systems and Technology Laboratory >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Engine-devel mailing list >>>>>>> Engine-devel at ovirt.org >>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>>> >>>>> -- >>>>> Shu Ming >>>>> IBM China Systems and Technology Laboratory >>>>> >>>>> >>>>> >>> >>> >>> -- >>> Shu Ming >>> IBM China Systems and Technology Laboratory > > > -- > Shu Ming > IBM China Systems and Technology Laboratory -------------- next part -------------- An HTML attachment was scrubbed... URL: From abaron at redhat.com Tue May 1 23:32:31 2012 From: abaron at redhat.com (Ayal Baron) Date: Tue, 01 May 2012 19:32:31 -0400 (EDT) Subject: [Engine-devel] Disk Cloning When Creating a VM via a Template In-Reply-To: <0A1534657992624AACDCA570F1D3E20003C2C846@SACEXCMBX03-PRD.hq.netapp.com> Message-ID: <4f0e54a3-090e-417b-9f2b-1c5df74d477e@zmail13.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > Okay, I'll have a look at master and play around with things a little > bit. Thanks for that insight, Ayal! So, when a VM is cloned from a > template, all disks associated with the template are cloned to go > with the new VM, correct? Could I do something similar with the > floating disks and just clone all of the associated disks from a VM? I think there is some misunderstanding here. A floating disk is a disk which is not associated with any VM, so what are all of the associated disks? The only place where different disks have any relation to each other us within the context of a VM. Note that if you clone while engine thinks you're creating a qcow snapshot then you'd need to handle merge (snapshot delete) differently as well > In the meantime, I'll read up a bit more on Floating Disks on the > feature pages on the wiki. Thanks again! > > -- Dustin > > -----Original Message----- > From: Ayal Baron [mailto:abaron at redhat.com] > Sent: Sunday, April 29, 2012 6:25 AM > To: Livnat Peer > Cc: engine-devel at ovirt.org; Schoenbrun, Dustin > Subject: Re: [Engine-devel] Disk Cloning When Creating a VM via a > Template > > > > ----- Original Message ----- > > On 26/04/12 22:24, Schoenbrun, Dustin wrote: > > > I know that floating disks are coming in the next version of > > > oVirt, > > > but in the interim I want to know internally what the procedure > > > is > > > when a disk is cloned when creating a VM from a template. > > I'm not sure what floating disks have to do with it (it would be > relevant for cloning a single disk, not cloning an entire VM). > For cloning a single disk I believe that floating disk is already > available in master by the way. > > > > > > > > Hi, > > > > Today when creating a VM from template the user can choose the > > provisioning method: > > - It can be 'Thin' in which the engine is taking a snapshot of the > > template disks (running AddVMCommand which executes > > CreateSnapshotFromTemplateCommand) > > - Or 'Clone' which results in cloning the template disks (executes > > AddVmFromTemplateCommand which in turn executes > > CreateCloneOfTemplateCommand) > > For createCloneOfTemplateCommand, other than the VM configuration > being copied, the engine creates copies of all of the template > images (calls moveImage in vdsm per Image). > > > > > > > > Thanks, Livnat > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > From alkaplan at redhat.com Wed May 2 08:58:12 2012 From: alkaplan at redhat.com (Alona Kaplan) Date: Wed, 02 May 2012 04:58:12 -0400 (EDT) Subject: [Engine-devel] Fwd: Checkstyle- Webadmin & userportal localization In-Reply-To: <78cba266-7d09-4e3d-aee8-bfb919e7f010@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <10181293-9ac7-426b-9828-f097d5591cd5@zmail11.collab.prod.int.phx2.redhat.com> Hi, Yesterday some changes were made in oVirt's checkstyle (http://gerrit.ovirt.org/#change,3760) 1. Renaming built-tools to build-tools-root and separating it into two packages: * checksyles- for checkstyle xml files. * ovirt-checkstyle-extension- for adding new (not built-in) checkstyle checks. 2. Adding to the checkstyle.xml a new check- NlsCheck, which fails the compilation in case non-externalized strings appear in the code. [To understand more about the need of this check, see http://gerrit.ovirt.org/#change,3612] >From now on, all strings in the web-admin/user-portal java code should be one of the following: - Externalized (in case the string should be localized) - Have a "//$NON-NLS-N$" comment next to them (in case the string shouldn't be externalized, e.g. HashName of a component) If there is a non externalized string in a web-admin/user-portal java file and there is no "//$NON-NLS-N$" comment next to it, mvn compilation will fail. Note: NlsCheck is currently configured to run only on web-admin/user-portal projects. If you want NlsCheck check to run on another project, please add the following to the configuration of the checkstyle in the project's pom file: runNlsCheck=true Alona. From shuming at linux.vnet.ibm.com Wed May 2 09:04:45 2012 From: shuming at linux.vnet.ibm.com (Shu Ming) Date: Wed, 02 May 2012 17:04:45 +0800 Subject: [Engine-devel] Updating ovirt engine from 3.0 to the 3.1.0 version In-Reply-To: <9F20D9B5-DFE3-44BE-836B-DFACCEEB0C3B@redhat.com> References: <8faf07bc-015d-439d-b403-8d3d216b58ad@zmail14.collab.prod.int.phx2.redhat.com> <4F9EBC6A.5090803@linux.vnet.ibm.com> <36C82119-0445-49AD-98E2-B6A240E73D2F@redhat.com> <4F9FFDE0.9040800@linux.vnet.ibm.com> <9F20D9B5-DFE3-44BE-836B-DFACCEEB0C3B@redhat.com> Message-ID: <4FA0F8AD.4010608@linux.vnet.ibm.com> After "touch engine.ear.doreply" in /usr/share/jboss-as-7.1.0.Beta1b/standalone/deployments, ovirt engine can be accessed now. Thanks for your support. On 2012-5-2 0:50, Ofer Schreiber wrote: > What about creating the engine.ear.dodeploy file as suggested earlier? > > > > On 1 May 2012, at 18:15, Shu Ming > wrote: > >> Oops. Actually, I deleted the engine.ear.failed and engine.ear was >> there untouched. >> Her is the directory hierarchy now in jboss deployment directory. >> >> [root at ovirt-engine-112 deployments]# pwd >> /usr/share/jboss-as-7.1.0.Beta1b/standalone/deployments >> [root at ovirt-engine-112 deployments]# ls -l >> total 16 >> lrwxrwxrwx. 1 root root 34 Apr 28 01:14 engine.ear -> >> /usr/share/ovirt-engine/engine.ear >> -rw-r--r--. 1 jboss-as jboss-as 8868 Dec 2 05:10 README.txt >> lrwxrwxrwx. 1 root root 48 Apr 28 01:14 ROOT.war -> >> /usr/share/ovirt-engine/resources/jboss/ROOT.war >> -rw-rw-r--. 1 jboss-as jboss-as 8 Apr 28 01:14 ROOT.war.deployed >> [root at ovirt-engine-112 deployments]# >> >> >> >> On 2012-5-1 4:11, Ofer Schreiber wrote: >>> Please re create the link to engine.ear. >>> That's the base java code that contains webadmin. >>> >>> If it doesn't deploy, create also engine.ear.dodeploy >>> >>> Ofer. >>> >>> >>> >>> On 30 Apr 2012, at 19:23, Shu Ming >> > wrote: >>> >>>> After deleting the engine.ear in >>>> /usr/share/jboss-as-7.1.0.Beta1b/standalone/deployments, I can >>>> access the page now. Thanks for you suggestions. >>>> >>>> However, when I tried to access "Administrator Portal(no SSL)". >>>> The following errors were encountered. >>>> >>>> >>>> HTTP Status 404 - /webadmin >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> *type* Status report >>>> >>>> *message* _/webadmin_ >>>> >>>> *description* _The requested resource (/webadmin) is not available._ >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> JBoss Web/7.0.3.Final >>>> >>>> >>>> >>>> On 2012-4-30 15:22, Ofer Schreiber wrote: >>>>> Looks like something went wrong with the .ear deployment. (already saw such an issue inhttp://lists.ovirt.org/pipermail/engine-devel/2012-January/000483.html) >>>>> >>>>> Can you please: >>>>> 1. Stop JBoss >>>>> 2. Make sure jboss deployment directory contain a single engine.ear >>>>> - Remove engine.ear.failed (or similar files if exists) >>>>> 3. Start JBoss again >>>>> >>>>> ----- Original Message ----- >>>>>> On 2012-4-29 19:33, Ofer Schreiber wrote: >>>>>>> I need more info about this: >>>>>>> 1. It looks like a clean install (DB created from scratch). why do >>>>>>> you call it an upgrade? >>>>>> Sorry for confusion here. I used engine-cleanup and ran engine-setup >>>>>> again after the 3.1 RPM package were installed. >>>>>> >>>>>>> 2. Do you see any error in JBoss/engine logs? (/var/log/jboss-as >>>>>>> and /var/log/ovirt-engine usually) >>>>>> [root at ovirt-engine-112 ~]# cat /var/log/jboss-as/console.log >>>>>> >>>>>> 01:15:16,901 INFO [org.jboss.as] (Controller Boot Thread) JBoss AS >>>>>> 7.1.0.Beta1b "Tesla" started in 2405ms - Started 140 of 203 services >>>>>> (61 >>>>>> services are passive or on-demand) >>>>>> 01:15:17,207 INFO [org.jboss.as.server.deployment.scanner] >>>>>> (DeploymentScanner-threads - 1) JBAS015014: Re-attempting failed >>>>>> deployment engine.ear >>>>>> 01:15:17,431 INFO [org.jboss.as.server.deployment.scanner] >>>>>> (DeploymentScanner-threads - 1) JBAS015014: Re-attempting failed >>>>>> deployment ROOT.war >>>>>> 01:15:17,432 INFO [org.jboss.as.server.deployment.scanner] >>>>>> (DeploymentScanner-threads - 1) JBAS015003: Found ROOT.war in >>>>>> deployment >>>>>> directory. To trigger deployment create a file called >>>>>> ROOT.war.dodeploy >>>>>> 01:15:17,432 INFO [org.jboss.as.server.deployment.scanner] >>>>>> (DeploymentScanner-threads - 1) JBAS015003: Found engine.ear in >>>>>> deployment directory. To trigger deployment create a file called >>>>>> engine.ear.dodeploy >>>>>> 01:15:17,478 ERROR [org.jboss.as.controller] >>>>>> (DeploymentScanner-threads >>>>>> - 2) JBAS014612: Operation ("add") failed - address: ([("deployment" >>>>>> => >>>>>> "engine.ear")]): java.lang.IllegalStateException: JBAS014666: >>>>>> Duplicate >>>>>> resource [("deployment" => "engine.ear")] >>>>>> at >>>>>> org.jboss.as.controller.OperationContextImpl.addResource(OperationContextImpl.java:503) >>>>>> [jboss-as-controller-7.1.0.Beta1b.jar:] >>>>>> at >>>>>> org.jboss.as.controller.OperationContextImpl.createResource(OperationContextImpl.java:471) >>>>>> [jboss-as-controller-7.1.0.Beta1b.jar:] >>>>>> at >>>>>> org.jboss.as.server.deployment.DeploymentAddHandler.execute(DeploymentAddHandler.java:170) >>>>>> .... >>>>>> >>>>>> at java.util.concurrent.FutureTask.run(FutureTask.java:166) >>>>>> [:1.6.0_24] >>>>>> at >>>>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165) >>>>>> [:1.6.0_24] >>>>>> at >>>>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266) >>>>>> [:1.6.0_24] >>>>>> at >>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) >>>>>> [:1.6.0_24] >>>>>> at >>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) >>>>>> [:1.6.0_24] >>>>>> at java.lang.Thread.run(Thread.java:679) [:1.6.0_24] >>>>>> at org.jboss.threads.JBossThread.run(JBossThread.java:122) >>>>>> [jboss-threads-2.0.0.GA.jar:] >>>>>> >>>>>> 01:15:17,482 ERROR [org.jboss.as.server.deployment.scanner] >>>>>> (DeploymentScanner-threads - 1) JBAS014654: Composite operation was >>>>>> rolled back >>>>>> 01:15:17,483 ERROR [org.jboss.as.server.deployment.scanner] >>>>>> (DeploymentScanner-threads - 1) JBAS014654: Composite operation was >>>>>> rolled back >>>>>> 01:15:17,483 ERROR [org.jboss.as.server.deployment.scanner] >>>>>> (DeploymentScanner-threads - 1) {"JBAS014653: Composite operation >>>>>> failed >>>>>> and was rolled back. Steps that failed:" => {"Operation step-1" => >>>>>> "JBAS014749: Operation handler failed: JBAS014666: Duplicate resource >>>>>> [(\"deployment\" => \"engine.ear\")]"}} >>>>>> 01:15:17,483 ERROR [org.jboss.as.server.deployment.scanner] >>>>>> (DeploymentScanner-threads - 1) undefined >>>>>> >>>>>> >>>>>> >>>>>>> 3. Any error in the httpd log? >>>>>> [root at ovirt-engine-112 ~]# cat /var/log/httpd/access_log >>>>>> 9.181.193.205 - - [30/Apr/2012:00:28:27 +0800] "GET / HTTP/1.0" 404 - >>>>>> "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.28) >>>>>> Gecko/20120306 Firefox/3.6.28 ( .NET CLR 3.5.30729)" >>>>>> 9.181.193.205 - - [30/Apr/2012:00:28:44 +0800] "GET /favicon.ico >>>>>> HTTP/1.0" 404 - "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; >>>>>> rv:1.9.2.28) Gecko/20120306 Firefox/3.6.28 ( .NET CLR 3.5.30729)" >>>>>> 9.181.193.205 - - [30/Apr/2012:00:28:44 +0800] "GET /favicon.ico >>>>>> HTTP/1.0" 404 - "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; >>>>>> rv:1.9.2.28) Gecko/20120306 Firefox/3.6.28 ( .NET CLR 3.5.30729)" >>>>>> 9.181.193.205 - - [30/Apr/2012:00:28:54 +0800] "GET / HTTP/1.0" 404 - >>>>>> "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.28) >>>>>> Gecko/20120306 Firefox/3.6.28 ( .NET CLR 3.5.30729)" >>>>>> 9.181.193.205 - - [30/Apr/2012:00:28:55 +0800] "GET /favicon.ico >>>>>> HTTP/1.0" 404 - "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; >>>>>> rv:1.9.2.28) Gecko/20120306 Firefox/3.6.28 ( .NET CLR 3.5.30729)" >>>>>> [root at ovirt-engine-112 ~]# >>>>>> >>>>>> [root at ovirt-engine-112 ~]# cat /var/log/httpd/error_log >>>>>> [Sun Apr 29 03:36:02 2012] [notice] Digest: generating secret for >>>>>> digest >>>>>> authentication ... >>>>>> [Sun Apr 29 03:36:02 2012] [notice] Digest: done >>>>>> [Sun Apr 29 03:36:02 2012] [notice] SSL FIPS mode disabled >>>>>> [Sun Apr 29 03:36:02 2012] [notice] Apache/2.2.22 (Unix) DAV/2 >>>>>> mod_ssl/2.2.22 OpenSSL/1.0.0h-fips configured -- resuming normal >>>>>> operations >>>>>> [root at ovirt-engine-112 ~]# >>>>>> >>>>>> >>>>>> >>>>>>> 4. What happens if you stop iptables and access your server with >>>>>>> :8080? >>>>>> The same as before. >>>>>> >>>>>>> Thanks, >>>>>>> Ofer >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>>> Hi, >>>>>>>> I built a set of ovirt engine RPM packages from near the >>>>>>>> latest >>>>>>>> ovirt >>>>>>>> engine source code. However, when I try to access the engine >>>>>>>> server >>>>>>>> with URL"http://ovirt-engine-112:80", the browser displayed a >>>>>>>> blank >>>>>>>> page without http error returned. Any clue about what is going on >>>>>>>> here? >>>>>>>> Why didn't the engine administrator home page be shown? >>>>>>>> >>>>>>>> >>>>>>>> And the packages were also installed successfully in my target >>>>>>>> system, >>>>>>>> checked this by "rpm -q -a|grep engine". >>>>>>>> I) upgraded the packages to the 3.1 >>>>>>>> >>>>>>>> [root at ovirt-engine-112 ~]# rpm -q -a |grep engine >>>>>>>> ovirt-engine-restapi-3.1.0_0001-1.8.fc16.x86_64 >>>>>>>> ovirt-engine-dbscripts-3.1.0_0001-1.8.fc16.x86_64 >>>>>>>> ovirt-engine-log-collector-3.0.0_0001-1.6.fc16.x86_64 >>>>>>>> ovirt-engine-genericapi-3.1.0_0001-1.8.fc16.x86_64 >>>>>>>> ovirt-engine-backend-3.1.0_0001-1.8.fc16.x86_64 >>>>>>>> ovirt-engine-setup-3.1.0_0001-1.8.fc16.x86_64 >>>>>>>> ovirt-engine-jbossas-1.2-2.fc16.x86_64 >>>>>>>> ovirt-engine-jboss-deps-3.1.0_0001-1.8.fc16.x86_64 >>>>>>>> ovirt-engine-config-3.1.0_0001-1.8.fc16.x86_64 >>>>>>>> ovirt-engine-3.1.0_0001-1.8.fc16.x86_64 >>>>>>>> ovirt-engine-webadmin-portal-3.1.0_0001-1.8.fc16.x86_64 >>>>>>>> ovirt-engine-userportal-3.1.0_0001-1.8.fc16.x86_64 >>>>>>>> ovirt-engine-tools-common-3.1.0_0001-1.8.fc16.x86_64 >>>>>>>> ovirt-engine-image-uploader-3.1.0_0001-1.8.fc16.x86_64 >>>>>>>> ovirt-engine-notification-service-3.1.0_0001-1.8.fc16.x86_64 >>>>>>>> ovirt-engine-iso-uploader-3.1.0_0001-1.8.fc16.x86_64 >>>>>>>> gtk2-engines-2.20.2-2.fc15.x86_64 >>>>>>>> >>>>>>>> Step II) >>>>>>>> Then I used "engine-setup" to setup the engine. It seems >>>>>>>> that >>>>>>>> everything is ok, see the log below. >>>>>>>> >>>>>>>> ------------- >>>>>>>> [root at ovirt-engine-112 ~]# engine-setup >>>>>>>> Welcome to oVirt Engine setup utility >>>>>>>> HTTP Port [80] : >>>>>>>> HTTPS Port [443] : >>>>>>>> Host fully qualified domain name, note that this name should be >>>>>>>> fully >>>>>>>> resolvable [ovirt-engine-112] : >>>>>>>> ERROR: domain is not a valid domain name >>>>>>>> User input failed validation, do you still wish to use it? >>>>>>>> (yes|no): >>>>>>>> yes >>>>>>>> Password for Administrator (admin at internal) : >>>>>>>> Warning: Weak Password. >>>>>>>> Confirm password : >>>>>>>> Organization Name for the Certificate: cstl >>>>>>>> The default storage type you will be using ['NFS'| 'FC'| 'ISCSI'] >>>>>>>> [NFS] : >>>>>>>> Enter DB type for installation ['remote'| 'local'] [local] : >>>>>>>> Local database password : >>>>>>>> Warning: Weak Password. >>>>>>>> Confirm password : >>>>>>>> Should the installer configure NFS share on this server to be used >>>>>>>> as >>>>>>>> an >>>>>>>> ISO Domain? ['yes'| 'no'] [yes] : >>>>>>>> Mount point path: /iso-dom >>>>>>>> ERROR: mount point already exists in /etc/exports >>>>>>>> Mount point path: /iso-dom >>>>>>>> Display name for the ISO Domain: iso-domains >>>>>>>> Firewall ports need to be opened. >>>>>>>> You can let the installer configure iptables automatically >>>>>>>> overriding >>>>>>>> the current configuration. The old configuration will be backed >>>>>>>> up. >>>>>>>> Alternately you can configure the firewall later using an example >>>>>>>> iptables file found under >>>>>>>> /usr/share/ovirt-engine/conf/iptables.example >>>>>>>> Configure iptables ? ['yes'| 'no']: yes >>>>>>>> >>>>>>>> oVirt Engine will be installed using the following configuration: >>>>>>>> ================================================================= >>>>>>>> http-port: 80 >>>>>>>> https-port: 443 >>>>>>>> host-fqdn: ovirt-engine-112 >>>>>>>> auth-pass: ******** >>>>>>>> org-name: cstl >>>>>>>> default-dc-type: NFS >>>>>>>> db-remote-install: local >>>>>>>> db-local-pass: ******** >>>>>>>> nfs-mp: /iso-dom >>>>>>>> iso-domain-name: iso-domains >>>>>>>> config-nfs: yes >>>>>>>> override-iptables: yes >>>>>>>> Proceed with the configuration listed above? (yes|no): yes >>>>>>>> >>>>>>>> Installing: >>>>>>>> Configuring oVirt-engine... [ DONE ] >>>>>>>> Creating CA... [ DONE ] >>>>>>>> Editing JBoss Configuration... [ DONE ] >>>>>>>> Setting Database Configuration... [ DONE ] >>>>>>>> Setting Database Security... [ DONE ] >>>>>>>> Creating Database... [ DONE ] >>>>>>>> Updating the Default Data Center Storage Type... [ DONE ] >>>>>>>> Editing oVirt Engine Configuration... [ DONE ] >>>>>>>> Editing Postgresql Configuration... [ DONE ] >>>>>>>> Configuring the Default ISO Domain... [ DONE ] >>>>>>>> Configuring Firewall (iptables)... [ DONE ] >>>>>>>> Starting JBoss Service... [ DONE ] >>>>>>>> Handling HTTPD... [ DONE ] >>>>>>>> >>>>>>>> **** Installation completed successfully ****** >>>>>>>> >>>>>>>> (Please allow oVirt Engine a few moments to start up.....) >>>>>>>> >>>>>>>> >>>>>>>> Additional information: >>>>>>>> * SSL Certificate fingerprint: >>>>>>>> C6:01:83:93:4B:2C:2A:38:65:C8:49:C9:17:34:FE:4B:1C:10:D5:FF >>>>>>>> * SSH Public key fingerprint: >>>>>>>> 69:8c:bd:05:43:17:0a:43:a3:cc:62:7e:f7:be:0c:42 >>>>>>>> * A default ISO share has been created on this host. >>>>>>>> If IP based access restrictions are required, please edit >>>>>>>> /iso-dom >>>>>>>> entry in /etc/exports >>>>>>>> * The firewall has been updated, the old iptables configuration >>>>>>>> file >>>>>>>> was saved to >>>>>>>> /usr/share/ovirt-engine/conf/iptables.backup.011513-04282012_2225 >>>>>>>> * The installation log file is available at: >>>>>>>> /var/log/ovirt-engine/engine-setup_2012_04_28_01_13_01.log >>>>>>>> * Please use the user "admin" and password specified in order >>>>>>>> to >>>>>>>> login >>>>>>>> into oVirt Engine >>>>>>>> * To configure additional users, first configure authentication >>>>>>>> domains using the 'engine-manage-domains' utility >>>>>>>> * To access oVirt Engine please go to the following URL: >>>>>>>> http://ovirt-engine-112:80 >>>>>>>> [root at ovirt-engine-112 ~]# >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Shu Ming >>>>>>>> IBM China Systems and Technology Laboratory >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Engine-devel mailing list >>>>>>>> Engine-devel at ovirt.org >>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>>>> >>>>>> -- >>>>>> Shu Ming >>>>>> IBM China Systems and Technology Laboratory >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> -- >>>> Shu Ming >>>> IBM China Systems and Technology Laboratory >> >> >> -- >> Shu Ming >> IBM China Systems and Technology Laboratory -- Shu Ming IBM China Systems and Technology Laboratory -------------- next part -------------- An HTML attachment was scrubbed... URL: From eedri at redhat.com Wed May 2 09:24:32 2012 From: eedri at redhat.com (Eyal Edri) Date: Wed, 02 May 2012 05:24:32 -0400 (EDT) Subject: [Engine-devel] Fwd: Checkstyle- Webadmin & userportal localization In-Reply-To: <10181293-9ac7-426b-9828-f097d5591cd5@zmail11.collab.prod.int.phx2.redhat.com> Message-ID: I believe we can add a checkstyle validation job in jenkins for that using checkstyle plugin[1]. [1] https://wiki.jenkins-ci.org/display/JENKINS/Checkstyle+Plugin It can run on each commit, and soon on each patch sent to gerrit (once we'll boost our Jenkins framework for oVirt). Eyal. ----- Original Message ----- > From: "Alona Kaplan" > To: derez at redhat.com, gchaplik at redhat.com, achub at redhat.com, vszocs at redhat.com, tjelinek at redhat.com > Cc: engine-devel at ovirt.org > Sent: Wednesday, May 2, 2012 11:58:12 AM > Subject: [Engine-devel] Fwd: Checkstyle- Webadmin & userportal localization > > Hi, > > Yesterday some changes were made in oVirt's checkstyle > (http://gerrit.ovirt.org/#change,3760) > > 1. Renaming built-tools to build-tools-root and separating it into > two packages: > * checksyles- for checkstyle xml files. > * ovirt-checkstyle-extension- for adding new (not built-in) > checkstyle checks. > > 2. Adding to the checkstyle.xml a new check- NlsCheck, which fails > the compilation in case non-externalized strings appear in the code. > > [To understand more about the need of this check, see > http://gerrit.ovirt.org/#change,3612] > > From now on, all strings in the web-admin/user-portal java code > should be one of the following: > - Externalized (in case the string should be localized) > - Have a "//$NON-NLS-N$" comment next to them (in case the string > shouldn't be externalized, e.g. HashName of a component) > > If there is a non externalized string in a web-admin/user-portal java > file and > there is no "//$NON-NLS-N$" comment next to it, mvn compilation will > fail. > > Note: NlsCheck is currently configured to run only on > web-admin/user-portal projects. > If you want NlsCheck check to run on another project, please add the > following to the configuration of the checkstyle in the project's > pom file: > runNlsCheck=true > > > Alona. > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From dfediuck at redhat.com Wed May 2 10:19:43 2012 From: dfediuck at redhat.com (Doron Fediuck) Date: Wed, 02 May 2012 13:19:43 +0300 Subject: [Engine-devel] Fwd: Checkstyle- Webadmin & userportal localization In-Reply-To: References: Message-ID: <4FA10A3F.4070307@redhat.com> If you're running simple compilation (build) on each patch, it'll be included. So no need for a special job. On 02/05/12 12:24, Eyal Edri wrote: > I believe we can add a checkstyle validation job in jenkins for that using checkstyle plugin[1]. > > [1] https://wiki.jenkins-ci.org/display/JENKINS/Checkstyle+Plugin > > > It can run on each commit, and soon on each patch sent to gerrit (once we'll boost our Jenkins framework for oVirt). > > Eyal. > > ----- Original Message ----- >> From: "Alona Kaplan" >> To: derez at redhat.com, gchaplik at redhat.com, achub at redhat.com, vszocs at redhat.com, tjelinek at redhat.com >> Cc: engine-devel at ovirt.org >> Sent: Wednesday, May 2, 2012 11:58:12 AM >> Subject: [Engine-devel] Fwd: Checkstyle- Webadmin & userportal localization >> >> Hi, >> >> Yesterday some changes were made in oVirt's checkstyle >> (http://gerrit.ovirt.org/#change,3760) >> >> 1. Renaming built-tools to build-tools-root and separating it into >> two packages: >> * checksyles- for checkstyle xml files. >> * ovirt-checkstyle-extension- for adding new (not built-in) >> checkstyle checks. >> >> 2. Adding to the checkstyle.xml a new check- NlsCheck, which fails >> the compilation in case non-externalized strings appear in the code. >> >> [To understand more about the need of this check, see >> http://gerrit.ovirt.org/#change,3612] >> >> From now on, all strings in the web-admin/user-portal java code >> should be one of the following: >> - Externalized (in case the string should be localized) >> - Have a "//$NON-NLS-N$" comment next to them (in case the string >> shouldn't be externalized, e.g. HashName of a component) >> >> If there is a non externalized string in a web-admin/user-portal java >> file and >> there is no "//$NON-NLS-N$" comment next to it, mvn compilation will >> fail. >> >> Note: NlsCheck is currently configured to run only on >> web-admin/user-portal projects. >> If you want NlsCheck check to run on another project, please add the >> following to the configuration of the checkstyle in the project's >> pom file: >> runNlsCheck=true >> >> >> Alona. -- /d "Common sense is not so common." --Voltaire, Dictionnaire Philosophique (1764) From eglynn at redhat.com Wed May 2 14:28:27 2012 From: eglynn at redhat.com (Eoghan Glynn) Date: Wed, 02 May 2012 10:28:27 -0400 (EDT) Subject: [Engine-devel] Logical network Usages collection problematic approach In-Reply-To: <4FA034C5.80106@redhat.com> Message-ID: <450e1d76-7925-44b6-8dbb-f7e960567476@zmail11.collab.prod.int.phx2.redhat.com> > The new design of logical network 'usages' collection came out a bit > problematic or shall i say annoying. > The idea is to send the entire collection elements every time a user > wants to update a single usage otherwise the missing elements will be > automatically removed from the collection. > > Example: > having VM > 1. in order to add 'display' usage to the collection i must send 'vm' > as well. > 2. to remove an element from the collection, i must send the entire > collection without the desired element > (note: in this case it is only one extra element for every update but > in other cases it could be much more) Yep, this seems to conflict with the general idiom around the interpretation of missing properties in a PUT representation - i.e. any properties omitted from the representation are ignored and not changed. > The solution should be: > truefalse > That way we can send a single usage having different boolean text > without including the entire collection elements. I wonder would a POST/DELETE idiom be more natural, if the individual usages would be pressed into service as a psuedo-OID, e.g: POST .../networks/network_id/usages HTTP/1.1 201 Created Location: .../networks/network_id/usages/VM -- GET .../networks/network_id/usages HTTP/1.1 200 OK Location: .../networks/network_id/usages/VM -- POST .../networks/network_id/usages HTTP/1.1 201 Created Location: .../networks/network_id/usages/display -- GET .../networks/network_id/usages HTTP/1.1 200 OK -- DELETE .../networks/network_id/usages/VM 204 No Content -- GET .../networks/network_id/usages HTTP/1.1 200 OK So from each usage would appear like a first class resource from the perspective of the creation/deletion idiom. If the client providing the ID is considered inconsistent, this could be a "name" child element instead, e.g.: POST .../networks/network_id/usages HTTP/1.1 display 201 Created Location: .../networks/network_id/usages/display display Cheers, Eoghan From oliel at redhat.com Wed May 2 15:25:35 2012 From: oliel at redhat.com (Ori Liel) Date: Wed, 02 May 2012 11:25:35 -0400 (EDT) Subject: [Engine-devel] Logical network Usages collection problematic approach In-Reply-To: <450e1d76-7925-44b6-8dbb-f7e960567476@zmail11.collab.prod.int.phx2.redhat.com> Message-ID: <00ca9808-bfaa-42bd-8d67-304dcd73da05@zmail17.collab.prod.int.phx2.redhat.com> > > >> The new design of logical network 'usages' collection came out a bit >> problematic or shall i say annoying. >> The idea is to send the entire collection elements every time a user >> wants to update a single usage otherwise the missing elements will be >> automatically removed from the collection. >> >> Example: >> having VM >> 1. in order to add 'display' usage to the collection i must send 'vm' >> as well. >> 2. to remove an element from the collection, i must send the entire >> collection without the desired element >> (note: in this case it is only one extra element for every update but >> in other cases it could be much more) > > >Yep, this seems to conflict with the general idiom around the >interpretation of missing properties in a PUT representation - >i.e. any properties omitted from the representation are ignored >and not changed. > **I'm going to explain the current modelling; this does not mean I object to other modellings** In the current modelling, usages are a non-trivial collection within a Network, but they are not business entities, and thus do not have their own 'context' (i.e, there's no: .../networks/{network:id}/usages). This is not new to our API; VM Custom Properties behave in the same way. If user doesn't pass custom-properties when updating a VM, they are unchanged. But if he passes element, then its contents *replace* the previous context. This means effectively that if an existing custom property isn't there - it will be deleted. I understood from Avi (although I don't think you mentioned it in this mail), that there's a bug, that if the user doesn't pass at all - they will all be deleted. This is off course a bug, and it will be fixed. But if user passes empty then yes, they all will be deleted. > >> The solution should be: >> truefalse >> That way we can send a single usage having different boolean text >> without including the entire collection elements. > > >I wonder would a POST/DELETE idiom be more natural, if the individual >usages would be pressed into service as a psuedo-OID, e.g: > > POST .../networks/network_id/usages HTTP/1.1 > > > 201 Created > Location: .../networks/network_id/usages/VM > > >-- > > GET .../networks/network_id/usages HTTP/1.1 > > 200 OK > Location: .../networks/network_id/usages/VM > > > > >-- > > POST .../networks/network_id/usages HTTP/1.1 > > > 201 Created > Location: .../networks/network_id/usages/display > > >-- > > GET .../networks/network_id/usages HTTP/1.1 > > 200 OK > > > > > >-- > > DELETE .../networks/network_id/usages/VM > > 204 No Content > >-- > > GET .../networks/network_id/usages HTTP/1.1 > > 200 OK > > > > >So from each usage would appear like a first class resource from the >perspective of the creation/deletion idiom. If the client providing >the ID is considered inconsistent, this could be a "name" child >element instead, e.g.: > > POST .../networks/network_id/usages HTTP/1.1 > > display > > > 201 Created > Location: .../networks/network_id/usages/display > > display > > We'd need to develop an infrastructure for generating on-the-fly IDs for internal, non-entity, collections (based on a specified field) - and then correctly following links that contain these IDs. I like it, but it won't be trivial, so the question is - is now the time to do it? Ori. > >Cheers, >Eoghan > From emesika at redhat.com Wed May 2 22:01:45 2012 From: emesika at redhat.com (Eli Mesika) Date: Wed, 02 May 2012 18:01:45 -0400 (EDT) Subject: [Engine-devel] Naming convention in db upgrade script temporary functions In-Reply-To: <7e04cb91-5853-450a-816e-1f0eff65eb27@zmail13.collab.prod.int.phx2.redhat.com> Message-ID: <1e41bf03-8f9f-4e6c-8218-fe5a9c68ec8f@zmail13.collab.prod.int.phx2.redhat.com> Hi >From now on, please use the prefix __temp_ for temporary functions defined in a db upgrade scripts The reasons are 1) Each time that you have to rename your upgrade script after sync with master you have to rename the function as well 2) As a result, may function are pushed with a wrong suffix (for example upgrade 03_01_0950 had a function name suffix of 08200) Since the reason for that numbering was in the first place for avoiding dropping real installed functions, now you will have just to put in a temporary function created in an upgrade script just the prefix "__temp_" Hope that this will make handling upgrade scripts more accurate and less painful. This was documented as well at the oVirt db upgrade wiki page: http://www.ovirt.org/wiki/OVirt-database-upgrade-procedure (see section 1.5 Temporary Functions in Upgrade scripts) From irenab at mellanox.com Thu May 3 09:02:42 2012 From: irenab at mellanox.com (Irena Berezovsky) Date: Thu, 3 May 2012 09:02:42 +0000 Subject: [Engine-devel] oVirt and Quantum In-Reply-To: <4F9E7DB1.1010409@redhat.com> References: <4F9D1AD4.8070503@redhat.com> <4F9E41AE.6030302@redhat.com> <4F9E7DB1.1010409@redhat.com> Message-ID: <9D25E123B44F4A4291F4B5C13DA94E772510FFEA@mtrdag02.mtl.com> Gary, Thank you for a very detailed proposal. I would like to address several issues of the proposed Quantum-oVirt integration. 1. User Interface: Network Management I suggest to consider Logical Network Management to indicate if the Network should be managed by Quantum or not. This may lead to different options that user can specify via UI. It can have a Network Type attribute. Maybe it is a place to consider custom properties piggy-backing. Host management As long as the proposed API is used for viewing interface it's OK. It just should not be required by user to go over each Host and define each interface with type of Fabric he should manage. Maybe it should be some defaults on Cluster level (will work for Homogenous cluster). 2. Back End Network Creation: If not every Host in the cluster has Quantum supporting interface, it should be forbidden to apply VM migrate operation to such Host. This probably should be indicated properly via UI and Backed should not start the migrate process. VM Creation: To be able to extend the basic Quantum API and add some QoS/Port Profile attributes to the port ( like in Cisco plugin). There should be some way in oVirt to map between port uuid (+ network)and VM id. VM Migrate: Even though it's just an initial suggestion, I think that VM migration use case should be elaborated also for 'else' cases. What happens if target Host does not support Quantum? What happens if target host fails to run VM? Another issue is a lack of calls to Quantum. For my understanding (but I can be wrong) in OpenStack it will issue unplug and plug attachment calls. 3. VDSM Host Management: Any suggestion /plans to define a way to write and deploy a Vif plug Driver ( a complimentary part to the Quantum Agent)? Regards, Irena -----Original Message----- From: engine-devel-bounces at ovirt.org [mailto:engine-devel-bounces at ovirt.org] On Behalf Of Gary Kotton Sent: Monday, April 30, 2012 2:56 PM To: dlaor at redhat.com Cc: engine-devel at ovirt.org; users at ovirt.org Subject: Re: [Engine-devel] oVirt and Quantum On 04/30/2012 10:39 AM, Dor Laor wrote: > > Gary, would it be possible to compare the current major api verbs > offered by Quantum vs the ones offered by oVirt? Please look at https://docs.google.com/presentation/d/1cLW88tPw-8z_ANXU2WC8gd4U2k-ACrPnMQbgj5wDLz4/edit#slide=id.p This gives a high level explanation of Quantum and the flows. In short both Quantum and oVirt enable the creation of logical networks. By design Quantum hides the network details from the user. In oVirt the user is able to configure the tags etc. We are in the process of addressing this. > It would be nice to review the length/feature-rich of each and also > the ease of use. In addition to linux bridge (which is what oVirt uses today), Quantum supports Open vSwitch, RYU and Cisco UCS - these are not supported by oVirt at the moment. The RYU and Open vSwitch support OpenFlow > > In addition, what would be the todo items in order to get OVS working > w/ oVirt? Actually not much. In fact this is currently supported with the Quantum integration. There are two parts: 1. The VM vNic management (implemented): i. Create a tap device that has "ethernet" as the the network device ii. Set the device us UP ii. Attach to the integration bridge and configure tags etc. (The Quantum agent does this part) 2. The host management (to be implemented): i. oVirt Engine and VDSM need to indicate which physical network interfaces will use the integration bridge. This can be one or more NICS or a bond (in Quantum this is part of a configuration file). We need to think of a nice way to show this in the GUI. ii. The logic in oVirt engine that "decides" if a Host is "Non Operational" needs to be updated. > Example for Quantum: > http://docs.openstack.org/incubation/openstack-network/developer/quant > um-api-1.0/content/Show_port_Details.html#d6e777 > > Cheers, > Dor > >> >> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel > _______________________________________________ Engine-devel mailing list Engine-devel at ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel From eglynn at redhat.com Thu May 3 10:09:50 2012 From: eglynn at redhat.com (Eoghan Glynn) Date: Thu, 03 May 2012 06:09:50 -0400 (EDT) Subject: [Engine-devel] Logical network Usages collection problematic approach In-Reply-To: <00ca9808-bfaa-42bd-8d67-304dcd73da05@zmail17.collab.prod.int.phx2.redhat.com> Message-ID: <5a958fed-05b1-4ea1-b7d3-a436b9c893e2@zmail11.collab.prod.int.phx2.redhat.com> > >> The new design of logical network 'usages' collection came out a > >> bit > >> problematic or shall i say annoying. > >> The idea is to send the entire collection elements every time a > >> user > >> wants to update a single usage otherwise the missing elements will > >> be > >> automatically removed from the collection. > >> > >> Example: > >> having VM > >> 1. in order to add 'display' usage to the collection i must send > >> 'vm' > >> as well. > >> 2. to remove an element from the collection, i must send the > >> entire > >> collection without the desired element > >> (note: in this case it is only one extra element for every update > >> but > >> in other cases it could be much more) > > > > > >Yep, this seems to conflict with the general idiom around the > >interpretation of missing properties in a PUT representation - > >i.e. any properties omitted from the representation are ignored > >and not changed. > > > > **I'm going to explain the current modelling; this does not mean I > object to other modellings** > > In the current modelling, usages are a non-trivial collection within > a > Network, but they are not business entities, and thus do not have > their > own 'context' (i.e, there's no: .../networks/{network:id}/usages). A-ha, I see. I was thrown by the overloading on the term "collection", which I would have understood as a set of resources that may be addressed as a group. Whereas in fact we're more talking about an aspect of the Network representation that happens to include boolean sub-elements, right? In which case, making this explicit via your suggestion: truefalse would seem reasonable on the face of it. However there's an implementation wrinkle in the type-mapper framework ... I'd understand the PUT below as meaning: "set the VM usage to true, and leave other usages as they are". GET .../networks/{network:id} HTTP/1.1 200 OK ... true -- PUT .../networks/{network:id} HTTP/1.1 true 200 OK ... true true as things currently stand, the type mapper called prior to the UpdateNetwork action being initiated doesn't have access to the *existing* network entity, so it has no way of setting the is_display flag on the mapped entity to match the pre-existing setting. I guess you could work around this by forcing a network lookup *prior* to the update, so that the pre-existing display setting is available, and then pass this entity as a template into the type mapping. > >I wonder would a POST/DELETE idiom be more natural, if the individual > >usages would be pressed into service as a psuedo-OID, e.g: > >[snip] > > > We'd need to develop an infrastructure for generating on-the-fly IDs > for internal, > non-entity, collections (based on a specified field) Well, the idea was to avoid the need for generating on-the-fly OIDs, by reusing the display "name" as the OID. But yes, it would still involve some deviation from the established collection/sub-resource implementation patterns. Cheers, Eoghan From gkotton at redhat.com Thu May 3 12:18:24 2012 From: gkotton at redhat.com (Gary Kotton) Date: Thu, 03 May 2012 15:18:24 +0300 Subject: [Engine-devel] oVirt and Quantum In-Reply-To: <9D25E123B44F4A4291F4B5C13DA94E772510FFEA@mtrdag02.mtl.com> References: <4F9D1AD4.8070503@redhat.com> <4F9E41AE.6030302@redhat.com> <4F9E7DB1.1010409@redhat.com> <9D25E123B44F4A4291F4B5C13DA94E772510FFEA@mtrdag02.mtl.com> Message-ID: <4FA27790.5080308@redhat.com> Hi, Thanks for the input. Please see my inline comments. Thanks Gary On 05/03/2012 12:02 PM, Irena Berezovsky wrote: > Gary, > Thank you for a very detailed proposal. > I would like to address several issues of the proposed Quantum-oVirt integration. > > 1. User Interface: > Network Management > I suggest to consider Logical Network Management to indicate if the Network should be managed by Quantum or not. This may lead to different options that user can specify via UI. It can have a Network Type attribute. Maybe it is a place to consider custom properties piggy-backing. This is an interesting point. I am not sure that the user should be exposed to this. My intentions when writing the integration notes were to try and keep things simple for the user. There are a number of options: - Uniform cluster support - If the UI for the cluster could provide an interface for the network properties then it would be great. If each Host in the cluster has the same characteristics then one configuration could be used for each host - for example the NIC of the integration bridge in the case of OVS plugin. - Non uniform cluster support - in this case each Host will need to be configured separately. Live migration could be challenging - this can and should be done only between hosts with the same networking characteristics. > Host management > As long as the proposed API is used for viewing interface it's OK. It just should not be required by user to go over each Host and define each interface with type of Fabric he should manage. Maybe it should be some defaults on Cluster level (will work for Homogenous cluster). Addressed above. > > 2. Back End > Network Creation: > If not every Host in the cluster has Quantum supporting interface, it should be forbidden to apply VM migrate operation to such Host. This probably should be indicated properly via UI and Backed should not start the migrate process. I also think that this is addressed above. > VM Creation: > To be able to extend the basic Quantum API and add some QoS/Port Profile attributes to the port ( like in Cisco plugin). There should be some way in oVirt to map between port uuid (+ network)and VM id. This is addressed in the wiki. For each VM the oVirt engine should keep the relevant UUID's. "Each of the above is represented by a UUID. oVirt should save all of the UUID's with the relevant artifacts that make use of the information, namely the logical network and the virtual machines. The usage of these will be discussed below." I could describe this more explicitly. > VM Migrate: > Even though it's just an initial suggestion, I think that VM migration use case should be elaborated also for 'else' cases. What happens if target Host does not support Quantum? What happens if target host fails to run VM? Another issue is a lack of calls to Quantum. For my understanding (but I can be wrong) in OpenStack it will issue unplug and plug attachment calls. I agree. The goal here should be VM uptime and connectivity. If the "network" connectivity can be support but in a limited fashion then great - the migration can take place - this should nonetheless only be done when there is no other option. The live migration algorithm may have to be tweaked to support this. > 3. VDSM > Host Management: Any suggestion /plans to define a way to write and deploy a Vif plug Driver ( a complimentary part to the Quantum Agent)? In Quantum the spirit of things is to keep the driver as thin as possible. The Quantum agent that runs on the VDSM host should do most of the work. It would be best if VDSM could provide a "plugin" mechanism that support the following: 1. deviceNameGet - this is due to the fact that the agent knows the device name - in the case of ovs and linux bridge this is done by using the first 11 characters of the attachment UUID. Other plugins may operate in a different manner. 2. vifAdd - this will be called with the MAC address, the VM UUID and maybe additional information 3. vifDelete > Regards, > Irena > -----Original Message----- > From: engine-devel-bounces at ovirt.org [mailto:engine-devel-bounces at ovirt.org] On Behalf Of Gary Kotton > Sent: Monday, April 30, 2012 2:56 PM > To: dlaor at redhat.com > Cc: engine-devel at ovirt.org; users at ovirt.org > Subject: Re: [Engine-devel] oVirt and Quantum > > On 04/30/2012 10:39 AM, Dor Laor wrote: >> Gary, would it be possible to compare the current major api verbs >> offered by Quantum vs the ones offered by oVirt? > Please look at > https://docs.google.com/presentation/d/1cLW88tPw-8z_ANXU2WC8gd4U2k-ACrPnMQbgj5wDLz4/edit#slide=id.p > This gives a high level explanation of Quantum and the flows. In short both Quantum and oVirt enable the creation of logical networks. By design Quantum hides the network details from the user. In oVirt the user is able to configure the tags etc. We are in the process of addressing this. > >> It would be nice to review the length/feature-rich of each and also >> the ease of use. > In addition to linux bridge (which is what oVirt uses today), Quantum supports Open vSwitch, RYU and Cisco UCS - these are not supported by oVirt at the moment. The RYU and Open vSwitch support OpenFlow >> In addition, what would be the todo items in order to get OVS working >> w/ oVirt? > Actually not much. In fact this is currently supported with the Quantum integration. There are two parts: > 1. The VM vNic management (implemented): > i. Create a tap device that has "ethernet" as the the network device > ii. Set the device us UP > ii. Attach to the integration bridge and configure tags etc. (The Quantum agent does this part) > > 2. The host management (to be implemented): > i. oVirt Engine and VDSM need to indicate which physical network interfaces will use the integration bridge. This can be one or more NICS or a bond (in Quantum this is part of a configuration file). We need to think of a nice way to show this in the GUI. > ii. The logic in oVirt engine that "decides" if a Host is "Non Operational" needs to be updated. >> Example for Quantum: >> http://docs.openstack.org/incubation/openstack-network/developer/quant >> um-api-1.0/content/Show_port_Details.html#d6e777 >> >> Cheers, >> Dor >> >>> >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel at ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From oliel at redhat.com Thu May 3 14:24:02 2012 From: oliel at redhat.com (Ori Liel) Date: Thu, 03 May 2012 10:24:02 -0400 (EDT) Subject: [Engine-devel] REST-API: Exposing correlation-ID In-Reply-To: <7678909c-0bb5-47b1-99b8-4a9c89452edd@zmail17.collab.prod.int.phx2.redhat.com> Message-ID: <5f017132-f1da-4f42-b76e-5cf9361dd0c7@zmail17.collab.prod.int.phx2.redhat.com> Correlation-ID feature allows 'tagging' a call to a Backend command with a String ID, and this ID will be appended to all log messages that result from this command. http://www.ovirt.org/wiki/Features/TaskManagerDetailed In REST-API, we would like to enable the user to pass a correlation-ID when he activates actions. I have two questions: 1) what's the name you'd give this parameter? job-id? batch-id? flow-id? command-id? correlation-id??? 2) I've already implemented this as a url parameter. Are there objections? The only viable alternative I see is as an http header, which doesn't feel right. It's not an option to pass it in the XML body, because sometimes there is no body, for example, in DELETE commands. Thanks Ori. From ykaul at redhat.com Thu May 3 14:34:52 2012 From: ykaul at redhat.com (Yaniv Kaul) Date: Thu, 03 May 2012 17:34:52 +0300 Subject: [Engine-devel] REST-API: Exposing correlation-ID In-Reply-To: <5f017132-f1da-4f42-b76e-5cf9361dd0c7@zmail17.collab.prod.int.phx2.redhat.com> References: <5f017132-f1da-4f42-b76e-5cf9361dd0c7@zmail17.collab.prod.int.phx2.redhat.com> Message-ID: <4FA2978C.7060805@redhat.com> On 05/03/2012 05:24 PM, Ori Liel wrote: > Correlation-ID feature allows 'tagging' a call to a Backend command > with a String ID, and this ID will be appended to all log messages > that result from this command. > > http://www.ovirt.org/wiki/Features/TaskManagerDetailed > > In REST-API, we would like to enable the user to pass a correlation-ID > when he activates actions. Makes a more sense to me that the user will get it in the response, rather than setting it by himself. What's the added value of the user setting it (as opposed to the engine, which is already doing it) ? Y. > > I have two questions: > > 1) what's the name you'd give this parameter? job-id? batch-id? > flow-id? command-id? correlation-id??? > > 2) I've already implemented this as a url parameter. Are there objections? > The only viable alternative I see is as an http header, which doesn't feel > right. It's not an option to pass it in the XML body, because sometimes > there is no body, for example, in DELETE commands. > > Thanks > > Ori. > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From shuming at linux.vnet.ibm.com Thu May 3 14:56:18 2012 From: shuming at linux.vnet.ibm.com (Shu Ming) Date: Thu, 03 May 2012 22:56:18 +0800 Subject: [Engine-devel] vds_bootstrap.py 's residency Message-ID: <4FA29C92.1030805@linux.vnet.ibm.com> Hi, I am checking the VDSM and ovirt-engine workspace for "vds_bootstrap.py" file. It was found that vds_bootstrap.py file was in VDSM workspace and was packaged into vdsm-bootstrap rpm package. Also, it was found that in the host installation process, host node will try to get the "vds_bootstrap.py" from the engine server. But "vds_bootstrap.py" is not included in any engine packages. Does that mean we should install vdsm-bootstrap package into engine server? Why not package this file into engine packages instead of vdsm packages? -- Shu Ming IBM China Systems and Technology Laboratory From eglynn at redhat.com Thu May 3 15:15:34 2012 From: eglynn at redhat.com (Eoghan Glynn) Date: Thu, 03 May 2012 11:15:34 -0400 (EDT) Subject: [Engine-devel] REST-API: Exposing correlation-ID In-Reply-To: <5f017132-f1da-4f42-b76e-5cf9361dd0c7@zmail17.collab.prod.int.phx2.redhat.com> Message-ID: <31823c55-c6df-465e-8f05-d5f6e6d8baf6@zmail11.collab.prod.int.phx2.redhat.com> > Correlation-ID feature allows 'tagging' a call to a Backend command > with a String ID, and this ID will be appended to all log messages > that result from this command. > > http://www.ovirt.org/wiki/Features/TaskManagerDetailed > > In REST-API, we would like to enable the user to pass a > correlation-ID > when he activates actions. > > I have two questions: > > 1) what's the name you'd give this parameter? job-id? batch-id? > flow-id? command-id? correlation-id??? > > 2) I've already implemented this as a url parameter. Are there > objections? > The only viable alternative I see is as an http header, which doesn't > feel > right. It's not an option to pass it in the XML body, because > sometimes > there is no body, for example, in DELETE commands. Hi Ori, Is the intent here to allow correlation between multiple backend actions initiated from a single restapi call, or an over-arching correlation across multiple restapi calls? If the former, then I'd agree with Yaniv, just generate the ID internally and return it as a response header. If the latter, then allowing it to be optionally set via a request header, seems more natural to me than a URL parameter because this is additional out-of-band data that aids in log interpretation, as opposed to something directly germane to the interaction with the target resource. Cheers, Eoghan From deepakcs at linux.vnet.ibm.com Thu May 3 15:24:25 2012 From: deepakcs at linux.vnet.ibm.com (Deepak C Shetty) Date: Thu, 03 May 2012 20:54:25 +0530 Subject: [Engine-devel] [vdsm] Storage Device Management in VDSM and oVirt In-Reply-To: <4F97DE7A.2040808@linux.vnet.ibm.com> References: <4F97DE7A.2040808@linux.vnet.ibm.com> Message-ID: <4FA2A329.6060400@linux.vnet.ibm.com> On 04/25/2012 04:52 PM, Deepak C Shetty wrote: > > This seems interesting. > > I am interested in pursuing this further and helping contribute to the > vdsm lsm integration. lsm is still in the early stages, but i feel its > the right time to start influencing it so that vdsm integration can be > smooth. My interest mainly lies in how external storage array can be > integrated into oVirt/VDSM and help oVirt exploit the array offload > features as part of the virtualization stack. > > I didn't find any oVirt wiki page on this topic, tho' there is a old > mailing list thread on vdsm lsm integration, which when read brings up > more issues to discuss :) > How does storage repo engine and possible vdsm services framework ( i > learnt about these in my brief chat with Saggie some time back) play a > role here ? > > Can "Provisioning Storage" itself be like a high level service, with > gluster and lsm exposing storage services, which vdsm can enumerate > and send to oVirt GUI, is that the idea ? > Is there any wiki page on this topic which lists the todos on this > front, which I can start looking at ? > Hello Ayal, Looking for you opinion here. thanx, deepak From dfediuck at redhat.com Thu May 3 15:43:32 2012 From: dfediuck at redhat.com (Doron Fediuck) Date: Thu, 03 May 2012 18:43:32 +0300 Subject: [Engine-devel] [vdsm] vds_bootstrap.py 's residency In-Reply-To: <4FA29C92.1030805@linux.vnet.ibm.com> References: <4FA29C92.1030805@linux.vnet.ibm.com> Message-ID: <4FA2A7A4.5080508@redhat.com> On 03/05/12 17:56, Shu Ming wrote: > Hi, > I am checking the VDSM and ovirt-engine workspace for "vds_bootstrap.py" file. It was found that vds_bootstrap.py file was in VDSM workspace and was packaged into vdsm-bootstrap rpm package. Also, it was found that in the host installation process, host node will try to get the "vds_bootstrap.py" from the engine server. But "vds_bootstrap.py" is not included in any engine packages. Does that mean we should install vdsm-bootstrap package into engine server? Why not package this file into engine packages instead of vdsm packages? > Hi Shu, good questions ;) Let's take it one at a time: 1. The bootstrap RPM should be installed on the engine's machine. 2. The reason behind this odd behavior is as follows; The concept of bootstrapping, means taking a bare Linux installation, and making a Hypervisor out of it. This process includes (amongst other) several delicate operations, such as validations, network configuration, certificate generation and RPM installation. One of the RPM being installed by the bootstrap script, is vdsm itself, so bootstrap cannot be a part of the vdsm. 3. The reason for keeping the bootstrapping scripts in the vdsm repo, is that bootstrapping prepares the hypervisor for vdsm, so if/when something changes in vdsm, is should be modified in bootstrap as well. Hope it helps, Doron -- /d "This message will self destruct in the future. Or not." From ykaul at redhat.com Thu May 3 15:47:07 2012 From: ykaul at redhat.com (Yaniv Kaul) Date: Thu, 03 May 2012 18:47:07 +0300 Subject: [Engine-devel] [vdsm] vds_bootstrap.py 's residency In-Reply-To: <4FA2A7A4.5080508@redhat.com> References: <4FA29C92.1030805@linux.vnet.ibm.com> <4FA2A7A4.5080508@redhat.com> Message-ID: <4FA2A87B.1000700@redhat.com> On 05/03/2012 06:43 PM, Doron Fediuck wrote: > On 03/05/12 17:56, Shu Ming wrote: >> Hi, >> I am checking the VDSM and ovirt-engine workspace for "vds_bootstrap.py" file. It was found that vds_bootstrap.py file was in VDSM workspace and was packaged into vdsm-bootstrap rpm package. Also, it was found that in the host installation process, host node will try to get the "vds_bootstrap.py" from the engine server. But "vds_bootstrap.py" is not included in any engine packages. Does that mean we should install vdsm-bootstrap package into engine server? Why not package this file into engine packages instead of vdsm packages? >> > Hi Shu, good questions ;) > > Let's take it one at a time: > > 1. The bootstrap RPM should be installed on the engine's machine. > 2. The reason behind this odd behavior is as follows; > The concept of bootstrapping, means taking a bare Linux installation, and making a Hypervisor out of it. > This process includes (amongst other) several delicate operations, such as validations, network configuration, certificate > generation and RPM installation. One of the RPM being installed by the bootstrap script, is vdsm itself, so > bootstrap cannot be a part of the vdsm. > 3. The reason for keeping the bootstrapping scripts in the vdsm repo, is that bootstrapping prepares the > hypervisor for vdsm, so if/when something changes in vdsm, is should be modified in bootstrap as well. > > Hope it helps, > Doron > 4. Yes, the name is horribly confusing. host-bootstrap / hypervisor-bootstrap would have been a much better name. Y. From iheim at redhat.com Thu May 3 16:08:43 2012 From: iheim at redhat.com (Itamar Heim) Date: Thu, 03 May 2012 19:08:43 +0300 Subject: [Engine-devel] REST-API: Exposing correlation-ID In-Reply-To: <4FA2978C.7060805@redhat.com> References: <5f017132-f1da-4f42-b76e-5cf9361dd0c7@zmail17.collab.prod.int.phx2.redhat.com> <4FA2978C.7060805@redhat.com> Message-ID: <4FA2AD8B.4060404@redhat.com> On 05/03/2012 05:34 PM, Yaniv Kaul wrote: > On 05/03/2012 05:24 PM, Ori Liel wrote: >> Correlation-ID feature allows 'tagging' a call to a Backend command >> with a String ID, and this ID will be appended to all log messages >> that result from this command. >> >> http://www.ovirt.org/wiki/Features/TaskManagerDetailed >> >> In REST-API, we would like to enable the user to pass a correlation-ID >> when he activates actions. > > Makes a more sense to me that the user will get it in the response, > rather than setting it by himself. > What's the added value of the user setting it (as opposed to the engine, > which is already doing it) ? engine only does it if not passed by user. user being able to set it allows user to annotate a group of several commands under same group/flow/batch-id > Y. > >> >> I have two questions: >> >> 1) what's the name you'd give this parameter? job-id? batch-id? >> flow-id? command-id? correlation-id??? >> >> 2) I've already implemented this as a url parameter. Are there >> objections? >> The only viable alternative I see is as an http header, which doesn't >> feel >> right. It's not an option to pass it in the XML body, because sometimes >> there is no body, for example, in DELETE commands. >> >> Thanks >> >> Ori. >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From iheim at redhat.com Thu May 3 16:10:32 2012 From: iheim at redhat.com (Itamar Heim) Date: Thu, 03 May 2012 19:10:32 +0300 Subject: [Engine-devel] REST-API: Exposing correlation-ID In-Reply-To: <31823c55-c6df-465e-8f05-d5f6e6d8baf6@zmail11.collab.prod.int.phx2.redhat.com> References: <31823c55-c6df-465e-8f05-d5f6e6d8baf6@zmail11.collab.prod.int.phx2.redhat.com> Message-ID: <4FA2ADF8.5020905@redhat.com> On 05/03/2012 06:15 PM, Eoghan Glynn wrote: > > >> Correlation-ID feature allows 'tagging' a call to a Backend command >> with a String ID, and this ID will be appended to all log messages >> that result from this command. >> >> http://www.ovirt.org/wiki/Features/TaskManagerDetailed >> >> In REST-API, we would like to enable the user to pass a >> correlation-ID >> when he activates actions. >> >> I have two questions: >> >> 1) what's the name you'd give this parameter? job-id? batch-id? >> flow-id? command-id? correlation-id??? >> >> 2) I've already implemented this as a url parameter. Are there >> objections? >> The only viable alternative I see is as an http header, which doesn't >> feel >> right. It's not an option to pass it in the XML body, because >> sometimes >> there is no body, for example, in DELETE commands. > > Hi Ori, > > Is the intent here to allow correlation between multiple backend actions > initiated from a single restapi call, or an over-arching correlation > across multiple restapi calls? > > If the former, then I'd agree with Yaniv, just generate the ID internally > and return it as a response header. > > If the latter, then allowing it to be optionally set via a request header, > seems more natural to me than a URL parameter because this is additional > out-of-band data that aids in log interpretation, as opposed to something > directly germane to the interaction with the target resource. both. engine auto-generates this if not provided and domain is single command. but client can pass this to see all events or multiple commands running in parallel as part of same single client logical action. From oliel at redhat.com Thu May 3 18:49:28 2012 From: oliel at redhat.com (Ori Liel) Date: Thu, 03 May 2012 14:49:28 -0400 (EDT) Subject: [Engine-devel] REST-API: Exposing correlation-ID In-Reply-To: <4FA2ADF8.5020905@redhat.com> Message-ID: <51653ca1-07d0-4704-8033-039bb5dfb5c3@zmail17.collab.prod.int.phx2.redhat.com> ----- Original Message ----- From: "Itamar Heim" > To: "Eoghan Glynn" > Cc: "Ori Liel" >, engine-devel at ovirt.org Sent: Thursday, May 3, 2012 7:10:32 PM Subject: Re: [Engine-devel] REST-API: Exposing correlation-ID On 05/03/2012 06:15 PM, Eoghan Glynn wrote: >> >> >>> Correlation-ID feature allows 'tagging' a call to a Backend command >>> with a String ID, and this ID will be appended to all log messages >>> that result from this command. >>> >>> http://www.ovirt.org/wiki/Features/TaskManagerDetailed >>> >>> In REST-API, we would like to enable the user to pass a >>> correlation-ID >>> when he activates actions. >>> >>> I have two questions: >>> >>> 1) what's the name you'd give this parameter? job-id? batch-id? >>> flow-id? command-id? correlation-id??? >>> >>> 2) I've already implemented this as a url parameter. Are there >>> objections? >>> The only viable alternative I see is as an http header, which doesn't >>> feel >>> right. It's not an option to pass it in the XML body, because >>> sometimes >>> there is no body, for example, in DELETE commands. >> >> Hi Ori, >> >> Is the intent here to allow correlation between multiple backend actions >> initiated from a single restapi call, or an over-arching correlation >> across multiple restapi calls? >> >> If the former, then I'd agree with Yaniv, just generate the ID internally >> and return it as a response header. >> >> If the latter, then allowing it to be optionally set via a request header, >> seems more natural to me than a URL parameter because this is additional >> out-of-band data that aids in log interpretation, as opposed to something >> directly germane to the interaction with the target resource. > >both. >engine auto-generates this if not provided and domain is single command. >but client can pass this to see all events or multiple commands running >in parallel as part of same single client logical action. Right, when user passes a correlation ID on the http request, all calls to the Backend, that are done in the context of this request, will have this correlation-ID (and thus appear in the log as part of the same operation). But when I think about it, why should the user be involved? If a REST action - for example restore-snapshot - involves more than one call to the Backend, REST-API (not the user) can decide to always attach a hard-coded, descriptive correlation ID to these calls. In trying to justify letting the user set the correlation ID, I came up with the following scenarios: * the user wants to analyze an action in the log, but the server is shared by many users. It would be easier to look for "ori's_restore_snapshot" than for the generic "restore_snapshot", because maybe other users restored snapshots. * tester wants to run the same action 50 times with different parameters, and see the actions in the log as: "restore_snapshot_test_1", "restore_snapshot_test_2", etc. So in summary, I think there is some value in letting the user set the value. Ori From iheim at redhat.com Thu May 3 19:03:07 2012 From: iheim at redhat.com (Itamar Heim) Date: Thu, 03 May 2012 22:03:07 +0300 Subject: [Engine-devel] REST-API: Exposing correlation-ID In-Reply-To: <51653ca1-07d0-4704-8033-039bb5dfb5c3@zmail17.collab.prod.int.phx2.redhat.com> References: <51653ca1-07d0-4704-8033-039bb5dfb5c3@zmail17.collab.prod.int.phx2.redhat.com> Message-ID: <4FA2D66B.2010503@redhat.com> On 05/03/2012 09:49 PM, Ori Liel wrote: ... >>> Hi Ori, >>> >>> Is the intent here to allow correlation between multiple backend actions >>> initiated from a single restapi call, or an over-arching correlation >>> across multiple restapi calls? >>> >>> If the former, then I'd agree with Yaniv, just generate the ID internally >>> and return it as a response header. >>> >>> If the latter, then allowing it to be optionally set via a request header, >>> seems more natural to me than a URL parameter because this is additional >>> out-of-band data that aids in log interpretation, as opposed to something >>> directly germane to the interaction with the target resource. >> >> both. >> engine auto-generates this if not provided and domain is single command. >> but client can pass this to see all events or multiple commands running >> in parallel as part of same single client logical action. > > Right, when user passes a correlation ID on the http request, all calls to > the Backend, that are done in the context of this request, will have this > correlation-ID (and thus appear in the log as part of the same operation). > > But when I think about it, why should the user be involved? If a REST > action - for example restore-snapshot - involves more than one call to the > Backend, REST-API (not the user) can decide to always attach a hard-coded, > descriptive correlation ID to these calls. true, if API performs multiple actions it should self-generated the ID on its own (just like the backend does). > > In trying to justify letting the user set the correlation ID, I came up with > the following scenarios: > * the user wants to analyze an action in the log, but the server is shared by > many users. It would be easier to look for "ori's_restore_snapshot" than for > the generic "restore_snapshot", because maybe other users restored snapshots. > * tester wants to run the same action 50 times with different parameters, and > see the actions in the log as: "restore_snapshot_test_1", "restore_snapshot_test_2", > etc. > > So in summary, I think there is some value in letting the user set the value. another use case - user wants to write their own feature of managing VM pools. user creates a group of VMs via a single action in the UI created on top of the REST API. as far as user is concerned, the 30 VMs created by their action, events, and statuses are all part of the same meta-action, so all should have the same batch id. > > Ori From abaron at redhat.com Thu May 3 21:36:02 2012 From: abaron at redhat.com (Ayal Baron) Date: Thu, 03 May 2012 17:36:02 -0400 (EDT) Subject: [Engine-devel] [vdsm] Storage Device Management in VDSM and oVirt In-Reply-To: <4F97DE7A.2040808@linux.vnet.ibm.com> Message-ID: ----- Original Message ----- > On 04/24/2012 07:37 PM, Ayal Baron wrote: > > > > ----- Original Message ----- > >> On 04/24/2012 02:07 AM, Ayal Baron wrote: > >>> ----- Original Message ----- > >>>> On 04/22/2012 12:28 PM, Ayal Baron wrote: > >>>>>>> This way we'd have a 2 stage process: > >>>>>>> 1. setupStorage (generic) > >>>>>> I was looking up on the VDSM archives and there are talks of > >>>>>> using > >>>>>> libstoragemgmt (lsm) > >>>>> Funny, we started using that acronym for Live Storage Migration > >>>>> :) > >>>>> > >>>>>> under VDSM. I was wondering if the setupStorage would be > >>>>>> something > >>>>>> where > >>>>>> lsm would > >>>>>> be used to do the work, it seems fit for purpose here. > >>>>>> > >>>>>> > >>>>> I don't think this is the libstoragemgmt mandate. > >>>>> > >>>>> libstoragemgmt is: > >>>>> "A library that will provide a vendor agnostic open source > >>>>> storage > >>>>> application programming interface (API) for storage arrays." > >>>>> > >>>>> i.e. it is there to abstract storage array specifics from the > >>>>> user. > >>>>> It will be used by things like LVM etc, not the other way > >>>>> around. > >>>>> > >>>>> setupStorage would use libstoragemgmt wherever appropriate of > >>>>> course. > >>>>> > >>>>> But as the libstoragemgmt maintainer, Tony (cc'd) can correct > >>>>> me > >>>>> if > >>>>> I'm wrong here. > >>>>> > >>>>> > >>>> I was looking at setupStorage as Provisioning + Setting up. > >>>> I know one of the basic goals of lsm is provision the storage to > >>>> the > >>>> host > >>>> and preparing the storage for consumption is higher layers work. > >>>> > >>>> With that, i think then its becomes a 3 stage process, from > >>>> oVirt/VDSM > >>>> pov... > >>>> 1) Provision Storage (using lsm if applicable, based on whether > >>>> external > >>>> storage is connected) > >>>> 2) Setup Storage (prepare the provisioned LUNs for usage) > >>>> 3) createSD/createGlusterVolume/... (plugin specific) > >>>> > >>>> Since we are talking about Storage management using VDSM, i was > >>>> interested in understanding the plans, strategy of how VDSM + > >>>> lsm > >>>> will integrate ? > >>> There are various ways of approaching this. > >>> 1. Given proper storage you could just provision new LUNs > >>> whenever > >>> you need a new virtual disk and utilize storage side thin > >>> provisioning and snapshots for most of your needs. > >>> When you have such storage you don't really need steps 2 and 3 > >>> above. Your storage is your virtual images repository. > >>> Although quite simple and powerful, very few arrays are capable > >>> of > >>> growing to a very large number of objects (luns + snapshots + > >>> whatever) today, so I don't see this being the most common use > >>> case any time soon. > >> This is not clear to me. This only talks about provisioning but > >> not > >> consuming. > >> 2 and 3 above are required from a consumability perspective. The > >> LUNs > >> will have > >> to prepared and used by LVM (pv, vg, lv, metadata) for VDSM to > >> host a > >> storage domain. > > There are several ways of managing the repo in such a scenario, > > just an example is to provision a LUN where vdsm would manage > > metadata (listing of images, relations between snapshots, logical > > sizes of images, etc) and every image is another LUN that we would > > provision, so there would be no need for LVM in such a scenario. > > > > Sorry, but not clear to me. If vdsm is configured for file based > storage > domain, it would expect the LUN to have a fs, and vdsm would create > the > fs storage domain over it. If vdsm is configured for block based > storage > domain, it would end up using the LUN as a pv, over which the VG/LV > would sit (hence the need for lvm) and form the block storage domain, > unless you are talking of vdsm using raw LUNs which is not supported > today ? Today vdsm cannot provision LUNs, only consume there so the full scenario is of course not supported today. However, we do support exposing LUNs directly to VMs so the only delta is that we do not manage the LUNs as a repository. > > >> > >>> 2. Provision LUNs (either statically or dynamically using lsm) > >>> once, preferably thinly provisioned. Then setupStorage (storage > >>> domain over VG / gLuster / other) and use lsm for creating > >>> snapshots/clones on the fly > >>> In my opinion this will be more prevalent to begin with. > >>> > >>> With lsm we will (hopefully) have a way of enumerating storage > >>> side > >>> capabilities so then when we create a repository (gluster / sd / > >>> ...) we'd be able to determine on the fly what capabilities it > >>> has > >>> and determine if to use these or to use virtualized capabilities > >>> (e.g. in the virt case when you need to create a snapshot use > >>> qcowX). > >>> > >>> In oVirt, once you've defined a storage domain and it exposes a > >>> set > >>> of capabilities, user should be able to override (e.g. even > >>> though > >>> storage supports snapshots, I want to use qcow as this storage > >>> can > >>> only create 255 snapshots per volume and I need more than that). > >>> > >>> I'm assuming that we will not have any way of knowing the limits > >>> per machine. > >>> > >>> Does that make sense? > >>> > >> Agree to #2. Thinking deeper.... > >> > >> 1) Provisioning Storage > >> > >> Provisioning storage using lsm would require new VDSM verbs to be > >> added, > >> which can create / show the LUNs to the oVirt user and user can > >> then > >> select which LUN(s) to use for setupStorage. > > create LUN doesn't exist today, but show LUNs does. > > > > Currently the (simplified) flow is: > > 1. connect to storage (when relevant) > > 2. get listing of devices > > 3. create a storage domain on selected devices > > > >> Provisioning LUNs will probably exploit the lsm capabilities and > >> provide > >> the options to the user to create the LUNs using the available > >> array > >> features. > >> > >> With GlusterFS also providing some of the array capabilities > >> (stripe, > >> replicate etc), user might want to provision GlusterFS volume > >> (with > >> whatever capabilities gluster offers) to host storage upon, > >> especially > >> if the storage is coming from not-so-reliable commodity hw > >> storage. > >> > >> I feel this also has to be considered as part of provisioning and > >> should > >> come before the setupStorage step. > >> > >> IMHO, there should be a "Storage Provisioning" tab in oVirt which > >> will > >> allow user to ... > >> > >> 1a) Carve LUNs from external Storage array. > >> > >> 1b) Provision storage as GlusterFS volume. User can select > >> the > >> LUNs > >> carved (from #1a) as bricks for GlusterFS volume, if need be. > >> > >> 1c) Use local host free disk space. > >> > >> Somewhere here there should be option ( as applicable) for user to > >> select whether to exploit storage array features or host virt > >> capabilities for say snapshot, in cases where both are applicable. > >> > >> 2) Setup Storage > >> > >> Here the user would create VDSM file or block based storage > >> domain, > >> based on the storage provisioned from the "Storage Provisioning" > >> tab. > >> I believe this is where VDSM will add its metadata to the > >> provisioned > >> storage to make it a storage domain. > >> > >> IMHO for image operations like snapshot/clone, VDSM will have to > >> track& > >> maintain whether the image is served by local host, external > >> storage > >> array or gluster volume and accordingly use the lvm, lsm or > >> gluster > >> apis > >> to get the job done. > > For sure. That would be part of the domain metadata. > > > >> 3) Not sure if anymore steps needed ? > > In general I agree with the above. wrt the scope of setupStorage, > > it's semantics. Personally I think we should differentiate > > between provisioning storage on the target side and provisioning > > on the initiator side. > > > > The flow (from GUI) as I see it is (with lsm and an array that > > supports dynamic provisioning): > > 1. provide credentials and login into storage (out of band, using > > lsm) > > 2. enumerate capabilities > > 3. based on 2, define required storage domain characteristics > > (size, thin provisioning, etc) > > - but note that this is generic, so should apply to gluster as > > well > > 4. create a storage domain - would implicitly create 1 or more LUNs > > and anything else that is needed according to above > > specifications. API wise, this is probably 3 calls, 1. provision > > LUNs, 2. setupStorage and 3. > > createStorageDomain/createGlusterVolume/... > > > > Characteristics might include things like partitions, encryption?, > > compression?, raid, file systems, etc. > > > > This seems interesting. > > I am interested in pursuing this further and helping contribute to > the > vdsm lsm integration. lsm is still in the early stages, but i feel > its > the right time to start influencing it so that vdsm integration can > be > smooth. My interest mainly lies in how external storage array can be > integrated into oVirt/VDSM and help oVirt exploit the array offload > features as part of the virtualization stack. > > I didn't find any oVirt wiki page on this topic, tho' there is a old > mailing list thread on vdsm lsm integration, which when read brings > up > more issues to discuss :) > How does storage repo engine and possible vdsm services framework ( i > learnt about these in my brief chat with Saggie some time back) play > a > role here ? Maybe Saggi could elaborate here. > > Can "Provisioning Storage" itself be like a high level service, with > gluster and lsm exposing storage services, which vdsm can enumerate > and > send to oVirt GUI, is that the idea ? I'm not sure "Provisioning Storage" is a clear enough definition, as it could cover a lot of possibly unrelated things, but I'd need to understand more what you mean to really be able to comment properly. > Is there any wiki page on this topic which lists the todos on this > front, which I can start looking at ? Unfortunately there is not as we haven't sat down to plan it in depth, but you're more than welcome to start it. Generally, the idea is as follows: Currently vdsm has storage virtualization capabilites, i.e. we've implemented a form of thin-provisioning, we provide snapshots using qcow etc, without relying on the hardware. Using lsm we could have feature negotiation and whenever we can offload, do it. e.g. we could know if a storage array supports thin cloning, if it supports thick cloning, if a LUN supports thin provisioning etc. In the last example (thin provisioning) when we create a VG on top of a thin-p LUN we should create all disk image (LVs) 'preallocated' and avoid vdsm's thin provisioning implementation (as it is not needed). However, we'd need a mechanism at domain level to 'disable' some of the capabilities, so for example if we know that on a specific array snapshots are limited or provide poor performance (worse than qcow) or whatever, we'd be able to fall back to vdsm's software implementation. Does this make sense? > > thanx, > deepak > > From oliel at redhat.com Sun May 6 06:56:19 2012 From: oliel at redhat.com (Ori Liel) Date: Sun, 06 May 2012 02:56:19 -0400 (EDT) Subject: [Engine-devel] restapi: 'gluster' prefix In-Reply-To: <6753cc0c-25f0-4738-a61e-bd463311f8a2@zmail17.collab.prod.int.phx2.redhat.com> Message-ID: <298033b3-0a78-42f9-a26c-cf39bed80e0b@zmail17.collab.prod.int.phx2.redhat.com> We are introducing Gluster functionality into ovirt-engine REST-API. Gluster entities are 'Volumes' and 'Bricks'. The question is: should they be called: 'volume'/'brick' or 'gluster_volume/gluster_brick'? (with or without the 'gluster' prefix)? There was a short conversation about this in a patch in Gerrit: http://gerrit.ovirt.org/#change,3918 Since there are conflicting opinions, I'm bringing it here for a resolution. Thanks, Ori. From oliel at redhat.com Sun May 6 07:03:44 2012 From: oliel at redhat.com (Ori Liel) Date: Sun, 06 May 2012 03:03:44 -0400 (EDT) Subject: [Engine-devel] REST-API: Exposing correlation-ID In-Reply-To: <5f017132-f1da-4f42-b76e-5cf9361dd0c7@zmail17.collab.prod.int.phx2.redhat.com> Message-ID: <3fad9fcc-cae3-4bc3-9e23-551bd6e312a9@zmail17.collab.prod.int.phx2.redhat.com> Still need to decide about this: >1) what's the name you'd give this parameter? job-id? batch-id? >flow-id? command-id? correlation-id??? From iheim at redhat.com Sun May 6 07:14:20 2012 From: iheim at redhat.com (Itamar Heim) Date: Sun, 06 May 2012 10:14:20 +0300 Subject: [Engine-devel] REST-API: Exposing correlation-ID In-Reply-To: <3fad9fcc-cae3-4bc3-9e23-551bd6e312a9@zmail17.collab.prod.int.phx2.redhat.com> References: <3fad9fcc-cae3-4bc3-9e23-551bd6e312a9@zmail17.collab.prod.int.phx2.redhat.com> Message-ID: <4FA624CC.3030307@redhat.com> On 05/06/2012 10:03 AM, Ori Liel wrote: > Still need to decide about this: > >> 1) what's the name you'd give this parameter? job-id? batch-id? >> flow-id? command-id? correlation-id??? job-id will confuse us with engine's job-id which is a single command today. correleation-id is pretty long and confusing as implies on correlation of something. I'm for flow-id or batch-id. batch-id sounds the right one to me, as this is identifying a batch of calls. From mkolesni at redhat.com Sun May 6 10:51:45 2012 From: mkolesni at redhat.com (Mike Kolesnik) Date: Sun, 06 May 2012 06:51:45 -0400 (EDT) Subject: [Engine-devel] REST-API: Exposing correlation-ID In-Reply-To: <4FA624CC.3030307@redhat.com> Message-ID: > On 05/06/2012 10:03 AM, Ori Liel wrote: > > Still need to decide about this: > > > >> 1) what's the name you'd give this parameter? job-id? batch-id? > >> flow-id? command-id? correlation-id??? > > job-id will confuse us with engine's job-id which is a single command > today. > correleation-id is pretty long and confusing as implies on > correlation > of something. > > I'm for flow-id or batch-id. > batch-id sounds the right one to me, as this is identifying a batch > of > calls. How about log-id? It isn't supposed to be unique, or of any format, it's just used to log calls, so log-id is the most natural (or log-tag or whatever name you prefer). Also I think it's more of a header-type parameter since it's metadata for the call, not an actual parameter that influences the outcome of the "flow". > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From oliel at redhat.com Sun May 6 12:36:12 2012 From: oliel at redhat.com (Ori Liel) Date: Sun, 06 May 2012 08:36:12 -0400 (EDT) Subject: [Engine-devel] REST-API: Exposing correlation-ID In-Reply-To: Message-ID: >> On 05/06/2012 10:03 AM, Ori Liel wrote: >> > Still need to decide about this: >> > >> >> 1) what's the name you'd give this parameter? job-id? batch-id? >> >> flow-id? command-id? correlation-id??? >> >> job-id will confuse us with engine's job-id which is a single command >> today. >> correleation-id is pretty long and confusing as implies on >> correlation >> of something. >> >> I'm for flow-id or batch-id. >> batch-id sounds the right one to me, as this is identifying a batch >> of >> calls. >How about log-id? >It isn't supposed to be unique, or of any format, it's just used to log calls, so log-id is the most natural (or log-tag or whatever name you prefer). > >Also I think it's more of a header-type parameter since it's metadata for the call, not an actual parameter that influences the outcome of the "flow". I actually believe you're right, it probably is better to pass this parameter as an http header. You've changed my mind about this (objections, anyone, to passing it as a header as opposed to passing it as a url parameter)? About log_id - it could sound like there are numerous logs, and the user is asked to specify the ID of the log he wishes to write to. But perhaps: log_entry_id? Thanks, Ori > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From amureini at redhat.com Sun May 6 12:46:03 2012 From: amureini at redhat.com (Allon Mureinik) Date: Sun, 06 May 2012 08:46:03 -0400 (EDT) Subject: [Engine-devel] The correct way to create test dependencies between In-Reply-To: <1ebe5c34-dcb5-4abe-9824-1637d0d605e2@zmail17.collab.prod.int.phx2.redhat.com> Message-ID: Hi guys, I've recently come up with (what I believe is) an elegant way to mock the Config object using JUnit @Rules and Mockito (The gritty details can be found at http://gerrit.ovirt.org/4155). This presented me with another issue: On the one hand, the code depends on junit and mockito jars, which are not available in the main scope, only in the test scope. On the other hand, in vanilla Maven there is no dependency between tests of different projects, so placing this class in util's test would make it inaccessible to bll tests. The solution Maven suggests for these kind of issues is creating a test jar (http://maven.apache.org/guides/mini/guide-attached-tests.html): In addition to the regular jar the module produces, you'll get another -test jar, which other modules can depend on using the test-jar, which could of course be put in test. Before pushing forward with this approach, I'd like to know if anyone has a principle objection to it. Thanks, Allon From yzaslavs at redhat.com Sun May 6 13:13:28 2012 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Sun, 06 May 2012 16:13:28 +0300 Subject: [Engine-devel] The correct way to create test dependencies between In-Reply-To: References: Message-ID: <4FA678F8.2080904@redhat.com> On 05/06/2012 03:46 PM, Allon Mureinik wrote: > Hi guys, > > I've recently come up with (what I believe is) an elegant way to mock the Config object using JUnit @Rules and Mockito (The gritty details can be found at http://gerrit.ovirt.org/4155). More on @Rule can be found at this blog - http://blog.schauderhaft.de/2009/10/04/junit-rules/ > > This presented me with another issue: > On the one hand, the code depends on junit and mockito jars, which are not available in the main scope, only in the test scope. > On the other hand, in vanilla Maven there is no dependency between tests of different projects, so placing this class in util's test would make it inaccessible to bll tests. > > The solution Maven suggests for these kind of issues is creating a test jar (http://maven.apache.org/guides/mini/guide-attached-tests.html): In addition to the regular jar the module produces, you'll get another -test jar, which other modules can depend on using the test-jar, which could of course be put in test. > > Before pushing forward with this approach, I'd like to know if anyone has a principle objection to it. > > > Thanks, > Allon > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From eedri at redhat.com Sun May 6 14:38:31 2012 From: eedri at redhat.com (Eyal Edri) Date: Sun, 06 May 2012 10:38:31 -0400 (EDT) Subject: [Engine-devel] [Jenkins] new High priority bug in ovirt-engine In-Reply-To: <7a4284f9-59f1-4fa4-853f-20e6a1966642@zmail17.collab.prod.int.phx2.redhat.com> Message-ID: <87b658e7-4a17-4529-aa1f-f7f6978f9666@zmail17.collab.prod.int.phx2.redhat.com> fyi, a new HIGH priority bug was pushed to ovirt-engine, please check. bug details: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/765/findbugsResult/HIGH/source.143160/#362 Found in file: VmPropertiesUtils.java:362, GC_UNRELATED_TYPES Introduced after these commits: engine: Create Gluster Volume enhancements (detail / gitweb) core: removing async tasks and compensation data on upgrade (detail / gitweb) engine: support versions for vm properties (detail / gitweb) webadmin: support versions for vm properties (detail / gitweb) core: Fixing bll tests (detail / gitweb) engine: New query to fetch Gluster Volume by ID (detail / gitweb) Eyal. From yzaslavs at redhat.com Sun May 6 14:46:48 2012 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Sun, 06 May 2012 17:46:48 +0300 Subject: [Engine-devel] [Jenkins] new High priority bug in ovirt-engine In-Reply-To: <87b658e7-4a17-4529-aa1f-f7f6978f9666@zmail17.collab.prod.int.phx2.redhat.com> References: <87b658e7-4a17-4529-aa1f-f7f6978f9666@zmail17.collab.prod.int.phx2.redhat.com> Message-ID: <4FA68ED8.5090007@redhat.com> On 05/06/2012 05:38 PM, Eyal Edri wrote: > fyi, > > a new HIGH priority bug was pushed to ovirt-engine, please check. I am on it - I will check this ASAP. > > bug details: > http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/765/findbugsResult/HIGH/source.143160/#362 > > Found in file: VmPropertiesUtils.java:362, GC_UNRELATED_TYPES > > Introduced after these commits: > > engine: Create Gluster Volume enhancements (detail / gitweb) > core: removing async tasks and compensation data on upgrade (detail / gitweb) > engine: support versions for vm properties (detail / gitweb) > webadmin: support versions for vm properties (detail / gitweb) > core: Fixing bll tests (detail / gitweb) > engine: New query to fetch Gluster Volume by ID (detail / gitweb) > > > Eyal. > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From mpastern at redhat.com Sun May 6 19:09:29 2012 From: mpastern at redhat.com (Michael Pasternak) Date: Sun, 06 May 2012 22:09:29 +0300 Subject: [Engine-devel] restapi: 'gluster' prefix In-Reply-To: <298033b3-0a78-42f9-a26c-cf39bed80e0b@zmail17.collab.prod.int.phx2.redhat.com> References: <298033b3-0a78-42f9-a26c-cf39bed80e0b@zmail17.collab.prod.int.phx2.redhat.com> Message-ID: <4FA6CC69.7060301@redhat.com> i can't see any justification for the 'gluster' prefix, as this is only additional /service/ provided by the project, and Gluster now is a part of the RHT. On 05/06/2012 09:56 AM, Ori Liel wrote: > We are introducing Gluster functionality into ovirt-engine REST-API. > > Gluster entities are 'Volumes' and 'Bricks'. The question is: should > they be called: 'volume'/'brick' or 'gluster_volume/gluster_brick'? > (with or without the 'gluster' prefix)? > > There was a short conversation about this in a patch in Gerrit: > http://gerrit.ovirt.org/#change,3918 > > Since there are conflicting opinions, I'm bringing it here for a resolution. > > Thanks, > > Ori. > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel -- Michael Pasternak RedHat, ENG-Virtualization R&D From abaron at redhat.com Sun May 6 20:36:32 2012 From: abaron at redhat.com (Ayal Baron) Date: Sun, 06 May 2012 16:36:32 -0400 (EDT) Subject: [Engine-devel] restapi: 'gluster' prefix In-Reply-To: <4FA6CC69.7060301@redhat.com> Message-ID: <912036c6-0568-4f82-9434-9926ad0b6793@zmail13.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > > i can't see any justification for the 'gluster' prefix, > as this is only additional /service/ provided by the project, > and Gluster now is a part of the RHT. I believe there needs to be an indication which service this is about. If we will support provisioning other storage types which also have volumes then we'd want a way to differentiate. However, isn't there a way to simply add gluster as the name space? i.e. somthing like: /api/gluster/.../volumes ? (instead of 'cluster' as it is redundant imho) > > On 05/06/2012 09:56 AM, Ori Liel wrote: > > We are introducing Gluster functionality into ovirt-engine > > REST-API. > > > > Gluster entities are 'Volumes' and 'Bricks'. The question is: > > should > > they be called: 'volume'/'brick' or 'gluster_volume/gluster_brick'? > > (with or without the 'gluster' prefix)? > > > > There was a short conversation about this in a patch in Gerrit: > > http://gerrit.ovirt.org/#change,3918 > > > > Since there are conflicting opinions, I'm bringing it here for a > > resolution. > > > > Thanks, > > > > Ori. > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > -- > > Michael Pasternak > RedHat, ENG-Virtualization R&D > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From abaron at redhat.com Sun May 6 20:45:22 2012 From: abaron at redhat.com (Ayal Baron) Date: Sun, 06 May 2012 16:45:22 -0400 (EDT) Subject: [Engine-devel] REST-API: Exposing correlation-ID In-Reply-To: Message-ID: <60819bdb-9867-4498-a4e4-8b4e78fa039e@zmail13.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > >> On 05/06/2012 10:03 AM, Ori Liel wrote: > >> > Still need to decide about this: > >> > > >> >> 1) what's the name you'd give this parameter? job-id? batch-id? > >> >> flow-id? command-id? correlation-id??? > >> > >> job-id will confuse us with engine's job-id which is a single > >> command > >> today. > >> correleation-id is pretty long and confusing as implies on > >> correlation > >> of something. > >> > >> I'm for flow-id or batch-id. > >> batch-id sounds the right one to me, as this is identifying a > >> batch > >> of > >> calls. > > >How about log-id? > >It isn't supposed to be unique, or of any format, it's just used to > >log calls, so log-id is the most natural (or log-tag or whatever > >name you prefer). > > > >Also I think it's more of a header-type parameter since it's > >metadata for the call, not an actual parameter that influences the > >outcome of the "flow". > > I actually believe you're right, it probably is better to pass this > parameter as > an http header. You've changed my mind about this (objections, > anyone, to passing > it as a header as opposed to passing it as a url parameter)? > > About log_id - it could sound like there are numerous logs, and the > user is asked > to specify the ID of the log he wishes to write to. But perhaps: > log_entry_id? op_id? (operation_id) > > Thanks, > > Ori > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From gchaplik at redhat.com Sun May 6 22:02:38 2012 From: gchaplik at redhat.com (Gilad Chaplik) Date: Sun, 06 May 2012 18:02:38 -0400 (EDT) Subject: [Engine-devel] REST-API: Exposing correlation-ID In-Reply-To: <60819bdb-9867-4498-a4e4-8b4e78fa039e@zmail13.collab.prod.int.phx2.redhat.com> Message-ID: <4b6f6232-6006-43d2-b81b-d09179d78ed1@zmail14.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Ayal Baron" > To: "Ori Liel" > Cc: engine-devel at ovirt.org > Sent: Sunday, May 6, 2012 11:45:22 PM > Subject: Re: [Engine-devel] REST-API: Exposing correlation-ID > > > > ----- Original Message ----- > > >> On 05/06/2012 10:03 AM, Ori Liel wrote: > > >> > Still need to decide about this: > > >> > > > >> >> 1) what's the name you'd give this parameter? job-id? > > >> >> batch-id? > > >> >> flow-id? command-id? correlation-id??? > > >> > > >> job-id will confuse us with engine's job-id which is a single > > >> command > > >> today. > > >> correleation-id is pretty long and confusing as implies on > > >> correlation > > >> of something. > > >> > > >> I'm for flow-id or batch-id. > > >> batch-id sounds the right one to me, as this is identifying a > > >> batch > > >> of > > >> calls. > > > > >How about log-id? > > >It isn't supposed to be unique, or of any format, it's just used > > >to > > >log calls, so log-id is the most natural (or log-tag or whatever > > >name you prefer). > > > > > >Also I think it's more of a header-type parameter since it's > > >metadata for the call, not an actual parameter that influences the > > >outcome of the "flow". > > > > I actually believe you're right, it probably is better to pass this > > parameter as > > an http header. You've changed my mind about this (objections, > > anyone, to passing > > it as a header as opposed to passing it as a url parameter)? > > > > About log_id - it could sound like there are numerous logs, and the > > user is asked > > to specify the ID of the log he wishes to write to. But perhaps: > > log_entry_id? > > op_id? (operation_id) Actually I'm just committing a patch for it, I calling it 'Correlation Id' in the GUI. IMHO it's the 'most likely not to get confused' name :) > > > > > Thanks, > > > > Ori > > > > > > > _______________________________________________ > > > Engine-devel mailing list > > > Engine-devel at ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From deepakcs at linux.vnet.ibm.com Mon May 7 08:50:06 2012 From: deepakcs at linux.vnet.ibm.com (Deepak C Shetty) Date: Mon, 07 May 2012 14:20:06 +0530 Subject: [Engine-devel] [vdsm] Storage Device Management in VDSM and oVirt In-Reply-To: References: Message-ID: <4FA78CBE.4090300@linux.vnet.ibm.com> >> This seems interesting. >> >> I am interested in pursuing this further and helping contribute to >> the >> vdsm lsm integration. lsm is still in the early stages, but i feel >> its >> the right time to start influencing it so that vdsm integration can >> be >> smooth. My interest mainly lies in how external storage array can be >> integrated into oVirt/VDSM and help oVirt exploit the array offload >> features as part of the virtualization stack. >> >> I didn't find any oVirt wiki page on this topic, tho' there is a old >> mailing list thread on vdsm lsm integration, which when read brings >> up >> more issues to discuss :) >> How does storage repo engine and possible vdsm services framework ( i >> learnt about these in my brief chat with Saggie some time back) play >> a >> role here ? > Maybe Saggi could elaborate here. > >> Can "Provisioning Storage" itself be like a high level service, with >> gluster and lsm exposing storage services, which vdsm can enumerate >> and >> send to oVirt GUI, is that the idea ? > I'm not sure "Provisioning Storage" is a clear enough definition, as it could cover a lot of possibly unrelated things, but I'd need to understand more what you mean to really be able to comment properly. > Well, I was envisioning oVirt as being able to provision and consume storage, both, going ahead. Provisioning thru' vdsm-libstoragemgmt (lsm) integration. oVirt user should be able to carve out LUNs, be able to associate the LUNs visibility to host(s) of a oVirt cluster, all via libstoragemgmt interfaces. With gluster being integrated into vdsm, oVirt user can provision and manage gluster volumes soon, which also falls under "provisioning storage", hence I was wondering if there would be a new tab in oVirt for "provisioning storage", where gluster ( in near future) and external array/LUNs ( via vdsm -lsm integration) can be provisioned. >> Is there any wiki page on this topic which lists the todos on this >> front, which I can start looking at ? > Unfortunately there is not as we haven't sat down to plan it in depth, but you're more than welcome to start it. > > Generally, the idea is as follows: > Currently vdsm has storage virtualization capabilites, i.e. we've implemented a form of thin-provisioning, we provide snapshots using qcow etc, without relying on the hardware. Using lsm we could have feature negotiation and whenever we can offload, do it. > e.g. we could know if a storage array supports thin cloning, if it supports thick cloning, if a LUN supports thin provisioning etc. > In the last example (thin provisioning) when we create a VG on top of a thin-p LUN we should create all disk image (LVs) 'preallocated' and avoid vdsm's thin provisioning implementation (as it is not needed). > I was thinking libstoragemgmt 'query capability' or similar interface should help vdsm know the array capabilities. I agree that if the backing LUN already is thinp'ed, then vdsm should not add its own over it. So such usecases & needs from vdsm perspective need to be thought about and eventually it should influence the libstoragemgmt interfaces > However, we'd need a mechanism at domain level to 'disable' some of the capabilities, so for example if we know that on a specific array snapshots are limited or provide poor performance (worse than qcow) or whatever, we'd be able to fall back to vdsm's software implementation. > I was thinking that its for the user to decide, not sure if we can auto-detect and automate this. But i feel this falls under the 'advanced usecase' category :) We can always think about this later, rite ? From juan.hernandez at redhat.com Mon May 7 11:08:41 2012 From: juan.hernandez at redhat.com (Juan Hernandez) Date: Mon, 07 May 2012 13:08:41 +0200 Subject: [Engine-devel] Problem with detachment of host interface using ovirt-sdk In-Reply-To: <4488206DC085244C886DBC9E7038B6892517433E@mtrdag02.mtl.com> References: <4488206DC085244C886DBC9E7038B6892517433E@mtrdag02.mtl.com> Message-ID: <4FA7AD39.8080207@redhat.com> On 04/29/2012 10:44 AM, Itzik Brown wrote: > I used the repository git://gerrit.ovirt.org/ovirt-engine-sdk > Commit 3c721e60ab3af3ad07e1a20bc6fdbcdbc1344df0 > > The test script : > > #!/usr/bin/python > > import sys > from ovirtsdk.api import API > from ovirtsdk.xml import params > > OVIRT_ENGINE_SERVER = 'server1' > OVIRT_ENGINE_PORT = '8080' > OVIRT_ENGINE_USER = 'admin at internal' > OVIRT_ENGINE_PASSWORD = 'password' > > url = 'http://%s:%s' % (OVIRT_ENGINE_SERVER, OVIRT_ENGINE_PORT) > api = API(url = url, username = OVIRT_ENGINE_USER , password = OVIRT_ENGINE_PASSWORD) > > host = 'host1' > if_name = 'eth4' > net_name = 'net1' > nic = api.hosts.get(name=host).nics.get(name=if_name) > net = params.Network(name=net_name) > act = params.Action(network=net) > nic.detach(act) > api.hosts.get(name=host).commitnetconfig() Itzik, I think there is nothing wrong with the SDK or with your code. The issue is deeper in the restapi or the backend (depends on how you look at it). I compared what restapi and webadmin do: * Both create an instance of the parameters using the constructor: AttachNetworkToVdsParameters(Guid vdsId, network net, VdsNetworkInterface iface) * Webadmin passes an instance of the network class where the status is 0 (non operational), even if the status of the network is 1 (operational). This might be a bug, but a bug that combined with the backend behavior makes the operation work. * The rest API passes an instance of the network class where the status is 1 (operational). This, combined with the backend behavior, makes the operation fail. * In the backend, if the status of the network is operational, the detach is performed only if the network is not in use in the cluster, which will always be true. I think that neither the webadmin nor the restapi should pass anything but the network name (or id) and the backend should ignore any additional information if passed. In addition the backend should allow the detach operation even if the network is in use in the cluster. Livnat, Michael, Einav, any comments? From lhornyak at redhat.com Mon May 7 11:23:10 2012 From: lhornyak at redhat.com (Laszlo Hornyak) Date: Mon, 07 May 2012 07:23:10 -0400 (EDT) Subject: [Engine-devel] The correct way to create test dependencies between In-Reply-To: Message-ID: <6e24687f-cbf2-4f96-82bc-9dff3e700fe2@zmail01.collab.prod.int.phx2.redhat.com> +1 I like the idea, I think this would really improve our unit tests. ----- Original Message ----- > From: "Allon Mureinik" > To: "engine-devel" > Sent: Sunday, May 6, 2012 2:46:03 PM > Subject: [Engine-devel] The correct way to create test dependencies between > > Hi guys, > > I've recently come up with (what I believe is) an elegant way to mock > the Config object using JUnit @Rules and Mockito (The gritty > details can be found at http://gerrit.ovirt.org/4155). > > This presented me with another issue: > On the one hand, the code depends on junit and mockito jars, which > are not available in the main scope, only in the test scope. > On the other hand, in vanilla Maven there is no dependency between > tests of different projects, so placing this class in util's test > would make it inaccessible to bll tests. > > The solution Maven suggests for these kind of issues is creating a > test jar > (http://maven.apache.org/guides/mini/guide-attached-tests.html): In > addition to the regular jar the module produces, you'll get another > -test jar, which other modules can depend on using the > test-jar, which could of course be put in > test. > > Before pushing forward with this approach, I'd like to know if anyone > has a principle objection to it. > > > Thanks, > Allon > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From sanjal at redhat.com Mon May 7 16:06:45 2012 From: sanjal at redhat.com (Shireesh Anjal) Date: Mon, 07 May 2012 21:36:45 +0530 Subject: [Engine-devel] restapi: 'gluster' prefix In-Reply-To: <912036c6-0568-4f82-9434-9926ad0b6793@zmail13.collab.prod.int.phx2.redhat.com> References: <912036c6-0568-4f82-9434-9926ad0b6793@zmail13.collab.prod.int.phx2.redhat.com> Message-ID: <4FA7F315.2090909@redhat.com> On Monday 07 May 2012 02:06 AM, Ayal Baron wrote: > > ----- Original Message ----- >> i can't see any justification for the 'gluster' prefix, >> as this is only additional /service/ provided by the project, >> and Gluster now is a part of the RHT. > I believe there needs to be an indication which service this is about. > If we will support provisioning other storage types which also have volumes then we'd want a way to differentiate. > However, isn't there a way to simply add gluster as the name space? > i.e. somthing like: /api/gluster/.../volumes ? (instead of 'cluster' as it is redundant imho) A gluster volume is a cluster level entity, and hence "/api/.../clusters/{cluster:id}" seems like the right parent URI for the gluster volumes collection resource. > > >> On 05/06/2012 09:56 AM, Ori Liel wrote: >>> We are introducing Gluster functionality into ovirt-engine >>> REST-API. >>> >>> Gluster entities are 'Volumes' and 'Bricks'. The question is: >>> should >>> they be called: 'volume'/'brick' or 'gluster_volume/gluster_brick'? >>> (with or without the 'gluster' prefix)? >>> >>> There was a short conversation about this in a patch in Gerrit: >>> http://gerrit.ovirt.org/#change,3918 >>> >>> Since there are conflicting opinions, I'm bringing it here for a >>> resolution. >>> >>> Thanks, >>> >>> Ori. >>> >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel at ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >> >> -- >> >> Michael Pasternak >> RedHat, ENG-Virtualization R&D >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From iheim at redhat.com Mon May 7 17:13:41 2012 From: iheim at redhat.com (Itamar Heim) Date: Mon, 07 May 2012 20:13:41 +0300 Subject: [Engine-devel] restapi: 'gluster' prefix In-Reply-To: <4FA7F315.2090909@redhat.com> References: <912036c6-0568-4f82-9434-9926ad0b6793@zmail13.collab.prod.int.phx2.redhat.com> <4FA7F315.2090909@redhat.com> Message-ID: <4FA802C5.8060408@redhat.com> On 05/07/2012 07:06 PM, Shireesh Anjal wrote: > On Monday 07 May 2012 02:06 AM, Ayal Baron wrote: >> >> ----- Original Message ----- >>> i can't see any justification for the 'gluster' prefix, >>> as this is only additional /service/ provided by the project, >>> and Gluster now is a part of the RHT. >> I believe there needs to be an indication which service this is about. >> If we will support provisioning other storage types which also have >> volumes then we'd want a way to differentiate. >> However, isn't there a way to simply add gluster as the name space? >> i.e. somthing like: /api/gluster/.../volumes ? (instead of 'cluster' >> as it is redundant imho) > > A gluster volume is a cluster level entity, and hence > "/api/.../clusters/{cluster:id}" seems like the right parent URI for the > gluster volumes collection resource. that's true for all other root entities as well: - VM is DC/cluster level - template is DC level - disk is storage domain level - network is DC level - hosts are cluster level (for now) yet all of them have their own root collections as well. I think glustervolumes seems safest/most reasonable for now (either at cluster level or root level as well) > >> >> >>> On 05/06/2012 09:56 AM, Ori Liel wrote: >>>> We are introducing Gluster functionality into ovirt-engine >>>> REST-API. >>>> >>>> Gluster entities are 'Volumes' and 'Bricks'. The question is: >>>> should >>>> they be called: 'volume'/'brick' or 'gluster_volume/gluster_brick'? >>>> (with or without the 'gluster' prefix)? >>>> >>>> There was a short conversation about this in a patch in Gerrit: >>>> http://gerrit.ovirt.org/#change,3918 >>>> >>>> Since there are conflicting opinions, I'm bringing it here for a >>>> resolution. >>>> >>>> Thanks, >>>> >>>> Ori. >>>> >>>> _______________________________________________ >>>> Engine-devel mailing list >>>> Engine-devel at ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> >>> -- >>> >>> Michael Pasternak >>> RedHat, ENG-Virtualization R&D >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel at ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From abaron at redhat.com Mon May 7 20:52:31 2012 From: abaron at redhat.com (Ayal Baron) Date: Mon, 07 May 2012 16:52:31 -0400 (EDT) Subject: [Engine-devel] restapi: 'gluster' prefix In-Reply-To: <4FA802C5.8060408@redhat.com> Message-ID: <621b9b66-5c2f-4bf2-8d93-553128fb2c0e@zmail13.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > On 05/07/2012 07:06 PM, Shireesh Anjal wrote: > > On Monday 07 May 2012 02:06 AM, Ayal Baron wrote: > >> > >> ----- Original Message ----- > >>> i can't see any justification for the 'gluster' prefix, > >>> as this is only additional /service/ provided by the project, > >>> and Gluster now is a part of the RHT. > >> I believe there needs to be an indication which service this is > >> about. > >> If we will support provisioning other storage types which also > >> have > >> volumes then we'd want a way to differentiate. > >> However, isn't there a way to simply add gluster as the name > >> space? > >> i.e. somthing like: /api/gluster/.../volumes ? (instead of > >> 'cluster' > >> as it is redundant imho) > > > > A gluster volume is a cluster level entity, and hence > > "/api/.../clusters/{cluster:id}" seems like the right parent URI > > for the > > gluster volumes collection resource. > > that's true for all other root entities as well: > - VM is DC/cluster level > - template is DC level > - disk is storage domain level > - network is DC level > - hosts are cluster level (for now) > > yet all of them have their own root collections as well. > > I think glustervolumes seems safest/most reasonable for now (either > at > cluster level or root level as well) does it make sense to also have gluster/bricks ? if so, I would nest it, i.e. gluster/{volumes|bricks|...} > > > > >> > >> > >>> On 05/06/2012 09:56 AM, Ori Liel wrote: > >>>> We are introducing Gluster functionality into ovirt-engine > >>>> REST-API. > >>>> > >>>> Gluster entities are 'Volumes' and 'Bricks'. The question is: > >>>> should > >>>> they be called: 'volume'/'brick' or > >>>> 'gluster_volume/gluster_brick'? > >>>> (with or without the 'gluster' prefix)? > >>>> > >>>> There was a short conversation about this in a patch in Gerrit: > >>>> http://gerrit.ovirt.org/#change,3918 > >>>> > >>>> Since there are conflicting opinions, I'm bringing it here for a > >>>> resolution. > >>>> > >>>> Thanks, > >>>> > >>>> Ori. > >>>> > >>>> _______________________________________________ > >>>> Engine-devel mailing list > >>>> Engine-devel at ovirt.org > >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > >>> > >>> -- > >>> > >>> Michael Pasternak > >>> RedHat, ENG-Virtualization R&D > >>> _______________________________________________ > >>> Engine-devel mailing list > >>> Engine-devel at ovirt.org > >>> http://lists.ovirt.org/mailman/listinfo/engine-devel > >>> > >> _______________________________________________ > >> Engine-devel mailing list > >> Engine-devel at ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > From iheim at redhat.com Tue May 8 05:15:09 2012 From: iheim at redhat.com (Itamar Heim) Date: Tue, 08 May 2012 08:15:09 +0300 Subject: [Engine-devel] restapi: 'gluster' prefix In-Reply-To: <621b9b66-5c2f-4bf2-8d93-553128fb2c0e@zmail13.collab.prod.int.phx2.redhat.com> References: <621b9b66-5c2f-4bf2-8d93-553128fb2c0e@zmail13.collab.prod.int.phx2.redhat.com> Message-ID: <4FA8ABDD.9070403@redhat.com> On 05/07/2012 11:52 PM, Ayal Baron wrote: > > > ----- Original Message ----- >> On 05/07/2012 07:06 PM, Shireesh Anjal wrote: >>> On Monday 07 May 2012 02:06 AM, Ayal Baron wrote: >>>> >>>> ----- Original Message ----- >>>>> i can't see any justification for the 'gluster' prefix, >>>>> as this is only additional /service/ provided by the project, >>>>> and Gluster now is a part of the RHT. >>>> I believe there needs to be an indication which service this is >>>> about. >>>> If we will support provisioning other storage types which also >>>> have >>>> volumes then we'd want a way to differentiate. >>>> However, isn't there a way to simply add gluster as the name >>>> space? >>>> i.e. somthing like: /api/gluster/.../volumes ? (instead of >>>> 'cluster' >>>> as it is redundant imho) >>> >>> A gluster volume is a cluster level entity, and hence >>> "/api/.../clusters/{cluster:id}" seems like the right parent URI >>> for the >>> gluster volumes collection resource. >> >> that's true for all other root entities as well: >> - VM is DC/cluster level >> - template is DC level >> - disk is storage domain level >> - network is DC level >> - hosts are cluster level (for now) >> >> yet all of them have their own root collections as well. >> >> I think glustervolumes seems safest/most reasonable for now (either >> at >> cluster level or root level as well) > > does it make sense to also have gluster/bricks ? if so, I would nest it, i.e. gluster/{volumes|bricks|...} bricks are host level, afair they are not used like this at all. gluster/xxx is interesting as well, though not parallel to current virt mappings (storage_domains, disks, etc., being root collections) shireesh - any thoughts about this approach: - do you want volumes as root collection, or only under cluster - if root, should these be glustervolumes like other root collection, or the under a gluster collection. From oliel at redhat.com Tue May 8 06:19:36 2012 From: oliel at redhat.com (Ori Liel) Date: Tue, 08 May 2012 02:19:36 -0400 (EDT) Subject: [Engine-devel] restapi: 'gluster' prefix In-Reply-To: <4FA8ABDD.9070403@redhat.com> Message-ID: >On 05/07/2012 11:52 PM, Ayal Baron wrote: >> >> >> ----- Original Message ----- >>> On 05/07/2012 07:06 PM, Shireesh Anjal wrote: >>>> On Monday 07 May 2012 02:06 AM, Ayal Baron wrote: >>>>> >>>>> ----- Original Message ----- >>>>>> i can't see any justification for the 'gluster' prefix, >>>>>> as this is only additional /service/ provided by the project, >>>>>> and Gluster now is a part of the RHT. >>>>> I believe there needs to be an indication which service this is >>>>> about. >>>>> If we will support provisioning other storage types which also >>>>> have >>>>> volumes then we'd want a way to differentiate. >>>>> However, isn't there a way to simply add gluster as the name >>>>> space? >>>>> i.e. somthing like: /api/gluster/.../volumes ? (instead of >>>>> 'cluster' >>>>> as it is redundant imho) >>>> >>>> A gluster volume is a cluster level entity, and hence >>>> "/api/.../clusters/{cluster:id}" seems like the right parent URI >>>> for the >>>> gluster volumes collection resource. >>> >>> that's true for all other root entities as well: >>> - VM is DC/cluster level >>> - template is DC level >>> - disk is storage domain level >>> - network is DC level >>> - hosts are cluster level (for now) >>> >>> yet all of them have their own root collections as well. >>> >>> I think glustervolumes seems safest/most reasonable for now (either >>> at >>> cluster level or root level as well) >> >> does it make sense to also have gluster/bricks ? if so, I would nest it, i.e. gluster/{volumes|bricks|...} > >bricks are host level, afair they are not used like this at all. >gluster/xxx is interesting as well, though not parallel to current virt >mappings (storage_domains, disks, etc., being root collections) >shireesh - any thoughts about this approach: >- do you want volumes as root collection, or only under cluster >- if root, should these be glustervolumes like other root collection, or >the under a gluster collection. According to Geert, a key question in deciding whether gluster-volumes should exist in root collection is: are volumes potentially moveable between clusters? The answer, according to Shireesh, is no, and therefore Geert believes that the volumes should be under cluster. (Geert or Shireesh - if I misquoted you, please correct me). Bricks logically compose volumes, and thus are modelled under volumes. >_______________________________________________ >Engine-devel mailing list >Engine-devel at ovirt.org >http://lists.ovirt.org/mailman/listinfo/engine-devel From sanjal at redhat.com Tue May 8 07:46:30 2012 From: sanjal at redhat.com (Shireesh Anjal) Date: Tue, 08 May 2012 13:16:30 +0530 Subject: [Engine-devel] restapi: 'gluster' prefix In-Reply-To: <4FA8ABDD.9070403@redhat.com> References: <621b9b66-5c2f-4bf2-8d93-553128fb2c0e@zmail13.collab.prod.int.phx2.redhat.com> <4FA8ABDD.9070403@redhat.com> Message-ID: <4FA8CF56.4080409@redhat.com> On Tuesday 08 May 2012 10:45 AM, Itamar Heim wrote: > On 05/07/2012 11:52 PM, Ayal Baron wrote: >> >> >> ----- Original Message ----- >>> On 05/07/2012 07:06 PM, Shireesh Anjal wrote: >>>> On Monday 07 May 2012 02:06 AM, Ayal Baron wrote: >>>>> >>>>> ----- Original Message ----- >>>>>> i can't see any justification for the 'gluster' prefix, >>>>>> as this is only additional /service/ provided by the project, >>>>>> and Gluster now is a part of the RHT. >>>>> I believe there needs to be an indication which service this is >>>>> about. >>>>> If we will support provisioning other storage types which also >>>>> have >>>>> volumes then we'd want a way to differentiate. >>>>> However, isn't there a way to simply add gluster as the name >>>>> space? >>>>> i.e. somthing like: /api/gluster/.../volumes ? (instead of >>>>> 'cluster' >>>>> as it is redundant imho) >>>> >>>> A gluster volume is a cluster level entity, and hence >>>> "/api/.../clusters/{cluster:id}" seems like the right parent URI >>>> for the >>>> gluster volumes collection resource. >>> >>> that's true for all other root entities as well: >>> - VM is DC/cluster level >>> - template is DC level >>> - disk is storage domain level >>> - network is DC level >>> - hosts are cluster level (for now) >>> >>> yet all of them have their own root collections as well. >>> >>> I think glustervolumes seems safest/most reasonable for now (either >>> at >>> cluster level or root level as well) >> >> does it make sense to also have gluster/bricks ? if so, I would nest >> it, i.e. gluster/{volumes|bricks|...} > > bricks are host level, afair they are not used like this at all. Though bricks reside inside a host, they are logically part of a gluster volume, and hence should be sub-resources of the volume. [/api/.../(gluster)volumes/{(gluster)volume:id}/bricks]. > gluster/xxx is interesting as well, though not parallel to current > virt mappings (storage_domains, disks, etc., being root collections) Separate gluster namespace does sound interesting, however it may not be feasible because we want the gluster volumes to be a collection sub-resource of the existing "cluster" resource. It can work if all the existing resources relevant to gluster are made available under it, which includes clusters and hosts. e.g. /api/gluster/clusters/{cluster:id}/hosts/{host:id}/... /api/gluster/clusters/{cluster:id}/volumes/{volume:id}/... It'll be interesting to see what others think about this. > shireesh - any thoughts about this approach: > - do you want volumes as root collection, or only under cluster Root collection for gluster volumes could be useful, though not critically important right now. We can revisit this at a later point of time. > - if root, should these be glustervolumes like other root collection, > or the under a gluster collection. This depends on whether we decide to go with the gluster namespace or not. > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel Thanks, Shireesh From dfediuck at redhat.com Tue May 8 07:50:49 2012 From: dfediuck at redhat.com (Doron Fediuck) Date: Tue, 08 May 2012 10:50:49 +0300 Subject: [Engine-devel] [vdsm] RFD: NEW API getAllTasks In-Reply-To: <20120507183331.GQ11658@aglitke.ibm.com> References: <20120507183331.GQ11658@aglitke.ibm.com> Message-ID: <4FA8D059.7020801@redhat.com> On 07/05/12 21:33, Adam Litke wrote: > The current APIs for retrieving all task information do not actually return all > task information. I would like to introduce a new API that corrects this and > other issues with the current API while preserving backwards compatibility with > ovirt-engine for as long as is necessary. > > The current APIs: > > getAllTasksInfo(spUUID=None, options = None): > - Returns a dictionary that maps a task UUID to a task verb. > - Despite having 'all' in the name, this API only returns tasks that have an > 'spm' tag. > - This call returns only one piece of information for each task. > - The spUUID parameter is deprecated and ignored. > > getAllTasksStatuses(spUUID=None, options = None): > - Returns a dictionary of task status information. > - Despite having 'all' in the name, this API only returns tasks that have an > 'spm' tag. > - The spUUID parameter is deprecated and ignored. > > > I propose the following new API: > > getAllTasks(tag=None, options=None): > - Returns a dictionary of task information. The info from both of the above > functions would be merged into a single result set. > - If tag is None, all tasks are returned. otherwise, only tasks matching the > tag are returned. > - The spUUID parameter is dropped. options is for future extension and is > currently not used. > > This new API includes all functionality that is available in the old calls. In > the future, ovirt-engine could switch to this API and preserve the current > semantics by passing tag='spm' to getAllTasks. Meanwhile, API users that really > want all tasks (gluster and the REST API) can get what they need. > > Thoughts on this idea? > (Adding engine-devel, as this relates to the engine API). AFAIR, in the original design (when a-sync tasks where introduced into vdsm), most (if not all) of the tasks were SPM tasks, and this is the reason for this behavior. Improving the API is welcomed. The suggested design should work. I'd like to verify: - Backwards compatibility works; so running engine's shouldn't be replaced. Dan: any news on this? - Going forward with potential changes in SPM concepts should be supported as well. Dan/Ayal/Livnat: do you think it works? ie- anything else needed than alternate 'spm' tag? -- /d "All computers wait at the same speed." From ovedo at redhat.com Tue May 8 08:29:48 2012 From: ovedo at redhat.com (Oved Ourfalli) Date: Tue, 08 May 2012 04:29:48 -0400 (EDT) Subject: [Engine-devel] Supporting native USB in oVirt In-Reply-To: <4FA8CFD0.90907@redhat.com> Message-ID: <7633dc0e-4268-4954-88ef-409cc1f093c7@zmail02.collab.prod.int.phx2.redhat.com> cc-ing engine-devel. Oved ----- Original Message ----- > From: "Hans de Goede" > To: "Oved Ourfalli" > Cc: "Dave Allan" , "Jiri Denemark" , "Michal Privoznik" > , "Itamar Heim" , "Igor Lvovsky" , "Eli Mesika" > , "Dan Kenigsberg" , "Andrew Cathrow" > Sent: Tuesday, May 8, 2012 10:48:32 AM > Subject: Re: Supporting native USB in oVirt > > Hi, > > On 05/08/2012 09:19 AM, Oved Ourfalli wrote: > > Hi, > > > > We are now working on adding the support for native USB devices on > > oVirt. > > As far as we understand, in order to use it we need to pass the > > following devices with the following restrictions (according to > > the EHCI spec): > > 1. EHCI USB controller - with the highest function number, #7. > > > > devices='{type:controller,device:usb,model:ich9-ehci1,address:{type:pci,domain:0x0000,bus:0x00,slot:0x04,function:0x7}}' > > > > 2. 3 UHCI USB controllers, on the same bus and PCI slot as the EHCI > > controller. Set the multifunction bit to on, on the controller > > with function #0. > > > > devices='{type:controller,device:usb,model:ich9-uhci1,master:{startport:0},address:{type:pci,domain:0x0000,bus:0x00,slot:0x04,function:0x0,multifunction:on}}' > > devices='{type:controller,device:usb,model:ich9-uhci2,master:{startport:2},address:{type:pci,domain:0x0000,bus:0x00,slot:0x04,function:0x1}}' > > devices='{type:controller,device:usb,model:ich9-uhci3,master:{startport:4},address:{type:pci,domain:0x0000,bus:0x00,slot:0x04,function:0x2}}' > > > > 3. USB redirect devices (according to the needed number of USB > > slots, maximum 6) on the same bus, each one having a different > > port. > > > > devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:1}}' > > devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:2}}' > > devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:3}}' > > devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:4}}' > > devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:5}}' > > devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:6}}' > > > > To the best of my knowledge, the above is all correct. > > > 4. If we want more than 6 USB slots, we need to have 2 EHCI > > controllers, and 6 UHCI controllers, that are consistent with the > > restrictions above, on different bus. > > (we need them to be on different bus, since the connection between > > the redirect devices and the controllers is the bus). > > Correct, note that this may change in the future. Specifically I'm > thinking about > adding support for USB-2 hubs, and then have libvirt automatically > add new > redir-devices when all but one are in use. This is all just an idea > at the moment, > so don't count on it, I just wanted you to know that we are thinking > about making > it easier to make the number of devices dynamic in the future. So for > now you > could consider simply limiting redirection to max 6 devices. > > > According to Hans (cc-ed), if we let libvirt pick its own > > addresses, it will put each controller of the composite USB > > controller device on its own pci slot, which is a violation of the > > EHCI spec. > > Correct. > > > The problem is that the oVirt engine is not aware of addresses. They aren't managed by it. > > They are chosen automatically by libvirt, returned to the engine, and they saved in the engine database in order to provide the ability to retain the same PCI addresses after VM restart. > > > >So, in order to support the EHCI spec, oVirt will have to be aware of addresses, manage them (allocate them, check for collisions, update on every libvirt change regarding that, etc...). Obviously, it doesn't feel right, and in fact it is also not feasible, to manage these addresses in the oVirt domain. > > > > Is all the above correct, or are we missing something? > > If so, can you address the issues above, and provide the ability to manage these devices in libvirt? > Regards, > > Hans > From hkran at linux.vnet.ibm.com Tue May 8 08:58:56 2012 From: hkran at linux.vnet.ibm.com (Hui Kai Ran) Date: Tue, 08 May 2012 16:58:56 +0800 Subject: [Engine-devel] auth issue Message-ID: <4FA8E050.80500@linux.vnet.ibm.com> Hi, all When I access the REST API like this ==================================== import urllib2 theurl = 'http://9.181.129.112:8080/api' username = 'admin at internal' password = 'abcd1234' # a great password passman = urllib2.HTTPPasswordMgrWithDefaultRealm() passman.add_password('ENGINE', theurl, username, password) authhandler = urllib2.HTTPBasicAuthHandler(passman) opener = urllib2.build_opener(authhandler) urllib2.install_opener(opener) pagehandle = urllib2.urlopen(theurl) ========================================= urlopen failed. then We do that another way like this, it is ok ======================================== import urllib2 import sys import re import base64 import xml.etree.ElementTree as etree username='admin at internal' password='abcd1234' request = urllib2.Request("http://9.181.129.112:8080/api") base64string = base64.encodestring('%s:%s' % (username, password)).replace('\n', '') request.add_header("Authorization", "Basic %s" % base64string) result = urllib2.urlopen(request) by catching the packets transfered, we found the response from ovirt-engine server as below for failing case: ================================================================ GET /api HTTP/1.1 Accept-Encoding: identity Host: 9.181.129.112:8080 Connection: close User-Agent: Python-urllib/2.7 HTTP/1.1 401 Unauthorized Server: Apache-Coyote/1.1 WWW-Authenticate: Basic realm = "ENGINE" Content-Type: text/html;charset=utf-8 Content-Length: 956 Date: Fri, 04 May 2012 09:18:06 GMT Connection: close Is there anything wrong for oVirt-engine? Thanks! From eglynn at redhat.com Tue May 8 09:00:35 2012 From: eglynn at redhat.com (Eoghan Glynn) Date: Tue, 08 May 2012 05:00:35 -0400 (EDT) Subject: [Engine-devel] REST-API: Exposing correlation-ID In-Reply-To: Message-ID: <0974b097-0730-4057-8a92-637593309ce5@zmail11.collab.prod.int.phx2.redhat.com> > >> >> 1) what's the name you'd give this parameter? job-id? batch-id? > >> >> flow-id? command-id? correlation-id??? > >> > >> job-id will confuse us with engine's job-id which is a single > >> command > >> today. > >> correleation-id is pretty long and confusing as implies on > >> correlation > >> of something. > >> > >> I'm for flow-id or batch-id. > >> batch-id sounds the right one to me, as this is identifying a > >> batch > >> of > >> calls. > > >How about log-id? > >It isn't supposed to be unique, or of any format, it's just used to > >log calls, so log-id is the most natural (or log-tag or whatever > >name you prefer). > > > >Also I think it's more of a header-type parameter since it's > >metadata for the call, not an actual parameter that influences the > >outcome of the "flow". > > I actually believe you're right, it probably is better to pass this parameter as > an http header. You've changed my mind about this (objections, anyone, to passing > it as a header as opposed to passing it as a url parameter)? Agree also that a header is much more natural in this case than a URL parameter. Also in the case where the client does not specify the ID themselves on the initial request, a generated value should be returned as response header (so that this can be passed as request header with the next request if part of the same over-arching task, or else just to aid log interpretation if the initial request was standalone but still mapped internally to multiple backend actions). > About log_id - it could sound like there are numerous logs, and the user is asked > to specify the ID of the log he wishes to write to. But perhaps: log_entry_id? Is there any possibility that this identifier may be leveraged for uses other than log interpretation? One other suggestion to add into the mix: MetaTask-ID. Cheers, Eoghan From emesika at redhat.com Tue May 8 09:05:42 2012 From: emesika at redhat.com (Eli Mesika) Date: Tue, 08 May 2012 05:05:42 -0400 (EDT) Subject: [Engine-devel] Supporting native USB in oVirt In-Reply-To: <20120508084124.GA3927@redhat.com> Message-ID: <1520c0a6-cc0c-41ec-92eb-3ea38e008d8f@zmail13.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Dan Kenigsberg" > To: "Oved Ourfalli" , "Dave Allan" > Cc: "Dave Allan" , "Jiri Denemark" , "Michal Privoznik" > , "Itamar Heim" , "Igor Lvovsky" , "Eli Mesika" > , "Hans de Goede" , "Andrew Cathrow" > Sent: Tuesday, May 8, 2012 11:41:25 AM > Subject: Re: Supporting native USB in oVirt > > On Tue, May 08, 2012 at 03:19:32AM -0400, Oved Ourfalli wrote: > > Hi, > > > > We are now working on adding the support for native USB devices on > > oVirt. > > As far as we understand, in order to use it we need to pass the > > following devices with the following restrictions (according to > > the EHCI spec): > > 1. EHCI USB controller - with the highest function number, #7. > > > > devices='{type:controller,device:usb,model:ich9-ehci1,address:{type:pci,domain:0x0000,bus:0x00,slot:0x04,function:0x7}}' > > > > 2. 3 UHCI USB controllers, on the same bus and PCI slot as the EHCI > > controller. Set the multifunction bit to on, on the controller > > with function #0. > > > > devices='{type:controller,device:usb,model:ich9-uhci1,master:{startport:0},address:{type:pci,domain:0x0000,bus:0x00,slot:0x04,function:0x0,multifunction:on}}' > > devices='{type:controller,device:usb,model:ich9-uhci2,master:{startport:2},address:{type:pci,domain:0x0000,bus:0x00,slot:0x04,function:0x1}}' > > devices='{type:controller,device:usb,model:ich9-uhci3,master:{startport:4},address:{type:pci,domain:0x0000,bus:0x00,slot:0x04,function:0x2}}' > > I'd like to make it clear that the suggested API request Engine to > pass > a "master" attribute for the controller device, with a nested > dictionary > within. This makes sense, as I am certain that libvirt's modeling of > the > device has merits. However, AFAIK Engine does not do stuff like that > at > the momemnt. And should not do in future IMHO, this should be transparent to the engine core that should know only the USB device. > > > > > 3. USB redirect devices (according to the needed number of USB > > slots, maximum 6) on the same bus, each one having a different > > port. > > > > devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:1}}' > > devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:2}}' > > devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:3}}' > > devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:4}}' > > devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:5}}' > > devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:6}}' > > > > 4. If we want more than 6 USB slots, we need to have 2 EHCI > > controllers, and 6 UHCI controllers, that are consistent with the > > restrictions above, on different bus. > > (we need them to be on different bus, since the connection between > > the redirect devices and the controllers is the bus). > > > > According to Hans (cc-ed), if we let libvirt pick its own > > addresses, it will put each controller of the composite USB > > controller device on its own pci slot, which is a violation of the > > EHCI spec. > > Is there an open libvirt bug for this? > > > > > The problem is that the oVirt engine is not aware of addresses. > > They aren't managed by it. > > They are chosen automatically by libvirt, returned to the engine, > > and they saved in the engine database in order to provide the > > ability to retain the same PCI addresses after VM restart. > > Yes, we should be able to trust libvirt's assignement, certainly for > the > masses of VMs. Few VMs of certain customer may want to tweak the > location of their devices. Maybe Engine does not need to expose this > feature at the moment (I think it is better that each device address > is > considered a "blob" by Engine), but the Engine/Vdsm API should > support > that. I know that in future we may need to tweak the device location. But still, the general principle of address allocation should be kept simple: If you send an address, this address is honored by libvirt If you don't, you will get a valid one from libvirt. I think that engine should not handle any addresses apart from persisting the address in DB. > > > > > So, in order to support the EHCI spec, oVirt will have to be aware > > of addresses, manage them (allocate them, check for collisions, > > update on every libvirt change regarding that, etc...). Obviously, > > it doesn't feel right, and in fact it is also not feasible, to > > manage these addresses in the oVirt domain. > > That's not obvious to me. Engine could have a hard-coded addresses > for > the usb device gang. Libvirt could arrange the rest of the devices > around it, so Engine should not worry about collisions. Libvirt's > stable > API relieves Engine from worrying about "every libvirt change > regarding > that" - it is libvirt responsibility to make sure that every future > libvirt version would handle the USB addresses properly. A big hole for future bugs that will fall between libvirt & engine responsibility. I don't like that idea of spreading responsibilities between separate components and prefer that addresses will have one manager that is obviously libvirt. > > > > > Is all the above correct, or are we missing something? > > If so, can you address the issues above, and provide the ability to > > manage these devices in libvirt? > > > > Regards, > > Oved > From iheim at redhat.com Tue May 8 09:11:11 2012 From: iheim at redhat.com (Itamar Heim) Date: Tue, 08 May 2012 12:11:11 +0300 Subject: [Engine-devel] restapi: 'gluster' prefix In-Reply-To: <4FA802C5.8060408@redhat.com> References: <912036c6-0568-4f82-9434-9926ad0b6793@zmail13.collab.prod.int.phx2.redhat.com> <4FA7F315.2090909@redhat.com> <4FA802C5.8060408@redhat.com> Message-ID: <4FA8E32F.70503@redhat.com> On 05/07/2012 08:13 PM, Itamar Heim wrote: > On 05/07/2012 07:06 PM, Shireesh Anjal wrote: >> On Monday 07 May 2012 02:06 AM, Ayal Baron wrote: >>> >>> ----- Original Message ----- >>>> i can't see any justification for the 'gluster' prefix, >>>> as this is only additional /service/ provided by the project, >>>> and Gluster now is a part of the RHT. >>> I believe there needs to be an indication which service this is about. >>> If we will support provisioning other storage types which also have >>> volumes then we'd want a way to differentiate. >>> However, isn't there a way to simply add gluster as the name space? >>> i.e. somthing like: /api/gluster/.../volumes ? (instead of 'cluster' >>> as it is redundant imho) >> >> A gluster volume is a cluster level entity, and hence >> "/api/.../clusters/{cluster:id}" seems like the right parent URI for the >> gluster volumes collection resource. > > that's true for all other root entities as well: > - VM is DC/cluster level > - template is DC level > - disk is storage domain level > - network is DC level > - hosts are cluster level (for now) > > yet all of them have their own root collections as well. > > I think glustervolumes seems safest/most reasonable for now (either at > cluster level or root level as well) thinking about this some more, I'm for cluster/xxx/gluster_volumes. reasoning: 1. use gluster_volumes for now avoids potential conflicts with non-gluster volumes 2. start under cluster entity or root collection going with the argument of can the entity move (host and vm can move, but a gluster_volume cannot move between clusters), I'm for going with gluster_volumes under the cluster entity, and not the root collection. From juan.hernandez at redhat.com Tue May 8 09:12:54 2012 From: juan.hernandez at redhat.com (Juan Hernandez) Date: Tue, 08 May 2012 11:12:54 +0200 Subject: [Engine-devel] auth issue In-Reply-To: <4FA8E050.80500@linux.vnet.ibm.com> References: <4FA8E050.80500@linux.vnet.ibm.com> Message-ID: <4FA8E396.2010700@redhat.com> On 05/08/2012 10:58 AM, Hui Kai Ran wrote: > Hi, all > > When I access the REST API like this > ==================================== > import urllib2 > theurl = 'http://9.181.129.112:8080/api' > username = 'admin at internal' > password = 'abcd1234' > # a great password > > passman = urllib2.HTTPPasswordMgrWithDefaultRealm() > > passman.add_password('ENGINE', theurl, username, password) > > authhandler = urllib2.HTTPBasicAuthHandler(passman) > > opener = urllib2.build_opener(authhandler) > > urllib2.install_opener(opener) > pagehandle = urllib2.urlopen(theurl) > ========================================= > urlopen failed. > > then We do that another way like this, it is ok > ======================================== > import urllib2 > import sys > import re > import base64 > import xml.etree.ElementTree as etree > > username='admin at internal' > password='abcd1234' > > request = urllib2.Request("http://9.181.129.112:8080/api") > base64string = base64.encodestring('%s:%s' % (username, > password)).replace('\n', '') > request.add_header("Authorization", "Basic %s" % base64string) > result = urllib2.urlopen(request) > > by catching the packets transfered, we found the response from > ovirt-engine server as below for failing case: > ================================================================ > GET /api HTTP/1.1 > Accept-Encoding: identity > Host: 9.181.129.112:8080 > Connection: close > User-Agent: Python-urllib/2.7 > > HTTP/1.1 401 Unauthorized > Server: Apache-Coyote/1.1 > WWW-Authenticate: Basic realm = "ENGINE" > Content-Type: text/html;charset=utf-8 > Content-Length: 956 > Date: Fri, 04 May 2012 09:18:06 GMT > Connection: close > > Is there anything wrong for oVirt-engine? Yes, this is a known issue that has been recently fixed: http://gerrit.ovirt.org/3925 From iheim at redhat.com Tue May 8 09:40:25 2012 From: iheim at redhat.com (Itamar Heim) Date: Tue, 08 May 2012 12:40:25 +0300 Subject: [Engine-devel] REST-API: Exposing correlation-ID In-Reply-To: <0974b097-0730-4057-8a92-637593309ce5@zmail11.collab.prod.int.phx2.redhat.com> References: <0974b097-0730-4057-8a92-637593309ce5@zmail11.collab.prod.int.phx2.redhat.com> Message-ID: <4FA8EA09.6080605@redhat.com> On 05/08/2012 12:00 PM, Eoghan Glynn wrote: > > >>>>>> 1) what's the name you'd give this parameter? job-id? batch-id? >>>>>> flow-id? command-id? correlation-id??? >>>> >>>> job-id will confuse us with engine's job-id which is a single >>>> command >>>> today. >>>> correleation-id is pretty long and confusing as implies on >>>> correlation >>>> of something. >>>> >>>> I'm for flow-id or batch-id. >>>> batch-id sounds the right one to me, as this is identifying a >>>> batch >>>> of >>>> calls. >> >>> How about log-id? >>> It isn't supposed to be unique, or of any format, it's just used to >>> log calls, so log-id is the most natural (or log-tag or whatever >>> name you prefer). >>> >>> Also I think it's more of a header-type parameter since it's >>> metadata for the call, not an actual parameter that influences the >>> outcome of the "flow". >> >> I actually believe you're right, it probably is better to pass this parameter as >> an http header. You've changed my mind about this (objections, anyone, to passing >> it as a header as opposed to passing it as a url parameter)? > > Agree also that a header is much more natural in this case than a URL parameter. > > Also in the case where the client does not specify the ID themselves on the > initial request, a generated value should be returned as response header > (so that this can be passed as request header with the next request if part > of the same over-arching task, or else just to aid log interpretation if the > initial request was standalone but still mapped internally to multiple backend > actions). > > >> About log_id - it could sound like there are numerous logs, and the user is asked >> to specify the ID of the log he wishes to write to. But perhaps: log_entry_id? > > Is there any possibility that this identifier may be leveraged for uses other than > log interpretation? > > One other suggestion to add into the mix: MetaTask-ID. the one thing mentioned in the thread and worth remembering is this ID is not unique, as client can set it as they want. From agl at us.ibm.com Tue May 8 12:25:46 2012 From: agl at us.ibm.com (Adam Litke) Date: Tue, 8 May 2012 07:25:46 -0500 Subject: [Engine-devel] [vdsm] RFD: NEW API getAllTasks In-Reply-To: <4FA8D059.7020801@redhat.com> References: <20120507183331.GQ11658@aglitke.ibm.com> <4FA8D059.7020801@redhat.com> Message-ID: <20120508122546.GS11658@aglitke.ibm.com> On Tue, May 08, 2012 at 10:50:49AM +0300, Doron Fediuck wrote: > On 07/05/12 21:33, Adam Litke wrote: > > The current APIs for retrieving all task information do not actually return all > > task information. I would like to introduce a new API that corrects this and > > other issues with the current API while preserving backwards compatibility with > > ovirt-engine for as long as is necessary. > > > > The current APIs: > > > > getAllTasksInfo(spUUID=None, options = None): > > - Returns a dictionary that maps a task UUID to a task verb. > > - Despite having 'all' in the name, this API only returns tasks that have an > > 'spm' tag. > > - This call returns only one piece of information for each task. > > - The spUUID parameter is deprecated and ignored. > > > > getAllTasksStatuses(spUUID=None, options = None): > > - Returns a dictionary of task status information. > > - Despite having 'all' in the name, this API only returns tasks that have an > > 'spm' tag. > > - The spUUID parameter is deprecated and ignored. > > > > > > I propose the following new API: > > > > getAllTasks(tag=None, options=None): > > - Returns a dictionary of task information. The info from both of the above > > functions would be merged into a single result set. > > - If tag is None, all tasks are returned. otherwise, only tasks matching the > > tag are returned. > > - The spUUID parameter is dropped. options is for future extension and is > > currently not used. > > > > This new API includes all functionality that is available in the old calls. In > > the future, ovirt-engine could switch to this API and preserve the current > > semantics by passing tag='spm' to getAllTasks. Meanwhile, API users that really > > want all tasks (gluster and the REST API) can get what they need. > > > > Thoughts on this idea? > > > > (Adding engine-devel, as this relates to the engine API). > > AFAIR, in the original design (when a-sync tasks where introduced into vdsm), > most (if not all) of the tasks were SPM tasks, and this is the reason for this > behavior. > > Improving the API is welcomed. The suggested design should work. > I'd like to verify: > > - Backwards compatibility works; so running engine's shouldn't be replaced. > Dan: any news on this? Yes, we should make sure that future versions of ovirt-engine that would want to adopt this new API will have the behavior that they will need. For now, I plan to keep around the current/original APIs until they can be removed as part of a deprication plan in a few years. > - Going forward with potential changes in SPM concepts should be supported as well. > Dan/Ayal/Livnat: do you think it works? ie- anything else needed than alternate 'spm' tag? > -- > > /d > > "All computers wait at the same speed." > -- Adam Litke IBM Linux Technology Center From lpeer at redhat.com Wed May 9 08:17:11 2012 From: lpeer at redhat.com (Livnat Peer) Date: Wed, 09 May 2012 11:17:11 +0300 Subject: [Engine-devel] ovirt engine sync call Message-ID: <4FAA2807.8000805@redhat.com> Hi, If you have something you think should be discussed today in the engine core sync call let me know and we'll add it to the agenda. Thanks, Livnat From mpastern at redhat.com Wed May 9 08:36:54 2012 From: mpastern at redhat.com (Michael Pasternak) Date: Wed, 09 May 2012 11:36:54 +0300 Subject: [Engine-devel] auth issue In-Reply-To: <4FA8E050.80500@linux.vnet.ibm.com> References: <4FA8E050.80500@linux.vnet.ibm.com> Message-ID: <4FAA2CA6.2040902@redhat.com> Hey, We have official python SDK [1], i think it's worth for you using it as HTTP abstraction layer. [1] http://www.ovirt.org/wiki/SDK On 05/08/2012 11:58 AM, Hui Kai Ran wrote: > Hi, all > > When I access the REST API like this > ==================================== > import urllib2 > theurl = 'http://9.181.129.112:8080/api' > username = 'admin at internal' > password = 'abcd1234' > # a great password > > passman = urllib2.HTTPPasswordMgrWithDefaultRealm() > > passman.add_password('ENGINE', theurl, username, password) > > authhandler = urllib2.HTTPBasicAuthHandler(passman) > > opener = urllib2.build_opener(authhandler) > > urllib2.install_opener(opener) > pagehandle = urllib2.urlopen(theurl) > ========================================= > urlopen failed. > > then We do that another way like this, it is ok > ======================================== > import urllib2 > import sys > import re > import base64 > import xml.etree.ElementTree as etree > > username='admin at internal' > password='abcd1234' > > request = urllib2.Request("http://9.181.129.112:8080/api") > base64string = base64.encodestring('%s:%s' % (username, password)).replace('\n', '') > request.add_header("Authorization", "Basic %s" % base64string) > result = urllib2.urlopen(request) > > by catching the packets transfered, we found the response from ovirt-engine server as below for failing case: > ================================================================ > GET /api HTTP/1.1 > Accept-Encoding: identity > Host: 9.181.129.112:8080 > Connection: close > User-Agent: Python-urllib/2.7 > > HTTP/1.1 401 Unauthorized > Server: Apache-Coyote/1.1 > WWW-Authenticate: Basic realm = "ENGINE" > Content-Type: text/html;charset=utf-8 > Content-Length: 956 > Date: Fri, 04 May 2012 09:18:06 GMT > Connection: close > > Is there anything wrong for oVirt-engine? > > Thanks! > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel -- Michael Pasternak RedHat, ENG-Virtualization R&D From mpastern at redhat.com Wed May 9 08:40:51 2012 From: mpastern at redhat.com (Michael Pasternak) Date: Wed, 09 May 2012 11:40:51 +0300 Subject: [Engine-devel] restapi: 'gluster' prefix In-Reply-To: <4FA8E32F.70503@redhat.com> References: <912036c6-0568-4f82-9434-9926ad0b6793@zmail13.collab.prod.int.phx2.redhat.com> <4FA7F315.2090909@redhat.com> <4FA802C5.8060408@redhat.com> <4FA8E32F.70503@redhat.com> Message-ID: <4FAA2D93.6030306@redhat.com> On 05/08/2012 12:11 PM, Itamar Heim wrote: > On 05/07/2012 08:13 PM, Itamar Heim wrote: >> On 05/07/2012 07:06 PM, Shireesh Anjal wrote: >>> On Monday 07 May 2012 02:06 AM, Ayal Baron wrote: >>>> >>>> ----- Original Message ----- >>>>> i can't see any justification for the 'gluster' prefix, >>>>> as this is only additional /service/ provided by the project, >>>>> and Gluster now is a part of the RHT. >>>> I believe there needs to be an indication which service this is about. >>>> If we will support provisioning other storage types which also have >>>> volumes then we'd want a way to differentiate. >>>> However, isn't there a way to simply add gluster as the name space? >>>> i.e. somthing like: /api/gluster/.../volumes ? (instead of 'cluster' >>>> as it is redundant imho) >>> >>> A gluster volume is a cluster level entity, and hence >>> "/api/.../clusters/{cluster:id}" seems like the right parent URI for the >>> gluster volumes collection resource. >> >> that's true for all other root entities as well: >> - VM is DC/cluster level >> - template is DC level >> - disk is storage domain level >> - network is DC level >> - hosts are cluster level (for now) >> >> yet all of them have their own root collections as well. >> >> I think glustervolumes seems safest/most reasonable for now (either at >> cluster level or root level as well) > > thinking about this some more, I'm for > > cluster/xxx/gluster_volumes. > > reasoning: > 1. use gluster_volumes for now > avoids potential conflicts with non-gluster volumes why not having type in volume?, > > 2. start under cluster entity or root collection > going with the argument of can the entity move (host and vm can move, but a gluster_volume cannot move between clusters), I'm for going with gluster_volumes under the > cluster entity, and not the root collection. +1 > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel -- Michael Pasternak RedHat, ENG-Virtualization R&D From iheim at redhat.com Wed May 9 08:35:58 2012 From: iheim at redhat.com (Itamar Heim) Date: Wed, 09 May 2012 11:35:58 +0300 Subject: [Engine-devel] restapi: 'gluster' prefix In-Reply-To: <4FAA2D93.6030306@redhat.com> References: <912036c6-0568-4f82-9434-9926ad0b6793@zmail13.collab.prod.int.phx2.redhat.com> <4FA7F315.2090909@redhat.com> <4FA802C5.8060408@redhat.com> <4FA8E32F.70503@redhat.com> <4FAA2D93.6030306@redhat.com> Message-ID: <4FAA2C6E.5000502@redhat.com> On 05/09/2012 11:40 AM, Michael Pasternak wrote: > On 05/08/2012 12:11 PM, Itamar Heim wrote: >> On 05/07/2012 08:13 PM, Itamar Heim wrote: >>> On 05/07/2012 07:06 PM, Shireesh Anjal wrote: >>>> On Monday 07 May 2012 02:06 AM, Ayal Baron wrote: >>>>> >>>>> ----- Original Message ----- >>>>>> i can't see any justification for the 'gluster' prefix, >>>>>> as this is only additional /service/ provided by the project, >>>>>> and Gluster now is a part of the RHT. >>>>> I believe there needs to be an indication which service this is about. >>>>> If we will support provisioning other storage types which also have >>>>> volumes then we'd want a way to differentiate. >>>>> However, isn't there a way to simply add gluster as the name space? >>>>> i.e. somthing like: /api/gluster/.../volumes ? (instead of 'cluster' >>>>> as it is redundant imho) >>>> >>>> A gluster volume is a cluster level entity, and hence >>>> "/api/.../clusters/{cluster:id}" seems like the right parent URI for the >>>> gluster volumes collection resource. >>> >>> that's true for all other root entities as well: >>> - VM is DC/cluster level >>> - template is DC level >>> - disk is storage domain level >>> - network is DC level >>> - hosts are cluster level (for now) >>> >>> yet all of them have their own root collections as well. >>> >>> I think glustervolumes seems safest/most reasonable for now (either at >>> cluster level or root level as well) >> >> thinking about this some more, I'm for >> >> cluster/xxx/gluster_volumes. >> >> reasoning: >> 1. use gluster_volumes for now >> avoids potential conflicts with non-gluster volumes > > why not having type in volume?, because the different volumes would be entirely different entities not resembling each other > >> >> 2. start under cluster entity or root collection >> going with the argument of can the entity move (host and vm can move, but a gluster_volume cannot move between clusters), I'm for going with gluster_volumes under the >> cluster entity, and not the root collection. > > +1 > >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel > > From oliel at redhat.com Wed May 9 08:40:51 2012 From: oliel at redhat.com (Ori Liel) Date: Wed, 09 May 2012 04:40:51 -0400 (EDT) Subject: [Engine-devel] restapi: 'gluster' prefix In-Reply-To: <4FAA2D93.6030306@redhat.com> Message-ID: <23cc7f79-3abb-4afb-bf74-bbea989d5318@zmail17.collab.prod.int.phx2.redhat.com> >On 05/08/2012 12:11 PM, Itamar Heim wrote: >> On 05/07/2012 08:13 PM, Itamar Heim wrote: >>> On 05/07/2012 07:06 PM, Shireesh Anjal wrote: >>>> On Monday 07 May 2012 02:06 AM, Ayal Baron wrote: >>>>> >>>>> ----- Original Message ----- >>>>>> i can't see any justification for the 'gluster' prefix, >>>>>> as this is only additional /service/ provided by the project, >>>>>> and Gluster now is a part of the RHT. >>>>> I believe there needs to be an indication which service this is about. >>>>> If we will support provisioning other storage types which also have >>>>> volumes then we'd want a way to differentiate. >>>>> However, isn't there a way to simply add gluster as the name space? >>>>> i.e. somthing like: /api/gluster/.../volumes ? (instead of 'cluster' >>>>> as it is redundant imho) >>>> >>>> A gluster volume is a cluster level entity, and hence >>>> "/api/.../clusters/{cluster:id}" seems like the right parent URI for the >>>> gluster volumes collection resource. >>> >>> that's true for all other root entities as well: >>> - VM is DC/cluster level >>> - template is DC level >>> - disk is storage domain level >>> - network is DC level >>> - hosts are cluster level (for now) >>> >>> yet all of them have their own root collections as well. >>> >>> I think glustervolumes seems safest/most reasonable for now (either at >>> cluster level or root level as well) >> >> thinking about this some more, I'm for >> >> cluster/xxx/gluster_volumes. >> >> reasoning: >> 1. use gluster_volumes for now >> avoids potential conflicts with non-gluster volumes > >why not having type in volume?, I think 'volume' entity is too complex for that. A different storage vendor may have a completely different concept of a volume; for example, his volume may not have a 'block' sub-collection, and may not have any 'options' associated with it, and instead have all sorts of other stuff. > >> >> 2. start under cluster entity or root collection >> going with the argument of can the entity move (host and vm can move, but a gluster_volume cannot move between clusters), I'm for going with gluster_volumes under the >> cluster entity, and not the root collection. > >+1 > >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel > > >-- > >Michael Pasternak >RedHat, ENG-Virtualization R&D >_______________________________________________ >Engine-devel mailing list >Engine-devel at ovirt.org >http://lists.ovirt.org/mailman/listinfo/engine-devel From mpastern at redhat.com Wed May 9 08:50:31 2012 From: mpastern at redhat.com (Michael Pasternak) Date: Wed, 09 May 2012 11:50:31 +0300 Subject: [Engine-devel] restapi: 'gluster' prefix In-Reply-To: <4FAA2C6E.5000502@redhat.com> References: <912036c6-0568-4f82-9434-9926ad0b6793@zmail13.collab.prod.int.phx2.redhat.com> <4FA7F315.2090909@redhat.com> <4FA802C5.8060408@redhat.com> <4FA8E32F.70503@redhat.com> <4FAA2D93.6030306@redhat.com> <4FAA2C6E.5000502@redhat.com> Message-ID: <4FAA2FD7.6000102@redhat.com> On 05/09/2012 11:35 AM, Itamar Heim wrote: > On 05/09/2012 11:40 AM, Michael Pasternak wrote: >> On 05/08/2012 12:11 PM, Itamar Heim wrote: >>> On 05/07/2012 08:13 PM, Itamar Heim wrote: >>>> On 05/07/2012 07:06 PM, Shireesh Anjal wrote: >>>>> On Monday 07 May 2012 02:06 AM, Ayal Baron wrote: >>>>>> >>>>>> ----- Original Message ----- >>>>>>> i can't see any justification for the 'gluster' prefix, >>>>>>> as this is only additional /service/ provided by the project, >>>>>>> and Gluster now is a part of the RHT. >>>>>> I believe there needs to be an indication which service this is about. >>>>>> If we will support provisioning other storage types which also have >>>>>> volumes then we'd want a way to differentiate. >>>>>> However, isn't there a way to simply add gluster as the name space? >>>>>> i.e. somthing like: /api/gluster/.../volumes ? (instead of 'cluster' >>>>>> as it is redundant imho) >>>>> >>>>> A gluster volume is a cluster level entity, and hence >>>>> "/api/.../clusters/{cluster:id}" seems like the right parent URI for the >>>>> gluster volumes collection resource. >>>> >>>> that's true for all other root entities as well: >>>> - VM is DC/cluster level >>>> - template is DC level >>>> - disk is storage domain level >>>> - network is DC level >>>> - hosts are cluster level (for now) >>>> >>>> yet all of them have their own root collections as well. >>>> >>>> I think glustervolumes seems safest/most reasonable for now (either at >>>> cluster level or root level as well) >>> >>> thinking about this some more, I'm for >>> >>> cluster/xxx/gluster_volumes. >>> >>> reasoning: >>> 1. use gluster_volumes for now >>> avoids potential conflicts with non-gluster volumes >> >> why not having type in volume?, > > because the different volumes would be entirely different entities not resembling each other it's still works for our api, as non relevant properties does not shown in resource representation, we using this concept all over the api. both gluster and non gluster resources still be volumes so it's also works from the REST P.o.V. i guess the question we should ask ourself if we really want to have collection peer technology rather than differentiating between technologies by type. > >> >>> >>> 2. start under cluster entity or root collection >>> going with the argument of can the entity move (host and vm can move, but a gluster_volume cannot move between clusters), I'm for going with gluster_volumes under the >>> cluster entity, and not the root collection. >> >> +1 >> >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel at ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >> >> > -- Michael Pasternak RedHat, ENG-Virtualization R&D From oliel at redhat.com Wed May 9 08:46:26 2012 From: oliel at redhat.com (Ori Liel) Date: Wed, 09 May 2012 04:46:26 -0400 (EDT) Subject: [Engine-devel] restapi: 'gluster' prefix In-Reply-To: <4FAA2FD7.6000102@redhat.com> Message-ID: <4b358e7c-e618-45d8-9b86-d68bbdbbfe8e@zmail17.collab.prod.int.phx2.redhat.com> >On 05/09/2012 11:35 AM, Itamar Heim wrote: >> On 05/09/2012 11:40 AM, Michael Pasternak wrote: >>> On 05/08/2012 12:11 PM, Itamar Heim wrote: >>>> On 05/07/2012 08:13 PM, Itamar Heim wrote: >>>>> On 05/07/2012 07:06 PM, Shireesh Anjal wrote: >>>>>> On Monday 07 May 2012 02:06 AM, Ayal Baron wrote: >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>>> i can't see any justification for the 'gluster' prefix, >>>>>>>> as this is only additional /service/ provided by the project, >>>>>>>> and Gluster now is a part of the RHT. >>>>>>> I believe there needs to be an indication which service this is about. >>>>>>> If we will support provisioning other storage types which also have >>>>>>> volumes then we'd want a way to differentiate. >>>>>>> However, isn't there a way to simply add gluster as the name space? >>>>>>> i.e. somthing like: /api/gluster/.../volumes ? (instead of 'cluster' >>>>>>> as it is redundant imho) >>>>>> >>>>>> A gluster volume is a cluster level entity, and hence >>>>>> "/api/.../clusters/{cluster:id}" seems like the right parent URI for the >>>>>> gluster volumes collection resource. >>>>> >>>>> that's true for all other root entities as well: >>>>> - VM is DC/cluster level >>>>> - template is DC level >>>>> - disk is storage domain level >>>>> - network is DC level >>>>> - hosts are cluster level (for now) >>>>> >>>>> yet all of them have their own root collections as well. >>>>> >>>>> I think glustervolumes seems safest/most reasonable for now (either at >>>>> cluster level or root level as well) >>>> >>>> thinking about this some more, I'm for >>>> >>>> cluster/xxx/gluster_volumes. >>>> >>>> reasoning: >>>> 1. use gluster_volumes for now >>>> avoids potential conflicts with non-gluster volumes >>> >>> why not having type in volume?, >> >> because the different volumes would be entirely different entities not resembling each other > >it's still works for our api, as non relevant properties does not shown in resource representation, >we using this concept all over the api. > properties - yes, but I'm afraid the sub-collections might be different and we don't have support for that >both gluster and non gluster resources still be volumes so it's also works from the REST P.o.V. > >i guess the question we should ask ourself if we really want to have collection peer technology >rather than differentiating between technologies by type. > >> >>> >>>> >>>> 2. start under cluster entity or root collection >>>> going with the argument of can the entity move (host and vm can move, but a gluster_volume cannot move between clusters), I'm for going with gluster_volumes under the >>>> cluster entity, and not the root collection. >>> >>> +1 >>> >>>> _______________________________________________ >>>> Engine-devel mailing list >>>> Engine-devel at ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> >>> >> > > >-- > >Michael Pasternak >RedHat, ENG-Virtualization R&D >_______________________________________________ >Engine-devel mailing list >Engine-devel at ovirt.org >http://lists.ovirt.org/mailman/listinfo/engine-devel From mpastern at redhat.com Wed May 9 08:58:48 2012 From: mpastern at redhat.com (Michael Pasternak) Date: Wed, 09 May 2012 11:58:48 +0300 Subject: [Engine-devel] restapi: 'gluster' prefix In-Reply-To: <4b358e7c-e618-45d8-9b86-d68bbdbbfe8e@zmail17.collab.prod.int.phx2.redhat.com> References: <4b358e7c-e618-45d8-9b86-d68bbdbbfe8e@zmail17.collab.prod.int.phx2.redhat.com> Message-ID: <4FAA31C8.7000008@redhat.com> On 05/09/2012 11:46 AM, Ori Liel wrote: >>>> why not having type in volume?, >>> >> >>> >> because the different volumes would be entirely different entities not resembling each other >> > >> >it's still works for our api, as non relevant properties does not shown in resource representation, >> >we using this concept all over the api. >> > > properties - yes, but I'm afraid the sub-collections might be different and we don't > have support for that > sub-collections is the different story, you can create two volumes inheriting from same base class and return them according to the context, but this is implementation detail. -- Michael Pasternak RedHat, ENG-Virtualization R&D From iheim at redhat.com Wed May 9 09:03:30 2012 From: iheim at redhat.com (Itamar Heim) Date: Wed, 09 May 2012 12:03:30 +0300 Subject: [Engine-devel] restapi: 'gluster' prefix In-Reply-To: <4FAA31C8.7000008@redhat.com> References: <4b358e7c-e618-45d8-9b86-d68bbdbbfe8e@zmail17.collab.prod.int.phx2.redhat.com> <4FAA31C8.7000008@redhat.com> Message-ID: <4FAA32E2.9080901@redhat.com> On 05/09/2012 11:58 AM, Michael Pasternak wrote: > On 05/09/2012 11:46 AM, Ori Liel wrote: >>>>> why not having type in volume?, >>>>>> >>>>>> because the different volumes would be entirely different entities not resembling each other >>>> >>>> it's still works for our api, as non relevant properties does not shown in resource representation, >>>> we using this concept all over the api. >>>> >> properties - yes, but I'm afraid the sub-collections might be different and we don't >> have support for that >> > > sub-collections is the different story, you can create two volumes inheriting from same > base class and return them according to the context, but this is implementation detail. > yes, but the question is why would entirely different entities will share the same type just because they are called in the same name in different projects. so gluster volumes is path of less resistance than trying to figure out how all future things which call themselves volumes will look like. we can revisit later and refactor/deprecate carry some backward compatibility as relevant. From oschreib at redhat.com Wed May 9 10:52:01 2012 From: oschreib at redhat.com (Ofer Schreiber) Date: Wed, 09 May 2012 06:52:01 -0400 (EDT) Subject: [Engine-devel] Using JBoss F17 RPMs In-Reply-To: <2d3ac953-57fd-4095-bf87-ecc06e0ea2a0@zmail14.collab.prod.int.phx2.redhat.com> Message-ID: As you probably know, we're aiming to use the new JBoss Fedora RPMs in the next version of oVirt. If anyone have some info (or patches, we love patches) on how to do this change right, we would like to know. Any input is appreciated. Thanks, --- Ofer Schreiber oVirt Release Manager From abaron at redhat.com Wed May 9 12:18:31 2012 From: abaron at redhat.com (Ayal Baron) Date: Wed, 09 May 2012 08:18:31 -0400 (EDT) Subject: [Engine-devel] [vdsm] Storage Device Management in VDSM and oVirt In-Reply-To: <4FA78CBE.4090300@linux.vnet.ibm.com> Message-ID: <76e684fb-dcde-4ed3-8698-8e576327f09b@zmail13.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > > >> This seems interesting. > >> > >> I am interested in pursuing this further and helping contribute to > >> the > >> vdsm lsm integration. lsm is still in the early stages, but i feel > >> its > >> the right time to start influencing it so that vdsm integration > >> can > >> be > >> smooth. My interest mainly lies in how external storage array can > >> be > >> integrated into oVirt/VDSM and help oVirt exploit the array > >> offload > >> features as part of the virtualization stack. > >> > >> I didn't find any oVirt wiki page on this topic, tho' there is a > >> old > >> mailing list thread on vdsm lsm integration, which when read > >> brings > >> up > >> more issues to discuss :) > >> How does storage repo engine and possible vdsm services framework > >> ( i > >> learnt about these in my brief chat with Saggie some time back) > >> play > >> a > >> role here ? > > Maybe Saggi could elaborate here. > > > >> Can "Provisioning Storage" itself be like a high level service, > >> with > >> gluster and lsm exposing storage services, which vdsm can > >> enumerate > >> and > >> send to oVirt GUI, is that the idea ? > > I'm not sure "Provisioning Storage" is a clear enough definition, > > as it could cover a lot of possibly unrelated things, but I'd need > > to understand more what you mean to really be able to comment > > properly. > > > > Well, I was envisioning oVirt as being able to provision and consume > storage, both, going ahead. > Provisioning thru' vdsm-libstoragemgmt (lsm) integration. oVirt user > should be able to carve out LUNs, > be able to associate the LUNs visibility to host(s) of a oVirt > cluster, > all via libstoragemgmt interfaces. > > With gluster being integrated into vdsm, oVirt user can provision and > manage gluster volumes soon, > which also falls under "provisioning storage", hence I was wondering > if > there would be a new tab > in oVirt for "provisioning storage", where gluster ( in near future) > and > external array/LUNs ( via > vdsm -lsm integration) can be provisioned. Ok, now I that I understand a little more, then in general I agree. First upstream oVirt already has the ability to provision gLuster (albeit still in a limited way) and definitely we will need more provisioning capabilities including for example setting up LIO on a host and exposing LUNs that would be available to other hosts/VMs (for one, live storage migration without shared disks would need this). Specifically wrt "Provisioning Storage" tab, that's more of a design question as there are going to be many services we will need to provision not all specifically around storage and I'm not sure that we'd want a new tab for every type. > > > >> Is there any wiki page on this topic which lists the todos on this > >> front, which I can start looking at ? > > Unfortunately there is not as we haven't sat down to plan it in > > depth, but you're more than welcome to start it. > > > > Generally, the idea is as follows: > > Currently vdsm has storage virtualization capabilites, i.e. we've > > implemented a form of thin-provisioning, we provide snapshots > > using qcow etc, without relying on the hardware. Using lsm we > > could have feature negotiation and whenever we can offload, do it. > > e.g. we could know if a storage array supports thin cloning, if it > > supports thick cloning, if a LUN supports thin provisioning etc. > > In the last example (thin provisioning) when we create a VG on top > > of a thin-p LUN we should create all disk image (LVs) > > 'preallocated' and avoid vdsm's thin provisioning implementation > > (as it is not needed). > > > > I was thinking libstoragemgmt 'query capability' or similar interface > should help vdsm know the array capabilities. that is correct. > I agree that if the backing LUN already is thinp'ed, then vdsm should > not add its own over it. So such usecases & needs > from vdsm perspective need to be thought about and eventually it > should > influence the libstoragemgmt interfaces I don't see how it would influence the lsm interfaces. > > > However, we'd need a mechanism at domain level to 'disable' some of > > the capabilities, so for example if we know that on a specific > > array snapshots are limited or provide poor performance (worse > > than qcow) or whatever, we'd be able to fall back to vdsm's > > software implementation. > > > > I was thinking that its for the user to decide, not sure if we can > auto-detect and automate this. But i feel this falls under the > 'advanced > usecase' category :) > We can always think about this later, rite ? Correct, the mechanism is in order to allow the user to decide. > > From ovedo at redhat.com Wed May 9 13:46:18 2012 From: ovedo at redhat.com (Oved Ourfalli) Date: Wed, 09 May 2012 09:46:18 -0400 (EDT) Subject: [Engine-devel] Fwd: Supporting native USB in oVirt In-Reply-To: <4FAA4480.4000407@redhat.com> Message-ID: <6e404ca9-1f15-49a9-bd44-35d692df5c41@zmail02.collab.prod.int.phx2.redhat.com> Hey, We are now working on adding the support for native USB devices on oVirt, and we have some difficulties. Please see the details/discussion below. Thank you for your help, Oved ----- Forwarded Message ----- From: "Itamar Heim" To: "Michal Privoznik" Cc: "Oved Ourfalli" , "Dave Allan" , "Jiri Denemark" , "Igor Lvovsky" , "Eli Mesika" , "Hans de Goede" , "Dan Kenigsberg" , "Andrew Cathrow" Sent: Wednesday, May 9, 2012 1:18:40 PM Subject: Re: Supporting native USB in oVirt On 05/09/2012 01:12 PM, Michal Privoznik wrote: > On 08.05.2012 09:19, Oved Ourfalli wrote: >> Hi, >> >> We are now working on adding the support for native USB devices on oVirt. >> As far as we understand, in order to use it we need to pass the following devices with the following restrictions (according to the EHCI spec): >> 1. EHCI USB controller - with the highest function number, #7. >> >> devices='{type:controller,device:usb,model:ich9-ehci1,address:{type:pci,domain:0x0000,bus:0x00,slot:0x04,function:0x7}}' >> >> 2. 3 UHCI USB controllers, on the same bus and PCI slot as the EHCI controller. Set the multifunction bit to on, on the controller with function #0. >> >> devices='{type:controller,device:usb,model:ich9-uhci1,master:{startport:0},address:{type:pci,domain:0x0000,bus:0x00,slot:0x04,function:0x0,multifunction:on}}' >> devices='{type:controller,device:usb,model:ich9-uhci2,master:{startport:2},address:{type:pci,domain:0x0000,bus:0x00,slot:0x04,function:0x1}}' >> devices='{type:controller,device:usb,model:ich9-uhci3,master:{startport:4},address:{type:pci,domain:0x0000,bus:0x00,slot:0x04,function:0x2}}' >> >> 3. USB redirect devices (according to the needed number of USB slots, maximum 6) on the same bus, each one having a different port. >> >> devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:1}}' >> devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:2}}' >> devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:3}}' >> devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:4}}' >> devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:5}}' >> devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:6}}' >> >> 4. If we want more than 6 USB slots, we need to have 2 EHCI controllers, and 6 UHCI controllers, that are consistent with the restrictions above, on different bus. >> (we need them to be on different bus, since the connection between the redirect devices and the controllers is the bus). >> >> According to Hans (cc-ed), if we let libvirt pick its own addresses, it will put each controller of the composite USB controller device on its own pci slot, which is a violation of the EHCI spec. > >> >> The problem is that the oVirt engine is not aware of addresses. They aren't managed by it. >> They are chosen automatically by libvirt, returned to the engine, and they saved in the engine database in order to provide the ability to retain the same PCI addresses after VM restart. >> >> So, in order to support the EHCI spec, oVirt will have to be aware of addresses, manage them (allocate them, check for collisions, update on every libvirt change regarding that, etc...). Obviously, it doesn't feel right, and in fact it is also not feasible, to manage these addresses in the oVirt domain. >> >> Is all the above correct, or are we missing something? >> If so, can you address the issues above, and provide the ability to manage these devices in libvirt? > > Let's have this conversation upstream (libvirt-list at redhat.com). Many > developers are there so if there's anything libvirt can do, we should > agree on concept there. From shuming at linux.vnet.ibm.com Wed May 9 16:23:39 2012 From: shuming at linux.vnet.ibm.com (Shu Ming) Date: Thu, 10 May 2012 00:23:39 +0800 Subject: [Engine-devel] Stuck at the firewall.conf in vds_bootstrap Message-ID: <4FAA9A0B.4040506@linux.vnet.ibm.com> Hi, My vds_installer was stuck at running vds_bootstrap when I tried to add one host node in my ovirt-engine. For some reasons, the /tmp/firewall.conf.* file was not downloaded and that caused vds_bootstrap's failure. Is there any quick way to disable the "-f" option for vds_bootstrap in engine server or in host node? That will not allow vdsm to overwrite the firewall configurations in host. --- From the vds_install.xxxxxx.log in my host, here is the command where the vds_installer was stuck. /tmp/vds_bootstrap_1a9728df-e3b4-4d7b-8258-835038587bad.py -v -O cstl -t 2012-05-09T16:00:04 -f /tmp/firewall.conf.1a9728df-e3b4-4d7b-8258-835038587bad http://ovirt-engine-112:80/Components/vds/ 9.181.129.110 1a9728df-e3b4-4d7b-8258-835038587bad -- Shu Ming IBM China Systems and Technology Laboratory From shuming at linux.vnet.ibm.com Wed May 9 16:56:07 2012 From: shuming at linux.vnet.ibm.com (Shu Ming) Date: Thu, 10 May 2012 00:56:07 +0800 Subject: [Engine-devel] Stuck at the firewall.conf in vds_bootstrap In-Reply-To: <4FAA9A0B.4040506@linux.vnet.ibm.com> References: <4FAA9A0B.4040506@linux.vnet.ibm.com> Message-ID: <4FAAA1A7.8080703@linux.vnet.ibm.com> After changing the /scripts/vds_installer.py to remove the "-f" option and correct "-v" to '-V", the host node now can be installed and started. It looks like that the options of vds_installer.py or vds_bootstrap.py was broken. On 2012-5-10 0:23, Shu Ming wrote: > Hi, > My vds_installer was stuck at running vds_bootstrap when I tried to > add one host node in my ovirt-engine. For some reasons, the > /tmp/firewall.conf.* file was not downloaded and that caused > vds_bootstrap's failure. Is there any quick way to disable the "-f" > option for vds_bootstrap in engine server or in host node? That will > not allow vdsm to overwrite the firewall configurations in host. > > --- > From the vds_install.xxxxxx.log in my host, here is the command where > the vds_installer was stuck. > > /tmp/vds_bootstrap_1a9728df-e3b4-4d7b-8258-835038587bad.py -v -O cstl > -t 2012-05-09T16:00:04 -f > /tmp/firewall.conf.1a9728df-e3b4-4d7b-8258-835038587bad > http://ovirt-engine-112:80/Components/vds/ 9.181.129.110 > 1a9728df-e3b4-4d7b-8258-835038587bad > > > -- Shu Ming IBM China Systems and Technology Laboratory From lhawthor at redhat.com Wed May 9 14:49:05 2012 From: lhawthor at redhat.com (Leslie Hawthorn) Date: Wed, 09 May 2012 07:49:05 -0700 Subject: [Engine-devel] oVirt Workshop at LinuxCon Japan 2012 Message-ID: <4FAA83E1.3010208@redhat.com> Hello everyone, As part of our efforts to raise awareness of and educate more developers about the oVirt project, we will be holding an oVirt workshop at LinuxCon Japan, taking place on June 8, 2012. You can find full details of the workshop agenda on the LinuxCon Japan site. [0] Registration for the workshop is now open and is free of charge for the first 50 participants. We will also look at adding additional participant slots to the workshop based on demand. Attendees who register for LinuxCon Japan via the workshop registration link [1] will also be eligible for a discount on their LinuxCon Japan registration. Please spread the word to folks you think would find the workshop useful. If they have already registered for LinuxCon Japan, they can simply edit their existing registration to include the workshop. [0] - https://events.linuxfoundation.org/events/linuxcon-japan/ovirt-gluster-workshops [1] - http://www.regonline.com/Register/Checkin.aspx?EventID=1099949 Cheers, LH -- Leslie Hawthorn Community Action and Impact Open Source and Standards @ Red Hat identi.ca/lh twitter.com/lhawthorn From sanjal at redhat.com Thu May 10 06:33:20 2012 From: sanjal at redhat.com (Shireesh Anjal) Date: Thu, 10 May 2012 12:03:20 +0530 Subject: [Engine-devel] create_db_devel.sh failing Message-ID: <4FAB6130.3080703@redhat.com> Creating views... psql:create_views.sql:215: ERROR: column l.phisical_volume_id does not exist LINE 84: l.phisical_volume_id, ^ Failed to create database engine Regards, Shireesh From masayag at redhat.com Thu May 10 06:56:17 2012 From: masayag at redhat.com (Moti Asayag) Date: Thu, 10 May 2012 09:56:17 +0300 Subject: [Engine-devel] create_db_devel.sh failing In-Reply-To: <4FAB6130.3080703@redhat.com> References: <4FAB6130.3080703@redhat.com> Message-ID: <4FAB6691.8060003@redhat.com> On 05/10/2012 09:33 AM, Shireesh Anjal wrote: > Creating views... > psql:create_views.sql:215: ERROR: column l.phisical_volume_id does not > exist > LINE 84: l.phisical_volume_id, > ^ > Failed to create database engine A fix was merged by http://gerrit.ovirt.org/#change,4288 > > Regards, > Shireesh > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From hdegoede at redhat.com Thu May 10 08:32:15 2012 From: hdegoede at redhat.com (Hans de Goede) Date: Thu, 10 May 2012 10:32:15 +0200 Subject: [Engine-devel] [libvirt]Supporting native USB in oVirt In-Reply-To: <6e404ca9-1f15-49a9-bd44-35d692df5c41@zmail02.collab.prod.int.phx2.redhat.com> References: <6e404ca9-1f15-49a9-bd44-35d692df5c41@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <4FAB7D0F.1090400@redhat.com> Hi Oved, I think it will help if you can re-formulate things into a question for the libvirt developers. e.g. something along the lines of: "is it possible to add composite PCI devices to a vm while using automatic address assignment" ? Regards, Hans On 05/09/2012 03:46 PM, Oved Ourfalli wrote: > Hey, > > We are now working on adding the support for native USB devices on oVirt, and we have some difficulties. > Please see the details/discussion below. > > Thank you for your help, > Oved > > ----- Forwarded Message ----- > From: "Itamar Heim" > To: "Michal Privoznik" > Cc: "Oved Ourfalli", "Dave Allan", "Jiri Denemark", "Igor Lvovsky", "Eli Mesika", "Hans de Goede", "Dan Kenigsberg", "Andrew Cathrow" > Sent: Wednesday, May 9, 2012 1:18:40 PM > Subject: Re: Supporting native USB in oVirt > > On 05/09/2012 01:12 PM, Michal Privoznik wrote: >> On 08.05.2012 09:19, Oved Ourfalli wrote: >>> Hi, >>> >>> We are now working on adding the support for native USB devices on oVirt. >>> As far as we understand, in order to use it we need to pass the following devices with the following restrictions (according to the EHCI spec): >>> 1. EHCI USB controller - with the highest function number, #7. >>> >>> devices='{type:controller,device:usb,model:ich9-ehci1,address:{type:pci,domain:0x0000,bus:0x00,slot:0x04,function:0x7}}' >>> >>> 2. 3 UHCI USB controllers, on the same bus and PCI slot as the EHCI controller. Set the multifunction bit to on, on the controller with function #0. >>> >>> devices='{type:controller,device:usb,model:ich9-uhci1,master:{startport:0},address:{type:pci,domain:0x0000,bus:0x00,slot:0x04,function:0x0,multifunction:on}}' >>> devices='{type:controller,device:usb,model:ich9-uhci2,master:{startport:2},address:{type:pci,domain:0x0000,bus:0x00,slot:0x04,function:0x1}}' >>> devices='{type:controller,device:usb,model:ich9-uhci3,master:{startport:4},address:{type:pci,domain:0x0000,bus:0x00,slot:0x04,function:0x2}}' >>> >>> 3. USB redirect devices (according to the needed number of USB slots, maximum 6) on the same bus, each one having a different port. >>> >>> devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:1}}' >>> devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:2}}' >>> devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:3}}' >>> devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:4}}' >>> devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:5}}' >>> devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:6}}' >>> >>> 4. If we want more than 6 USB slots, we need to have 2 EHCI controllers, and 6 UHCI controllers, that are consistent with the restrictions above, on different bus. >>> (we need them to be on different bus, since the connection between the redirect devices and the controllers is the bus). >>> >>> According to Hans (cc-ed), if we let libvirt pick its own addresses, it will put each controller of the composite USB controller device on its own pci slot, which is a violation of the EHCI spec. >> >>> >>> The problem is that the oVirt engine is not aware of addresses. They aren't managed by it. >>> They are chosen automatically by libvirt, returned to the engine, and they saved in the engine database in order to provide the ability to retain the same PCI addresses after VM restart. >>> >>> So, in order to support the EHCI spec, oVirt will have to be aware of addresses, manage them (allocate them, check for collisions, update on every libvirt change regarding that, etc...). Obviously, it doesn't feel right, and in fact it is also not feasible, to manage these addresses in the oVirt domain. >>> >>> Is all the above correct, or are we missing something? >>> If so, can you address the issues above, and provide the ability to manage these devices in libvirt? >> >> Let's have this conversation upstream (libvirt-list at redhat.com). Many >> developers are there so if there's anything libvirt can do, we should >> agree on concept there. > > -- > libvir-list mailing list > libvir-list at redhat.com > https://www.redhat.com/mailman/listinfo/libvir-list From ovedo at redhat.com Thu May 10 11:39:13 2012 From: ovedo at redhat.com (Oved Ourfalli) Date: Thu, 10 May 2012 07:39:13 -0400 (EDT) Subject: [Engine-devel] [libvirt]Supporting native USB in oVirt In-Reply-To: <4FAB7D0F.1090400@redhat.com> Message-ID: <67f023e6-5853-4f81-858b-605f04283705@zmail02.collab.prod.int.phx2.redhat.com> Rephrasing my question a bit, to make it more clear. We are now working on adding the support for native USB devices on oVirt. This requires adding composite PCI devices to a VM (details below), requiring specific set of restrictions on the addresses of these devices, and the connections between them. Is it possible to add such a composite set of devices to a VM while using automatic address assignment, as we do today on the other PCI devices? More details below... Thank you, Oved ----- Original Message ----- > From: "Hans de Goede" > To: "Oved Ourfalli" > Cc: "engine-devel" , libvirt-list at redhat.com > Sent: Thursday, May 10, 2012 11:32:15 AM > Subject: Re: [Engine-devel] [libvirt]Supporting native USB in oVirt > > Hi Oved, > > I think it will help if you can re-formulate things into > a question for the libvirt developers. e.g. something along > the lines of: "is it possible to add composite PCI devices > to a vm while using automatic address assignment" ? > > Regards, > > Hans > > > On 05/09/2012 03:46 PM, Oved Ourfalli wrote: > > Hey, > > > > We are now working on adding the support for native USB devices on > > oVirt, and we have some difficulties. > > Please see the details/discussion below. > > > > Thank you for your help, > > Oved > > > > ----- Forwarded Message ----- > > From: "Itamar Heim" > > To: "Michal Privoznik" > > Cc: "Oved Ourfalli", "Dave > > Allan", "Jiri Denemark", > > "Igor Lvovsky", "Eli > > Mesika", "Hans de Goede", > > "Dan Kenigsberg", "Andrew > > Cathrow" > > Sent: Wednesday, May 9, 2012 1:18:40 PM > > Subject: Re: Supporting native USB in oVirt > > > > On 05/09/2012 01:12 PM, Michal Privoznik wrote: > >> On 08.05.2012 09:19, Oved Ourfalli wrote: > >>> Hi, > >>> > >>> We are now working on adding the support for native USB devices > >>> on oVirt. > >>> As far as we understand, in order to use it we need to pass the > >>> following devices with the following restrictions (according to > >>> the EHCI spec): > >>> 1. EHCI USB controller - with the highest function number, #7. > >>> > >>> devices='{type:controller,device:usb,model:ich9-ehci1,address:{type:pci,domain:0x0000,bus:0x00,slot:0x04,function:0x7}}' > >>> > >>> 2. 3 UHCI USB controllers, on the same bus and PCI slot as the > >>> EHCI controller. Set the multifunction bit to on, on the > >>> controller with function #0. > >>> > >>> devices='{type:controller,device:usb,model:ich9-uhci1,master:{startport:0},address:{type:pci,domain:0x0000,bus:0x00,slot:0x04,function:0x0,multifunction:on}}' > >>> devices='{type:controller,device:usb,model:ich9-uhci2,master:{startport:2},address:{type:pci,domain:0x0000,bus:0x00,slot:0x04,function:0x1}}' > >>> devices='{type:controller,device:usb,model:ich9-uhci3,master:{startport:4},address:{type:pci,domain:0x0000,bus:0x00,slot:0x04,function:0x2}}' > >>> > >>> 3. USB redirect devices (according to the needed number of USB > >>> slots, maximum 6) on the same bus, each one having a different > >>> port. > >>> > >>> devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:1}}' > >>> devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:2}}' > >>> devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:3}}' > >>> devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:4}}' > >>> devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:5}}' > >>> devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:6}}' > >>> > >>> 4. If we want more than 6 USB slots, we need to have 2 EHCI > >>> controllers, and 6 UHCI controllers, that are consistent with > >>> the restrictions above, on different bus. > >>> (we need them to be on different bus, since the connection > >>> between the redirect devices and the controllers is the bus). > >>> > >>> According to Hans (cc-ed), if we let libvirt pick its own > >>> addresses, it will put each controller of the composite USB > >>> controller device on its own pci slot, which is a violation of > >>> the EHCI spec. > >> > >>> > >>> The problem is that the oVirt engine is not aware of addresses. > >>> They aren't managed by it. > >>> They are chosen automatically by libvirt, returned to the engine, > >>> and they saved in the engine database in order to provide the > >>> ability to retain the same PCI addresses after VM restart. > >>> > >>> So, in order to support the EHCI spec, oVirt will have to be > >>> aware of addresses, manage them (allocate them, check for > >>> collisions, update on every libvirt change regarding that, > >>> etc...). Obviously, it doesn't feel right, and in fact it is > >>> also not feasible, to manage these addresses in the oVirt > >>> domain. > >>> > >>> Is all the above correct, or are we missing something? > >>> If so, can you address the issues above, and provide the ability > >>> to manage these devices in libvirt? > >> > >> Let's have this conversation upstream (libvirt-list at redhat.com). > >> Many > >> developers are there so if there's anything libvirt can do, we > >> should > >> agree on concept there. > > > > -- > > libvir-list mailing list > > libvir-list at redhat.com > > https://www.redhat.com/mailman/listinfo/libvir-list > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From vszocs at redhat.com Thu May 10 11:58:25 2012 From: vszocs at redhat.com (Vojtech Szocs) Date: Thu, 10 May 2012 07:58:25 -0400 (EDT) Subject: [Engine-devel] oVirt UserPortal changes In-Reply-To: <5a64f111-3965-47c0-96da-a4db6d0e173c@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: <7652b247-46ad-48bb-a702-4ea50072c4c0@zmail16.collab.prod.int.phx2.redhat.com> Hi everyone, there were some important changes regarding UserPortal introduced recently, so I'll try to summarize the main points here. Please refer to [http://gerrit.ovirt.org/4273] for more details. - legacy (SmartGWT-based) UserPortal is no longer built/compiled during standard oVirt Maven build In case you still want to build/deploy original UserPortal: 1. uncomment "userportal-legacy" sections in ear/pom.xml 2. in frontend/webadmin/modules/pom.xml, include userportal within the section 3. use "gwt-user-legacy" profile when building oVirt - profile "gwt-user-gwtp" is replaced with "gwt-user", this triggers compilation of new (GWTP-based) UserPortal For example, to build oVirt with WebAdmin and new UserPortal: mvn clean install -Psetup,dep,gwt-admin,gwt-user - UserPortal host page URL has changed to: http(s)://[:]/UserPortal/org.ovirt.engine.ui.userportal.UserPortal/UserPortal.html This reflects the URL of original UserPortal. Feel free to contact me if you have any questions. Thanks, Vojtech From hdegoede at redhat.com Thu May 10 12:12:42 2012 From: hdegoede at redhat.com (Hans de Goede) Date: Thu, 10 May 2012 14:12:42 +0200 Subject: [Engine-devel] [libvirt]Supporting native USB in oVirt In-Reply-To: <67f023e6-5853-4f81-858b-605f04283705@zmail02.collab.prod.int.phx2.redhat.com> References: <67f023e6-5853-4f81-858b-605f04283705@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <4FABB0BA.9050000@redhat.com> Hi, On 05/10/2012 01:39 PM, Oved Ourfalli wrote: > Rephrasing my question a bit, to make it more clear. > We are now working on adding the support for native USB devices on oVirt. > > This requires adding composite PCI devices to a VM (details below), requiring specific set of restrictions on the addresses of these devices, and the connections between them. > Is it possible to add such a composite set of devices to a VM while using automatic address assignment, as we do today on the other PCI devices? To be clear, what the ovirt-engine people want to do (AFAIK), is add an EHCI controller with UHCI companion controllers to a vm, which would normally be done in the xml file like this:
Without manually specifying the addresses, ie they want to be able to write something like: Which currently does not work, and even if it would work libvirt does not seem to know that all devices here should share one pci slot using different functions of that slot (and the EHCI controller must have the highest function) I can imagine a syntax like this: Where the id='usb' tells libvirt which master usb controller the companions belong to, and that libvirt would then automatically assign them all the same pci-slot, with different function number, ensuring the EHCI device gets the highest function nr. Regards, Hans > > More details below... > > Thank you, > Oved > > ----- Original Message ----- >> From: "Hans de Goede" >> To: "Oved Ourfalli" >> Cc: "engine-devel", libvirt-list at redhat.com >> Sent: Thursday, May 10, 2012 11:32:15 AM >> Subject: Re: [Engine-devel] [libvirt]Supporting native USB in oVirt >> >> Hi Oved, >> >> I think it will help if you can re-formulate things into >> a question for the libvirt developers. e.g. something along >> the lines of: "is it possible to add composite PCI devices >> to a vm while using automatic address assignment" ? >> >> Regards, >> >> Hans >> >> >> On 05/09/2012 03:46 PM, Oved Ourfalli wrote: >>> Hey, >>> >>> We are now working on adding the support for native USB devices on >>> oVirt, and we have some difficulties. >>> Please see the details/discussion below. >>> >>> Thank you for your help, >>> Oved >>> >>> ----- Forwarded Message ----- >>> From: "Itamar Heim" >>> To: "Michal Privoznik" >>> Cc: "Oved Ourfalli", "Dave >>> Allan", "Jiri Denemark", >>> "Igor Lvovsky", "Eli >>> Mesika", "Hans de Goede", >>> "Dan Kenigsberg", "Andrew >>> Cathrow" >>> Sent: Wednesday, May 9, 2012 1:18:40 PM >>> Subject: Re: Supporting native USB in oVirt >>> >>> On 05/09/2012 01:12 PM, Michal Privoznik wrote: >>>> On 08.05.2012 09:19, Oved Ourfalli wrote: >>>>> Hi, >>>>> >>>>> We are now working on adding the support for native USB devices >>>>> on oVirt. >>>>> As far as we understand, in order to use it we need to pass the >>>>> following devices with the following restrictions (according to >>>>> the EHCI spec): >>>>> 1. EHCI USB controller - with the highest function number, #7. >>>>> >>>>> devices='{type:controller,device:usb,model:ich9-ehci1,address:{type:pci,domain:0x0000,bus:0x00,slot:0x04,function:0x7}}' >>>>> >>>>> 2. 3 UHCI USB controllers, on the same bus and PCI slot as the >>>>> EHCI controller. Set the multifunction bit to on, on the >>>>> controller with function #0. >>>>> >>>>> devices='{type:controller,device:usb,model:ich9-uhci1,master:{startport:0},address:{type:pci,domain:0x0000,bus:0x00,slot:0x04,function:0x0,multifunction:on}}' >>>>> devices='{type:controller,device:usb,model:ich9-uhci2,master:{startport:2},address:{type:pci,domain:0x0000,bus:0x00,slot:0x04,function:0x1}}' >>>>> devices='{type:controller,device:usb,model:ich9-uhci3,master:{startport:4},address:{type:pci,domain:0x0000,bus:0x00,slot:0x04,function:0x2}}' >>>>> >>>>> 3. USB redirect devices (according to the needed number of USB >>>>> slots, maximum 6) on the same bus, each one having a different >>>>> port. >>>>> >>>>> devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:1}}' >>>>> devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:2}}' >>>>> devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:3}}' >>>>> devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:4}}' >>>>> devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:5}}' >>>>> devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:6}}' >>>>> >>>>> 4. If we want more than 6 USB slots, we need to have 2 EHCI >>>>> controllers, and 6 UHCI controllers, that are consistent with >>>>> the restrictions above, on different bus. >>>>> (we need them to be on different bus, since the connection >>>>> between the redirect devices and the controllers is the bus). >>>>> >>>>> According to Hans (cc-ed), if we let libvirt pick its own >>>>> addresses, it will put each controller of the composite USB >>>>> controller device on its own pci slot, which is a violation of >>>>> the EHCI spec. >>>> >>>>> >>>>> The problem is that the oVirt engine is not aware of addresses. >>>>> They aren't managed by it. >>>>> They are chosen automatically by libvirt, returned to the engine, >>>>> and they saved in the engine database in order to provide the >>>>> ability to retain the same PCI addresses after VM restart. >>>>> >>>>> So, in order to support the EHCI spec, oVirt will have to be >>>>> aware of addresses, manage them (allocate them, check for >>>>> collisions, update on every libvirt change regarding that, >>>>> etc...). Obviously, it doesn't feel right, and in fact it is >>>>> also not feasible, to manage these addresses in the oVirt >>>>> domain. >>>>> >>>>> Is all the above correct, or are we missing something? >>>>> If so, can you address the issues above, and provide the ability >>>>> to manage these devices in libvirt? >>>> >>>> Let's have this conversation upstream (libvirt-list at redhat.com). >>>> Many >>>> developers are there so if there's anything libvirt can do, we >>>> should >>>> agree on concept there. >>> >>> -- >>> libvir-list mailing list >>> libvir-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/libvir-list >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> From berrange at redhat.com Thu May 10 13:05:11 2012 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 10 May 2012 14:05:11 +0100 Subject: [Engine-devel] [libvirt]Supporting native USB in oVirt In-Reply-To: <4FABB0BA.9050000@redhat.com> References: <67f023e6-5853-4f81-858b-605f04283705@zmail02.collab.prod.int.phx2.redhat.com> <4FABB0BA.9050000@redhat.com> Message-ID: <20120510130510.GJ1223@redhat.com> On Thu, May 10, 2012 at 02:12:42PM +0200, Hans de Goede wrote: > Hi, > > On 05/10/2012 01:39 PM, Oved Ourfalli wrote: > >Rephrasing my question a bit, to make it more clear. > >We are now working on adding the support for native USB devices on oVirt. > > > >This requires adding composite PCI devices to a VM (details below), requiring specific set of restrictions on the addresses of these devices, and the connections between them. > >Is it possible to add such a composite set of devices to a VM while using automatic address assignment, as we do today on the other PCI devices? > > To be clear, what the ovirt-engine people want to do (AFAIK), is add an EHCI controller > with UHCI companion controllers to a vm, which would normally be done in the xml file > like this: > > >
> > > >
> > > >
> > > >
> > > Without manually specifying the addresses, ie they want to be able to write > something like: > > > > > > > > > > > > > > Which currently does not work, and even if it would work > libvirt does not seem to know that all devices here should > share one pci slot using different functions of that slot > (and the EHCI controller must have the highest function) > > I can imagine a syntax like this: > > > > > > > > > > > > > > Where the id='usb' tells libvirt which master usb controller > the companions belong to, and that libvirt would then > automatically assign them all the same pci-slot, with different > function number, ensuring the EHCI device gets the highest > function nr. While I don't much fancy adding support for automatic assignment with the companion controllers, we could probably make it work, even without needing an extra 'id' attribute. We'd just have to special-case handling of model names uhci[1-3], and apply a first-match rule against ehci controller, if there were multiple Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| From ecohen at redhat.com Thu May 10 13:16:24 2012 From: ecohen at redhat.com (Einav Cohen) Date: Thu, 10 May 2012 09:16:24 -0400 (EDT) Subject: [Engine-devel] PosixFS: GUI mock-ups have been updated In-Reply-To: <51e8a190-a075-49c0-a7c9-1560bff9aafa@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <5c2fc35f-33a8-4fe5-a542-d0a32998452f@zmail04.collab.prod.int.phx2.redhat.com> Please review the mock-ups on the feature page: http://www.ovirt.org/wiki/Features/PosixFSConnection#Changes_in_GUI Comments are welcome. ---- Thanks, Einav From yzaslavs at redhat.com Thu May 10 13:21:42 2012 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Thu, 10 May 2012 16:21:42 +0300 Subject: [Engine-devel] PosixFS: GUI mock-ups have been updated In-Reply-To: <5c2fc35f-33a8-4fe5-a542-d0a32998452f@zmail04.collab.prod.int.phx2.redhat.com> References: <5c2fc35f-33a8-4fe5-a542-d0a32998452f@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4FABC0E6.3010003@redhat.com> On 05/10/2012 04:16 PM, Einav Cohen wrote: > Please review the mock-ups on the feature page: > http://www.ovirt.org/wiki/Features/PosixFSConnection#Changes_in_GUI > > Comments are welcome. >From talking to Haim I understood that path should include ":" In addition - if we only support V1, why add the combo box? Thanks! > > ---- > Thanks, > Einav From ovedo at redhat.com Thu May 10 13:26:30 2012 From: ovedo at redhat.com (Oved Ourfalli) Date: Thu, 10 May 2012 09:26:30 -0400 (EDT) Subject: [Engine-devel] [libvirt]Supporting native USB in oVirt In-Reply-To: <20120510130510.GJ1223@redhat.com> Message-ID: ----- Original Message ----- > From: "Daniel P. Berrange" > To: "Hans de Goede" > Cc: "Oved Ourfalli" , "engine-devel" , libvirt-list at redhat.com > Sent: Thursday, May 10, 2012 4:05:11 PM > Subject: Re: [Engine-devel] [libvirt]Supporting native USB in oVirt > > On Thu, May 10, 2012 at 02:12:42PM +0200, Hans de Goede wrote: > > Hi, > > > > On 05/10/2012 01:39 PM, Oved Ourfalli wrote: > > >Rephrasing my question a bit, to make it more clear. > > >We are now working on adding the support for native USB devices on > > >oVirt. > > > > > >This requires adding composite PCI devices to a VM (details > > >below), requiring specific set of restrictions on the addresses > > >of these devices, and the connections between them. > > >Is it possible to add such a composite set of devices to a VM > > >while using automatic address assignment, as we do today on the > > >other PCI devices? > > > > To be clear, what the ovirt-engine people want to do (AFAIK), is > > add an EHCI controller > > with UHCI companion controllers to a vm, which would normally be > > done in the xml file > > like this: > > > > > >
> function='0x7'/> > > > > > > > >
> function='0x0' multifunction='on'/> > > > > > > > >
> function='0x1'/> > > > > > > > >
> function='0x2'/> > > > > > > Without manually specifying the addresses, ie they want to be able > > to write > > something like: > > > > > > > > > > > > > > > > > > > > > > > > > > > > Which currently does not work, and even if it would work > > libvirt does not seem to know that all devices here should > > share one pci slot using different functions of that slot > > (and the EHCI controller must have the highest function) > > > > I can imagine a syntax like this: > > > > > > > > > > > > > > > > > > > > > > > > > > > > Where the id='usb' tells libvirt which master usb controller > > the companions belong to, and that libvirt would then > > automatically assign them all the same pci-slot, with different > > function number, ensuring the EHCI device gets the highest > > function nr. > > While I don't much fancy adding support for automatic > assignment with the companion controllers, we could probably > make it work, even without needing an extra 'id' attribute. > We'd just have to special-case handling of model names > uhci[1-3], and apply a first-match rule against ehci > controller, if there were multiple > That would be very helpful indeed. We would need something similar for the redirect devices, as they also requiring their address to be assigned to the same bus as the controllers. > Daniel > -- > |: http://berrange.com -o- > | http://www.flickr.com/photos/dberrange/ :| > |: http://libvirt.org -o- > | http://virt-manager.org :| > |: http://autobuild.org -o- > | http://search.cpan.org/~danberr/ :| > |: http://entangle-photo.org -o- > | http://live.gnome.org/gtk-vnc :| > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From cfergeau at redhat.com Thu May 10 13:27:42 2012 From: cfergeau at redhat.com (Christophe Fergeau) Date: Thu, 10 May 2012 15:27:42 +0200 Subject: [Engine-devel] [libvirt] Supporting native USB in oVirt In-Reply-To: <20120510130510.GJ1223@redhat.com> References: <67f023e6-5853-4f81-858b-605f04283705@zmail02.collab.prod.int.phx2.redhat.com> <4FABB0BA.9050000@redhat.com> <20120510130510.GJ1223@redhat.com> Message-ID: <20120510132742.GS31054@teriyaki.cdg.redhat.com> On Thu, May 10, 2012 at 02:05:11PM +0100, Daniel P. Berrange wrote: > > While I don't much fancy adding support for automatic > assignment with the companion controllers, Fwiw, this would be useful to libvirt-glib too. Christophe -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From ecohen at redhat.com Thu May 10 13:28:31 2012 From: ecohen at redhat.com (Einav Cohen) Date: Thu, 10 May 2012 09:28:31 -0400 (EDT) Subject: [Engine-devel] PosixFS: GUI mock-ups have been updated In-Reply-To: <4FABC0E6.3010003@redhat.com> Message-ID: <5fa82da2-b037-4e04-8f35-7cbdbc4f2d8f@zmail04.collab.prod.int.phx2.redhat.com> > ----- Original Message ----- > From: "Yair Zaslavsky" > Sent: Thursday, May 10, 2012 4:21:42 PM > > On 05/10/2012 04:16 PM, Einav Cohen wrote: > > Please review the mock-ups on the feature page: > > http://www.ovirt.org/wiki/Features/PosixFSConnection#Changes_in_GUI > > > > Comments are welcome. > > From talking to Haim I understood that path should include ":" >From talking to Ayal, the path can be similar in its format to a path provided when creating an NFS storage domain (e.g. "server:/dir1/dir2"), *or* to a path provided when creating a Local storage domain (e.g. "/tmp/dir3"), meaning, without ":". @Ayal - any chance for a clarification here? > In addition - if we only support V1, why add the combo box? We are always showing the combo-box, even if we have only one option in it (so the user will know what is the value that is being sent). However, we disable it. I updated the mock-up to clarify this. > > Thanks! > > > > > ---- > > Thanks, > > Einav > > From ovedo at redhat.com Thu May 10 13:28:33 2012 From: ovedo at redhat.com (Oved Ourfalli) Date: Thu, 10 May 2012 09:28:33 -0400 (EDT) Subject: [Engine-devel] [libvirt] Supporting native USB in oVirt In-Reply-To: <4FABC18F.8040402@redhat.com> Message-ID: <9cde2744-5696-48f0-a30c-69982ab215a0@zmail02.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Gerd Hoffmann" > To: "Hans de Goede" > Cc: "Oved Ourfalli" , "engine-devel" , libvirt-list at redhat.com, "Eli > Mesika" > Sent: Thursday, May 10, 2012 4:24:31 PM > Subject: Re: [libvirt] [Engine-devel] Supporting native USB in oVirt > > Hi, > > > I can imagine a syntax like this: > > > > > > > > > > > > > > > > > > > > > > > > > > I think this should have been just something like ... > > > > ... since day one. It's not like those are 4 independant usb > controllers. > I totally agree. That would make things much more simple, as each component now has to be aware of all the controller (EHCI + companion controllers), without any good reason. Is that possible to do this change? > cheers, > Gerd > > From smizrahi at redhat.com Thu May 10 13:39:49 2012 From: smizrahi at redhat.com (Saggi Mizrahi) Date: Thu, 10 May 2012 09:39:49 -0400 (EDT) Subject: [Engine-devel] PosixFS: GUI mock-ups have been updated In-Reply-To: <5fa82da2-b037-4e04-8f35-7cbdbc4f2d8f@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <5fae469a-5d38-4f83-b964-bd416b2848f1@zmail16.collab.prod.int.phx2.redhat.com> I do express that empty mount options SHOULD NOT send an empty string, rather, omit the whole argument. ----- Original Message ----- > From: "Einav Cohen" > To: "Yair Zaslavsky" , "Ayal Baron" > Cc: "Saggi Mizrahi" , "Andrew Cathrow" , "Miki Kenneth" > , "Simon Grinberg" , "Eldan Hildesheim" , "Eldan > Hildesheim" , "Alexey Chub" , engine-devel at ovirt.org, "Haim Ateya" > > Sent: Thursday, May 10, 2012 9:28:31 AM > Subject: Re: PosixFS: GUI mock-ups have been updated > > > ----- Original Message ----- > > From: "Yair Zaslavsky" > > Sent: Thursday, May 10, 2012 4:21:42 PM > > > > On 05/10/2012 04:16 PM, Einav Cohen wrote: > > > Please review the mock-ups on the feature page: > > > http://www.ovirt.org/wiki/Features/PosixFSConnection#Changes_in_GUI > > > > > > Comments are welcome. > > > > From talking to Haim I understood that path should include ":" > > From talking to Ayal, the path can be similar in its format to a path > provided when creating an NFS storage domain (e.g. > "server:/dir1/dir2"), *or* to a path provided when creating a Local > storage domain (e.g. "/tmp/dir3"), meaning, without ":". > @Ayal - any chance for a clarification here? > > > In addition - if we only support V1, why add the combo box? > > We are always showing the combo-box, even if we have only one option > in it (so the user will know what is the value that is being sent). > However, we disable it. I updated the mock-up to clarify this. > > > > > Thanks! > > > > > > > > ---- > > > Thanks, > > > Einav > > > > > From kraxel at redhat.com Thu May 10 13:24:31 2012 From: kraxel at redhat.com (Gerd Hoffmann) Date: Thu, 10 May 2012 15:24:31 +0200 Subject: [Engine-devel] [libvirt] Supporting native USB in oVirt In-Reply-To: <4FABB0BA.9050000@redhat.com> References: <67f023e6-5853-4f81-858b-605f04283705@zmail02.collab.prod.int.phx2.redhat.com> <4FABB0BA.9050000@redhat.com> Message-ID: <4FABC18F.8040402@redhat.com> Hi, > I can imagine a syntax like this: > > > > > > > > > > > > I think this should have been just something like ... ... since day one. It's not like those are 4 independant usb controllers. cheers, Gerd From mkenneth at redhat.com Thu May 10 13:46:06 2012 From: mkenneth at redhat.com (Miki Kenneth) Date: Thu, 10 May 2012 09:46:06 -0400 (EDT) Subject: [Engine-devel] PosixFS: GUI mock-ups have been updated In-Reply-To: <5fa82da2-b037-4e04-8f35-7cbdbc4f2d8f@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <64da94ec-05a5-49b2-ad43-42fdcf477407@mkenneth.csb> we should had a mouseover tooltip for explaining what is PosixFS and mentioned that it is supported only in 3.1 cluster. Miki ----- Original Message ----- > From: "Einav Cohen" > To: "Yair Zaslavsky" , "Ayal Baron" > Cc: "Saggi Mizrahi" , "Andrew Cathrow" , "Miki Kenneth" > , "Simon Grinberg" , "Eldan Hildesheim" , "Eldan > Hildesheim" , "Alexey Chub" , engine-devel at ovirt.org, "Haim Ateya" > > Sent: Thursday, May 10, 2012 4:28:31 PM > Subject: Re: PosixFS: GUI mock-ups have been updated > > > ----- Original Message ----- > > From: "Yair Zaslavsky" > > Sent: Thursday, May 10, 2012 4:21:42 PM > > > > On 05/10/2012 04:16 PM, Einav Cohen wrote: > > > Please review the mock-ups on the feature page: > > > http://www.ovirt.org/wiki/Features/PosixFSConnection#Changes_in_GUI > > > > > > Comments are welcome. > > > > From talking to Haim I understood that path should include ":" > > From talking to Ayal, the path can be similar in its format to a path > provided when creating an NFS storage domain (e.g. > "server:/dir1/dir2"), *or* to a path provided when creating a Local > storage domain (e.g. "/tmp/dir3"), meaning, without ":". > @Ayal - any chance for a clarification here? > > > In addition - if we only support V1, why add the combo box? > > We are always showing the combo-box, even if we have only one option > in it (so the user will know what is the value that is being sent). > However, we disable it. I updated the mock-up to clarify this. > > > > > Thanks! > > > > > > > > ---- > > > Thanks, > > > Einav > > > > > From ecohen at redhat.com Thu May 10 13:51:32 2012 From: ecohen at redhat.com (Einav Cohen) Date: Thu, 10 May 2012 09:51:32 -0400 (EDT) Subject: [Engine-devel] PosixFS: GUI mock-ups have been updated In-Reply-To: <5fae469a-5d38-4f83-b964-bd416b2848f1@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: <48f42aa7-4bd6-4f09-b21d-fbd41590491d@zmail04.collab.prod.int.phx2.redhat.com> > ----- Original Message ----- > From: "Saggi Mizrahi" > Sent: Thursday, May 10, 2012 4:39:49 PM > > I do express that empty mount options SHOULD NOT send an empty > string, rather, omit the whole argument. Yes, this should be handled on the backend side (Yair - please note, maybe it is already implemented like this - don't know): When getting a null-or-empty "mount options" value from the client, the backend needs to make sure to *not* set the relevant parameter in the vdsm verb at all. So leaving the "mount options" text-box empty in the GUI is legal, only needs to be handled in a certain way in the backend. > > ----- Original Message ----- > > From: "Einav Cohen" > > To: "Yair Zaslavsky" , "Ayal Baron" > > > > Cc: "Saggi Mizrahi" , "Andrew Cathrow" > > , "Miki Kenneth" > > , "Simon Grinberg" , > > "Eldan Hildesheim" , "Eldan > > Hildesheim" , "Alexey Chub" , > > engine-devel at ovirt.org, "Haim Ateya" > > > > Sent: Thursday, May 10, 2012 9:28:31 AM > > Subject: Re: PosixFS: GUI mock-ups have been updated > > > > > ----- Original Message ----- > > > From: "Yair Zaslavsky" > > > Sent: Thursday, May 10, 2012 4:21:42 PM > > > > > > On 05/10/2012 04:16 PM, Einav Cohen wrote: > > > > Please review the mock-ups on the feature page: > > > > http://www.ovirt.org/wiki/Features/PosixFSConnection#Changes_in_GUI > > > > > > > > Comments are welcome. > > > > > > From talking to Haim I understood that path should include ":" > > > > From talking to Ayal, the path can be similar in its format to a > > path > > provided when creating an NFS storage domain (e.g. > > "server:/dir1/dir2"), *or* to a path provided when creating a Local > > storage domain (e.g. "/tmp/dir3"), meaning, without ":". > > @Ayal - any chance for a clarification here? > > > > > In addition - if we only support V1, why add the combo box? > > > > We are always showing the combo-box, even if we have only one > > option > > in it (so the user will know what is the value that is being sent). > > However, we disable it. I updated the mock-up to clarify this. > > > > > > > > Thanks! > > > > > > > > > > > ---- > > > > Thanks, > > > > Einav > > > > > > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > From gjansen at redhat.com Thu May 10 13:57:37 2012 From: gjansen at redhat.com (Geert Jansen) Date: Thu, 10 May 2012 15:57:37 +0200 Subject: [Engine-devel] PosixFS: GUI mock-ups have been updated In-Reply-To: <5fa82da2-b037-4e04-8f35-7cbdbc4f2d8f@zmail04.collab.prod.int.phx2.redhat.com> References: <5fa82da2-b037-4e04-8f35-7cbdbc4f2d8f@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4FABC951.3030505@redhat.com> On 05/10/2012 03:28 PM, Einav Cohen wrote: > From talking to Ayal, the path can be similar in its format to a path provided when creating an NFS storage domain (e.g. "server:/dir1/dir2"), *or* to a path provided when creating a Local storage domain (e.g. "/tmp/dir3"), meaning, without ":". > @Ayal - any chance for a clarification here? For generality i am not sure we want to validate this field other than ensuring it contains a non-empty string. Different file systems have different ways in which they specify the block device. Another common form to identify a block device is for example: UUID= Or a file server list: server1:/path,server2:/path Trying to list all possible formats for all possible file systems is IMHO not something that we should try to do. Regards, Geert From acathrow at redhat.com Thu May 10 13:57:44 2012 From: acathrow at redhat.com (Andrew Cathrow) Date: Thu, 10 May 2012 09:57:44 -0400 (EDT) Subject: [Engine-devel] PosixFS: GUI mock-ups have been updated In-Reply-To: <48f42aa7-4bd6-4f09-b21d-fbd41590491d@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <33ede6ec-e4ee-48e0-be4a-fc8a21b53eee@zmail07.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Einav Cohen" > To: "Saggi Mizrahi" , "Yair Zaslavsky" > Cc: "Haim Ateya" , "Eldan Hildesheim" , engine-devel at ovirt.org, "Eldan > Hildesheim" , "Simon Grinberg" > Sent: Thursday, May 10, 2012 9:51:32 AM > Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated > > > ----- Original Message ----- > > From: "Saggi Mizrahi" > > Sent: Thursday, May 10, 2012 4:39:49 PM > > > > I do express that empty mount options SHOULD NOT send an empty > > string, rather, omit the whole argument. > > Yes, this should be handled on the backend side (Yair - please note, > maybe it is already implemented like this - don't know): When > getting a null-or-empty "mount options" value from the client, the > backend needs to make sure to *not* set the relevant parameter in > the vdsm verb at all. > > So leaving the "mount options" text-box empty in the GUI is legal, > only needs to be handled in a certain way in the backend. In theory for a PosixFS file system a user could create multiple storage domains of different PosixFS types. Perhaps that's not a problem, but worth noting. Is "Path" the correct term to use for the remote mount? I can imagine customers thinking that is local and messing with fstab. Not sure if there's a better term - filesystem URI ? I presume we are doing just not-null validation for path. Obviously we can't validate the mount options but how good is the error reporting back going to be - if the mount options are wrong, or if something fails with the mount will we see "error 12345" in the UI and require the user to go digging in vdsm logs or are we going to pull back and display toe complete message. > > > > > ----- Original Message ----- > > > From: "Einav Cohen" > > > To: "Yair Zaslavsky" , "Ayal Baron" > > > > > > Cc: "Saggi Mizrahi" , "Andrew Cathrow" > > > , "Miki Kenneth" > > > , "Simon Grinberg" , > > > "Eldan Hildesheim" , "Eldan > > > Hildesheim" , "Alexey Chub" , > > > engine-devel at ovirt.org, "Haim Ateya" > > > > > > Sent: Thursday, May 10, 2012 9:28:31 AM > > > Subject: Re: PosixFS: GUI mock-ups have been updated > > > > > > > ----- Original Message ----- > > > > From: "Yair Zaslavsky" > > > > Sent: Thursday, May 10, 2012 4:21:42 PM > > > > > > > > On 05/10/2012 04:16 PM, Einav Cohen wrote: > > > > > Please review the mock-ups on the feature page: > > > > > http://www.ovirt.org/wiki/Features/PosixFSConnection#Changes_in_GUI > > > > > > > > > > Comments are welcome. > > > > > > > > From talking to Haim I understood that path should include ":" > > > > > > From talking to Ayal, the path can be similar in its format to a > > > path > > > provided when creating an NFS storage domain (e.g. > > > "server:/dir1/dir2"), *or* to a path provided when creating a > > > Local > > > storage domain (e.g. "/tmp/dir3"), meaning, without ":". > > > @Ayal - any chance for a clarification here? > > > > > > > In addition - if we only support V1, why add the combo box? > > > > > > We are always showing the combo-box, even if we have only one > > > option > > > in it (so the user will know what is the value that is being > > > sent). > > > However, we disable it. I updated the mock-up to clarify this. > > > > > > > > > > > Thanks! > > > > > > > > > > > > > > ---- > > > > > Thanks, > > > > > Einav > > > > > > > > > > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From yzaslavs at redhat.com Thu May 10 14:14:32 2012 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Thu, 10 May 2012 17:14:32 +0300 Subject: [Engine-devel] PosixFS: GUI mock-ups have been updated In-Reply-To: <64da94ec-05a5-49b2-ad43-42fdcf477407@mkenneth.csb> References: <64da94ec-05a5-49b2-ad43-42fdcf477407@mkenneth.csb> Message-ID: <4FABCD48.4020005@redhat.com> On 05/10/2012 04:46 PM, Miki Kenneth wrote: > we should had a mouseover tooltip for explaining what is PosixFS and mentioned that it is supported only in 3.1 cluster. > Miki > > ----- Original Message ----- >> From: "Einav Cohen" >> To: "Yair Zaslavsky" , "Ayal Baron" >> Cc: "Saggi Mizrahi" , "Andrew Cathrow" , "Miki Kenneth" >> , "Simon Grinberg" , "Eldan Hildesheim" , "Eldan >> Hildesheim" , "Alexey Chub" , engine-devel at ovirt.org, "Haim Ateya" >> >> Sent: Thursday, May 10, 2012 4:28:31 PM >> Subject: Re: PosixFS: GUI mock-ups have been updated >> >>> ----- Original Message ----- >>> From: "Yair Zaslavsky" >>> Sent: Thursday, May 10, 2012 4:21:42 PM >>> >>> On 05/10/2012 04:16 PM, Einav Cohen wrote: >>>> Please review the mock-ups on the feature page: >>>> http://www.ovirt.org/wiki/Features/PosixFSConnection#Changes_in_GUI >>>> >>>> Comments are welcome. >>> >>> From talking to Haim I understood that path should include ":" >> >> From talking to Ayal, the path can be similar in its format to a path >> provided when creating an NFS storage domain (e.g. >> "server:/dir1/dir2"), *or* to a path provided when creating a Local >> storage domain (e.g. "/tmp/dir3"), meaning, without ":". >> @Ayal - any chance for a clarification here? This is important - it may yield a change to REST-API. Ayal? >> >>> In addition - if we only support V1, why add the combo box? >> >> We are always showing the combo-box, even if we have only one option >> in it (so the user will know what is the value that is being sent). >> However, we disable it. I updated the mock-up to clarify this. >> >>> >>> Thanks! >>> >>>> >>>> ---- >>>> Thanks, >>>> Einav >>> >>> >> From acathrow at redhat.com Thu May 10 14:16:24 2012 From: acathrow at redhat.com (Andrew Cathrow) Date: Thu, 10 May 2012 10:16:24 -0400 (EDT) Subject: [Engine-devel] PosixFS: GUI mock-ups have been updated In-Reply-To: <4FABCD48.4020005@redhat.com> Message-ID: <0f0e7967-36c0-4d0c-a7f2-a043c012cdb2@zmail07.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Yair Zaslavsky" > To: "Miki Kenneth" > Cc: "Einav Cohen" , "Saggi Mizrahi" , "Andrew Cathrow" , > "Simon Grinberg" , "Eldan Hildesheim" , "Eldan Hildesheim" > , "Alexey Chub" , engine-devel at ovirt.org, "Haim Ateya" , > "Ayal Baron" > Sent: Thursday, May 10, 2012 10:14:32 AM > Subject: Re: PosixFS: GUI mock-ups have been updated > > On 05/10/2012 04:46 PM, Miki Kenneth wrote: > > we should had a mouseover tooltip for explaining what is PosixFS > > and mentioned that it is supported only in 3.1 cluster. > > Miki > > > > ----- Original Message ----- > >> From: "Einav Cohen" > >> To: "Yair Zaslavsky" , "Ayal Baron" > >> > >> Cc: "Saggi Mizrahi" , "Andrew Cathrow" > >> , "Miki Kenneth" > >> , "Simon Grinberg" , > >> "Eldan Hildesheim" , "Eldan > >> Hildesheim" , "Alexey Chub" , > >> engine-devel at ovirt.org, "Haim Ateya" > >> > >> Sent: Thursday, May 10, 2012 4:28:31 PM > >> Subject: Re: PosixFS: GUI mock-ups have been updated > >> > >>> ----- Original Message ----- > >>> From: "Yair Zaslavsky" > >>> Sent: Thursday, May 10, 2012 4:21:42 PM > >>> > >>> On 05/10/2012 04:16 PM, Einav Cohen wrote: > >>>> Please review the mock-ups on the feature page: > >>>> http://www.ovirt.org/wiki/Features/PosixFSConnection#Changes_in_GUI > >>>> > >>>> Comments are welcome. > >>> > >>> From talking to Haim I understood that path should include ":" > >> > >> From talking to Ayal, the path can be similar in its format to a > >> path > >> provided when creating an NFS storage domain (e.g. > >> "server:/dir1/dir2"), *or* to a path provided when creating a > >> Local > >> storage domain (e.g. "/tmp/dir3"), meaning, without ":". > >> @Ayal - any chance for a clarification here? > This is important - it may yield a change to REST-API. > Ayal? The validation should be not empty, after than anything goes. > > >> > >>> In addition - if we only support V1, why add the combo box? > >> > >> We are always showing the combo-box, even if we have only one > >> option > >> in it (so the user will know what is the value that is being > >> sent). > >> However, we disable it. I updated the mock-up to clarify this. > >> > >>> > >>> Thanks! > >>> > >>>> > >>>> ---- > >>>> Thanks, > >>>> Einav > >>> > >>> > >> > > From yzaslavs at redhat.com Thu May 10 14:29:23 2012 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Thu, 10 May 2012 17:29:23 +0300 Subject: [Engine-devel] PosixFS: GUI mock-ups have been updated In-Reply-To: <0f0e7967-36c0-4d0c-a7f2-a043c012cdb2@zmail07.collab.prod.int.phx2.redhat.com> References: <0f0e7967-36c0-4d0c-a7f2-a043c012cdb2@zmail07.collab.prod.int.phx2.redhat.com> Message-ID: <4FABD0C3.8030709@redhat.com> On 05/10/2012 05:16 PM, Andrew Cathrow wrote: > > > ----- Original Message ----- >> From: "Yair Zaslavsky" >> To: "Miki Kenneth" >> Cc: "Einav Cohen" , "Saggi Mizrahi" , "Andrew Cathrow" , >> "Simon Grinberg" , "Eldan Hildesheim" , "Eldan Hildesheim" >> , "Alexey Chub" , engine-devel at ovirt.org, "Haim Ateya" , >> "Ayal Baron" >> Sent: Thursday, May 10, 2012 10:14:32 AM >> Subject: Re: PosixFS: GUI mock-ups have been updated >> >> On 05/10/2012 04:46 PM, Miki Kenneth wrote: >>> we should had a mouseover tooltip for explaining what is PosixFS >>> and mentioned that it is supported only in 3.1 cluster. >>> Miki >>> >>> ----- Original Message ----- >>>> From: "Einav Cohen" >>>> To: "Yair Zaslavsky" , "Ayal Baron" >>>> >>>> Cc: "Saggi Mizrahi" , "Andrew Cathrow" >>>> , "Miki Kenneth" >>>> , "Simon Grinberg" , >>>> "Eldan Hildesheim" , "Eldan >>>> Hildesheim" , "Alexey Chub" , >>>> engine-devel at ovirt.org, "Haim Ateya" >>>> >>>> Sent: Thursday, May 10, 2012 4:28:31 PM >>>> Subject: Re: PosixFS: GUI mock-ups have been updated >>>> >>>>> ----- Original Message ----- >>>>> From: "Yair Zaslavsky" >>>>> Sent: Thursday, May 10, 2012 4:21:42 PM >>>>> >>>>> On 05/10/2012 04:16 PM, Einav Cohen wrote: >>>>>> Please review the mock-ups on the feature page: >>>>>> http://www.ovirt.org/wiki/Features/PosixFSConnection#Changes_in_GUI >>>>>> >>>>>> Comments are welcome. >>>>> >>>>> From talking to Haim I understood that path should include ":" >>>> >>>> From talking to Ayal, the path can be similar in its format to a >>>> path >>>> provided when creating an NFS storage domain (e.g. >>>> "server:/dir1/dir2"), *or* to a path provided when creating a >>>> Local >>>> storage domain (e.g. "/tmp/dir3"), meaning, without ":". >>>> @Ayal - any chance for a clarification here? >> This is important - it may yield a change to REST-API. >> Ayal? > > The validation should be not empty, after than anything goes. Ori - this means we should model REST-API differently, and not as I thought (current REST-API implementation will not be able to pass mountSpec without ":" to backend). I will summon a meeting on Sunday to close that ASAP > >> >>>> >>>>> In addition - if we only support V1, why add the combo box? >>>> >>>> We are always showing the combo-box, even if we have only one >>>> option >>>> in it (so the user will know what is the value that is being >>>> sent). >>>> However, we disable it. I updated the mock-up to clarify this. >>>> >>>>> >>>>> Thanks! >>>>> >>>>>> >>>>>> ---- >>>>>> Thanks, >>>>>> Einav >>>>> >>>>> >>>> >> >> From ecohen at redhat.com Thu May 10 14:27:03 2012 From: ecohen at redhat.com (Einav Cohen) Date: Thu, 10 May 2012 10:27:03 -0400 (EDT) Subject: [Engine-devel] PosixFS: GUI mock-ups have been updated In-Reply-To: <0f0e7967-36c0-4d0c-a7f2-a043c012cdb2@zmail07.collab.prod.int.phx2.redhat.com> Message-ID: > ----- Original Message ----- > From: "Andrew Cathrow" > Sent: Thursday, May 10, 2012 5:16:24 PM > > ----- Original Message ----- > > From: "Yair Zaslavsky" > > To: "Miki Kenneth" > > Cc: "Einav Cohen" , "Saggi Mizrahi" > > , "Andrew Cathrow" , > > "Simon Grinberg" , "Eldan Hildesheim" > > , "Eldan Hildesheim" > > , "Alexey Chub" , > > engine-devel at ovirt.org, "Haim Ateya" , > > "Ayal Baron" > > Sent: Thursday, May 10, 2012 10:14:32 AM > > Subject: Re: PosixFS: GUI mock-ups have been updated > > > > On 05/10/2012 04:46 PM, Miki Kenneth wrote: > > > we should had a mouseover tooltip for explaining what is PosixFS > > > and mentioned that it is supported only in 3.1 cluster. > > > Miki > > > > > > ----- Original Message ----- > > >> From: "Einav Cohen" > > >> To: "Yair Zaslavsky" , "Ayal Baron" > > >> > > >> Cc: "Saggi Mizrahi" , "Andrew Cathrow" > > >> , "Miki Kenneth" > > >> , "Simon Grinberg" , > > >> "Eldan Hildesheim" , "Eldan > > >> Hildesheim" , "Alexey Chub" > > >> , > > >> engine-devel at ovirt.org, "Haim Ateya" > > >> > > >> Sent: Thursday, May 10, 2012 4:28:31 PM > > >> Subject: Re: PosixFS: GUI mock-ups have been updated > > >> > > >>> ----- Original Message ----- > > >>> From: "Yair Zaslavsky" > > >>> Sent: Thursday, May 10, 2012 4:21:42 PM > > >>> > > >>> On 05/10/2012 04:16 PM, Einav Cohen wrote: > > >>>> Please review the mock-ups on the feature page: > > >>>> http://www.ovirt.org/wiki/Features/PosixFSConnection#Changes_in_GUI > > >>>> > > >>>> Comments are welcome. > > >>> > > >>> From talking to Haim I understood that path should include ":" > > >> > > >> From talking to Ayal, the path can be similar in its format to a > > >> path > > >> provided when creating an NFS storage domain (e.g. > > >> "server:/dir1/dir2"), *or* to a path provided when creating a > > >> Local > > >> storage domain (e.g. "/tmp/dir3"), meaning, without ":". > > >> @Ayal - any chance for a clarification here? > > This is important - it may yield a change to REST-API. > > Ayal? > > The validation should be not empty, after than anything goes. +1. Let's have only non-empty validation. We will re-visit later if necessary (not sure it will be). Haim: FYI. > > > > > >> > > >>> In addition - if we only support V1, why add the combo box? > > >> > > >> We are always showing the combo-box, even if we have only one > > >> option > > >> in it (so the user will know what is the value that is being > > >> sent). > > >> However, we disable it. I updated the mock-up to clarify this. > > >> > > >>> > > >>> Thanks! > > >>> > > >>>> > > >>>> ---- > > >>>> Thanks, > > >>>> Einav > > >>> > > >>> > > >> > > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > From ecohen at redhat.com Thu May 10 14:56:09 2012 From: ecohen at redhat.com (Einav Cohen) Date: Thu, 10 May 2012 10:56:09 -0400 (EDT) Subject: [Engine-devel] PosixFS: GUI mock-ups have been updated In-Reply-To: <33ede6ec-e4ee-48e0-be4a-fc8a21b53eee@zmail07.collab.prod.int.phx2.redhat.com> Message-ID: > ----- Original Message ----- > From: "Andrew Cathrow" > Sent: Thursday, May 10, 2012 4:57:44 PM > > ----- Original Message ----- > > From: "Einav Cohen" > > To: "Saggi Mizrahi" , "Yair Zaslavsky" > > > > Cc: "Haim Ateya" , "Eldan Hildesheim" > > , engine-devel at ovirt.org, "Eldan > > Hildesheim" , "Simon Grinberg" > > > > Sent: Thursday, May 10, 2012 9:51:32 AM > > Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated > > > > > ----- Original Message ----- > > > From: "Saggi Mizrahi" > > > Sent: Thursday, May 10, 2012 4:39:49 PM > > > > > > I do express that empty mount options SHOULD NOT send an empty > > > string, rather, omit the whole argument. > > > > Yes, this should be handled on the backend side (Yair - please > > note, > > maybe it is already implemented like this - don't know): When > > getting a null-or-empty "mount options" value from the client, the > > backend needs to make sure to *not* set the relevant parameter in > > the vdsm verb at all. > > > > So leaving the "mount options" text-box empty in the GUI is legal, > > only needs to be handled in a certain way in the backend. > > > > In theory for a PosixFS file system a user could create multiple > storage domains of different PosixFS types. Perhaps that's not a > problem, but worth noting. > > Is "Path" the correct term to use for the remote mount? I can imagine > customers thinking that is local and messing with fstab. > Not sure if there's a better term - filesystem URI ? - In the initial mock-up, it was called "Mount Spec". Is it better? - Note that the current PosixFS implementation in the rest-api utilizes the already-existing "" property within the "" tag within the "" rest-api business entity, therefore I put in the mockup the same term. Do you think that the rest-api should have a different term as well? > > I presume we are doing just not-null validation for path. > > Obviously we can't validate the mount options but how good is the > error reporting back going to be - if the mount options are wrong, > or if something fails with the mount will we see "error 12345" in > the UI and require the user to go digging in vdsm logs or are we > going to pull back and display toe complete message. Depends on backend/vdsm; Yair/Ayal? > > > > > > > > > > ----- Original Message ----- > > > > From: "Einav Cohen" > > > > To: "Yair Zaslavsky" , "Ayal Baron" > > > > > > > > Cc: "Saggi Mizrahi" , "Andrew Cathrow" > > > > , "Miki Kenneth" > > > > , "Simon Grinberg" , > > > > "Eldan Hildesheim" , "Eldan > > > > Hildesheim" , "Alexey Chub" > > > > , > > > > engine-devel at ovirt.org, "Haim Ateya" > > > > > > > > Sent: Thursday, May 10, 2012 9:28:31 AM > > > > Subject: Re: PosixFS: GUI mock-ups have been updated > > > > > > > > > ----- Original Message ----- > > > > > From: "Yair Zaslavsky" > > > > > Sent: Thursday, May 10, 2012 4:21:42 PM > > > > > > > > > > On 05/10/2012 04:16 PM, Einav Cohen wrote: > > > > > > Please review the mock-ups on the feature page: > > > > > > http://www.ovirt.org/wiki/Features/PosixFSConnection#Changes_in_GUI > > > > > > > > > > > > Comments are welcome. > > > > > > > > > > From talking to Haim I understood that path should include > > > > > ":" > > > > > > > > From talking to Ayal, the path can be similar in its format to > > > > a > > > > path > > > > provided when creating an NFS storage domain (e.g. > > > > "server:/dir1/dir2"), *or* to a path provided when creating a > > > > Local > > > > storage domain (e.g. "/tmp/dir3"), meaning, without ":". > > > > @Ayal - any chance for a clarification here? > > > > > > > > > In addition - if we only support V1, why add the combo box? > > > > > > > > We are always showing the combo-box, even if we have only one > > > > option > > > > in it (so the user will know what is the value that is being > > > > sent). > > > > However, we disable it. I updated the mock-up to clarify this. > > > > > > > > > > > > > > Thanks! > > > > > > > > > > > > > > > > > ---- > > > > > > Thanks, > > > > > > Einav > > > > > > > > > > > > > > > > > _______________________________________________ > > > Engine-devel mailing list > > > Engine-devel at ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > From acathrow at redhat.com Thu May 10 15:06:23 2012 From: acathrow at redhat.com (Andrew Cathrow) Date: Thu, 10 May 2012 11:06:23 -0400 (EDT) Subject: [Engine-devel] PosixFS: GUI mock-ups have been updated In-Reply-To: Message-ID: ----- Original Message ----- > From: "Einav Cohen" > To: "Andrew Cathrow" , "Geert Jansen" , "Ori Liel" , "Yair > Zaslavsky" , "Ayal Baron" > Cc: engine-devel at ovirt.org, "Simon Grinberg" , "Saggi Mizrahi" > Sent: Thursday, May 10, 2012 10:56:09 AM > Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated > > > ----- Original Message ----- > > From: "Andrew Cathrow" > > Sent: Thursday, May 10, 2012 4:57:44 PM > > > > ----- Original Message ----- > > > From: "Einav Cohen" > > > To: "Saggi Mizrahi" , "Yair Zaslavsky" > > > > > > Cc: "Haim Ateya" , "Eldan Hildesheim" > > > , engine-devel at ovirt.org, "Eldan > > > Hildesheim" , "Simon Grinberg" > > > > > > Sent: Thursday, May 10, 2012 9:51:32 AM > > > Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been > > > updated > > > > > > > ----- Original Message ----- > > > > From: "Saggi Mizrahi" > > > > Sent: Thursday, May 10, 2012 4:39:49 PM > > > > > > > > I do express that empty mount options SHOULD NOT send an empty > > > > string, rather, omit the whole argument. > > > > > > Yes, this should be handled on the backend side (Yair - please > > > note, > > > maybe it is already implemented like this - don't know): When > > > getting a null-or-empty "mount options" value from the client, > > > the > > > backend needs to make sure to *not* set the relevant parameter in > > > the vdsm verb at all. > > > > > > So leaving the "mount options" text-box empty in the GUI is > > > legal, > > > only needs to be handled in a certain way in the backend. > > > > > > > > In theory for a PosixFS file system a user could create multiple > > storage domains of different PosixFS types. Perhaps that's not a > > problem, but worth noting. > > > > Is "Path" the correct term to use for the remote mount? I can > > imagine > > customers thinking that is local and messing with fstab. > > Not sure if there's a better term - filesystem URI ? > > - In the initial mock-up, it was called "Mount Spec". Is it better? I don't like any of the options - but have a preference for Filesystem URI, but I'd like others to weigh in here. My concern with path is that it could mean local or remote, so another option is "Remote Path" > > - Note that the current PosixFS implementation in the rest-api > utilizes the already-existing "" property within the > "" tag within the "" rest-api business > entity, therefore I put in the mockup the same term. > Do you think that the rest-api should have a different term as well? > > > > > I presume we are doing just not-null validation for path. > > > > Obviously we can't validate the mount options but how good is the > > error reporting back going to be - if the mount options are wrong, > > or if something fails with the mount will we see "error 12345" in > > the UI and require the user to go digging in vdsm logs or are we > > going to pull back and display toe complete message. > > Depends on backend/vdsm; Yair/Ayal? > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Einav Cohen" > > > > > To: "Yair Zaslavsky" , "Ayal Baron" > > > > > > > > > > Cc: "Saggi Mizrahi" , "Andrew Cathrow" > > > > > , "Miki Kenneth" > > > > > , "Simon Grinberg" > > > > > , > > > > > "Eldan Hildesheim" , "Eldan > > > > > Hildesheim" , "Alexey Chub" > > > > > , > > > > > engine-devel at ovirt.org, "Haim Ateya" > > > > > > > > > > Sent: Thursday, May 10, 2012 9:28:31 AM > > > > > Subject: Re: PosixFS: GUI mock-ups have been updated > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Yair Zaslavsky" > > > > > > Sent: Thursday, May 10, 2012 4:21:42 PM > > > > > > > > > > > > On 05/10/2012 04:16 PM, Einav Cohen wrote: > > > > > > > Please review the mock-ups on the feature page: > > > > > > > http://www.ovirt.org/wiki/Features/PosixFSConnection#Changes_in_GUI > > > > > > > > > > > > > > Comments are welcome. > > > > > > > > > > > > From talking to Haim I understood that path should include > > > > > > ":" > > > > > > > > > > From talking to Ayal, the path can be similar in its format > > > > > to > > > > > a > > > > > path > > > > > provided when creating an NFS storage domain (e.g. > > > > > "server:/dir1/dir2"), *or* to a path provided when creating a > > > > > Local > > > > > storage domain (e.g. "/tmp/dir3"), meaning, without ":". > > > > > @Ayal - any chance for a clarification here? > > > > > > > > > > > In addition - if we only support V1, why add the combo box? > > > > > > > > > > We are always showing the combo-box, even if we have only one > > > > > option > > > > > in it (so the user will know what is the value that is being > > > > > sent). > > > > > However, we disable it. I updated the mock-up to clarify > > > > > this. > > > > > > > > > > > > > > > > > Thanks! > > > > > > > > > > > > > > > > > > > > ---- > > > > > > > Thanks, > > > > > > > Einav > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Engine-devel mailing list > > > > Engine-devel at ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > _______________________________________________ > > > Engine-devel mailing list > > > Engine-devel at ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > From ecohen at redhat.com Thu May 10 17:01:20 2012 From: ecohen at redhat.com (Einav Cohen) Date: Thu, 10 May 2012 13:01:20 -0400 (EDT) Subject: [Engine-devel] PosixFS: GUI mock-ups have been updated In-Reply-To: Message-ID: <88bddd4b-ac7a-4e16-a065-ec278bd002de@zmail04.collab.prod.int.phx2.redhat.com> > ----- Original Message ----- > From: "Andrew Cathrow" > Sent: Thursday, May 10, 2012 6:06:23 PM > > > ----- Original Message ----- > > From: "Einav Cohen" > > To: "Andrew Cathrow" , "Geert Jansen" > > , "Ori Liel" , "Yair > > Zaslavsky" , "Ayal Baron" > > Cc: engine-devel at ovirt.org, "Simon Grinberg" , > > "Saggi Mizrahi" > > Sent: Thursday, May 10, 2012 10:56:09 AM > > Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated > > > > > ----- Original Message ----- > > > From: "Andrew Cathrow" > > > Sent: Thursday, May 10, 2012 4:57:44 PM > > > > > > ----- Original Message ----- > > > > From: "Einav Cohen" > > > > To: "Saggi Mizrahi" , "Yair Zaslavsky" > > > > > > > > Cc: "Haim Ateya" , "Eldan Hildesheim" > > > > , engine-devel at ovirt.org, "Eldan > > > > Hildesheim" , "Simon Grinberg" > > > > > > > > Sent: Thursday, May 10, 2012 9:51:32 AM > > > > Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been > > > > updated > > > > > > > > > ----- Original Message ----- > > > > > From: "Saggi Mizrahi" > > > > > Sent: Thursday, May 10, 2012 4:39:49 PM > > > > > > > > > > I do express that empty mount options SHOULD NOT send an > > > > > empty > > > > > string, rather, omit the whole argument. > > > > > > > > Yes, this should be handled on the backend side (Yair - please > > > > note, > > > > maybe it is already implemented like this - don't know): When > > > > getting a null-or-empty "mount options" value from the client, > > > > the > > > > backend needs to make sure to *not* set the relevant parameter > > > > in > > > > the vdsm verb at all. > > > > > > > > So leaving the "mount options" text-box empty in the GUI is > > > > legal, > > > > only needs to be handled in a certain way in the backend. > > > > > > > > > > > > In theory for a PosixFS file system a user could create multiple > > > storage domains of different PosixFS types. Perhaps that's not a > > > problem, but worth noting. > > > > > > Is "Path" the correct term to use for the remote mount? I can > > > imagine > > > customers thinking that is local and messing with fstab. > > > Not sure if there's a better term - filesystem URI ? > > > > - In the initial mock-up, it was called "Mount Spec". Is it better? > > I don't like any of the options - but have a preference for > Filesystem URI, but I'd like others to weigh in here. > My concern with path is that it could mean local or remote, so > another option is "Remote Path" But it *can* be local or remote, so why "Remote Path"? "Path" actually sounds like a good term. > > > > > > - Note that the current PosixFS implementation in the rest-api > > utilizes the already-existing "" property within the > > "" tag within the "" rest-api business > > entity, therefore I put in the mockup the same term. > > Do you think that the rest-api should have a different term as > > well? > > > > > > > > I presume we are doing just not-null validation for path. > > > > > > Obviously we can't validate the mount options but how good is the > > > error reporting back going to be - if the mount options are > > > wrong, > > > or if something fails with the mount will we see "error 12345" in > > > the UI and require the user to go digging in vdsm logs or are we > > > going to pull back and display toe complete message. > > > > Depends on backend/vdsm; Yair/Ayal? > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Einav Cohen" > > > > > > To: "Yair Zaslavsky" , "Ayal Baron" > > > > > > > > > > > > Cc: "Saggi Mizrahi" , "Andrew Cathrow" > > > > > > , "Miki Kenneth" > > > > > > , "Simon Grinberg" > > > > > > , > > > > > > "Eldan Hildesheim" , "Eldan > > > > > > Hildesheim" , "Alexey Chub" > > > > > > , > > > > > > engine-devel at ovirt.org, "Haim Ateya" > > > > > > > > > > > > Sent: Thursday, May 10, 2012 9:28:31 AM > > > > > > Subject: Re: PosixFS: GUI mock-ups have been updated > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Yair Zaslavsky" > > > > > > > Sent: Thursday, May 10, 2012 4:21:42 PM > > > > > > > > > > > > > > On 05/10/2012 04:16 PM, Einav Cohen wrote: > > > > > > > > Please review the mock-ups on the feature page: > > > > > > > > http://www.ovirt.org/wiki/Features/PosixFSConnection#Changes_in_GUI > > > > > > > > > > > > > > > > Comments are welcome. > > > > > > > > > > > > > > From talking to Haim I understood that path should > > > > > > > include > > > > > > > ":" > > > > > > > > > > > > From talking to Ayal, the path can be similar in its format > > > > > > to > > > > > > a > > > > > > path > > > > > > provided when creating an NFS storage domain (e.g. > > > > > > "server:/dir1/dir2"), *or* to a path provided when creating > > > > > > a > > > > > > Local > > > > > > storage domain (e.g. "/tmp/dir3"), meaning, without ":". > > > > > > @Ayal - any chance for a clarification here? > > > > > > > > > > > > > In addition - if we only support V1, why add the combo > > > > > > > box? > > > > > > > > > > > > We are always showing the combo-box, even if we have only > > > > > > one > > > > > > option > > > > > > in it (so the user will know what is the value that is > > > > > > being > > > > > > sent). > > > > > > However, we disable it. I updated the mock-up to clarify > > > > > > this. > > > > > > > > > > > > > > > > > > > > Thanks! > > > > > > > > > > > > > > > > > > > > > > > ---- > > > > > > > > Thanks, > > > > > > > > Einav > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Engine-devel mailing list > > > > > Engine-devel at ovirt.org > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Engine-devel mailing list > > > > Engine-devel at ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > _______________________________________________ > > > Engine-devel mailing list > > > Engine-devel at ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > From acathrow at redhat.com Thu May 10 17:03:16 2012 From: acathrow at redhat.com (Andrew Cathrow) Date: Thu, 10 May 2012 13:03:16 -0400 (EDT) Subject: [Engine-devel] PosixFS: GUI mock-ups have been updated In-Reply-To: <88bddd4b-ac7a-4e16-a065-ec278bd002de@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <8f3c1897-4cc4-464f-9b89-e967f10b6b54@zmail07.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Einav Cohen" > To: "Andrew Cathrow" > Cc: engine-devel at ovirt.org, "Simon Grinberg" , "Saggi Mizrahi" , "Geert > Jansen" , "Ori Liel" , "Yair Zaslavsky" , "Ayal Baron" > > Sent: Thursday, May 10, 2012 1:01:20 PM > Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated > > > ----- Original Message ----- > > From: "Andrew Cathrow" > > Sent: Thursday, May 10, 2012 6:06:23 PM > > > > > > ----- Original Message ----- > > > From: "Einav Cohen" > > > To: "Andrew Cathrow" , "Geert Jansen" > > > , "Ori Liel" , "Yair > > > Zaslavsky" , "Ayal Baron" > > > > > > Cc: engine-devel at ovirt.org, "Simon Grinberg" > > > , > > > "Saggi Mizrahi" > > > Sent: Thursday, May 10, 2012 10:56:09 AM > > > Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been > > > updated > > > > > > > ----- Original Message ----- > > > > From: "Andrew Cathrow" > > > > Sent: Thursday, May 10, 2012 4:57:44 PM > > > > > > > > ----- Original Message ----- > > > > > From: "Einav Cohen" > > > > > To: "Saggi Mizrahi" , "Yair Zaslavsky" > > > > > > > > > > Cc: "Haim Ateya" , "Eldan Hildesheim" > > > > > , engine-devel at ovirt.org, "Eldan > > > > > Hildesheim" , "Simon Grinberg" > > > > > > > > > > Sent: Thursday, May 10, 2012 9:51:32 AM > > > > > Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been > > > > > updated > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Saggi Mizrahi" > > > > > > Sent: Thursday, May 10, 2012 4:39:49 PM > > > > > > > > > > > > I do express that empty mount options SHOULD NOT send an > > > > > > empty > > > > > > string, rather, omit the whole argument. > > > > > > > > > > Yes, this should be handled on the backend side (Yair - > > > > > please > > > > > note, > > > > > maybe it is already implemented like this - don't know): When > > > > > getting a null-or-empty "mount options" value from the > > > > > client, > > > > > the > > > > > backend needs to make sure to *not* set the relevant > > > > > parameter > > > > > in > > > > > the vdsm verb at all. > > > > > > > > > > So leaving the "mount options" text-box empty in the GUI is > > > > > legal, > > > > > only needs to be handled in a certain way in the backend. > > > > > > > > > > > > > > > > In theory for a PosixFS file system a user could create > > > > multiple > > > > storage domains of different PosixFS types. Perhaps that's not > > > > a > > > > problem, but worth noting. > > > > > > > > Is "Path" the correct term to use for the remote mount? I can > > > > imagine > > > > customers thinking that is local and messing with fstab. > > > > Not sure if there's a better term - filesystem URI ? > > > > > > - In the initial mock-up, it was called "Mount Spec". Is it > > > better? > > > > I don't like any of the options - but have a preference for > > Filesystem URI, but I'd like others to weigh in here. > > My concern with path is that it could mean local or remote, so > > another option is "Remote Path" > > But it *can* be local or remote, so why "Remote Path"? "Path" > actually sounds like a good term. > Can it be local - do we want a user mounting a local filesystem? > > > > > > > > > > - Note that the current PosixFS implementation in the rest-api > > > utilizes the already-existing "" property within the > > > "" tag within the "" rest-api business > > > entity, therefore I put in the mockup the same term. > > > Do you think that the rest-api should have a different term as > > > well? > > > > > > > > > > > I presume we are doing just not-null validation for path. > > > > > > > > Obviously we can't validate the mount options but how good is > > > > the > > > > error reporting back going to be - if the mount options are > > > > wrong, > > > > or if something fails with the mount will we see "error 12345" > > > > in > > > > the UI and require the user to go digging in vdsm logs or are > > > > we > > > > going to pull back and display toe complete message. > > > > > > Depends on backend/vdsm; Yair/Ayal? > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Einav Cohen" > > > > > > > To: "Yair Zaslavsky" , "Ayal Baron" > > > > > > > > > > > > > > Cc: "Saggi Mizrahi" , "Andrew > > > > > > > Cathrow" > > > > > > > , "Miki Kenneth" > > > > > > > , "Simon Grinberg" > > > > > > > , > > > > > > > "Eldan Hildesheim" , "Eldan > > > > > > > Hildesheim" , "Alexey Chub" > > > > > > > , > > > > > > > engine-devel at ovirt.org, "Haim Ateya" > > > > > > > > > > > > > > Sent: Thursday, May 10, 2012 9:28:31 AM > > > > > > > Subject: Re: PosixFS: GUI mock-ups have been updated > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Yair Zaslavsky" > > > > > > > > Sent: Thursday, May 10, 2012 4:21:42 PM > > > > > > > > > > > > > > > > On 05/10/2012 04:16 PM, Einav Cohen wrote: > > > > > > > > > Please review the mock-ups on the feature page: > > > > > > > > > http://www.ovirt.org/wiki/Features/PosixFSConnection#Changes_in_GUI > > > > > > > > > > > > > > > > > > Comments are welcome. > > > > > > > > > > > > > > > > From talking to Haim I understood that path should > > > > > > > > include > > > > > > > > ":" > > > > > > > > > > > > > > From talking to Ayal, the path can be similar in its > > > > > > > format > > > > > > > to > > > > > > > a > > > > > > > path > > > > > > > provided when creating an NFS storage domain (e.g. > > > > > > > "server:/dir1/dir2"), *or* to a path provided when > > > > > > > creating > > > > > > > a > > > > > > > Local > > > > > > > storage domain (e.g. "/tmp/dir3"), meaning, without ":". > > > > > > > @Ayal - any chance for a clarification here? > > > > > > > > > > > > > > > In addition - if we only support V1, why add the combo > > > > > > > > box? > > > > > > > > > > > > > > We are always showing the combo-box, even if we have only > > > > > > > one > > > > > > > option > > > > > > > in it (so the user will know what is the value that is > > > > > > > being > > > > > > > sent). > > > > > > > However, we disable it. I updated the mock-up to clarify > > > > > > > this. > > > > > > > > > > > > > > > > > > > > > > > Thanks! > > > > > > > > > > > > > > > > > > > > > > > > > > ---- > > > > > > > > > Thanks, > > > > > > > > > Einav > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Engine-devel mailing list > > > > > > Engine-devel at ovirt.org > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Engine-devel mailing list > > > > > Engine-devel at ovirt.org > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > _______________________________________________ > > > > Engine-devel mailing list > > > > Engine-devel at ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > From ecohen at redhat.com Thu May 10 17:12:06 2012 From: ecohen at redhat.com (Einav Cohen) Date: Thu, 10 May 2012 13:12:06 -0400 (EDT) Subject: [Engine-devel] PosixFS: GUI mock-ups have been updated In-Reply-To: <8f3c1897-4cc4-464f-9b89-e967f10b6b54@zmail07.collab.prod.int.phx2.redhat.com> Message-ID: <55ae627b-7eb4-4622-9155-253b59569d9f@zmail04.collab.prod.int.phx2.redhat.com> > ----- Original Message ----- > From: "Andrew Cathrow" > Sent: Thursday, May 10, 2012 8:03:16 PM > > > ----- Original Message ----- > > From: "Einav Cohen" > > To: "Andrew Cathrow" > > Cc: engine-devel at ovirt.org, "Simon Grinberg" , > > "Saggi Mizrahi" , "Geert > > Jansen" , "Ori Liel" , "Yair > > Zaslavsky" , "Ayal Baron" > > > > Sent: Thursday, May 10, 2012 1:01:20 PM > > Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated > > > > > ----- Original Message ----- > > > From: "Andrew Cathrow" > > > Sent: Thursday, May 10, 2012 6:06:23 PM > > > > > > > > > ----- Original Message ----- > > > > From: "Einav Cohen" > > > > To: "Andrew Cathrow" , "Geert Jansen" > > > > , "Ori Liel" , "Yair > > > > Zaslavsky" , "Ayal Baron" > > > > > > > > Cc: engine-devel at ovirt.org, "Simon Grinberg" > > > > , > > > > "Saggi Mizrahi" > > > > Sent: Thursday, May 10, 2012 10:56:09 AM > > > > Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been > > > > updated > > > > > > > > > ----- Original Message ----- > > > > > From: "Andrew Cathrow" > > > > > Sent: Thursday, May 10, 2012 4:57:44 PM > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Einav Cohen" > > > > > > To: "Saggi Mizrahi" , "Yair Zaslavsky" > > > > > > > > > > > > Cc: "Haim Ateya" , "Eldan Hildesheim" > > > > > > , engine-devel at ovirt.org, "Eldan > > > > > > Hildesheim" , "Simon Grinberg" > > > > > > > > > > > > Sent: Thursday, May 10, 2012 9:51:32 AM > > > > > > Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been > > > > > > updated > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Saggi Mizrahi" > > > > > > > Sent: Thursday, May 10, 2012 4:39:49 PM > > > > > > > > > > > > > > I do express that empty mount options SHOULD NOT send an > > > > > > > empty > > > > > > > string, rather, omit the whole argument. > > > > > > > > > > > > Yes, this should be handled on the backend side (Yair - > > > > > > please > > > > > > note, > > > > > > maybe it is already implemented like this - don't know): > > > > > > When > > > > > > getting a null-or-empty "mount options" value from the > > > > > > client, > > > > > > the > > > > > > backend needs to make sure to *not* set the relevant > > > > > > parameter > > > > > > in > > > > > > the vdsm verb at all. > > > > > > > > > > > > So leaving the "mount options" text-box empty in the GUI is > > > > > > legal, > > > > > > only needs to be handled in a certain way in the backend. > > > > > > > > > > > > > > > > > > > > In theory for a PosixFS file system a user could create > > > > > multiple > > > > > storage domains of different PosixFS types. Perhaps that's > > > > > not > > > > > a > > > > > problem, but worth noting. > > > > > > > > > > Is "Path" the correct term to use for the remote mount? I can > > > > > imagine > > > > > customers thinking that is local and messing with fstab. > > > > > Not sure if there's a better term - filesystem URI ? > > > > > > > > - In the initial mock-up, it was called "Mount Spec". Is it > > > > better? > > > > > > I don't like any of the options - but have a preference for > > > Filesystem URI, but I'd like others to weigh in here. > > > My concern with path is that it could mean local or remote, so > > > another option is "Remote Path" > > > > But it *can* be local or remote, so why "Remote Path"? "Path" > > actually sounds like a good term. > > > > Can it be local - do we want a user mounting a local filesystem? If it is possible - I don't see why limiting it. It should be similar to defining a "Local on Host" storage domain IIUC. Even if it is potentially harmful for some reason, we don't want to nanny the user, right? He should know what he is doing. > > > > > > > > > > > > > > - Note that the current PosixFS implementation in the rest-api > > > > utilizes the already-existing "" property within the > > > > "" tag within the "" rest-api business > > > > entity, therefore I put in the mockup the same term. > > > > Do you think that the rest-api should have a different term as > > > > well? > > > > > > > > > > > > > > I presume we are doing just not-null validation for path. > > > > > > > > > > Obviously we can't validate the mount options but how good is > > > > > the > > > > > error reporting back going to be - if the mount options are > > > > > wrong, > > > > > or if something fails with the mount will we see "error > > > > > 12345" > > > > > in > > > > > the UI and require the user to go digging in vdsm logs or are > > > > > we > > > > > going to pull back and display toe complete message. > > > > > > > > Depends on backend/vdsm; Yair/Ayal? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Einav Cohen" > > > > > > > > To: "Yair Zaslavsky" , "Ayal > > > > > > > > Baron" > > > > > > > > > > > > > > > > Cc: "Saggi Mizrahi" , "Andrew > > > > > > > > Cathrow" > > > > > > > > , "Miki Kenneth" > > > > > > > > , "Simon Grinberg" > > > > > > > > , > > > > > > > > "Eldan Hildesheim" , "Eldan > > > > > > > > Hildesheim" , "Alexey Chub" > > > > > > > > , > > > > > > > > engine-devel at ovirt.org, "Haim Ateya" > > > > > > > > > > > > > > > > Sent: Thursday, May 10, 2012 9:28:31 AM > > > > > > > > Subject: Re: PosixFS: GUI mock-ups have been updated > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > From: "Yair Zaslavsky" > > > > > > > > > Sent: Thursday, May 10, 2012 4:21:42 PM > > > > > > > > > > > > > > > > > > On 05/10/2012 04:16 PM, Einav Cohen wrote: > > > > > > > > > > Please review the mock-ups on the feature page: > > > > > > > > > > http://www.ovirt.org/wiki/Features/PosixFSConnection#Changes_in_GUI > > > > > > > > > > > > > > > > > > > > Comments are welcome. > > > > > > > > > > > > > > > > > > From talking to Haim I understood that path should > > > > > > > > > include > > > > > > > > > ":" > > > > > > > > > > > > > > > > From talking to Ayal, the path can be similar in its > > > > > > > > format > > > > > > > > to > > > > > > > > a > > > > > > > > path > > > > > > > > provided when creating an NFS storage domain (e.g. > > > > > > > > "server:/dir1/dir2"), *or* to a path provided when > > > > > > > > creating > > > > > > > > a > > > > > > > > Local > > > > > > > > storage domain (e.g. "/tmp/dir3"), meaning, without > > > > > > > > ":". > > > > > > > > @Ayal - any chance for a clarification here? > > > > > > > > > > > > > > > > > In addition - if we only support V1, why add the > > > > > > > > > combo > > > > > > > > > box? > > > > > > > > > > > > > > > > We are always showing the combo-box, even if we have > > > > > > > > only > > > > > > > > one > > > > > > > > option > > > > > > > > in it (so the user will know what is the value that is > > > > > > > > being > > > > > > > > sent). > > > > > > > > However, we disable it. I updated the mock-up to > > > > > > > > clarify > > > > > > > > this. > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ---- > > > > > > > > > > Thanks, > > > > > > > > > > Einav > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Engine-devel mailing list > > > > > > > Engine-devel at ovirt.org > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Engine-devel mailing list > > > > > > Engine-devel at ovirt.org > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > _______________________________________________ > > > > > Engine-devel mailing list > > > > > Engine-devel at ovirt.org > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > > > > > From acathrow at redhat.com Thu May 10 17:18:58 2012 From: acathrow at redhat.com (Andrew Cathrow) Date: Thu, 10 May 2012 13:18:58 -0400 (EDT) Subject: [Engine-devel] PosixFS: GUI mock-ups have been updated In-Reply-To: <55ae627b-7eb4-4622-9155-253b59569d9f@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <99c27bec-861f-4f91-8744-5a5d5df0d023@zmail07.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Einav Cohen" > To: "Andrew Cathrow" > Cc: engine-devel at ovirt.org, "Simon Grinberg" , "Saggi Mizrahi" , "Geert > Jansen" , "Ori Liel" , "Yair Zaslavsky" , "Ayal Baron" > > Sent: Thursday, May 10, 2012 1:12:06 PM > Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated > > > ----- Original Message ----- > > From: "Andrew Cathrow" > > Sent: Thursday, May 10, 2012 8:03:16 PM > > > > > > ----- Original Message ----- > > > From: "Einav Cohen" > > > To: "Andrew Cathrow" > > > Cc: engine-devel at ovirt.org, "Simon Grinberg" > > > , > > > "Saggi Mizrahi" , "Geert > > > Jansen" , "Ori Liel" , > > > "Yair > > > Zaslavsky" , "Ayal Baron" > > > > > > Sent: Thursday, May 10, 2012 1:01:20 PM > > > Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been > > > updated > > > > > > > ----- Original Message ----- > > > > From: "Andrew Cathrow" > > > > Sent: Thursday, May 10, 2012 6:06:23 PM > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Einav Cohen" > > > > > To: "Andrew Cathrow" , "Geert Jansen" > > > > > , "Ori Liel" , "Yair > > > > > Zaslavsky" , "Ayal Baron" > > > > > > > > > > Cc: engine-devel at ovirt.org, "Simon Grinberg" > > > > > , > > > > > "Saggi Mizrahi" > > > > > Sent: Thursday, May 10, 2012 10:56:09 AM > > > > > Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been > > > > > updated > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Andrew Cathrow" > > > > > > Sent: Thursday, May 10, 2012 4:57:44 PM > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Einav Cohen" > > > > > > > To: "Saggi Mizrahi" , "Yair > > > > > > > Zaslavsky" > > > > > > > > > > > > > > Cc: "Haim Ateya" , "Eldan Hildesheim" > > > > > > > , engine-devel at ovirt.org, "Eldan > > > > > > > Hildesheim" , "Simon Grinberg" > > > > > > > > > > > > > > Sent: Thursday, May 10, 2012 9:51:32 AM > > > > > > > Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have > > > > > > > been > > > > > > > updated > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Saggi Mizrahi" > > > > > > > > Sent: Thursday, May 10, 2012 4:39:49 PM > > > > > > > > > > > > > > > > I do express that empty mount options SHOULD NOT send > > > > > > > > an > > > > > > > > empty > > > > > > > > string, rather, omit the whole argument. > > > > > > > > > > > > > > Yes, this should be handled on the backend side (Yair - > > > > > > > please > > > > > > > note, > > > > > > > maybe it is already implemented like this - don't know): > > > > > > > When > > > > > > > getting a null-or-empty "mount options" value from the > > > > > > > client, > > > > > > > the > > > > > > > backend needs to make sure to *not* set the relevant > > > > > > > parameter > > > > > > > in > > > > > > > the vdsm verb at all. > > > > > > > > > > > > > > So leaving the "mount options" text-box empty in the GUI > > > > > > > is > > > > > > > legal, > > > > > > > only needs to be handled in a certain way in the backend. > > > > > > > > > > > > > > > > > > > > > > > > In theory for a PosixFS file system a user could create > > > > > > multiple > > > > > > storage domains of different PosixFS types. Perhaps that's > > > > > > not > > > > > > a > > > > > > problem, but worth noting. > > > > > > > > > > > > Is "Path" the correct term to use for the remote mount? I > > > > > > can > > > > > > imagine > > > > > > customers thinking that is local and messing with fstab. > > > > > > Not sure if there's a better term - filesystem URI ? > > > > > > > > > > - In the initial mock-up, it was called "Mount Spec". Is it > > > > > better? > > > > > > > > I don't like any of the options - but have a preference for > > > > Filesystem URI, but I'd like others to weigh in here. > > > > My concern with path is that it could mean local or remote, so > > > > another option is "Remote Path" > > > > > > But it *can* be local or remote, so why "Remote Path"? "Path" > > > actually sounds like a good term. > > > > > > > Can it be local - do we want a user mounting a local filesystem? > > If it is possible - I don't see why limiting it. It should be similar > to defining a "Local on Host" storage domain IIUC. Even if it is > potentially harmful for some reason, we don't want to nanny the > user, right? He should know what he is doing. I'm not saying we should stop them, we should make it clear how this is going to be used. When we're setting up a storage domain it's shared storage. > > > > > > > > > > > > > > > > > > > - Note that the current PosixFS implementation in the > > > > > rest-api > > > > > utilizes the already-existing "" property within the > > > > > "" tag within the "" rest-api > > > > > business > > > > > entity, therefore I put in the mockup the same term. > > > > > Do you think that the rest-api should have a different term > > > > > as > > > > > well? > > > > > > > > > > > > > > > > > I presume we are doing just not-null validation for path. > > > > > > > > > > > > Obviously we can't validate the mount options but how good > > > > > > is > > > > > > the > > > > > > error reporting back going to be - if the mount options are > > > > > > wrong, > > > > > > or if something fails with the mount will we see "error > > > > > > 12345" > > > > > > in > > > > > > the UI and require the user to go digging in vdsm logs or > > > > > > are > > > > > > we > > > > > > going to pull back and display toe complete message. > > > > > > > > > > Depends on backend/vdsm; Yair/Ayal? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > From: "Einav Cohen" > > > > > > > > > To: "Yair Zaslavsky" , "Ayal > > > > > > > > > Baron" > > > > > > > > > > > > > > > > > > Cc: "Saggi Mizrahi" , "Andrew > > > > > > > > > Cathrow" > > > > > > > > > , "Miki Kenneth" > > > > > > > > > , "Simon Grinberg" > > > > > > > > > , > > > > > > > > > "Eldan Hildesheim" , "Eldan > > > > > > > > > Hildesheim" , "Alexey Chub" > > > > > > > > > , > > > > > > > > > engine-devel at ovirt.org, "Haim Ateya" > > > > > > > > > > > > > > > > > > Sent: Thursday, May 10, 2012 9:28:31 AM > > > > > > > > > Subject: Re: PosixFS: GUI mock-ups have been updated > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > From: "Yair Zaslavsky" > > > > > > > > > > Sent: Thursday, May 10, 2012 4:21:42 PM > > > > > > > > > > > > > > > > > > > > On 05/10/2012 04:16 PM, Einav Cohen wrote: > > > > > > > > > > > Please review the mock-ups on the feature page: > > > > > > > > > > > http://www.ovirt.org/wiki/Features/PosixFSConnection#Changes_in_GUI > > > > > > > > > > > > > > > > > > > > > > Comments are welcome. > > > > > > > > > > > > > > > > > > > > From talking to Haim I understood that path should > > > > > > > > > > include > > > > > > > > > > ":" > > > > > > > > > > > > > > > > > > From talking to Ayal, the path can be similar in its > > > > > > > > > format > > > > > > > > > to > > > > > > > > > a > > > > > > > > > path > > > > > > > > > provided when creating an NFS storage domain (e.g. > > > > > > > > > "server:/dir1/dir2"), *or* to a path provided when > > > > > > > > > creating > > > > > > > > > a > > > > > > > > > Local > > > > > > > > > storage domain (e.g. "/tmp/dir3"), meaning, without > > > > > > > > > ":". > > > > > > > > > @Ayal - any chance for a clarification here? > > > > > > > > > > > > > > > > > > > In addition - if we only support V1, why add the > > > > > > > > > > combo > > > > > > > > > > box? > > > > > > > > > > > > > > > > > > We are always showing the combo-box, even if we have > > > > > > > > > only > > > > > > > > > one > > > > > > > > > option > > > > > > > > > in it (so the user will know what is the value that > > > > > > > > > is > > > > > > > > > being > > > > > > > > > sent). > > > > > > > > > However, we disable it. I updated the mock-up to > > > > > > > > > clarify > > > > > > > > > this. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ---- > > > > > > > > > > > Thanks, > > > > > > > > > > > Einav > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Engine-devel mailing list > > > > > > > > Engine-devel at ovirt.org > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Engine-devel mailing list > > > > > > > Engine-devel at ovirt.org > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > _______________________________________________ > > > > > > Engine-devel mailing list > > > > > > Engine-devel at ovirt.org > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From ecohen at redhat.com Thu May 10 17:42:15 2012 From: ecohen at redhat.com (Einav Cohen) Date: Thu, 10 May 2012 13:42:15 -0400 (EDT) Subject: [Engine-devel] PosixFS: GUI mock-ups have been updated In-Reply-To: <99c27bec-861f-4f91-8744-5a5d5df0d023@zmail07.collab.prod.int.phx2.redhat.com> Message-ID: <94b39630-75dc-4053-9bfc-5593a6670155@zmail04.collab.prod.int.phx2.redhat.com> > ----- Original Message ----- > From: "Andrew Cathrow" > Sent: Thursday, May 10, 2012 8:18:58 PM > > ----- Original Message ----- > > From: "Einav Cohen" > > To: "Andrew Cathrow" > > Cc: engine-devel at ovirt.org, "Simon Grinberg" , > > "Saggi Mizrahi" , "Geert > > Jansen" , "Ori Liel" , "Yair > > Zaslavsky" , "Ayal Baron" > > > > Sent: Thursday, May 10, 2012 1:12:06 PM > > Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated > > > > > ----- Original Message ----- > > > From: "Andrew Cathrow" > > > Sent: Thursday, May 10, 2012 8:03:16 PM > > > > > > > > > ----- Original Message ----- > > > > From: "Einav Cohen" > > > > To: "Andrew Cathrow" > > > > Cc: engine-devel at ovirt.org, "Simon Grinberg" > > > > , > > > > "Saggi Mizrahi" , "Geert > > > > Jansen" , "Ori Liel" , > > > > "Yair > > > > Zaslavsky" , "Ayal Baron" > > > > > > > > Sent: Thursday, May 10, 2012 1:01:20 PM > > > > Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been > > > > updated > > > > > > > > > ----- Original Message ----- > > > > > From: "Andrew Cathrow" > > > > > Sent: Thursday, May 10, 2012 6:06:23 PM > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Einav Cohen" > > > > > > To: "Andrew Cathrow" , "Geert Jansen" > > > > > > , "Ori Liel" , "Yair > > > > > > Zaslavsky" , "Ayal Baron" > > > > > > > > > > > > Cc: engine-devel at ovirt.org, "Simon Grinberg" > > > > > > , > > > > > > "Saggi Mizrahi" > > > > > > Sent: Thursday, May 10, 2012 10:56:09 AM > > > > > > Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been > > > > > > updated > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Andrew Cathrow" > > > > > > > Sent: Thursday, May 10, 2012 4:57:44 PM > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Einav Cohen" > > > > > > > > To: "Saggi Mizrahi" , "Yair > > > > > > > > Zaslavsky" > > > > > > > > > > > > > > > > Cc: "Haim Ateya" , "Eldan > > > > > > > > Hildesheim" > > > > > > > > , engine-devel at ovirt.org, "Eldan > > > > > > > > Hildesheim" , "Simon Grinberg" > > > > > > > > > > > > > > > > Sent: Thursday, May 10, 2012 9:51:32 AM > > > > > > > > Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have > > > > > > > > been > > > > > > > > updated > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > From: "Saggi Mizrahi" > > > > > > > > > Sent: Thursday, May 10, 2012 4:39:49 PM > > > > > > > > > > > > > > > > > > I do express that empty mount options SHOULD NOT send > > > > > > > > > an > > > > > > > > > empty > > > > > > > > > string, rather, omit the whole argument. > > > > > > > > > > > > > > > > Yes, this should be handled on the backend side (Yair - > > > > > > > > please > > > > > > > > note, > > > > > > > > maybe it is already implemented like this - don't > > > > > > > > know): > > > > > > > > When > > > > > > > > getting a null-or-empty "mount options" value from the > > > > > > > > client, > > > > > > > > the > > > > > > > > backend needs to make sure to *not* set the relevant > > > > > > > > parameter > > > > > > > > in > > > > > > > > the vdsm verb at all. > > > > > > > > > > > > > > > > So leaving the "mount options" text-box empty in the > > > > > > > > GUI > > > > > > > > is > > > > > > > > legal, > > > > > > > > only needs to be handled in a certain way in the > > > > > > > > backend. > > > > > > > > > > > > > > > > > > > > > > > > > > > > In theory for a PosixFS file system a user could create > > > > > > > multiple > > > > > > > storage domains of different PosixFS types. Perhaps > > > > > > > that's > > > > > > > not > > > > > > > a > > > > > > > problem, but worth noting. > > > > > > > > > > > > > > Is "Path" the correct term to use for the remote mount? I > > > > > > > can > > > > > > > imagine > > > > > > > customers thinking that is local and messing with fstab. > > > > > > > Not sure if there's a better term - filesystem URI ? > > > > > > > > > > > > - In the initial mock-up, it was called "Mount Spec". Is it > > > > > > better? > > > > > > > > > > I don't like any of the options - but have a preference for > > > > > Filesystem URI, but I'd like others to weigh in here. > > > > > My concern with path is that it could mean local or remote, > > > > > so > > > > > another option is "Remote Path" > > > > > > > > But it *can* be local or remote, so why "Remote Path"? "Path" > > > > actually sounds like a good term. > > > > > > > > > > Can it be local - do we want a user mounting a local filesystem? > > > > If it is possible - I don't see why limiting it. It should be > > similar > > to defining a "Local on Host" storage domain IIUC. Even if it is > > potentially harmful for some reason, we don't want to nanny the > > user, right? He should know what he is doing. > > I'm not saying we should stop them, we should make it clear how this > is going to be used. > When we're setting up a storage domain it's shared storage. I am probably missing something here, but I assume that "Path" isn't a good term (I apologize for not understanding why). In any case, we need to finalize this term, since it has implications on the rest-api as well. Andrew/Geert/Simon/Ayal/Miki/Saggi/others: Please feel free to suggest a new term, or vote for one of the previously-discussed terms ("Remote Path" / "Path" / "Mount Spec" / "File System URI"). If no decision will be made here, the term will remain as-is, i.e. "Path". > > > > > > > > > > > > > > > > > > > > > > > > > > > - Note that the current PosixFS implementation in the > > > > > > rest-api > > > > > > utilizes the already-existing "" property within the > > > > > > "" tag within the "" rest-api > > > > > > business > > > > > > entity, therefore I put in the mockup the same term. > > > > > > Do you think that the rest-api should have a different term > > > > > > as > > > > > > well? > > > > > > > > > > > > > > > > > > > > I presume we are doing just not-null validation for path. > > > > > > > > > > > > > > Obviously we can't validate the mount options but how > > > > > > > good > > > > > > > is > > > > > > > the > > > > > > > error reporting back going to be - if the mount options > > > > > > > are > > > > > > > wrong, > > > > > > > or if something fails with the mount will we see "error > > > > > > > 12345" > > > > > > > in > > > > > > > the UI and require the user to go digging in vdsm logs or > > > > > > > are > > > > > > > we > > > > > > > going to pull back and display toe complete message. > > > > > > > > > > > > Depends on backend/vdsm; Yair/Ayal? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > From: "Einav Cohen" > > > > > > > > > > To: "Yair Zaslavsky" , "Ayal > > > > > > > > > > Baron" > > > > > > > > > > > > > > > > > > > > Cc: "Saggi Mizrahi" , "Andrew > > > > > > > > > > Cathrow" > > > > > > > > > > , "Miki Kenneth" > > > > > > > > > > , "Simon Grinberg" > > > > > > > > > > , > > > > > > > > > > "Eldan Hildesheim" , "Eldan > > > > > > > > > > Hildesheim" , "Alexey Chub" > > > > > > > > > > , > > > > > > > > > > engine-devel at ovirt.org, "Haim Ateya" > > > > > > > > > > > > > > > > > > > > Sent: Thursday, May 10, 2012 9:28:31 AM > > > > > > > > > > Subject: Re: PosixFS: GUI mock-ups have been > > > > > > > > > > updated > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > From: "Yair Zaslavsky" > > > > > > > > > > > Sent: Thursday, May 10, 2012 4:21:42 PM > > > > > > > > > > > > > > > > > > > > > > On 05/10/2012 04:16 PM, Einav Cohen wrote: > > > > > > > > > > > > Please review the mock-ups on the feature page: > > > > > > > > > > > > http://www.ovirt.org/wiki/Features/PosixFSConnection#Changes_in_GUI > > > > > > > > > > > > > > > > > > > > > > > > Comments are welcome. > > > > > > > > > > > > > > > > > > > > > > From talking to Haim I understood that path > > > > > > > > > > > should > > > > > > > > > > > include > > > > > > > > > > > ":" > > > > > > > > > > > > > > > > > > > > From talking to Ayal, the path can be similar in > > > > > > > > > > its > > > > > > > > > > format > > > > > > > > > > to > > > > > > > > > > a > > > > > > > > > > path > > > > > > > > > > provided when creating an NFS storage domain (e.g. > > > > > > > > > > "server:/dir1/dir2"), *or* to a path provided when > > > > > > > > > > creating > > > > > > > > > > a > > > > > > > > > > Local > > > > > > > > > > storage domain (e.g. "/tmp/dir3"), meaning, without > > > > > > > > > > ":". > > > > > > > > > > @Ayal - any chance for a clarification here? > > > > > > > > > > > > > > > > > > > > > In addition - if we only support V1, why add the > > > > > > > > > > > combo > > > > > > > > > > > box? > > > > > > > > > > > > > > > > > > > > We are always showing the combo-box, even if we > > > > > > > > > > have > > > > > > > > > > only > > > > > > > > > > one > > > > > > > > > > option > > > > > > > > > > in it (so the user will know what is the value that > > > > > > > > > > is > > > > > > > > > > being > > > > > > > > > > sent). > > > > > > > > > > However, we disable it. I updated the mock-up to > > > > > > > > > > clarify > > > > > > > > > > this. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ---- > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Einav > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Engine-devel mailing list > > > > > > > > > Engine-devel at ovirt.org > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Engine-devel mailing list > > > > > > > > Engine-devel at ovirt.org > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Engine-devel mailing list > > > > > > > Engine-devel at ovirt.org > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From acathrow at redhat.com Thu May 10 17:57:30 2012 From: acathrow at redhat.com (Andrew Cathrow) Date: Thu, 10 May 2012 13:57:30 -0400 (EDT) Subject: [Engine-devel] PosixFS: GUI mock-ups have been updated In-Reply-To: <94b39630-75dc-4053-9bfc-5593a6670155@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: ----- Original Message ----- > From: "Einav Cohen" > To: "Andrew Cathrow" > Cc: engine-devel at ovirt.org, "Simon Grinberg" , "Saggi Mizrahi" , "Geert > Jansen" , "Ori Liel" , "Yair Zaslavsky" , "Ayal Baron" > , "Miki Kenneth" > Sent: Thursday, May 10, 2012 1:42:15 PM > Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated > > > ----- Original Message ----- > > From: "Andrew Cathrow" > > Sent: Thursday, May 10, 2012 8:18:58 PM > > > > ----- Original Message ----- > > > From: "Einav Cohen" > > > To: "Andrew Cathrow" > > > Cc: engine-devel at ovirt.org, "Simon Grinberg" > > > , > > > "Saggi Mizrahi" , "Geert > > > Jansen" , "Ori Liel" , > > > "Yair > > > Zaslavsky" , "Ayal Baron" > > > > > > Sent: Thursday, May 10, 2012 1:12:06 PM > > > Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been > > > updated > > > > > > > ----- Original Message ----- > > > > From: "Andrew Cathrow" > > > > Sent: Thursday, May 10, 2012 8:03:16 PM > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Einav Cohen" > > > > > To: "Andrew Cathrow" > > > > > Cc: engine-devel at ovirt.org, "Simon Grinberg" > > > > > , > > > > > "Saggi Mizrahi" , "Geert > > > > > Jansen" , "Ori Liel" , > > > > > "Yair > > > > > Zaslavsky" , "Ayal Baron" > > > > > > > > > > Sent: Thursday, May 10, 2012 1:01:20 PM > > > > > Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been > > > > > updated > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Andrew Cathrow" > > > > > > Sent: Thursday, May 10, 2012 6:06:23 PM > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Einav Cohen" > > > > > > > To: "Andrew Cathrow" , "Geert > > > > > > > Jansen" > > > > > > > , "Ori Liel" , > > > > > > > "Yair > > > > > > > Zaslavsky" , "Ayal Baron" > > > > > > > > > > > > > > Cc: engine-devel at ovirt.org, "Simon Grinberg" > > > > > > > , > > > > > > > "Saggi Mizrahi" > > > > > > > Sent: Thursday, May 10, 2012 10:56:09 AM > > > > > > > Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have > > > > > > > been > > > > > > > updated > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Andrew Cathrow" > > > > > > > > Sent: Thursday, May 10, 2012 4:57:44 PM > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > From: "Einav Cohen" > > > > > > > > > To: "Saggi Mizrahi" , "Yair > > > > > > > > > Zaslavsky" > > > > > > > > > > > > > > > > > > Cc: "Haim Ateya" , "Eldan > > > > > > > > > Hildesheim" > > > > > > > > > , engine-devel at ovirt.org, "Eldan > > > > > > > > > Hildesheim" , "Simon Grinberg" > > > > > > > > > > > > > > > > > > Sent: Thursday, May 10, 2012 9:51:32 AM > > > > > > > > > Subject: Re: [Engine-devel] PosixFS: GUI mock-ups > > > > > > > > > have > > > > > > > > > been > > > > > > > > > updated > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > From: "Saggi Mizrahi" > > > > > > > > > > Sent: Thursday, May 10, 2012 4:39:49 PM > > > > > > > > > > > > > > > > > > > > I do express that empty mount options SHOULD NOT > > > > > > > > > > send > > > > > > > > > > an > > > > > > > > > > empty > > > > > > > > > > string, rather, omit the whole argument. > > > > > > > > > > > > > > > > > > Yes, this should be handled on the backend side (Yair > > > > > > > > > - > > > > > > > > > please > > > > > > > > > note, > > > > > > > > > maybe it is already implemented like this - don't > > > > > > > > > know): > > > > > > > > > When > > > > > > > > > getting a null-or-empty "mount options" value from > > > > > > > > > the > > > > > > > > > client, > > > > > > > > > the > > > > > > > > > backend needs to make sure to *not* set the relevant > > > > > > > > > parameter > > > > > > > > > in > > > > > > > > > the vdsm verb at all. > > > > > > > > > > > > > > > > > > So leaving the "mount options" text-box empty in the > > > > > > > > > GUI > > > > > > > > > is > > > > > > > > > legal, > > > > > > > > > only needs to be handled in a certain way in the > > > > > > > > > backend. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > In theory for a PosixFS file system a user could create > > > > > > > > multiple > > > > > > > > storage domains of different PosixFS types. Perhaps > > > > > > > > that's > > > > > > > > not > > > > > > > > a > > > > > > > > problem, but worth noting. > > > > > > > > > > > > > > > > Is "Path" the correct term to use for the remote mount? > > > > > > > > I > > > > > > > > can > > > > > > > > imagine > > > > > > > > customers thinking that is local and messing with > > > > > > > > fstab. > > > > > > > > Not sure if there's a better term - filesystem URI ? > > > > > > > > > > > > > > - In the initial mock-up, it was called "Mount Spec". Is > > > > > > > it > > > > > > > better? > > > > > > > > > > > > I don't like any of the options - but have a preference for > > > > > > Filesystem URI, but I'd like others to weigh in here. > > > > > > My concern with path is that it could mean local or remote, > > > > > > so > > > > > > another option is "Remote Path" > > > > > > > > > > But it *can* be local or remote, so why "Remote Path"? "Path" > > > > > actually sounds like a good term. > > > > > > > > > > > > > Can it be local - do we want a user mounting a local > > > > filesystem? > > > > > > If it is possible - I don't see why limiting it. It should be > > > similar > > > to defining a "Local on Host" storage domain IIUC. Even if it is > > > potentially harmful for some reason, we don't want to nanny the > > > user, right? He should know what he is doing. > > > > I'm not saying we should stop them, we should make it clear how > > this > > is going to be used. > > When we're setting up a storage domain it's shared storage. > > I am probably missing something here, but I assume that "Path" isn't > a good term (I apologize for not understanding why). > In any case, we need to finalize this term, since it has implications > on the rest-api as well. > The important thing is that it's clear what it is - eg. the remote/target not the local mount point. That could be accomplished in the tool tip, etc. > Andrew/Geert/Simon/Ayal/Miki/Saggi/others: Please feel free to > suggest a new term, or vote for one of the previously-discussed > terms ("Remote Path" / "Path" / "Mount Spec" / "File System URI"). > If no decision will be made here, the term will remain as-is, i.e. > "Path". > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - Note that the current PosixFS implementation in the > > > > > > > rest-api > > > > > > > utilizes the already-existing "" property within > > > > > > > the > > > > > > > "" tag within the "" rest-api > > > > > > > business > > > > > > > entity, therefore I put in the mockup the same term. > > > > > > > Do you think that the rest-api should have a different > > > > > > > term > > > > > > > as > > > > > > > well? > > > > > > > > > > > > > > > > > > > > > > > I presume we are doing just not-null validation for > > > > > > > > path. > > > > > > > > > > > > > > > > Obviously we can't validate the mount options but how > > > > > > > > good > > > > > > > > is > > > > > > > > the > > > > > > > > error reporting back going to be - if the mount options > > > > > > > > are > > > > > > > > wrong, > > > > > > > > or if something fails with the mount will we see "error > > > > > > > > 12345" > > > > > > > > in > > > > > > > > the UI and require the user to go digging in vdsm logs > > > > > > > > or > > > > > > > > are > > > > > > > > we > > > > > > > > going to pull back and display toe complete message. > > > > > > > > > > > > > > Depends on backend/vdsm; Yair/Ayal? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > From: "Einav Cohen" > > > > > > > > > > > To: "Yair Zaslavsky" , "Ayal > > > > > > > > > > > Baron" > > > > > > > > > > > > > > > > > > > > > > Cc: "Saggi Mizrahi" , > > > > > > > > > > > "Andrew > > > > > > > > > > > Cathrow" > > > > > > > > > > > , "Miki Kenneth" > > > > > > > > > > > , "Simon Grinberg" > > > > > > > > > > > , > > > > > > > > > > > "Eldan Hildesheim" , "Eldan > > > > > > > > > > > Hildesheim" , "Alexey Chub" > > > > > > > > > > > , > > > > > > > > > > > engine-devel at ovirt.org, "Haim Ateya" > > > > > > > > > > > > > > > > > > > > > > Sent: Thursday, May 10, 2012 9:28:31 AM > > > > > > > > > > > Subject: Re: PosixFS: GUI mock-ups have been > > > > > > > > > > > updated > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > From: "Yair Zaslavsky" > > > > > > > > > > > > Sent: Thursday, May 10, 2012 4:21:42 PM > > > > > > > > > > > > > > > > > > > > > > > > On 05/10/2012 04:16 PM, Einav Cohen wrote: > > > > > > > > > > > > > Please review the mock-ups on the feature > > > > > > > > > > > > > page: > > > > > > > > > > > > > http://www.ovirt.org/wiki/Features/PosixFSConnection#Changes_in_GUI > > > > > > > > > > > > > > > > > > > > > > > > > > Comments are welcome. > > > > > > > > > > > > > > > > > > > > > > > > From talking to Haim I understood that path > > > > > > > > > > > > should > > > > > > > > > > > > include > > > > > > > > > > > > ":" > > > > > > > > > > > > > > > > > > > > > > From talking to Ayal, the path can be similar in > > > > > > > > > > > its > > > > > > > > > > > format > > > > > > > > > > > to > > > > > > > > > > > a > > > > > > > > > > > path > > > > > > > > > > > provided when creating an NFS storage domain > > > > > > > > > > > (e.g. > > > > > > > > > > > "server:/dir1/dir2"), *or* to a path provided > > > > > > > > > > > when > > > > > > > > > > > creating > > > > > > > > > > > a > > > > > > > > > > > Local > > > > > > > > > > > storage domain (e.g. "/tmp/dir3"), meaning, > > > > > > > > > > > without > > > > > > > > > > > ":". > > > > > > > > > > > @Ayal - any chance for a clarification here? > > > > > > > > > > > > > > > > > > > > > > > In addition - if we only support V1, why add > > > > > > > > > > > > the > > > > > > > > > > > > combo > > > > > > > > > > > > box? > > > > > > > > > > > > > > > > > > > > > > We are always showing the combo-box, even if we > > > > > > > > > > > have > > > > > > > > > > > only > > > > > > > > > > > one > > > > > > > > > > > option > > > > > > > > > > > in it (so the user will know what is the value > > > > > > > > > > > that > > > > > > > > > > > is > > > > > > > > > > > being > > > > > > > > > > > sent). > > > > > > > > > > > However, we disable it. I updated the mock-up to > > > > > > > > > > > clarify > > > > > > > > > > > this. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ---- > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > Einav > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > Engine-devel mailing list > > > > > > > > > > Engine-devel at ovirt.org > > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Engine-devel mailing list > > > > > > > > > Engine-devel at ovirt.org > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Engine-devel mailing list > > > > > > > > Engine-devel at ovirt.org > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From ecohen at redhat.com Thu May 10 18:05:55 2012 From: ecohen at redhat.com (Einav Cohen) Date: Thu, 10 May 2012 14:05:55 -0400 (EDT) Subject: [Engine-devel] PosixFS: GUI mock-ups have been updated In-Reply-To: Message-ID: > ... > > The important thing is that it's clear what it is - eg. the > remote/target not the local mount point. That could be accomplished > in the tool tip, etc. So if there will be a tool-tip (or similar) in the GUI explaining what this field is supposed to be, are you OK with keeping the term "Path" (in both GUI and rest-api)? > > > Andrew/Geert/Simon/Ayal/Miki/Saggi/others: Please feel free to > > suggest a new term, or vote for one of the previously-discussed > > terms ("Remote Path" / "Path" / "Mount Spec" / "File System URI"). > > If no decision will be made here, the term will remain as-is, i.e. > > "Path". > > > ... From acathrow at redhat.com Thu May 10 18:15:23 2012 From: acathrow at redhat.com (Andrew Cathrow) Date: Thu, 10 May 2012 14:15:23 -0400 (EDT) Subject: [Engine-devel] PosixFS: GUI mock-ups have been updated In-Reply-To: Message-ID: <7a856274-3f88-40a7-b0fe-86b2623e0139@zmail07.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Einav Cohen" > To: "Andrew Cathrow" > Cc: engine-devel at ovirt.org, "Simon Grinberg" , "Saggi Mizrahi" , "Geert > Jansen" , "Ori Liel" , "Yair Zaslavsky" , "Ayal Baron" > , "Miki Kenneth" > Sent: Thursday, May 10, 2012 2:05:55 PM > Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated > > > ... > > > > The important thing is that it's clear what it is - eg. the > > remote/target not the local mount point. That could be accomplished > > in the tool tip, etc. > > So if there will be a tool-tip (or similar) in the GUI explaining > what this field is supposed to be, are you OK with keeping the term > "Path" (in both GUI and rest-api)? I am , does everyone else agree. > > > > > > Andrew/Geert/Simon/Ayal/Miki/Saggi/others: Please feel free to > > > suggest a new term, or vote for one of the previously-discussed > > > terms ("Remote Path" / "Path" / "Mount Spec" / "File System > > > URI"). > > > If no decision will be made here, the term will remain as-is, > > > i.e. > > > "Path". > > > > > ... > From abaron at redhat.com Thu May 10 19:46:44 2012 From: abaron at redhat.com (Ayal Baron) Date: Thu, 10 May 2012 15:46:44 -0400 (EDT) Subject: [Engine-devel] PosixFS: GUI mock-ups have been updated In-Reply-To: <7a856274-3f88-40a7-b0fe-86b2623e0139@zmail07.collab.prod.int.phx2.redhat.com> Message-ID: <3d5e2952-8c98-42e2-bc28-1b142f6fa291@zmail13.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > > > ----- Original Message ----- > > From: "Einav Cohen" > > To: "Andrew Cathrow" > > Cc: engine-devel at ovirt.org, "Simon Grinberg" , > > "Saggi Mizrahi" , "Geert > > Jansen" , "Ori Liel" , "Yair > > Zaslavsky" , "Ayal Baron" > > , "Miki Kenneth" > > Sent: Thursday, May 10, 2012 2:05:55 PM > > Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated > > > > > ... > > > > > > The important thing is that it's clear what it is - eg. the > > > remote/target not the local mount point. That could be > > > accomplished > > > in the tool tip, etc. > > > > So if there will be a tool-tip (or similar) in the GUI explaining > > what this field is supposed to be, are you OK with keeping the term > > "Path" (in both GUI and rest-api)? > > I am , does everyone else agree. either 'path' or 'device' "mount [-fnrsvw] [-t vfstype] [-o options] device dir" device is what is being mounted and in the case of NFS is server:path There is a reason why we termed it PosixFS and not SharedFS and that users can specify local devices/FS's (and there is no reason to limit it). Note that if user defines a local FS and adds 2 hosts to the Posix FS DC then 1 host will be non-op Miki - this is not cluster level seeing as PosixFS is a DC type (afaik) so no need for tooltips about that. In the future when we get rid of the single storage type in DC limitation then we'll be able to define a local posixFS domain and a shared one. > > > > > > > > > Andrew/Geert/Simon/Ayal/Miki/Saggi/others: Please feel free to > > > > suggest a new term, or vote for one of the previously-discussed > > > > terms ("Remote Path" / "Path" / "Mount Spec" / "File System > > > > URI"). > > > > If no decision will be made here, the term will remain as-is, > > > > i.e. > > > > "Path". > > > > > > > ... > > > From ItzikB at mellanox.com Fri May 11 00:52:15 2012 From: ItzikB at mellanox.com (Itzik Brown) Date: Fri, 11 May 2012 00:52:15 +0000 Subject: [Engine-devel] value too long for type character varying(20) in function "insertvds_interface" Message-ID: <4488206DC085244C886DBC9E7038B689251852C6@mtrdag02.mtl.com> Hi, When running VDSM on host with Infiniband HCAs I get the following errors in /usr/share/jboss-as/standalone/log/server.log on the ovirt-engine host. WARN [org.ovirt.engine.core.vdsbroker.VdsManager] (QuartzScheduler_Worker-17) ResourceManager::refreshVdsRunTimeInfo::Failed to refresh VDS , vds = 783eb0ac-9a91-11e1-a8e4-000c29de7759 : xena003, error = DataIntegrityViolationException: CallableStatementCallback; SQL [{call insertvds_interface(?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)}]; ERROR: value too long for type character varying(20) Where: SQL statement "INSERT INTO vds_interface(addr, bond_name, bond_type, gateway, id, is_bond, bond_opts, mac_addr, name, network_name, speed, subnet, boot_protocol, type, VDS_ID, vlan_id, mtu, bridged) VALUES(v_addr, v_bond_name, v_bond_type, v_gateway, v_id, v_is_bond, v_bond_opts, v_mac_addr, v_name, v_network_name, v_speed, v_subnet, v_boot_protocol, v_type, v_vds_id, v_vlan_id, v_mtu, v_bridged)" More detailed log: http://pastebin.com/AHD3di5i VDSM: From git repository commit 8a14b63fbbafbdb9ee7f85a9b702bff310f4f668 oVirt-engine: From git repository comit b24dddf094e08afa6a2032a487b37476318a872d Any suggestions? Regards, Itzik From ecohen at redhat.com Fri May 11 07:00:10 2012 From: ecohen at redhat.com (Einav Cohen) Date: Fri, 11 May 2012 03:00:10 -0400 (EDT) Subject: [Engine-devel] PosixFS: GUI mock-ups have been updated In-Reply-To: <3d5e2952-8c98-42e2-bc28-1b142f6fa291@zmail13.collab.prod.int.phx2.redhat.com> Message-ID: > ----- Original Message ----- > From: "Ayal Baron" > Sent: Thursday, May 10, 2012 10:46:44 PM > > > > > > > ----- Original Message ----- > > > From: "Einav Cohen" > > > To: "Andrew Cathrow" > > > Cc: engine-devel at ovirt.org, "Simon Grinberg" > > > , > > > "Saggi Mizrahi" , "Geert > > > Jansen" , "Ori Liel" , > > > "Yair > > > Zaslavsky" , "Ayal Baron" > > > , "Miki Kenneth" > > > Sent: Thursday, May 10, 2012 2:05:55 PM > > > Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been > > > updated > > > > > > > ... > > > > > > > > The important thing is that it's clear what it is - eg. the > > > > remote/target not the local mount point. That could be > > > > accomplished > > > > in the tool tip, etc. > > > > > > So if there will be a tool-tip (or similar) in the GUI explaining > > > what this field is supposed to be, are you OK with keeping the > > > term > > > "Path" (in both GUI and rest-api)? > > > > I am , does everyone else agree. > > either 'path' or 'device' - "Path" it is. - Instead of a tool-tip, I suggest to use an explanation caption below the text-box (similar to what we have for NFS storage domain - see attached). Agreed? - What should be the exact phrasing of the explanation text? > "mount [-fnrsvw] [-t vfstype] [-o options] device dir" > > device is what is being mounted and in the case of NFS is server:path > > There is a reason why we termed it PosixFS and not SharedFS and that > users can specify local devices/FS's (and there is no reason to > limit it). > > Note that if user defines a local FS and adds 2 hosts to the Posix FS > DC then 1 host will be non-op > > Miki - this is not cluster level seeing as PosixFS is a DC type > (afaik) so no need for tooltips about that. > > In the future when we get rid of the single storage type in DC > limitation then we'll be able to define a local posixFS domain and a > shared one. > > > > > > > > > > > > > > > > Andrew/Geert/Simon/Ayal/Miki/Saggi/others: Please feel free > > > > > to > > > > > suggest a new term, or vote for one of the > > > > > previously-discussed > > > > > terms ("Remote Path" / "Path" / "Mount Spec" / "File System > > > > > URI"). > > > > > If no decision will be made here, the term will remain as-is, > > > > > i.e. > > > > > "Path". > > > > > > > > > ... > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: NewNfsStorageDomainDialog-PathExplanation.png Type: image/png Size: 19600 bytes Desc: not available URL: From iheim at redhat.com Fri May 11 08:04:14 2012 From: iheim at redhat.com (Itamar Heim) Date: Fri, 11 May 2012 11:04:14 +0300 Subject: [Engine-devel] value too long for type character varying(20) in function "insertvds_interface" In-Reply-To: <4488206DC085244C886DBC9E7038B689251852C6@mtrdag02.mtl.com> References: <4488206DC085244C886DBC9E7038B689251852C6@mtrdag02.mtl.com> Message-ID: <4FACC7FE.4030700@redhat.com> On 05/11/2012 03:52 AM, Itzik Brown wrote: > Hi, > > When running VDSM on host with Infiniband HCAs I get the following errors in /usr/share/jboss-as/standalone/log/server.log on the ovirt-engine host. > > WARN [org.ovirt.engine.core.vdsbroker.VdsManager] (QuartzScheduler_Worker-17) ResourceManager::refreshVdsRunTimeInfo::Failed to refresh VDS , vds = 783eb0ac-9a91-11e1-a8e4-000c29de7759 : xena003, error = DataIntegrityViolationException: CallableStatementCallback; SQL [{call insertvds_interface(?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)}]; ERROR: value too long for type character varying(20) > Where: SQL statement "INSERT INTO vds_interface(addr, bond_name, bond_type, gateway, id, is_bond, bond_opts, mac_addr, name, network_name, speed, subnet, boot_protocol, type, VDS_ID, vlan_id, mtu, bridged) > VALUES(v_addr, v_bond_name, v_bond_type, v_gateway, v_id, v_is_bond, v_bond_opts, v_mac_addr, v_name, v_network_name, v_speed, v_subnet, v_boot_protocol, v_type, v_vds_id, v_vlan_id, v_mtu, v_bridged)" > > More detailed log: > http://pastebin.com/AHD3di5i > > VDSM: From git repository commit 8a14b63fbbafbdb9ee7f85a9b702bff310f4f668 > oVirt-engine: From git repository comit b24dddf094e08afa6a2032a487b37476318a872d > > Any suggestions? in general, you would need to send a patch to upgrade the scheme to a value longer than 20 characters for a logical network name. 1. I think bridge name is linux is limited to 15 characters, so not sure actually why 20 are allowed today. danken? 2. if changing the db scheme of the engine, also need to remember to upgrade the history db as well. 3. if different network implementation can support varying lengths, need to add validations in engine ("CanDoAction") to check the length per type of network implementation. > > Regards, > Itzik > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From abaron at redhat.com Fri May 11 08:39:42 2012 From: abaron at redhat.com (Ayal Baron) Date: Fri, 11 May 2012 04:39:42 -0400 (EDT) Subject: [Engine-devel] PosixFS: GUI mock-ups have been updated In-Reply-To: Message-ID: ----- Original Message ----- > > ----- Original Message ----- > > From: "Ayal Baron" > > Sent: Thursday, May 10, 2012 10:46:44 PM > > > > > > > > > > > ----- Original Message ----- > > > > From: "Einav Cohen" > > > > To: "Andrew Cathrow" > > > > Cc: engine-devel at ovirt.org, "Simon Grinberg" > > > > , > > > > "Saggi Mizrahi" , "Geert > > > > Jansen" , "Ori Liel" , > > > > "Yair > > > > Zaslavsky" , "Ayal Baron" > > > > , "Miki Kenneth" > > > > Sent: Thursday, May 10, 2012 2:05:55 PM > > > > Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been > > > > updated > > > > > > > > > ... > > > > > > > > > > The important thing is that it's clear what it is - eg. the > > > > > remote/target not the local mount point. That could be > > > > > accomplished > > > > > in the tool tip, etc. > > > > > > > > So if there will be a tool-tip (or similar) in the GUI > > > > explaining > > > > what this field is supposed to be, are you OK with keeping the > > > > term > > > > "Path" (in both GUI and rest-api)? > > > > > > I am , does everyone else agree. > > > > either 'path' or 'device' > > - "Path" it is. > - Instead of a tool-tip, I suggest to use an explanation caption > below the text-box (similar to what we have for NFS storage domain - > see attached). Agreed? i.e. "Path to device to mount / remote export" or something? > - What should be the exact phrasing of the explanation text? > > > "mount [-fnrsvw] [-t vfstype] [-o options] device dir" > > > > device is what is being mounted and in the case of NFS is > > server:path > > > > There is a reason why we termed it PosixFS and not SharedFS and > > that > > users can specify local devices/FS's (and there is no reason to > > limit it). > > > > Note that if user defines a local FS and adds 2 hosts to the Posix > > FS > > DC then 1 host will be non-op > > > > Miki - this is not cluster level seeing as PosixFS is a DC type > > (afaik) so no need for tooltips about that. > > > > In the future when we get rid of the single storage type in DC > > limitation then we'll be able to define a local posixFS domain and > > a > > shared one. > > > > > > > > > > > > > > > > > > > > > > > Andrew/Geert/Simon/Ayal/Miki/Saggi/others: Please feel free > > > > > > to > > > > > > suggest a new term, or vote for one of the > > > > > > previously-discussed > > > > > > terms ("Remote Path" / "Path" / "Mount Spec" / "File System > > > > > > URI"). > > > > > > If no decision will be made here, the term will remain > > > > > > as-is, > > > > > > i.e. > > > > > > "Path". > > > > > > > > > > > ... > > > > > > > > > > From danken at redhat.com Fri May 11 08:40:43 2012 From: danken at redhat.com (Dan Kenigsberg) Date: Fri, 11 May 2012 11:40:43 +0300 Subject: [Engine-devel] value too long for type character varying(20) in function "insertvds_interface" In-Reply-To: <4FACC7FE.4030700@redhat.com> References: <4488206DC085244C886DBC9E7038B689251852C6@mtrdag02.mtl.com> <4FACC7FE.4030700@redhat.com> Message-ID: <20120511084042.GF22381@redhat.com> On Fri, May 11, 2012 at 11:04:14AM +0300, Itamar Heim wrote: > On 05/11/2012 03:52 AM, Itzik Brown wrote: > >Hi, > > > >When running VDSM on host with Infiniband HCAs I get the following errors in /usr/share/jboss-as/standalone/log/server.log on the ovirt-engine host. > > > >WARN [org.ovirt.engine.core.vdsbroker.VdsManager] (QuartzScheduler_Worker-17) ResourceManager::refreshVdsRunTimeInfo::Failed to refresh VDS , vds = 783eb0ac-9a91-11e1-a8e4-000c29de7759 : xena003, error = DataIntegrityViolationException: CallableStatementCallback; SQL [{call insertvds_interface(?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)}]; ERROR: value too long for type character varying(20) > > Where: SQL statement "INSERT INTO vds_interface(addr, bond_name, bond_type, gateway, id, is_bond, bond_opts, mac_addr, name, network_name, speed, subnet, boot_protocol, type, VDS_ID, vlan_id, mtu, bridged) > > VALUES(v_addr, v_bond_name, v_bond_type, v_gateway, v_id, v_is_bond, v_bond_opts, v_mac_addr, v_name, v_network_name, v_speed, v_subnet, v_boot_protocol, v_type, v_vds_id, v_vlan_id, v_mtu, v_bridged)" > > > >More detailed log: > >http://pastebin.com/AHD3di5i > > > >VDSM: From git repository commit 8a14b63fbbafbdb9ee7f85a9b702bff310f4f668 > >oVirt-engine: From git repository comit b24dddf094e08afa6a2032a487b37476318a872d > > > >Any suggestions? > > in general, you would need to send a patch to upgrade the scheme to > a value longer than 20 characters for a logical network name. > 1. I think bridge name is linux is limited to 15 characters, so not > sure actually why 20 are allowed today. danken? No idea why it's 20.. IIRC vdsm silently ignore the trailing chars past the 15th. > 2. if changing the db scheme of the engine, also need to remember to > upgrade the history db as well. > 3. if different network implementation can support varying lengths, > need to add validations in engine ("CanDoAction") to check the > length per type of network implementation. From hdegoede at redhat.com Fri May 11 09:35:45 2012 From: hdegoede at redhat.com (Hans de Goede) Date: Fri, 11 May 2012 11:35:45 +0200 Subject: [Engine-devel] [libvirt]Supporting native USB in oVirt In-Reply-To: <4FABB0BA.9050000@redhat.com> References: <67f023e6-5853-4f81-858b-605f04283705@zmail02.collab.prod.int.phx2.redhat.com> <4FABB0BA.9050000@redhat.com> Message-ID: <4FACDD71.8050901@redhat.com> Hi, On 05/10/2012 02:12 PM, Hans de Goede wrote: > Hi, > > On 05/10/2012 01:39 PM, Oved Ourfalli wrote: >> Rephrasing my question a bit, to make it more clear. >> We are now working on adding the support for native USB devices on oVirt. >> >> This requires adding composite PCI devices to a VM (details below), requiring specific set of restrictions on the addresses of these devices, and the connections between them. >> Is it possible to add such a composite set of devices to a VM while using automatic address assignment, as we do today on the other PCI devices? > > To be clear, what the ovirt-engine people want to do (AFAIK), is add an EHCI controller > with UHCI companion controllers to a vm, which would normally be done in the xml file > like this: > > >
> > > >
> > > >
> > > >
> > > Without manually specifying the addresses, ie they want to be able to write > something like: > > > > > > > > > > > > > As indicated by danpb in a follow up mail fixing this so that the following: Will work should be doable, a bug has been filed for tracking this: https://bugzilla.redhat.com/show_bug.cgi?id=820869 Regards, Hans From ecohen at redhat.com Fri May 11 11:14:19 2012 From: ecohen at redhat.com (Einav Cohen) Date: Fri, 11 May 2012 07:14:19 -0400 (EDT) Subject: [Engine-devel] PosixFS: GUI mock-ups have been updated In-Reply-To: Message-ID: > ----- Original Message ----- > From: "Ayal Baron" > Sent: Friday, May 11, 2012 11:39:42 AM > > > ----- Original Message ----- > > > ----- Original Message ----- > > > From: "Ayal Baron" > > > Sent: Thursday, May 10, 2012 10:46:44 PM > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Einav Cohen" > > > > > To: "Andrew Cathrow" > > > > > Cc: engine-devel at ovirt.org, "Simon Grinberg" > > > > > , > > > > > "Saggi Mizrahi" , "Geert > > > > > Jansen" , "Ori Liel" , > > > > > "Yair > > > > > Zaslavsky" , "Ayal Baron" > > > > > , "Miki Kenneth" > > > > > Sent: Thursday, May 10, 2012 2:05:55 PM > > > > > Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been > > > > > updated > > > > > > > > > > > ... > > > > > > > > > > > > The important thing is that it's clear what it is - eg. the > > > > > > remote/target not the local mount point. That could be > > > > > > accomplished > > > > > > in the tool tip, etc. > > > > > > > > > > So if there will be a tool-tip (or similar) in the GUI > > > > > explaining > > > > > what this field is supposed to be, are you OK with keeping > > > > > the > > > > > term > > > > > "Path" (in both GUI and rest-api)? > > > > > > > > I am , does everyone else agree. > > > > > > either 'path' or 'device' > > > > - "Path" it is. > > - Instead of a tool-tip, I suggest to use an explanation caption > > below the text-box (similar to what we have for NFS storage domain > > - > > see attached). Agreed? > > i.e. "Path to device to mount / remote export" or something? Yes, that's a good answer to the question afterwards :) But what do you think about the general idea of using an explanation caption below the "Path" text-box (instead of a tool-tip that was suggested here earlier)? Also, do you think that the above should be the exact phrasing? The NFS one is: "Please use 'FQDN:/path' or 'IP:/path' Example 'server.example.com:/export/VMs'" so maybe a "Please use" should be incorporated in this case as well, maybe also an example, etc. What do you think? > > > > - What should be the exact phrasing of the explanation text? > > > > > "mount [-fnrsvw] [-t vfstype] [-o options] device dir" > > > > > > device is what is being mounted and in the case of NFS is > > > server:path > > > > > > There is a reason why we termed it PosixFS and not SharedFS and > > > that > > > users can specify local devices/FS's (and there is no reason to > > > limit it). > > > > > > Note that if user defines a local FS and adds 2 hosts to the > > > Posix > > > FS > > > DC then 1 host will be non-op > > > > > > Miki - this is not cluster level seeing as PosixFS is a DC type > > > (afaik) so no need for tooltips about that. > > > > > > In the future when we get rid of the single storage type in DC > > > limitation then we'll be able to define a local posixFS domain > > > and > > > a > > > shared one. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Andrew/Geert/Simon/Ayal/Miki/Saggi/others: Please feel > > > > > > > free > > > > > > > to > > > > > > > suggest a new term, or vote for one of the > > > > > > > previously-discussed > > > > > > > terms ("Remote Path" / "Path" / "Mount Spec" / "File > > > > > > > System > > > > > > > URI"). > > > > > > > If no decision will be made here, the term will remain > > > > > > > as-is, > > > > > > > i.e. > > > > > > > "Path". > > > > > > > > > > > > > ... > > > > > > > > > > > > > > > From gjansen at redhat.com Fri May 11 14:10:37 2012 From: gjansen at redhat.com (Geert Jansen) Date: Fri, 11 May 2012 16:10:37 +0200 Subject: [Engine-devel] PosixFS: GUI mock-ups have been updated In-Reply-To: <3d5e2952-8c98-42e2-bc28-1b142f6fa291@zmail13.collab.prod.int.phx2.redhat.com> References: <3d5e2952-8c98-42e2-bc28-1b142f6fa291@zmail13.collab.prod.int.phx2.redhat.com> Message-ID: <4FAD1DDD.7050903@redhat.com> On 05/10/2012 09:46 PM, Ayal Baron wrote: > device is what is being mounted and in the case of NFS is server:path > > There is a reason why we termed it PosixFS and not SharedFS and that users can specify local devices/FS's (and there is no reason to limit it). > > Note that if user defines a local FS and adds 2 hosts to the Posix FS DC then 1 host will be non-op Why? This makes some very interesting use cases a lot more difficult to set up. We should allow multiple hosts in a PosixFS data center, and it should be the user's responsibility that if he adds multiple hosts, that each of those see the same data. Regards, Geert From acathrow at redhat.com Fri May 11 14:15:51 2012 From: acathrow at redhat.com (Andrew Cathrow) Date: Fri, 11 May 2012 10:15:51 -0400 (EDT) Subject: [Engine-devel] PosixFS: GUI mock-ups have been updated In-Reply-To: <4FAD1DDD.7050903@redhat.com> Message-ID: <30d35804-3373-4f25-8e31-8642a03b67ab@zmail07.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Geert Jansen" > To: "Ayal Baron" > Cc: "Andrew Cathrow" , engine-devel at ovirt.org, "Simon Grinberg" , "Saggi > Mizrahi" , "Ori Liel" , "Yair Zaslavsky" , "Miki > Kenneth" , "Einav Cohen" > Sent: Friday, May 11, 2012 10:10:37 AM > Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated > > > On 05/10/2012 09:46 PM, Ayal Baron wrote: > > > device is what is being mounted and in the case of NFS is > > server:path > > > > There is a reason why we termed it PosixFS and not SharedFS and > > that users can specify local devices/FS's (and there is no reason > > to limit it). > > > > Note that if user defines a local FS and adds 2 hosts to the Posix > > FS DC then 1 host will be non-op > > Why? This makes some very interesting use cases a lot more difficult > to > set up. We should allow multiple hosts in a PosixFS data center, and > it > should be the user's responsibility that if he adds multiple hosts, > that > each of those see the same data. I *think* we're saying the same thing. If you have multiple hosts in a datacenter with PosixFS then it's your responsibility to make sure that they can all see the same storage > > Regards, > Geert > From ecohen at redhat.com Fri May 11 14:25:27 2012 From: ecohen at redhat.com (Einav Cohen) Date: Fri, 11 May 2012 10:25:27 -0400 (EDT) Subject: [Engine-devel] PosixFS: GUI mock-ups have been updated In-Reply-To: <30d35804-3373-4f25-8e31-8642a03b67ab@zmail07.collab.prod.int.phx2.redhat.com> Message-ID: <5879ddb9-6a76-48ed-99bd-b2c9c868d58b@zmail04.collab.prod.int.phx2.redhat.com> > ----- Original Message ----- > From: "Andrew Cathrow" > Sent: Friday, May 11, 2012 5:15:51 PM > > ----- Original Message ----- > > From: "Geert Jansen" > > To: "Ayal Baron" > > Cc: "Andrew Cathrow" , engine-devel at ovirt.org, > > "Simon Grinberg" , "Saggi > > Mizrahi" , "Ori Liel" , > > "Yair Zaslavsky" , "Miki > > Kenneth" , "Einav Cohen" > > Sent: Friday, May 11, 2012 10:10:37 AM > > Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated > > > > > > On 05/10/2012 09:46 PM, Ayal Baron wrote: > > > > > device is what is being mounted and in the case of NFS is > > > server:path > > > > > > There is a reason why we termed it PosixFS and not SharedFS and > > > that users can specify local devices/FS's (and there is no reason > > > to limit it). > > > > > > Note that if user defines a local FS and adds 2 hosts to the > > > Posix > > > FS DC then 1 host will be non-op > > > > Why? This makes some very interesting use cases a lot more > > difficult > > to > > set up. We should allow multiple hosts in a PosixFS data center, > > and > > it > > should be the user's responsibility that if he adds multiple hosts, > > that > > each of those see the same data. > > > I *think* we're saying the same thing. > If you have multiple hosts in a datacenter with PosixFS then it's > your responsibility to make sure that they can all see the same > storage +1. I believe that Ayal didn't mean that we should limit the number of Hosts in a PosixFS DC to 1; all he said is that in case the user has defined more than 1 Host in a PosixFS DC and the PosixFS storage domain in it happens to be a local one (i.e. local on one of the Hosts in the DC), all other Hosts will become Non Operational (simply because they won't be able to reach that storage domain). > > > > > > Regards, > > Geert > > > From abaron at redhat.com Fri May 11 19:56:49 2012 From: abaron at redhat.com (Ayal Baron) Date: Fri, 11 May 2012 15:56:49 -0400 (EDT) Subject: [Engine-devel] PosixFS: GUI mock-ups have been updated In-Reply-To: <5879ddb9-6a76-48ed-99bd-b2c9c868d58b@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: ----- Original Message ----- > > ----- Original Message ----- > > From: "Andrew Cathrow" > > Sent: Friday, May 11, 2012 5:15:51 PM > > > > ----- Original Message ----- > > > From: "Geert Jansen" > > > To: "Ayal Baron" > > > Cc: "Andrew Cathrow" , > > > engine-devel at ovirt.org, > > > "Simon Grinberg" , "Saggi > > > Mizrahi" , "Ori Liel" , > > > "Yair Zaslavsky" , "Miki > > > Kenneth" , "Einav Cohen" > > > Sent: Friday, May 11, 2012 10:10:37 AM > > > Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been > > > updated > > > > > > > > > On 05/10/2012 09:46 PM, Ayal Baron wrote: > > > > > > > device is what is being mounted and in the case of NFS is > > > > server:path > > > > > > > > There is a reason why we termed it PosixFS and not SharedFS and > > > > that users can specify local devices/FS's (and there is no > > > > reason > > > > to limit it). > > > > > > > > Note that if user defines a local FS and adds 2 hosts to the > > > > Posix > > > > FS DC then 1 host will be non-op > > > > > > Why? This makes some very interesting use cases a lot more > > > difficult > > > to > > > set up. We should allow multiple hosts in a PosixFS data center, > > > and > > > it > > > should be the user's responsibility that if he adds multiple > > > hosts, > > > that > > > each of those see the same data. > > > > > > I *think* we're saying the same thing. > > If you have multiple hosts in a datacenter with PosixFS then it's > > your responsibility to make sure that they can all see the same > > storage > > +1. > I believe that Ayal didn't mean that we should limit the number of > Hosts in a PosixFS DC to 1; all he said is that in case the user has > defined more than 1 Host in a PosixFS DC and the PosixFS storage > domain in it happens to be a local one (i.e. local on one of the > Hosts in the DC), all other Hosts will become Non Operational > (simply because they won't be able to reach that storage domain). Correct. It was a disclaimer that we do not prevent user from doing stupid things. > > > > > > > > > > > Regards, > > > Geert > > > > > > From abaron at redhat.com Fri May 11 20:03:04 2012 From: abaron at redhat.com (Ayal Baron) Date: Fri, 11 May 2012 16:03:04 -0400 (EDT) Subject: [Engine-devel] PosixFS: GUI mock-ups have been updated In-Reply-To: Message-ID: <033767e7-0ddc-40d2-89a1-f08a2ec63778@zmail13.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > > ----- Original Message ----- > > From: "Ayal Baron" > > Sent: Friday, May 11, 2012 11:39:42 AM > > > > > > ----- Original Message ----- > > > > ----- Original Message ----- > > > > From: "Ayal Baron" > > > > Sent: Thursday, May 10, 2012 10:46:44 PM > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Einav Cohen" > > > > > > To: "Andrew Cathrow" > > > > > > Cc: engine-devel at ovirt.org, "Simon Grinberg" > > > > > > , > > > > > > "Saggi Mizrahi" , "Geert > > > > > > Jansen" , "Ori Liel" > > > > > > , > > > > > > "Yair > > > > > > Zaslavsky" , "Ayal Baron" > > > > > > , "Miki Kenneth" > > > > > > Sent: Thursday, May 10, 2012 2:05:55 PM > > > > > > Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been > > > > > > updated > > > > > > > > > > > > > ... > > > > > > > > > > > > > > The important thing is that it's clear what it is - eg. > > > > > > > the > > > > > > > remote/target not the local mount point. That could be > > > > > > > accomplished > > > > > > > in the tool tip, etc. > > > > > > > > > > > > So if there will be a tool-tip (or similar) in the GUI > > > > > > explaining > > > > > > what this field is supposed to be, are you OK with keeping > > > > > > the > > > > > > term > > > > > > "Path" (in both GUI and rest-api)? > > > > > > > > > > I am , does everyone else agree. > > > > > > > > either 'path' or 'device' > > > > > > - "Path" it is. > > > - Instead of a tool-tip, I suggest to use an explanation caption > > > below the text-box (similar to what we have for NFS storage > > > domain > > > - > > > see attached). Agreed? > > > > i.e. "Path to device to mount / remote export" or something? > > Yes, that's a good answer to the question afterwards :) > But what do you think about the general idea of using an explanation > caption below the "Path" text-box (instead of a tool-tip that was > suggested here earlier)? > > Also, do you think that the above should be the exact phrasing? The > NFS one is: > "Please use 'FQDN:/path' or 'IP:/path' Example > 'server.example.com:/export/VMs'" > so maybe a "Please use" should be incorporated in this case as well, > maybe also an example, etc. > What do you think? I replied after viewing the other message and disliking it (personal opinion). I prefer a static explanation (what the field is) rather than an action request. So in the NFS example I would've phrased it as "Remote path to NFS export, takes either the form: FQDN:/path or IP:/path, e.g. server.example.com:/export/VMs". But in any event it is better to have consistency (so both messages should probably be phrased similarly). > > > > > > > > - What should be the exact phrasing of the explanation text? > > > > > > > "mount [-fnrsvw] [-t vfstype] [-o options] device dir" > > > > > > > > device is what is being mounted and in the case of NFS is > > > > server:path > > > > > > > > There is a reason why we termed it PosixFS and not SharedFS and > > > > that > > > > users can specify local devices/FS's (and there is no reason to > > > > limit it). > > > > > > > > Note that if user defines a local FS and adds 2 hosts to the > > > > Posix > > > > FS > > > > DC then 1 host will be non-op > > > > > > > > Miki - this is not cluster level seeing as PosixFS is a DC type > > > > (afaik) so no need for tooltips about that. > > > > > > > > In the future when we get rid of the single storage type in DC > > > > limitation then we'll be able to define a local posixFS domain > > > > and > > > > a > > > > shared one. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Andrew/Geert/Simon/Ayal/Miki/Saggi/others: Please feel > > > > > > > > free > > > > > > > > to > > > > > > > > suggest a new term, or vote for one of the > > > > > > > > previously-discussed > > > > > > > > terms ("Remote Path" / "Path" / "Mount Spec" / "File > > > > > > > > System > > > > > > > > URI"). > > > > > > > > If no decision will be made here, the term will remain > > > > > > > > as-is, > > > > > > > > i.e. > > > > > > > > "Path". > > > > > > > > > > > > > > > ... > > > > > > > > > > > > > > > > > > > > > From ecohen at redhat.com Fri May 11 20:28:09 2012 From: ecohen at redhat.com (Einav Cohen) Date: Fri, 11 May 2012 16:28:09 -0400 (EDT) Subject: [Engine-devel] PosixFS: GUI mock-ups have been updated In-Reply-To: <033767e7-0ddc-40d2-89a1-f08a2ec63778@zmail13.collab.prod.int.phx2.redhat.com> Message-ID: <54a2bd83-73bd-471e-968a-d351c1f41464@zmail04.collab.prod.int.phx2.redhat.com> > ----- Original Message ----- > From: "Ayal Baron" > Sent: Friday, May 11, 2012 11:03:04 PM > > > ----- Original Message ----- > > > ----- Original Message ----- > > > From: "Ayal Baron" > > > Sent: Friday, May 11, 2012 11:39:42 AM > > > > > > > > > ----- Original Message ----- > > > > > ----- Original Message ----- > > > > > From: "Ayal Baron" > > > > > Sent: Thursday, May 10, 2012 10:46:44 PM > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Einav Cohen" > > > > > > > To: "Andrew Cathrow" > > > > > > > Cc: engine-devel at ovirt.org, "Simon Grinberg" > > > > > > > , > > > > > > > "Saggi Mizrahi" , "Geert > > > > > > > Jansen" , "Ori Liel" > > > > > > > , > > > > > > > "Yair > > > > > > > Zaslavsky" , "Ayal Baron" > > > > > > > , "Miki Kenneth" > > > > > > > Sent: Thursday, May 10, 2012 2:05:55 PM > > > > > > > Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have > > > > > > > been > > > > > > > updated > > > > > > > > > > > > > > > ... > > > > > > > > > > > > > > > > The important thing is that it's clear what it is - eg. > > > > > > > > the > > > > > > > > remote/target not the local mount point. That could be > > > > > > > > accomplished > > > > > > > > in the tool tip, etc. > > > > > > > > > > > > > > So if there will be a tool-tip (or similar) in the GUI > > > > > > > explaining > > > > > > > what this field is supposed to be, are you OK with > > > > > > > keeping > > > > > > > the > > > > > > > term > > > > > > > "Path" (in both GUI and rest-api)? > > > > > > > > > > > > I am , does everyone else agree. > > > > > > > > > > either 'path' or 'device' > > > > > > > > - "Path" it is. > > > > - Instead of a tool-tip, I suggest to use an explanation > > > > caption > > > > below the text-box (similar to what we have for NFS storage > > > > domain > > > > - > > > > see attached). Agreed? > > > > > > i.e. "Path to device to mount / remote export" or something? > > > > Yes, that's a good answer to the question afterwards :) > > But what do you think about the general idea of using an > > explanation > > caption below the "Path" text-box (instead of a tool-tip that was > > suggested here earlier)? > > > > Also, do you think that the above should be the exact phrasing? The > > NFS one is: > > "Please use 'FQDN:/path' or 'IP:/path' Example > > 'server.example.com:/export/VMs'" > > so maybe a "Please use" should be incorporated in this case as > > well, > > maybe also an example, etc. > > What do you think? > > I replied after viewing the other message and disliking it (personal > opinion). I prefer a static explanation (what the field is) rather > than an action request. > So in the NFS example I would've phrased it as "Remote path to NFS > export, takes either the form: FQDN:/path or IP:/path, e.g. > server.example.com:/export/VMs". > But in any event it is better to have consistency (so both messages > should probably be phrased similarly). There is no problem changing the phrasing for NFS. So for NFS, the caption will be: "Remote path to NFS export, takes either the form: FQDN:/path or IP:/path, e.g. server.example.com:/export/VMs". And for PosixFS, the caption will be: "Path to device to mount / remote export". (no 'takes the form' or example provided) Agreed? > > > > > > > > > > > > > - What should be the exact phrasing of the explanation text? > > > > > > > > > "mount [-fnrsvw] [-t vfstype] [-o options] device dir" > > > > > > > > > > device is what is being mounted and in the case of NFS is > > > > > server:path > > > > > > > > > > There is a reason why we termed it PosixFS and not SharedFS > > > > > and > > > > > that > > > > > users can specify local devices/FS's (and there is no reason > > > > > to > > > > > limit it). > > > > > > > > > > Note that if user defines a local FS and adds 2 hosts to the > > > > > Posix > > > > > FS > > > > > DC then 1 host will be non-op > > > > > > > > > > Miki - this is not cluster level seeing as PosixFS is a DC > > > > > type > > > > > (afaik) so no need for tooltips about that. > > > > > > > > > > In the future when we get rid of the single storage type in > > > > > DC > > > > > limitation then we'll be able to define a local posixFS > > > > > domain > > > > > and > > > > > a > > > > > shared one. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Andrew/Geert/Simon/Ayal/Miki/Saggi/others: Please > > > > > > > > > feel > > > > > > > > > free > > > > > > > > > to > > > > > > > > > suggest a new term, or vote for one of the > > > > > > > > > previously-discussed > > > > > > > > > terms ("Remote Path" / "Path" / "Mount Spec" / "File > > > > > > > > > System > > > > > > > > > URI"). > > > > > > > > > If no decision will be made here, the term will > > > > > > > > > remain > > > > > > > > > as-is, > > > > > > > > > i.e. > > > > > > > > > "Path". > > > > > > > > > > > > > > > > > ... > > > > > > > > > > > > > > > > > > > > > > > > > > > > From lpeer at redhat.com Sat May 12 18:47:56 2012 From: lpeer at redhat.com (Livnat Peer) Date: Sat, 12 May 2012 21:47:56 +0300 Subject: [Engine-devel] value too long for type character varying(20) in function "insertvds_interface" In-Reply-To: <20120511084042.GF22381@redhat.com> References: <4488206DC085244C886DBC9E7038B689251852C6@mtrdag02.mtl.com> <4FACC7FE.4030700@redhat.com> <20120511084042.GF22381@redhat.com> Message-ID: <4FAEB05C.4080807@redhat.com> On 11/05/12 11:40, Dan Kenigsberg wrote: > On Fri, May 11, 2012 at 11:04:14AM +0300, Itamar Heim wrote: >> On 05/11/2012 03:52 AM, Itzik Brown wrote: >>> Hi, >>> >>> When running VDSM on host with Infiniband HCAs I get the following errors in /usr/share/jboss-as/standalone/log/server.log on the ovirt-engine host. >>> >>> WARN [org.ovirt.engine.core.vdsbroker.VdsManager] (QuartzScheduler_Worker-17) ResourceManager::refreshVdsRunTimeInfo::Failed to refresh VDS , vds = 783eb0ac-9a91-11e1-a8e4-000c29de7759 : xena003, error = DataIntegrityViolationException: CallableStatementCallback; SQL [{call insertvds_interface(?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)}]; ERROR: value too long for type character varying(20) >>> Where: SQL statement "INSERT INTO vds_interface(addr, bond_name, bond_type, gateway, id, is_bond, bond_opts, mac_addr, name, network_name, speed, subnet, boot_protocol, type, VDS_ID, vlan_id, mtu, bridged) >>> VALUES(v_addr, v_bond_name, v_bond_type, v_gateway, v_id, v_is_bond, v_bond_opts, v_mac_addr, v_name, v_network_name, v_speed, v_subnet, v_boot_protocol, v_type, v_vds_id, v_vlan_id, v_mtu, v_bridged)" >>> >>> More detailed log: >>> http://pastebin.com/AHD3di5i >>> >>> VDSM: From git repository commit 8a14b63fbbafbdb9ee7f85a9b702bff310f4f668 >>> oVirt-engine: From git repository comit b24dddf094e08afa6a2032a487b37476318a872d >>> >>> Any suggestions? >> >> in general, you would need to send a patch to upgrade the scheme to >> a value longer than 20 characters for a logical network name. >> 1. I think bridge name is linux is limited to 15 characters, so not >> sure actually why 20 are allowed today. danken? > > No idea why it's 20.. IIRC vdsm silently ignore the trailing chars past > the 15th. > I opened a BZ on this - https://bugzilla.redhat.com/show_bug.cgi?id=821172 "VM network name should be limited to 15 chars " Livnat >> 2. if changing the db scheme of the engine, also need to remember to >> upgrade the history db as well. >> 3. if different network implementation can support varying lengths, >> need to add validations in engine ("CanDoAction") to check the >> length per type of network implementation. From yzaslavs at redhat.com Sun May 13 07:05:23 2012 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Sun, 13 May 2012 10:05:23 +0300 Subject: [Engine-devel] PosixFS: GUI mock-ups have been updated In-Reply-To: <54a2bd83-73bd-471e-968a-d351c1f41464@zmail04.collab.prod.int.phx2.redhat.com> References: <54a2bd83-73bd-471e-968a-d351c1f41464@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4FAF5D33.7040308@redhat.com> On 05/11/2012 11:28 PM, Einav Cohen wrote: >> ----- Original Message ----- >> From: "Ayal Baron" >> Sent: Friday, May 11, 2012 11:03:04 PM >> >> >> ----- Original Message ----- >>>> ----- Original Message ----- >>>> From: "Ayal Baron" >>>> Sent: Friday, May 11, 2012 11:39:42 AM >>>> >>>> >>>> ----- Original Message ----- >>>>>> ----- Original Message ----- >>>>>> From: "Ayal Baron" >>>>>> Sent: Thursday, May 10, 2012 10:46:44 PM >>>>>> >>>>>>> >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>>> From: "Einav Cohen" >>>>>>>> To: "Andrew Cathrow" >>>>>>>> Cc: engine-devel at ovirt.org, "Simon Grinberg" >>>>>>>> , >>>>>>>> "Saggi Mizrahi" , "Geert >>>>>>>> Jansen" , "Ori Liel" >>>>>>>> , >>>>>>>> "Yair >>>>>>>> Zaslavsky" , "Ayal Baron" >>>>>>>> , "Miki Kenneth" >>>>>>>> Sent: Thursday, May 10, 2012 2:05:55 PM >>>>>>>> Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have >>>>>>>> been >>>>>>>> updated >>>>>>>> >>>>>>>>> ... >>>>>>>>> >>>>>>>>> The important thing is that it's clear what it is - eg. >>>>>>>>> the >>>>>>>>> remote/target not the local mount point. That could be >>>>>>>>> accomplished >>>>>>>>> in the tool tip, etc. >>>>>>>> >>>>>>>> So if there will be a tool-tip (or similar) in the GUI >>>>>>>> explaining >>>>>>>> what this field is supposed to be, are you OK with >>>>>>>> keeping >>>>>>>> the >>>>>>>> term >>>>>>>> "Path" (in both GUI and rest-api)? >>>>>>> >>>>>>> I am , does everyone else agree. >>>>>> >>>>>> either 'path' or 'device' >>>>> >>>>> - "Path" it is. +1 on "path" and this was my original implementation by the way. >>>>> - Instead of a tool-tip, I suggest to use an explanation >>>>> caption >>>>> below the text-box (similar to what we have for NFS storage >>>>> domain >>>>> - >>>>> see attached). Agreed? >>>> >>>> i.e. "Path to device to mount / remote export" or something? >>> >>> Yes, that's a good answer to the question afterwards :) >>> But what do you think about the general idea of using an >>> explanation >>> caption below the "Path" text-box (instead of a tool-tip that was >>> suggested here earlier)? >>> >>> Also, do you think that the above should be the exact phrasing? The >>> NFS one is: >>> "Please use 'FQDN:/path' or 'IP:/path' Example >>> 'server.example.com:/export/VMs'" >>> so maybe a "Please use" should be incorporated in this case as >>> well, >>> maybe also an example, etc. >>> What do you think? >> >> I replied after viewing the other message and disliking it (personal >> opinion). I prefer a static explanation (what the field is) rather >> than an action request. >> So in the NFS example I would've phrased it as "Remote path to NFS >> export, takes either the form: FQDN:/path or IP:/path, e.g. >> server.example.com:/export/VMs". >> But in any event it is better to have consistency (so both messages >> should probably be phrased similarly). > > There is no problem changing the phrasing for NFS. > > So for NFS, the caption will be: > "Remote path to NFS export, takes either the form: FQDN:/path or IP:/path, e.g. server.example.com:/export/VMs". > > And for PosixFS, the caption will be: > "Path to device to mount / remote export". > (no 'takes the form' or example provided) > > Agreed? > >> >>> >>>> >>>> >>>>> - What should be the exact phrasing of the explanation text? >>>>> >>>>>> "mount [-fnrsvw] [-t vfstype] [-o options] device dir" >>>>>> >>>>>> device is what is being mounted and in the case of NFS is >>>>>> server:path >>>>>> >>>>>> There is a reason why we termed it PosixFS and not SharedFS >>>>>> and >>>>>> that >>>>>> users can specify local devices/FS's (and there is no reason >>>>>> to >>>>>> limit it). >>>>>> >>>>>> Note that if user defines a local FS and adds 2 hosts to the >>>>>> Posix >>>>>> FS >>>>>> DC then 1 host will be non-op >>>>>> >>>>>> Miki - this is not cluster level seeing as PosixFS is a DC >>>>>> type >>>>>> (afaik) so no need for tooltips about that. >>>>>> >>>>>> In the future when we get rid of the single storage type in >>>>>> DC >>>>>> limitation then we'll be able to define a local posixFS >>>>>> domain >>>>>> and >>>>>> a >>>>>> shared one. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>>> Andrew/Geert/Simon/Ayal/Miki/Saggi/others: Please >>>>>>>>>> feel >>>>>>>>>> free >>>>>>>>>> to >>>>>>>>>> suggest a new term, or vote for one of the >>>>>>>>>> previously-discussed >>>>>>>>>> terms ("Remote Path" / "Path" / "Mount Spec" / "File >>>>>>>>>> System >>>>>>>>>> URI"). >>>>>>>>>> If no decision will be made here, the term will >>>>>>>>>> remain >>>>>>>>>> as-is, >>>>>>>>>> i.e. >>>>>>>>>> "Path". >>>>>>>>>> >>>>>>>>> ... >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> From ecohen at redhat.com Sun May 13 08:54:04 2012 From: ecohen at redhat.com (Einav Cohen) Date: Sun, 13 May 2012 04:54:04 -0400 (EDT) Subject: [Engine-devel] PosixFS: GUI mock-ups have been updated In-Reply-To: <4FAF5D33.7040308@redhat.com> Message-ID: <7ed17043-96e5-4151-a32c-6ddb8e68d990@zmail04.collab.prod.int.phx2.redhat.com> [top posting] GUI Mockup has been updated according to this thread: http://www.ovirt.org/wiki/Features/PosixFSConnection#Changes_in_GUI Further comments are welcome. ---- Thanks, Einav ----- Original Message ----- > From: "Yair Zaslavsky" > To: "Einav Cohen" > Cc: "Ayal Baron" , engine-devel at ovirt.org, "Simon Grinberg" , "Saggi Mizrahi" > , "Geert Jansen" , "Ori Liel" , "Miki Kenneth" > , "Andrew Cathrow" > Sent: Sunday, May 13, 2012 10:05:23 AM > Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated > > On 05/11/2012 11:28 PM, Einav Cohen wrote: > >> ----- Original Message ----- > >> From: "Ayal Baron" > >> Sent: Friday, May 11, 2012 11:03:04 PM > >> > >> > >> ----- Original Message ----- > >>>> ----- Original Message ----- > >>>> From: "Ayal Baron" > >>>> Sent: Friday, May 11, 2012 11:39:42 AM > >>>> > >>>> > >>>> ----- Original Message ----- > >>>>>> ----- Original Message ----- > >>>>>> From: "Ayal Baron" > >>>>>> Sent: Thursday, May 10, 2012 10:46:44 PM > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> ----- Original Message ----- > >>>>>>>> From: "Einav Cohen" > >>>>>>>> To: "Andrew Cathrow" > >>>>>>>> Cc: engine-devel at ovirt.org, "Simon Grinberg" > >>>>>>>> , > >>>>>>>> "Saggi Mizrahi" , "Geert > >>>>>>>> Jansen" , "Ori Liel" > >>>>>>>> , > >>>>>>>> "Yair > >>>>>>>> Zaslavsky" , "Ayal Baron" > >>>>>>>> , "Miki Kenneth" > >>>>>>>> Sent: Thursday, May 10, 2012 2:05:55 PM > >>>>>>>> Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have > >>>>>>>> been > >>>>>>>> updated > >>>>>>>> > >>>>>>>>> ... > >>>>>>>>> > >>>>>>>>> The important thing is that it's clear what it is - eg. > >>>>>>>>> the > >>>>>>>>> remote/target not the local mount point. That could be > >>>>>>>>> accomplished > >>>>>>>>> in the tool tip, etc. > >>>>>>>> > >>>>>>>> So if there will be a tool-tip (or similar) in the GUI > >>>>>>>> explaining > >>>>>>>> what this field is supposed to be, are you OK with > >>>>>>>> keeping > >>>>>>>> the > >>>>>>>> term > >>>>>>>> "Path" (in both GUI and rest-api)? > >>>>>>> > >>>>>>> I am , does everyone else agree. > >>>>>> > >>>>>> either 'path' or 'device' > >>>>> > >>>>> - "Path" it is. > +1 on "path" and this was my original implementation by the way. > > > >>>>> - Instead of a tool-tip, I suggest to use an explanation > >>>>> caption > >>>>> below the text-box (similar to what we have for NFS storage > >>>>> domain > >>>>> - > >>>>> see attached). Agreed? > >>>> > >>>> i.e. "Path to device to mount / remote export" or something? > >>> > >>> Yes, that's a good answer to the question afterwards :) > >>> But what do you think about the general idea of using an > >>> explanation > >>> caption below the "Path" text-box (instead of a tool-tip that was > >>> suggested here earlier)? > >>> > >>> Also, do you think that the above should be the exact phrasing? > >>> The > >>> NFS one is: > >>> "Please use 'FQDN:/path' or 'IP:/path' Example > >>> 'server.example.com:/export/VMs'" > >>> so maybe a "Please use" should be incorporated in this case as > >>> well, > >>> maybe also an example, etc. > >>> What do you think? > >> > >> I replied after viewing the other message and disliking it > >> (personal > >> opinion). I prefer a static explanation (what the field is) > >> rather > >> than an action request. > >> So in the NFS example I would've phrased it as "Remote path to NFS > >> export, takes either the form: FQDN:/path or IP:/path, e.g. > >> server.example.com:/export/VMs". > >> But in any event it is better to have consistency (so both > >> messages > >> should probably be phrased similarly). > > > > There is no problem changing the phrasing for NFS. > > > > So for NFS, the caption will be: > > "Remote path to NFS export, takes either the form: FQDN:/path or > > IP:/path, e.g. server.example.com:/export/VMs". > > > > And for PosixFS, the caption will be: > > "Path to device to mount / remote export". > > (no 'takes the form' or example provided) > > > > Agreed? > > > >> > >>> > >>>> > >>>> > >>>>> - What should be the exact phrasing of the explanation text? > >>>>> > >>>>>> "mount [-fnrsvw] [-t vfstype] [-o options] device dir" > >>>>>> > >>>>>> device is what is being mounted and in the case of NFS is > >>>>>> server:path > >>>>>> > >>>>>> There is a reason why we termed it PosixFS and not SharedFS > >>>>>> and > >>>>>> that > >>>>>> users can specify local devices/FS's (and there is no reason > >>>>>> to > >>>>>> limit it). > >>>>>> > >>>>>> Note that if user defines a local FS and adds 2 hosts to the > >>>>>> Posix > >>>>>> FS > >>>>>> DC then 1 host will be non-op > >>>>>> > >>>>>> Miki - this is not cluster level seeing as PosixFS is a DC > >>>>>> type > >>>>>> (afaik) so no need for tooltips about that. > >>>>>> > >>>>>> In the future when we get rid of the single storage type in > >>>>>> DC > >>>>>> limitation then we'll be able to define a local posixFS > >>>>>> domain > >>>>>> and > >>>>>> a > >>>>>> shared one. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>>> > >>>>>>>>> > >>>>>>>>>> Andrew/Geert/Simon/Ayal/Miki/Saggi/others: Please > >>>>>>>>>> feel > >>>>>>>>>> free > >>>>>>>>>> to > >>>>>>>>>> suggest a new term, or vote for one of the > >>>>>>>>>> previously-discussed > >>>>>>>>>> terms ("Remote Path" / "Path" / "Mount Spec" / "File > >>>>>>>>>> System > >>>>>>>>>> URI"). > >>>>>>>>>> If no decision will be made here, the term will > >>>>>>>>>> remain > >>>>>>>>>> as-is, > >>>>>>>>>> i.e. > >>>>>>>>>> "Path". > >>>>>>>>>> > >>>>>>>>> ... > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > From ykaul at redhat.com Sun May 13 11:04:59 2012 From: ykaul at redhat.com (Yaniv Kaul) Date: Sun, 13 May 2012 14:04:59 +0300 Subject: [Engine-devel] PosixFS: GUI mock-ups have been updated In-Reply-To: <7ed17043-96e5-4151-a32c-6ddb8e68d990@zmail04.collab.prod.int.phx2.redhat.com> References: <7ed17043-96e5-4151-a32c-6ddb8e68d990@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4FAF955B.3090503@redhat.com> On 05/13/2012 11:54 AM, Einav Cohen wrote: > [top posting] > > GUI Mockup has been updated according to this thread: > http://www.ovirt.org/wiki/Features/PosixFSConnection#Changes_in_GUI > > Further comments are welcome. - POSIX, not Posix. - 'POSIX compliant FS', not 'PosixFS' - I'd be happy if we could validate whatever we pass to the mount command against command injection[1] . Y. [1] https://www.owasp.org/index.php/Command_Injection > > ---- > Thanks, > Einav > > ----- Original Message ----- >> From: "Yair Zaslavsky" >> To: "Einav Cohen" >> Cc: "Ayal Baron", engine-devel at ovirt.org, "Simon Grinberg", "Saggi Mizrahi" >> , "Geert Jansen", "Ori Liel", "Miki Kenneth" >> , "Andrew Cathrow" >> Sent: Sunday, May 13, 2012 10:05:23 AM >> Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated >> >> On 05/11/2012 11:28 PM, Einav Cohen wrote: >>>> ----- Original Message ----- >>>> From: "Ayal Baron" >>>> Sent: Friday, May 11, 2012 11:03:04 PM >>>> >>>> >>>> ----- Original Message ----- >>>>>> ----- Original Message ----- >>>>>> From: "Ayal Baron" >>>>>> Sent: Friday, May 11, 2012 11:39:42 AM >>>>>> >>>>>> >>>>>> ----- Original Message ----- >>>>>>>> ----- Original Message ----- >>>>>>>> From: "Ayal Baron" >>>>>>>> Sent: Thursday, May 10, 2012 10:46:44 PM >>>>>>>> >>>>>>>>> >>>>>>>>> ----- Original Message ----- >>>>>>>>>> From: "Einav Cohen" >>>>>>>>>> To: "Andrew Cathrow" >>>>>>>>>> Cc: engine-devel at ovirt.org, "Simon Grinberg" >>>>>>>>>> , >>>>>>>>>> "Saggi Mizrahi", "Geert >>>>>>>>>> Jansen", "Ori Liel" >>>>>>>>>> , >>>>>>>>>> "Yair >>>>>>>>>> Zaslavsky", "Ayal Baron" >>>>>>>>>> , "Miki Kenneth" >>>>>>>>>> Sent: Thursday, May 10, 2012 2:05:55 PM >>>>>>>>>> Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have >>>>>>>>>> been >>>>>>>>>> updated >>>>>>>>>> >>>>>>>>>>> ... >>>>>>>>>>> >>>>>>>>>>> The important thing is that it's clear what it is - eg. >>>>>>>>>>> the >>>>>>>>>>> remote/target not the local mount point. That could be >>>>>>>>>>> accomplished >>>>>>>>>>> in the tool tip, etc. >>>>>>>>>> So if there will be a tool-tip (or similar) in the GUI >>>>>>>>>> explaining >>>>>>>>>> what this field is supposed to be, are you OK with >>>>>>>>>> keeping >>>>>>>>>> the >>>>>>>>>> term >>>>>>>>>> "Path" (in both GUI and rest-api)? >>>>>>>>> I am , does everyone else agree. >>>>>>>> either 'path' or 'device' >>>>>>> - "Path" it is. >> +1 on "path" and this was my original implementation by the way. >> >> >>>>>>> - Instead of a tool-tip, I suggest to use an explanation >>>>>>> caption >>>>>>> below the text-box (similar to what we have for NFS storage >>>>>>> domain >>>>>>> - >>>>>>> see attached). Agreed? >>>>>> i.e. "Path to device to mount / remote export" or something? >>>>> Yes, that's a good answer to the question afterwards :) >>>>> But what do you think about the general idea of using an >>>>> explanation >>>>> caption below the "Path" text-box (instead of a tool-tip that was >>>>> suggested here earlier)? >>>>> >>>>> Also, do you think that the above should be the exact phrasing? >>>>> The >>>>> NFS one is: >>>>> "Please use 'FQDN:/path' or 'IP:/path' Example >>>>> 'server.example.com:/export/VMs'" >>>>> so maybe a "Please use" should be incorporated in this case as >>>>> well, >>>>> maybe also an example, etc. >>>>> What do you think? >>>> I replied after viewing the other message and disliking it >>>> (personal >>>> opinion). I prefer a static explanation (what the field is) >>>> rather >>>> than an action request. >>>> So in the NFS example I would've phrased it as "Remote path to NFS >>>> export, takes either the form: FQDN:/path or IP:/path, e.g. >>>> server.example.com:/export/VMs". >>>> But in any event it is better to have consistency (so both >>>> messages >>>> should probably be phrased similarly). >>> There is no problem changing the phrasing for NFS. >>> >>> So for NFS, the caption will be: >>> "Remote path to NFS export, takes either the form: FQDN:/path or >>> IP:/path, e.g. server.example.com:/export/VMs". >>> >>> And for PosixFS, the caption will be: >>> "Path to device to mount / remote export". >>> (no 'takes the form' or example provided) >>> >>> Agreed? >>> >>>>>> >>>>>>> - What should be the exact phrasing of the explanation text? >>>>>>> >>>>>>>> "mount [-fnrsvw] [-t vfstype] [-o options] device dir" >>>>>>>> >>>>>>>> device is what is being mounted and in the case of NFS is >>>>>>>> server:path >>>>>>>> >>>>>>>> There is a reason why we termed it PosixFS and not SharedFS >>>>>>>> and >>>>>>>> that >>>>>>>> users can specify local devices/FS's (and there is no reason >>>>>>>> to >>>>>>>> limit it). >>>>>>>> >>>>>>>> Note that if user defines a local FS and adds 2 hosts to the >>>>>>>> Posix >>>>>>>> FS >>>>>>>> DC then 1 host will be non-op >>>>>>>> >>>>>>>> Miki - this is not cluster level seeing as PosixFS is a DC >>>>>>>> type >>>>>>>> (afaik) so no need for tooltips about that. >>>>>>>> >>>>>>>> In the future when we get rid of the single storage type in >>>>>>>> DC >>>>>>>> limitation then we'll be able to define a local posixFS >>>>>>>> domain >>>>>>>> and >>>>>>>> a >>>>>>>> shared one. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>> Andrew/Geert/Simon/Ayal/Miki/Saggi/others: Please >>>>>>>>>>>> feel >>>>>>>>>>>> free >>>>>>>>>>>> to >>>>>>>>>>>> suggest a new term, or vote for one of the >>>>>>>>>>>> previously-discussed >>>>>>>>>>>> terms ("Remote Path" / "Path" / "Mount Spec" / "File >>>>>>>>>>>> System >>>>>>>>>>>> URI"). >>>>>>>>>>>> If no decision will be made here, the term will >>>>>>>>>>>> remain >>>>>>>>>>>> as-is, >>>>>>>>>>>> i.e. >>>>>>>>>>>> "Path". >>>>>>>>>>>> >>>>>>>>>>> ... >> > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecohen at redhat.com Sun May 13 11:30:49 2012 From: ecohen at redhat.com (Einav Cohen) Date: Sun, 13 May 2012 07:30:49 -0400 (EDT) Subject: [Engine-devel] PosixFS: GUI mock-ups have been updated In-Reply-To: <4FAF955B.3090503@redhat.com> Message-ID: <66fce4e8-3597-48af-a71c-5a6dc87d282f@zmail04.collab.prod.int.phx2.redhat.com> > ----- Original Message ----- > From: "Yaniv Kaul" > Sent: Sunday, May 13, 2012 2:04:59 PM > > On 05/13/2012 11:54 AM, Einav Cohen wrote: > > [top posting] > > GUI Mockup has been updated according to this thread: > http://www.ovirt.org/wiki/Features/PosixFSConnection#Changes_in_GUI > Further comments are welcome. > - POSIX, not Posix. > - 'POSIX compliant FS', not 'PosixFS' - Mockups updated. - rest-api change is probably needed [Ori/Geert/Yair - FYI] > - I'd be happy if we could validate whatever we pass to the mount > command against command injection[1] . Ayal/Saggi: Do we have such validation on vdsm? I think we can start with that, we can always add validation to the engine core/UI later. > > Y. > [1] https://www.owasp.org/index.php/Command_Injection > > > > ---- > Thanks, > Einav > > ----- Original Message ----- > > From: "Yair Zaslavsky" To: "Einav Cohen" > Cc: "Ayal Baron" , > engine-devel at ovirt.org , "Simon Grinberg" , > "Saggi Mizrahi" , "Geert Jansen" > , "Ori Liel" , "Miki > Kenneth" , "Andrew Cathrow" > Sent: Sunday, May 13, 2012 10:05:23 AM > Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated > > On 05/11/2012 11:28 PM, Einav Cohen wrote: > > > > ----- Original Message ----- > From: "Ayal Baron" Sent: Friday, May 11, 2012 > 11:03:04 PM > > > ----- Original Message ----- > > > > ----- Original Message ----- > From: "Ayal Baron" Sent: Friday, May 11, 2012 > 11:39:42 AM > > > ----- Original Message ----- > > > > ----- Original Message ----- > From: "Ayal Baron" Sent: Thursday, May 10, 2012 > 10:46:44 PM > > ----- Original Message ----- > > From: "Einav Cohen" To: "Andrew Cathrow" > Cc: engine-devel at ovirt.org , "Simon Grinberg" > , > "Saggi Mizrahi" , "Geert > Jansen" , "Ori Liel" , > "Yair > Zaslavsky" , "Ayal Baron" , > "Miki Kenneth" Sent: Thursday, May 10, 2012 > 2:05:55 PM > Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have > been > updated > > ... > > The important thing is that it's clear what it is - eg. > the > remote/target not the local mount point. That could be > accomplished > in the tool tip, etc. So if there will be a tool-tip (or similar) in > the GUI > explaining > what this field is supposed to be, are you OK with > keeping > the > term > "Path" (in both GUI and rest-api)? I am , does everyone else agree. > either 'path' or 'device' - "Path" it is. +1 on "path" and this was > my original implementation by the way. > > > > > > > > > > - Instead of a tool-tip, I suggest to use an explanation > caption > below the text-box (similar to what we have for NFS storage > domain > - > see attached). Agreed? i.e. "Path to device to mount / remote export" > or something? Yes, that's a good answer to the question afterwards > :) > But what do you think about the general idea of using an > explanation > caption below the "Path" text-box (instead of a tool-tip that was > suggested here earlier)? > > Also, do you think that the above should be the exact phrasing? > The > NFS one is: > "Please use 'FQDN:/path' or 'IP:/path' Example > 'server.example.com:/export/VMs'" > so maybe a "Please use" should be incorporated in this case as > well, > maybe also an example, etc. > What do you think? I replied after viewing the other message and > disliking it > (personal > opinion). I prefer a static explanation (what the field is) > rather > than an action request. > So in the NFS example I would've phrased it as "Remote path to NFS > export, takes either the form: FQDN:/path or IP:/path, e.g. > server.example.com:/export/VMs". > But in any event it is better to have consistency (so both > messages > should probably be phrased similarly). There is no problem changing > the phrasing for NFS. > > So for NFS, the caption will be: > "Remote path to NFS export, takes either the form: FQDN:/path or > IP:/path, e.g. server.example.com:/export/VMs". > > And for PosixFS, the caption will be: > "Path to device to mount / remote export". > (no 'takes the form' or example provided) > > Agreed? > > > > > > > > - What should be the exact phrasing of the explanation text? > > "mount [-fnrsvw] [-t vfstype] [-o options] device dir" > > device is what is being mounted and in the case of NFS is > server:path > > There is a reason why we termed it PosixFS and not SharedFS > and > that > users can specify local devices/FS's (and there is no reason > to > limit it). > > Note that if user defines a local FS and adds 2 hosts to the > Posix > FS > DC then 1 host will be non-op > > Miki - this is not cluster level seeing as PosixFS is a DC > type > (afaik) so no need for tooltips about that. > > In the future when we get rid of the single storage type in > DC > limitation then we'll be able to define a local posixFS > domain > and > a > shared one. > > > > > > > > Andrew/Geert/Simon/Ayal/Miki/Saggi/others: Please > feel > free > to > suggest a new term, or vote for one of the > previously-discussed > terms ("Remote Path" / "Path" / "Mount Spec" / "File > System > URI"). > If no decision will be made here, the term will > remain > as-is, > i.e. > "Path". ... _______________________________________________ > Engine-devel mailing list Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From ykaul at redhat.com Sun May 13 12:12:28 2012 From: ykaul at redhat.com (Yaniv Kaul) Date: Sun, 13 May 2012 15:12:28 +0300 Subject: [Engine-devel] Questions on NIC hotplug (http://www.ovirt.org/wiki/Features/Design/DetailedHotlugNic) Message-ID: <4FAFA52C.8020208@redhat.com> 1. I wasn't sure from the description, but can one change the Network to which a NIC is connected to when it's up? (looks like a much lighter and reasonable action than unplugging-changing-plugging. Also very easy to do in the physical world). I'm quite sure there's a request for such a feature. 2. The REST API usage of 'activate' and 'deactivate' is certainly not inline with the UI's terminology, which is not only a shame, but is also (to me) confusing with setting the NIC's link up/down (which is possible in QEMU, not sure if we do it in oVirt). the UI concept of arrows also seem to support 'up'/'down' ... 3. Donno if it's just the mock ups, but lets try to use 'Network Card' over 'NIC' where possible. 4. I'm not sure why do we need the 'plug' and 'unplug' buttons, and can't do it in the 'Edit' dialog box. I think it's confusing. 5. How do I create a non-plugged NIC via the API? How do I see if a VM's NIC is plugged or not via the API? 6. SDK example would be great too. From lpeer at redhat.com Sun May 13 12:30:33 2012 From: lpeer at redhat.com (Livnat Peer) Date: Sun, 13 May 2012 15:30:33 +0300 Subject: [Engine-devel] Questions on NIC hotplug (http://www.ovirt.org/wiki/Features/Design/DetailedHotlugNic) In-Reply-To: <4FAFA52C.8020208@redhat.com> References: <4FAFA52C.8020208@redhat.com> Message-ID: <4FAFA969.3020008@redhat.com> On 13/05/12 15:12, Yaniv Kaul wrote: > 1. I wasn't sure from the description, but can one change the Network to > which a NIC is connected to when it's up? (looks like a much lighter and > reasonable action than unplugging-changing-plugging. Also very easy to > do in the physical world). I'm quite sure there's a request for such a > feature. It is not supported in libvirt yet: https://bugzilla.redhat.com/show_bug.cgi?id=805071 > 2. The REST API usage of 'activate' and 'deactivate' is certainly not > inline with the UI's terminology, which is not only a shame, but is also > (to me) confusing with setting the NIC's link up/down (which is possible > in QEMU, not sure if we do it in oVirt). the UI concept of arrows also > seem to support 'up'/'down' ... Actually the UI part is not up to date, we changed the terminology and updated the API but the UI screens were left with the old terminology, Igor is fixing that as we speak. > 3. Donno if it's just the mock ups, but lets try to use 'Network Card' > over 'NIC' where possible. Will do, Alona can you please suggest where this can be fixed. > 4. I'm not sure why do we need the 'plug' and 'unplug' buttons, and > can't do it in the 'Edit' dialog box. I think it's confusing. Plug/unplugged is replaced with activate/deactivate and I don't see it as a nic property thus I think they don't belong in the edit dialog box, IMO separate buttons are more clear. > 5. How do I create a non-plugged NIC via the API? How do I see if a VM's > NIC is plugged or not via the API? When you create a nic you can pass a parameter active/inactive, Roy - can you please confirm and add how can I see if a nic is plugged or not in the API? > 6. SDK example would be great too. We'll add it soon. Thanks for your feedback, Livnat _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From alkaplan at redhat.com Sun May 13 12:54:09 2012 From: alkaplan at redhat.com (Alona Kaplan) Date: Sun, 13 May 2012 08:54:09 -0400 (EDT) Subject: [Engine-devel] Questions on NIC hotplug (http://www.ovirt.org/wiki/Features/Design/DetailedHotlugNic) In-Reply-To: <4FAFA969.3020008@redhat.com> Message-ID: > > Regarding 3- It is just the mock up. Actually it is - Network Interfaces. ----- Original Message ----- > From: "Livnat Peer" > To: "Yaniv Kaul" > Cc: engine-devel at ovirt.org, "Alona Kaplan" , "Roy Golan" > Sent: Sunday, May 13, 2012 3:30:33 PM > Subject: Re: [Engine-devel] Questions on NIC hotplug (http://www.ovirt.org/wiki/Features/Design/DetailedHotlugNic) > > On 13/05/12 15:12, Yaniv Kaul wrote: > > 1. I wasn't sure from the description, but can one change the > > Network to > > which a NIC is connected to when it's up? (looks like a much > > lighter and > > reasonable action than unplugging-changing-plugging. Also very easy > > to > > do in the physical world). I'm quite sure there's a request for > > such a > > feature. > > It is not supported in libvirt yet: > https://bugzilla.redhat.com/show_bug.cgi?id=805071 > > > > 2. The REST API usage of 'activate' and 'deactivate' is certainly > > not > > inline with the UI's terminology, which is not only a shame, but is > > also > > (to me) confusing with setting the NIC's link up/down (which is > > possible > > in QEMU, not sure if we do it in oVirt). the UI concept of arrows > > also > > seem to support 'up'/'down' ... > > Actually the UI part is not up to date, we changed the terminology > and > updated the API but the UI screens were left with the old > terminology, > Igor is fixing that as we speak. > > > 3. Donno if it's just the mock ups, but lets try to use 'Network > > Card' > > over 'NIC' where possible. > > Will do, Alona can you please suggest where this can be fixed. > > > 4. I'm not sure why do we need the 'plug' and 'unplug' buttons, and > > can't do it in the 'Edit' dialog box. I think it's confusing. > > Plug/unplugged is replaced with activate/deactivate and I don't see > it > as a nic property thus I think they don't belong in the edit dialog > box, IMO separate buttons are more clear. > > > 5. How do I create a non-plugged NIC via the API? How do I see if a > > VM's > > NIC is plugged or not via the API? > > When you create a nic you can pass a parameter active/inactive, Roy - > can you please confirm and add how can I see if a nic is plugged or > not > in the API? > > > 6. SDK example would be great too. > > We'll add it soon. > > Thanks for your feedback, > > Livnat > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > From yzaslavs at redhat.com Sun May 13 13:51:31 2012 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Sun, 13 May 2012 16:51:31 +0300 Subject: [Engine-devel] PosixFS: GUI mock-ups have been updated In-Reply-To: <4FAF955B.3090503@redhat.com> References: <7ed17043-96e5-4151-a32c-6ddb8e68d990@zmail04.collab.prod.int.phx2.redhat.com> <4FAF955B.3090503@redhat.com> Message-ID: <4FAFBC63.8020306@redhat.com> On 05/13/2012 02:04 PM, Yaniv Kaul wrote: > On 05/13/2012 11:54 AM, Einav Cohen wrote: >> [top posting] >> >> GUI Mockup has been updated according to this thread: >> http://www.ovirt.org/wiki/Features/PosixFSConnection#Changes_in_GUI >> >> Further comments are welcome. > > - POSIX, not Posix. > - 'POSIX compliant FS', not 'PosixFS' > - I'd be happy if we could validate whatever we pass to the mount > command against command injection[1] . > > Y. > [1] https://www.owasp.org/index.php/Command_Injection > >> >> ---- >> Thanks, >> Einav >> >> ----- Original Message ----- >>> From: "Yair Zaslavsky" >>> To: "Einav Cohen" >>> Cc: "Ayal Baron" , engine-devel at ovirt.org, "Simon Grinberg" , "Saggi Mizrahi" >>> , "Geert Jansen" , "Ori Liel" , "Miki Kenneth" >>> , "Andrew Cathrow" >>> Sent: Sunday, May 13, 2012 10:05:23 AM >>> Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated >>> >>> On 05/11/2012 11:28 PM, Einav Cohen wrote: >>>>> ----- Original Message ----- >>>>> From: "Ayal Baron" >>>>> Sent: Friday, May 11, 2012 11:03:04 PM >>>>> >>>>> >>>>> ----- Original Message ----- >>>>>>> ----- Original Message ----- >>>>>>> From: "Ayal Baron" >>>>>>> Sent: Friday, May 11, 2012 11:39:42 AM >>>>>>> >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>>>> ----- Original Message ----- >>>>>>>>> From: "Ayal Baron" >>>>>>>>> Sent: Thursday, May 10, 2012 10:46:44 PM >>>>>>>>> >>>>>>>>>> >>>>>>>>>> ----- Original Message ----- >>>>>>>>>>> From: "Einav Cohen" >>>>>>>>>>> To: "Andrew Cathrow" >>>>>>>>>>> Cc: engine-devel at ovirt.org, "Simon Grinberg" >>>>>>>>>>> , >>>>>>>>>>> "Saggi Mizrahi" , "Geert >>>>>>>>>>> Jansen" , "Ori Liel" >>>>>>>>>>> , >>>>>>>>>>> "Yair >>>>>>>>>>> Zaslavsky" , "Ayal Baron" >>>>>>>>>>> , "Miki Kenneth" >>>>>>>>>>> Sent: Thursday, May 10, 2012 2:05:55 PM >>>>>>>>>>> Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have >>>>>>>>>>> been >>>>>>>>>>> updated >>>>>>>>>>> >>>>>>>>>>>> ... >>>>>>>>>>>> >>>>>>>>>>>> The important thing is that it's clear what it is - eg. >>>>>>>>>>>> the >>>>>>>>>>>> remote/target not the local mount point. That could be >>>>>>>>>>>> accomplished >>>>>>>>>>>> in the tool tip, etc. >>>>>>>>>>> So if there will be a tool-tip (or similar) in the GUI >>>>>>>>>>> explaining >>>>>>>>>>> what this field is supposed to be, are you OK with >>>>>>>>>>> keeping >>>>>>>>>>> the >>>>>>>>>>> term >>>>>>>>>>> "Path" (in both GUI and rest-api)? >>>>>>>>>> I am , does everyone else agree. >>>>>>>>> either 'path' or 'device' >>>>>>>> - "Path" it is. >>> +1 on "path" and this was my original implementation by the way. Now that I think of it - maybe we can have "Address" as optional argument AND "Path" as mandatory at REST-API? Examples - address: 10.35.16.36 path: /export/share1 Will be translated to mountSpec of "10.35.16.36:/export/share1" path: /home/someuser/domain1 Will be translated to mounSpec of "/home/some/user/domain1". Thoughts on this? >>> >>> >>>>>>>> - Instead of a tool-tip, I suggest to use an explanation >>>>>>>> caption >>>>>>>> below the text-box (similar to what we have for NFS storage >>>>>>>> domain >>>>>>>> - >>>>>>>> see attached). Agreed? >>>>>>> i.e. "Path to device to mount / remote export" or something? >>>>>> Yes, that's a good answer to the question afterwards :) >>>>>> But what do you think about the general idea of using an >>>>>> explanation >>>>>> caption below the "Path" text-box (instead of a tool-tip that was >>>>>> suggested here earlier)? >>>>>> >>>>>> Also, do you think that the above should be the exact phrasing? >>>>>> The >>>>>> NFS one is: >>>>>> "Please use 'FQDN:/path' or 'IP:/path' Example >>>>>> 'server.example.com:/export/VMs'" >>>>>> so maybe a "Please use" should be incorporated in this case as >>>>>> well, >>>>>> maybe also an example, etc. >>>>>> What do you think? >>>>> I replied after viewing the other message and disliking it >>>>> (personal >>>>> opinion). I prefer a static explanation (what the field is) >>>>> rather >>>>> than an action request. >>>>> So in the NFS example I would've phrased it as "Remote path to NFS >>>>> export, takes either the form: FQDN:/path or IP:/path, e.g. >>>>> server.example.com:/export/VMs". >>>>> But in any event it is better to have consistency (so both >>>>> messages >>>>> should probably be phrased similarly). >>>> There is no problem changing the phrasing for NFS. >>>> >>>> So for NFS, the caption will be: >>>> "Remote path to NFS export, takes either the form: FQDN:/path or >>>> IP:/path, e.g. server.example.com:/export/VMs". >>>> >>>> And for PosixFS, the caption will be: >>>> "Path to device to mount / remote export". >>>> (no 'takes the form' or example provided) >>>> >>>> Agreed? >>>> >>>>>>> >>>>>>>> - What should be the exact phrasing of the explanation text? >>>>>>>> >>>>>>>>> "mount [-fnrsvw] [-t vfstype] [-o options] device dir" >>>>>>>>> >>>>>>>>> device is what is being mounted and in the case of NFS is >>>>>>>>> server:path >>>>>>>>> >>>>>>>>> There is a reason why we termed it PosixFS and not SharedFS >>>>>>>>> and >>>>>>>>> that >>>>>>>>> users can specify local devices/FS's (and there is no reason >>>>>>>>> to >>>>>>>>> limit it). >>>>>>>>> >>>>>>>>> Note that if user defines a local FS and adds 2 hosts to the >>>>>>>>> Posix >>>>>>>>> FS >>>>>>>>> DC then 1 host will be non-op >>>>>>>>> >>>>>>>>> Miki - this is not cluster level seeing as PosixFS is a DC >>>>>>>>> type >>>>>>>>> (afaik) so no need for tooltips about that. >>>>>>>>> >>>>>>>>> In the future when we get rid of the single storage type in >>>>>>>>> DC >>>>>>>>> limitation then we'll be able to define a local posixFS >>>>>>>>> domain >>>>>>>>> and >>>>>>>>> a >>>>>>>>> shared one. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> Andrew/Geert/Simon/Ayal/Miki/Saggi/others: Please >>>>>>>>>>>>> feel >>>>>>>>>>>>> free >>>>>>>>>>>>> to >>>>>>>>>>>>> suggest a new term, or vote for one of the >>>>>>>>>>>>> previously-discussed >>>>>>>>>>>>> terms ("Remote Path" / "Path" / "Mount Spec" / "File >>>>>>>>>>>>> System >>>>>>>>>>>>> URI"). >>>>>>>>>>>>> If no decision will be made here, the term will >>>>>>>>>>>>> remain >>>>>>>>>>>>> as-is, >>>>>>>>>>>>> i.e. >>>>>>>>>>>>> "Path". >>>>>>>>>>>>> >>>>>>>>>>>> ... >>> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel > From ecohen at redhat.com Sun May 13 14:13:47 2012 From: ecohen at redhat.com (Einav Cohen) Date: Sun, 13 May 2012 10:13:47 -0400 (EDT) Subject: [Engine-devel] PosixFS: GUI mock-ups have been updated In-Reply-To: <4FAFBC63.8020306@redhat.com> Message-ID: > ----- Original Message ----- > From: "Yair Zaslavsky" > Sent: Sunday, May 13, 2012 4:51:31 PM > > On 05/13/2012 02:04 PM, Yaniv Kaul wrote: > > On 05/13/2012 11:54 AM, Einav Cohen wrote: > >> [top posting] > >> > >> GUI Mockup has been updated according to this thread: > >> http://www.ovirt.org/wiki/Features/PosixFSConnection#Changes_in_GUI > >> > >> Further comments are welcome. > > > > - POSIX, not Posix. > > - 'POSIX compliant FS', not 'PosixFS' > > - I'd be happy if we could validate whatever we pass to the mount > > command against command injection[1] . > > > > Y. > > [1] https://www.owasp.org/index.php/Command_Injection > > > >> > >> ---- > >> Thanks, > >> Einav > >> > >> ----- Original Message ----- > >>> From: "Yair Zaslavsky" > >>> To: "Einav Cohen" > >>> Cc: "Ayal Baron" , engine-devel at ovirt.org, > >>> "Simon Grinberg" , "Saggi Mizrahi" > >>> , "Geert Jansen" , "Ori > >>> Liel" , "Miki Kenneth" > >>> , "Andrew Cathrow" > >>> Sent: Sunday, May 13, 2012 10:05:23 AM > >>> Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been > >>> updated > >>> > >>> On 05/11/2012 11:28 PM, Einav Cohen wrote: > >>>>> ----- Original Message ----- > >>>>> From: "Ayal Baron" > >>>>> Sent: Friday, May 11, 2012 11:03:04 PM > >>>>> > >>>>> > >>>>> ----- Original Message ----- > >>>>>>> ----- Original Message ----- > >>>>>>> From: "Ayal Baron" > >>>>>>> Sent: Friday, May 11, 2012 11:39:42 AM > >>>>>>> > >>>>>>> > >>>>>>> ----- Original Message ----- > >>>>>>>>> ----- Original Message ----- > >>>>>>>>> From: "Ayal Baron" > >>>>>>>>> Sent: Thursday, May 10, 2012 10:46:44 PM > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> ----- Original Message ----- > >>>>>>>>>>> From: "Einav Cohen" > >>>>>>>>>>> To: "Andrew Cathrow" > >>>>>>>>>>> Cc: engine-devel at ovirt.org, "Simon Grinberg" > >>>>>>>>>>> , > >>>>>>>>>>> "Saggi Mizrahi" , "Geert > >>>>>>>>>>> Jansen" , "Ori Liel" > >>>>>>>>>>> , > >>>>>>>>>>> "Yair > >>>>>>>>>>> Zaslavsky" , "Ayal Baron" > >>>>>>>>>>> , "Miki Kenneth" > >>>>>>>>>>> Sent: Thursday, May 10, 2012 2:05:55 PM > >>>>>>>>>>> Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have > >>>>>>>>>>> been > >>>>>>>>>>> updated > >>>>>>>>>>> > >>>>>>>>>>>> ... > >>>>>>>>>>>> > >>>>>>>>>>>> The important thing is that it's clear what it is - eg. > >>>>>>>>>>>> the > >>>>>>>>>>>> remote/target not the local mount point. That could be > >>>>>>>>>>>> accomplished > >>>>>>>>>>>> in the tool tip, etc. > >>>>>>>>>>> So if there will be a tool-tip (or similar) in the GUI > >>>>>>>>>>> explaining > >>>>>>>>>>> what this field is supposed to be, are you OK with > >>>>>>>>>>> keeping > >>>>>>>>>>> the > >>>>>>>>>>> term > >>>>>>>>>>> "Path" (in both GUI and rest-api)? > >>>>>>>>>> I am , does everyone else agree. > >>>>>>>>> either 'path' or 'device' > >>>>>>>> - "Path" it is. > >>> +1 on "path" and this was my original implementation by the way. > Now that I think of it - maybe we can have "Address" as optional > argument AND "Path" as mandatory at REST-API? > Examples - > address: 10.35.16.36 > path: /export/share1 > > Will be translated to mountSpec of "10.35.16.36:/export/share1" > > path: /home/someuser/domain1 > > Will be translated to mounSpec of "/home/some/user/domain1". > > Thoughts on this? +1 It is more compliant with the already-existing NFS storage domain representation in rest-api (that also uses "address" and "path" in the same manner). This is, of course, assuming that we can enforce "address" as mandatory for NFS storage domain and treat it as optional for POSIX storage domain. Geert/Ori/Michael - any thoughts about this? > > >>> > >>> > >>>>>>>> - Instead of a tool-tip, I suggest to use an explanation > >>>>>>>> caption > >>>>>>>> below the text-box (similar to what we have for NFS storage > >>>>>>>> domain > >>>>>>>> - > >>>>>>>> see attached). Agreed? > >>>>>>> i.e. "Path to device to mount / remote export" or something? > >>>>>> Yes, that's a good answer to the question afterwards :) > >>>>>> But what do you think about the general idea of using an > >>>>>> explanation > >>>>>> caption below the "Path" text-box (instead of a tool-tip that > >>>>>> was > >>>>>> suggested here earlier)? > >>>>>> > >>>>>> Also, do you think that the above should be the exact > >>>>>> phrasing? > >>>>>> The > >>>>>> NFS one is: > >>>>>> "Please use 'FQDN:/path' or 'IP:/path' Example > >>>>>> 'server.example.com:/export/VMs'" > >>>>>> so maybe a "Please use" should be incorporated in this case as > >>>>>> well, > >>>>>> maybe also an example, etc. > >>>>>> What do you think? > >>>>> I replied after viewing the other message and disliking it > >>>>> (personal > >>>>> opinion). I prefer a static explanation (what the field is) > >>>>> rather > >>>>> than an action request. > >>>>> So in the NFS example I would've phrased it as "Remote path to > >>>>> NFS > >>>>> export, takes either the form: FQDN:/path or IP:/path, e.g. > >>>>> server.example.com:/export/VMs". > >>>>> But in any event it is better to have consistency (so both > >>>>> messages > >>>>> should probably be phrased similarly). > >>>> There is no problem changing the phrasing for NFS. > >>>> > >>>> So for NFS, the caption will be: > >>>> "Remote path to NFS export, takes either the form: FQDN:/path or > >>>> IP:/path, e.g. server.example.com:/export/VMs". > >>>> > >>>> And for PosixFS, the caption will be: > >>>> "Path to device to mount / remote export". > >>>> (no 'takes the form' or example provided) > >>>> > >>>> Agreed? > >>>> > >>>>>>> > >>>>>>>> - What should be the exact phrasing of the explanation text? > >>>>>>>> > >>>>>>>>> "mount [-fnrsvw] [-t vfstype] [-o options] device dir" > >>>>>>>>> > >>>>>>>>> device is what is being mounted and in the case of NFS is > >>>>>>>>> server:path > >>>>>>>>> > >>>>>>>>> There is a reason why we termed it PosixFS and not SharedFS > >>>>>>>>> and > >>>>>>>>> that > >>>>>>>>> users can specify local devices/FS's (and there is no > >>>>>>>>> reason > >>>>>>>>> to > >>>>>>>>> limit it). > >>>>>>>>> > >>>>>>>>> Note that if user defines a local FS and adds 2 hosts to > >>>>>>>>> the > >>>>>>>>> Posix > >>>>>>>>> FS > >>>>>>>>> DC then 1 host will be non-op > >>>>>>>>> > >>>>>>>>> Miki - this is not cluster level seeing as PosixFS is a DC > >>>>>>>>> type > >>>>>>>>> (afaik) so no need for tooltips about that. > >>>>>>>>> > >>>>>>>>> In the future when we get rid of the single storage type in > >>>>>>>>> DC > >>>>>>>>> limitation then we'll be able to define a local posixFS > >>>>>>>>> domain > >>>>>>>>> and > >>>>>>>>> a > >>>>>>>>> shared one. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>>>> Andrew/Geert/Simon/Ayal/Miki/Saggi/others: Please > >>>>>>>>>>>>> feel > >>>>>>>>>>>>> free > >>>>>>>>>>>>> to > >>>>>>>>>>>>> suggest a new term, or vote for one of the > >>>>>>>>>>>>> previously-discussed > >>>>>>>>>>>>> terms ("Remote Path" / "Path" / "Mount Spec" / "File > >>>>>>>>>>>>> System > >>>>>>>>>>>>> URI"). > >>>>>>>>>>>>> If no decision will be made here, the term will > >>>>>>>>>>>>> remain > >>>>>>>>>>>>> as-is, > >>>>>>>>>>>>> i.e. > >>>>>>>>>>>>> "Path". > >>>>>>>>>>>>> > >>>>>>>>>>>> ... > >>> > >> _______________________________________________ > >> Engine-devel mailing list > >> Engine-devel at ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > From ItzikB at mellanox.com Mon May 14 06:12:03 2012 From: ItzikB at mellanox.com (Itzik Brown) Date: Mon, 14 May 2012 06:12:03 +0000 Subject: [Engine-devel] value too long for type character varying(20) in function "insertvds_interface" In-Reply-To: <4FAEB05C.4080807@redhat.com> References: <4488206DC085244C886DBC9E7038B689251852C6@mtrdag02.mtl.com> <4FACC7FE.4030700@redhat.com> <20120511084042.GF22381@redhat.com> <4FAEB05C.4080807@redhat.com> Message-ID: <4488206DC085244C886DBC9E7038B689251855F3@mtrdag02.mtl.com> The problem is with the mac_addr field. For my Infiniband HCA the hardware address is 59 chars long. I changed the scheme of the engine and now it works. Itzik -----Original Message----- From: Livnat Peer [mailto:lpeer at redhat.com] Sent: ??? 12 ??? 2012 21:48 To: Dan Kenigsberg Cc: Itamar Heim; Itzik Brown; engine-devel at ovirt.org; Yaniv Dary Subject: Re: [Engine-devel] value too long for type character varying(20) in function "insertvds_interface" On 11/05/12 11:40, Dan Kenigsberg wrote: > On Fri, May 11, 2012 at 11:04:14AM +0300, Itamar Heim wrote: >> On 05/11/2012 03:52 AM, Itzik Brown wrote: >>> Hi, >>> >>> When running VDSM on host with Infiniband HCAs I get the following errors in /usr/share/jboss-as/standalone/log/server.log on the ovirt-engine host. >>> >>> WARN [org.ovirt.engine.core.vdsbroker.VdsManager] (QuartzScheduler_Worker-17) ResourceManager::refreshVdsRunTimeInfo::Failed to refresh VDS , vds = 783eb0ac-9a91-11e1-a8e4-000c29de7759 : xena003, error = DataIntegrityViolationException: CallableStatementCallback; SQL [{call insertvds_interface(?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)}]; ERROR: value too long for type character varying(20) >>> Where: SQL statement "INSERT INTO vds_interface(addr, bond_name, bond_type, gateway, id, is_bond, bond_opts, mac_addr, name, network_name, speed, subnet, boot_protocol, type, VDS_ID, vlan_id, mtu, bridged) >>> VALUES(v_addr, v_bond_name, v_bond_type, v_gateway, v_id, v_is_bond, v_bond_opts, v_mac_addr, v_name, v_network_name, v_speed, v_subnet, v_boot_protocol, v_type, v_vds_id, v_vlan_id, v_mtu, v_bridged)" >>> >>> More detailed log: >>> http://pastebin.com/AHD3di5i >>> >>> VDSM: From git repository commit >>> 8a14b63fbbafbdb9ee7f85a9b702bff310f4f668 >>> oVirt-engine: From git repository comit >>> b24dddf094e08afa6a2032a487b37476318a872d >>> >>> Any suggestions? >> >> in general, you would need to send a patch to upgrade the scheme to a >> value longer than 20 characters for a logical network name. >> 1. I think bridge name is linux is limited to 15 characters, so not >> sure actually why 20 are allowed today. danken? > > No idea why it's 20.. IIRC vdsm silently ignore the trailing chars > past the 15th. > I opened a BZ on this - https://bugzilla.redhat.com/show_bug.cgi?id=821172 "VM network name should be limited to 15 chars " Livnat >> 2. if changing the db scheme of the engine, also need to remember to >> upgrade the history db as well. >> 3. if different network implementation can support varying lengths, >> need to add validations in engine ("CanDoAction") to check the >> length per type of network implementation. From yzaslavs at redhat.com Mon May 14 06:22:05 2012 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Mon, 14 May 2012 09:22:05 +0300 Subject: [Engine-devel] value too long for type character varying(20) in function "insertvds_interface" In-Reply-To: <4488206DC085244C886DBC9E7038B689251855F3@mtrdag02.mtl.com> References: <4488206DC085244C886DBC9E7038B689251852C6@mtrdag02.mtl.com> <4FACC7FE.4030700@redhat.com> <20120511084042.GF22381@redhat.com> <4FAEB05C.4080807@redhat.com> <4488206DC085244C886DBC9E7038B689251855F3@mtrdag02.mtl.com> Message-ID: <4FB0A48D.5070507@redhat.com> On 05/14/2012 09:12 AM, Itzik Brown wrote: > The problem is with the mac_addr field. > For my Infiniband HCA the hardware address is 59 chars long. > I changed the scheme of the engine and now it works. > > Itzik I wonder if there is some upper bound on the varchar length we can decide upon... Yair > > -----Original Message----- > From: Livnat Peer [mailto:lpeer at redhat.com] > Sent: ??? 12 ??? 2012 21:48 > To: Dan Kenigsberg > Cc: Itamar Heim; Itzik Brown; engine-devel at ovirt.org; Yaniv Dary > Subject: Re: [Engine-devel] value too long for type character varying(20) in function "insertvds_interface" > > On 11/05/12 11:40, Dan Kenigsberg wrote: >> On Fri, May 11, 2012 at 11:04:14AM +0300, Itamar Heim wrote: >>> On 05/11/2012 03:52 AM, Itzik Brown wrote: >>>> Hi, >>>> >>>> When running VDSM on host with Infiniband HCAs I get the following errors in /usr/share/jboss-as/standalone/log/server.log on the ovirt-engine host. >>>> >>>> WARN [org.ovirt.engine.core.vdsbroker.VdsManager] (QuartzScheduler_Worker-17) ResourceManager::refreshVdsRunTimeInfo::Failed to refresh VDS , vds = 783eb0ac-9a91-11e1-a8e4-000c29de7759 : xena003, error = DataIntegrityViolationException: CallableStatementCallback; SQL [{call insertvds_interface(?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)}]; ERROR: value too long for type character varying(20) >>>> Where: SQL statement "INSERT INTO vds_interface(addr, bond_name, bond_type, gateway, id, is_bond, bond_opts, mac_addr, name, network_name, speed, subnet, boot_protocol, type, VDS_ID, vlan_id, mtu, bridged) >>>> VALUES(v_addr, v_bond_name, v_bond_type, v_gateway, v_id, v_is_bond, v_bond_opts, v_mac_addr, v_name, v_network_name, v_speed, v_subnet, v_boot_protocol, v_type, v_vds_id, v_vlan_id, v_mtu, v_bridged)" >>>> >>>> More detailed log: >>>> http://pastebin.com/AHD3di5i >>>> >>>> VDSM: From git repository commit >>>> 8a14b63fbbafbdb9ee7f85a9b702bff310f4f668 >>>> oVirt-engine: From git repository comit >>>> b24dddf094e08afa6a2032a487b37476318a872d >>>> >>>> Any suggestions? >>> >>> in general, you would need to send a patch to upgrade the scheme to a >>> value longer than 20 characters for a logical network name. >>> 1. I think bridge name is linux is limited to 15 characters, so not >>> sure actually why 20 are allowed today. danken? >> >> No idea why it's 20.. IIRC vdsm silently ignore the trailing chars >> past the 15th. >> > > I opened a BZ on this - > > https://bugzilla.redhat.com/show_bug.cgi?id=821172 > "VM network name should be limited to 15 chars " > > > Livnat > >>> 2. if changing the db scheme of the engine, also need to remember to >>> upgrade the history db as well. >>> 3. if different network implementation can support varying lengths, >>> need to add validations in engine ("CanDoAction") to check the >>> length per type of network implementation. > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From amureini at redhat.com Mon May 14 09:03:01 2012 From: amureini at redhat.com (Allon Mureinik) Date: Mon, 14 May 2012 05:03:01 -0400 (EDT) Subject: [Engine-devel] The easy way to mock Config in your unit tests In-Reply-To: <6e24687f-cbf2-4f96-82bc-9dff3e700fe2@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: Here's the outcome of the thread below: http://ovirt.org/wiki/MockConfigRule Enjoy! Many thanks to the patches' reviewers. ----- Original Message ----- > From: "Laszlo Hornyak" > To: "engine-devel" > Sent: Monday, May 7, 2012 2:23:10 PM > Subject: Re: [Engine-devel] The correct way to create test dependencies between > > +1 > I like the idea, I think this would really improve our unit tests. > > ----- Original Message ----- > > From: "Allon Mureinik" > > To: "engine-devel" > > Sent: Sunday, May 6, 2012 2:46:03 PM > > Subject: [Engine-devel] The correct way to create test dependencies > > between > > > > Hi guys, > > > > I've recently come up with (what I believe is) an elegant way to > > mock > > the Config object using JUnit @Rules and Mockito (The gritty > > details can be found at http://gerrit.ovirt.org/4155). > > > > This presented me with another issue: > > On the one hand, the code depends on junit and mockito jars, which > > are not available in the main scope, only in the test scope. > > On the other hand, in vanilla Maven there is no dependency between > > tests of different projects, so placing this class in util's test > > would make it inaccessible to bll tests. > > > > The solution Maven suggests for these kind of issues is creating a > > test jar > > (http://maven.apache.org/guides/mini/guide-attached-tests.html): In > > addition to the regular jar the module produces, you'll get another > > -test jar, which other modules can depend on using the > > test-jar, which could of course be put in > > test. > > > > Before pushing forward with this approach, I'd like to know if > > anyone > > has a principle objection to it. > > > > > > Thanks, > > Allon > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From lhornyak at redhat.com Mon May 14 09:19:11 2012 From: lhornyak at redhat.com (Laszlo Hornyak) Date: Mon, 14 May 2012 05:19:11 -0400 (EDT) Subject: [Engine-devel] reviewer needed for cleanup patchset In-Reply-To: <629c3147-2db8-4fd1-9c24-8f6c15877679@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: Hi, I need someone who could verify and/or approve my changeset to remove usage of the deprecated RefObject class. http://gerrit.ovirt.org/4235 http://gerrit.ovirt.org/4236 http://gerrit.ovirt.org/4237 http://gerrit.ovirt.org/4238 http://gerrit.ovirt.org/4239 Thank you, Laszlo From oliel at redhat.com Mon May 14 11:19:20 2012 From: oliel at redhat.com (Ori Liel) Date: Mon, 14 May 2012 07:19:20 -0400 (EDT) Subject: [Engine-devel] REST-API: Exposing correlation-ID In-Reply-To: <4FA8EA09.6080605@redhat.com> Message-ID: <750f8c50-2d5e-4524-99dc-52d9180306a2@zmail17.collab.prod.int.phx2.redhat.com> No decision about the name of the parameter yet, and this is blocking me. Names that were suggested so far: * flow-id * batch-id * log_id / log_entry_id * op_id / operation_id * correlation_id * MetaTask-ID It seems like the only purpose of this feature is logging, so I'm voting for 'log_entry_id' (although I consider some of the other options viable as well). Does someone disagree with 'log_entry_id'? Thanks, Ori. ----- Original Message ----- From: "Itamar Heim" To: "Eoghan Glynn" Cc: "Ori Liel" , engine-devel at ovirt.org Sent: Tuesday, May 8, 2012 12:40:25 PM Subject: Re: [Engine-devel] REST-API: Exposing correlation-ID On 05/08/2012 12:00 PM, Eoghan Glynn wrote: > > >>>>>> 1) what's the name you'd give this parameter? job-id? batch-id? >>>>>> flow-id? command-id? correlation-id??? >>>> >>>> job-id will confuse us with engine's job-id which is a single >>>> command >>>> today. >>>> correleation-id is pretty long and confusing as implies on >>>> correlation >>>> of something. >>>> >>>> I'm for flow-id or batch-id. >>>> batch-id sounds the right one to me, as this is identifying a >>>> batch >>>> of >>>> calls. >> >>> How about log-id? >>> It isn't supposed to be unique, or of any format, it's just used to >>> log calls, so log-id is the most natural (or log-tag or whatever >>> name you prefer). >>> >>> Also I think it's more of a header-type parameter since it's >>> metadata for the call, not an actual parameter that influences the >>> outcome of the "flow". >> >> I actually believe you're right, it probably is better to pass this parameter as >> an http header. You've changed my mind about this (objections, anyone, to passing >> it as a header as opposed to passing it as a url parameter)? > > Agree also that a header is much more natural in this case than a URL parameter. > > Also in the case where the client does not specify the ID themselves on the > initial request, a generated value should be returned as response header > (so that this can be passed as request header with the next request if part > of the same over-arching task, or else just to aid log interpretation if the > initial request was standalone but still mapped internally to multiple backend > actions). > > >> About log_id - it could sound like there are numerous logs, and the user is asked >> to specify the ID of the log he wishes to write to. But perhaps: log_entry_id? > > Is there any possibility that this identifier may be leveraged for uses other than > log interpretation? > > One other suggestion to add into the mix: MetaTask-ID. the one thing mentioned in the thread and worth remembering is this ID is not unique, as client can set it as they want. From yzaslavs at redhat.com Mon May 14 12:18:56 2012 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Mon, 14 May 2012 15:18:56 +0300 Subject: [Engine-devel] REST-API: Exposing correlation-ID In-Reply-To: <750f8c50-2d5e-4524-99dc-52d9180306a2@zmail17.collab.prod.int.phx2.redhat.com> References: <750f8c50-2d5e-4524-99dc-52d9180306a2@zmail17.collab.prod.int.phx2.redhat.com> Message-ID: <4FB0F830.1070904@redhat.com> On 05/14/2012 02:19 PM, Ori Liel wrote: > No decision about the name of the parameter yet, and this is blocking me. > > Names that were suggested so far: > > * flow-id > * batch-id > * log_id / log_entry_id > * op_id / operation_id +1 > * correlation_id > * MetaTask-ID > > It seems like the only purpose of this feature is logging, so I'm > voting for 'log_entry_id' (although I consider some of the other options > viable as well). Does someone disagree with 'log_entry_id'? IMHO, log_entry_id shounds "too generic" to me. Maybe in the future we would like to expose other logging/tracking to REST-API? >From the other options op_id/operation_id sounds best to me. > > Thanks, > > Ori. > > ----- Original Message ----- > From: "Itamar Heim" > To: "Eoghan Glynn" > Cc: "Ori Liel" , engine-devel at ovirt.org > Sent: Tuesday, May 8, 2012 12:40:25 PM > Subject: Re: [Engine-devel] REST-API: Exposing correlation-ID > > On 05/08/2012 12:00 PM, Eoghan Glynn wrote: >> >> >>>>>>> 1) what's the name you'd give this parameter? job-id? batch-id? >>>>>>> flow-id? command-id? correlation-id??? >>>>> >>>>> job-id will confuse us with engine's job-id which is a single >>>>> command >>>>> today. >>>>> correleation-id is pretty long and confusing as implies on >>>>> correlation >>>>> of something. >>>>> >>>>> I'm for flow-id or batch-id. >>>>> batch-id sounds the right one to me, as this is identifying a >>>>> batch >>>>> of >>>>> calls. >>> >>>> How about log-id? >>>> It isn't supposed to be unique, or of any format, it's just used to >>>> log calls, so log-id is the most natural (or log-tag or whatever >>>> name you prefer). >>>> >>>> Also I think it's more of a header-type parameter since it's >>>> metadata for the call, not an actual parameter that influences the >>>> outcome of the "flow". >>> >>> I actually believe you're right, it probably is better to pass this parameter as >>> an http header. You've changed my mind about this (objections, anyone, to passing >>> it as a header as opposed to passing it as a url parameter)? >> >> Agree also that a header is much more natural in this case than a URL parameter. >> >> Also in the case where the client does not specify the ID themselves on the >> initial request, a generated value should be returned as response header >> (so that this can be passed as request header with the next request if part >> of the same over-arching task, or else just to aid log interpretation if the >> initial request was standalone but still mapped internally to multiple backend >> actions). >> >> >>> About log_id - it could sound like there are numerous logs, and the user is asked >>> to specify the ID of the log he wishes to write to. But perhaps: log_entry_id? >> >> Is there any possibility that this identifier may be leveraged for uses other than >> log interpretation? >> >> One other suggestion to add into the mix: MetaTask-ID. > > the one thing mentioned in the thread and worth remembering is this ID > is not unique, as client can set it as they want. > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From iheim at redhat.com Mon May 14 15:39:38 2012 From: iheim at redhat.com (Itamar Heim) Date: Mon, 14 May 2012 18:39:38 +0300 Subject: [Engine-devel] REST-API: Exposing correlation-ID In-Reply-To: <4FB0F830.1070904@redhat.com> References: <750f8c50-2d5e-4524-99dc-52d9180306a2@zmail17.collab.prod.int.phx2.redhat.com> <4FB0F830.1070904@redhat.com> Message-ID: <4FB1273A.3080704@redhat.com> On 05/14/2012 03:18 PM, Yair Zaslavsky wrote: > On 05/14/2012 02:19 PM, Ori Liel wrote: >> No decision about the name of the parameter yet, and this is blocking me. >> >> Names that were suggested so far: >> >> * flow-id +1 >> * batch-id +1 >> * log_id / log_entry_id >> * op_id / operation_id > +1 -1 from me, as this is about a group of operations . >> * correlation_id +1 >> * MetaTask-ID -1, too pompous? a maybe to remove the "ID" from name, since there is no uniqueness guarantee. >> >> It seems like the only purpose of this feature is logging, so I'm >> voting for 'log_entry_id' (although I consider some of the other options >> viable as well). Does someone disagree with 'log_entry_id'? > > IMHO, log_entry_id shounds "too generic" to me. Maybe in the future we > would like to expose other logging/tracking to REST-API? > > From the other options op_id/operation_id sounds best to me. > >> >> Thanks, >> >> Ori. >> >> ----- Original Message ----- >> From: "Itamar Heim" >> To: "Eoghan Glynn" >> Cc: "Ori Liel", engine-devel at ovirt.org >> Sent: Tuesday, May 8, 2012 12:40:25 PM >> Subject: Re: [Engine-devel] REST-API: Exposing correlation-ID >> >> On 05/08/2012 12:00 PM, Eoghan Glynn wrote: >>> >>> >>>>>>>> 1) what's the name you'd give this parameter? job-id? batch-id? >>>>>>>> flow-id? command-id? correlation-id??? >>>>>> >>>>>> job-id will confuse us with engine's job-id which is a single >>>>>> command >>>>>> today. >>>>>> correleation-id is pretty long and confusing as implies on >>>>>> correlation >>>>>> of something. >>>>>> >>>>>> I'm for flow-id or batch-id. >>>>>> batch-id sounds the right one to me, as this is identifying a >>>>>> batch >>>>>> of >>>>>> calls. >>>> >>>>> How about log-id? >>>>> It isn't supposed to be unique, or of any format, it's just used to >>>>> log calls, so log-id is the most natural (or log-tag or whatever >>>>> name you prefer). >>>>> >>>>> Also I think it's more of a header-type parameter since it's >>>>> metadata for the call, not an actual parameter that influences the >>>>> outcome of the "flow". >>>> >>>> I actually believe you're right, it probably is better to pass this parameter as >>>> an http header. You've changed my mind about this (objections, anyone, to passing >>>> it as a header as opposed to passing it as a url parameter)? >>> >>> Agree also that a header is much more natural in this case than a URL parameter. >>> >>> Also in the case where the client does not specify the ID themselves on the >>> initial request, a generated value should be returned as response header >>> (so that this can be passed as request header with the next request if part >>> of the same over-arching task, or else just to aid log interpretation if the >>> initial request was standalone but still mapped internally to multiple backend >>> actions). >>> >>> >>>> About log_id - it could sound like there are numerous logs, and the user is asked >>>> to specify the ID of the log he wishes to write to. But perhaps: log_entry_id? >>> >>> Is there any possibility that this identifier may be leveraged for uses other than >>> log interpretation? >>> >>> One other suggestion to add into the mix: MetaTask-ID. >> >> the one thing mentioned in the thread and worth remembering is this ID >> is not unique, as client can set it as they want. >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From eglynn at redhat.com Mon May 14 16:05:37 2012 From: eglynn at redhat.com (Eoghan Glynn) Date: Mon, 14 May 2012 12:05:37 -0400 (EDT) Subject: [Engine-devel] REST-API: Exposing correlation-ID In-Reply-To: <4FB1273A.3080704@redhat.com> Message-ID: > >> * MetaTask-ID > > -1, too pompous? Me, pompous? Never! ;) > a maybe to remove the "ID" from name, since there is no uniqueness > guarantee. Sure, MetaTask-Tag for example would be less connoting of uniqueness. But in general, I'd +1 any of the options that aren't suggestive of this being a purely log-oriented thing. Cheers, Eoghan From iheim at redhat.com Mon May 14 16:07:07 2012 From: iheim at redhat.com (Itamar Heim) Date: Mon, 14 May 2012 19:07:07 +0300 Subject: [Engine-devel] REST-API: Exposing correlation-ID In-Reply-To: References: Message-ID: <4FB12DAB.3080902@redhat.com> On 05/14/2012 07:05 PM, Eoghan Glynn wrote: > > >>>> * MetaTask-ID >> >> -1, too pompous? > > Me, pompous? Never! ;) > >> a maybe to remove the "ID" from name, since there is no uniqueness >> guarantee. > > Sure, MetaTask-Tag for example would be less connoting of uniqueness. I like 'Tag' only problem is we have tags in the system already... looking for something in same area - how about just calling this field 'label' > > But in general, I'd +1 any of the options that aren't suggestive of > this being a purely log-oriented thing. > > Cheers, > Eoghan From snmishra at linux.vnet.ibm.com Mon May 14 18:07:38 2012 From: snmishra at linux.vnet.ibm.com (snmishra at linux.vnet.ibm.com) Date: Mon, 14 May 2012 14:07:38 -0400 Subject: [Engine-devel] git-review error. Message-ID: <20120514140738.Horde.NpQLKpir309PsUnqeGx0aWA@imap.linux.ibm.com> Hi, I am trying to push a patch to gerrit for review. $ ./git-review -t nullpointer remote: Resolving deltas: 0% (0/6) To ssh://snmishra at gerrit.ovirt.org:29418/ovirt-engine.git ! [remote rejected] HEAD -> refs/publish/master/nullpointer (prohibited by Gerrit) error: failed to push some refs to 'ssh://snmishra at gerrit.ovirt.org:29418/ovirt-engine.git' I can ssh to gerrit.ovirt.org without password, so that seems to be setup correctly. git-review version is 1.17. I am on 'nullpointer' branch. Thanks in advance for your help. Regards Sharad Mishra From gchaplik at redhat.com Mon May 14 19:58:36 2012 From: gchaplik at redhat.com (Gilad Chaplik) Date: Mon, 14 May 2012 15:58:36 -0400 (EDT) Subject: [Engine-devel] git-review error. In-Reply-To: <20120514140738.Horde.NpQLKpir309PsUnqeGx0aWA@imap.linux.ibm.com> Message-ID: <312d19b3-2c60-4df6-85e7-b24a6d5db0ae@zmail14.collab.prod.int.phx2.redhat.com> Hi Sharad, Take a look at http://www.ovirt.org/wiki/Working_with_oVirt_Gerrit#Push_your_patch_for_review Good luck, Gilad. ----- Original Message ----- > From: snmishra at linux.vnet.ibm.com > To: engine-devel at ovirt.org > Sent: Monday, May 14, 2012 9:07:38 PM > Subject: [Engine-devel] git-review error. > > > Hi, > > I am trying to push a patch to gerrit for review. > > $ ./git-review -t nullpointer > remote: Resolving deltas: 0% (0/6) > To ssh://snmishra at gerrit.ovirt.org:29418/ovirt-engine.git > ! [remote rejected] HEAD -> refs/publish/master/nullpointer > (prohibited by Gerrit) > error: failed to push some refs to > 'ssh://snmishra at gerrit.ovirt.org:29418/ovirt-engine.git' > > > I can ssh to gerrit.ovirt.org without password, so that seems to be > setup correctly. git-review version is 1.17. I am on 'nullpointer' > branch. > > Thanks in advance for your help. > > Regards > Sharad Mishra > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From snmishra at linux.vnet.ibm.com Mon May 14 20:20:32 2012 From: snmishra at linux.vnet.ibm.com (snmishra at linux.vnet.ibm.com) Date: Mon, 14 May 2012 16:20:32 -0400 Subject: [Engine-devel] git-review error. In-Reply-To: <312d19b3-2c60-4df6-85e7-b24a6d5db0ae@zmail14.collab.prod.int.phx2.redhat.com> References: <312d19b3-2c60-4df6-85e7-b24a6d5db0ae@zmail14.collab.prod.int.phx2.redhat.com> Message-ID: <20120514162032.Horde.GPh7xJir309PsWkQ3DJUaZA@imap.linux.ibm.com> Gilad, I followed the same page, section "Submit your topic branch to gerrit". Here is what I did - 1. git clone git://gerrit.ovirt.org/ovirt-engine 2. cd ovirt-engine 3. scp -p gerrit.ovirt.org:hooks/commit-msg .git/hooks/ 4. cp git-review/git-review ovirt-engine/ 5. git-review -s 6. git checkout -b nullpointer 7. git add <> 8. git commit -s 9. git-review -t nullpointer the "remote" portion of my .git/config file looks like - [remote "gerrit"] url = git://gerrit.ovirt.org/ovirt-engine.git pushurl = ssh://snmishra at gerrit.ovirt.org:29418/ovirt-engine.git fetch = +refs/heads/*:refs/remotes/gerrit/* Thanks Sharad Quoting Gilad Chaplik : > Hi Sharad, > > Take a look at > http://www.ovirt.org/wiki/Working_with_oVirt_Gerrit#Push_your_patch_for_review > > Good luck, > Gilad. > > ----- Original Message ----- >> From: snmishra at linux.vnet.ibm.com >> To: engine-devel at ovirt.org >> Sent: Monday, May 14, 2012 9:07:38 PM >> Subject: [Engine-devel] git-review error. >> >> >> Hi, >> >> I am trying to push a patch to gerrit for review. >> >> $ ./git-review -t nullpointer >> remote: Resolving deltas: 0% (0/6) >> To ssh://snmishra at gerrit.ovirt.org:29418/ovirt-engine.git >> ! [remote rejected] HEAD -> refs/publish/master/nullpointer >> (prohibited by Gerrit) >> error: failed to push some refs to >> 'ssh://snmishra at gerrit.ovirt.org:29418/ovirt-engine.git' >> >> >> I can ssh to gerrit.ovirt.org without password, so that seems to be >> setup correctly. git-review version is 1.17. I am on 'nullpointer' >> branch. >> >> Thanks in advance for your help. >> >> Regards >> Sharad Mishra >> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> From hkran at linux.vnet.ibm.com Tue May 15 04:55:19 2012 From: hkran at linux.vnet.ibm.com (hkran at linux.vnet.ibm.com) Date: Tue, 15 May 2012 00:55:19 -0400 Subject: [Engine-devel] add host failed Message-ID: <20120515005519.Horde.MWyPG5ir309PseG3wg1EaZA@imap.linux.ibm.com> Hi, when I add a host to newly setup ovirt-engine,the system told me that install failed What can I do to figure out what is wrong with it? 2012-May-15, 11:51:37 Host mddd installation failed. Please refer to log files for further details.. 2012-May-15, 11:51:37 Failed to install Host mddd. Step: INSTALLER LIB; Details: deployUtil.py download failed. Pathname could not be resolved (verify computer/domain name).. 2012-May-15, 11:51:31 Installing Host mddd. Step: INSTALLER; Details: Test platform succeeded. 2012-May-15, 11:51:14 Installing Host mddd. Step: RHEV_INSTALL; Details: Connected to Host 9.115.118.194 with SSH key fingerprint: e1:bf:2a:93:f4:1e:4c:fe:22:ca:68:5d:36:06:3b:68. 2012-May-15, 11:51:12 Host mddd parameters were updated by admin at internal. 2012-May-15, 11:46:27 User admin at internal logged in. thanks! From ovirt at qip.ru Tue May 15 05:49:07 2012 From: ovirt at qip.ru (ovirt at qip.ru) Date: Tue, 15 May 2012 09:49:07 +0400 Subject: [Engine-devel] =?utf-8?q?add_host_f=C2=ADailed?= In-Reply-To: <20120515005519.Horde.MWyPG5ir309PseG3wg1EaZA@imap.linux.ibm.com> References: <20120515005519.Horde.MWyPG5ir309PseG3wg1EaZA@imap.linux.ibm.com> Message-ID: <80552cceb44ab3be93a304f4da3c31fd5049f490@mail.qip.ru> This is not development but users maillist question but the main phrase is Pathname could not be resolved (verify computer/domain name).. do forward/reverse DNS lookups of vdsm-host and engine from engine and do forward/reverse DNS lookups of engine from vdsm-host ??? 15 ??? 2012 08:55:27 +0400, hkran at linux.vnet.ibm.com ???????: Hi, when I add a host to newly setup ovirt-engine,the system told me that install failed What can I do to figure out what is wrong with it? 2012-May-15, 11:51:37 Host mddd installation failed. Please refer to log files for further details.. 2012-May-15, 11:51:37 Failed to install Host mddd. Step: INSTALLER LIB; Details: deployUtil.py download failed. Pathname could not be resolved (verify computer/domain name).. 2012-May-15, 11:51:31 Installing Host mddd. Step: INSTALLER; Details: Test platform succeeded. 2012-May-15, 11:51:14 Installing Host mddd. Step: RHEV_INSTALL; Details: Connected to Host 9.115.118.194 with SSH key fingerprint: e1:bf:2a:93:f4:1e:4c:fe:22:ca:68:5d:36:06:3b:68. 2012-May-15, 11:51:12 Host mddd parameters were updated by admin at internal. 2012-May-15, 11:46:27 User admin at internal logged in. thanks! _______________________________________________ Engine-devel mailing list Engine-devel at ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From amureini at redhat.com Tue May 15 06:05:54 2012 From: amureini at redhat.com (Allon Mureinik) Date: Tue, 15 May 2012 02:05:54 -0400 (EDT) Subject: [Engine-devel] git-review error. In-Reply-To: <20120514140738.Horde.NpQLKpir309PsUnqeGx0aWA@imap.linux.ibm.com> Message-ID: Hi Sharad, I'm not too big on git-review, but AFAIK -t is used to supply a topic (see https://github.com/openstack-ci/git-review#readme). can you try with an explicit notation refs/for/master/nullpointer ? -Allon ----- Original Message ----- > From: snmishra at linux.vnet.ibm.com > To: engine-devel at ovirt.org > Sent: Monday, May 14, 2012 9:07:38 PM > Subject: [Engine-devel] git-review error. > > > Hi, > > I am trying to push a patch to gerrit for review. > > $ ./git-review -t nullpointer > remote: Resolving deltas: 0% (0/6) > To ssh://snmishra at gerrit.ovirt.org:29418/ovirt-engine.git > ! [remote rejected] HEAD -> refs/publish/master/nullpointer > (prohibited by Gerrit) > error: failed to push some refs to > 'ssh://snmishra at gerrit.ovirt.org:29418/ovirt-engine.git' > > > I can ssh to gerrit.ovirt.org without password, so that seems to be > setup correctly. git-review version is 1.17. I am on 'nullpointer' > branch. > > Thanks in advance for your help. > > Regards > Sharad Mishra > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From rgolan at redhat.com Tue May 15 09:13:52 2012 From: rgolan at redhat.com (Roy Golan) Date: Tue, 15 May 2012 12:13:52 +0300 Subject: [Engine-devel] git-review error. In-Reply-To: <20120514140738.Horde.NpQLKpir309PsUnqeGx0aWA@imap.linux.ibm.com> References: <20120514140738.Horde.NpQLKpir309PsUnqeGx0aWA@imap.linux.ibm.com> Message-ID: <4FB21E50.9090200@redhat.com> On 05/14/2012 09:07 PM, snmishra at linux.vnet.ibm.com wrote: > > Hi, > > I am trying to push a patch to gerrit for review. > > $ ./git-review -t nullpointer > remote: Resolving deltas: 0% (0/6) > To ssh://snmishra at gerrit.ovirt.org:29418/ovirt-engine.git > ! [remote rejected] HEAD -> refs/publish/master/nullpointer > (prohibited by Gerrit) we're not allowed to push to refs/pulish switch it to refs/for/master/nullpointer > error: failed to push some refs to > 'ssh://snmishra at gerrit.ovirt.org:29418/ovirt-engine.git' > > > I can ssh to gerrit.ovirt.org without password, so that seems to be > setup correctly. git-review version is 1.17. I am on 'nullpointer' > branch. > > Thanks in advance for your help. > > Regards > Sharad Mishra > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From iheim at redhat.com Tue May 15 10:38:42 2012 From: iheim at redhat.com (Itamar Heim) Date: Tue, 15 May 2012 13:38:42 +0300 Subject: [Engine-devel] [Users] oVirt and Quantum In-Reply-To: <4F9D1AD4.8070503@redhat.com> References: <4F9D1AD4.8070503@redhat.com> Message-ID: <4FB23232.7090008@redhat.com> On 04/29/2012 01:41 PM, Gary Kotton wrote: > Hi, > > As part of a POC we have integrated Quantum > (http://wiki.openstack.org/Quantum) into oVirt (http://www.ovirt.org/). > This has been tested with the OVS and Linux Bridge plugins. > The details of the integration can be found at - > https://fedoraproject.org/wiki/Quantum_and_oVirt. > Any comments and suggestions would be greatly appreciated. > Thanks > Gary Thanks Gary - some questions: 1. you are using the term 'user' for both an end-user and an admin. I think admin is more appropriate in most places. 2. host management --> interface 2.1 you are suggesting to remove the vlan field with a fabric field? are we sure this is something which shouldn't be presented in the main view and only via extended properties? 2.2 is the fabric really a host interface level property, or a cluster wide property (would same logical network be implemented on different hosts in the cluster via both vdsm and quantum)? would live migration work in same cluster if one host has qunatum fabric and another vdsm fabric for same logical network? 2.3 you are describing the subtab of an interface, and mention a qunatum pull down menu. is this in the subtab? in a dialog? UI mockups are needed here. 2.4 also, is this pulldown correct at host level or cluster level (would live migration work between hosts implementing different plugins for same logical network in same cluster?) on to backend: 3.1 "The Quantum Service is a process that runs the Quantum API web server (port 9696)" how is authentication between engine and quantum service is done (we have a client certificate for engine which qunatum can verify i guess) 3.2 is there a config of the quantum service uri? should it be a single instance or a per DC property? (it sounds like a per DC property, can be a future thing) 3.3 network creation semantics: we create a network at DC level. we attach it at cluster level. the UI allows you to "create at DC and attach to cluster" at cluster level. 3.3.1 what if i create a network with same VLAN in two DC's? what if we attach same logical network to multiple clusters - each will create the logical network in qunatum again? 3.3.2 what if the qunatum service is down when engine performs this action or quantum returns an error? 3.3.3 each creation of a DC creates a rhevm network - I assume these are not created, since "no host in a cluster in the DC yet"? 3.3.4 what happens on moving of a host to another cluster, or moving of a cluster to another DC (possible if it's DC was removed iirc). 3.3.5 shouldn't this be limited to vm networks, or all networks are relevant? 3.3.6 what if the host with the qunatum fabric is in maint mode? 3.3.7 could a host with qunatum fabric have a VDSM fabric on another interface (for vm neworks? for non-vm networks)? 3.5 network deletion (detach network from a cluster) 3.5.1 what happens if qunatum is down or returned an error? 3.6 vm creation 3.6.1 what about moving a VM from/to a cluster with a quantum fabric? 3.6.2 what about import of a VM into a cluster with a qunatum fabric? 3.6.3 you have vm creation/removal - missing vnic addition/removal 3.6.4 worth mentioning qunatum doesn't care about the vnic model? about the mac address? 3.7 vm start 3.7.1 why is the plugin parameter required at vm start? can multiple plugins be supported in parallel at vdsm/host level or by the quantum service? 3.7.2 aren't network_uuid and port uuid redundant to attachment uuid (I assume qunatum service knows from attachment the port and network) - i have no objection to passing them to vdsm, just trying to understand reasoning for this. I am missing what happens at vdsm level in this point (even after reading the matching vdsm part) 3.8 vm suspend/resume (it's fine to say it behaves like X, but still need to be covered to not cause bugs/regressions) 3.9 vm stop 3.9.1 need to make sure vm stop when engine is down is handled correctly. 3.9.2 what happens if qunatum service is down? unlike start vm or network creation the operation in this case cannot be stopped/rolledback, only rolled forward. 3.10 hot plug nic? 3.11 vm migration 3.11.1 ok, so this is the first time i understand hosts can be mixed in same cluster. worth specifying this in the beginning (still not clear if mixed plugins can exist) 3.11.2 afair, we don't deal with engine talking to both hosts during live migration. only to host A, who is then communicating with host B. so why not always have the VM configuration at vm start (and hot plug nic) have the quantum details so live migration can occur at will without additional information? 3.11.3 "In order to implement the above a REST client needs to be implemented in the oVirt engine. " did not understand this statement - please elaborate. 4. host management 4.1 deployment we do not deploy packages from engine to hosts, we can install them from a repo configured to the host. but this is done today only as part of initial bootstrap/installation of host. also, it is not relevant for ovirt node which is 'firmware' like. any reason to not require the 'plugin installation packages' at vdsm rpm level for plugins we think are good enough to use (until then, responsibility to deploy them is of admin) (what are plugin level packages at host level - aren't these the agents?) 4.2 plugin configuration per DC? per cluster? per host? per plugin? please provide more details here on configuration details expected and flow of when they are configured and when they are expected to change? I think this will merit a per 'ovirt supported' qunatum plugin to see it works in a way we can use. 4.3 connectivity again, this requires more details. if needed per plugin. what is expected? how authentication/encryption happens? what iptables rules need to change in engine/host if at all, etc. I'm fine with this being 'direct access to db from hosts' for POC level of patches, but not for something we actually merge/provide support for later. 5. VDSM 5.1 s/The agent packe/The agent package/ ? 5.2 "The agent package can and may be received from the oVirt Engine or can be downloaded via RPM's" see 4.1 above - we don't deploy rpm's/code on the fly today. 5.3 "n addition to the treatment below VDSM should also maintain a health check to the Quantum agent" what if the restart didn't help? how should ovirt treat the host wrt networking? to running VMs? to ability to live migrate VMs from the host if needed? 5.4 "Logical Network Management" please see 3.11 above - we would want live migration to not require additional information, so details should be available even if not immediately acted upon. 5.5 "The tap device created uses an "ethernet" network device. This means that the creation of the libvirt XML file is a bit different." 5.5.1 does this impact stable device addresses somehow? 5.5.2 how is live migration possible if the libvirt xml to a non quantum host is different (or is this the binding part only)? 5.6 I assume libvirtvm.py is part of vdsm. is quantum.py part of quantum code base or vdsm codebase (it sounds like it should be part of quantum code base)? so how exactly the rpm for this would look like? deploy it to /xxx/qunatum and have it add a symbolic link to it from vdsm paths? 5.7 "When a communication channel is established between VDSM and the oVirt engine. The VDSM host should notify the oVirt Engine of the Quantum fabric that is supported." how does vdsm goes about detecting an agent is installed exactly? (especially since deployment wise, most likely is all agents would be deployed via rpm requirements?) is any agent a service at host level rather than code only? is there a scenario where a vdsm level plugin isn't required? 6. open issues 6.1 worth mentioning if any are in the works 6.2 specifying the vlan from ovirt engine is not a gap? 6.3 ok, so this is the first time "no multiple plugins" is mentioned ("Non-uniform technology"). but it sounds like the approach in the wiki assume it is/will be possible to have multiple technologies (agents/plugins) going forward? 6.4 need to discuss which of the open issues should block going forward with merging of code, and expected timeframe for resolution of some of them 7. other questions/items (some mentioned above as well) 7.1 please add ui mockups, db scheme changes and REST api changes 7.2 i'm missing the deployment flow: - user install engine. is quantum a separate install or bundled going forward? - any configuration items by user at this point? what are they? - what rpms are deployed at host level? what configuration do they need - communication channels and their security are a must to understand 7.3 upgrade path / compatibility levels this is relevant to? 7.4 monitoring flow - how is monitoring/state of a host is affected by quantum service being down, communication problem from host to (where actually?) From iheim at redhat.com Tue May 15 10:44:39 2012 From: iheim at redhat.com (Itamar Heim) Date: Tue, 15 May 2012 13:44:39 +0300 Subject: [Engine-devel] oVirt and Quantum In-Reply-To: <4FA27790.5080308@redhat.com> References: <4F9D1AD4.8070503@redhat.com> <4F9E41AE.6030302@redhat.com> <4F9E7DB1.1010409@redhat.com> <9D25E123B44F4A4291F4B5C13DA94E772510FFEA@mtrdag02.mtl.com> <4FA27790.5080308@redhat.com> Message-ID: <4FB23397.50102@redhat.com> On 05/03/2012 03:18 PM, Gary Kotton wrote: > Hi, > Thanks for the input. Please see my inline comments. > Thanks > Gary > > On 05/03/2012 12:02 PM, Irena Berezovsky wrote: >> Gary, >> Thank you for a very detailed proposal. >> I would like to address several issues of the proposed Quantum-oVirt >> integration. >> >> 1. User Interface: >> Network Management >> I suggest to consider Logical Network Management to indicate if the >> Network should be managed by Quantum or not. This may lead to >> different options that user can specify via UI. It can have a Network >> Type attribute. Maybe it is a place to consider custom properties >> piggy-backing. > This is an interesting point. I am not sure that the user should be > exposed to this. My intentions when writing the integration notes were > to try and keep things simple for the user. There are a number of options: > - Uniform cluster support - If the UI for the cluster could provide an > interface for the network properties then it would be great. If each > Host in the cluster has the same characteristics then one configuration > could be used for each host - for example the NIC of the integration > bridge in the case of OVS plugin. > - Non uniform cluster support - in this case each Host will need to be > configured separately. Live migration could be challenging - this can > and should be done only between hosts with the same networking > characteristics. at least today, a cluster best definition is a live migration domain. so if live migration is not supported between different plugins or with/without qunatum - definition of plugin should be at cluster level and required from all hosts. >> Host management >> As long as the proposed API is used for viewing interface it's OK. It >> just should not be required by user to go over each Host and define >> each interface with type of Fabric he should manage. Maybe it should >> be some defaults on Cluster level (will work for Homogenous cluster). > Addressed above. >> >> 2. Back End >> Network Creation: >> If not every Host in the cluster has Quantum supporting interface, it >> should be forbidden to apply VM migrate operation to such Host. This >> probably should be indicated properly via UI and Backed should not >> start the migrate process. > I also think that this is addressed above. >> VM Creation: >> To be able to extend the basic Quantum API and add some QoS/Port >> Profile attributes to the port ( like in Cisco plugin). There should >> be some way in oVirt to map between port uuid (+ network)and VM id. > This is addressed in the wiki. For each VM the oVirt engine should keep > the relevant UUID's. > "Each of the above is represented by a UUID. oVirt should save all of > the UUID's with the relevant artifacts that make use of the information, > namely the logical network and the virtual machines. The usage of these > will be discussed below." > I could describe this more explicitly. ovirt engine keeps it. how would one query by it though? what api and credentials would they be using to do so? >> VM Migrate: >> Even though it's just an initial suggestion, I think that VM migration >> use case should be elaborated also for 'else' cases. What happens if >> target Host does not support Quantum? What happens if target host >> fails to run VM? Another issue is a lack of calls to Quantum. For my >> understanding (but I can be wrong) in OpenStack it will issue unplug >> and plug attachment calls. > I agree. The goal here should be VM uptime and connectivity. If the > "network" connectivity can be support but in a limited fashion then > great - the migration can take place - this should nonetheless only be > done when there is no other option. The live migration algorithm may > have to be tweaked to support this. we do not assume involvement in engine in live migration today other than issuing a 'migrate' command to source host, or host needing information from engine to perform the live migration. there must be a very good reason to break this assumption. >> 3. VDSM >> Host Management: Any suggestion /plans to define a way to write and >> deploy a Vif plug Driver ( a complimentary part to the Quantum Agent)? > In Quantum the spirit of things is to keep the driver as thin as > possible. The Quantum agent that runs on the VDSM host should do most of > the work. It would be best if VDSM could provide a "plugin" mechanism > that support the following: > 1. deviceNameGet - this is due to the fact that the agent knows the > device name - in the case of ovs and linux bridge this is done by using > the first 11 characters of the attachment UUID. Other plugins may > operate in a different manner. > 2. vifAdd - this will be called with the MAC address, the VM UUID and > maybe additional information > 3. vifDelete > >> Regards, >> Irena >> -----Original Message----- >> From: engine-devel-bounces at ovirt.org >> [mailto:engine-devel-bounces at ovirt.org] On Behalf Of Gary Kotton >> Sent: Monday, April 30, 2012 2:56 PM >> To: dlaor at redhat.com >> Cc: engine-devel at ovirt.org; users at ovirt.org >> Subject: Re: [Engine-devel] oVirt and Quantum >> >> On 04/30/2012 10:39 AM, Dor Laor wrote: >>> Gary, would it be possible to compare the current major api verbs >>> offered by Quantum vs the ones offered by oVirt? >> Please look at >> https://docs.google.com/presentation/d/1cLW88tPw-8z_ANXU2WC8gd4U2k-ACrPnMQbgj5wDLz4/edit#slide=id.p >> >> This gives a high level explanation of Quantum and the flows. In short >> both Quantum and oVirt enable the creation of logical networks. By >> design Quantum hides the network details from the user. In oVirt the >> user is able to configure the tags etc. We are in the process of >> addressing this. >> >>> It would be nice to review the length/feature-rich of each and also >>> the ease of use. >> In addition to linux bridge (which is what oVirt uses today), Quantum >> supports Open vSwitch, RYU and Cisco UCS - these are not supported by >> oVirt at the moment. The RYU and Open vSwitch support OpenFlow >>> In addition, what would be the todo items in order to get OVS working >>> w/ oVirt? >> Actually not much. In fact this is currently supported with the >> Quantum integration. There are two parts: >> 1. The VM vNic management (implemented): >> i. Create a tap device that has "ethernet" as the the network device >> ii. Set the device us UP >> ii. Attach to the integration bridge and configure tags etc. (The >> Quantum agent does this part) >> >> 2. The host management (to be implemented): >> i. oVirt Engine and VDSM need to indicate which physical network >> interfaces will use the integration bridge. This can be one or more >> NICS or a bond (in Quantum this is part of a configuration file). We >> need to think of a nice way to show this in the GUI. >> ii. The logic in oVirt engine that "decides" if a Host is "Non >> Operational" needs to be updated. >>> Example for Quantum: >>> http://docs.openstack.org/incubation/openstack-network/developer/quant >>> um-api-1.0/content/Show_port_Details.html#d6e777 >>> >>> Cheers, >>> Dor >>> >>>> >>>> _______________________________________________ >>>> Engine-devel mailing list >>>> Engine-devel at ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From irenab at mellanox.com Tue May 15 11:34:58 2012 From: irenab at mellanox.com (Irena Berezovsky) Date: Tue, 15 May 2012 11:34:58 +0000 Subject: [Engine-devel] oVirt and Quantum In-Reply-To: <4FB23397.50102@redhat.com> References: <4F9D1AD4.8070503@redhat.com> <4F9E41AE.6030302@redhat.com> <4F9E7DB1.1010409@redhat.com> <9D25E123B44F4A4291F4B5C13DA94E772510FFEA@mtrdag02.mtl.com> <4FA27790.5080308@redhat.com> <4FB23397.50102@redhat.com> Message-ID: <9D25E123B44F4A4291F4B5C13DA94E772511530B@mtrdag02.mtl.com> Please see my comments inline -----Original Message----- From: Itamar Heim [mailto:iheim at redhat.com] Sent: Tuesday, May 15, 2012 1:45 PM To: gkotton at redhat.com Cc: Irena Berezovsky; engine-devel at ovirt.org Subject: Re: [Engine-devel] oVirt and Quantum On 05/03/2012 03:18 PM, Gary Kotton wrote: > Hi, > Thanks for the input. Please see my inline comments. > Thanks > Gary > > On 05/03/2012 12:02 PM, Irena Berezovsky wrote: >> Gary, >> Thank you for a very detailed proposal. >> I would like to address several issues of the proposed Quantum-oVirt >> integration. >> >> 1. User Interface: >> Network Management >> I suggest to consider Logical Network Management to indicate if the >> Network should be managed by Quantum or not. This may lead to >> different options that user can specify via UI. It can have a Network >> Type attribute. Maybe it is a place to consider custom properties >> piggy-backing. > This is an interesting point. I am not sure that the user should be > exposed to this. My intentions when writing the integration notes were > to try and keep things simple for the user. There are a number of options: > - Uniform cluster support - If the UI for the cluster could provide an > interface for the network properties then it would be great. If each > Host in the cluster has the same characteristics then one > configuration could be used for each host - for example the NIC of the > integration bridge in the case of OVS plugin. > - Non uniform cluster support - in this case each Host will need to be > configured separately. Live migration could be challenging - this can > and should be done only between hosts with the same networking > characteristics. at least today, a cluster best definition is a live migration domain. so if live migration is not supported between different plugins or with/without qunatum - definition of plugin should be at cluster level and required from all hosts. >> Host management >> As long as the proposed API is used for viewing interface it's OK. It >> just should not be required by user to go over each Host and define >> each interface with type of Fabric he should manage. Maybe it should >> be some defaults on Cluster level (will work for Homogenous cluster). > Addressed above. >> >> 2. Back End >> Network Creation: >> If not every Host in the cluster has Quantum supporting interface, it >> should be forbidden to apply VM migrate operation to such Host. This >> probably should be indicated properly via UI and Backed should not >> start the migrate process. > I also think that this is addressed above. >> VM Creation: >> To be able to extend the basic Quantum API and add some QoS/Port >> Profile attributes to the port ( like in Cisco plugin). There should >> be some way in oVirt to map between port uuid (+ network)and VM id. > This is addressed in the wiki. For each VM the oVirt engine should > keep the relevant UUID's. > "Each of the above is represented by a UUID. oVirt should save all of > the UUID's with the relevant artifacts that make use of the > information, namely the logical network and the virtual machines. The > usage of these will be discussed below." > I could describe this more explicitly. ovirt engine keeps it. how would one query by it though? what api and credentials would they be using to do so? [IB] I think it should be accessible via REST and SDK . I guess it should use admin credentials, but not sure. >> VM Migrate: >> Even though it's just an initial suggestion, I think that VM >> migration use case should be elaborated also for 'else' cases. What >> happens if target Host does not support Quantum? What happens if >> target host fails to run VM? Another issue is a lack of calls to >> Quantum. For my understanding (but I can be wrong) in OpenStack it >> will issue unplug and plug attachment calls. > I agree. The goal here should be VM uptime and connectivity. If the > "network" connectivity can be support but in a limited fashion then > great - the migration can take place - this should nonetheless only be > done when there is no other option. The live migration algorithm may > have to be tweaked to support this. we do not assume involvement in engine in live migration today other than issuing a 'migrate' command to source host, or host needing information from engine to perform the live migration. there must be a very good reason to break this assumption. [IB] If this assumption should be in place, maybe it worth to consider to invoke 'create port' and 'plug interface' Quantum calls from VDSM node and not from oVirt engine. This this the model in OpenStack. Nova-compute invokes 'create port' and 'plug interface' Quantum calls. It is described in the following doc: http://wiki.openstack.org/QuantumAPIUseCases >> 3. VDSM >> Host Management: Any suggestion /plans to define a way to write and >> deploy a Vif plug Driver ( a complimentary part to the Quantum Agent)? > In Quantum the spirit of things is to keep the driver as thin as > possible. The Quantum agent that runs on the VDSM host should do most > of the work. It would be best if VDSM could provide a "plugin" > mechanism that support the following: > 1. deviceNameGet - this is due to the fact that the agent knows the > device name - in the case of ovs and linux bridge this is done by > using the first 11 characters of the attachment UUID. Other plugins > may operate in a different manner. > 2. vifAdd - this will be called with the MAC address, the VM UUID and > maybe additional information 3. vifDelete > >> Regards, >> Irena >> -----Original Message----- >> From: engine-devel-bounces at ovirt.org >> [mailto:engine-devel-bounces at ovirt.org] On Behalf Of Gary Kotton >> Sent: Monday, April 30, 2012 2:56 PM >> To: dlaor at redhat.com >> Cc: engine-devel at ovirt.org; users at ovirt.org >> Subject: Re: [Engine-devel] oVirt and Quantum >> >> On 04/30/2012 10:39 AM, Dor Laor wrote: >>> Gary, would it be possible to compare the current major api verbs >>> offered by Quantum vs the ones offered by oVirt? >> Please look at >> https://docs.google.com/presentation/d/1cLW88tPw-8z_ANXU2WC8gd4U2k-AC >> rPnMQbgj5wDLz4/edit#slide=id.p >> >> This gives a high level explanation of Quantum and the flows. In >> short both Quantum and oVirt enable the creation of logical networks. >> By design Quantum hides the network details from the user. In oVirt >> the user is able to configure the tags etc. We are in the process of >> addressing this. >> >>> It would be nice to review the length/feature-rich of each and also >>> the ease of use. >> In addition to linux bridge (which is what oVirt uses today), Quantum >> supports Open vSwitch, RYU and Cisco UCS - these are not supported by >> oVirt at the moment. The RYU and Open vSwitch support OpenFlow >>> In addition, what would be the todo items in order to get OVS >>> working w/ oVirt? >> Actually not much. In fact this is currently supported with the >> Quantum integration. There are two parts: >> 1. The VM vNic management (implemented): >> i. Create a tap device that has "ethernet" as the the network device >> ii. Set the device us UP ii. Attach to the integration bridge and >> configure tags etc. (The Quantum agent does this part) >> >> 2. The host management (to be implemented): >> i. oVirt Engine and VDSM need to indicate which physical network >> interfaces will use the integration bridge. This can be one or more >> NICS or a bond (in Quantum this is part of a configuration file). We >> need to think of a nice way to show this in the GUI. >> ii. The logic in oVirt engine that "decides" if a Host is "Non >> Operational" needs to be updated. >>> Example for Quantum: >>> http://docs.openstack.org/incubation/openstack-network/developer/qua >>> nt >>> um-api-1.0/content/Show_port_Details.html#d6e777 >>> >>> Cheers, >>> Dor >>> >>>> >>>> _______________________________________________ >>>> Engine-devel mailing list >>>> Engine-devel at ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From iheim at redhat.com Tue May 15 11:39:18 2012 From: iheim at redhat.com (Itamar Heim) Date: Tue, 15 May 2012 14:39:18 +0300 Subject: [Engine-devel] oVirt and Quantum In-Reply-To: <9D25E123B44F4A4291F4B5C13DA94E772511530B@mtrdag02.mtl.com> References: <4F9D1AD4.8070503@redhat.com> <4F9E41AE.6030302@redhat.com> <4F9E7DB1.1010409@redhat.com> <9D25E123B44F4A4291F4B5C13DA94E772510FFEA@mtrdag02.mtl.com> <4FA27790.5080308@redhat.com> <4FB23397.50102@redhat.com> <9D25E123B44F4A4291F4B5C13DA94E772511530B@mtrdag02.mtl.com> Message-ID: <4FB24066.70009@redhat.com> On 05/15/2012 02:34 PM, Irena Berezovsky wrote: > Please see my comments inline > > -----Original Message----- > From: Itamar Heim [mailto:iheim at redhat.com] > Sent: Tuesday, May 15, 2012 1:45 PM > To: gkotton at redhat.com > Cc: Irena Berezovsky; engine-devel at ovirt.org > Subject: Re: [Engine-devel] oVirt and Quantum > > On 05/03/2012 03:18 PM, Gary Kotton wrote: >> Hi, >> Thanks for the input. Please see my inline comments. >> Thanks >> Gary >> >> On 05/03/2012 12:02 PM, Irena Berezovsky wrote: >>> Gary, >>> Thank you for a very detailed proposal. >>> I would like to address several issues of the proposed Quantum-oVirt >>> integration. >>> >>> 1. User Interface: >>> Network Management >>> I suggest to consider Logical Network Management to indicate if the >>> Network should be managed by Quantum or not. This may lead to >>> different options that user can specify via UI. It can have a Network >>> Type attribute. Maybe it is a place to consider custom properties >>> piggy-backing. >> This is an interesting point. I am not sure that the user should be >> exposed to this. My intentions when writing the integration notes were >> to try and keep things simple for the user. There are a number of options: >> - Uniform cluster support - If the UI for the cluster could provide an >> interface for the network properties then it would be great. If each >> Host in the cluster has the same characteristics then one >> configuration could be used for each host - for example the NIC of the >> integration bridge in the case of OVS plugin. >> - Non uniform cluster support - in this case each Host will need to be >> configured separately. Live migration could be challenging - this can >> and should be done only between hosts with the same networking >> characteristics. > > at least today, a cluster best definition is a live migration domain. so if live migration is not supported between different plugins or with/without qunatum - definition of plugin should be at cluster level and required from all hosts. > >>> Host management >>> As long as the proposed API is used for viewing interface it's OK. It >>> just should not be required by user to go over each Host and define >>> each interface with type of Fabric he should manage. Maybe it should >>> be some defaults on Cluster level (will work for Homogenous cluster). >> Addressed above. >>> >>> 2. Back End >>> Network Creation: >>> If not every Host in the cluster has Quantum supporting interface, it >>> should be forbidden to apply VM migrate operation to such Host. This >>> probably should be indicated properly via UI and Backed should not >>> start the migrate process. >> I also think that this is addressed above. >>> VM Creation: >>> To be able to extend the basic Quantum API and add some QoS/Port >>> Profile attributes to the port ( like in Cisco plugin). There should >>> be some way in oVirt to map between port uuid (+ network)and VM id. >> This is addressed in the wiki. For each VM the oVirt engine should >> keep the relevant UUID's. >> "Each of the above is represented by a UUID. oVirt should save all of >> the UUID's with the relevant artifacts that make use of the >> information, namely the logical network and the virtual machines. The >> usage of these will be discussed below." >> I could describe this more explicitly. > > ovirt engine keeps it. how would one query by it though? what api and credentials would they be using to do so? > [IB] I think it should be accessible via REST and SDK . > I guess it should use admin credentials, but not sure. REST doesn't support lookup by every property and the is search for vnics/ports. so a modeling question. I'm not sure i like the concept of providing an administrative user credentials to all hosts, or of managing a password change in this case. not sure hosts should use the REST API, or another API intended for bi-directional communication with engine, secured in the same way the xml/rpc is secured. > >>> VM Migrate: >>> Even though it's just an initial suggestion, I think that VM >>> migration use case should be elaborated also for 'else' cases. What >>> happens if target Host does not support Quantum? What happens if >>> target host fails to run VM? Another issue is a lack of calls to >>> Quantum. For my understanding (but I can be wrong) in OpenStack it >>> will issue unplug and plug attachment calls. >> I agree. The goal here should be VM uptime and connectivity. If the >> "network" connectivity can be support but in a limited fashion then >> great - the migration can take place - this should nonetheless only be >> done when there is no other option. The live migration algorithm may >> have to be tweaked to support this. > > we do not assume involvement in engine in live migration today other than issuing a 'migrate' command to source host, or host needing information from engine to perform the live migration. > there must be a very good reason to break this assumption. > [IB] If this assumption should be in place, maybe it worth to consider to invoke 'create port' and 'plug interface' Quantum calls from VDSM node and not from oVirt engine. This this the model in OpenStack. Nova-compute invokes 'create port' and 'plug interface' Quantum calls. > It is described in the following doc: > http://wiki.openstack.org/QuantumAPIUseCases I'm not sure i like that better. would it be possible for engine to pre-provision the port on more than one host? > > >>> 3. VDSM >>> Host Management: Any suggestion /plans to define a way to write and >>> deploy a Vif plug Driver ( a complimentary part to the Quantum Agent)? >> In Quantum the spirit of things is to keep the driver as thin as >> possible. The Quantum agent that runs on the VDSM host should do most >> of the work. It would be best if VDSM could provide a "plugin" >> mechanism that support the following: >> 1. deviceNameGet - this is due to the fact that the agent knows the >> device name - in the case of ovs and linux bridge this is done by >> using the first 11 characters of the attachment UUID. Other plugins >> may operate in a different manner. >> 2. vifAdd - this will be called with the MAC address, the VM UUID and >> maybe additional information 3. vifDelete >> >>> Regards, >>> Irena >>> -----Original Message----- >>> From: engine-devel-bounces at ovirt.org >>> [mailto:engine-devel-bounces at ovirt.org] On Behalf Of Gary Kotton >>> Sent: Monday, April 30, 2012 2:56 PM >>> To: dlaor at redhat.com >>> Cc: engine-devel at ovirt.org; users at ovirt.org >>> Subject: Re: [Engine-devel] oVirt and Quantum >>> >>> On 04/30/2012 10:39 AM, Dor Laor wrote: >>>> Gary, would it be possible to compare the current major api verbs >>>> offered by Quantum vs the ones offered by oVirt? >>> Please look at >>> https://docs.google.com/presentation/d/1cLW88tPw-8z_ANXU2WC8gd4U2k-AC >>> rPnMQbgj5wDLz4/edit#slide=id.p >>> >>> This gives a high level explanation of Quantum and the flows. In >>> short both Quantum and oVirt enable the creation of logical networks. >>> By design Quantum hides the network details from the user. In oVirt >>> the user is able to configure the tags etc. We are in the process of >>> addressing this. >>> >>>> It would be nice to review the length/feature-rich of each and also >>>> the ease of use. >>> In addition to linux bridge (which is what oVirt uses today), Quantum >>> supports Open vSwitch, RYU and Cisco UCS - these are not supported by >>> oVirt at the moment. The RYU and Open vSwitch support OpenFlow >>>> In addition, what would be the todo items in order to get OVS >>>> working w/ oVirt? >>> Actually not much. In fact this is currently supported with the >>> Quantum integration. There are two parts: >>> 1. The VM vNic management (implemented): >>> i. Create a tap device that has "ethernet" as the the network device >>> ii. Set the device us UP ii. Attach to the integration bridge and >>> configure tags etc. (The Quantum agent does this part) >>> >>> 2. The host management (to be implemented): >>> i. oVirt Engine and VDSM need to indicate which physical network >>> interfaces will use the integration bridge. This can be one or more >>> NICS or a bond (in Quantum this is part of a configuration file). We >>> need to think of a nice way to show this in the GUI. >>> ii. The logic in oVirt engine that "decides" if a Host is "Non >>> Operational" needs to be updated. >>>> Example for Quantum: >>>> http://docs.openstack.org/incubation/openstack-network/developer/qua >>>> nt >>>> um-api-1.0/content/Show_port_Details.html#d6e777 >>>> >>>> Cheers, >>>> Dor >>>> >>>>> >>>>> _______________________________________________ >>>>> Engine-devel mailing list >>>>> Engine-devel at ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel at ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel > From irenab at mellanox.com Tue May 15 11:55:00 2012 From: irenab at mellanox.com (Irena Berezovsky) Date: Tue, 15 May 2012 11:55:00 +0000 Subject: [Engine-devel] oVirt and Quantum In-Reply-To: <4FB24066.70009@redhat.com> References: <4F9D1AD4.8070503@redhat.com> <4F9E41AE.6030302@redhat.com> <4F9E7DB1.1010409@redhat.com> <9D25E123B44F4A4291F4B5C13DA94E772510FFEA@mtrdag02.mtl.com> <4FA27790.5080308@redhat.com> <4FB23397.50102@redhat.com> <9D25E123B44F4A4291F4B5C13DA94E772511530B@mtrdag02.mtl.com> <4FB24066.70009@redhat.com> Message-ID: <9D25E123B44F4A4291F4B5C13DA94E7725115351@mtrdag02.mtl.com> -----Original Message----- From: Itamar Heim [mailto:iheim at redhat.com] Sent: Tuesday, May 15, 2012 2:39 PM To: Irena Berezovsky Cc: gkotton at redhat.com; engine-devel at ovirt.org Subject: Re: [Engine-devel] oVirt and Quantum On 05/15/2012 02:34 PM, Irena Berezovsky wrote: > Please see my comments inline > > -----Original Message----- > From: Itamar Heim [mailto:iheim at redhat.com] > Sent: Tuesday, May 15, 2012 1:45 PM > To: gkotton at redhat.com > Cc: Irena Berezovsky; engine-devel at ovirt.org > Subject: Re: [Engine-devel] oVirt and Quantum > > On 05/03/2012 03:18 PM, Gary Kotton wrote: >> Hi, >> Thanks for the input. Please see my inline comments. >> Thanks >> Gary >> >> On 05/03/2012 12:02 PM, Irena Berezovsky wrote: >>> Gary, >>> Thank you for a very detailed proposal. >>> I would like to address several issues of the proposed Quantum-oVirt >>> integration. >>> >>> 1. User Interface: >>> Network Management >>> I suggest to consider Logical Network Management to indicate if the >>> Network should be managed by Quantum or not. This may lead to >>> different options that user can specify via UI. It can have a >>> Network Type attribute. Maybe it is a place to consider custom >>> properties piggy-backing. >> This is an interesting point. I am not sure that the user should be >> exposed to this. My intentions when writing the integration notes >> were to try and keep things simple for the user. There are a number of options: >> - Uniform cluster support - If the UI for the cluster could provide >> an interface for the network properties then it would be great. If >> each Host in the cluster has the same characteristics then one >> configuration could be used for each host - for example the NIC of >> the integration bridge in the case of OVS plugin. >> - Non uniform cluster support - in this case each Host will need to >> be configured separately. Live migration could be challenging - this >> can and should be done only between hosts with the same networking >> characteristics. > > at least today, a cluster best definition is a live migration domain. so if live migration is not supported between different plugins or with/without qunatum - definition of plugin should be at cluster level and required from all hosts. > >>> Host management >>> As long as the proposed API is used for viewing interface it's OK. >>> It just should not be required by user to go over each Host and >>> define each interface with type of Fabric he should manage. Maybe it >>> should be some defaults on Cluster level (will work for Homogenous cluster). >> Addressed above. >>> >>> 2. Back End >>> Network Creation: >>> If not every Host in the cluster has Quantum supporting interface, >>> it should be forbidden to apply VM migrate operation to such Host. >>> This probably should be indicated properly via UI and Backed should >>> not start the migrate process. >> I also think that this is addressed above. >>> VM Creation: >>> To be able to extend the basic Quantum API and add some QoS/Port >>> Profile attributes to the port ( like in Cisco plugin). There should >>> be some way in oVirt to map between port uuid (+ network)and VM id. >> This is addressed in the wiki. For each VM the oVirt engine should >> keep the relevant UUID's. >> "Each of the above is represented by a UUID. oVirt should save all of >> the UUID's with the relevant artifacts that make use of the >> information, namely the logical network and the virtual machines. The >> usage of these will be discussed below." >> I could describe this more explicitly. > > ovirt engine keeps it. how would one query by it though? what api and credentials would they be using to do so? > [IB] I think it should be accessible via REST and SDK . > I guess it should use admin credentials, but not sure. REST doesn't support lookup by every property and the is search for vnics/ports. so a modeling question. I'm not sure i like the concept of providing an administrative user credentials to all hosts, or of managing a password change in this case. not sure hosts should use the REST API, or another API intended for bi-directional communication with engine, secured in the same way the xml/rpc is secured. [IB2] Considering Quantum plugin implementation, I guess that may also handle physical Network configuration (Network between Hypervisors). In such case Quantum Plugin will need to resolve for VIF UUID plugged to certain network on what Server it is deployed. I think is the best way is to get it via SDK or REST. Do you have any suggestion? > >>> VM Migrate: >>> Even though it's just an initial suggestion, I think that VM >>> migration use case should be elaborated also for 'else' cases. What >>> happens if target Host does not support Quantum? What happens if >>> target host fails to run VM? Another issue is a lack of calls to >>> Quantum. For my understanding (but I can be wrong) in OpenStack it >>> will issue unplug and plug attachment calls. >> I agree. The goal here should be VM uptime and connectivity. If the >> "network" connectivity can be support but in a limited fashion then >> great - the migration can take place - this should nonetheless only >> be done when there is no other option. The live migration algorithm >> may have to be tweaked to support this. > > we do not assume involvement in engine in live migration today other than issuing a 'migrate' command to source host, or host needing information from engine to perform the live migration. > there must be a very good reason to break this assumption. > [IB] If this assumption should be in place, maybe it worth to consider to invoke 'create port' and 'plug interface' Quantum calls from VDSM node and not from oVirt engine. This this the model in OpenStack. Nova-compute invokes 'create port' and 'plug interface' Quantum calls. > It is described in the following doc: > http://wiki.openstack.org/QuantumAPIUseCases I'm not sure i like that better. would it be possible for engine to pre-provision the port on more than one host? [IB2] For my understanding, definition of port on the Network just defines a logical port and does not apply the physical location. Regarding the interface plugging it probably should work for plugging same interface more than once temporarily during VM migration phase. > > >>> 3. VDSM >>> Host Management: Any suggestion /plans to define a way to write and >>> deploy a Vif plug Driver ( a complimentary part to the Quantum Agent)? >> In Quantum the spirit of things is to keep the driver as thin as >> possible. The Quantum agent that runs on the VDSM host should do most >> of the work. It would be best if VDSM could provide a "plugin" >> mechanism that support the following: >> 1. deviceNameGet - this is due to the fact that the agent knows the >> device name - in the case of ovs and linux bridge this is done by >> using the first 11 characters of the attachment UUID. Other plugins >> may operate in a different manner. >> 2. vifAdd - this will be called with the MAC address, the VM UUID and >> maybe additional information 3. vifDelete >> >>> Regards, >>> Irena >>> -----Original Message----- >>> From: engine-devel-bounces at ovirt.org >>> [mailto:engine-devel-bounces at ovirt.org] On Behalf Of Gary Kotton >>> Sent: Monday, April 30, 2012 2:56 PM >>> To: dlaor at redhat.com >>> Cc: engine-devel at ovirt.org; users at ovirt.org >>> Subject: Re: [Engine-devel] oVirt and Quantum >>> >>> On 04/30/2012 10:39 AM, Dor Laor wrote: >>>> Gary, would it be possible to compare the current major api verbs >>>> offered by Quantum vs the ones offered by oVirt? >>> Please look at >>> https://docs.google.com/presentation/d/1cLW88tPw-8z_ANXU2WC8gd4U2k-A >>> C >>> rPnMQbgj5wDLz4/edit#slide=id.p >>> >>> This gives a high level explanation of Quantum and the flows. In >>> short both Quantum and oVirt enable the creation of logical networks. >>> By design Quantum hides the network details from the user. In oVirt >>> the user is able to configure the tags etc. We are in the process of >>> addressing this. >>> >>>> It would be nice to review the length/feature-rich of each and also >>>> the ease of use. >>> In addition to linux bridge (which is what oVirt uses today), >>> Quantum supports Open vSwitch, RYU and Cisco UCS - these are not >>> supported by oVirt at the moment. The RYU and Open vSwitch support >>> OpenFlow >>>> In addition, what would be the todo items in order to get OVS >>>> working w/ oVirt? >>> Actually not much. In fact this is currently supported with the >>> Quantum integration. There are two parts: >>> 1. The VM vNic management (implemented): >>> i. Create a tap device that has "ethernet" as the the network device >>> ii. Set the device us UP ii. Attach to the integration bridge and >>> configure tags etc. (The Quantum agent does this part) >>> >>> 2. The host management (to be implemented): >>> i. oVirt Engine and VDSM need to indicate which physical network >>> interfaces will use the integration bridge. This can be one or more >>> NICS or a bond (in Quantum this is part of a configuration file). We >>> need to think of a nice way to show this in the GUI. >>> ii. The logic in oVirt engine that "decides" if a Host is "Non >>> Operational" needs to be updated. >>>> Example for Quantum: >>>> http://docs.openstack.org/incubation/openstack-network/developer/qu >>>> a >>>> nt >>>> um-api-1.0/content/Show_port_Details.html#d6e777 >>>> >>>> Cheers, >>>> Dor >>>> >>>>> >>>>> _______________________________________________ >>>>> Engine-devel mailing list >>>>> Engine-devel at ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel at ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel > From masayag at redhat.com Tue May 15 14:31:50 2012 From: masayag at redhat.com (Moti Asayag) Date: Tue, 15 May 2012 17:31:50 +0300 Subject: [Engine-devel] REST-API: Exposing correlation-ID In-Reply-To: <750f8c50-2d5e-4524-99dc-52d9180306a2@zmail17.collab.prod.int.phx2.redhat.com> References: <750f8c50-2d5e-4524-99dc-52d9180306a2@zmail17.collab.prod.int.phx2.redhat.com> Message-ID: <4FB268D6.4030002@redhat.com> On 05/14/2012 02:19 PM, Ori Liel wrote: > No decision about the name of the parameter yet, and this is blocking me. > > Names that were suggested so far: > > * flow-id flow-id is the name used by VDSM logs for logging this value (e.g. flowID w23rew34) +1 > * batch-id > * log_id / log_entry_id > * op_id / operation_id > * correlation_id correlation-ID is the name used by the ovirt engine, however, it is a bit too long, yet +1. > * MetaTask-ID > > It seems like the only purpose of this feature is logging, so I'm > voting for 'log_entry_id' (although I consider some of the other options > viable as well). Does someone disagree with 'log_entry_id'? > > Thanks, > > Ori. > > ----- Original Message ----- > From: "Itamar Heim" > To: "Eoghan Glynn" > Cc: "Ori Liel" , engine-devel at ovirt.org > Sent: Tuesday, May 8, 2012 12:40:25 PM > Subject: Re: [Engine-devel] REST-API: Exposing correlation-ID > > On 05/08/2012 12:00 PM, Eoghan Glynn wrote: >> >> >>>>>>> 1) what's the name you'd give this parameter? job-id? batch-id? >>>>>>> flow-id? command-id? correlation-id??? >>>>> >>>>> job-id will confuse us with engine's job-id which is a single >>>>> command >>>>> today. >>>>> correleation-id is pretty long and confusing as implies on >>>>> correlation >>>>> of something. >>>>> >>>>> I'm for flow-id or batch-id. >>>>> batch-id sounds the right one to me, as this is identifying a >>>>> batch >>>>> of >>>>> calls. >>> >>>> How about log-id? >>>> It isn't supposed to be unique, or of any format, it's just used to >>>> log calls, so log-id is the most natural (or log-tag or whatever >>>> name you prefer). >>>> >>>> Also I think it's more of a header-type parameter since it's >>>> metadata for the call, not an actual parameter that influences the >>>> outcome of the "flow". >>> >>> I actually believe you're right, it probably is better to pass this parameter as >>> an http header. You've changed my mind about this (objections, anyone, to passing >>> it as a header as opposed to passing it as a url parameter)? >> >> Agree also that a header is much more natural in this case than a URL parameter. >> >> Also in the case where the client does not specify the ID themselves on the >> initial request, a generated value should be returned as response header >> (so that this can be passed as request header with the next request if part >> of the same over-arching task, or else just to aid log interpretation if the >> initial request was standalone but still mapped internally to multiple backend >> actions). >> >> >>> About log_id - it could sound like there are numerous logs, and the user is asked >>> to specify the ID of the log he wishes to write to. But perhaps: log_entry_id? >> >> Is there any possibility that this identifier may be leveraged for uses other than >> log interpretation? >> >> One other suggestion to add into the mix: MetaTask-ID. > > the one thing mentioned in the thread and worth remembering is this ID > is not unique, as client can set it as they want. > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From gkotton at redhat.com Tue May 15 14:34:35 2012 From: gkotton at redhat.com (Gary Kotton) Date: Tue, 15 May 2012 17:34:35 +0300 Subject: [Engine-devel] [Users] oVirt and Quantum In-Reply-To: <4FB23232.7090008@redhat.com> References: <4F9D1AD4.8070503@redhat.com> <4FB23232.7090008@redhat.com> Message-ID: <4FB2697B.4000406@redhat.com> Hi, Please see my inline comments. There are quite a few. Thanks Gary On 05/15/2012 01:38 PM, Itamar Heim wrote: > On 04/29/2012 01:41 PM, Gary Kotton wrote: >> Hi, >> >> As part of a POC we have integrated Quantum >> (http://wiki.openstack.org/Quantum) into oVirt (http://www.ovirt.org/). >> This has been tested with the OVS and Linux Bridge plugins. >> The details of the integration can be found at - >> https://fedoraproject.org/wiki/Quantum_and_oVirt. >> Any comments and suggestions would be greatly appreciated. >> Thanks >> Gary > > Thanks Gary - some questions: > > 1. you are using the term 'user' for both an end-user and an admin. I > think admin is more appropriate in most places. > > 2. host management --> interface > 2.1 you are suggesting to remove the vlan field with a fabric field? Yes, this is what I am suggesting. VLAN tagging is one method of network isolation. There are more, for example GRE tunneling. > are we sure this is something which shouldn't be presented in the main > view and only via extended properties? > > 2.2 is the fabric really a host interface level property, or a cluster > wide property (would same logical network be implemented on different > hosts in the cluster via both vdsm and quantum)? > would live migration work in same cluster if one host has qunatum > fabric and another vdsm fabric for same logical network? These are all up for discussion. I just wanted to provide something that we can start to work with. It would be nice if there was some input from product management on this issue (not exactly sure how this works in an open source community :)) > > 2.3 you are describing the subtab of an interface, and mention a > qunatum pull down menu. is this in the subtab? in a dialog? > UI mockups are needed here. I think that prior to getting mockups, we should ensure that we have the idea crystallized. > > 2.4 also, is this pulldown correct at host level or cluster level > (would live migration work between hosts implementing different > plugins for same logical network in same cluster?) > > on to backend: > 3.1 "The Quantum Service is a process that runs the Quantum API web > server (port 9696)" > > how is authentication between engine and quantum service is done (we > have a client certificate for engine which qunatum can verify i guess) In my opinion this should be running locally on the same host as the engine. > > 3.2 is there a config of the quantum service uri? should it be a > single instance or a per DC property? > (it sounds like a per DC property, can be a future thing) I am sorry but I do not understand the question. > > 3.3 network creation > > semantics: we create a network at DC level. we attach it at cluster > level. the UI allows you to "create at DC and attach to cluster" at > cluster level. > > 3.3.1 what if i create a network with same VLAN in two DC's? what if > we attach same logical network to multiple clusters - each will create > the logical network in qunatum again? If I understand you correctly then I think that one Quantum network can be created. This should work. In my opinion this should be managed by the oVirt engine so the actual creation is not an issue. Ensuring that each cluster has the correct network management configurations is what is important. > 3.3.2 what if the qunatum service is down when engine performs this > action or quantum returns an error? The engine should be able to deal with this - similar to the way in which it deals with a network creation when VDSM is down. > 3.3.3 each creation of a DC creates a rhevm network - I assume these > are not created, since "no host in a cluster in the DC yet"? This functionally can remain the same. > 3.3.4 what happens on moving of a host to another cluster, or moving > of a cluster to another DC (possible if it's DC was removed iirc). The Quantum agents take care of this. On each host there will be a Quantum agent that treats the network management. > 3.3.5 shouldn't this be limited to vm networks, or all networks are > relevant? I think all Quantum networks are relevant > 3.3.6 what if the host with the qunatum fabric is in maint mode? I do not understand. When a host is in maintenace mode do VM's receive traffic? The Quantum port for the VM's can be set as DOWN > 3.3.7 could a host with qunatum fabric have a VDSM fabric on another > interface (for vm neworks? for non-vm networks)? Yes. This is something that I would like. I also would like the Quantum API to be updated so that we can indicate the phycal network interface that the Quantum network will be running on. > > 3.5 network deletion (detach network from a cluster) > 3.5.1 what happens if qunatum is down or returned an error? The engine should be able to deal with this - similarly to what it does today > > 3.6 vm creation > 3.6.1 what about moving a VM from/to a cluster with a quantum fabric? I do not see a problem here. The agenets running on VDSM will detect and treat accordingly. > 3.6.2 what about import of a VM into a cluster with a qunatum fabric? Same as above > 3.6.3 you have vm creation/removal - missing vnic addition/removal > 3.6.4 worth mentioning qunatum doesn't care about the vnic model? > about the mac address? The Quantum driver on VDSM does take into account the MAC address. This is used in some plugins - for example the openvswicth plugin. > > 3.7 vm start > 3.7.1 why is the plugin parameter required at vm start? This is to indicate to VDSM the operations to take place - for example updating the openvswitch integration bridge > can multiple plugins be supported in parallel at vdsm/host level or by > the quantum service? Yes/ Multiple agents can run on VDSM. In the engine a little work is required to run multiple plugins. > 3.7.2 aren't network_uuid and port uuid redundant to attachment uuid > (I assume qunatum service knows from attachment the port and network) > - i have no objection to passing them to vdsm, just trying to > understand reasoning for this. > I am missing what happens at vdsm level in this point (even after > reading the matching vdsm part) The network ID and the port ID are returned by the Quantum service. The attachment ID is passed to the Quantum server. If this is unique then it can be a key to the above (I am currently working on the scale issue with Quantum and there are 2 options, the first is that it is unique, the second is that all three are passed to the agent). It is a few extra bytes passed. I think that it is better to be safe and have all of the information on VDSM for future use. > > 3.8 vm suspend/resume (it's fine to say it behaves like X, but still > need to be covered to not cause bugs/regressions) The Quantum port status can be updated. > > 3.9 vm stop Same as above > 3.9.1 need to make sure vm stop when engine is down is handled correctly. > 3.9.2 what happens if qunatum service is down? unlike start vm or > network creation the operation in this case cannot be > stopped/rolledback, only rolled forward. We have to ensure that it is up. > > 3.10 hot plug nic? Each new NIC has an attachment ID - the agent know that a new NIC is added and treats accordingly. > > 3.11 vm migration > 3.11.1 ok, so this is the first time i understand hosts can be mixed > in same cluster. worth specifying this in the beginning (still not > clear if mixed plugins can exist) If the networks are configured with the same characteristics then this should be OK. As mentioned above we are working on a blueprint to deal with connecting to existing networks - i.e. enable the user/admin to configure the VLAN tags > 3.11.2 afair, we don't deal with engine talking to both hosts during > live migration. only to host A, who is then communicating with host B. > so why not always have the VM configuration at vm start (and hot plug > nic) have the quantum details so live migration can occur at will > without additional information? I do not understand can you please explain. VDSM creates the tap device and builds the libvirt files. The agents detect the tap device and attach to the network. I do not understand why it is a problem for the live migration. This is also driven by the libvirt XML's being created. Is this correct? > 3.11.3 "In order to implement the above a REST client needs to be > implemented in the oVirt engine. " > did not understand this statement - please elaborate. All interface with the Quantum server is done via REST. In order for oVirt to be able to communicate, it will need to send REST messages to the server and be able to parse the replies - this is what I meant by the REST client. > > 4. host management > 4.1 deployment > we do not deploy packages from engine to hosts, we can install them > from a repo configured to the host. but this is done today only as > part of initial bootstrap/installation of host. > also, it is not relevant for ovirt node which is 'firmware' like. > any reason to not require the 'plugin installation packages' at vdsm > rpm level for plugins we think are good enough to use (until then, > responsibility to deploy them is of admin) > Correct. I agree with you. > (what are plugin level packages at host level - aren't these the agents?) Each plugin has the relevant packages that should be installed. > > 4.2 plugin configuration > per DC? per cluster? per host? per plugin? please provide more details > here on configuration details expected and flow of when they are > configured and when they are expected to change? I think that plugin per cluster is a good start. This could limit live migration problems. > I think this will merit a per 'ovirt supported' qunatum plugin to see > it works in a way we can use. > > 4.3 connectivity > again, this requires more details. if needed per plugin. > what is expected? how authentication/encryption happens? what iptables > rules need to change in engine/host if at all, etc. > I'm fine with this being 'direct access to db from hosts' for POC > level of patches, but not for something we actually merge/provide > support for later. I am currently working on a blueprint to ensure better scaling of quantum agents. This will be done by making use of the nova RPC library. This supports Qpid, rabbit mq, kombu etc. These have an option of being secure. Please clarify if this suffices? > > 5. VDSM > > 5.1 s/The agent packe/The agent package/ ? :) > > 5.2 "The agent package can and may be received from the oVirt Engine > or can be downloaded via RPM's" > see 4.1 above - we don't deploy rpm's/code on the fly today. When I was sitting with the guys from oVirt this is what I was told. I guess that I misunderstood. > > 5.3 "n addition to the treatment below VDSM should also maintain a > health check to the Quantum agent" > what if the restart didn't help? how should ovirt treat the host wrt > networking? to running VMs? to ability to live migrate VMs from the > host if needed? If the agent is down then the oVirt engine should be notified to at least events for the user. > > 5.4 "Logical Network Management" > please see 3.11 above - we would want live migration to not require > additional information, so details should be available even if not > immediately acted upon. > > 5.5 "The tap device created uses an "ethernet" network device. This > means that the creation of the libvirt XML file is a bit different." Yes, that is correct > 5.5.1 does this impact stable device addresses somehow? Not that I am aware of > 5.5.2 how is live migration possible if the libvirt xml to a non > quantum host is different (or is this the binding part only)? If the libvirt is "pacthed" when the migration takes place then this should not be a problem. > > 5.6 I assume libvirtvm.py is part of vdsm. > is quantum.py part of quantum code base or vdsm codebase (it sounds > like it should be part of quantum code base)? > so how exactly the rpm for this would look like? deploy it to > /xxx/qunatum and have it add a symbolic link to it from vdsm paths? In my opinion this should be part of VDSM. It would be ideal if each plugin can bind load a driver - in Nova each driver is part of the nova code. If the API is well defined then all vendors can provide their drivers. This is open for discussion and we should try and understand what the best way of doing this is. I like the NOVA model. > > 5.7 "When a communication channel is established between VDSM and the > oVirt engine. The VDSM host should notify the oVirt Engine of the > Quantum fabric that is supported." > how does vdsm goes about detecting an agent is installed exactly? The user needs to install a package for the agent - this creates the relevant configuartion files. These files can be used to detect the running agent or via "ps" > (especially since deployment wise, most likely is all agents would be > deployed via rpm requirements?) > is any agent a service at host level rather than code only? > is there a scenario where a vdsm level plugin isn't required? > > 6. open issues > 6.1 worth mentioning if any are in the works No shortage :). But we have a good start. There are some blueprints in the works which solve a large amount of problems > 6.2 specifying the vlan from ovirt engine is not a gap? Yes it is. This is currently being addressed. This is not a reason to stop us moving ahead. > 6.3 ok, so this is the first time "no multiple plugins" is mentioned > ("Non-uniform technology"). but it sounds like the approach in the > wiki assume it is/will be possible to have multiple technologies > (agents/plugins) going forward? My take is that this can be hidden by oVirt engine. It is just an implemnattion detail - this should not affect the user experience - which at the end of the day is what counts > 6.4 need to discuss which of the open issues should block going > forward with merging of code, and expected timeframe for resolution of > some of them Correct. In my opinion there are no major blocking issues at the moment. > > 7. other questions/items (some mentioned above as well) > 7.1 please add ui mockups, db scheme changes and REST api changes OK > 7.2 i'm missing the deployment flow: OK > - user install engine. is quantum a separate install or bundled going > forward? > - any configuration items by user at this point? what are they? > - what rpms are deployed at host level? what configuration do they need > - communication channels and their security are a must to understand > 7.3 upgrade path / compatibility levels this is relevant to? > 7.4 monitoring flow - how is monitoring/state of a host is affected by > quantum service being down, communication problem from host to (where > actually?) From mkenneth at redhat.com Tue May 15 14:44:20 2012 From: mkenneth at redhat.com (Miki Kenneth) Date: Tue, 15 May 2012 10:44:20 -0400 (EDT) Subject: [Engine-devel] REST-API: Exposing correlation-ID In-Reply-To: <4FB12DAB.3080902@redhat.com> Message-ID: <8fe33536-cd1c-4bea-bac3-3353178c611d@mkenneth.csb> ----- Original Message ----- > From: "Itamar Heim" > To: "Eoghan Glynn" > Cc: engine-devel at ovirt.org > Sent: Monday, May 14, 2012 7:07:07 PM > Subject: Re: [Engine-devel] REST-API: Exposing correlation-ID > > On 05/14/2012 07:05 PM, Eoghan Glynn wrote: > > > > > >>>> * MetaTask-ID > >> > >> -1, too pompous? > > > > Me, pompous? Never! ;) > > > >> a maybe to remove the "ID" from name, since there is no uniqueness > >> guarantee. > > > > Sure, MetaTask-Tag for example would be less connoting of > > uniqueness. > > I like 'Tag' > only problem is we have tags in the system already... > > looking for something in same area - how about just calling this > field > 'label' Agreed. I like Tag cause it's short... need to find something similar. cmd-id? > > > > > But in general, I'd +1 any of the options that aren't suggestive of > > this being a purely log-oriented thing. > > > > Cheers, > > Eoghan > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From iheim at redhat.com Tue May 15 21:18:35 2012 From: iheim at redhat.com (Itamar Heim) Date: Wed, 16 May 2012 00:18:35 +0300 Subject: [Engine-devel] REST-API: Exposing correlation-ID In-Reply-To: <8fe33536-cd1c-4bea-bac3-3353178c611d@mkenneth.csb> References: <8fe33536-cd1c-4bea-bac3-3353178c611d@mkenneth.csb> Message-ID: <4FB2C82B.1010206@redhat.com> On 05/15/2012 05:44 PM, Miki Kenneth wrote: > > > ----- Original Message ----- >> From: "Itamar Heim" >> To: "Eoghan Glynn" >> Cc: engine-devel at ovirt.org >> Sent: Monday, May 14, 2012 7:07:07 PM >> Subject: Re: [Engine-devel] REST-API: Exposing correlation-ID >> >> On 05/14/2012 07:05 PM, Eoghan Glynn wrote: >>> >>> >>>>>> * MetaTask-ID >>>> >>>> -1, too pompous? >>> >>> Me, pompous? Never! ;) >>> >>>> a maybe to remove the "ID" from name, since there is no uniqueness >>>> guarantee. >>> >>> Sure, MetaTask-Tag for example would be less connoting of >>> uniqueness. >> >> I like 'Tag' >> only problem is we have tags in the system already... >> >> looking for something in same area - how about just calling this >> field >> 'label' > Agreed. I like Tag cause it's short... need to find something similar. > cmd-id? cmd represents a single command in backend. id represent something unique. I'm liking 'label' more and more, since it doesn't imply uniqueness. >> >>> >>> But in general, I'd +1 any of the options that aren't suggestive of >>> this being a purely log-oriented thing. >>> >>> Cheers, >>> Eoghan >> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> From yzaslavs at redhat.com Wed May 16 05:56:46 2012 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Wed, 16 May 2012 08:56:46 +0300 Subject: [Engine-devel] REST-API: Exposing correlation-ID In-Reply-To: <4FB2C82B.1010206@redhat.com> References: <8fe33536-cd1c-4bea-bac3-3353178c611d@mkenneth.csb> <4FB2C82B.1010206@redhat.com> Message-ID: <4FB3419E.2060102@redhat.com> On 05/16/2012 12:18 AM, Itamar Heim wrote: > On 05/15/2012 05:44 PM, Miki Kenneth wrote: >> >> >> ----- Original Message ----- >>> From: "Itamar Heim" >>> To: "Eoghan Glynn" >>> Cc: engine-devel at ovirt.org >>> Sent: Monday, May 14, 2012 7:07:07 PM >>> Subject: Re: [Engine-devel] REST-API: Exposing correlation-ID >>> >>> On 05/14/2012 07:05 PM, Eoghan Glynn wrote: >>>> >>>> >>>>>>> * MetaTask-ID >>>>> >>>>> -1, too pompous? >>>> >>>> Me, pompous? Never! ;) >>>> >>>>> a maybe to remove the "ID" from name, since there is no uniqueness >>>>> guarantee. >>>> >>>> Sure, MetaTask-Tag for example would be less connoting of >>>> uniqueness. >>> >>> I like 'Tag' >>> only problem is we have tags in the system already... >>> >>> looking for something in same area - how about just calling this >>> field >>> 'label' >> Agreed. I like Tag cause it's short... need to find something similar. >> cmd-id? > > cmd represents a single command in backend. > id represent something unique. > > I'm liking 'label' more and more, since it doesn't imply uniqueness. > >>> >>>> >>>> But in general, I'd +1 any of the options that aren't suggestive of >>>> this being a purely log-oriented thing. I actually agree here. the log option bothered me the most. >>>> >>>> Cheers, >>>> Eoghan >>> >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel at ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From amureini at redhat.com Wed May 16 08:24:18 2012 From: amureini at redhat.com (Allon Mureinik) Date: Wed, 16 May 2012 04:24:18 -0400 (EDT) Subject: [Engine-devel] Random seeding in unit tests In-Reply-To: Message-ID: <173d737e-d7eb-439b-9eb9-f87e1d8903ed@zmail17.collab.prod.int.phx2.redhat.com> If you ever need a comfortable way to inject a random seed to your test (e.g., for reproducing a specific run), check out the new RandomUtilsSeedingRule: http://ovirt.org/wiki/RandomUtilsSeedingRule From gchaplik at redhat.com Wed May 16 10:16:24 2012 From: gchaplik at redhat.com (Gilad Chaplik) Date: Wed, 16 May 2012 06:16:24 -0400 (EDT) Subject: [Engine-devel] restapi: New params for import VM/Template In-Reply-To: Message-ID: Hi All, I am adding the ability to import a VM or a Template to a storage-domain, when this VM or Template already exists in the destination storage domain. Until now, Backend failed this. Now I want to enable the user to specify that he wishes this VM/Template will be created again by a different name, i.e - cloned. [feature page: http://www.ovirt.org/wiki/Features/ImportMoreThanOnce] I plan to achieve this using a new parameter, but I want to reach an agreement about this parameter's name. I thought simply to call it "clone". Another thing that I'll do in the patch-set is add the currently-missing ability to specify whether the snapshots of the VM, which is being imported, will be collapsed into a single snapshot (we have this ability in GUI). I am also deliberating about the name of this parameter. I thought about "collapse_snapshots" (same as in GUI). Does anyone think "clone" and "collapse_snapshots" are inappropriate and has better suggestions? Thanks, Gilad From mpastern at redhat.com Wed May 16 11:01:07 2012 From: mpastern at redhat.com (Michael Pasternak) Date: Wed, 16 May 2012 14:01:07 +0300 Subject: [Engine-devel] restapi: New params for import VM/Template In-Reply-To: References: Message-ID: <4FB388F3.1030308@redhat.com> On 05/16/2012 01:16 PM, Gilad Chaplik wrote: > Hi All, > > I am adding the ability to import a VM or a Template to a storage-domain, > when this VM or Template already exists in the destination storage domain. > Until now, Backend failed this. Now I want to enable the user to specify > that he wishes this VM/Template will be created again by a different name, > i.e - cloned. > > [feature page: http://www.ovirt.org/wiki/Features/ImportMoreThanOnce] > > I plan to achieve this using a new parameter, but I want to reach an agreement > about this parameter's name. I thought simply to call it "clone". > > Another thing that I'll do in the patch-set is add the currently-missing ability > to specify whether the snapshots of the VM, which is being imported, will > be collapsed into a single snapshot (we have this ability in GUI). I am also > deliberating about the name of this parameter. I thought about > "collapse_snapshots" (same as in GUI). > > Does anyone think "clone" and "collapse_snapshots" are inappropriate and has /clone/ already in-use (used to clone vm from template), true|false ..., you can simply say if imported vm has element, this is import+clone, otherwise import, as about collapse_snapshots, i don't mind, but this should be done in the way is implemented in collection > better suggestions? > > Thanks, > Gilad -- Michael Pasternak RedHat, ENG-Virtualization R&D From oliel at redhat.com Wed May 16 11:49:17 2012 From: oliel at redhat.com (Ori Liel) Date: Wed, 16 May 2012 07:49:17 -0400 (EDT) Subject: [Engine-devel] restapi: New params for import VM/Template In-Reply-To: <4FB388F3.1030308@redhat.com> Message-ID: >On 05/16/2012 01:16 PM, Gilad Chaplik wrote: >> Hi All, >> >> I am adding the ability to import a VM or a Template to a storage-domain, >> when this VM or Template already exists in the destination storage domain. >> Until now, Backend failed this. Now I want to enable the user to specify >> that he wishes this VM/Template will be created again by a different name, >> i.e - cloned. >> >> [feature page: http://www.ovirt.org/wiki/Features/ImportMoreThanOnce] >> >> I plan to achieve this using a new parameter, but I want to reach an agreement >> about this parameter's name. I thought simply to call it "clone". >> >> Another thing that I'll do in the patch-set is add the currently-missing ability >> to specify whether the snapshots of the VM, which is being imported, will >> be collapsed into a single snapshot (we have this ability in GUI). I am also >> deliberating about the name of this parameter. I thought about >> "collapse_snapshots" (same as in GUI). >> >> Does anyone think "clone" and "collapse_snapshots" are inappropriate and has > >/clone/ already in-use (used to clone vm from template), > > > > true|false >..., > >you can simply say if imported vm has element, this is import+clone, otherwise import, If in the future we will want to enable overriding a VM's params on import, this will be confusing (because a user might want to import a VM and change it's name - but not clone it if it already exists). >as about collapse_snapshots, i don't mind, but this should be done in the way is implemented >in collection Semantically, a snapshot is a point in time of a VM. It not only associated any more only with the VM's disks; it includes the VM's meta-data as well. For this reason, maybe the parameter collapse_snapshots should not be in collection (although, technically, the collapse will be done on disks) > > >> better suggestions? >> >> Thanks, >> Gilad > > >-- > >Michael Pasternak >RedHat, ENG-Virtualization R&D From mpastern at redhat.com Wed May 16 12:06:07 2012 From: mpastern at redhat.com (Michael Pasternak) Date: Wed, 16 May 2012 15:06:07 +0300 Subject: [Engine-devel] restapi: New params for import VM/Template In-Reply-To: References: Message-ID: <4FB3982F.6080202@redhat.com> On 05/16/2012 02:49 PM, Ori Liel wrote: >> On 05/16/2012 01:16 PM, Gilad Chaplik wrote: >>> Hi All, >>> >>> I am adding the ability to import a VM or a Template to a storage-domain, >>> when this VM or Template already exists in the destination storage domain. >>> Until now, Backend failed this. Now I want to enable the user to specify >>> that he wishes this VM/Template will be created again by a different name, >>> i.e - cloned. >>> >>> [feature page: http://www.ovirt.org/wiki/Features/ImportMoreThanOnce] >>> >>> I plan to achieve this using a new parameter, but I want to reach an agreement >>> about this parameter's name. I thought simply to call it "clone". >>> >>> Another thing that I'll do in the patch-set is add the currently-missing ability >>> to specify whether the snapshots of the VM, which is being imported, will >>> be collapsed into a single snapshot (we have this ability in GUI). I am also >>> deliberating about the name of this parameter. I thought about >>> "collapse_snapshots" (same as in GUI). >>> >>> Does anyone think "clone" and "collapse_snapshots" are inappropriate and has >> >> /clone/ already in-use (used to clone vm from template), >> >> >> >> true|false >> ..., >> >> you can simply say if imported vm has element, this is import+clone, otherwise import, > > If in the future we will want to enable overriding a VM's params on import, this will be confusing > (because a user might want to import a VM and change it's name - but not clone it if it already exists). the concept of /import/ is copy vm from sd1 to sd2, then you can change vm meta as needed, besides we already using element existence/absence as action 'determinator' in other places in api. > >> as about collapse_snapshots, i don't mind, but this should be done in the way is implemented >> in collection > > Semantically, a snapshot is a point in time of a VM. It not only associated any more only with the VM's > disks; it includes the VM's meta-data as well. For this reason, maybe the parameter collapse_snapshots > should not be in collection (although, technically, the collapse will be done on disks) obviously i meant , thanks. > >> >> >>> better suggestions? >>> >>> Thanks, >>> Gilad >> >> >> -- >> >> Michael Pasternak >> RedHat, ENG-Virtualization R&D -- Michael Pasternak RedHat, ENG-Virtualization R&D From gchaplik at redhat.com Wed May 16 12:26:52 2012 From: gchaplik at redhat.com (Gilad Chaplik) Date: Wed, 16 May 2012 08:26:52 -0400 (EDT) Subject: [Engine-devel] restapi: New params for import VM/Template In-Reply-To: Message-ID: <57255a02-2a7f-4a2e-be76-1e0ec28c3e0b@zmail14.collab.prod.int.phx2.redhat.com> Thanks, Gilad. ----- Original Message ----- > From: "Ori Liel" > To: "Michael Pasternak" > Cc: "engine-devel" , "Itamar Heim" , "Doron Fediuck" , > "Gilad Chaplik" > Sent: Wednesday, May 16, 2012 2:49:17 PM > Subject: Re: restapi: New params for import VM/Template > > >On 05/16/2012 01:16 PM, Gilad Chaplik wrote: > >> Hi All, > >> > >> I am adding the ability to import a VM or a Template to a > >> storage-domain, > >> when this VM or Template already exists in the destination storage > >> domain. > >> Until now, Backend failed this. Now I want to enable the user to > >> specify > >> that he wishes this VM/Template will be created again by a > >> different name, > >> i.e - cloned. > >> > >> [feature page: > >> http://www.ovirt.org/wiki/Features/ImportMoreThanOnce] > >> > >> I plan to achieve this using a new parameter, but I want to reach > >> an agreement > >> about this parameter's name. I thought simply to call it "clone". > >> > >> Another thing that I'll do in the patch-set is add the > >> currently-missing ability > >> to specify whether the snapshots of the VM, which is being > >> imported, will > >> be collapsed into a single snapshot (we have this ability in GUI). > >> I am also > >> deliberating about the name of this parameter. I thought about > >> "collapse_snapshots" (same as in GUI). > >> > >> Does anyone think "clone" and "collapse_snapshots" are > >> inappropriate and has > > > >/clone/ already in-use (used to clone vm from template), clone here has a different context, clone VM vs. clone disks. > > > > > > > > true|false > >..., > > > >you can simply say if imported vm has element, this is > >import+clone, otherwise import, > > If in the future we will want to enable overriding a VM's params on > import, this will be confusing > (because a user might want to import a VM and change it's name - but > not clone it if it already exists). +1, cloning a vm and changing the vm's metadata (i.e vm's name) should not be inter-dependent. > > >as about collapse_snapshots, i don't mind, but this should be done > >in the way is implemented > >in collection > > Semantically, a snapshot is a point in time of a VM. It not only > associated any more only with the VM's > disks; it includes the VM's meta-data as well. For this reason, maybe > the parameter collapse_snapshots > should not be in collection (although, technically, the > collapse will be done on disks) +1, I think the collapse_snapshots should be in the vm context (snapshots is under vm). Other than that, currently, if you want to clone a vm, it must be 'collapsed snapshots', so the flow to clone a vm (with your suggestion) will be: new_vm true true where collapse_snapshot should be superior to clone, this structure is a bit confusing. > > > > > > >> better suggestions? > >> > >> Thanks, > >> Gilad > > > > > >-- > > > >Michael Pasternak > >RedHat, ENG-Virtualization R&D > From mpastern at redhat.com Wed May 16 12:49:24 2012 From: mpastern at redhat.com (Michael Pasternak) Date: Wed, 16 May 2012 15:49:24 +0300 Subject: [Engine-devel] restapi: New params for import VM/Template In-Reply-To: <57255a02-2a7f-4a2e-be76-1e0ec28c3e0b@zmail14.collab.prod.int.phx2.redhat.com> References: <57255a02-2a7f-4a2e-be76-1e0ec28c3e0b@zmail14.collab.prod.int.phx2.redhat.com> Message-ID: <4FB3A254.8090900@redhat.com> On 05/16/2012 03:26 PM, Gilad Chaplik wrote: > > > Thanks, > Gilad. > > ----- Original Message ----- >> From: "Ori Liel" >> To: "Michael Pasternak" >> Cc: "engine-devel" , "Itamar Heim" , "Doron Fediuck" , >> "Gilad Chaplik" >> Sent: Wednesday, May 16, 2012 2:49:17 PM >> Subject: Re: restapi: New params for import VM/Template >> >>> On 05/16/2012 01:16 PM, Gilad Chaplik wrote: >>>> Hi All, >>>> >>>> I am adding the ability to import a VM or a Template to a >>>> storage-domain, >>>> when this VM or Template already exists in the destination storage >>>> domain. >>>> Until now, Backend failed this. Now I want to enable the user to >>>> specify >>>> that he wishes this VM/Template will be created again by a >>>> different name, >>>> i.e - cloned. >>>> >>>> [feature page: >>>> http://www.ovirt.org/wiki/Features/ImportMoreThanOnce] >>>> >>>> I plan to achieve this using a new parameter, but I want to reach >>>> an agreement >>>> about this parameter's name. I thought simply to call it "clone". >>>> >>>> Another thing that I'll do in the patch-set is add the >>>> currently-missing ability >>>> to specify whether the snapshots of the VM, which is being >>>> imported, will >>>> be collapsed into a single snapshot (we have this ability in GUI). >>>> I am also >>>> deliberating about the name of this parameter. I thought about >>>> "collapse_snapshots" (same as in GUI). >>>> >>>> Does anyone think "clone" and "collapse_snapshots" are >>>> inappropriate and has >>> >>> /clone/ already in-use (used to clone vm from template), > > clone here has a different context, clone VM vs. clone disks. having two clone elements in vm will be confusing. -1 > >>> >>> >>> >>> true|false >>> ..., >>> >>> you can simply say if imported vm has element, this is >>> import+clone, otherwise import, >> >> If in the future we will want to enable overriding a VM's params on >> import, this will be confusing >> (because a user might want to import a VM and change it's name - but >> not clone it if it already exists). > > +1, cloning a vm and changing the vm's metadata (i.e vm's name) should not be inter-dependent. how exactly this is contradict changing metadata on the fly?, exactly on opposite - it works perfectly well for your use-case: BE logic: -------- if (local ) has vm named as on remote (export.domain) { if PARAMS != remote (export.domain) { copy + rename } else { error } } else { if PARAMS != remote (export.domain) { copy + rename } else { copy } } > >> >>> as about collapse_snapshots, i don't mind, but this should be done >>> in the way is implemented >>> in collection >> >> Semantically, a snapshot is a point in time of a VM. It not only >> associated any more only with the VM's >> disks; it includes the VM's meta-data as well. For this reason, maybe >> the parameter collapse_snapshots >> should not be in collection (although, technically, the >> collapse will be done on disks) > > +1, I think the collapse_snapshots should be in the vm context (snapshots is under vm). i meant , see my other email on this. > > Other than that, currently, if you want to clone a vm, it must be 'collapsed snapshots', so > the flow to clone a vm (with your suggestion) will be: > > > > new_vm > > true > > > true > > > where collapse_snapshot should be superior to clone, this structure is a bit confusing. > >> >>> >>> >>>> better suggestions? >>>> >>>> Thanks, >>>> Gilad >>> >>> >>> -- >>> >>> Michael Pasternak >>> RedHat, ENG-Virtualization R&D >> -- Michael Pasternak RedHat, ENG-Virtualization R&D From oliel at redhat.com Wed May 16 12:44:25 2012 From: oliel at redhat.com (Ori Liel) Date: Wed, 16 May 2012 08:44:25 -0400 (EDT) Subject: [Engine-devel] restapi: New params for import VM/Template In-Reply-To: <4FB3982F.6080202@redhat.com> Message-ID: >On 05/16/2012 02:49 PM, Ori Liel wrote: >>> On 05/16/2012 01:16 PM, Gilad Chaplik wrote: >>>> Hi All, >>>> >>>> I am adding the ability to import a VM or a Template to a storage-domain, >>>> when this VM or Template already exists in the destination storage domain. >>>> Until now, Backend failed this. Now I want to enable the user to specify >>>> that he wishes this VM/Template will be created again by a different name, >>>> i.e - cloned. >>>> >>>> [feature page: http://www.ovirt.org/wiki/Features/ImportMoreThanOnce] >>>> >>>> I plan to achieve this using a new parameter, but I want to reach an agreement >>>> about this parameter's name. I thought simply to call it "clone". >>>> >>>> Another thing that I'll do in the patch-set is add the currently-missing ability >>>> to specify whether the snapshots of the VM, which is being imported, will >>>> be collapsed into a single snapshot (we have this ability in GUI). I am also >>>> deliberating about the name of this parameter. I thought about >>>> "collapse_snapshots" (same as in GUI). >>>> >>>> Does anyone think "clone" and "collapse_snapshots" are inappropriate and has >>> >>> /clone/ already in-use (used to clone vm from template), >>> >>> >>> >>> true|false >>> ..., >>> >>> you can simply say if imported vm has element, this is import+clone, otherwise import, >> >> If in the future we will want to enable overriding a VM's params on import, this will be confusing >> (because a user might want to import a VM and change it's name - but not clone it if it already exists). > >the concept of /import/ is copy vm from sd1 to sd2, then you can change vm meta as needed, ok >besides we already using element existence/absence as action 'determinator' in other >places in api. It's true, existence of ID/name does determine behaviour elsewhere in the API. In this specific case, it feels a bit less intuitive; what do you think about the difference between the following two scenarios? If user passes clone=true, and this VM doesn't already exist on the destination storage-domain, then the operation fails - makes direct sense: you wanted to clone, but this VM doesn't already exist. If user passes name=VM1, and this VM doesn't already exist on the destination storage-domain, then the operation fails - a bit strange. The logic is more construed: you supplied a name, therefore you meant you want to clone, but this VM doesn't already exist. > >> >>> as about collapse_snapshots, i don't mind, but this should be done in the way is implemented >>> in collection >> >> Semantically, a snapshot is a point in time of a VM. It not only associated any more only with the VM's >> disks; it includes the VM's meta-data as well. For this reason, maybe the parameter collapse_snapshots >> should not be in collection (although, technically, the collapse will be done on disks) > >obviously i meant , thanks. > >> >>> >>> >>>> better suggestions? >>>> >>>> Thanks, >>>> Gilad >>> >>> >>> -- >>> >>> Michael Pasternak >>> RedHat, ENG-Virtualization R&D > > >-- > >Michael Pasternak >RedHat, ENG-Virtualization R&D From mpastern at redhat.com Wed May 16 12:54:01 2012 From: mpastern at redhat.com (Michael Pasternak) Date: Wed, 16 May 2012 15:54:01 +0300 Subject: [Engine-devel] restapi: New params for import VM/Template In-Reply-To: References: Message-ID: <4FB3A369.70102@redhat.com> On 05/16/2012 03:44 PM, Ori Liel wrote: > It's true, existence of ID/name does determine behaviour elsewhere in the API. In this specific case, > it feels a bit less intuitive; what do you think about the difference between the following two > scenarios? > > If user passes clone=true, and this VM doesn't already exist on the destination storage-domain, then > the operation fails - makes direct sense: you wanted to clone, but this VM doesn't already exist. > > If user passes name=VM1, and this VM doesn't already exist on the destination storage-domain, then > the operation fails - a bit strange. The logic is more construed: you supplied a name, therefore you > meant you want to clone, but this VM doesn't already exist. it's just another import, see my other email on this with pseudocode. -- Michael Pasternak RedHat, ENG-Virtualization R&D From mpastern at redhat.com Wed May 16 13:17:57 2012 From: mpastern at redhat.com (Michael Pasternak) Date: Wed, 16 May 2012 16:17:57 +0300 Subject: [Engine-devel] restapi: New params for import VM/Template In-Reply-To: <4FB3A62E.9070309@redhat.com> References: <57255a02-2a7f-4a2e-be76-1e0ec28c3e0b@zmail14.collab.prod.int.phx2.redhat.com> <4FB3A254.8090900@redhat.com> <4FB3A62E.9070309@redhat.com> Message-ID: <4FB3A905.50903@redhat.com> On 05/16/2012 04:05 PM, Itamar Heim wrote: > On 05/16/2012 03:49 PM, Michael Pasternak wrote: >> On 05/16/2012 03:26 PM, Gilad Chaplik wrote: >>> >>> >>> Thanks, >>> Gilad. >>> >>> ----- Original Message ----- >>>> From: "Ori Liel" >>>> To: "Michael Pasternak" >>>> Cc: "engine-devel", "Itamar Heim", "Doron Fediuck", >>>> "Gilad Chaplik" >>>> Sent: Wednesday, May 16, 2012 2:49:17 PM >>>> Subject: Re: restapi: New params for import VM/Template >>>> >>>>> On 05/16/2012 01:16 PM, Gilad Chaplik wrote: >>>>>> Hi All, >>>>>> >>>>>> I am adding the ability to import a VM or a Template to a >>>>>> storage-domain, >>>>>> when this VM or Template already exists in the destination storage >>>>>> domain. >>>>>> Until now, Backend failed this. Now I want to enable the user to >>>>>> specify >>>>>> that he wishes this VM/Template will be created again by a >>>>>> different name, >>>>>> i.e - cloned. >>>>>> >>>>>> [feature page: >>>>>> http://www.ovirt.org/wiki/Features/ImportMoreThanOnce] >>>>>> >>>>>> I plan to achieve this using a new parameter, but I want to reach >>>>>> an agreement >>>>>> about this parameter's name. I thought simply to call it "clone". >>>>>> >>>>>> Another thing that I'll do in the patch-set is add the >>>>>> currently-missing ability >>>>>> to specify whether the snapshots of the VM, which is being >>>>>> imported, will >>>>>> be collapsed into a single snapshot (we have this ability in GUI). >>>>>> I am also >>>>>> deliberating about the name of this parameter. I thought about >>>>>> "collapse_snapshots" (same as in GUI). >>>>>> >>>>>> Does anyone think "clone" and "collapse_snapshots" are >>>>>> inappropriate and has >>>>> >>>>> /clone/ already in-use (used to clone vm from template), >>> >>> clone here has a different context, clone VM vs. clone disks. >> >> having two clone elements in vm will be confusing. >> >> -1 >> >>> >>>>> >>>>> >>>>> >>>>> true|false >>>>> ..., >>>>> >>>>> you can simply say if imported vm has element, this is >>>>> import+clone, otherwise import, >>>> >>>> If in the future we will want to enable overriding a VM's params on >>>> import, this will be confusing >>>> (because a user might want to import a VM and change it's name - but >>>> not clone it if it already exists). >>> >>> +1, cloning a vm and changing the vm's metadata (i.e vm's name) should not be inter-dependent. >> >> how exactly this is contradict changing metadata on the fly?, >> exactly on opposite - it works perfectly well for your use-case: >> >> BE logic: >> -------- >> >> if (local) has vm named as on remote (export.domain) > > please note "vm exists" is based on vm uuid, not on vm name i think it based on name, Omer? > >> { >> if PARAMS != remote (export.domain) >> { >> copy + rename >> } else { >> error >> } >> } else { >> if PARAMS != remote (export.domain) >> { >> copy + rename >> } else { >> copy >> } >> } >> >>> >>>> >>>>> as about collapse_snapshots, i don't mind, but this should be done >>>>> in the way is implemented >>>>> in collection >>>> >>>> Semantically, a snapshot is a point in time of a VM. It not only >>>> associated any more only with the VM's >>>> disks; it includes the VM's meta-data as well. For this reason, maybe >>>> the parameter collapse_snapshots >>>> should not be in collection (although, technically, the >>>> collapse will be done on disks) >>> >>> +1, I think the collapse_snapshots should be in the vm context (snapshots is under vm). >> >> i meant, see my other email on this. >> >>> >>> Other than that, currently, if you want to clone a vm, it must be 'collapsed snapshots', so >>> the flow to clone a vm (with your suggestion) will be: >>> >>> >>> >>> new_vm >>> >>> true >>> >>> >>> true >>> >>> >>> where collapse_snapshot should be superior to clone, this structure is a bit confusing. >>> >>>> >>>>> >>>>> >>>>>> better suggestions? >>>>>> >>>>>> Thanks, >>>>>> Gilad >>>>> >>>>> >>>>> -- >>>>> >>>>> Michael Pasternak >>>>> RedHat, ENG-Virtualization R&D >>>> >> >> > -- Michael Pasternak RedHat, ENG-Virtualization R&D From gchaplik at redhat.com Wed May 16 13:26:56 2012 From: gchaplik at redhat.com (Gilad Chaplik) Date: Wed, 16 May 2012 09:26:56 -0400 (EDT) Subject: [Engine-devel] restapi: New params for import VM/Template In-Reply-To: <4FB3A905.50903@redhat.com> Message-ID: <3aca8566-2422-46e8-abdb-322cbc1fb536@zmail14.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Michael Pasternak" > To: "Itamar Heim" , "Omer Frenkel" > Cc: "Gilad Chaplik" , "engine-devel" , "Doron Fediuck" > , "Ori Liel" > Sent: Wednesday, May 16, 2012 4:17:57 PM > Subject: Re: restapi: New params for import VM/Template > > On 05/16/2012 04:05 PM, Itamar Heim wrote: > > On 05/16/2012 03:49 PM, Michael Pasternak wrote: > >> On 05/16/2012 03:26 PM, Gilad Chaplik wrote: > >>> > >>> > >>> Thanks, > >>> Gilad. > >>> > >>> ----- Original Message ----- > >>>> From: "Ori Liel" > >>>> To: "Michael Pasternak" > >>>> Cc: "engine-devel", "Itamar > >>>> Heim", "Doron Fediuck", > >>>> "Gilad Chaplik" > >>>> Sent: Wednesday, May 16, 2012 2:49:17 PM > >>>> Subject: Re: restapi: New params for import VM/Template > >>>> > >>>>> On 05/16/2012 01:16 PM, Gilad Chaplik wrote: > >>>>>> Hi All, > >>>>>> > >>>>>> I am adding the ability to import a VM or a Template to a > >>>>>> storage-domain, > >>>>>> when this VM or Template already exists in the destination > >>>>>> storage > >>>>>> domain. > >>>>>> Until now, Backend failed this. Now I want to enable the user > >>>>>> to > >>>>>> specify > >>>>>> that he wishes this VM/Template will be created again by a > >>>>>> different name, > >>>>>> i.e - cloned. > >>>>>> > >>>>>> [feature page: > >>>>>> http://www.ovirt.org/wiki/Features/ImportMoreThanOnce] > >>>>>> > >>>>>> I plan to achieve this using a new parameter, but I want to > >>>>>> reach > >>>>>> an agreement > >>>>>> about this parameter's name. I thought simply to call it > >>>>>> "clone". > >>>>>> > >>>>>> Another thing that I'll do in the patch-set is add the > >>>>>> currently-missing ability > >>>>>> to specify whether the snapshots of the VM, which is being > >>>>>> imported, will > >>>>>> be collapsed into a single snapshot (we have this ability in > >>>>>> GUI). > >>>>>> I am also > >>>>>> deliberating about the name of this parameter. I thought about > >>>>>> "collapse_snapshots" (same as in GUI). > >>>>>> > >>>>>> Does anyone think "clone" and "collapse_snapshots" are > >>>>>> inappropriate and has > >>>>> > >>>>> /clone/ already in-use (used to clone vm from template), > >>> > >>> clone here has a different context, clone VM vs. clone disks. > >> > >> having two clone elements in vm will be confusing. > >> > >> -1 > >> > >>> > >>>>> > >>>>> > >>>>> > >>>>> true|false > >>>>> ..., > >>>>> > >>>>> you can simply say if imported vm has element, this is > >>>>> import+clone, otherwise import, > >>>> > >>>> If in the future we will want to enable overriding a VM's params > >>>> on > >>>> import, this will be confusing > >>>> (because a user might want to import a VM and change it's name - > >>>> but > >>>> not clone it if it already exists). > >>> > >>> +1, cloning a vm and changing the vm's metadata (i.e vm's name) > >>> should not be inter-dependent. > >> > >> how exactly this is contradict changing metadata on the fly?, > >> exactly on opposite - it works perfectly well for your use-case: > >> > >> BE logic: > >> -------- > >> > >> if (local) has vm named as on remote > >> (export.domain) > > > > please note "vm exists" is based on vm uuid, not on vm name > > i think it based on name, Omer? I wrote the backend-side, it is by uuid. > > > > >> { > >> if PARAMS != remote (export.domain) > >> { > >> copy + rename > >> } else { > >> error > >> } > >> } else { > >> if PARAMS != remote (export.domain) > >> { > >> copy + rename > >> } else { > >> copy > >> } > >> } > >> > >>> > >>>> > >>>>> as about collapse_snapshots, i don't mind, but this should be > >>>>> done > >>>>> in the way is implemented > >>>>> in collection > >>>> > >>>> Semantically, a snapshot is a point in time of a VM. It not only > >>>> associated any more only with the VM's > >>>> disks; it includes the VM's meta-data as well. For this reason, > >>>> maybe > >>>> the parameter collapse_snapshots > >>>> should not be in collection (although, technically, the > >>>> collapse will be done on disks) > >>> > >>> +1, I think the collapse_snapshots should be in the vm context > >>> (snapshots is under vm). > >> > >> i meant, see my other email on this. > >> > >>> > >>> Other than that, currently, if you want to clone a vm, it must be > >>> 'collapsed snapshots', so > >>> the flow to clone a vm (with your suggestion) will be: > >>> > >>> > >>> > >>> new_vm > >>> > >>> true > >>> > >>> > >>> true > >>> > >>> > >>> where collapse_snapshot should be superior to clone, this > >>> structure is a bit confusing. > >>> > >>>> > >>>>> > >>>>> > >>>>>> better suggestions? > >>>>>> > >>>>>> Thanks, > >>>>>> Gilad > >>>>> > >>>>> > >>>>> -- > >>>>> > >>>>> Michael Pasternak > >>>>> RedHat, ENG-Virtualization R&D > >>>> > >> > >> > > > > > -- > > Michael Pasternak > RedHat, ENG-Virtualization R&D > From iheim at redhat.com Wed May 16 13:05:50 2012 From: iheim at redhat.com (Itamar Heim) Date: Wed, 16 May 2012 16:05:50 +0300 Subject: [Engine-devel] restapi: New params for import VM/Template In-Reply-To: <4FB3A254.8090900@redhat.com> References: <57255a02-2a7f-4a2e-be76-1e0ec28c3e0b@zmail14.collab.prod.int.phx2.redhat.com> <4FB3A254.8090900@redhat.com> Message-ID: <4FB3A62E.9070309@redhat.com> On 05/16/2012 03:49 PM, Michael Pasternak wrote: > On 05/16/2012 03:26 PM, Gilad Chaplik wrote: >> >> >> Thanks, >> Gilad. >> >> ----- Original Message ----- >>> From: "Ori Liel" >>> To: "Michael Pasternak" >>> Cc: "engine-devel", "Itamar Heim", "Doron Fediuck", >>> "Gilad Chaplik" >>> Sent: Wednesday, May 16, 2012 2:49:17 PM >>> Subject: Re: restapi: New params for import VM/Template >>> >>>> On 05/16/2012 01:16 PM, Gilad Chaplik wrote: >>>>> Hi All, >>>>> >>>>> I am adding the ability to import a VM or a Template to a >>>>> storage-domain, >>>>> when this VM or Template already exists in the destination storage >>>>> domain. >>>>> Until now, Backend failed this. Now I want to enable the user to >>>>> specify >>>>> that he wishes this VM/Template will be created again by a >>>>> different name, >>>>> i.e - cloned. >>>>> >>>>> [feature page: >>>>> http://www.ovirt.org/wiki/Features/ImportMoreThanOnce] >>>>> >>>>> I plan to achieve this using a new parameter, but I want to reach >>>>> an agreement >>>>> about this parameter's name. I thought simply to call it "clone". >>>>> >>>>> Another thing that I'll do in the patch-set is add the >>>>> currently-missing ability >>>>> to specify whether the snapshots of the VM, which is being >>>>> imported, will >>>>> be collapsed into a single snapshot (we have this ability in GUI). >>>>> I am also >>>>> deliberating about the name of this parameter. I thought about >>>>> "collapse_snapshots" (same as in GUI). >>>>> >>>>> Does anyone think "clone" and "collapse_snapshots" are >>>>> inappropriate and has >>>> >>>> /clone/ already in-use (used to clone vm from template), >> >> clone here has a different context, clone VM vs. clone disks. > > having two clone elements in vm will be confusing. > > -1 > >> >>>> >>>> >>>> >>>> true|false >>>> ..., >>>> >>>> you can simply say if imported vm has element, this is >>>> import+clone, otherwise import, >>> >>> If in the future we will want to enable overriding a VM's params on >>> import, this will be confusing >>> (because a user might want to import a VM and change it's name - but >>> not clone it if it already exists). >> >> +1, cloning a vm and changing the vm's metadata (i.e vm's name) should not be inter-dependent. > > how exactly this is contradict changing metadata on the fly?, > exactly on opposite - it works perfectly well for your use-case: > > BE logic: > -------- > > if (local) has vm named as on remote (export.domain) please note "vm exists" is based on vm uuid, not on vm name > { > if PARAMS != remote (export.domain) > { > copy + rename > } else { > error > } > } else { > if PARAMS != remote (export.domain) > { > copy + rename > } else { > copy > } > } > >> >>> >>>> as about collapse_snapshots, i don't mind, but this should be done >>>> in the way is implemented >>>> in collection >>> >>> Semantically, a snapshot is a point in time of a VM. It not only >>> associated any more only with the VM's >>> disks; it includes the VM's meta-data as well. For this reason, maybe >>> the parameter collapse_snapshots >>> should not be in collection (although, technically, the >>> collapse will be done on disks) >> >> +1, I think the collapse_snapshots should be in the vm context (snapshots is under vm). > > i meant, see my other email on this. > >> >> Other than that, currently, if you want to clone a vm, it must be 'collapsed snapshots', so >> the flow to clone a vm (with your suggestion) will be: >> >> >> >> new_vm >> >> true >> >> >> true >> >> >> where collapse_snapshot should be superior to clone, this structure is a bit confusing. >> >>> >>>> >>>> >>>>> better suggestions? >>>>> >>>>> Thanks, >>>>> Gilad >>>> >>>> >>>> -- >>>> >>>> Michael Pasternak >>>> RedHat, ENG-Virtualization R&D >>> > > From iheim at redhat.com Wed May 16 13:38:44 2012 From: iheim at redhat.com (Itamar Heim) Date: Wed, 16 May 2012 16:38:44 +0300 Subject: [Engine-devel] restapi: New params for import VM/Template In-Reply-To: <4FB3A905.50903@redhat.com> References: <57255a02-2a7f-4a2e-be76-1e0ec28c3e0b@zmail14.collab.prod.int.phx2.redhat.com> <4FB3A254.8090900@redhat.com> <4FB3A62E.9070309@redhat.com> <4FB3A905.50903@redhat.com> Message-ID: <4FB3ADE4.5080300@redhat.com> On 05/16/2012 04:17 PM, Michael Pasternak wrote: > On 05/16/2012 04:05 PM, Itamar Heim wrote: >> On 05/16/2012 03:49 PM, Michael Pasternak wrote: >>> On 05/16/2012 03:26 PM, Gilad Chaplik wrote: >>>> >>>> >>>> Thanks, >>>> Gilad. >>>> >>>> ----- Original Message ----- >>>>> From: "Ori Liel" >>>>> To: "Michael Pasternak" >>>>> Cc: "engine-devel", "Itamar Heim", "Doron Fediuck", >>>>> "Gilad Chaplik" >>>>> Sent: Wednesday, May 16, 2012 2:49:17 PM >>>>> Subject: Re: restapi: New params for import VM/Template >>>>> >>>>>> On 05/16/2012 01:16 PM, Gilad Chaplik wrote: >>>>>>> Hi All, >>>>>>> >>>>>>> I am adding the ability to import a VM or a Template to a >>>>>>> storage-domain, >>>>>>> when this VM or Template already exists in the destination storage >>>>>>> domain. >>>>>>> Until now, Backend failed this. Now I want to enable the user to >>>>>>> specify >>>>>>> that he wishes this VM/Template will be created again by a >>>>>>> different name, >>>>>>> i.e - cloned. >>>>>>> >>>>>>> [feature page: >>>>>>> http://www.ovirt.org/wiki/Features/ImportMoreThanOnce] >>>>>>> >>>>>>> I plan to achieve this using a new parameter, but I want to reach >>>>>>> an agreement >>>>>>> about this parameter's name. I thought simply to call it "clone". >>>>>>> >>>>>>> Another thing that I'll do in the patch-set is add the >>>>>>> currently-missing ability >>>>>>> to specify whether the snapshots of the VM, which is being >>>>>>> imported, will >>>>>>> be collapsed into a single snapshot (we have this ability in GUI). >>>>>>> I am also >>>>>>> deliberating about the name of this parameter. I thought about >>>>>>> "collapse_snapshots" (same as in GUI). >>>>>>> >>>>>>> Does anyone think "clone" and "collapse_snapshots" are >>>>>>> inappropriate and has >>>>>> >>>>>> /clone/ already in-use (used to clone vm from template), >>>> >>>> clone here has a different context, clone VM vs. clone disks. >>> >>> having two clone elements in vm will be confusing. >>> >>> -1 >>> >>>> >>>>>> >>>>>> >>>>>> >>>>>> true|false >>>>>> ..., >>>>>> >>>>>> you can simply say if imported vm has element, this is >>>>>> import+clone, otherwise import, >>>>> >>>>> If in the future we will want to enable overriding a VM's params on >>>>> import, this will be confusing >>>>> (because a user might want to import a VM and change it's name - but >>>>> not clone it if it already exists). >>>> >>>> +1, cloning a vm and changing the vm's metadata (i.e vm's name) should not be inter-dependent. >>> >>> how exactly this is contradict changing metadata on the fly?, >>> exactly on opposite - it works perfectly well for your use-case: >>> >>> BE logic: >>> -------- >>> >>> if (local) has vm named as on remote (export.domain) >> >> please note "vm exists" is based on vm uuid, not on vm name > > i think it based on name, Omer? two different things: 1. vm name is unique. 2. import vm cannot import an existing vm based on it's uuid (which is what this feature is about). i.e., if i create a vm X, export it, rename X to Y, i will still fail importing X without 'cloning' it (the cloning process is about changing uuid's of vm, disks, nics) > >> >>> { >>> if PARAMS != remote (export.domain) >>> { >>> copy + rename >>> } else { >>> error >>> } >>> } else { >>> if PARAMS != remote (export.domain) >>> { >>> copy + rename >>> } else { >>> copy >>> } >>> } >>> >>>> >>>>> >>>>>> as about collapse_snapshots, i don't mind, but this should be done >>>>>> in the way is implemented >>>>>> in collection >>>>> >>>>> Semantically, a snapshot is a point in time of a VM. It not only >>>>> associated any more only with the VM's >>>>> disks; it includes the VM's meta-data as well. For this reason, maybe >>>>> the parameter collapse_snapshots >>>>> should not be in collection (although, technically, the >>>>> collapse will be done on disks) >>>> >>>> +1, I think the collapse_snapshots should be in the vm context (snapshots is under vm). >>> >>> i meant, see my other email on this. >>> >>>> >>>> Other than that, currently, if you want to clone a vm, it must be 'collapsed snapshots', so >>>> the flow to clone a vm (with your suggestion) will be: >>>> >>>> >>>> >>>> new_vm >>>> >>>> true >>>> >>>> >>>> true >>>> >>>> >>>> where collapse_snapshot should be superior to clone, this structure is a bit confusing. >>>> >>>>> >>>>>> >>>>>> >>>>>>> better suggestions? >>>>>>> >>>>>>> Thanks, >>>>>>> Gilad >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Michael Pasternak >>>>>> RedHat, ENG-Virtualization R&D >>>>> >>> >>> >> > > From mpastern at redhat.com Wed May 16 14:08:56 2012 From: mpastern at redhat.com (Michael Pasternak) Date: Wed, 16 May 2012 17:08:56 +0300 Subject: [Engine-devel] restapi: New params for import VM/Template In-Reply-To: <4FB3ADE4.5080300@redhat.com> References: <57255a02-2a7f-4a2e-be76-1e0ec28c3e0b@zmail14.collab.prod.int.phx2.redhat.com> <4FB3A254.8090900@redhat.com> <4FB3A62E.9070309@redhat.com> <4FB3A905.50903@redhat.com> <4FB3ADE4.5080300@redhat.com> Message-ID: <4FB3B4F8.8050606@redhat.com> On 05/16/2012 04:38 PM, Itamar Heim wrote: >>> >>> please note "vm exists" is based on vm uuid, not on vm name >> >> i think it based on name, Omer? > > two different things: > 1. vm name is unique. > 2. import vm cannot import an existing vm based on it's uuid (which is what this feature is about). > > i.e., if i create a vm X, export it, rename X to Y, i will still fail importing X without 'cloning' it (the cloning process is about changing uuid's of vm, disks, nics) why import not changing ids by definition? this way only collision that might happen is a vm.name ..., i.e 'cannot import vm.x cause vm with same name already exist' ... -- Michael Pasternak RedHat, ENG-Virtualization R&D From iheim at redhat.com Wed May 16 14:05:03 2012 From: iheim at redhat.com (Itamar Heim) Date: Wed, 16 May 2012 17:05:03 +0300 Subject: [Engine-devel] restapi: New params for import VM/Template In-Reply-To: <4FB3B4F8.8050606@redhat.com> References: <57255a02-2a7f-4a2e-be76-1e0ec28c3e0b@zmail14.collab.prod.int.phx2.redhat.com> <4FB3A254.8090900@redhat.com> <4FB3A62E.9070309@redhat.com> <4FB3A905.50903@redhat.com> <4FB3ADE4.5080300@redhat.com> <4FB3B4F8.8050606@redhat.com> Message-ID: <4FB3B40F.2090302@redhat.com> On 05/16/2012 05:08 PM, Michael Pasternak wrote: > On 05/16/2012 04:38 PM, Itamar Heim wrote: >>>> >>>> please note "vm exists" is based on vm uuid, not on vm name >>> >>> i think it based on name, Omer? >> >> two different things: >> 1. vm name is unique. >> 2. import vm cannot import an existing vm based on it's uuid (which is what this feature is about). >> >> i.e., if i create a vm X, export it, rename X to Y, i will still fail importing X without 'cloning' it (the cloning process is about changing uuid's of vm, disks, nics) > > why import not changing ids by definition? this way only collision that might happen > is a vm.name ..., i.e 'cannot import vm.x cause vm with same name already exist' ... > 1. because we didn't have this behavior till now. 2. because for templates you may want to preserve the uuid to move over VMs/chains using it. 3. because import keeping uuid's allows to handle snapshot chains and re-use of template which does not require changing the actual images, still pointing to the low level actual file/chains (can also be fixed by separating internal uuid's and disks/snapshots uuids, but much more work) From mpastern at redhat.com Wed May 16 15:03:21 2012 From: mpastern at redhat.com (Michael Pasternak) Date: Wed, 16 May 2012 18:03:21 +0300 Subject: [Engine-devel] restapi: New params for import VM/Template In-Reply-To: <4FB3B40F.2090302@redhat.com> References: <57255a02-2a7f-4a2e-be76-1e0ec28c3e0b@zmail14.collab.prod.int.phx2.redhat.com> <4FB3A254.8090900@redhat.com> <4FB3A62E.9070309@redhat.com> <4FB3A905.50903@redhat.com> <4FB3ADE4.5080300@redhat.com> <4FB3B4F8.8050606@redhat.com> <4FB3B40F.2090302@redhat.com> Message-ID: <4FB3C1B9.80508@redhat.com> On 05/16/2012 05:05 PM, Itamar Heim wrote: > On 05/16/2012 05:08 PM, Michael Pasternak wrote: >> On 05/16/2012 04:38 PM, Itamar Heim wrote: >>>>> >>>>> please note "vm exists" is based on vm uuid, not on vm name >>>> >>>> i think it based on name, Omer? >>> >>> two different things: >>> 1. vm name is unique. >>> 2. import vm cannot import an existing vm based on it's uuid (which is what this feature is about). >>> >>> i.e., if i create a vm X, export it, rename X to Y, i will still fail importing X without 'cloning' it (the cloning process is about changing uuid's of vm, disks, nics) >> >> why import not changing ids by definition? this way only collision that might happen >> is a vm.name ..., i.e 'cannot import vm.x cause vm with same name already exist' ... >> > > 1. because we didn't have this behavior till now. > 2. because for templates you may want to preserve the uuid to move over VMs/chains using it. > 3. because import keeping uuid's allows to handle snapshot chains and re-use of template which does not require changing the actual images, still pointing to the low level > actual file/chains (can also be fixed by separating internal uuid's and disks/snapshots uuids, but much more work) ok, then implicit re-id can happen when importing already existent entity and only complaint will be entity name (which has to stay unique and user-defined). this way you does not force user to supply /X=true/ arg as it's obvious in this scenario. -- Michael Pasternak RedHat, ENG-Virtualization R&D From mpastern at redhat.com Wed May 16 15:06:15 2012 From: mpastern at redhat.com (Michael Pasternak) Date: Wed, 16 May 2012 18:06:15 +0300 Subject: [Engine-devel] restapi: New params for import VM/Template In-Reply-To: <4FB3B40F.2090302@redhat.com> References: <57255a02-2a7f-4a2e-be76-1e0ec28c3e0b@zmail14.collab.prod.int.phx2.redhat.com> <4FB3A254.8090900@redhat.com> <4FB3A62E.9070309@redhat.com> <4FB3A905.50903@redhat.com> <4FB3ADE4.5080300@redhat.com> <4FB3B4F8.8050606@redhat.com> <4FB3B40F.2090302@redhat.com> Message-ID: <4FB3C267.1010203@redhat.com> On 05/16/2012 05:05 PM, Itamar Heim wrote: > On 05/16/2012 05:08 PM, Michael Pasternak wrote: >> On 05/16/2012 04:38 PM, Itamar Heim wrote: >>>>> >>>>> please note "vm exists" is based on vm uuid, not on vm name >>>> >>>> i think it based on name, Omer? >>> >>> two different things: >>> 1. vm name is unique. >>> 2. import vm cannot import an existing vm based on it's uuid (which is what this feature is about). >>> >>> i.e., if i create a vm X, export it, rename X to Y, i will still fail importing X without 'cloning' it (the cloning process is about changing uuid's of vm, disks, nics) >> >> why import not changing ids by definition? this way only collision that might happen >> is a vm.name ..., i.e 'cannot import vm.x cause vm with same name already exist' ... >> > > 1. because we didn't have this behavior till now. > 2. because for templates you may want to preserve the uuid to move over VMs/chains using it. > 3. because import keeping uuid's allows to handle snapshot chains and re-use of template which does not require changing the actual images, still pointing to the low level > actual file/chains (can also be fixed by separating internal uuid's and disks/snapshots uuids, but much more work) ok, then implicit re-id can happen when importing already existent entity and only complaint will be entity name (which has to stay unique and user-defined). this way you does not force user to supply /X=true/ arg as it's obvious in this scenario. -- Michael Pasternak RedHat, ENG-Virtualization R&D From gchaplik at redhat.com Wed May 16 15:46:06 2012 From: gchaplik at redhat.com (Gilad Chaplik) Date: Wed, 16 May 2012 11:46:06 -0400 (EDT) Subject: [Engine-devel] restapi: New params for import VM/Template In-Reply-To: <4FB3C267.1010203@redhat.com> Message-ID: <675ef1f9-08f2-471f-96ce-027fa1e19636@zmail14.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Michael Pasternak" > To: "Itamar Heim" > Cc: "Omer Frenkel" , "Gilad Chaplik" , "engine-devel" > , "Doron Fediuck" , "Ori Liel" > Sent: Wednesday, May 16, 2012 6:06:15 PM > Subject: Re: restapi: New params for import VM/Template > > On 05/16/2012 05:05 PM, Itamar Heim wrote: > > On 05/16/2012 05:08 PM, Michael Pasternak wrote: > >> On 05/16/2012 04:38 PM, Itamar Heim wrote: > >>>>> > >>>>> please note "vm exists" is based on vm uuid, not on vm name > >>>> > >>>> i think it based on name, Omer? > >>> > >>> two different things: > >>> 1. vm name is unique. > >>> 2. import vm cannot import an existing vm based on it's uuid > >>> (which is what this feature is about). > >>> > >>> i.e., if i create a vm X, export it, rename X to Y, i will still > >>> fail importing X without 'cloning' it (the cloning process is > >>> about changing uuid's of vm, disks, nics) > >> > >> why import not changing ids by definition? this way only collision > >> that might happen > >> is a vm.name ..., i.e 'cannot import vm.x cause vm with same name > >> already exist' ... > >> > > > > 1. because we didn't have this behavior till now. > > 2. because for templates you may want to preserve the uuid to move > > over VMs/chains using it. > > 3. because import keeping uuid's allows to handle snapshot chains > > and re-use of template which does not require changing the actual > > images, still pointing to the low level > > actual file/chains (can also be fixed by separating internal uuid's > > and disks/snapshots uuids, but much more work) > > ok, then implicit re-id can happen when importing already existent > entity and only complaint will be entity name (which has to stay > unique and user-defined). > > this way you does not force user to supply /X=true/ arg as it's > obvious in this scenario. ok, so we agree on: 'collapse_snapshots' under vm->snapshots but I have doubt about the 'implicit clone by name': first of all I don't think it's that obvious for the user. Going FW it would be nice to override parameters in import vm/template (e.g. open similar dialog to new vm dialog in import vm - GUI-wise), and to limit the vm name uniqueness to DC/cluster level (not the entire system) - and [for both of them] not cloning the vm/template - let say because of licensing issues. > > > -- > > Michael Pasternak > RedHat, ENG-Virtualization R&D > From lpeer at redhat.com Thu May 17 06:43:45 2012 From: lpeer at redhat.com (Livnat Peer) Date: Thu, 17 May 2012 09:43:45 +0300 Subject: [Engine-devel] restapi: New params for import VM/Template In-Reply-To: <675ef1f9-08f2-471f-96ce-027fa1e19636@zmail14.collab.prod.int.phx2.redhat.com> References: <675ef1f9-08f2-471f-96ce-027fa1e19636@zmail14.collab.prod.int.phx2.redhat.com> Message-ID: <4FB49E21.9070105@redhat.com> > > Going FW it would be nice to override parameters in import vm/template I agree with you and that's why - As a user I don't think there should be a difference in the API between: - Importing a VM and changing it's name - Importing a VM for the second time The reason you want to add artificial difference between the two scenarios above is because currently there are implementations limitations (changing the image ID while importing is not supported yet) I think that we should solve the limitations in the implementation instead of making our API cumbersome (implicit clone by name and adding some clone entity are both bad IMO). Livnat From gchaplik at redhat.com Thu May 17 07:21:51 2012 From: gchaplik at redhat.com (Gilad Chaplik) Date: Thu, 17 May 2012 03:21:51 -0400 (EDT) Subject: [Engine-devel] restapi: New params for import VM/Template In-Reply-To: <4FB49E21.9070105@redhat.com> Message-ID: <682d97c4-f61a-4112-8dab-5d24f06d21af@zmail14.collab.prod.int.phx2.redhat.com> cc'ing Simon, Hi Simon, I remember we talked about why the engine can't decide implicitly if to clone the vm or not - it should be the user call? Can you share your opinion about that? Thanks, Gilad. ----- Original Message ----- > From: "Livnat Peer" > To: "Gilad Chaplik" > Cc: "Michael Pasternak" , "engine-devel" , "Itamar Heim" > > Sent: Thursday, May 17, 2012 9:43:45 AM > Subject: Re: [Engine-devel] restapi: New params for import VM/Template > > > > > > Going FW it would be nice to override parameters in import > > vm/template > > > I agree with you and that's why - > > As a user I don't think there should be a difference in the API > between: > - Importing a VM and changing it's name > - Importing a VM for the second time > > The reason you want to add artificial difference between the two > scenarios above is because currently there are implementations > limitations (changing the image ID while importing is not supported > yet) > > I think that we should solve the limitations in the implementation > instead of making our API cumbersome (implicit clone by name and > adding > some clone entity are both bad IMO). > > > > Livnat > > From mpastern at redhat.com Thu May 17 07:45:48 2012 From: mpastern at redhat.com (Michael Pasternak) Date: Thu, 17 May 2012 10:45:48 +0300 Subject: [Engine-devel] restapi: New params for import VM/Template In-Reply-To: <4FB49E21.9070105@redhat.com> References: <675ef1f9-08f2-471f-96ce-027fa1e19636@zmail14.collab.prod.int.phx2.redhat.com> <4FB49E21.9070105@redhat.com> Message-ID: <4FB4ACAC.40109@redhat.com> On 05/17/2012 09:43 AM, Livnat Peer wrote: > >> >> Going FW it would be nice to override parameters in import vm/template > > > I agree with you and that's why - > > As a user I don't think there should be a difference in the API between: > - Importing a VM and changing it's name > - Importing a VM for the second time > > The reason you want to add artificial difference between the two > scenarios above is because currently there are implementations > limitations (changing the image ID while importing is not supported yet) > > I think that we should solve the limitations in the implementation > instead of making our API cumbersome (implicit clone by name and adding > some clone entity are both bad IMO). 1. please read carefully my previous email with pseudocode on this thread (it also works for if_exist by id), it's enabling parameters override and it's not /implicit clone by name/, but explicit error when clone is required. 2. the solution i suggested is in engine and not api. > > > > Livnat > -- Michael Pasternak RedHat, ENG-Virtualization R&D From lhornyak at redhat.com Thu May 17 09:13:14 2012 From: lhornyak at redhat.com (Laszlo Hornyak) Date: Thu, 17 May 2012 05:13:14 -0400 (EDT) Subject: [Engine-devel] RefObject In-Reply-To: <09e7bb61-044f-4301-97df-095c30daea8d@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: hi, Thank you for the reviews on the refobject removal patches! Here are some more :) http://gerrit.ovirt.org/4465 http://gerrit.ovirt.org/4501 http://gerrit.ovirt.org/4502 Thank you, Laszlo From dfediuck at redhat.com Thu May 17 11:42:46 2012 From: dfediuck at redhat.com (Doron Fediuck) Date: Thu, 17 May 2012 14:42:46 +0300 Subject: [Engine-devel] CPU Pinning @engine Message-ID: <4FB4E436.50100@redhat.com> Hi All, Currently the VDSM has a CPU pinning hook. We'd like to add better support of it into the engine itself. Here's a design draft to cover it: http://www.ovirt.org/wiki/Features/Design/cpu-pinning Please review and comment if needed. Thanks! -- /d Never say "OOPS!" always say "Ah, Interesting!" From alourie at redhat.com Thu May 17 12:01:37 2012 From: alourie at redhat.com (Alex Lourie) Date: Thu, 17 May 2012 15:01:37 +0300 Subject: [Engine-devel] Feedback requested on name change Message-ID: <4FB4E8A1.30304@redhat.com> We have now separated tools repositories which are built independently from ovirt-engine, for example "ovirt-image-uploader". Our rpms (ovirt-engine) has a dependency on those tools, using the following option: ... Requires: %{name}-image-uploader ... %{name} is substituted by 'ovirt-engine' during build, creating a dependency on "*ovirt-engine-image-uploader*". This, in turn, makes a non-resolved dependency, as the actual package name built for image-uploader is "*ovirt-image-uploader*". We can resolve this by either changing the dependency in our rpms or by changing the tools package names (relevant also for iso-uploader and log-collector). Please let me know which way seems preferable for this. Thanks. -- Alex Lourie. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecohen at redhat.com Thu May 17 12:10:50 2012 From: ecohen at redhat.com (Einav Cohen) Date: Thu, 17 May 2012 08:10:50 -0400 (EDT) Subject: [Engine-devel] custom properties sheet feature page In-Reply-To: <10e82e92-bfbe-4267-afc5-f8c74ed5c495@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: Hi, Please review/comment on the Custom Properties Sheet feature page: http://www.ovirt.org/wiki/Features/CustomPropertiesSheet ---- Thanks, Einav From acathrow at redhat.com Thu May 17 12:32:05 2012 From: acathrow at redhat.com (Andrew Cathrow) Date: Thu, 17 May 2012 08:32:05 -0400 (EDT) Subject: [Engine-devel] custom properties sheet feature page In-Reply-To: Message-ID: <82ef4b53-85a5-486d-8e25-2b91c1be4882@zmail07.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Einav Cohen" > To: "Gilad Chaplik" , "Andrew Cathrow" , "Miki Kenneth" > , "Simon Grinberg" , "Eldan Hildesheim" , "Eldan > Hildesheim" > Cc: engine-devel at ovirt.org > Sent: Thursday, May 17, 2012 8:10:50 AM > Subject: custom properties sheet feature page > > Hi, > > Please review/comment on the Custom Properties Sheet feature page: > http://www.ovirt.org/wiki/Features/CustomPropertiesSheet > It looks great. Are all the keys going to be exposed in the dropdown, or will we have private keys that the user has to know about? > ---- > Thanks, > Einav > From juan.hernandez at redhat.com Thu May 17 12:35:53 2012 From: juan.hernandez at redhat.com (Juan Hernandez) Date: Thu, 17 May 2012 14:35:53 +0200 Subject: [Engine-devel] Feedback requested on name change In-Reply-To: <4FB4E8A1.30304@redhat.com> References: <4FB4E8A1.30304@redhat.com> Message-ID: <4FB4F0A9.4090404@redhat.com> On 05/17/2012 02:01 PM, Alex Lourie wrote: > We have now separated tools repositories which are built independently > from ovirt-engine, for example "ovirt-image-uploader". Our rpms > (ovirt-engine) has a dependency on those tools, using the following option: > > > ... > Requires: %{name}-image-uploader > ... > > > %{name} is substituted by 'ovirt-engine' during build, creating a > dependency on "*ovirt-engine-image-uploader*". This, in turn, makes a > non-resolved dependency, as the actual package name built for > image-uploader is "*ovirt-image-uploader*". > > We can resolve this by either changing the dependency in our rpms or by > changing the tools package names (relevant also for iso-uploader and > log-collector). > > Please let me know which way seems preferable for this. I like more the new shorter package names. In addition they reflect better the fact that they are not subpackages of the engine. But take into account that changing the names means that the upgrade path has to be managed carefully. The new renamed packages should obsolete the old ones. I would also suggest to replace the "Requires: %{name}-whatever" that we currently use with "Requires: %{name}-whatever = %{version}-%{release}". From djasa at redhat.com Thu May 17 12:40:19 2012 From: djasa at redhat.com (David =?UTF-8?Q?Ja=C5=A1a?=) Date: Thu, 17 May 2012 14:40:19 +0200 Subject: [Engine-devel] custom properties sheet feature page In-Reply-To: References: Message-ID: <1337258419.12011.93.camel@dhcp-29-7.brq.redhat.com> Einav Cohen p??e v ?t 17. 05. 2012 v 08:10 -0400: > Hi, > > Please review/comment on the Custom Properties Sheet feature page: > http://www.ovirt.org/wiki/Features/CustomPropertiesSheet > Just my $0.02: The table could have always empty row at the bottom, eliminating one or all [+] buttons and saving user one needless click: [ key1 |v] [ value ] [+] [-] [ key2 |v] [ value ] [+] [-] [ key3 |v] [ value ] [-] [ "please select a key..." |v] The [+] buttons at first and second rows would allow user to insert a row at specified location to make easy custom sorting of the properties (not applicable if properties are auto-sorted, in that case, all [+] buttons can be actually removed). David > ---- > Thanks, > Einav > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel -- David Ja?a, RHCE SPICE QE based in Brno GPG Key: 22C33E24 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24 From ecohen at redhat.com Thu May 17 13:08:10 2012 From: ecohen at redhat.com (Einav Cohen) Date: Thu, 17 May 2012 09:08:10 -0400 (EDT) Subject: [Engine-devel] custom properties sheet feature page In-Reply-To: <82ef4b53-85a5-486d-8e25-2b91c1be4882@zmail07.collab.prod.int.phx2.redhat.com> Message-ID: <1b6c0b31-4072-4c19-8108-97ede5065df5@zmail04.collab.prod.int.phx2.redhat.com> > ----- Original Message ----- > From: "Andrew Cathrow" > Sent: Thursday, May 17, 2012 3:32:05 PM > > ----- Original Message ----- > > From: "Einav Cohen" > > To: "Gilad Chaplik" , "Andrew Cathrow" > > , "Miki Kenneth" > > , "Simon Grinberg" , > > "Eldan Hildesheim" , "Eldan > > Hildesheim" > > Cc: engine-devel at ovirt.org > > Sent: Thursday, May 17, 2012 8:10:50 AM > > Subject: custom properties sheet feature page > > > > Hi, > > > > Please review/comment on the Custom Properties Sheet feature page: > > http://www.ovirt.org/wiki/Features/CustomPropertiesSheet > > > > It looks great. > Are all the keys going to be exposed in the dropdown, or will we have > private keys that the user has to know about? All keys will be exposed; not sure what you mean by "private", but all keys are treated the same today. If we want some kind of differentiation between the keys, it is a another feature... [I could, of course, be missing something, please clarify if I did] > > > > > ---- > > Thanks, > > Einav > > > From acathrow at redhat.com Thu May 17 13:23:23 2012 From: acathrow at redhat.com (Andrew Cathrow) Date: Thu, 17 May 2012 09:23:23 -0400 (EDT) Subject: [Engine-devel] custom properties sheet feature page In-Reply-To: <1b6c0b31-4072-4c19-8108-97ede5065df5@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <8fccb42c-d916-4c7c-94c1-2455bae8e882@zmail07.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Einav Cohen" > To: "Andrew Cathrow" > Cc: engine-devel at ovirt.org, "Gilad Chaplik" , "Miki Kenneth" , "Simon > Grinberg" , "Eldan Hildesheim" , "Eldan Hildesheim" > Sent: Thursday, May 17, 2012 9:08:10 AM > Subject: Re: custom properties sheet feature page > > > ----- Original Message ----- > > From: "Andrew Cathrow" > > Sent: Thursday, May 17, 2012 3:32:05 PM > > > > ----- Original Message ----- > > > From: "Einav Cohen" > > > To: "Gilad Chaplik" , "Andrew Cathrow" > > > , "Miki Kenneth" > > > , "Simon Grinberg" , > > > "Eldan Hildesheim" , "Eldan > > > Hildesheim" > > > Cc: engine-devel at ovirt.org > > > Sent: Thursday, May 17, 2012 8:10:50 AM > > > Subject: custom properties sheet feature page > > > > > > Hi, > > > > > > Please review/comment on the Custom Properties Sheet feature > > > page: > > > http://www.ovirt.org/wiki/Features/CustomPropertiesSheet > > > > > > > It looks great. > > Are all the keys going to be exposed in the dropdown, or will we > > have > > private keys that the user has to know about? > > All keys will be exposed; not sure what you mean by "private", but > all keys are treated the same today. if we're exposing all (which is preferable) then it's perfect. > If we want some kind of differentiation between the keys, it is a > another feature... > [I could, of course, be missing something, please clarify if I did] > > > > > > > > > > ---- > > > Thanks, > > > Einav > > > > > > From gkotton at redhat.com Thu May 17 13:24:21 2012 From: gkotton at redhat.com (Gary Kotton) Date: Thu, 17 May 2012 16:24:21 +0300 Subject: [Engine-devel] CPU Pinning @engine In-Reply-To: <4FB4E436.50100@redhat.com> References: <4FB4E436.50100@redhat.com> Message-ID: <4FB4FC05.4040002@redhat.com> On 05/17/2012 02:42 PM, Doron Fediuck wrote: > Hi All, > Currently the VDSM has a CPU pinning hook. > We'd like to add better support of it into the engine itself. > Here's a design draft to cover it: http://www.ovirt.org/wiki/Features/Design/cpu-pinning > > Please review and comment if needed. Hi, I have a number of comments: 1. Will the user have any indication for the maximum amount of vCPU's? 2. What happens if a VM is already configured with the same CPU pin info? Will this be shared? 3. Would it possible to extend this to limit the MHz of CPU that can be allocated to a VM? 5. If the VM has more than one core, will each core have to be mapped? 6. "similar to the existing hook Shahar wrote" - can you please put a link the the hook that Shahar wrote. :) This will be helpful for those of us unfamiliar with it. 7. Why will live migration not be supported? What is the gap to have this type of support? Thanks Gary > Thanks! From ecohen at redhat.com Thu May 17 13:30:37 2012 From: ecohen at redhat.com (Einav Cohen) Date: Thu, 17 May 2012 09:30:37 -0400 (EDT) Subject: [Engine-devel] custom properties sheet feature page In-Reply-To: <1337258419.12011.93.camel@dhcp-29-7.brq.redhat.com> Message-ID: <90b0ad78-b4ff-4c43-aae5-5e9a41da6e2e@zmail04.collab.prod.int.phx2.redhat.com> > ----- Original Message ----- > From: "David Ja?a" > Sent: Thursday, May 17, 2012 3:40:19 PM > > Einav Cohen p??e v ?t 17. 05. 2012 v 08:10 -0400: > > Hi, > > > > Please review/comment on the Custom Properties Sheet feature page: > > http://www.ovirt.org/wiki/Features/CustomPropertiesSheet > > > > Just my $0.02: > > The table could have always empty row at the bottom, eliminating one > or > all [+] buttons and saving user one needless click: > > [ key1 |v] [ value ] [+] [-] > [ key2 |v] [ value ] [+] [-] > [ key3 |v] [ value ] [-] > [ "please select a key..." |v] > > The [+] buttons at first and second rows would allow user to insert a > row at specified location to make easy custom sorting of the > properties > (not applicable if properties are auto-sorted, in that case, all [+] > buttons can be actually removed). Thanks for the input, David. This is an interesting idea. Indeed, when choosing a key in the last row, we can automatically add a new "please select a key..." row, which actually saves the user a button-click for adding a new row. On the other hand, from graphic-design point of view, it will look more consistent and "pretty" if: - The "please select a key..." row won't be displayed (unless, or course, the user explicitly chose to add another row) - All (full) rows will have both [+] and [-] buttons next to them i.e., instead of your suggestion, which looks like this: [ key1 |v] [ value ] [+] [-] [ key2 |v] [ value ] [+] [-] [ key3 |v] [ value ] [-] [ "please select a key..." |v] it will be "prettier" like this: [ key1 |v] [ value ] [+] [-] [ key2 |v] [ value ] [+] [-] [ key3 |v] [ value ] [+] [-] and only if clicking on [+], it will be: [ key1 |v] [ value ] [+] [-] [ key2 |v] [ value ] [+] [-] [ key3 |v] [ value ] [+] [-] [ "please select a key..." |v] I believe that auto-sorting can be confusing, as it can result in rows "jumping" up and down whenever changing the selection(s) in the Key drop-down(s), therefore I don't think it is a good idea to implement it here. > > David > > > ---- > > Thanks, > > Einav > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > -- > > David Ja?a, RHCE > > SPICE QE based in Brno > GPG Key: 22C33E24 > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24 > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > From djasa at redhat.com Thu May 17 13:44:10 2012 From: djasa at redhat.com (David =?UTF-8?Q?Ja=C5=A1a?=) Date: Thu, 17 May 2012 15:44:10 +0200 Subject: [Engine-devel] custom properties sheet feature page In-Reply-To: <90b0ad78-b4ff-4c43-aae5-5e9a41da6e2e@zmail04.collab.prod.int.phx2.redhat.com> References: <90b0ad78-b4ff-4c43-aae5-5e9a41da6e2e@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <1337262250.12011.102.camel@dhcp-29-7.brq.redhat.com> Einav Cohen p??e v ?t 17. 05. 2012 v 09:30 -0400: > > ----- Original Message ----- > > From: "David Ja?a" > > Sent: Thursday, May 17, 2012 3:40:19 PM > > > > Einav Cohen p??e v ?t 17. 05. 2012 v 08:10 -0400: > > > Hi, > > > > > > Please review/comment on the Custom Properties Sheet feature page: > > > http://www.ovirt.org/wiki/Features/CustomPropertiesSheet > > > > > > > Just my $0.02: > > > > The table could have always empty row at the bottom, eliminating one > > or > > all [+] buttons and saving user one needless click: > > > > [ key1 |v] [ value ] [+] [-] > > [ key2 |v] [ value ] [+] [-] > > [ key3 |v] [ value ] [-] > > [ "please select a key..." |v] > > > > The [+] buttons at first and second rows would allow user to insert a > > row at specified location to make easy custom sorting of the > > properties > > (not applicable if properties are auto-sorted, in that case, all [+] > > buttons can be actually removed). > > Thanks for the input, David. This is an interesting idea. > > Indeed, when choosing a key in the last row, we can automatically add a new "please select a key..." row, which actually saves the user a button-click for adding a new row. > > On the other hand, from graphic-design point of view, it will look more consistent and "pretty" if: > - The "please select a key..." row won't be displayed (unless, or course, the user explicitly chose to add another row) > - All (full) rows will have both [+] and [-] buttons next to them If the [+] button in my proposal is just greyed out instead of ommited, it could satisfy both requirements. > > i.e., instead of your suggestion, which looks like this: > > [ key1 |v] [ value ] [+] [-] > [ key2 |v] [ value ] [+] [-] > [ key3 |v] [ value ] [-] > [ "please select a key..." |v] > > it will be "prettier" like this: > > [ key1 |v] [ value ] [+] [-] > [ key2 |v] [ value ] [+] [-] > [ key3 |v] [ value ] [+] [-] > > and only if clicking on [+], it will be: > > [ key1 |v] [ value ] [+] [-] > [ key2 |v] [ value ] [+] [-] > [ key3 |v] [ value ] [+] [-] > [ "please select a key..." |v] > > I believe that auto-sorting can be confusing, as it can result in rows "jumping" up and down whenever changing the selection(s) in the Key drop-down(s), this could be sort of mitigated by sorting server-side upon modification. > therefore I don't think it is a good idea to implement it here. OTOH if we're to be manual sorting friendly, we should allow rearranging of the rows by drag & drop or by some sort of move up/down buttons and the dialog would start to be cluttered. I don't really like either of these but auto-sort is slightly better IMO as it is kept consistent accross various VMs without user interaction. David > > > > > David > > > > > ---- > > > Thanks, > > > Einav > > > _______________________________________________ > > > Engine-devel mailing list > > > Engine-devel at ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > -- > > > > David Ja?a, RHCE > > > > SPICE QE based in Brno > > GPG Key: 22C33E24 > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24 > > > > > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > -- David Ja?a, RHCE SPICE QE based in Brno GPG Key: 22C33E24 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24 From dlaor at redhat.com Thu May 17 14:04:10 2012 From: dlaor at redhat.com (Dor Laor) Date: Thu, 17 May 2012 17:04:10 +0300 Subject: [Engine-devel] CPU Pinning @engine In-Reply-To: <4FB4FC05.4040002@redhat.com> References: <4FB4E436.50100@redhat.com> <4FB4FC05.4040002@redhat.com> Message-ID: <4FB5055A.7040204@redhat.com> On 05/17/2012 04:24 PM, Gary Kotton wrote: > On 05/17/2012 02:42 PM, Doron Fediuck wrote: >> Hi All, >> Currently the VDSM has a CPU pinning hook. >> We'd like to add better support of it into the engine itself. >> Here's a design draft to cover it: >> http://www.ovirt.org/wiki/Features/Design/cpu-pinning >> >> Please review and comment if needed. > Hi, > I have a number of comments: > 1. Will the user have any indication for the maximum amount of vCPU's? > 2. What happens if a VM is already configured with the same CPU pin > info? Will this be shared? > 3. Would it possible to extend this to limit the MHz of CPU that can be > allocated to a VM? > 5. If the VM has more than one core, will each core have to be mapped? > 6. "similar to the existing hook Shahar wrote" - can you please put a > link the the hook that Shahar wrote. :) This will be helpful for those > of us unfamiliar with it. > 7. Why will live migration not be supported? What is the gap to have > this type of support? +1 on the above. In addition, it should be nice to reveal the host cpu topology so the user will be able to match the virtual one. Getting the hyperthread topology is important factor as well. Numa is not mentioned at all. It should be highly desirable to expose the numa topology and add numa pinning using numactl. Since you're refactoring this code, adding options for the new numda daemon would be important too. Another important factor is the ability to pin not only the vcpu threads but also to pin 'service threads' in the host, potential to other physical cpus. Examples for such are the qemu io thread, vhost threads, etc. Regards, Dor > Thanks > Gary >> Thanks! > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From ecohen at redhat.com Thu May 17 14:14:37 2012 From: ecohen at redhat.com (Einav Cohen) Date: Thu, 17 May 2012 10:14:37 -0400 (EDT) Subject: [Engine-devel] custom properties sheet feature page In-Reply-To: <1337262250.12011.102.camel@dhcp-29-7.brq.redhat.com> Message-ID: > ----- Original Message ----- > From: "David Ja?a" > Sent: Thursday, May 17, 2012 4:44:10 PM > > Einav Cohen p??e v ?t 17. 05. 2012 v 09:30 -0400: > > > ----- Original Message ----- > > > From: "David Ja?a" > > > Sent: Thursday, May 17, 2012 3:40:19 PM > > > > > > Einav Cohen p??e v ?t 17. 05. 2012 v 08:10 -0400: > > > > Hi, > > > > > > > > Please review/comment on the Custom Properties Sheet feature > > > > page: > > > > http://www.ovirt.org/wiki/Features/CustomPropertiesSheet > > > > > > > > > > Just my $0.02: > > > > > > The table could have always empty row at the bottom, eliminating > > > one > > > or > > > all [+] buttons and saving user one needless click: > > > > > > [ key1 |v] [ value ] [+] [-] > > > [ key2 |v] [ value ] [+] [-] > > > [ key3 |v] [ value ] [-] > > > [ "please select a key..." |v] > > > > > > The [+] buttons at first and second rows would allow user to > > > insert a > > > row at specified location to make easy custom sorting of the > > > properties > > > (not applicable if properties are auto-sorted, in that case, all > > > [+] > > > buttons can be actually removed). > > > > Thanks for the input, David. This is an interesting idea. > > > > Indeed, when choosing a key in the last row, we can automatically > > add a new "please select a key..." row, which actually saves the > > user a button-click for adding a new row. > > > > On the other hand, from graphic-design point of view, it will look > > more consistent and "pretty" if: > > - The "please select a key..." row won't be displayed (unless, or > > course, the user explicitly chose to add another row) > > - All (full) rows will have both [+] and [-] buttons next to them > > If the [+] button in my proposal is just greyed out instead of > ommited, > it could satisfy both requirements. Almost; the "please select a key..." row is still always displayed; question is if we want to save a button-click (your suggestion) or to have a "cleaner" sheet (my suggestion). > > > > > i.e., instead of your suggestion, which looks like this: > > > > [ key1 |v] [ value ] [+] [-] > > [ key2 |v] [ value ] [+] [-] > > [ key3 |v] [ value ] [-] > > [ "please select a key..." |v] > > > > it will be "prettier" like this: > > > > [ key1 |v] [ value ] [+] [-] > > [ key2 |v] [ value ] [+] [-] > > [ key3 |v] [ value ] [+] [-] > > > > and only if clicking on [+], it will be: > > > > [ key1 |v] [ value ] [+] [-] > > [ key2 |v] [ value ] [+] [-] > > [ key3 |v] [ value ] [+] [-] > > [ "please select a key..." |v] > > > > I believe that auto-sorting can be confusing, as it can result in > > rows "jumping" up and down whenever changing the selection(s) in > > the Key drop-down(s), > > this could be sort of mitigated by sorting server-side upon > modification. > > > therefore I don't think it is a good idea to implement it here. > > OTOH if we're to be manual sorting friendly, we should allow > rearranging > of the rows by drag & drop or by some sort of move up/down buttons > and > the dialog would start to be cluttered. > > I don't really like either of these but auto-sort is slightly better > IMO > as it is kept consistent accross various VMs without user > interaction. Indeed, auto-sort will keep the order consistent across all VMs. However, maybe the user would like to see the properties in the order in which he filled them; in this case, your suggestion of "move up/down buttons" is probably relevant here. I believe that the majority of use-cases won't require more than 2 or 3 custom properties per VM, so sorting won't be that critical, therefore I assume we can start without it; I will add "sorting" to the "open issues" section in the wiki page. > > David > > > > > > > > > David > > > > > > > ---- > > > > Thanks, > > > > Einav > > > > _______________________________________________ > > > > Engine-devel mailing list > > > > Engine-devel at ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > -- > > > > > > David Ja?a, RHCE > > > > > > SPICE QE based in Brno > > > GPG Key: 22C33E24 > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24 > > > > > > > > > > > > _______________________________________________ > > > Engine-devel mailing list > > > Engine-devel at ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > -- > > David Ja?a, RHCE > > SPICE QE based in Brno > GPG Key: 22C33E24 > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24 > > > > From acathrow at redhat.com Thu May 17 14:38:56 2012 From: acathrow at redhat.com (Andrew Cathrow) Date: Thu, 17 May 2012 10:38:56 -0400 (EDT) Subject: [Engine-devel] CPU Pinning @engine In-Reply-To: <4FB5055A.7040204@redhat.com> Message-ID: <2e53684b-37f2-43b2-b86f-2cc0f5da0d87@zmail07.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Dor Laor" > To: gkotton at redhat.com > Cc: engine-devel at ovirt.org, "Eduardo Habkost" , "Gleb Natapov" > Sent: Thursday, May 17, 2012 10:04:10 AM > Subject: Re: [Engine-devel] CPU Pinning @engine > > On 05/17/2012 04:24 PM, Gary Kotton wrote: > > On 05/17/2012 02:42 PM, Doron Fediuck wrote: > >> Hi All, > >> Currently the VDSM has a CPU pinning hook. > >> We'd like to add better support of it into the engine itself. > >> Here's a design draft to cover it: > >> http://www.ovirt.org/wiki/Features/Design/cpu-pinning > >> > >> Please review and comment if needed. > > Hi, > > I have a number of comments: > > 1. Will the user have any indication for the maximum amount of > > vCPU's? > > 2. What happens if a VM is already configured with the same CPU pin > > info? Will this be shared? Yes > > 3. Would it possible to extend this to limit the MHz of CPU that > > can be > > allocated to a VM? No, that's not supported today in KVM. In the future we should use cgroups to provide prioritization as part of the future SLA feature. > > 5. If the VM has more than one core, will each core have to be > > mapped? yes > > 6. "similar to the existing hook Shahar wrote" - can you please put > > a > > link the the hook that Shahar wrote. :) This will be helpful for > > those > > of us unfamiliar with it. http://gerrit.ovirt.org/gitweb?p=vdsm.git;a=tree;f=vdsm_hooks/pincpu;h=fd7a1a85912504d6b0cc8ae4e8123d71bf3c2741;hb=HEAD But basically it's the same syntax as libvirt uses today. > > 7. Why will live migration not be supported? What is the gap to > > have > > this type of support? There's been disagreement here. The argument against it is that if you have heterogeneous hardware then it might not work. eg. If I pin on vCPU 10-11 on host A and and host B only has 8 CPUs .... I'd argue that if an admin is doing the pinning then it's up to him to make sure he picks a sensible value > > +1 on the above. > > In addition, it should be nice to reveal the host cpu topology so the > user will be able to match the virtual one. > Getting the hyperthread topology is important factor as well. > > Numa is not mentioned at all. It should be highly desirable to expose > the numa topology and add numa pinning using numactl. > Since you're refactoring this code, adding options for the new numda > daemon would be important too. > > Another important factor is the ability to pin not only the vcpu > threads > but also to pin 'service threads' in the host, potential to other > physical cpus. Examples for such are the qemu io thread, vhost > threads, etc. > > Regards, > Dor > > > Thanks > > Gary > >> Thanks! > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From dfediuck at redhat.com Thu May 17 14:58:16 2012 From: dfediuck at redhat.com (Doron Fediuck) Date: Thu, 17 May 2012 17:58:16 +0300 Subject: [Engine-devel] CPU Pinning @engine In-Reply-To: <2e53684b-37f2-43b2-b86f-2cc0f5da0d87@zmail07.collab.prod.int.phx2.redhat.com> References: <2e53684b-37f2-43b2-b86f-2cc0f5da0d87@zmail07.collab.prod.int.phx2.redhat.com> Message-ID: <4FB51208.7070900@redhat.com> On 17/05/12 17:38, Andrew Cathrow wrote: > > > ----- Original Message ----- >> From: "Dor Laor" >> To: gkotton at redhat.com >> Cc: engine-devel at ovirt.org, "Eduardo Habkost" , "Gleb Natapov" >> Sent: Thursday, May 17, 2012 10:04:10 AM >> Subject: Re: [Engine-devel] CPU Pinning @engine >> >> On 05/17/2012 04:24 PM, Gary Kotton wrote: >>> On 05/17/2012 02:42 PM, Doron Fediuck wrote: >>>> Hi All, >>>> Currently the VDSM has a CPU pinning hook. >>>> We'd like to add better support of it into the engine itself. >>>> Here's a design draft to cover it: >>>> http://www.ovirt.org/wiki/Features/Design/cpu-pinning >>>> >>>> Please review and comment if needed. >>> Hi, >>> I have a number of comments: >>> 1. Will the user have any indication for the maximum amount of >>> vCPU's? > > >>> 2. What happens if a VM is already configured with the same CPU pin >>> info? Will this be shared? > > Yes > >>> 3. Would it possible to extend this to limit the MHz of CPU that >>> can be >>> allocated to a VM? > > No, that's not supported today in KVM. In the future we should use cgroups to provide prioritization as part of the future SLA feature. > > >>> 5. If the VM has more than one core, will each core have to be >>> mapped? > > yes > >>> 6. "similar to the existing hook Shahar wrote" - can you please put >>> a >>> link the the hook that Shahar wrote. :) This will be helpful for >>> those >>> of us unfamiliar with it. > > http://gerrit.ovirt.org/gitweb?p=vdsm.git;a=tree;f=vdsm_hooks/pincpu;h=fd7a1a85912504d6b0cc8ae4e8123d71bf3c2741;hb=HEAD > But basically it's the same syntax as libvirt uses today. > > > >>> 7. Why will live migration not be supported? What is the gap to >>> have >>> this type of support? > > There's been disagreement here. > The argument against it is that if you have heterogeneous hardware then it might not work. > eg. If I pin on vCPU 10-11 on host A and and host B only has 8 CPUs .... > I'd argue that if an admin is doing the pinning then it's up to him to make sure he picks a sensible value > >> >> +1 on the above. >> >> In addition, it should be nice to reveal the host cpu topology so the >> user will be able to match the virtual one. >> Getting the hyperthread topology is important factor as well. >> >> Numa is not mentioned at all. It should be highly desirable to expose >> the numa topology and add numa pinning using numactl. >> Since you're refactoring this code, adding options for the new numda >> daemon would be important too. >> >> Another important factor is the ability to pin not only the vcpu >> threads >> but also to pin 'service threads' in the host, potential to other >> physical cpus. Examples for such are the qemu io thread, vhost >> threads, etc. >> >> Regards, >> Dor >> >>> Thanks >>> Gary >>>> Thanks! >>> +1 on Andrew's answers. Just want to add a general comment- CPU tuning can evolve into something which is much bigger. I choose to start with a humble pinning support, which I know is already being used today using vdsm hook. Having it in the engine (even in a basic mode) will be more friendly and helpful to many users. Going forward we have a lot of grounds to cover in this area, including NUMA and other exciting features, which we'll gradually introduce as the community allows. -- /d "All computers wait at the same speed." From abaron at redhat.com Thu May 17 17:28:53 2012 From: abaron at redhat.com (Ayal Baron) Date: Thu, 17 May 2012 13:28:53 -0400 (EDT) Subject: [Engine-devel] CPU Pinning @engine In-Reply-To: <4FB4E436.50100@redhat.com> Message-ID: <8cec63b1-c0e9-4914-be11-de2bfbabc85a@abaron.usersys.redhat.com> "Live migration will not be supported for such VM's." Migration will work on homogeneous clusters so this should not be enforced (not limited to VMs which are pinned to host) just give a warning. ----- Original Message ----- > From: "Doron Fediuck" > To: engine-devel at ovirt.org > Sent: Thursday, May 17, 2012 2:42:46 PM > Subject: [Engine-devel] CPU Pinning @engine > > Hi All, > Currently the VDSM has a CPU pinning hook. > We'd like to add better support of it into the engine itself. > Here's a design draft to cover it: > http://www.ovirt.org/wiki/Features/Design/cpu-pinning > > Please review and comment if needed. > > Thanks! > -- > > /d > > Never say "OOPS!" always say "Ah, Interesting!" > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From juan.hernandez at redhat.com Thu May 17 20:13:50 2012 From: juan.hernandez at redhat.com (Juan Hernandez) Date: Thu, 17 May 2012 22:13:50 +0200 Subject: [Engine-devel] IMPORTANT: Root web application moved Message-ID: <4FB55BFE.4080200@redhat.com> Hello, I have recently merged a change that moves the root web application to the .ear directory: http://gerrit.ovirt.org/3782 This change could break your environment if you apply the patch and you don't do a clean installation. You may find an error like this in your server log and the application can fail to deploy: JBAS014777: Services which failed to start: service jboss.web.deployment.default-host./: org.jboss.msc.service.StartException in service jboss.web.deployment.default-host./: Failed to start service That means that you have more than one / application. Please make sure that you don't have the old ROOT.war in your deployment directory. Just remove it and the corresponding ROOT.war.dodeploy file. Also make sure that you don't have the following parameter in your standalone.xml file: enable-welcome-root="true" Change the value to "false". None of this actions are needed if you are building new RPMs and doing a clean installation. If you still have problems starting the application server after applying this change please let me know. Regards, Juan Hernandez From dfediuck at redhat.com Thu May 17 20:15:14 2012 From: dfediuck at redhat.com (Doron Fediuck) Date: Thu, 17 May 2012 23:15:14 +0300 Subject: [Engine-devel] CPU Pinning @engine In-Reply-To: <8cec63b1-c0e9-4914-be11-de2bfbabc85a@abaron.usersys.redhat.com> References: <8cec63b1-c0e9-4914-be11-de2bfbabc85a@abaron.usersys.redhat.com> Message-ID: <4FB55C52.5000609@redhat.com> On 17/05/12 20:28, Ayal Baron wrote: > "Live migration will not be supported for such VM's." > > Migration will work on homogeneous clusters so this should not be enforced (not limited to VMs which are pinned to host) just give a warning. > I agree, but if we wish to ping vCPUx to pCPUy in host a, we cannot ensure to have the same in host b, since it may have pCPUy too busy, so performance will degrade. Also, I hope you saw my general comment about starting with a humble solution and gradually improving. In this context (auto)numa can help us, so we better do numa than handle migration for basic mode, risking performance issues. > > ----- Original Message ----- >> From: "Doron Fediuck" >> To: engine-devel at ovirt.org >> Sent: Thursday, May 17, 2012 2:42:46 PM >> Subject: [Engine-devel] CPU Pinning @engine >> >> Hi All, >> Currently the VDSM has a CPU pinning hook. >> We'd like to add better support of it into the engine itself. >> Here's a design draft to cover it: >> http://www.ovirt.org/wiki/Features/Design/cpu-pinning >> >> Please review and comment if needed. >> >> Thanks! >> -- >> >> /d >> >> Never say "OOPS!" always say "Ah, Interesting!" >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel -- /d "Common sense is not so common." --Voltaire, Dictionnaire Philosophique (1764) From iheim at redhat.com Thu May 17 22:50:17 2012 From: iheim at redhat.com (Itamar Heim) Date: Fri, 18 May 2012 01:50:17 +0300 Subject: [Engine-devel] custom properties sheet feature page In-Reply-To: <1b6c0b31-4072-4c19-8108-97ede5065df5@zmail04.collab.prod.int.phx2.redhat.com> References: <1b6c0b31-4072-4c19-8108-97ede5065df5@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4FB580A9.8090208@redhat.com> On 05/17/2012 04:08 PM, Einav Cohen wrote: ... >>> Hi, >>> >>> Please review/comment on the Custom Properties Sheet feature page: >>> http://www.ovirt.org/wiki/Features/CustomPropertiesSheet >>> >> >> It looks great. >> Are all the keys going to be exposed in the dropdown, or will we have >> private keys that the user has to know about? > > All keys will be exposed; not sure what you mean by "private", but all keys are treated the same today. > If we want some kind of differentiation between the keys, it is a another feature... > [I could, of course, be missing something, please clarify if I did] > in the future, we may want to give permissions to which users are allowed to use which custom properties. not relevant for now. From iheim at redhat.com Thu May 17 23:19:41 2012 From: iheim at redhat.com (Itamar Heim) Date: Fri, 18 May 2012 02:19:41 +0300 Subject: [Engine-devel] oVirt and Quantum In-Reply-To: <9D25E123B44F4A4291F4B5C13DA94E7725115351@mtrdag02.mtl.com> References: <4F9D1AD4.8070503@redhat.com> <4F9E41AE.6030302@redhat.com> <4F9E7DB1.1010409@redhat.com> <9D25E123B44F4A4291F4B5C13DA94E772510FFEA@mtrdag02.mtl.com> <4FA27790.5080308@redhat.com> <4FB23397.50102@redhat.com> <9D25E123B44F4A4291F4B5C13DA94E772511530B@mtrdag02.mtl.com> <4FB24066.70009@redhat.com> <9D25E123B44F4A4291F4B5C13DA94E7725115351@mtrdag02.mtl.com> Message-ID: <4FB5878D.1040209@redhat.com> On 05/15/2012 02:55 PM, Irena Berezovsky wrote: ... >> ovirt engine keeps it. how would one query by it though? what api and credentials would they be using to do so? >> [IB] I think it should be accessible via REST and SDK . >> I guess it should use admin credentials, but not sure. > > REST doesn't support lookup by every property and the is search for vnics/ports. > so a modeling question. > I'm not sure i like the concept of providing an administrative user credentials to all hosts, or of managing a password change in this case. > not sure hosts should use the REST API, or another API intended for bi-directional communication with engine, secured in the same way the xml/rpc is secured. > > [IB2] Considering Quantum plugin implementation, I guess that may also handle physical Network configuration (Network between Hypervisors). In such case Quantum Plugin will need to resolve for VIF UUID plugged to certain network on what Server it is deployed. I think is the best way is to get it via SDK or REST. Do you have any suggestion? from what i understand, this isn't about using quantum for the non vm networks (management, storage, live migration, etc.) we need to find a solution to passing needed info for agents/drivers through supported communication channels. yes, the REST API is there, but i don't see a provisioning process providing hosts with credentials to access the REST API (or as specified above, REST API having a query to match the requested information). OTOH, it could make sense to have hosts pull various type of configuration information relevant to them from ovirt engine via an api limited to hosts, based on their hosts certificates. then have agents use this as the supported communication channel. >> >>>> VM Migrate: >>>> Even though it's just an initial suggestion, I think that VM >>>> migration use case should be elaborated also for 'else' cases. What >>>> happens if target Host does not support Quantum? What happens if >>>> target host fails to run VM? Another issue is a lack of calls to >>>> Quantum. For my understanding (but I can be wrong) in OpenStack it >>>> will issue unplug and plug attachment calls. >>> I agree. The goal here should be VM uptime and connectivity. If the >>> "network" connectivity can be support but in a limited fashion then >>> great - the migration can take place - this should nonetheless only >>> be done when there is no other option. The live migration algorithm >>> may have to be tweaked to support this. >> >> we do not assume involvement in engine in live migration today other than issuing a 'migrate' command to source host, or host needing information from engine to perform the live migration. >> there must be a very good reason to break this assumption. >> [IB] If this assumption should be in place, maybe it worth to consider to invoke 'create port' and 'plug interface' Quantum calls from VDSM node and not from oVirt engine. This this the model in OpenStack. Nova-compute invokes 'create port' and 'plug interface' Quantum calls. >> It is described in the following doc: >> http://wiki.openstack.org/QuantumAPIUseCases > > I'm not sure i like that better. > would it be possible for engine to pre-provision the port on more than one host? > [IB2] For my understanding, definition of port on the Network just defines a logical port and does not apply the physical location. Regarding the interface plugging it probably should work for plugging same interface more than once temporarily during VM migration phase. if it doesn't provide physical location, then i am not sure i understand why another call is required to begin with? From djasa at redhat.com Fri May 18 08:33:44 2012 From: djasa at redhat.com (David =?UTF-8?Q?Ja=C5=A1a?=) Date: Fri, 18 May 2012 10:33:44 +0200 Subject: [Engine-devel] custom properties sheet feature page In-Reply-To: References: Message-ID: <1337330024.12011.141.camel@dhcp-29-7.brq.redhat.com> Einav Cohen p??e v ?t 17. 05. 2012 v 10:14 -0400: > > ----- Original Message ----- > > From: "David Ja?a" > > Sent: Thursday, May 17, 2012 4:44:10 PM > > > > Einav Cohen p??e v ?t 17. 05. 2012 v 09:30 -0400: > > > > ----- Original Message ----- > > > > From: "David Ja?a" > > > > Sent: Thursday, May 17, 2012 3:40:19 PM > > > > > > > > Einav Cohen p??e v ?t 17. 05. 2012 v 08:10 -0400: > > > > > Hi, > > > > > > > > > > Please review/comment on the Custom Properties Sheet feature > > > > > page: > > > > > http://www.ovirt.org/wiki/Features/CustomPropertiesSheet > > > > > > > > > > > > > Just my $0.02: > > > > > > > > The table could have always empty row at the bottom, eliminating > > > > one > > > > or > > > > all [+] buttons and saving user one needless click: > > > > > > > > [ key1 |v] [ value ] [+] [-] > > > > [ key2 |v] [ value ] [+] [-] > > > > [ key3 |v] [ value ] [-] > > > > [ "please select a key..." |v] > > > > > > > > The [+] buttons at first and second rows would allow user to > > > > insert a > > > > row at specified location to make easy custom sorting of the > > > > properties > > > > (not applicable if properties are auto-sorted, in that case, all > > > > [+] > > > > buttons can be actually removed). > > > > > > Thanks for the input, David. This is an interesting idea. > > > > > > Indeed, when choosing a key in the last row, we can automatically > > > add a new "please select a key..." row, which actually saves the > > > user a button-click for adding a new row. > > > > > > On the other hand, from graphic-design point of view, it will look > > > more consistent and "pretty" if: > > > - The "please select a key..." row won't be displayed (unless, or > > > course, the user explicitly chose to add another row) > > > - All (full) rows will have both [+] and [-] buttons next to them I should have probably elaborated more on this. To me, UI with less elements looks cleaner and prettier even when one of them stands out. There's also nothing wrong with standing out if the element has "special" meaning (one add vs bunch of modify). Specifically, this looks cleaner to my eyes: [ key1 |v] [ value ] [-] [ key2 |v] [ value ] [-] [ key3 |v] [ value ] [-] [ "Please select a key..." |v] than [ key1 |v] [ value ] [+] [-] [ key2 |v] [ value ] [+] [-] [ key3 |v] [ value ] [+] [-] > > > > If the [+] button in my proposal is just greyed out instead of > > ommited, > > it could satisfy both requirements. > > Almost; the "please select a key..." row is still always displayed; question is if we want to save a button-click (your suggestion) or to have a "cleaner" sheet (my suggestion). > > > > > > > > > i.e., instead of your suggestion, which looks like this: > > > > > > [ key1 |v] [ value ] [+] [-] > > > [ key2 |v] [ value ] [+] [-] > > > [ key3 |v] [ value ] [-] > > > [ "please select a key..." |v] > > > > > > it will be "prettier" like this: > > > > > > [ key1 |v] [ value ] [+] [-] > > > [ key2 |v] [ value ] [+] [-] > > > [ key3 |v] [ value ] [+] [-] > > > > > > and only if clicking on [+], it will be: > > > > > > [ key1 |v] [ value ] [+] [-] > > > [ key2 |v] [ value ] [+] [-] > > > [ key3 |v] [ value ] [+] [-] > > > [ "please select a key..." |v] > > > > > > I believe that auto-sorting can be confusing, as it can result in > > > rows "jumping" up and down whenever changing the selection(s) in > > > the Key drop-down(s), > > > > this could be sort of mitigated by sorting server-side upon > > modification. > > > > > therefore I don't think it is a good idea to implement it here. > > > > OTOH if we're to be manual sorting friendly, we should allow > > rearranging > > of the rows by drag & drop or by some sort of move up/down buttons > > and > > the dialog would start to be cluttered. > > > > I don't really like either of these but auto-sort is slightly better > > IMO > > as it is kept consistent accross various VMs without user > > interaction. > > Indeed, auto-sort will keep the order consistent across all VMs. > However, maybe the user would like to see the properties in the order in which he filled them; in this case, your suggestion of "move up/down buttons" is probably relevant here. > > I believe that the majority of use-cases won't require more than 2 or 3 custom properties per VM, so sorting won't be that critical, therefore I assume we can start without it; I will add "sorting" to the "open issues" section in the wiki page. > That seems as more argument in favor of auto sorting. David > > > > David > > > > > > > > > > > > > David > > > > > > > > > ---- > > > > > Thanks, > > > > > Einav > > > > > _______________________________________________ > > > > > Engine-devel mailing list > > > > > Engine-devel at ovirt.org > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > -- > > > > > > > > David Ja?a, RHCE > > > > > > > > SPICE QE based in Brno > > > > GPG Key: 22C33E24 > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24 > > > > > > > > > > > > > > > > _______________________________________________ > > > > Engine-devel mailing list > > > > Engine-devel at ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > -- > > > > David Ja?a, RHCE > > > > SPICE QE based in Brno > > GPG Key: 22C33E24 > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24 > > > > > > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel -- David Ja?a, RHCE SPICE QE based in Brno GPG Key: 22C33E24 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24 From shuming at linux.vnet.ibm.com Fri May 18 09:04:18 2012 From: shuming at linux.vnet.ibm.com (Shu Ming) Date: Fri, 18 May 2012 17:04:18 +0800 Subject: [Engine-devel] Where is the git workspace of "engine-iso-uploader"? Message-ID: <4FB61092.5040903@linux.vnet.ibm.com> Hi, From this page, I am told that it should be in the same workspace as ovirt-engine. http://www.ovirt.org/project/subprojects/ However, I can not find it in ovirt-engine workspace. Where does it go? -- Shu Ming IBM China Systems and Technology Laboratory From ecohen at redhat.com Fri May 18 09:12:54 2012 From: ecohen at redhat.com (Einav Cohen) Date: Fri, 18 May 2012 05:12:54 -0400 (EDT) Subject: [Engine-devel] custom properties sheet feature page In-Reply-To: <1337330024.12011.141.camel@dhcp-29-7.brq.redhat.com> Message-ID: <77017ed0-c13f-465c-bafd-2dafba66a1e8@zmail04.collab.prod.int.phx2.redhat.com> > ----- Original Message ----- > From: "David Ja?a" > Sent: Friday, May 18, 2012 11:33:44 AM > > Einav Cohen p??e v ?t 17. 05. 2012 v 10:14 -0400: > > > ----- Original Message ----- > > > From: "David Ja?a" > > > Sent: Thursday, May 17, 2012 4:44:10 PM > > > > > > Einav Cohen p??e v ?t 17. 05. 2012 v 09:30 -0400: > > > > > ----- Original Message ----- > > > > > From: "David Ja?a" > > > > > Sent: Thursday, May 17, 2012 3:40:19 PM > > > > > > > > > > Einav Cohen p??e v ?t 17. 05. 2012 v 08:10 -0400: > > > > > > Hi, > > > > > > > > > > > > Please review/comment on the Custom Properties Sheet > > > > > > feature > > > > > > page: > > > > > > http://www.ovirt.org/wiki/Features/CustomPropertiesSheet > > > > > > > > > > > > > > > > Just my $0.02: > > > > > > > > > > The table could have always empty row at the bottom, > > > > > eliminating > > > > > one > > > > > or > > > > > all [+] buttons and saving user one needless click: > > > > > > > > > > [ key1 |v] [ value ] [+] [-] > > > > > [ key2 |v] [ value ] [+] [-] > > > > > [ key3 |v] [ value ] [-] > > > > > [ "please select a key..." |v] > > > > > > > > > > The [+] buttons at first and second rows would allow user to > > > > > insert a > > > > > row at specified location to make easy custom sorting of the > > > > > properties > > > > > (not applicable if properties are auto-sorted, in that case, > > > > > all > > > > > [+] > > > > > buttons can be actually removed). > > > > > > > > Thanks for the input, David. This is an interesting idea. > > > > > > > > Indeed, when choosing a key in the last row, we can > > > > automatically > > > > add a new "please select a key..." row, which actually saves > > > > the > > > > user a button-click for adding a new row. > > > > > > > > On the other hand, from graphic-design point of view, it will > > > > look > > > > more consistent and "pretty" if: > > > > - The "please select a key..." row won't be displayed (unless, > > > > or > > > > course, the user explicitly chose to add another row) > > > > - All (full) rows will have both [+] and [-] buttons next to > > > > them > > I should have probably elaborated more on this. To me, UI with less > elements looks cleaner and prettier even when one of them stands out. > There's also nothing wrong with standing out if the element has > "special" meaning (one add vs bunch of modify). > > Specifically, this looks cleaner to my eyes: > > [ key1 |v] [ value ] [-] > [ key2 |v] [ value ] [-] > [ key3 |v] [ value ] [-] > [ "Please select a key..." |v] > > than > > [ key1 |v] [ value ] [+] [-] > [ key2 |v] [ value ] [+] [-] > [ key3 |v] [ value ] [+] [-] > > Note that in your suggestion above, you cannot insert a new key in between existing keys - only at the end; so although "cleaner", it has less functionality (depends also on the sorting, which is another issue; if there is auto-sorting, it doesn't matter). It is also a matter of taste, I guess, so no absolute right or wrong here IMO. [Others - you are welcome to comment as well] > > > > > > > If the [+] button in my proposal is just greyed out instead of > > > ommited, > > > it could satisfy both requirements. > > > > Almost; the "please select a key..." row is still always displayed; > > question is if we want to save a button-click (your suggestion) or > > to have a "cleaner" sheet (my suggestion). > > > > > > > > > > > > > i.e., instead of your suggestion, which looks like this: > > > > > > > > [ key1 |v] [ value ] [+] [-] > > > > [ key2 |v] [ value ] [+] [-] > > > > [ key3 |v] [ value ] [-] > > > > [ "please select a key..." |v] > > > > > > > > it will be "prettier" like this: > > > > > > > > [ key1 |v] [ value ] [+] [-] > > > > [ key2 |v] [ value ] [+] [-] > > > > [ key3 |v] [ value ] [+] [-] > > > > > > > > and only if clicking on [+], it will be: > > > > > > > > [ key1 |v] [ value ] [+] [-] > > > > [ key2 |v] [ value ] [+] [-] > > > > [ key3 |v] [ value ] [+] [-] > > > > [ "please select a key..." |v] > > > > > > > > I believe that auto-sorting can be confusing, as it can result > > > > in > > > > rows "jumping" up and down whenever changing the selection(s) > > > > in > > > > the Key drop-down(s), > > > > > > this could be sort of mitigated by sorting server-side upon > > > modification. > > > > > > > therefore I don't think it is a good idea to implement it > > > > here. > > > > > > OTOH if we're to be manual sorting friendly, we should allow > > > rearranging > > > of the rows by drag & drop or by some sort of move up/down > > > buttons > > > and > > > the dialog would start to be cluttered. > > > > > > I don't really like either of these but auto-sort is slightly > > > better > > > IMO > > > as it is kept consistent accross various VMs without user > > > interaction. > > > > Indeed, auto-sort will keep the order consistent across all VMs. > > However, maybe the user would like to see the properties in the > > order in which he filled them; in this case, your suggestion of > > "move up/down buttons" is probably relevant here. > > > > I believe that the majority of use-cases won't require more than 2 > > or 3 custom properties per VM, so sorting won't be that critical, > > therefore I assume we can start without it; I will add "sorting" > > to the "open issues" section in the wiki page. > > > > That seems as more argument in favor of auto sorting. Or no sorting at all (i.e. simply display in order of filling)... In any case, open issue has been added to the wiki. > > David > > > > > > > David > > > > > > > > > > > > > > > > > David > > > > > > > > > > > ---- > > > > > > Thanks, > > > > > > Einav > > > > > > _______________________________________________ > > > > > > Engine-devel mailing list > > > > > > Engine-devel at ovirt.org > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > -- > > > > > > > > > > David Ja?a, RHCE > > > > > > > > > > SPICE QE based in Brno > > > > > GPG Key: 22C33E24 > > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 > > > > > 3E24 > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Engine-devel mailing list > > > > > Engine-devel at ovirt.org > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > -- > > > > > > David Ja?a, RHCE > > > > > > SPICE QE based in Brno > > > GPG Key: 22C33E24 > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24 > > > > > > > > > > > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > -- > > David Ja?a, RHCE > > SPICE QE based in Brno > GPG Key: 22C33E24 > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24 > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > From gchaplik at redhat.com Fri May 18 09:25:45 2012 From: gchaplik at redhat.com (Gilad Chaplik) Date: Fri, 18 May 2012 05:25:45 -0400 (EDT) Subject: [Engine-devel] custom properties sheet feature page In-Reply-To: <77017ed0-c13f-465c-bafd-2dafba66a1e8@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <6caf769d-4f82-4ffe-a814-db89cf2d3da7@zmail14.collab.prod.int.phx2.redhat.com> inline Thanks, Gilad. ----- Original Message ----- > From: "Einav Cohen" > To: "David Ja?a" , "Miki Kenneth" , "Andrew Cathrow" , > "Simon Grinberg" , "Eldan Hildesheim" , "Eldan Hildesheim" > , "Gilad Chaplik" > Cc: engine-devel at ovirt.org > Sent: Friday, May 18, 2012 12:12:54 PM > Subject: Re: [Engine-devel] custom properties sheet feature page > > > ----- Original Message ----- > > From: "David Ja?a" > > Sent: Friday, May 18, 2012 11:33:44 AM > > > > Einav Cohen p??e v ?t 17. 05. 2012 v 10:14 -0400: > > > > ----- Original Message ----- > > > > From: "David Ja?a" > > > > Sent: Thursday, May 17, 2012 4:44:10 PM > > > > > > > > Einav Cohen p??e v ?t 17. 05. 2012 v 09:30 -0400: > > > > > > ----- Original Message ----- > > > > > > From: "David Ja?a" > > > > > > Sent: Thursday, May 17, 2012 3:40:19 PM > > > > > > > > > > > > Einav Cohen p??e v ?t 17. 05. 2012 v 08:10 -0400: > > > > > > > Hi, > > > > > > > > > > > > > > Please review/comment on the Custom Properties Sheet > > > > > > > feature > > > > > > > page: > > > > > > > http://www.ovirt.org/wiki/Features/CustomPropertiesSheet > > > > > > > > > > > > > > > > > > > Just my $0.02: > > > > > > > > > > > > The table could have always empty row at the bottom, > > > > > > eliminating > > > > > > one > > > > > > or > > > > > > all [+] buttons and saving user one needless click: > > > > > > > > > > > > [ key1 |v] [ value ] [+] [-] > > > > > > [ key2 |v] [ value ] [+] [-] > > > > > > [ key3 |v] [ value ] [-] > > > > > > [ "please select a key..." |v] > > > > > > > > > > > > The [+] buttons at first and second rows would allow user > > > > > > to > > > > > > insert a > > > > > > row at specified location to make easy custom sorting of > > > > > > the > > > > > > properties > > > > > > (not applicable if properties are auto-sorted, in that > > > > > > case, > > > > > > all > > > > > > [+] > > > > > > buttons can be actually removed). > > > > > > > > > > Thanks for the input, David. This is an interesting idea. > > > > > > > > > > Indeed, when choosing a key in the last row, we can > > > > > automatically > > > > > add a new "please select a key..." row, which actually saves > > > > > the > > > > > user a button-click for adding a new row. > > > > > > > > > > On the other hand, from graphic-design point of view, it will > > > > > look > > > > > more consistent and "pretty" if: > > > > > - The "please select a key..." row won't be displayed > > > > > (unless, > > > > > or > > > > > course, the user explicitly chose to add another row) > > > > > - All (full) rows will have both [+] and [-] buttons next to > > > > > them > > > > I should have probably elaborated more on this. To me, UI with less > > elements looks cleaner and prettier even when one of them stands > > out. > > There's also nothing wrong with standing out if the element has > > "special" meaning (one add vs bunch of modify). > > > > Specifically, this looks cleaner to my eyes: > > > > [ key1 |v] [ value ] [-] > > [ key2 |v] [ value ] [-] > > [ key3 |v] [ value ] [-] > > [ "Please select a key..." |v] > > > > than > > > > [ key1 |v] [ value ] [+] [-] > > [ key2 |v] [ value ] [+] [-] > > [ key3 |v] [ value ] [+] [-] > > > > > > Note that in your suggestion above, you cannot insert a new key in > between existing keys - only at the end; so > although "cleaner", it has less functionality (depends also on the > sorting, which is another issue; if there is auto-sorting, it > doesn't matter). > It is also a matter of taste, I guess, so no absolute right or wrong > here IMO. > [Others - you are welcome to comment as well] +1 another tiny comment: can the empty line contain all the fields from initial state [["please select a key..."][field(empty)][+][-]] instead of showing them only after selecting a key. [["please select a key..."]] both of these scenarios are liable, I can select a key, regret (change back to [please select a key]) and the field and buttons are still visible. so for the sake of complexity, I prefer to have only one. > > > > > > > > > > > If the [+] button in my proposal is just greyed out instead of > > > > ommited, > > > > it could satisfy both requirements. > > > > > > Almost; the "please select a key..." row is still always > > > displayed; > > > question is if we want to save a button-click (your suggestion) > > > or > > > to have a "cleaner" sheet (my suggestion). > > > > > > > > > > > > > > > > > i.e., instead of your suggestion, which looks like this: > > > > > > > > > > [ key1 |v] [ value ] [+] [-] > > > > > [ key2 |v] [ value ] [+] [-] > > > > > [ key3 |v] [ value ] [-] > > > > > [ "please select a key..." |v] > > > > > > > > > > it will be "prettier" like this: > > > > > > > > > > [ key1 |v] [ value ] [+] [-] > > > > > [ key2 |v] [ value ] [+] [-] > > > > > [ key3 |v] [ value ] [+] [-] > > > > > > > > > > and only if clicking on [+], it will be: > > > > > > > > > > [ key1 |v] [ value ] [+] [-] > > > > > [ key2 |v] [ value ] [+] [-] > > > > > [ key3 |v] [ value ] [+] [-] > > > > > [ "please select a key..." |v] > > > > > > > > > > I believe that auto-sorting can be confusing, as it can > > > > > result > > > > > in > > > > > rows "jumping" up and down whenever changing the selection(s) > > > > > in > > > > > the Key drop-down(s), > > > > > > > > this could be sort of mitigated by sorting server-side upon > > > > modification. > > > > > > > > > therefore I don't think it is a good idea to implement it > > > > > here. > > > > > > > > OTOH if we're to be manual sorting friendly, we should allow > > > > rearranging > > > > of the rows by drag & drop or by some sort of move up/down > > > > buttons > > > > and > > > > the dialog would start to be cluttered. > > > > > > > > I don't really like either of these but auto-sort is slightly > > > > better > > > > IMO > > > > as it is kept consistent accross various VMs without user > > > > interaction. > > > > > > Indeed, auto-sort will keep the order consistent across all VMs. > > > However, maybe the user would like to see the properties in the > > > order in which he filled them; in this case, your suggestion of > > > "move up/down buttons" is probably relevant here. > > > > > > I believe that the majority of use-cases won't require more than > > > 2 > > > or 3 custom properties per VM, so sorting won't be that critical, > > > therefore I assume we can start without it; I will add "sorting" > > > to the "open issues" section in the wiki page. > > > > > > > That seems as more argument in favor of auto sorting. > > Or no sorting at all (i.e. simply display in order of filling)... > In any case, open issue has been added to the wiki. > > > > > David > > > > > > > > > > David > > > > > > > > > > > > > > > > > > > > > David > > > > > > > > > > > > > ---- > > > > > > > Thanks, > > > > > > > Einav > > > > > > > _______________________________________________ > > > > > > > Engine-devel mailing list > > > > > > > Engine-devel at ovirt.org > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > -- > > > > > > > > > > > > David Ja?a, RHCE > > > > > > > > > > > > SPICE QE based in Brno > > > > > > GPG Key: 22C33E24 > > > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 > > > > > > 3E24 > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Engine-devel mailing list > > > > > > Engine-devel at ovirt.org > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > David Ja?a, RHCE > > > > > > > > SPICE QE based in Brno > > > > GPG Key: 22C33E24 > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24 > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Engine-devel mailing list > > > Engine-devel at ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > -- > > > > David Ja?a, RHCE > > > > SPICE QE based in Brno > > GPG Key: 22C33E24 > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24 > > > > > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > From ecohen at redhat.com Fri May 18 09:35:34 2012 From: ecohen at redhat.com (Einav Cohen) Date: Fri, 18 May 2012 05:35:34 -0400 (EDT) Subject: [Engine-devel] custom properties sheet feature page In-Reply-To: <6caf769d-4f82-4ffe-a814-db89cf2d3da7@zmail14.collab.prod.int.phx2.redhat.com> Message-ID: > ----- Original Message ----- > From: "Gilad Chaplik" > Sent: Friday, May 18, 2012 12:25:45 PM > > inline > > Thanks, > Gilad. > > ----- Original Message ----- > > From: "Einav Cohen" > > To: "David Ja?a" , "Miki Kenneth" > > , "Andrew Cathrow" , > > "Simon Grinberg" , "Eldan Hildesheim" > > , "Eldan Hildesheim" > > , "Gilad Chaplik" > > Cc: engine-devel at ovirt.org > > Sent: Friday, May 18, 2012 12:12:54 PM > > Subject: Re: [Engine-devel] custom properties sheet feature page > > > > > ----- Original Message ----- > > > From: "David Ja?a" > > > Sent: Friday, May 18, 2012 11:33:44 AM > > > > > > Einav Cohen p??e v ?t 17. 05. 2012 v 10:14 -0400: > > > > > ----- Original Message ----- > > > > > From: "David Ja?a" > > > > > Sent: Thursday, May 17, 2012 4:44:10 PM > > > > > > > > > > Einav Cohen p??e v ?t 17. 05. 2012 v 09:30 -0400: > > > > > > > ----- Original Message ----- > > > > > > > From: "David Ja?a" > > > > > > > Sent: Thursday, May 17, 2012 3:40:19 PM > > > > > > > > > > > > > > Einav Cohen p??e v ?t 17. 05. 2012 v 08:10 -0400: > > > > > > > > Hi, > > > > > > > > > > > > > > > > Please review/comment on the Custom Properties Sheet > > > > > > > > feature > > > > > > > > page: > > > > > > > > http://www.ovirt.org/wiki/Features/CustomPropertiesSheet > > > > > > > > > > > > > > > > > > > > > > Just my $0.02: > > > > > > > > > > > > > > The table could have always empty row at the bottom, > > > > > > > eliminating > > > > > > > one > > > > > > > or > > > > > > > all [+] buttons and saving user one needless click: > > > > > > > > > > > > > > [ key1 |v] [ value ] [+] [-] > > > > > > > [ key2 |v] [ value ] [+] [-] > > > > > > > [ key3 |v] [ value ] [-] > > > > > > > [ "please select a key..." |v] > > > > > > > > > > > > > > The [+] buttons at first and second rows would allow user > > > > > > > to > > > > > > > insert a > > > > > > > row at specified location to make easy custom sorting of > > > > > > > the > > > > > > > properties > > > > > > > (not applicable if properties are auto-sorted, in that > > > > > > > case, > > > > > > > all > > > > > > > [+] > > > > > > > buttons can be actually removed). > > > > > > > > > > > > Thanks for the input, David. This is an interesting idea. > > > > > > > > > > > > Indeed, when choosing a key in the last row, we can > > > > > > automatically > > > > > > add a new "please select a key..." row, which actually > > > > > > saves > > > > > > the > > > > > > user a button-click for adding a new row. > > > > > > > > > > > > On the other hand, from graphic-design point of view, it > > > > > > will > > > > > > look > > > > > > more consistent and "pretty" if: > > > > > > - The "please select a key..." row won't be displayed > > > > > > (unless, > > > > > > or > > > > > > course, the user explicitly chose to add another row) > > > > > > - All (full) rows will have both [+] and [-] buttons next > > > > > > to > > > > > > them > > > > > > I should have probably elaborated more on this. To me, UI with > > > less > > > elements looks cleaner and prettier even when one of them stands > > > out. > > > There's also nothing wrong with standing out if the element has > > > "special" meaning (one add vs bunch of modify). > > > > > > Specifically, this looks cleaner to my eyes: > > > > > > [ key1 |v] [ value ] [-] > > > [ key2 |v] [ value ] [-] > > > [ key3 |v] [ value ] [-] > > > [ "Please select a key..." |v] > > > > > > than > > > > > > [ key1 |v] [ value ] [+] [-] > > > [ key2 |v] [ value ] [+] [-] > > > [ key3 |v] [ value ] [+] [-] > > > > > > > > > > Note that in your suggestion above, you cannot insert a new key in > > between existing keys - only at the end; so > > although "cleaner", it has less functionality (depends also on the > > sorting, which is another issue; if there is auto-sorting, it > > doesn't matter). > > It is also a matter of taste, I guess, so no absolute right or > > wrong > > here IMO. > > [Others - you are welcome to comment as well] > > +1 > > another tiny comment: > can the empty line contain all the fields from initial state > [["please select a key..."][field(empty)][+][-]] > instead of showing them only after selecting a key. > [["please select a key..."]] > > both of these scenarios are liable, > I can select a key, regret (change back to [please select a key]) and > the field and buttons are still visible. > > so for the sake of complexity, I prefer to have only one. * Note that the field input control type (text-box, drop-down) depends on the key anyway (more accurately, on the validation regular expression of the key), so what are you going to show in case of "please select a key..."? * Need to make sure that validation fails in case field value is not empty and key is "please select a key...". Due to both of these reasons, I prefer to not show an input control at all in this case. * No problem of having a "+" button there; however, need to make sure that in case there is only one row in the sheet and it is with "please select a key...", the "-" button should be either hidden or disabled (or non-responsive), since we can't remove the last row. > > > > > > > > > > > > > > > > > If the [+] button in my proposal is just greyed out instead > > > > > of > > > > > ommited, > > > > > it could satisfy both requirements. > > > > > > > > Almost; the "please select a key..." row is still always > > > > displayed; > > > > question is if we want to save a button-click (your suggestion) > > > > or > > > > to have a "cleaner" sheet (my suggestion). > > > > > > > > > > > > > > > > > > > > > i.e., instead of your suggestion, which looks like this: > > > > > > > > > > > > [ key1 |v] [ value ] [+] [-] > > > > > > [ key2 |v] [ value ] [+] [-] > > > > > > [ key3 |v] [ value ] [-] > > > > > > [ "please select a key..." |v] > > > > > > > > > > > > it will be "prettier" like this: > > > > > > > > > > > > [ key1 |v] [ value ] [+] [-] > > > > > > [ key2 |v] [ value ] [+] [-] > > > > > > [ key3 |v] [ value ] [+] [-] > > > > > > > > > > > > and only if clicking on [+], it will be: > > > > > > > > > > > > [ key1 |v] [ value ] [+] [-] > > > > > > [ key2 |v] [ value ] [+] [-] > > > > > > [ key3 |v] [ value ] [+] [-] > > > > > > [ "please select a key..." |v] > > > > > > > > > > > > I believe that auto-sorting can be confusing, as it can > > > > > > result > > > > > > in > > > > > > rows "jumping" up and down whenever changing the > > > > > > selection(s) > > > > > > in > > > > > > the Key drop-down(s), > > > > > > > > > > this could be sort of mitigated by sorting server-side upon > > > > > modification. > > > > > > > > > > > therefore I don't think it is a good idea to implement it > > > > > > here. > > > > > > > > > > OTOH if we're to be manual sorting friendly, we should allow > > > > > rearranging > > > > > of the rows by drag & drop or by some sort of move up/down > > > > > buttons > > > > > and > > > > > the dialog would start to be cluttered. > > > > > > > > > > I don't really like either of these but auto-sort is slightly > > > > > better > > > > > IMO > > > > > as it is kept consistent accross various VMs without user > > > > > interaction. > > > > > > > > Indeed, auto-sort will keep the order consistent across all > > > > VMs. > > > > However, maybe the user would like to see the properties in the > > > > order in which he filled them; in this case, your suggestion of > > > > "move up/down buttons" is probably relevant here. > > > > > > > > I believe that the majority of use-cases won't require more > > > > than > > > > 2 > > > > or 3 custom properties per VM, so sorting won't be that > > > > critical, > > > > therefore I assume we can start without it; I will add > > > > "sorting" > > > > to the "open issues" section in the wiki page. > > > > > > > > > > That seems as more argument in favor of auto sorting. > > > > Or no sorting at all (i.e. simply display in order of filling)... > > In any case, open issue has been added to the wiki. > > > > > > > > David > > > > > > > > > > > > > David > > > > > > > > > > > > > > > > > > > > > > > > > David > > > > > > > > > > > > > > > ---- > > > > > > > > Thanks, > > > > > > > > Einav > > > > > > > > _______________________________________________ > > > > > > > > Engine-devel mailing list > > > > > > > > Engine-devel at ovirt.org > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > David Ja?a, RHCE > > > > > > > > > > > > > > SPICE QE based in Brno > > > > > > > GPG Key: 22C33E24 > > > > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 > > > > > > > 3E24 > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Engine-devel mailing list > > > > > > > Engine-devel at ovirt.org > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > David Ja?a, RHCE > > > > > > > > > > SPICE QE based in Brno > > > > > GPG Key: 22C33E24 > > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 > > > > > 3E24 > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Engine-devel mailing list > > > > Engine-devel at ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > -- > > > > > > David Ja?a, RHCE > > > > > > SPICE QE based in Brno > > > GPG Key: 22C33E24 > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24 > > > > > > > > > > > > _______________________________________________ > > > Engine-devel mailing list > > > Engine-devel at ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > From gchaplik at redhat.com Fri May 18 09:44:04 2012 From: gchaplik at redhat.com (Gilad Chaplik) Date: Fri, 18 May 2012 05:44:04 -0400 (EDT) Subject: [Engine-devel] custom properties sheet feature page In-Reply-To: Message-ID: <930b2d36-0b5d-46d5-877b-7d5f26fe2259@zmail14.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Einav Cohen" > To: "Gilad Chaplik" > Cc: engine-devel at ovirt.org, "David Ja?a" , "Miki Kenneth" , "Andrew Cathrow" > , "Simon Grinberg" , "Eldan Hildesheim" , "Eldan > Hildesheim" > Sent: Friday, May 18, 2012 12:35:34 PM > Subject: Re: [Engine-devel] custom properties sheet feature page > > > ----- Original Message ----- > > From: "Gilad Chaplik" > > Sent: Friday, May 18, 2012 12:25:45 PM > > > > inline > > > > Thanks, > > Gilad. > > > > ----- Original Message ----- > > > From: "Einav Cohen" > > > To: "David Ja?a" , "Miki Kenneth" > > > , "Andrew Cathrow" , > > > "Simon Grinberg" , "Eldan Hildesheim" > > > , "Eldan Hildesheim" > > > , "Gilad Chaplik" > > > Cc: engine-devel at ovirt.org > > > Sent: Friday, May 18, 2012 12:12:54 PM > > > Subject: Re: [Engine-devel] custom properties sheet feature page > > > > > > > ----- Original Message ----- > > > > From: "David Ja?a" > > > > Sent: Friday, May 18, 2012 11:33:44 AM > > > > > > > > Einav Cohen p??e v ?t 17. 05. 2012 v 10:14 -0400: > > > > > > ----- Original Message ----- > > > > > > From: "David Ja?a" > > > > > > Sent: Thursday, May 17, 2012 4:44:10 PM > > > > > > > > > > > > Einav Cohen p??e v ?t 17. 05. 2012 v 09:30 -0400: > > > > > > > > ----- Original Message ----- > > > > > > > > From: "David Ja?a" > > > > > > > > Sent: Thursday, May 17, 2012 3:40:19 PM > > > > > > > > > > > > > > > > Einav Cohen p??e v ?t 17. 05. 2012 v 08:10 -0400: > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > Please review/comment on the Custom Properties Sheet > > > > > > > > > feature > > > > > > > > > page: > > > > > > > > > http://www.ovirt.org/wiki/Features/CustomPropertiesSheet > > > > > > > > > > > > > > > > > > > > > > > > > Just my $0.02: > > > > > > > > > > > > > > > > The table could have always empty row at the bottom, > > > > > > > > eliminating > > > > > > > > one > > > > > > > > or > > > > > > > > all [+] buttons and saving user one needless click: > > > > > > > > > > > > > > > > [ key1 |v] [ value ] [+] [-] > > > > > > > > [ key2 |v] [ value ] [+] [-] > > > > > > > > [ key3 |v] [ value ] [-] > > > > > > > > [ "please select a key..." |v] > > > > > > > > > > > > > > > > The [+] buttons at first and second rows would allow > > > > > > > > user > > > > > > > > to > > > > > > > > insert a > > > > > > > > row at specified location to make easy custom sorting > > > > > > > > of > > > > > > > > the > > > > > > > > properties > > > > > > > > (not applicable if properties are auto-sorted, in that > > > > > > > > case, > > > > > > > > all > > > > > > > > [+] > > > > > > > > buttons can be actually removed). > > > > > > > > > > > > > > Thanks for the input, David. This is an interesting idea. > > > > > > > > > > > > > > Indeed, when choosing a key in the last row, we can > > > > > > > automatically > > > > > > > add a new "please select a key..." row, which actually > > > > > > > saves > > > > > > > the > > > > > > > user a button-click for adding a new row. > > > > > > > > > > > > > > On the other hand, from graphic-design point of view, it > > > > > > > will > > > > > > > look > > > > > > > more consistent and "pretty" if: > > > > > > > - The "please select a key..." row won't be displayed > > > > > > > (unless, > > > > > > > or > > > > > > > course, the user explicitly chose to add another row) > > > > > > > - All (full) rows will have both [+] and [-] buttons next > > > > > > > to > > > > > > > them > > > > > > > > I should have probably elaborated more on this. To me, UI with > > > > less > > > > elements looks cleaner and prettier even when one of them > > > > stands > > > > out. > > > > There's also nothing wrong with standing out if the element has > > > > "special" meaning (one add vs bunch of modify). > > > > > > > > Specifically, this looks cleaner to my eyes: > > > > > > > > [ key1 |v] [ value ] [-] > > > > [ key2 |v] [ value ] [-] > > > > [ key3 |v] [ value ] [-] > > > > [ "Please select a key..." |v] > > > > > > > > than > > > > > > > > [ key1 |v] [ value ] [+] [-] > > > > [ key2 |v] [ value ] [+] [-] > > > > [ key3 |v] [ value ] [+] [-] > > > > > > > > > > > > > > Note that in your suggestion above, you cannot insert a new key > > > in > > > between existing keys - only at the end; so > > > although "cleaner", it has less functionality (depends also on > > > the > > > sorting, which is another issue; if there is auto-sorting, it > > > doesn't matter). > > > It is also a matter of taste, I guess, so no absolute right or > > > wrong > > > here IMO. > > > [Others - you are welcome to comment as well] > > > > +1 > > > > another tiny comment: > > can the empty line contain all the fields from initial state > > [["please select a key..."][field(empty)][+][-]] > > instead of showing them only after selecting a key. > > [["please select a key..."]] > > > > both of these scenarios are liable, > > I can select a key, regret (change back to [please select a key]) > > and > > the field and buttons are still visible. > > > > so for the sake of complexity, I prefer to have only one. > > * Note that the field input control type (text-box, drop-down) > depends on the key anyway (more accurately, on the validation > regular expression of the key), so what are you going to show in > case of "please select a key..."? empty text-box > > * Need to make sure that validation fails in case field value is not > empty and key is "please select a key...". > > Due to both of these reasons, I prefer to not show an input control > at all in this case. still, I don't see any difference, except adding complexity/devel-time/bugs later on. plus I think it's nicer. > > * No problem of having a "+" button there; however, need to make sure > that in case there is only one row in the sheet and it is with > "please select a key...", the "-" button should be either hidden or > disabled (or non-responsive), since we can't remove the last row. > > > > > > > > > > > > > > > > > > > > > > > > If the [+] button in my proposal is just greyed out instead > > > > > > of > > > > > > ommited, > > > > > > it could satisfy both requirements. > > > > > > > > > > Almost; the "please select a key..." row is still always > > > > > displayed; > > > > > question is if we want to save a button-click (your > > > > > suggestion) > > > > > or > > > > > to have a "cleaner" sheet (my suggestion). > > > > > > > > > > > > > > > > > > > > > > > > > i.e., instead of your suggestion, which looks like this: > > > > > > > > > > > > > > [ key1 |v] [ value ] [+] [-] > > > > > > > [ key2 |v] [ value ] [+] [-] > > > > > > > [ key3 |v] [ value ] [-] > > > > > > > [ "please select a key..." |v] > > > > > > > > > > > > > > it will be "prettier" like this: > > > > > > > > > > > > > > [ key1 |v] [ value ] [+] [-] > > > > > > > [ key2 |v] [ value ] [+] [-] > > > > > > > [ key3 |v] [ value ] [+] [-] > > > > > > > > > > > > > > and only if clicking on [+], it will be: > > > > > > > > > > > > > > [ key1 |v] [ value ] [+] [-] > > > > > > > [ key2 |v] [ value ] [+] [-] > > > > > > > [ key3 |v] [ value ] [+] [-] > > > > > > > [ "please select a key..." |v] > > > > > > > > > > > > > > I believe that auto-sorting can be confusing, as it can > > > > > > > result > > > > > > > in > > > > > > > rows "jumping" up and down whenever changing the > > > > > > > selection(s) > > > > > > > in > > > > > > > the Key drop-down(s), > > > > > > > > > > > > this could be sort of mitigated by sorting server-side upon > > > > > > modification. > > > > > > > > > > > > > therefore I don't think it is a good idea to implement > > > > > > > it > > > > > > > here. > > > > > > > > > > > > OTOH if we're to be manual sorting friendly, we should > > > > > > allow > > > > > > rearranging > > > > > > of the rows by drag & drop or by some sort of move up/down > > > > > > buttons > > > > > > and > > > > > > the dialog would start to be cluttered. > > > > > > > > > > > > I don't really like either of these but auto-sort is > > > > > > slightly > > > > > > better > > > > > > IMO > > > > > > as it is kept consistent accross various VMs without user > > > > > > interaction. > > > > > > > > > > Indeed, auto-sort will keep the order consistent across all > > > > > VMs. > > > > > However, maybe the user would like to see the properties in > > > > > the > > > > > order in which he filled them; in this case, your suggestion > > > > > of > > > > > "move up/down buttons" is probably relevant here. > > > > > > > > > > I believe that the majority of use-cases won't require more > > > > > than > > > > > 2 > > > > > or 3 custom properties per VM, so sorting won't be that > > > > > critical, > > > > > therefore I assume we can start without it; I will add > > > > > "sorting" > > > > > to the "open issues" section in the wiki page. > > > > > > > > > > > > > That seems as more argument in favor of auto sorting. > > > > > > Or no sorting at all (i.e. simply display in order of filling)... > > > In any case, open issue has been added to the wiki. > > > > > > > > > > > David > > > > > > > > > > > > > > > > David > > > > > > > > > > > > > > > > > > > > > > > > > > > > > David > > > > > > > > > > > > > > > > > ---- > > > > > > > > > Thanks, > > > > > > > > > Einav > > > > > > > > > _______________________________________________ > > > > > > > > > Engine-devel mailing list > > > > > > > > > Engine-devel at ovirt.org > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > David Ja?a, RHCE > > > > > > > > > > > > > > > > SPICE QE based in Brno > > > > > > > > GPG Key: 22C33E24 > > > > > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 > > > > > > > > 22C3 > > > > > > > > 3E24 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Engine-devel mailing list > > > > > > > > Engine-devel at ovirt.org > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > David Ja?a, RHCE > > > > > > > > > > > > SPICE QE based in Brno > > > > > > GPG Key: 22C33E24 > > > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 > > > > > > 3E24 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Engine-devel mailing list > > > > > Engine-devel at ovirt.org > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > -- > > > > > > > > David Ja?a, RHCE > > > > > > > > SPICE QE based in Brno > > > > GPG Key: 22C33E24 > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24 > > > > > > > > > > > > > > > > _______________________________________________ > > > > Engine-devel mailing list > > > > Engine-devel at ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > From djasa at redhat.com Fri May 18 09:51:43 2012 From: djasa at redhat.com (David =?UTF-8?Q?Ja=C5=A1a?=) Date: Fri, 18 May 2012 11:51:43 +0200 Subject: [Engine-devel] custom properties sheet feature page In-Reply-To: <930b2d36-0b5d-46d5-877b-7d5f26fe2259@zmail14.collab.prod.int.phx2.redhat.com> References: <930b2d36-0b5d-46d5-877b-7d5f26fe2259@zmail14.collab.prod.int.phx2.redhat.com> Message-ID: <1337334703.12011.151.camel@dhcp-29-7.brq.redhat.com> Gilad Chaplik p??e v P? 18. 05. 2012 v 05:44 -0400: > ----- Original Message ----- > > From: "Einav Cohen" > > To: "Gilad Chaplik" > > Cc: engine-devel at ovirt.org, "David Ja?a" , "Miki Kenneth" , "Andrew Cathrow" > > , "Simon Grinberg" , "Eldan Hildesheim" , "Eldan > > Hildesheim" > > Sent: Friday, May 18, 2012 12:35:34 PM > > Subject: Re: [Engine-devel] custom properties sheet feature page > > > > > ----- Original Message ----- > > > From: "Gilad Chaplik" > > > Sent: Friday, May 18, 2012 12:25:45 PM > > > > > > inline > > > > > > Thanks, > > > Gilad. > > > > > > ----- Original Message ----- > > > > From: "Einav Cohen" > > > > To: "David Ja?a" , "Miki Kenneth" > > > > , "Andrew Cathrow" , > > > > "Simon Grinberg" , "Eldan Hildesheim" > > > > , "Eldan Hildesheim" > > > > , "Gilad Chaplik" > > > > Cc: engine-devel at ovirt.org > > > > Sent: Friday, May 18, 2012 12:12:54 PM > > > > Subject: Re: [Engine-devel] custom properties sheet feature page > > > > > > > > > ----- Original Message ----- > > > > > From: "David Ja?a" > > > > > Sent: Friday, May 18, 2012 11:33:44 AM > > > > > > > > > > Einav Cohen p??e v ?t 17. 05. 2012 v 10:14 -0400: > > > > > > > ----- Original Message ----- > > > > > > > From: "David Ja?a" > > > > > > > Sent: Thursday, May 17, 2012 4:44:10 PM > > > > > > > > > > > > > > Einav Cohen p??e v ?t 17. 05. 2012 v 09:30 -0400: > > > > > > > > > ----- Original Message ----- > > > > > > > > > From: "David Ja?a" > > > > > > > > > Sent: Thursday, May 17, 2012 3:40:19 PM > > > > > > > > > > > > > > > > > > Einav Cohen p??e v ?t 17. 05. 2012 v 08:10 -0400: > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > Please review/comment on the Custom Properties Sheet > > > > > > > > > > feature > > > > > > > > > > page: > > > > > > > > > > http://www.ovirt.org/wiki/Features/CustomPropertiesSheet > > > > > > > > > > > > > > > > > > > > > > > > > > > > Just my $0.02: > > > > > > > > > > > > > > > > > > The table could have always empty row at the bottom, > > > > > > > > > eliminating > > > > > > > > > one > > > > > > > > > or > > > > > > > > > all [+] buttons and saving user one needless click: > > > > > > > > > > > > > > > > > > [ key1 |v] [ value ] [+] [-] > > > > > > > > > [ key2 |v] [ value ] [+] [-] > > > > > > > > > [ key3 |v] [ value ] [-] > > > > > > > > > [ "please select a key..." |v] > > > > > > > > > > > > > > > > > > The [+] buttons at first and second rows would allow > > > > > > > > > user > > > > > > > > > to > > > > > > > > > insert a > > > > > > > > > row at specified location to make easy custom sorting > > > > > > > > > of > > > > > > > > > the > > > > > > > > > properties > > > > > > > > > (not applicable if properties are auto-sorted, in that > > > > > > > > > case, > > > > > > > > > all > > > > > > > > > [+] > > > > > > > > > buttons can be actually removed). > > > > > > > > > > > > > > > > Thanks for the input, David. This is an interesting idea. > > > > > > > > > > > > > > > > Indeed, when choosing a key in the last row, we can > > > > > > > > automatically > > > > > > > > add a new "please select a key..." row, which actually > > > > > > > > saves > > > > > > > > the > > > > > > > > user a button-click for adding a new row. > > > > > > > > > > > > > > > > On the other hand, from graphic-design point of view, it > > > > > > > > will > > > > > > > > look > > > > > > > > more consistent and "pretty" if: > > > > > > > > - The "please select a key..." row won't be displayed > > > > > > > > (unless, > > > > > > > > or > > > > > > > > course, the user explicitly chose to add another row) > > > > > > > > - All (full) rows will have both [+] and [-] buttons next > > > > > > > > to > > > > > > > > them > > > > > > > > > > I should have probably elaborated more on this. To me, UI with > > > > > less > > > > > elements looks cleaner and prettier even when one of them > > > > > stands > > > > > out. > > > > > There's also nothing wrong with standing out if the element has > > > > > "special" meaning (one add vs bunch of modify). > > > > > > > > > > Specifically, this looks cleaner to my eyes: > > > > > > > > > > [ key1 |v] [ value ] [-] > > > > > [ key2 |v] [ value ] [-] > > > > > [ key3 |v] [ value ] [-] > > > > > [ "Please select a key..." |v] > > > > > > > > > > than > > > > > > > > > > [ key1 |v] [ value ] [+] [-] > > > > > [ key2 |v] [ value ] [+] [-] > > > > > [ key3 |v] [ value ] [+] [-] > > > > > > > > > > > > > > > > > > Note that in your suggestion above, you cannot insert a new key > > > > in > > > > between existing keys - only at the end; so > > > > although "cleaner", it has less functionality (depends also on > > > > the > > > > sorting, which is another issue; if there is auto-sorting, it > > > > doesn't matter). > > > > It is also a matter of taste, I guess, so no absolute right or > > > > wrong > > > > here IMO. > > > > [Others - you are welcome to comment as well] > > > > > > +1 > > > > > > another tiny comment: > > > can the empty line contain all the fields from initial state > > > [["please select a key..."][field(empty)][+][-]] > > > instead of showing them only after selecting a key. > > > [["please select a key..."]] > > > > > > both of these scenarios are liable, > > > I can select a key, regret (change back to [please select a key]) > > > and > > > the field and buttons are still visible. > > > > > > so for the sake of complexity, I prefer to have only one. > > > > * Note that the field input control type (text-box, drop-down) > > depends on the key anyway (more accurately, on the validation > > regular expression of the key), so what are you going to show in > > case of "please select a key..."? > > empty text-box > > > > > * Need to make sure that validation fails in case field value is not > > empty and key is "please select a key...". > > I would prefer to just disable the value input field and do re-validation upon change of key (clear the value if it fails validation against a new key) or server-side when it is changed (clear the key-value pair altogether). David > > Due to both of these reasons, I prefer to not show an input control > > at all in this case. > > still, I don't see any difference, except adding complexity/devel-time/bugs later on. > plus I think it's nicer. > > > > > * No problem of having a "+" button there; however, need to make sure > > that in case there is only one row in the sheet and it is with > > "please select a key...", the "-" button should be either hidden or > > disabled (or non-responsive), since we can't remove the last row. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If the [+] button in my proposal is just greyed out instead > > > > > > > of > > > > > > > ommited, > > > > > > > it could satisfy both requirements. > > > > > > > > > > > > Almost; the "please select a key..." row is still always > > > > > > displayed; > > > > > > question is if we want to save a button-click (your > > > > > > suggestion) > > > > > > or > > > > > > to have a "cleaner" sheet (my suggestion). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > i.e., instead of your suggestion, which looks like this: > > > > > > > > > > > > > > > > [ key1 |v] [ value ] [+] [-] > > > > > > > > [ key2 |v] [ value ] [+] [-] > > > > > > > > [ key3 |v] [ value ] [-] > > > > > > > > [ "please select a key..." |v] > > > > > > > > > > > > > > > > it will be "prettier" like this: > > > > > > > > > > > > > > > > [ key1 |v] [ value ] [+] [-] > > > > > > > > [ key2 |v] [ value ] [+] [-] > > > > > > > > [ key3 |v] [ value ] [+] [-] > > > > > > > > > > > > > > > > and only if clicking on [+], it will be: > > > > > > > > > > > > > > > > [ key1 |v] [ value ] [+] [-] > > > > > > > > [ key2 |v] [ value ] [+] [-] > > > > > > > > [ key3 |v] [ value ] [+] [-] > > > > > > > > [ "please select a key..." |v] > > > > > > > > > > > > > > > > I believe that auto-sorting can be confusing, as it can > > > > > > > > result > > > > > > > > in > > > > > > > > rows "jumping" up and down whenever changing the > > > > > > > > selection(s) > > > > > > > > in > > > > > > > > the Key drop-down(s), > > > > > > > > > > > > > > this could be sort of mitigated by sorting server-side upon > > > > > > > modification. > > > > > > > > > > > > > > > therefore I don't think it is a good idea to implement > > > > > > > > it > > > > > > > > here. > > > > > > > > > > > > > > OTOH if we're to be manual sorting friendly, we should > > > > > > > allow > > > > > > > rearranging > > > > > > > of the rows by drag & drop or by some sort of move up/down > > > > > > > buttons > > > > > > > and > > > > > > > the dialog would start to be cluttered. > > > > > > > > > > > > > > I don't really like either of these but auto-sort is > > > > > > > slightly > > > > > > > better > > > > > > > IMO > > > > > > > as it is kept consistent accross various VMs without user > > > > > > > interaction. > > > > > > > > > > > > Indeed, auto-sort will keep the order consistent across all > > > > > > VMs. > > > > > > However, maybe the user would like to see the properties in > > > > > > the > > > > > > order in which he filled them; in this case, your suggestion > > > > > > of > > > > > > "move up/down buttons" is probably relevant here. > > > > > > > > > > > > I believe that the majority of use-cases won't require more > > > > > > than > > > > > > 2 > > > > > > or 3 custom properties per VM, so sorting won't be that > > > > > > critical, > > > > > > therefore I assume we can start without it; I will add > > > > > > "sorting" > > > > > > to the "open issues" section in the wiki page. > > > > > > > > > > > > > > > > That seems as more argument in favor of auto sorting. > > > > > > > > Or no sorting at all (i.e. simply display in order of filling)... > > > > In any case, open issue has been added to the wiki. > > > > > > > > > > > > > > David > > > > > > > > > > > > > > > > > > > David > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > David > > > > > > > > > > > > > > > > > > > ---- > > > > > > > > > > Thanks, > > > > > > > > > > Einav > > > > > > > > > > _______________________________________________ > > > > > > > > > > Engine-devel mailing list > > > > > > > > > > Engine-devel at ovirt.org > > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > David Ja?a, RHCE > > > > > > > > > > > > > > > > > > SPICE QE based in Brno > > > > > > > > > GPG Key: 22C33E24 > > > > > > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 > > > > > > > > > 22C3 > > > > > > > > > 3E24 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Engine-devel mailing list > > > > > > > > > Engine-devel at ovirt.org > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > David Ja?a, RHCE > > > > > > > > > > > > > > SPICE QE based in Brno > > > > > > > GPG Key: 22C33E24 > > > > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 > > > > > > > 3E24 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Engine-devel mailing list > > > > > > Engine-devel at ovirt.org > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > -- > > > > > > > > > > David Ja?a, RHCE > > > > > > > > > > SPICE QE based in Brno > > > > > GPG Key: 22C33E24 > > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24 > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Engine-devel mailing list > > > > > Engine-devel at ovirt.org > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > > > > -- David Ja?a, RHCE SPICE QE based in Brno GPG Key: 22C33E24 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24 From gchaplik at redhat.com Fri May 18 09:56:00 2012 From: gchaplik at redhat.com (Gilad Chaplik) Date: Fri, 18 May 2012 05:56:00 -0400 (EDT) Subject: [Engine-devel] custom properties sheet feature page In-Reply-To: <1337334703.12011.151.camel@dhcp-29-7.brq.redhat.com> Message-ID: <8a7fb724-0b4f-496b-af38-4d9bd2da5682@zmail14.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "David Ja?a" > To: "Gilad Chaplik" > Cc: "Einav Cohen" , engine-devel at ovirt.org, "Miki Kenneth" , "Andrew Cathrow" > , "Simon Grinberg" , "Eldan Hildesheim" , "Eldan > Hildesheim" > Sent: Friday, May 18, 2012 12:51:43 PM > Subject: Re: [Engine-devel] custom properties sheet feature page > > Gilad Chaplik p??e v P? 18. 05. 2012 v 05:44 -0400: > > ----- Original Message ----- > > > From: "Einav Cohen" > > > To: "Gilad Chaplik" > > > Cc: engine-devel at ovirt.org, "David Ja?a" , > > > "Miki Kenneth" , "Andrew Cathrow" > > > , "Simon Grinberg" , > > > "Eldan Hildesheim" , "Eldan > > > Hildesheim" > > > Sent: Friday, May 18, 2012 12:35:34 PM > > > Subject: Re: [Engine-devel] custom properties sheet feature page > > > > > > > ----- Original Message ----- > > > > From: "Gilad Chaplik" > > > > Sent: Friday, May 18, 2012 12:25:45 PM > > > > > > > > inline > > > > > > > > Thanks, > > > > Gilad. > > > > > > > > ----- Original Message ----- > > > > > From: "Einav Cohen" > > > > > To: "David Ja?a" , "Miki Kenneth" > > > > > , "Andrew Cathrow" > > > > > , > > > > > "Simon Grinberg" , "Eldan Hildesheim" > > > > > , "Eldan Hildesheim" > > > > > , "Gilad Chaplik" > > > > > Cc: engine-devel at ovirt.org > > > > > Sent: Friday, May 18, 2012 12:12:54 PM > > > > > Subject: Re: [Engine-devel] custom properties sheet feature > > > > > page > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "David Ja?a" > > > > > > Sent: Friday, May 18, 2012 11:33:44 AM > > > > > > > > > > > > Einav Cohen p??e v ?t 17. 05. 2012 v 10:14 -0400: > > > > > > > > ----- Original Message ----- > > > > > > > > From: "David Ja?a" > > > > > > > > Sent: Thursday, May 17, 2012 4:44:10 PM > > > > > > > > > > > > > > > > Einav Cohen p??e v ?t 17. 05. 2012 v 09:30 -0400: > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > From: "David Ja?a" > > > > > > > > > > Sent: Thursday, May 17, 2012 3:40:19 PM > > > > > > > > > > > > > > > > > > > > Einav Cohen p??e v ?t 17. 05. 2012 v 08:10 -0400: > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > Please review/comment on the Custom Properties > > > > > > > > > > > Sheet > > > > > > > > > > > feature > > > > > > > > > > > page: > > > > > > > > > > > http://www.ovirt.org/wiki/Features/CustomPropertiesSheet > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Just my $0.02: > > > > > > > > > > > > > > > > > > > > The table could have always empty row at the > > > > > > > > > > bottom, > > > > > > > > > > eliminating > > > > > > > > > > one > > > > > > > > > > or > > > > > > > > > > all [+] buttons and saving user one needless click: > > > > > > > > > > > > > > > > > > > > [ key1 |v] [ value ] [+] [-] > > > > > > > > > > [ key2 |v] [ value ] [+] [-] > > > > > > > > > > [ key3 |v] [ value ] [-] > > > > > > > > > > [ "please select a key..." |v] > > > > > > > > > > > > > > > > > > > > The [+] buttons at first and second rows would > > > > > > > > > > allow > > > > > > > > > > user > > > > > > > > > > to > > > > > > > > > > insert a > > > > > > > > > > row at specified location to make easy custom > > > > > > > > > > sorting > > > > > > > > > > of > > > > > > > > > > the > > > > > > > > > > properties > > > > > > > > > > (not applicable if properties are auto-sorted, in > > > > > > > > > > that > > > > > > > > > > case, > > > > > > > > > > all > > > > > > > > > > [+] > > > > > > > > > > buttons can be actually removed). > > > > > > > > > > > > > > > > > > Thanks for the input, David. This is an interesting > > > > > > > > > idea. > > > > > > > > > > > > > > > > > > Indeed, when choosing a key in the last row, we can > > > > > > > > > automatically > > > > > > > > > add a new "please select a key..." row, which > > > > > > > > > actually > > > > > > > > > saves > > > > > > > > > the > > > > > > > > > user a button-click for adding a new row. > > > > > > > > > > > > > > > > > > On the other hand, from graphic-design point of view, > > > > > > > > > it > > > > > > > > > will > > > > > > > > > look > > > > > > > > > more consistent and "pretty" if: > > > > > > > > > - The "please select a key..." row won't be displayed > > > > > > > > > (unless, > > > > > > > > > or > > > > > > > > > course, the user explicitly chose to add another row) > > > > > > > > > - All (full) rows will have both [+] and [-] buttons > > > > > > > > > next > > > > > > > > > to > > > > > > > > > them > > > > > > > > > > > > I should have probably elaborated more on this. To me, UI > > > > > > with > > > > > > less > > > > > > elements looks cleaner and prettier even when one of them > > > > > > stands > > > > > > out. > > > > > > There's also nothing wrong with standing out if the element > > > > > > has > > > > > > "special" meaning (one add vs bunch of modify). > > > > > > > > > > > > Specifically, this looks cleaner to my eyes: > > > > > > > > > > > > [ key1 |v] [ value ] [-] > > > > > > [ key2 |v] [ value ] [-] > > > > > > [ key3 |v] [ value ] [-] > > > > > > [ "Please select a key..." |v] > > > > > > > > > > > > than > > > > > > > > > > > > [ key1 |v] [ value ] [+] [-] > > > > > > [ key2 |v] [ value ] [+] [-] > > > > > > [ key3 |v] [ value ] [+] [-] > > > > > > > > > > > > > > > > > > > > > > Note that in your suggestion above, you cannot insert a new > > > > > key > > > > > in > > > > > between existing keys - only at the end; so > > > > > although "cleaner", it has less functionality (depends also > > > > > on > > > > > the > > > > > sorting, which is another issue; if there is auto-sorting, it > > > > > doesn't matter). > > > > > It is also a matter of taste, I guess, so no absolute right > > > > > or > > > > > wrong > > > > > here IMO. > > > > > [Others - you are welcome to comment as well] > > > > > > > > +1 > > > > > > > > another tiny comment: > > > > can the empty line contain all the fields from initial state > > > > [["please select a key..."][field(empty)][+][-]] > > > > instead of showing them only after selecting a key. > > > > [["please select a key..."]] > > > > > > > > both of these scenarios are liable, > > > > I can select a key, regret (change back to [please select a > > > > key]) > > > > and > > > > the field and buttons are still visible. > > > > > > > > so for the sake of complexity, I prefer to have only one. > > > > > > * Note that the field input control type (text-box, drop-down) > > > depends on the key anyway (more accurately, on the validation > > > regular expression of the key), so what are you going to show in > > > case of "please select a key..."? > > > > empty text-box > > > > > > > > * Need to make sure that validation fails in case field value is > > > not > > > empty and key is "please select a key...". > > > > > I would prefer to just disable the value input field and do > re-validation upon change of key (clear the value if it fails > validation > against a new key) or server-side when it is changed (clear the > key-value pair altogether). +1 for disabling -1 for clearing - it is not advised to clear a field if its fails on validation. > > David > > > > Due to both of these reasons, I prefer to not show an input > > > control > > > at all in this case. > > > > still, I don't see any difference, except adding > > complexity/devel-time/bugs later on. > > plus I think it's nicer. > > > > > > > > * No problem of having a "+" button there; however, need to make > > > sure > > > that in case there is only one row in the sheet and it is with > > > "please select a key...", the "-" button should be either hidden > > > or > > > disabled (or non-responsive), since we can't remove the last row. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If the [+] button in my proposal is just greyed out > > > > > > > > instead > > > > > > > > of > > > > > > > > ommited, > > > > > > > > it could satisfy both requirements. > > > > > > > > > > > > > > Almost; the "please select a key..." row is still always > > > > > > > displayed; > > > > > > > question is if we want to save a button-click (your > > > > > > > suggestion) > > > > > > > or > > > > > > > to have a "cleaner" sheet (my suggestion). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > i.e., instead of your suggestion, which looks like > > > > > > > > > this: > > > > > > > > > > > > > > > > > > [ key1 |v] [ value ] [+] [-] > > > > > > > > > [ key2 |v] [ value ] [+] [-] > > > > > > > > > [ key3 |v] [ value ] [-] > > > > > > > > > [ "please select a key..." |v] > > > > > > > > > > > > > > > > > > it will be "prettier" like this: > > > > > > > > > > > > > > > > > > [ key1 |v] [ value ] [+] [-] > > > > > > > > > [ key2 |v] [ value ] [+] [-] > > > > > > > > > [ key3 |v] [ value ] [+] [-] > > > > > > > > > > > > > > > > > > and only if clicking on [+], it will be: > > > > > > > > > > > > > > > > > > [ key1 |v] [ value ] [+] [-] > > > > > > > > > [ key2 |v] [ value ] [+] [-] > > > > > > > > > [ key3 |v] [ value ] [+] [-] > > > > > > > > > [ "please select a key..." |v] > > > > > > > > > > > > > > > > > > I believe that auto-sorting can be confusing, as it > > > > > > > > > can > > > > > > > > > result > > > > > > > > > in > > > > > > > > > rows "jumping" up and down whenever changing the > > > > > > > > > selection(s) > > > > > > > > > in > > > > > > > > > the Key drop-down(s), > > > > > > > > > > > > > > > > this could be sort of mitigated by sorting server-side > > > > > > > > upon > > > > > > > > modification. > > > > > > > > > > > > > > > > > therefore I don't think it is a good idea to > > > > > > > > > implement > > > > > > > > > it > > > > > > > > > here. > > > > > > > > > > > > > > > > OTOH if we're to be manual sorting friendly, we should > > > > > > > > allow > > > > > > > > rearranging > > > > > > > > of the rows by drag & drop or by some sort of move > > > > > > > > up/down > > > > > > > > buttons > > > > > > > > and > > > > > > > > the dialog would start to be cluttered. > > > > > > > > > > > > > > > > I don't really like either of these but auto-sort is > > > > > > > > slightly > > > > > > > > better > > > > > > > > IMO > > > > > > > > as it is kept consistent accross various VMs without > > > > > > > > user > > > > > > > > interaction. > > > > > > > > > > > > > > Indeed, auto-sort will keep the order consistent across > > > > > > > all > > > > > > > VMs. > > > > > > > However, maybe the user would like to see the properties > > > > > > > in > > > > > > > the > > > > > > > order in which he filled them; in this case, your > > > > > > > suggestion > > > > > > > of > > > > > > > "move up/down buttons" is probably relevant here. > > > > > > > > > > > > > > I believe that the majority of use-cases won't require > > > > > > > more > > > > > > > than > > > > > > > 2 > > > > > > > or 3 custom properties per VM, so sorting won't be that > > > > > > > critical, > > > > > > > therefore I assume we can start without it; I will add > > > > > > > "sorting" > > > > > > > to the "open issues" section in the wiki page. > > > > > > > > > > > > > > > > > > > That seems as more argument in favor of auto sorting. > > > > > > > > > > Or no sorting at all (i.e. simply display in order of > > > > > filling)... > > > > > In any case, open issue has been added to the wiki. > > > > > > > > > > > > > > > > > David > > > > > > > > > > > > > > > > > > > > > > David > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > David > > > > > > > > > > > > > > > > > > > > > ---- > > > > > > > > > > > Thanks, > > > > > > > > > > > Einav > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > Engine-devel mailing list > > > > > > > > > > > Engine-devel at ovirt.org > > > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > David Ja?a, RHCE > > > > > > > > > > > > > > > > > > > > SPICE QE based in Brno > > > > > > > > > > GPG Key: 22C33E24 > > > > > > > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 > > > > > > > > > > CD00 > > > > > > > > > > 22C3 > > > > > > > > > > 3E24 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > Engine-devel mailing list > > > > > > > > > > Engine-devel at ovirt.org > > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > David Ja?a, RHCE > > > > > > > > > > > > > > > > SPICE QE based in Brno > > > > > > > > GPG Key: 22C33E24 > > > > > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 > > > > > > > > 22C3 > > > > > > > > 3E24 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Engine-devel mailing list > > > > > > > Engine-devel at ovirt.org > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > -- > > > > > > > > > > > > David Ja?a, RHCE > > > > > > > > > > > > SPICE QE based in Brno > > > > > > GPG Key: 22C33E24 > > > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 > > > > > > 3E24 > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Engine-devel mailing list > > > > > > Engine-devel at ovirt.org > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > David Ja?a, RHCE > > SPICE QE based in Brno > GPG Key: 22C33E24 > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24 > > > > From ecohen at redhat.com Fri May 18 10:02:03 2012 From: ecohen at redhat.com (Einav Cohen) Date: Fri, 18 May 2012 06:02:03 -0400 (EDT) Subject: [Engine-devel] custom properties sheet feature page In-Reply-To: <8a7fb724-0b4f-496b-af38-4d9bd2da5682@zmail14.collab.prod.int.phx2.redhat.com> Message-ID: <9b43cec7-3abc-4c6a-9481-f32090a93fae@zmail04.collab.prod.int.phx2.redhat.com> > ----- Original Message ----- > From: "Gilad Chaplik" > Sent: Friday, May 18, 2012 12:56:00 PM > > ----- Original Message ----- > > From: "David Ja?a" > > To: "Gilad Chaplik" > > Cc: "Einav Cohen" , engine-devel at ovirt.org, > > "Miki Kenneth" , "Andrew Cathrow" > > , "Simon Grinberg" , > > "Eldan Hildesheim" , "Eldan > > Hildesheim" > > Sent: Friday, May 18, 2012 12:51:43 PM > > Subject: Re: [Engine-devel] custom properties sheet feature page > > > > Gilad Chaplik p??e v P? 18. 05. 2012 v 05:44 -0400: > > > ----- Original Message ----- > > > > From: "Einav Cohen" > > > > To: "Gilad Chaplik" > > > > Cc: engine-devel at ovirt.org, "David Ja?a" , > > > > "Miki Kenneth" , "Andrew Cathrow" > > > > , "Simon Grinberg" , > > > > "Eldan Hildesheim" , "Eldan > > > > Hildesheim" > > > > Sent: Friday, May 18, 2012 12:35:34 PM > > > > Subject: Re: [Engine-devel] custom properties sheet feature > > > > page > > > > > > > > > ----- Original Message ----- > > > > > From: "Gilad Chaplik" > > > > > Sent: Friday, May 18, 2012 12:25:45 PM > > > > > > > > > > inline > > > > > > > > > > Thanks, > > > > > Gilad. > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Einav Cohen" > > > > > > To: "David Ja?a" , "Miki Kenneth" > > > > > > , "Andrew Cathrow" > > > > > > , > > > > > > "Simon Grinberg" , "Eldan Hildesheim" > > > > > > , "Eldan Hildesheim" > > > > > > , "Gilad Chaplik" > > > > > > Cc: engine-devel at ovirt.org > > > > > > Sent: Friday, May 18, 2012 12:12:54 PM > > > > > > Subject: Re: [Engine-devel] custom properties sheet feature > > > > > > page > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "David Ja?a" > > > > > > > Sent: Friday, May 18, 2012 11:33:44 AM > > > > > > > > > > > > > > Einav Cohen p??e v ?t 17. 05. 2012 v 10:14 -0400: > > > > > > > > > ----- Original Message ----- > > > > > > > > > From: "David Ja?a" > > > > > > > > > Sent: Thursday, May 17, 2012 4:44:10 PM > > > > > > > > > > > > > > > > > > Einav Cohen p??e v ?t 17. 05. 2012 v 09:30 -0400: > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > From: "David Ja?a" > > > > > > > > > > > Sent: Thursday, May 17, 2012 3:40:19 PM > > > > > > > > > > > > > > > > > > > > > > Einav Cohen p??e v ?t 17. 05. 2012 v 08:10 -0400: > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > Please review/comment on the Custom Properties > > > > > > > > > > > > Sheet > > > > > > > > > > > > feature > > > > > > > > > > > > page: > > > > > > > > > > > > http://www.ovirt.org/wiki/Features/CustomPropertiesSheet > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Just my $0.02: > > > > > > > > > > > > > > > > > > > > > > The table could have always empty row at the > > > > > > > > > > > bottom, > > > > > > > > > > > eliminating > > > > > > > > > > > one > > > > > > > > > > > or > > > > > > > > > > > all [+] buttons and saving user one needless > > > > > > > > > > > click: > > > > > > > > > > > > > > > > > > > > > > [ key1 |v] [ value ] [+] [-] > > > > > > > > > > > [ key2 |v] [ value ] [+] [-] > > > > > > > > > > > [ key3 |v] [ value ] [-] > > > > > > > > > > > [ "please select a key..." |v] > > > > > > > > > > > > > > > > > > > > > > The [+] buttons at first and second rows would > > > > > > > > > > > allow > > > > > > > > > > > user > > > > > > > > > > > to > > > > > > > > > > > insert a > > > > > > > > > > > row at specified location to make easy custom > > > > > > > > > > > sorting > > > > > > > > > > > of > > > > > > > > > > > the > > > > > > > > > > > properties > > > > > > > > > > > (not applicable if properties are auto-sorted, in > > > > > > > > > > > that > > > > > > > > > > > case, > > > > > > > > > > > all > > > > > > > > > > > [+] > > > > > > > > > > > buttons can be actually removed). > > > > > > > > > > > > > > > > > > > > Thanks for the input, David. This is an interesting > > > > > > > > > > idea. > > > > > > > > > > > > > > > > > > > > Indeed, when choosing a key in the last row, we can > > > > > > > > > > automatically > > > > > > > > > > add a new "please select a key..." row, which > > > > > > > > > > actually > > > > > > > > > > saves > > > > > > > > > > the > > > > > > > > > > user a button-click for adding a new row. > > > > > > > > > > > > > > > > > > > > On the other hand, from graphic-design point of > > > > > > > > > > view, > > > > > > > > > > it > > > > > > > > > > will > > > > > > > > > > look > > > > > > > > > > more consistent and "pretty" if: > > > > > > > > > > - The "please select a key..." row won't be > > > > > > > > > > displayed > > > > > > > > > > (unless, > > > > > > > > > > or > > > > > > > > > > course, the user explicitly chose to add another > > > > > > > > > > row) > > > > > > > > > > - All (full) rows will have both [+] and [-] > > > > > > > > > > buttons > > > > > > > > > > next > > > > > > > > > > to > > > > > > > > > > them > > > > > > > > > > > > > > I should have probably elaborated more on this. To me, UI > > > > > > > with > > > > > > > less > > > > > > > elements looks cleaner and prettier even when one of them > > > > > > > stands > > > > > > > out. > > > > > > > There's also nothing wrong with standing out if the > > > > > > > element > > > > > > > has > > > > > > > "special" meaning (one add vs bunch of modify). > > > > > > > > > > > > > > Specifically, this looks cleaner to my eyes: > > > > > > > > > > > > > > [ key1 |v] [ value ] [-] > > > > > > > [ key2 |v] [ value ] [-] > > > > > > > [ key3 |v] [ value ] [-] > > > > > > > [ "Please select a key..." |v] > > > > > > > > > > > > > > than > > > > > > > > > > > > > > [ key1 |v] [ value ] [+] [-] > > > > > > > [ key2 |v] [ value ] [+] [-] > > > > > > > [ key3 |v] [ value ] [+] [-] > > > > > > > > > > > > > > > > > > > > > > > > > > Note that in your suggestion above, you cannot insert a new > > > > > > key > > > > > > in > > > > > > between existing keys - only at the end; so > > > > > > although "cleaner", it has less functionality (depends also > > > > > > on > > > > > > the > > > > > > sorting, which is another issue; if there is auto-sorting, > > > > > > it > > > > > > doesn't matter). > > > > > > It is also a matter of taste, I guess, so no absolute right > > > > > > or > > > > > > wrong > > > > > > here IMO. > > > > > > [Others - you are welcome to comment as well] > > > > > > > > > > +1 > > > > > > > > > > another tiny comment: > > > > > can the empty line contain all the fields from initial state > > > > > [["please select a key..."][field(empty)][+][-]] > > > > > instead of showing them only after selecting a key. > > > > > [["please select a key..."]] > > > > > > > > > > both of these scenarios are liable, > > > > > I can select a key, regret (change back to [please select a > > > > > key]) > > > > > and > > > > > the field and buttons are still visible. > > > > > > > > > > so for the sake of complexity, I prefer to have only one. > > > > > > > > * Note that the field input control type (text-box, drop-down) > > > > depends on the key anyway (more accurately, on the validation > > > > regular expression of the key), so what are you going to show > > > > in > > > > case of "please select a key..."? > > > > > > empty text-box > > > > > > > > > > > * Need to make sure that validation fails in case field value > > > > is > > > > not > > > > empty and key is "please select a key...". > > > > > > > > I would prefer to just disable the value input field and do > > re-validation upon change of key (clear the value if it fails > > validation > > against a new key) or server-side when it is changed (clear the > > key-value pair altogether). > > +1 for disabling > -1 for clearing - it is not advised to clear a field if its fails on > validation. > > > > > David > > > > > > Due to both of these reasons, I prefer to not show an input > > > > control > > > > at all in this case. > > > > > > still, I don't see any difference, except adding > > > complexity/devel-time/bugs later on. > > > plus I think it's nicer. > > > > > > > > > > > * No problem of having a "+" button there; however, need to > > > > make > > > > sure > > > > that in case there is only one row in the sheet and it is with > > > > "please select a key...", the "-" button should be either > > > > hidden > > > > or > > > > disabled (or non-responsive), since we can't remove the last > > > > row. Don't forget to take this ^^^ also under consideration. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If the [+] button in my proposal is just greyed out > > > > > > > > > instead > > > > > > > > > of > > > > > > > > > ommited, > > > > > > > > > it could satisfy both requirements. > > > > > > > > > > > > > > > > Almost; the "please select a key..." row is still > > > > > > > > always > > > > > > > > displayed; > > > > > > > > question is if we want to save a button-click (your > > > > > > > > suggestion) > > > > > > > > or > > > > > > > > to have a "cleaner" sheet (my suggestion). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > i.e., instead of your suggestion, which looks like > > > > > > > > > > this: > > > > > > > > > > > > > > > > > > > > [ key1 |v] [ value ] [+] [-] > > > > > > > > > > [ key2 |v] [ value ] [+] [-] > > > > > > > > > > [ key3 |v] [ value ] [-] > > > > > > > > > > [ "please select a key..." |v] > > > > > > > > > > > > > > > > > > > > it will be "prettier" like this: > > > > > > > > > > > > > > > > > > > > [ key1 |v] [ value ] [+] [-] > > > > > > > > > > [ key2 |v] [ value ] [+] [-] > > > > > > > > > > [ key3 |v] [ value ] [+] [-] > > > > > > > > > > > > > > > > > > > > and only if clicking on [+], it will be: > > > > > > > > > > > > > > > > > > > > [ key1 |v] [ value ] [+] [-] > > > > > > > > > > [ key2 |v] [ value ] [+] [-] > > > > > > > > > > [ key3 |v] [ value ] [+] [-] > > > > > > > > > > [ "please select a key..." |v] > > > > > > > > > > > > > > > > > > > > I believe that auto-sorting can be confusing, as it > > > > > > > > > > can > > > > > > > > > > result > > > > > > > > > > in > > > > > > > > > > rows "jumping" up and down whenever changing the > > > > > > > > > > selection(s) > > > > > > > > > > in > > > > > > > > > > the Key drop-down(s), > > > > > > > > > > > > > > > > > > this could be sort of mitigated by sorting > > > > > > > > > server-side > > > > > > > > > upon > > > > > > > > > modification. > > > > > > > > > > > > > > > > > > > therefore I don't think it is a good idea to > > > > > > > > > > implement > > > > > > > > > > it > > > > > > > > > > here. > > > > > > > > > > > > > > > > > > OTOH if we're to be manual sorting friendly, we > > > > > > > > > should > > > > > > > > > allow > > > > > > > > > rearranging > > > > > > > > > of the rows by drag & drop or by some sort of move > > > > > > > > > up/down > > > > > > > > > buttons > > > > > > > > > and > > > > > > > > > the dialog would start to be cluttered. > > > > > > > > > > > > > > > > > > I don't really like either of these but auto-sort is > > > > > > > > > slightly > > > > > > > > > better > > > > > > > > > IMO > > > > > > > > > as it is kept consistent accross various VMs without > > > > > > > > > user > > > > > > > > > interaction. > > > > > > > > > > > > > > > > Indeed, auto-sort will keep the order consistent across > > > > > > > > all > > > > > > > > VMs. > > > > > > > > However, maybe the user would like to see the > > > > > > > > properties > > > > > > > > in > > > > > > > > the > > > > > > > > order in which he filled them; in this case, your > > > > > > > > suggestion > > > > > > > > of > > > > > > > > "move up/down buttons" is probably relevant here. > > > > > > > > > > > > > > > > I believe that the majority of use-cases won't require > > > > > > > > more > > > > > > > > than > > > > > > > > 2 > > > > > > > > or 3 custom properties per VM, so sorting won't be that > > > > > > > > critical, > > > > > > > > therefore I assume we can start without it; I will add > > > > > > > > "sorting" > > > > > > > > to the "open issues" section in the wiki page. > > > > > > > > > > > > > > > > > > > > > > That seems as more argument in favor of auto sorting. > > > > > > > > > > > > Or no sorting at all (i.e. simply display in order of > > > > > > filling)... > > > > > > In any case, open issue has been added to the wiki. > > > > > > > > > > > > > > > > > > > > David > > > > > > > > > > > > > > > > > > > > > > > > > David > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > David > > > > > > > > > > > > > > > > > > > > > > > ---- > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Einav > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > Engine-devel mailing list > > > > > > > > > > > > Engine-devel at ovirt.org > > > > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > David Ja?a, RHCE > > > > > > > > > > > > > > > > > > > > > > SPICE QE based in Brno > > > > > > > > > > > GPG Key: 22C33E24 > > > > > > > > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 > > > > > > > > > > > CD00 > > > > > > > > > > > 22C3 > > > > > > > > > > > 3E24 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > Engine-devel mailing list > > > > > > > > > > > Engine-devel at ovirt.org > > > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > David Ja?a, RHCE > > > > > > > > > > > > > > > > > > SPICE QE based in Brno > > > > > > > > > GPG Key: 22C33E24 > > > > > > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 > > > > > > > > > 22C3 > > > > > > > > > 3E24 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Engine-devel mailing list > > > > > > > > Engine-devel at ovirt.org > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > David Ja?a, RHCE > > > > > > > > > > > > > > SPICE QE based in Brno > > > > > > > GPG Key: 22C33E24 > > > > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 > > > > > > > 3E24 > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Engine-devel mailing list > > > > > > > Engine-devel at ovirt.org > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > David Ja?a, RHCE > > > > SPICE QE based in Brno > > GPG Key: 22C33E24 > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24 > > > > > > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > From gchaplik at redhat.com Fri May 18 10:15:16 2012 From: gchaplik at redhat.com (Gilad Chaplik) Date: Fri, 18 May 2012 06:15:16 -0400 (EDT) Subject: [Engine-devel] custom properties sheet feature page In-Reply-To: <9b43cec7-3abc-4c6a-9481-f32090a93fae@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <9f1cb6e4-dfd4-49fc-bc64-0f6e14e7c432@zmail14.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Einav Cohen" > To: "Gilad Chaplik" > Cc: "Eldan Hildesheim" , engine-devel at ovirt.org, "Simon Grinberg" , "Eldan > Hildesheim" , "David Ja?a" > Sent: Friday, May 18, 2012 1:02:03 PM > Subject: Re: [Engine-devel] custom properties sheet feature page > > > ----- Original Message ----- > > From: "Gilad Chaplik" > > Sent: Friday, May 18, 2012 12:56:00 PM > > > > ----- Original Message ----- > > > From: "David Ja?a" > > > To: "Gilad Chaplik" > > > Cc: "Einav Cohen" , engine-devel at ovirt.org, > > > "Miki Kenneth" , "Andrew Cathrow" > > > , "Simon Grinberg" , > > > "Eldan Hildesheim" , "Eldan > > > Hildesheim" > > > Sent: Friday, May 18, 2012 12:51:43 PM > > > Subject: Re: [Engine-devel] custom properties sheet feature page > > > > > > Gilad Chaplik p??e v P? 18. 05. 2012 v 05:44 -0400: > > > > ----- Original Message ----- > > > > > From: "Einav Cohen" > > > > > To: "Gilad Chaplik" > > > > > Cc: engine-devel at ovirt.org, "David Ja?a" , > > > > > "Miki Kenneth" , "Andrew Cathrow" > > > > > , "Simon Grinberg" > > > > > , > > > > > "Eldan Hildesheim" , "Eldan > > > > > Hildesheim" > > > > > Sent: Friday, May 18, 2012 12:35:34 PM > > > > > Subject: Re: [Engine-devel] custom properties sheet feature > > > > > page > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Gilad Chaplik" > > > > > > Sent: Friday, May 18, 2012 12:25:45 PM > > > > > > > > > > > > inline > > > > > > > > > > > > Thanks, > > > > > > Gilad. > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Einav Cohen" > > > > > > > To: "David Ja?a" , "Miki Kenneth" > > > > > > > , "Andrew Cathrow" > > > > > > > , > > > > > > > "Simon Grinberg" , "Eldan > > > > > > > Hildesheim" > > > > > > > , "Eldan Hildesheim" > > > > > > > , "Gilad Chaplik" > > > > > > > Cc: engine-devel at ovirt.org > > > > > > > Sent: Friday, May 18, 2012 12:12:54 PM > > > > > > > Subject: Re: [Engine-devel] custom properties sheet > > > > > > > feature > > > > > > > page > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "David Ja?a" > > > > > > > > Sent: Friday, May 18, 2012 11:33:44 AM > > > > > > > > > > > > > > > > Einav Cohen p??e v ?t 17. 05. 2012 v 10:14 -0400: > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > From: "David Ja?a" > > > > > > > > > > Sent: Thursday, May 17, 2012 4:44:10 PM > > > > > > > > > > > > > > > > > > > > Einav Cohen p??e v ?t 17. 05. 2012 v 09:30 -0400: > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > From: "David Ja?a" > > > > > > > > > > > > Sent: Thursday, May 17, 2012 3:40:19 PM > > > > > > > > > > > > > > > > > > > > > > > > Einav Cohen p??e v ?t 17. 05. 2012 v 08:10 > > > > > > > > > > > > -0400: > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > > > Please review/comment on the Custom > > > > > > > > > > > > > Properties > > > > > > > > > > > > > Sheet > > > > > > > > > > > > > feature > > > > > > > > > > > > > page: > > > > > > > > > > > > > http://www.ovirt.org/wiki/Features/CustomPropertiesSheet > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Just my $0.02: > > > > > > > > > > > > > > > > > > > > > > > > The table could have always empty row at the > > > > > > > > > > > > bottom, > > > > > > > > > > > > eliminating > > > > > > > > > > > > one > > > > > > > > > > > > or > > > > > > > > > > > > all [+] buttons and saving user one needless > > > > > > > > > > > > click: > > > > > > > > > > > > > > > > > > > > > > > > [ key1 |v] [ value ] [+] > > > > > > > > > > > > [-] > > > > > > > > > > > > [ key2 |v] [ value ] [+] > > > > > > > > > > > > [-] > > > > > > > > > > > > [ key3 |v] [ value ] > > > > > > > > > > > > [-] > > > > > > > > > > > > [ "please select a key..." |v] > > > > > > > > > > > > > > > > > > > > > > > > The [+] buttons at first and second rows would > > > > > > > > > > > > allow > > > > > > > > > > > > user > > > > > > > > > > > > to > > > > > > > > > > > > insert a > > > > > > > > > > > > row at specified location to make easy custom > > > > > > > > > > > > sorting > > > > > > > > > > > > of > > > > > > > > > > > > the > > > > > > > > > > > > properties > > > > > > > > > > > > (not applicable if properties are auto-sorted, > > > > > > > > > > > > in > > > > > > > > > > > > that > > > > > > > > > > > > case, > > > > > > > > > > > > all > > > > > > > > > > > > [+] > > > > > > > > > > > > buttons can be actually removed). > > > > > > > > > > > > > > > > > > > > > > Thanks for the input, David. This is an > > > > > > > > > > > interesting > > > > > > > > > > > idea. > > > > > > > > > > > > > > > > > > > > > > Indeed, when choosing a key in the last row, we > > > > > > > > > > > can > > > > > > > > > > > automatically > > > > > > > > > > > add a new "please select a key..." row, which > > > > > > > > > > > actually > > > > > > > > > > > saves > > > > > > > > > > > the > > > > > > > > > > > user a button-click for adding a new row. > > > > > > > > > > > > > > > > > > > > > > On the other hand, from graphic-design point of > > > > > > > > > > > view, > > > > > > > > > > > it > > > > > > > > > > > will > > > > > > > > > > > look > > > > > > > > > > > more consistent and "pretty" if: > > > > > > > > > > > - The "please select a key..." row won't be > > > > > > > > > > > displayed > > > > > > > > > > > (unless, > > > > > > > > > > > or > > > > > > > > > > > course, the user explicitly chose to add another > > > > > > > > > > > row) > > > > > > > > > > > - All (full) rows will have both [+] and [-] > > > > > > > > > > > buttons > > > > > > > > > > > next > > > > > > > > > > > to > > > > > > > > > > > them > > > > > > > > > > > > > > > > I should have probably elaborated more on this. To me, > > > > > > > > UI > > > > > > > > with > > > > > > > > less > > > > > > > > elements looks cleaner and prettier even when one of > > > > > > > > them > > > > > > > > stands > > > > > > > > out. > > > > > > > > There's also nothing wrong with standing out if the > > > > > > > > element > > > > > > > > has > > > > > > > > "special" meaning (one add vs bunch of modify). > > > > > > > > > > > > > > > > Specifically, this looks cleaner to my eyes: > > > > > > > > > > > > > > > > [ key1 |v] [ value ] [-] > > > > > > > > [ key2 |v] [ value ] [-] > > > > > > > > [ key3 |v] [ value ] [-] > > > > > > > > [ "Please select a key..." |v] > > > > > > > > > > > > > > > > than > > > > > > > > > > > > > > > > [ key1 |v] [ value ] [+] [-] > > > > > > > > [ key2 |v] [ value ] [+] [-] > > > > > > > > [ key3 |v] [ value ] [+] [-] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Note that in your suggestion above, you cannot insert a > > > > > > > new > > > > > > > key > > > > > > > in > > > > > > > between existing keys - only at the end; so > > > > > > > although "cleaner", it has less functionality (depends > > > > > > > also > > > > > > > on > > > > > > > the > > > > > > > sorting, which is another issue; if there is > > > > > > > auto-sorting, > > > > > > > it > > > > > > > doesn't matter). > > > > > > > It is also a matter of taste, I guess, so no absolute > > > > > > > right > > > > > > > or > > > > > > > wrong > > > > > > > here IMO. > > > > > > > [Others - you are welcome to comment as well] > > > > > > > > > > > > +1 > > > > > > > > > > > > another tiny comment: > > > > > > can the empty line contain all the fields from initial > > > > > > state > > > > > > [["please select a key..."][field(empty)][+][-]] > > > > > > instead of showing them only after selecting a key. > > > > > > [["please select a key..."]] > > > > > > > > > > > > both of these scenarios are liable, > > > > > > I can select a key, regret (change back to [please select a > > > > > > key]) > > > > > > and > > > > > > the field and buttons are still visible. > > > > > > > > > > > > so for the sake of complexity, I prefer to have only one. > > > > > > > > > > * Note that the field input control type (text-box, > > > > > drop-down) > > > > > depends on the key anyway (more accurately, on the validation > > > > > regular expression of the key), so what are you going to show > > > > > in > > > > > case of "please select a key..."? > > > > > > > > empty text-box > > > > > > > > > > > > > > * Need to make sure that validation fails in case field value > > > > > is > > > > > not > > > > > empty and key is "please select a key...". > > > > > > > > > > > I would prefer to just disable the value input field and do > > > re-validation upon change of key (clear the value if it fails > > > validation > > > against a new key) or server-side when it is changed (clear the > > > key-value pair altogether). > > > > +1 for disabling > > -1 for clearing - it is not advised to clear a field if its fails > > on > > validation. > > > > > > > > David > > > > > > > > Due to both of these reasons, I prefer to not show an input > > > > > control > > > > > at all in this case. > > > > > > > > still, I don't see any difference, except adding > > > > complexity/devel-time/bugs later on. > > > > plus I think it's nicer. > > > > > > > > > > > > > > * No problem of having a "+" button there; however, need to > > > > > make > > > > > sure > > > > > that in case there is only one row in the sheet and it is > > > > > with > > > > > "please select a key...", the "-" button should be either > > > > > hidden > > > > > or > > > > > disabled (or non-responsive), since we can't remove the last > > > > > row. > > Don't forget to take this ^^^ also under consideration. silence means agreement :) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If the [+] button in my proposal is just greyed out > > > > > > > > > > instead > > > > > > > > > > of > > > > > > > > > > ommited, > > > > > > > > > > it could satisfy both requirements. > > > > > > > > > > > > > > > > > > Almost; the "please select a key..." row is still > > > > > > > > > always > > > > > > > > > displayed; > > > > > > > > > question is if we want to save a button-click (your > > > > > > > > > suggestion) > > > > > > > > > or > > > > > > > > > to have a "cleaner" sheet (my suggestion). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > i.e., instead of your suggestion, which looks > > > > > > > > > > > like > > > > > > > > > > > this: > > > > > > > > > > > > > > > > > > > > > > [ key1 |v] [ value ] [+] [-] > > > > > > > > > > > [ key2 |v] [ value ] [+] [-] > > > > > > > > > > > [ key3 |v] [ value ] [-] > > > > > > > > > > > [ "please select a key..." |v] > > > > > > > > > > > > > > > > > > > > > > it will be "prettier" like this: > > > > > > > > > > > > > > > > > > > > > > [ key1 |v] [ value ] [+] [-] > > > > > > > > > > > [ key2 |v] [ value ] [+] [-] > > > > > > > > > > > [ key3 |v] [ value ] [+] [-] > > > > > > > > > > > > > > > > > > > > > > and only if clicking on [+], it will be: > > > > > > > > > > > > > > > > > > > > > > [ key1 |v] [ value ] [+] [-] > > > > > > > > > > > [ key2 |v] [ value ] [+] [-] > > > > > > > > > > > [ key3 |v] [ value ] [+] [-] > > > > > > > > > > > [ "please select a key..." |v] > > > > > > > > > > > > > > > > > > > > > > I believe that auto-sorting can be confusing, as > > > > > > > > > > > it > > > > > > > > > > > can > > > > > > > > > > > result > > > > > > > > > > > in > > > > > > > > > > > rows "jumping" up and down whenever changing the > > > > > > > > > > > selection(s) > > > > > > > > > > > in > > > > > > > > > > > the Key drop-down(s), > > > > > > > > > > > > > > > > > > > > this could be sort of mitigated by sorting > > > > > > > > > > server-side > > > > > > > > > > upon > > > > > > > > > > modification. > > > > > > > > > > > > > > > > > > > > > therefore I don't think it is a good idea to > > > > > > > > > > > implement > > > > > > > > > > > it > > > > > > > > > > > here. > > > > > > > > > > > > > > > > > > > > OTOH if we're to be manual sorting friendly, we > > > > > > > > > > should > > > > > > > > > > allow > > > > > > > > > > rearranging > > > > > > > > > > of the rows by drag & drop or by some sort of move > > > > > > > > > > up/down > > > > > > > > > > buttons > > > > > > > > > > and > > > > > > > > > > the dialog would start to be cluttered. > > > > > > > > > > > > > > > > > > > > I don't really like either of these but auto-sort > > > > > > > > > > is > > > > > > > > > > slightly > > > > > > > > > > better > > > > > > > > > > IMO > > > > > > > > > > as it is kept consistent accross various VMs > > > > > > > > > > without > > > > > > > > > > user > > > > > > > > > > interaction. > > > > > > > > > > > > > > > > > > Indeed, auto-sort will keep the order consistent > > > > > > > > > across > > > > > > > > > all > > > > > > > > > VMs. > > > > > > > > > However, maybe the user would like to see the > > > > > > > > > properties > > > > > > > > > in > > > > > > > > > the > > > > > > > > > order in which he filled them; in this case, your > > > > > > > > > suggestion > > > > > > > > > of > > > > > > > > > "move up/down buttons" is probably relevant here. > > > > > > > > > > > > > > > > > > I believe that the majority of use-cases won't > > > > > > > > > require > > > > > > > > > more > > > > > > > > > than > > > > > > > > > 2 > > > > > > > > > or 3 custom properties per VM, so sorting won't be > > > > > > > > > that > > > > > > > > > critical, > > > > > > > > > therefore I assume we can start without it; I will > > > > > > > > > add > > > > > > > > > "sorting" > > > > > > > > > to the "open issues" section in the wiki page. > > > > > > > > > > > > > > > > > > > > > > > > > That seems as more argument in favor of auto sorting. > > > > > > > > > > > > > > Or no sorting at all (i.e. simply display in order of > > > > > > > filling)... > > > > > > > In any case, open issue has been added to the wiki. > > > > > > > > > > > > > > > > > > > > > > > David > > > > > > > > > > > > > > > > > > > > > > > > > > > > David > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > David > > > > > > > > > > > > > > > > > > > > > > > > > ---- > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > Einav > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > Engine-devel mailing list > > > > > > > > > > > > > Engine-devel at ovirt.org > > > > > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > David Ja?a, RHCE > > > > > > > > > > > > > > > > > > > > > > > > SPICE QE based in Brno > > > > > > > > > > > > GPG Key: 22C33E24 > > > > > > > > > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 > > > > > > > > > > > > CD00 > > > > > > > > > > > > 22C3 > > > > > > > > > > > > 3E24 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > Engine-devel mailing list > > > > > > > > > > > > Engine-devel at ovirt.org > > > > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > David Ja?a, RHCE > > > > > > > > > > > > > > > > > > > > SPICE QE based in Brno > > > > > > > > > > GPG Key: 22C33E24 > > > > > > > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 > > > > > > > > > > CD00 > > > > > > > > > > 22C3 > > > > > > > > > > 3E24 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Engine-devel mailing list > > > > > > > > > Engine-devel at ovirt.org > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > David Ja?a, RHCE > > > > > > > > > > > > > > > > SPICE QE based in Brno > > > > > > > > GPG Key: 22C33E24 > > > > > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 > > > > > > > > 22C3 > > > > > > > > 3E24 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Engine-devel mailing list > > > > > > > > Engine-devel at ovirt.org > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > David Ja?a, RHCE > > > > > > SPICE QE based in Brno > > > GPG Key: 22C33E24 > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24 > > > > > > > > > > > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > From jhernand at redhat.com Fri May 18 10:43:27 2012 From: jhernand at redhat.com (Juan Hernandez) Date: Fri, 18 May 2012 12:43:27 +0200 Subject: [Engine-devel] Java 7: Fix namespaces use in OVF writer Message-ID: <4FB627CF.8050805@redhat.com> Hello, I recently submitted a change to fix the way we manage namespaces in the OVF writer: http://gerrit.ovirt.org/4540 The problem is that it doesn't work with the StAX reference implementation included with Java 7. With the patched OVF writer I generated the attached OVF file. I would appreciate if someone can take a quick look at it and tell me if it is correct. I would also appreciate if you can send me known good OVF files generated by the engine, to compare them with the ones produced with the patched OVF writer. Thanks in advance, Juan Hernandez -- Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3?D, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat S.L. -------------- next part -------------- A non-text attachment was scrubbed... Name: myserver.ovf Type: text/xml Size: 4501 bytes Desc: not available URL: From iheim at redhat.com Fri May 18 10:07:50 2012 From: iheim at redhat.com (Itamar Heim) Date: Fri, 18 May 2012 13:07:50 +0300 Subject: [Engine-devel] [Users] oVirt and Quantum In-Reply-To: <4FB2697B.4000406@redhat.com> References: <4F9D1AD4.8070503@redhat.com> <4FB23232.7090008@redhat.com> <4FB2697B.4000406@redhat.com> Message-ID: <4FB61F76.5000205@redhat.com> On 05/15/2012 05:34 PM, Gary Kotton wrote: ... >> 2. host management --> interface >> 2.1 you are suggesting to remove the vlan field with a fabric field? >> are we sure this is something which shouldn't be presented in the main >> view and only via extended properties? > Yes, this is what I am suggesting. VLAN tagging is one method of network > isolation. There are more, for example GRE tunneling. that doesn't mean this is not an important enough piece of information to have in the subtab, rather than in an additional dialog (the fabric type could be represented in an icon for example) miki/andrew/einav - thoughts on the UI aspect of this? >> >> 2.2 is the fabric really a host interface level property, or a cluster >> wide property (would same logical network be implemented on different >> hosts in the cluster via both vdsm and quantum)? >> would live migration work in same cluster if one host has qunatum >> fabric and another vdsm fabric for same logical network? > These are all up for discussion. I just wanted to provide something that > we can start to work with. It would be nice if there was some input from > product management on this issue (not exactly sure how this works in an > open source community :)) This goes to assumptions on qunatum integration and capabilities. I'm missing this part in the beginning of the feature page. if quantum can support multiple types, and live migration between, then it can a host level config. if live migration wouldn't work, it would have to be a cluster level config. if it is limited to a single technology, it is kind of a system level config. (and actually, after reading your reply to 3.7.1, i understand the plugin is an interface level config, since you can have more than a single one on the same host). same goes to implications to the logical network entity (see my comment in 2.4 below). I'd also like to understand in that regard how do we match up host reporting it can support (i.e., installed and configured) to a specific technology. i.e., there needs to be some correlation between which logical networks can be deployed on which plugin. so also need to understand how this correlation is done automatically between logical network, to which fabric/interface it belongs to. (I admit your reply to 3.7.1 confused me as to how quantum will decide on which plugin to create a specific attachment)? >> >> 2.3 you are describing the subtab of an interface, and mention a >> qunatum pull down menu. is this in the subtab? in a dialog? >> UI mockups are needed here. > I think that prior to getting mockups, we should ensure that we have the > idea crystallized. I can live with that, goes back to what i wrote in 2.2. >> >> 2.4 also, is this pulldown correct at host level or cluster level >> (would live migration work between hosts implementing different >> plugins for same logical network in same cluster?) as i stated above - this has to be clarified in assumptions. doesn't have to be the current state, rather a clear understanding where it is going to, or as to what makes sense. (I am not sure requiring live migration between multiple technologies makes sense, since implementation of the logical network could be based on different concepts (vlan vs. gre). however, this means we need to define if the logical network (which is not limited to a cluster) should be limited to clusters supporting these technologies. i.e., a vlan based logical network can cross (in different clusters) UCS, openvswitch and bridges. but a gre based logical network cannot cross all of them, etc. >> >> on to backend: >> 3.1 "The Quantum Service is a process that runs the Quantum API web >> server (port 9696)" >> >> how is authentication between engine and quantum service is done (we >> have a client certificate for engine which qunatum can verify i guess) > In my opinion this should be running locally on the same host as the > engine. even on same server, we have authentication between components running in different processes. on top of that, one of our main goals is to allow multiple engines running side by side for scale. maybe quantum will have to be in active/passive mode for a while, but multiple nodes should be able to access it. there is no need for fancy authentication/authorization. simply trusting ovirt engine CA certificate and validating engine client certificate should suffice (and i assume can be done via config in the http layer of quantum). also, this can be a phase 2, but let's have a list of what is a must for merging the code (this isn't), to deployment (phase 2), to more than that (phase 3). under deployment i'd expect not requiring a different db technology, integrating with installer, an upgrade path, cleaner and secure communication channels, etc. >> >> 3.2 is there a config of the quantum service uri? should it be a >> single instance or a per DC property? >> (it sounds like a per DC property, can be a future thing) > I am sorry but I do not understand the question. even if quantum is running on same host, you will have a configuration item of the URI to the service, and will configure this as part of installation flow. if this is not configured, I'd expect engine/ui to not show quantum options. is this a single uri or a DC instance level property goes to modeling/assumptions part. can we live with a single quantum service for multiple technologies, or will need different quantum for different technologies. this can also be a later phase, starting with a limitation of a single, system-wide quantum. >> >> 3.3 network creation >> >> semantics: we create a network at DC level. we attach it at cluster >> level. the UI allows you to "create at DC and attach to cluster" at >> cluster level. >> >> 3.3.1 what if i create a network with same VLAN in two DC's? what if >> we attach same logical network to multiple clusters - each will create >> the logical network in qunatum again? > If I understand you correctly then I think that one Quantum network can > be created. This should work. In my opinion this should be managed by > the oVirt engine so the actual creation is not an issue. Ensuring that > each cluster has the correct network management configurations is what > is important. >> 3.3.2 what if the qunatum service is down when engine performs this >> action or quantum returns an error? > The engine should be able to deal with this - similar to the way in > which it deals with a network creation when VDSM is down. network creation is not affected when VDSM is down, as the admin configures it on the hosts after it is created (via the UI). in quantum case, there is no admin step. so need to solve engine monitoring quantum for list of networks relevant to a cluster are defined to mark non defined networks as non-operational, and have timer based or manual retry mechanism. I don't think this is a merge blocker to code, but it should be part of the phase 1 of this feature. >> 3.3.3 each creation of a DC creates a rhevm network - I assume these >> are not created, since "no host in a cluster in the DC yet"? > This functionally can remain the same. ok, goes to assumptions part. "quantum integration will be done only for vm networks" >> 3.3.4 what happens on moving of a host to another cluster, or moving >> of a cluster to another DC (possible if it's DC was removed iirc). > The Quantum agents take care of this. On each host there will be a > Quantum agent that treats the network management. I meant in the aspect of provisioning needed configuration to the host (doing it when a host tries to go to up status is fine, but need to remember this use case when desiging, since it means this isn't a bootstrap aspect) also, please document this so flow so someone trying to test the integration covers it. >> 3.3.5 shouldn't this be limited to vm networks, or all networks are >> relevant? > I think all Quantum networks are relevant I understood in 3.3.3 that quantum networks are only relevant to vm networks (networks that can run virtual machines, rather than the management, live migration or storage networks)? (I'd suggest keeping it simple and limited to vm networks for first phase) important part here is code should not try to create this network via quantum i guess. >> 3.3.6 what if the host with the qunatum fabric is in maint mode? > I do not understand. When a host is in maintenace mode do VM's receive > traffic? The Quantum port for the VM's can be set as DOWN I'm offline - we'll need to re-read the wiki to reply. >> 3.3.7 could a host with qunatum fabric have a VDSM fabric on another >> interface (for vm neworks? for non-vm networks)? > Yes. This is something that I would like. I also would like the Quantum then this should go to assumptions part. > API to be updated so that we can indicate the phycal network interface > that the Quantum network will be running on. i don't think this is needed. when admin configures the interface or bond on the host to be 'fabric' or 'quantum' it calls vdsm to perform the network configuration change. this will flag the relevant interface in the host as fabric/quantum (either via config, or alias, etc.) but for modeling sake, can you please explain how this is supposed to look for a UCS host? >> >> 3.5 network deletion (detach network from a cluster) >> 3.5.1 what happens if qunatum is down or returned an error? > The engine should be able to deal with this - similarly to what it does > today see my reply on 3.3.2. this is managed by the admin today. so this is coding to be done that should be documented (it is not a merge blocker in my view, but it is part of phase 1. >> >> 3.6 vm creation >> 3.6.1 what about moving a VM from/to a cluster with a quantum fabric? > I do not see a problem here. The agenets running on VDSM will detect and > treat accordingly. i meant in the aspect of the need to create the port for them in quantum? >> 3.6.2 what about import of a VM into a cluster with a qunatum fabric? > Same as above indeed - need to handle port creations? >> 3.6.3 you have vm creation/removal - missing vnic addition/removal please document this operation so someone testing this will have full picture. >> 3.6.4 worth mentioning qunatum doesn't care about the vnic model? >> about the mac address? > The Quantum driver on VDSM does take into account the MAC address. This > is used in some plugins - for example the openvswicth plugin. ok, can you please explain the flow of data of how it gets it (simply vdsm needs to pass it to the driver?) >> >> 3.7 vm start >> 3.7.1 why is the plugin parameter required at vm start? > This is to indicate to VDSM the operations to take place - for example > updating the openvswitch integration bridge i thought the integration bridge is pre-configured at host level? i thought the host already knows which interface is used for quantum, and for sure, which plugin is supposed to be used for that interface. so why is this a vm start parameter? >> can multiple plugins be supported in parallel at vdsm/host level or by >> the quantum service? > Yes/ Multiple agents can run on VDSM. In the engine a little work is ok, please document this in the assumptions part. i assume multiple agents, but still only one per fabric interface? also, if plugins are services, I want to understand when vdsm needs to start them (I assume when admin configures an interface of type fabric for a specific plugin type). > required to run multiple plugins. in the engine or in quantum? I updated my reply on assumptions above based on this info as something that needs clearing up. >> 3.7.2 aren't network_uuid and port uuid redundant to attachment uuid >> (I assume qunatum service knows from attachment the port and network) >> - i have no objection to passing them to vdsm, just trying to >> understand reasoning for this. >> I am missing what happens at vdsm level in this point (even after >> reading the matching vdsm part) > The network ID and the port ID are returned by the Quantum service. The > attachment ID is passed to the Quantum server. If this is unique then it > can be a key to the above (I am currently working on the scale issue > with Quantum and there are 2 options, the first is that it is unique, > the second is that all three are passed to the agent). It is a few extra > bytes passed. I think that it is better to be safe and have all of the > information on VDSM for future use. >> >> 3.8 vm suspend/resume (it's fine to say it behaves like X, but still >> need to be covered to not cause bugs/regressions) > The Quantum port status can be updated. please document this operation so someone testing this will have full picture. >> >> 3.9 vm stop > Same as above please document this operation so someone testing this will have full picture. >> 3.9.1 need to make sure vm stop when engine is down is handled correctly. this requires adhering to. again, not a merge blocker to code. but in my view part of phase 1 (my view of phase 1 is deployment is still manual, but flows are handled correctly and do not leave leftovers around) please document this operation so someone testing this will have full picture. >> 3.9.2 what happens if qunatum service is down? unlike start vm or >> network creation the operation in this case cannot be >> stopped/rolledback, only rolled forward. > We have to ensure that it is up. we have several use cases requiring to be able to start virtual machines even when engine is down (regardless of HA aspects for the engine). this means admin wants to go to a host, and start the VM from command line. the VM definition is recovered from the OVF for such a manual emergency procedure. sanlock is supposed to protect against vm corruption in this case. but the VMs will need networking to be useful. so what's the emergency flow to starting a VM? >> >> 3.10 hot plug nic? > Each new NIC has an attachment ID - the agent know that a new NIC is > added and treats accordingly. true, but i assume you would need to change the api here to get the quantum details like the attachemnt_id (and the rest). also, all affected use cases should be documented for someone testing this to have full picture of scope. >> >> 3.11 vm migration >> 3.11.1 ok, so this is the first time i understand hosts can be mixed >> in same cluster. worth specifying this in the beginning (still not >> clear if mixed plugins can exist) > If the networks are configured with the same characteristics then this > should be OK. As mentioned above we are working on a blueprint to deal > with connecting to existing networks - i.e. enable the user/admin to > configure the VLAN tags please define under assumptions part what are the network characteristics, how they are mapped to which plugins support which characteristics to be relevant. also, monitoring wise, you are implying each host must be able to accommodate all types of characteristics in the networks in the cluster. >> 3.11.2 afair, we don't deal with engine talking to both hosts during >> live migration. only to host A, who is then communicating with host B. >> so why not always have the VM configuration at vm start (and hot plug >> nic) have the quantum details so live migration can occur at will >> without additional information? > I do not understand can you please explain. VDSM creates the tap device > and builds the libvirt files. The agents detect the tap device and > attach to the network. I do not understand why it is a problem for the > live migration. This is also driven by the libvirt XML's being created. > Is this correct? that is fine. iirc, the wiki states engine needs to pass information to target host. we don't have such a flow in live migration (which is complex enough). live migration should be based on the information already available to vdsm in source host. I don't know if quantum cares about the attachement/port residing on more than one host (the target host has to set them up before migration starts, and source host removes them only after migration ends). i hope we are both understanding this the same way. in any case, need to remember to test failure of live migration in its various steps cleans up any quantum related changes. >> 3.11.3 "In order to implement the above a REST client needs to be >> implemented in the oVirt engine. " >> did not understand this statement - please elaborate. > All interface with the Quantum server is done via REST. In order for > oVirt to be able to communicate, it will need to send REST messages to > the server and be able to parse the replies - this is what I meant by > the REST client. >> >> 4. host management >> 4.1 deployment >> we do not deploy packages from engine to hosts, we can install them >> from a repo configured to the host. but this is done today only as >> part of initial bootstrap/installation of host. >> also, it is not relevant for ovirt node which is 'firmware' like. >> any reason to not require the 'plugin installation packages' at vdsm >> rpm level for plugins we think are good enough to use (until then, >> responsibility to deploy them is of admin) >> > Correct. I agree with you. ok, so on ovirt-node all quantum agents will be pre-installed. if a quantum agent is changed to work correctly with ovirt/vdsm, why not simply always require at rpm level to deploy it on the host? then a regular host and ovirt-node are the same. still need to define how vdsm reports which agents are supported by it (which is different than those which are installed, say for UCS?), which is different from those that are actively running since they are configured). >> (what are plugin level packages at host level - aren't these the agents?) > Each plugin has the relevant packages that should be installed. >> >> 4.2 plugin configuration >> per DC? per cluster? per host? per plugin? please provide more details >> here on configuration details expected and flow of when they are >> configured and when they are expected to change? > I think that plugin per cluster is a good start. This could limit live > migration problems. I agree... question is this part of phases, or part of assumptions (end goal) modeling should be aligned with end goal (i am not suggesting it can do in steps, just that end goal should be understood so it doesn't interrupt it. especially for the API part which requires to keep backward compatibility as much as possible). >> I think this will merit a per 'ovirt supported' qunatum plugin to see >> it works in a way we can use. >> >> 4.3 connectivity >> again, this requires more details. if needed per plugin. >> what is expected? how authentication/encryption happens? what iptables >> rules need to change in engine/host if at all, etc. >> I'm fine with this being 'direct access to db from hosts' for POC >> level of patches, but not for something we actually merge/provide >> support for later. > I am currently working on a blueprint to ensure better scaling of > quantum agents. This will be done by making use of the nova RPC library. > This supports Qpid, rabbit mq, kombu etc. These have an option of being > secure. Please clarify if this suffices? having all work on same channel will solve most problems. still need to map those that require data not in quantum for some reason to try and pass to qunatum the needed data as customer parameters rather than add a channel to engine if possible/makes sense. do all of these require a broker to be deployed? I assume all support certificate based authentication. it should be the same one we'll pick for engine-vdsm (I heard fans of zeromq as well), but this doesn't have to be phase 1, or we might be lucky and agree on one already supported :) >> >> 5. VDSM ... >> >> 5.2 "The agent package can and may be received from the oVirt Engine >> or can be downloaded via RPM's" >> see 4.1 above - we don't deploy rpm's/code on the fly today. > When I was sitting with the guys from oVirt this is what I was told. I > guess that I misunderstood. ok, I assume 4.1 resolves this and we simply deploy all those made to work with ovirt as part of vdsm rpm requirements? (implies each one should have a sub rpm, not sure if that is the case today) >> >> 5.3 "in addition to the treatment below VDSM should also maintain a >> health check to the Quantum agent" >> what if the restart didn't help? how should ovirt treat the host wrt >> networking? to running VMs? to ability to live migrate VMs from the >> host if needed? > If the agent is down then the oVirt engine should be notified to at > least events for the user. ok. I assume vdsm knows which agent to start and later monitor based on the host level config by admin of the fabric interface (whether the plugin type is cluster or interface level) >> >> 5.4 "Logical Network Management" >> please see 3.11 above - we would want live migration to not require >> additional information, so details should be available even if not >> immediately acted upon. >> >> 5.5 "The tap device created uses an "ethernet" network device. This >> means that the creation of the libvirt XML file is a bit different." > Yes, that is correct >> 5.5.1 does this impact stable device addresses somehow? > Not that I am aware of >> 5.5.2 how is live migration possible if the libvirt xml to a non >> quantum host is different (or is this the binding part only)? > If the libvirt is "pacthed" when the migration takes place then this > should not be a problem. does libvirt support something like that? the live migration happens directly between the two libvirt's. libvirt created an abstraction layer to their networking model to allow live migration between host where the physical layer is different so the logical layer remains the same during live migration. I just don't know it the 'ethernet' attribute you mentioned is in that physical mapping layer (which would be fine), or in the logical one (which won't live migrate). please verify with a libvirt expert (dbp modeled that part iirc) >> >> 5.6 I assume libvirtvm.py is part of vdsm. >> is quantum.py part of quantum code base or vdsm codebase (it sounds >> like it should be part of quantum code base)? >> so how exactly the rpm for this would look like? deploy it to >> /xxx/qunatum and have it add a symbolic link to it from vdsm paths? > In my opinion this should be part of VDSM. It would be ideal if each > plugin can bind load a driver - in Nova each driver is part of the nova > code. If the API is well defined then all vendors can provide their > drivers. This is open for discussion and we should try and understand > what the best way of doing this is. I like the NOVA model. doesn't this mean we need to recode each driver for vdsm? I thought it was part of making quantum a separate entity that it provides drivers as well (especially if the api for drivers is well defined)? >> >> 5.7 "When a communication channel is established between VDSM and the >> oVirt engine. The VDSM host should notify the oVirt Engine of the >> Quantum fabric that is supported." >> how does vdsm goes about detecting an agent is installed exactly? > The user needs to install a package for the agent - this creates the > relevant configuartion files. These files can be used to detect the > running agent or via "ps" 1. I assume per the discussion in the deployment section that all relevant code is always deployed. 2. vdsm needs to report what is installed 3. vdsm needs to get the chosen technology at host level fabric interface definition to configure it to up state. 4. or, as part of engine "init_vds_on_up" flow, engine needs to pass to vdsm quantum relevant configuration if defined at cluster level and not relevant to interface level maybe) >> (especially since deployment wise, most likely is all agents would be >> deployed via rpm requirements?) >> is any agent a service at host level rather than code only? >> is there a scenario where a vdsm level plugin isn't required? >> >> 6. open issues >> 6.1 worth mentioning if any are in the works > No shortage :). But we have a good start. There are some blueprints in > the works which solve a large amount of problems I'd add links to those that exists. >> 6.2 specifying the vlan from ovirt engine is not a gap? > Yes it is. This is currently being addressed. This is not a reason to > stop us moving ahead. >> 6.3 ok, so this is the first time "no multiple plugins" is mentioned >> ("Non-uniform technology"). but it sounds like the approach in the >> wiki assume it is/will be possible to have multiple technologies >> (agents/plugins) going forward? > My take is that this can be hidden by oVirt engine. It is just an > implementation detail - this should not affect the user experience - > which at the end of the day is what counts this is kind of a crucial part of the assumptions/modeling part for the engine. >> 6.4 need to discuss which of the open issues should block going >> forward with merging of code, and expected timeframe for resolution of >> some of them > Correct. In my opinion there are no major blocking issues at the moment. again, apart of code level issues, we need to clear the modeling so code review can be done compared to some understanding of the plan. in my view, clarifying these is blocking understanding the feature: - defining the assumptions (even if some are not supported yet) - modeling per the assumptions - UI mockups per the modeling (since they make things visible) - API modeling, since it is a pain on any one integrating with it when it changes - db scheme changes I agree solving these isn't blocking merging code: - communication channels between quantum components - deployment implications/flow I do think these would block further consumption, so they should be covered/understood as to what the gaps are. for communication part, i think the approach you suggested should be fine (assuming it will merge with the same brokering technology used by engine/vdsm) but for deployment part, "how this will look like" should be cleared up in a bit more detail to have the gap list (on both engine and vdsm) >> >> 7. other questions/items (some mentioned above as well) >> 7.1 please add ui mockups, db scheme changes and REST api changes > OK >> 7.2 i'm missing the deployment flow: > OK >> - user install engine. is quantum a separate install or bundled going >> forward? >> - any configuration items by user at this point? what are they? >> - what rpms are deployed at host level? what configuration do they need >> - communication channels and their security are a must to understand >> 7.3 upgrade path / compatibility levels this is relevant to? >> 7.4 monitoring flow - how is monitoring/state of a host is affected by >> quantum service being down, communication problem from host to (where >> actually?) From juan.hernandez at redhat.com Fri May 18 12:54:10 2012 From: juan.hernandez at redhat.com (Juan Hernandez) Date: Fri, 18 May 2012 14:54:10 +0200 Subject: [Engine-devel] Where is the git workspace of "engine-iso-uploader"? In-Reply-To: <4FB61092.5040903@linux.vnet.ibm.com> References: <4FB61092.5040903@linux.vnet.ibm.com> Message-ID: <4FB64672.1000200@redhat.com> On 05/18/2012 11:04 AM, Shu Ming wrote: > From this page, I am told that it should be in the same workspace as > ovirt-engine. > http://www.ovirt.org/project/subprojects/ > > However, I can not find it in ovirt-engine workspace. Where does it go? Try this: git clone git://gerrit.ovirt.org/ovirt-iso-uploader From kroberts at redhat.com Fri May 18 13:58:18 2012 From: kroberts at redhat.com (Keith Robertson) Date: Fri, 18 May 2012 09:58:18 -0400 Subject: [Engine-devel] Java 7: Fix namespaces use in OVF writer In-Reply-To: <4FB627CF.8050805@redhat.com> References: <4FB627CF.8050805@redhat.com> Message-ID: <4FB6557A.1070203@redhat.com> Juan, I wouldn't consider it an exhaustive test by any means, but I have a simple .ovf file in the Image Uploader GIT repo that I do unit testing with. You can review the OVF XML file therein if you like. FWIW, I would recommend you simply export an image from an "unpatched" oVirt engine and just compare the resulting XML to a patched version. 1: git clone gerrit.ovirt.org:ovirt-image-uploader 2: cd ovirt-image-uploader/src 3: tar -xvf sample.ovf <- This is a portable/exported "image" - Note: For some reason there seems to be a consensus to append/apply the .ovf extension to .tgz file image files. It is somewhat confusing, IMHO. 4: Look at master/vms/5272b689-cd9f-4532-9b5d-2413eb7b9402/5272b689-cd9f-4532-9b5d-2413eb7b9402.ovf for an OVF XML file. Cheers, Keith On 05/18/2012 06:43 AM, Juan Hernandez wrote: > Hello, > > I recently submitted a change to fix the way we manage namespaces in > the OVF writer: > > http://gerrit.ovirt.org/4540 > > The problem is that it doesn't work with the StAX reference > implementation included with Java 7. > > With the patched OVF writer I generated the attached OVF file. I would > appreciate if someone can take a quick look at it and tell me if it is > correct. I would also appreciate if you can send me known good OVF > files generated by the engine, to compare them with the ones produced > with the patched OVF writer. > > Thanks in advance, > Juan Hernandez > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From shuming at linux.vnet.ibm.com Fri May 18 15:19:06 2012 From: shuming at linux.vnet.ibm.com (Shu Ming) Date: Fri, 18 May 2012 23:19:06 +0800 Subject: [Engine-devel] Where is the git workspace of "engine-iso-uploader"? In-Reply-To: <4FB64672.1000200@redhat.com> References: <4FB61092.5040903@linux.vnet.ibm.com> <4FB64672.1000200@redhat.com> Message-ID: <4FB6686A.7030705@linux.vnet.ibm.com> On 2012-5-18 20:54, Juan Hernandez wrote: > On 05/18/2012 11:04 AM, Shu Ming wrote: >> From this page, I am told that it should be in the same workspace as >> ovirt-engine. >> http://www.ovirt.org/project/subprojects/ >> >> However, I can not find it in ovirt-engine workspace. Where does it >> go? > > Try this: > > git clone git://gerrit.ovirt.org/ovirt-iso-uploader > I tried git clone git://gerrit.ovirt.org/engine-iso-uploader, no luck to success. I think ovirt-iso-uploader and enginer-iso-uploader are misused in some time. -- Shu Ming IBM China Systems and Technology Laboratory From juan.hernandez at redhat.com Fri May 18 15:26:26 2012 From: juan.hernandez at redhat.com (Juan Hernandez) Date: Fri, 18 May 2012 17:26:26 +0200 Subject: [Engine-devel] Where is the git workspace of "engine-iso-uploader"? In-Reply-To: <4FB6686A.7030705@linux.vnet.ibm.com> References: <4FB61092.5040903@linux.vnet.ibm.com> <4FB64672.1000200@redhat.com> <4FB6686A.7030705@linux.vnet.ibm.com> Message-ID: <4FB66A22.3070205@redhat.com> On 05/18/2012 05:19 PM, Shu Ming wrote: > On 2012-5-18 20:54, Juan Hernandez wrote: >> On 05/18/2012 11:04 AM, Shu Ming wrote: >>> From this page, I am told that it should be in the same workspace as >>> ovirt-engine. >>> http://www.ovirt.org/project/subprojects/ >>> >>> However, I can not find it in ovirt-engine workspace. Where does it >>> go? >> >> Try this: >> >> git clone git://gerrit.ovirt.org/ovirt-iso-uploader >> > I tried git clone git://gerrit.ovirt.org/engine-iso-uploader, no luck to > success. I think ovirt-iso-uploader and enginer-iso-uploader are misused > in some time. I just did it again and it works correctly for me: $ git clone git://gerrit.ovirt.org/ovirt-iso-uploader Cloning into 'ovirt-iso-uploader'... remote: Counting objects: 37, done. remote: Compressing objects: 100% (20/20), done. remote: Total 37 (delta 10), reused 37 (delta 10) Receiving objects: 100% (37/37), 23.70 KiB, done. Resolving deltas: 100% (10/10), done. Network or DNS problems? From shuming at linux.vnet.ibm.com Fri May 18 15:39:02 2012 From: shuming at linux.vnet.ibm.com (Shu Ming) Date: Fri, 18 May 2012 23:39:02 +0800 Subject: [Engine-devel] Where is the git workspace of "engine-iso-uploader"? In-Reply-To: <4FB66A22.3070205@redhat.com> References: <4FB61092.5040903@linux.vnet.ibm.com> <4FB64672.1000200@redhat.com> <4FB6686A.7030705@linux.vnet.ibm.com> <4FB66A22.3070205@redhat.com> Message-ID: <4FB66D16.6090206@linux.vnet.ibm.com> On 2012-5-18 23:26, Juan Hernandez wrote: > On 05/18/2012 05:19 PM, Shu Ming wrote: >> On 2012-5-18 20:54, Juan Hernandez wrote: >>> On 05/18/2012 11:04 AM, Shu Ming wrote: >>>> From this page, I am told that it should be in the same >>>> workspace as >>>> ovirt-engine. >>>> http://www.ovirt.org/project/subprojects/ >>>> >>>> However, I can not find it in ovirt-engine workspace. Where does it >>>> go? >>> >>> Try this: >>> >>> git clone git://gerrit.ovirt.org/ovirt-iso-uploader >>> >> I tried git clone git://gerrit.ovirt.org/engine-iso-uploader, no luck to >> success. I think ovirt-iso-uploader and enginer-iso-uploader are misused >> in some time. > > I just did it again and it works correctly for me: Sorry for confusing. I cloned ovirt-iso-uploader workspace sucessfully. I thought the workspace name was engine-iso-uploader before. > > $ git clone git://gerrit.ovirt.org/ovirt-iso-uploader > Cloning into 'ovirt-iso-uploader'... > remote: Counting objects: 37, done. > remote: Compressing objects: 100% (20/20), done. > remote: Total 37 (delta 10), reused 37 (delta 10) > Receiving objects: 100% (37/37), 23.70 KiB, done. > Resolving deltas: 100% (10/10), done. > > Network or DNS problems? > > -- Shu Ming IBM China Systems and Technology Laboratory From jhernand at redhat.com Fri May 18 17:20:58 2012 From: jhernand at redhat.com (Juan Hernandez) Date: Fri, 18 May 2012 19:20:58 +0200 Subject: [Engine-devel] Java 7: Fix namespaces use in OVF writer In-Reply-To: <4FB6557A.1070203@redhat.com> References: <4FB627CF.8050805@redhat.com> <4FB6557A.1070203@redhat.com> Message-ID: <4FB684FA.5020502@redhat.com> On 05/18/2012 03:58 PM, Keith Robertson wrote: > Juan, > > I wouldn't consider it an exhaustive test by any means, but I have a > simple .ovf file in the Image Uploader GIT repo that I do unit testing > with. You can review the OVF XML file therein if you like. > > FWIW, I would recommend you simply export an image from an "unpatched" > oVirt engine and just compare the resulting XML to a patched version. > > 1: git clone gerrit.ovirt.org:ovirt-image-uploader > 2: cd ovirt-image-uploader/src > 3: tar -xvf sample.ovf<- This is a portable/exported "image" > - Note: For some reason there seems to be a consensus to append/apply > the .ovf extension to .tgz file image files. It is somewhat confusing, > IMHO. > 4: Look at > master/vms/5272b689-cd9f-4532-9b5d-2413eb7b9402/5272b689-cd9f-4532-9b5d-2413eb7b9402.ovf > for an OVF XML file. Keith, that helped a lot, thanks! After comparing with your example I updated the patch and now the result almost identical to the example. The resulting XML that I get now is attached. I appreciate if someone can take a look. > On 05/18/2012 06:43 AM, Juan Hernandez wrote: >> Hello, >> >> I recently submitted a change to fix the way we manage namespaces in >> the OVF writer: >> >> http://gerrit.ovirt.org/4540 >> >> The problem is that it doesn't work with the StAX reference >> implementation included with Java 7. >> >> With the patched OVF writer I generated the attached OVF file. I would >> appreciate if someone can take a quick look at it and tell me if it is >> correct. I would also appreciate if you can send me known good OVF >> files generated by the engine, to compare them with the ones produced >> with the patched OVF writer. >> >> Thanks in advance, >> Juan Hernandez -- Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3?D, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat S.L. -------------- next part -------------- A non-text attachment was scrubbed... Name: mydesktop.xml Type: text/xml Size: 4768 bytes Desc: not available URL: From gkotton at redhat.com Sat May 19 06:59:34 2012 From: gkotton at redhat.com (Gary Kotton) Date: Sat, 19 May 2012 09:59:34 +0300 Subject: [Engine-devel] [Users] oVirt and Quantum In-Reply-To: <4FB61F76.5000205@redhat.com> References: <4F9D1AD4.8070503@redhat.com> <4FB23232.7090008@redhat.com> <4FB2697B.4000406@redhat.com> <4FB61F76.5000205@redhat.com> Message-ID: <4FB744D6.5090608@redhat.com> On 05/18/2012 01:07 PM, Itamar Heim wrote: > On 05/15/2012 05:34 PM, Gary Kotton wrote: > ... > >>> 2. host management --> interface >>> 2.1 you are suggesting to remove the vlan field with a fabric field? >>> are we sure this is something which shouldn't be presented in the main >>> view and only via extended properties? > > > Yes, this is what I am suggesting. VLAN tagging is one method of > network > > isolation. There are more, for example GRE tunneling. > > that doesn't mean this is not an important enough piece of information > to have in the subtab, rather than in an additional dialog (the fabric > type could be represented in an icon for example) > miki/andrew/einav - thoughts on the UI aspect of this? This is a very important piece of information. The network specific are very important. I think that they can be displayed on a different screen and do not need to clutter this specific view. Please not that currently Quantum does not return the network specifics, for example the VLAN tag. This is something that is being addressed by a blueprint for connecting to existing networks. > >>> >>> 2.2 is the fabric really a host interface level property, or a cluster >>> wide property (would same logical network be implemented on different >>> hosts in the cluster via both vdsm and quantum)? >>> would live migration work in same cluster if one host has qunatum >>> fabric and another vdsm fabric for same logical network? >> These are all up for discussion. I just wanted to provide something that >> we can start to work with. It would be nice if there was some input from >> product management on this issue (not exactly sure how this works in an >> open source community :)) > > This goes to assumptions on qunatum integration and capabilities. > I'm missing this part in the beginning of the feature page. I can add a link to the Quantum wiki or documentation. I am not sure that this will address this issue. Quantum is evolving. It started with simple layer 2 connectivity. Now layer 3 address management is being added. Next stop will be security policies and quality of service. > if quantum can support multiple types, and live migration between, > then it can a host level config. > if live migration wouldn't work, it would have to be a cluster level > config. > if it is limited to a single technology, it is kind of a system level > config. > > (and actually, after reading your reply to 3.7.1, i understand the > plugin is an interface level config, since you can have more than a > single one on the same host). > Quantum is a network service. It can work in all of the above scenarios - for example, it works in OpenStack which supports the above. It is just a matter of configuring it correctly. > same goes to implications to the logical network entity (see my > comment in 2.4 below). > > I'd also like to understand in that regard how do we match up host > reporting it can support (i.e., installed and configured) to a > specific technology. > i.e., there needs to be some correlation between which logical > networks can be deployed on which plugin. > so also need to understand how this correlation is done automatically > between logical network, to which fabric/interface it belongs to. This is a gap in Quantum at the moment, that is, Quantum does not return logical network statistics. (https://blueprints.launchpad.net/quantum/+spec/network-statistics) > > (I admit your reply to 3.7.1 confused me as to how quantum will decide > on which plugin to create a specific attachment)? > > >>> >>> 2.3 you are describing the subtab of an interface, and mention a >>> qunatum pull down menu. is this in the subtab? in a dialog? >>> UI mockups are needed here. >> I think that prior to getting mockups, we should ensure that we have the >> idea crystallized. > > I can live with that, goes back to what i wrote in 2.2. > >>> >>> 2.4 also, is this pulldown correct at host level or cluster level >>> (would live migration work between hosts implementing different >>> plugins for same logical network in same cluster?) > > as i stated above - this has to be clarified in assumptions. > doesn't have to be the current state, rather a clear understanding > where it is going to, or as to what makes sense. > (I am not sure requiring live migration between multiple technologies > makes sense, since implementation of the logical network could be > based on different concepts (vlan vs. gre). > however, this means we need to define if the logical network (which is > not limited to a cluster) should be limited to clusters supporting > these technologies. > i.e., a vlan based logical network can cross (in different clusters) > UCS, openvswitch and bridges. but a gre based logical network cannot > cross all of them, etc. For a start we can limit live migration only for homogeneous hosts, that is the same Quantum agent. If the VM has characteristics that are supported by more than one plugin then I do not see any reason why this should be limited. For example, every plugin supports VLAN tagging. If a VM runs on a tagged network then there is no reason why the VM cannot be moved from a host running OVS to a Host that has UCS > >>> >>> on to backend: >>> 3.1 "The Quantum Service is a process that runs the Quantum API web >>> server (port 9696)" >>> >>> how is authentication between engine and quantum service is done (we >>> have a client certificate for engine which qunatum can verify i guess) >> In my opinion this should be running locally on the same host as the >> engine. > > even on same server, we have authentication between components running > in different processes. Can you please point me to an example so that I can understand in more detail. The interface with the Quantum server is via REST API. If necesasry this can be done over SSL. > on top of that, one of our main goals is to allow multiple engines > running side by side for scale. maybe quantum will have to be in > active/passive mode for a while, but multiple nodes should be able to > access it. Do the engines have a common database or does each engine have their own database? If the service si the problem then a load balancer can be used to select the "best" server. The issue is the information stored in the database. > > there is no need for fancy authentication/authorization. simply > trusting ovirt engine CA certificate and validating engine client > certificate should suffice (and i assume can be done via config in the > http layer of quantum). > > also, this can be a phase 2, but let's have a list of what is a must > for merging the code (this isn't), to deployment (phase 2), to more > than that (phase 3). > under deployment i'd expect not requiring a different db technology, > integrating with installer, an upgrade path, cleaner and secure > communication channels, etc. Some Quantum plugins have a database, others do not. The open source plugins are implemented in python whcih uses the SQL Alchemy database interface. The user can select the database type. I have current used this with the default mysql. If we use the postgres database and it is on the same database with the same authentication as the oVirt engine does this cover the authentication issues? > >>> >>> 3.2 is there a config of the quantum service uri? should it be a >>> single instance or a per DC property? >>> (it sounds like a per DC property, can be a future thing) >> I am sorry but I do not understand the question. > > even if quantum is running on same host, you will have a configuration > item of the URI to the service, and will configure this as part of > installation flow. > if this is not configured, I'd expect engine/ui to not show quantum > options. > is this a single uri or a DC instance level property goes to > modeling/assumptions part. can we live with a single quantum service > for multiple technologies, or will need different quantum for > different technologies. > this can also be a later phase, starting with a limitation of a > single, system-wide quantum. The way that I see this is that the user should know of the existance of a Quantum server. They just know that Quantum implemnts the networking. It would be ideal if the oVirt engine hides all of the interfaces with the server. This is just an implementation detail. > >>> >>> 3.3 network creation >>> >>> semantics: we create a network at DC level. we attach it at cluster >>> level. the UI allows you to "create at DC and attach to cluster" at >>> cluster level. >>> >>> 3.3.1 what if i create a network with same VLAN in two DC's? what if >>> we attach same logical network to multiple clusters - each will create >>> the logical network in qunatum again? >> If I understand you correctly then I think that one Quantum network can >> be created. This should work. In my opinion this should be managed by >> the oVirt engine so the actual creation is not an issue. Ensuring that >> each cluster has the correct network management configurations is what >> is important. >>> 3.3.2 what if the qunatum service is down when engine performs this >>> action or quantum returns an error? >> The engine should be able to deal with this - similar to the way in >> which it deals with a network creation when VDSM is down. > > network creation is not affected when VDSM is down, as the admin > configures it on the hosts after it is created (via the UI). > in quantum case, there is no admin step. > so need to solve engine monitoring quantum for list of networks > relevant to a cluster are defined to mark non defined networks as > non-operational, and have timer based or manual retry mechanism. I personally think that the issue of "non operational" status has to be addressed. In my opinion the goal is to have VM's up. I'll give you an example. Say we have VM1, VM2 and VM3 running on one host. VM1 and VM2 communicate on an internal network. VM3 is connectd to the internal network and to the outside work. If there is a problem with the networking then the user is unable to do anything with VM1 and VM2 due to the fact that thir host is non operational... How does one monitor the state of a network? At the moment VDSM just sends a periodic interface update to the engine. The engine has a logic that defines if the host is up or down according to this. I think that it should suffice to the user to know that the network link is up or down. VMware does not have such a strict and limiting system. If a user takes a hardware device and connects it to the wrong switch port they are still able to work on the device. Why should this be different for a virtual machine? > > I don't think this is a merge blocker to code, but it should be part > of the phase 1 of this feature. I am not sure that I am in sync with the phases. It would be great maybe if we could describe the scope of the various phases. This will help address the issues for each phase. > >>> 3.3.3 each creation of a DC creates a rhevm network - I assume these >>> are not created, since "no host in a cluster in the DC yet"? >> This functionally can remain the same. > > ok, goes to assumptions part. > "quantum integration will be done only for vm networks" > >>> 3.3.4 what happens on moving of a host to another cluster, or moving >>> of a cluster to another DC (possible if it's DC was removed iirc). >> The Quantum agents take care of this. On each host there will be a >> Quantum agent that treats the network management. > > I meant in the aspect of provisioning needed configuration to the host > (doing it when a host tries to go to up status is fine, but need to > remember this use case when desiging, since it means this isn't a > bootstrap aspect) > also, please document this so flow so someone trying to test the > integration covers it. OK. > >>> 3.3.5 shouldn't this be limited to vm networks, or all networks are >>> relevant? >> I think all Quantum networks are relevant > > I understood in 3.3.3 that quantum networks are only relevant to vm > networks (networks that can run virtual machines, rather than the > management, live migration or storage networks)? > > (I'd suggest keeping it simple and limited to vm networks for first > phase) I agree > > important part here is code should not try to create this network via > quantum i guess. This is why the user should still be able to still have an option of the using the "VDSM style" networking. > >>> 3.3.6 what if the host with the qunatum fabric is in maint mode? >> I do not understand. When a host is in maintenace mode do VM's receive >> traffic? The Quantum port for the VM's can be set as DOWN > > I'm offline - we'll need to re-read the wiki to reply. > >>> 3.3.7 could a host with qunatum fabric have a VDSM fabric on another >>> interface (for vm neworks? for non-vm networks)? >> Yes. This is something that I would like. I also would like the Quantum > > then this should go to assumptions part. > >> API to be updated so that we can indicate the phycal network interface >> that the Quantum network will be running on. > > i don't think this is needed. > when admin configures the interface or bond on the host to be 'fabric' > or 'quantum' it calls vdsm to perform the network configuration > change. this will flag the relevant interface in the host as > fabric/quantum (either via config, or alias, etc.) At the moment Quantum has one network interface for all of the networks. We would like Quantum to be extended so that it can indicate which network is run on which physical interface. For example if NIC 1 (eth0) is on a DMZ and NIC 2 (eth2) is on a provate network, we want the Quantum DMZ network to only be connected to NIC1. > > but for modeling sake, can you please explain how this is supposed to > look for a UCS host? > >>> >>> 3.5 network deletion (detach network from a cluster) >>> 3.5.1 what happens if qunatum is down or returned an error? >> The engine should be able to deal with this - similarly to what it does >> today > > see my reply on 3.3.2. this is managed by the admin today. > so this is coding to be done that should be documented (it is not a > merge blocker in my view, but it is part of phase 1. > >>> >>> 3.6 vm creation >>> 3.6.1 what about moving a VM from/to a cluster with a quantum fabric? >> I do not see a problem here. The agenets running on VDSM will detect and >> treat accordingly. > > i meant in the aspect of the need to create the port for them in quantum? I think that we need to discuss the port creation. Quantum enable the user to create a network a port on the network and the ability to attach an interface to the port. I thin that the port creation is something that should be hidden from the oVirt engine user. They just nee to know about networks and that a VM has been connected to the network. > >>> 3.6.2 what about import of a VM into a cluster with a qunatum fabric? >> Same as above > > indeed - need to handle port creations? > >>> 3.6.3 you have vm creation/removal - missing vnic addition/removal > > please document this operation so someone testing this will have full > picture. :) OK - seems like I have quite a lot of documentation to do. The same test cases should be used as those with the existing VDSM implemntation. Our first goal is to have network parity. Once we have this we can expand the scope. > >>> 3.6.4 worth mentioning qunatum doesn't care about the vnic model? >>> about the mac address? >> The Quantum driver on VDSM does take into account the MAC address. This >> is used in some plugins - for example the openvswicth plugin. > > ok, can you please explain the flow of data of how it gets it (simply > vdsm needs to pass it to the driver?) In the POC implementation that I did the Quantum treatment in VDSM received the following information:- - mac address of the interface - VM UUID - Quantum ID's > >>> >>> 3.7 vm start >>> 3.7.1 why is the plugin parameter required at vm start? >> This is to indicate to VDSM the operations to take place - for example >> updating the openvswitch integration bridge > > i thought the integration bridge is pre-configured at host level? > i thought the host already knows which interface is used for quantum, > and for sure, which plugin is supposed to be used for that interface. > so why is this a vm start parameter? When I spoke with the guys from VDSM they did not want me to change the VDSM configuration files. The idea was to deal with each plugin type at run time. This is logical and leaves changes on the VDSM side to a minimal. Less chance for configuration problems. > >>> can multiple plugins be supported in parallel at vdsm/host level or by >>> the quantum service? >> Yes/ Multiple agents can run on VDSM. In the engine a little work is > > ok, please document this in the assumptions part. > i assume multiple agents, but still only one per fabric interface? Correct. > also, if plugins are services, I want to understand when vdsm needs to > start them (I assume when admin configures an interface of type fabric > for a specific plugin type). The agent will be running on VDSM. This service is started when the VDSM host boots. The installation of the agent shoud ensure this. > >> required to run multiple plugins. > > in the engine or in quantum? The plugin runs on the engine. The agent runs on the host. > > I updated my reply on assumptions above based on this info as > something that needs clearing up. > >>> 3.7.2 aren't network_uuid and port uuid redundant to attachment uuid >>> (I assume qunatum service knows from attachment the port and network) >>> - i have no objection to passing them to vdsm, just trying to >>> understand reasoning for this. >>> I am missing what happens at vdsm level in this point (even after >>> reading the matching vdsm part) >> The network ID and the port ID are returned by the Quantum service. The >> attachment ID is passed to the Quantum server. If this is unique then it >> can be a key to the above (I am currently working on the scale issue >> with Quantum and there are 2 options, the first is that it is unique, >> the second is that all three are passed to the agent). It is a few extra >> bytes passed. I think that it is better to be safe and have all of the >> information on VDSM for future use. >>> >>> 3.8 vm suspend/resume (it's fine to say it behaves like X, but still >>> need to be covered to not cause bugs/regressions) >> The Quantum port status can be updated. > > please document this operation so someone testing this will have full > picture. > OK >>> >>> 3.9 vm stop >> Same as above > > please document this operation so someone testing this will have full > picture. OK > >>> 3.9.1 need to make sure vm stop when engine is down is handled >>> correctly. > > this requires adhering to. again, not a merge blocker to code. but in > my view part of phase 1 (my view of phase 1 is deployment is still > manual, but flows are handled correctly and do not leave leftovers > around) > please document this operation so someone testing this will have full > picture. > >>> 3.9.2 what happens if qunatum service is down? unlike start vm or >>> network creation the operation in this case cannot be >>> stopped/rolledback, only rolled forward. >> We have to ensure that it is up. > > we have several use cases requiring to be able to start virtual > machines even when engine is down (regardless of HA aspects for the > engine). > this means admin wants to go to a host, and start the VM from command > line. > the VM definition is recovered from the OVF for such a manual > emergency procedure. > sanlock is supposed to protect against vm corruption in this case. > but the VMs will need networking to be useful. > so what's the emergency flow to starting a VM? If the user is usingt he VDSM command line for VM creation then the same support should be offered for Quantum. The underlying assumption here is that the VM is using a network that exists. If this is the case then we should be OK here. > >>> >>> 3.10 hot plug nic? >> Each new NIC has an attachment ID - the agent know that a new NIC is >> added and treats accordingly. > > true, but i assume you would need to change the api here to get the > quantum details like the attachemnt_id (and the rest). > also, all affected use cases should be documented for someone testing > this to have full picture of scope. The oVirt engine for allocating the attachment ID. The fact that the engine does the hot nic assignment ensure that it will also assigned the attachment. I have yet to understand the hot vnic flow - the code that I was working on did not have this support. I should also test this with Quantum. > >>> >>> 3.11 vm migration >>> 3.11.1 ok, so this is the first time i understand hosts can be mixed >>> in same cluster. worth specifying this in the beginning (still not >>> clear if mixed plugins can exist) >> If the networks are configured with the same characteristics then this >> should be OK. As mentioned above we are working on a blueprint to deal >> with connecting to existing networks - i.e. enable the user/admin to >> configure the VLAN tags > > please define under assumptions part what are the network > characteristics, how they are mapped to which plugins support which > characteristics to be relevant. > also, monitoring wise, you are implying each host must be able to > accommodate all types of characteristics in the networks in the cluster. Monitoring whould be discussed. Statistics are currently not reported. > >>> 3.11.2 afair, we don't deal with engine talking to both hosts during >>> live migration. only to host A, who is then communicating with host B. >>> so why not always have the VM configuration at vm start (and hot plug >>> nic) have the quantum details so live migration can occur at will >>> without additional information? >> I do not understand can you please explain. VDSM creates the tap device >> and builds the libvirt files. The agents detect the tap device and >> attach to the network. I do not understand why it is a problem for the >> live migration. This is also driven by the libvirt XML's being created. >> Is this correct? > > that is fine. iirc, the wiki states engine needs to pass information > to target host. we don't have such a flow in live migration (which is > complex enough). > live migration should be based on the information already available to > vdsm in source host. > I don't know if quantum cares about the attachement/port residing on > more than one host (the target host has to set them up before > migration starts, and source host removes them only after migration > ends). > i hope we are both understanding this the same way. > > in any case, need to remember to test failure of live migration in its > various steps cleans up any quantum related changes. > >>> 3.11.3 "In order to implement the above a REST client needs to be >>> implemented in the oVirt engine. " >>> did not understand this statement - please elaborate. >> All interface with the Quantum server is done via REST. In order for >> oVirt to be able to communicate, it will need to send REST messages to >> the server and be able to parse the replies - this is what I meant by >> the REST client. >>> >>> 4. host management >>> 4.1 deployment >>> we do not deploy packages from engine to hosts, we can install them >>> from a repo configured to the host. but this is done today only as >>> part of initial bootstrap/installation of host. >>> also, it is not relevant for ovirt node which is 'firmware' like. >>> any reason to not require the 'plugin installation packages' at vdsm >>> rpm level for plugins we think are good enough to use (until then, >>> responsibility to deploy them is of admin) >>> >> Correct. I agree with you. > > ok, so on ovirt-node all quantum agents will be pre-installed. > if a quantum agent is changed to work correctly with ovirt/vdsm, why > not simply always require at rpm level to deploy it on the host? > then a regular host and ovirt-node are the same. > still need to define how vdsm reports which agents are supported by it > (which is different than those which are installed, say for UCS?), > which is different from those that are actively running since they are > configured). I was thinking that when VDSM dos the "handshake" with the engine that this information would be transferred. > > >>> (what are plugin level packages at host level - aren't these the >>> agents?) >> Each plugin has the relevant packages that should be installed. >>> >>> 4.2 plugin configuration >>> per DC? per cluster? per host? per plugin? please provide more details >>> here on configuration details expected and flow of when they are >>> configured and when they are expected to change? >> I think that plugin per cluster is a good start. This could limit live >> migration problems. > > I agree... > question is this part of phases, or part of assumptions (end goal) > modeling should be aligned with end goal (i am not suggesting it can > do in steps, just that end goal should be understood so it doesn't > interrupt it. especially for the API part which requires to keep > backward compatibility as much as possible). > >>> I think this will merit a per 'ovirt supported' qunatum plugin to see >>> it works in a way we can use. >>> >>> 4.3 connectivity >>> again, this requires more details. if needed per plugin. >>> what is expected? how authentication/encryption happens? what iptables >>> rules need to change in engine/host if at all, etc. >>> I'm fine with this being 'direct access to db from hosts' for POC >>> level of patches, but not for something we actually merge/provide >>> support for later. >> I am currently working on a blueprint to ensure better scaling of >> quantum agents. This will be done by making use of the nova RPC library. >> This supports Qpid, rabbit mq, kombu etc. These have an option of being >> secure. Please clarify if this suffices? > > having all work on same channel will solve most problems. > still need to map those that require data not in quantum for some > reason to try and pass to qunatum the needed data as customer > parameters rather than add a channel to engine if possible/makes sense. > > do all of these require a broker to be deployed? > I assume all support certificate based authentication. > > it should be the same one we'll pick for engine-vdsm (I heard fans of > zeromq as well), but this doesn't have to be phase 1, or we might be > lucky and agree on one already supported :) > >>> >>> 5. VDSM > ... > >>> >>> 5.2 "The agent package can and may be received from the oVirt Engine >>> or can be downloaded via RPM's" >>> see 4.1 above - we don't deploy rpm's/code on the fly today. >> When I was sitting with the guys from oVirt this is what I was told. I >> guess that I misunderstood. > > ok, I assume 4.1 resolves this and we simply deploy all those made to > work with ovirt as part of vdsm rpm requirements? I think that we need to discuss packaging - should the quantum agents be part of VDSM? I am not sure. > > (implies each one should have a sub rpm, not sure if that is the case > today) > >>> >>> 5.3 "in addition to the treatment below VDSM should also maintain a >>> health check to the Quantum agent" >>> what if the restart didn't help? how should ovirt treat the host wrt >>> networking? to running VMs? to ability to live migrate VMs from the >>> host if needed? >> If the agent is down then the oVirt engine should be notified to at >> least events for the user. > > ok. > I assume vdsm knows which agent to start and later monitor based on > the host level config by admin of the fabric interface (whether the > plugin type is cluster or interface level) This is related to the issue above. If the user runs the RPM for VDSM then she/he can run the agent RPM - this will register the agent. > >>> >>> 5.4 "Logical Network Management" >>> please see 3.11 above - we would want live migration to not require >>> additional information, so details should be available even if not >>> immediately acted upon. >>> >>> 5.5 "The tap device created uses an "ethernet" network device. This >>> means that the creation of the libvirt XML file is a bit different." >> Yes, that is correct >>> 5.5.1 does this impact stable device addresses somehow? >> Not that I am aware of >>> 5.5.2 how is live migration possible if the libvirt xml to a non >>> quantum host is different (or is this the binding part only)? >> If the libvirt is "pacthed" when the migration takes place then this >> should not be a problem. > > does libvirt support something like that? the live migration happens > directly between the two libvirt's. > libvirt created an abstraction layer to their networking model to > allow live migration between host where the physical layer is > different so the logical layer remains the same during live migration. > I just don't know it the 'ethernet' attribute you mentioned is in that > physical mapping layer (which would be fine), or in the logical one > (which won't live migrate). > please verify with a libvirt expert (dbp modeled that part iirc) Thanks, I'll speak with Dan > >>> >>> 5.6 I assume libvirtvm.py is part of vdsm. >>> is quantum.py part of quantum code base or vdsm codebase (it sounds >>> like it should be part of quantum code base)? >>> so how exactly the rpm for this would look like? deploy it to >>> /xxx/qunatum and have it add a symbolic link to it from vdsm paths? >> In my opinion this should be part of VDSM. It would be ideal if each >> plugin can bind load a driver - in Nova each driver is part of the nova >> code. If the API is well defined then all vendors can provide their >> drivers. This is open for discussion and we should try and understand >> what the best way of doing this is. I like the NOVA model. > > doesn't this mean we need to recode each driver for vdsm? > I thought it was part of making quantum a separate entity that it > provides drivers as well (especially if the api for drivers is well > defined)? OpenStack nova has Quantum drivers. It would be best if we could use the same interface. > >>> >>> 5.7 "When a communication channel is established between VDSM and the >>> oVirt engine. The VDSM host should notify the oVirt Engine of the >>> Quantum fabric that is supported." >>> how does vdsm goes about detecting an agent is installed exactly? >> The user needs to install a package for the agent - this creates the >> relevant configuartion files. These files can be used to detect the >> running agent or via "ps" > > 1. I assume per the discussion in the deployment section that all > relevant code is always deployed. > 2. vdsm needs to report what is installed > 3. vdsm needs to get the chosen technology at host level fabric > interface definition to configure it to up state. > 4. or, as part of engine "init_vds_on_up" flow, engine needs to pass > to vdsm quantum relevant configuration if defined at cluster level and > not relevant to interface level maybe) > >>> (especially since deployment wise, most likely is all agents would be >>> deployed via rpm requirements?) >>> is any agent a service at host level rather than code only? >>> is there a scenario where a vdsm level plugin isn't required? >>> >>> 6. open issues >>> 6.1 worth mentioning if any are in the works >> No shortage :). But we have a good start. There are some blueprints in >> the works which solve a large amount of problems > > I'd add links to those that exists. https://blueprints.launchpad.net/quantum/+spec/melange-integration https://blueprints.launchpad.net/quantum/+spec/authorization-support-for-quantum (may be relevant for authentication) https://blueprints.launchpad.net/quantum/+spec/provider-networks https://blueprints.launchpad.net/quantum/+spec/quantum-usage https://blueprints.launchpad.net/quantum/+spec/linuxbridge-portstats-support https://blueprints.launchpad.net/quantum/+spec/network-statistics https://blueprints.launchpad.net/quantum/+spec/scalable-agent-comms > >>> 6.2 specifying the vlan from ovirt engine is not a gap? >> Yes it is. This is currently being addressed. This is not a reason to >> stop us moving ahead. >>> 6.3 ok, so this is the first time "no multiple plugins" is mentioned >>> ("Non-uniform technology"). but it sounds like the approach in the >>> wiki assume it is/will be possible to have multiple technologies >>> (agents/plugins) going forward? >> My take is that this can be hidden by oVirt engine. It is just an >> implementation detail - this should not affect the user experience - >> which at the end of the day is what counts > > this is kind of a crucial part of the assumptions/modeling part for > the engine. > >>> 6.4 need to discuss which of the open issues should block going >>> forward with merging of code, and expected timeframe for resolution of >>> some of them >> Correct. In my opinion there are no major blocking issues at the moment. > > again, apart of code level issues, we need to clear the modeling so > code review can be done compared to some understanding of the plan. > > in my view, clarifying these is blocking understanding the feature: > - defining the assumptions (even if some are not supported yet) > - modeling per the assumptions > - UI mockups per the modeling (since they make things visible) > - API modeling, since it is a pain on any one integrating with it when > it changes > - db scheme changes Quantum is evolving and changing. We will have to be flexible... > > I agree solving these isn't blocking merging code: > - communication channels between quantum components > - deployment implications/flow > > I do think these would block further consumption, so they should be > covered/understood as to what the gaps are. > > for communication part, i think the approach you suggested should be > fine (assuming it will merge with the same brokering technology used > by engine/vdsm) > > but for deployment part, "how this will look like" should be cleared > up in a bit more detail to have the gap list (on both engine and vdsm) > >>> >>> 7. other questions/items (some mentioned above as well) >>> 7.1 please add ui mockups, db scheme changes and REST api changes >> OK >>> 7.2 i'm missing the deployment flow: >> OK >>> - user install engine. is quantum a separate install or bundled going >>> forward? >>> - any configuration items by user at this point? what are they? >>> - what rpms are deployed at host level? what configuration do they need >>> - communication channels and their security are a must to understand >>> 7.3 upgrade path / compatibility levels this is relevant to? >>> 7.4 monitoring flow - how is monitoring/state of a host is affected by >>> quantum service being down, communication problem from host to (where >>> actually?) From ovedo at redhat.com Sun May 20 08:49:21 2012 From: ovedo at redhat.com (Oved Ourfalli) Date: Sun, 20 May 2012 04:49:21 -0400 (EDT) Subject: [Engine-devel] IMPORTANT: Root web application moved In-Reply-To: <4FB55BFE.4080200@redhat.com> Message-ID: <603b3df9-3cf0-4e66-9f6a-7e8de94f8a23@zmail02.collab.prod.int.phx2.redhat.com> Hey, Is there a reason not to push the changes in standalone.xml (true-->false) as a patch? Thank you, Oved ----- Original Message ----- > From: "Juan Hernandez" > To: engine-devel at ovirt.org, shireesh at redhat.com > Sent: Thursday, May 17, 2012 11:13:50 PM > Subject: [Engine-devel] IMPORTANT: Root web application moved > > Hello, > > I have recently merged a change that moves the root web application > to > the .ear directory: > > http://gerrit.ovirt.org/3782 > > This change could break your environment if you apply the patch and > you > don't do a clean installation. You may find an error like this in > your > server log and the application can fail to deploy: > > JBAS014777: Services which failed to start: service > jboss.web.deployment.default-host./: > org.jboss.msc.service.StartException in service > jboss.web.deployment.default-host./: Failed to start service > > That means that you have more than one / application. Please make > sure > that you don't have the old ROOT.war in your deployment directory. > Just > remove it and the corresponding ROOT.war.dodeploy file. > > Also make sure that you don't have the following parameter in your > standalone.xml file: > > enable-welcome-root="true" > > Change the value to "false". > > None of this actions are needed if you are building new RPMs and > doing a > clean installation. > > If you still have problems starting the application server after > applying this change please let me know. > > Regards, > Juan Hernandez > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From gchaplik at redhat.com Sun May 20 12:50:15 2012 From: gchaplik at redhat.com (Gilad Chaplik) Date: Sun, 20 May 2012 08:50:15 -0400 (EDT) Subject: [Engine-devel] custom properties sheet feature page In-Reply-To: <9f1cb6e4-dfd4-49fc-bc64-0f6e14e7c432@zmail14.collab.prod.int.phx2.redhat.com> Message-ID: <046d8552-19d5-452a-ad86-f89f1890d2fe@zmail14.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Gilad Chaplik" > To: "Einav Cohen" > Cc: "David Ja?a" , "Eldan Hildesheim" , engine-devel at ovirt.org, "Eldan > Hildesheim" , "Simon Grinberg" > Sent: Friday, May 18, 2012 1:15:16 PM > Subject: Re: [Engine-devel] custom properties sheet feature page > > > ----- Original Message ----- > > From: "Einav Cohen" > > To: "Gilad Chaplik" > > Cc: "Eldan Hildesheim" , engine-devel at ovirt.org, > > "Simon Grinberg" , "Eldan > > Hildesheim" , "David Ja?a" > > Sent: Friday, May 18, 2012 1:02:03 PM > > Subject: Re: [Engine-devel] custom properties sheet feature page > > > > > ----- Original Message ----- > > > From: "Gilad Chaplik" > > > Sent: Friday, May 18, 2012 12:56:00 PM > > > > > > ----- Original Message ----- > > > > From: "David Ja?a" > > > > To: "Gilad Chaplik" > > > > Cc: "Einav Cohen" , engine-devel at ovirt.org, > > > > "Miki Kenneth" , "Andrew Cathrow" > > > > , "Simon Grinberg" , > > > > "Eldan Hildesheim" , "Eldan > > > > Hildesheim" > > > > Sent: Friday, May 18, 2012 12:51:43 PM > > > > Subject: Re: [Engine-devel] custom properties sheet feature > > > > page > > > > > > > > Gilad Chaplik p??e v P? 18. 05. 2012 v 05:44 -0400: > > > > > ----- Original Message ----- > > > > > > From: "Einav Cohen" > > > > > > To: "Gilad Chaplik" > > > > > > Cc: engine-devel at ovirt.org, "David Ja?a" > > > > > > , > > > > > > "Miki Kenneth" , "Andrew Cathrow" > > > > > > , "Simon Grinberg" > > > > > > , > > > > > > "Eldan Hildesheim" , "Eldan > > > > > > Hildesheim" > > > > > > Sent: Friday, May 18, 2012 12:35:34 PM > > > > > > Subject: Re: [Engine-devel] custom properties sheet feature > > > > > > page > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Gilad Chaplik" > > > > > > > Sent: Friday, May 18, 2012 12:25:45 PM > > > > > > > > > > > > > > inline > > > > > > > > > > > > > > Thanks, > > > > > > > Gilad. > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Einav Cohen" > > > > > > > > To: "David Ja?a" , "Miki Kenneth" > > > > > > > > , "Andrew Cathrow" > > > > > > > > , > > > > > > > > "Simon Grinberg" , "Eldan > > > > > > > > Hildesheim" > > > > > > > > , "Eldan Hildesheim" > > > > > > > > , "Gilad Chaplik" > > > > > > > > > > > > > > > > Cc: engine-devel at ovirt.org > > > > > > > > Sent: Friday, May 18, 2012 12:12:54 PM > > > > > > > > Subject: Re: [Engine-devel] custom properties sheet > > > > > > > > feature > > > > > > > > page > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > From: "David Ja?a" > > > > > > > > > Sent: Friday, May 18, 2012 11:33:44 AM > > > > > > > > > > > > > > > > > > Einav Cohen p??e v ?t 17. 05. 2012 v 10:14 -0400: > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > From: "David Ja?a" > > > > > > > > > > > Sent: Thursday, May 17, 2012 4:44:10 PM > > > > > > > > > > > > > > > > > > > > > > Einav Cohen p??e v ?t 17. 05. 2012 v 09:30 -0400: > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > From: "David Ja?a" > > > > > > > > > > > > > Sent: Thursday, May 17, 2012 3:40:19 PM > > > > > > > > > > > > > > > > > > > > > > > > > > Einav Cohen p??e v ?t 17. 05. 2012 v 08:10 > > > > > > > > > > > > > -0400: > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please review/comment on the Custom > > > > > > > > > > > > > > Properties > > > > > > > > > > > > > > Sheet > > > > > > > > > > > > > > feature > > > > > > > > > > > > > > page: > > > > > > > > > > > > > > http://www.ovirt.org/wiki/Features/CustomPropertiesSheet > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Just my $0.02: > > > > > > > > > > > > > > > > > > > > > > > > > > The table could have always empty row at the > > > > > > > > > > > > > bottom, > > > > > > > > > > > > > eliminating > > > > > > > > > > > > > one > > > > > > > > > > > > > or > > > > > > > > > > > > > all [+] buttons and saving user one needless > > > > > > > > > > > > > click: > > > > > > > > > > > > > > > > > > > > > > > > > > [ key1 |v] [ value ] [+] > > > > > > > > > > > > > [-] > > > > > > > > > > > > > [ key2 |v] [ value ] [+] > > > > > > > > > > > > > [-] > > > > > > > > > > > > > [ key3 |v] [ value ] > > > > > > > > > > > > > [-] > > > > > > > > > > > > > [ "please select a key..." |v] > > > > > > > > > > > > > > > > > > > > > > > > > > The [+] buttons at first and second rows > > > > > > > > > > > > > would > > > > > > > > > > > > > allow > > > > > > > > > > > > > user > > > > > > > > > > > > > to > > > > > > > > > > > > > insert a > > > > > > > > > > > > > row at specified location to make easy custom > > > > > > > > > > > > > sorting > > > > > > > > > > > > > of > > > > > > > > > > > > > the > > > > > > > > > > > > > properties > > > > > > > > > > > > > (not applicable if properties are > > > > > > > > > > > > > auto-sorted, > > > > > > > > > > > > > in > > > > > > > > > > > > > that > > > > > > > > > > > > > case, > > > > > > > > > > > > > all > > > > > > > > > > > > > [+] > > > > > > > > > > > > > buttons can be actually removed). > > > > > > > > > > > > > > > > > > > > > > > > Thanks for the input, David. This is an > > > > > > > > > > > > interesting > > > > > > > > > > > > idea. > > > > > > > > > > > > > > > > > > > > > > > > Indeed, when choosing a key in the last row, we > > > > > > > > > > > > can > > > > > > > > > > > > automatically > > > > > > > > > > > > add a new "please select a key..." row, which > > > > > > > > > > > > actually > > > > > > > > > > > > saves > > > > > > > > > > > > the > > > > > > > > > > > > user a button-click for adding a new row. > > > > > > > > > > > > > > > > > > > > > > > > On the other hand, from graphic-design point of > > > > > > > > > > > > view, > > > > > > > > > > > > it > > > > > > > > > > > > will > > > > > > > > > > > > look > > > > > > > > > > > > more consistent and "pretty" if: > > > > > > > > > > > > - The "please select a key..." row won't be > > > > > > > > > > > > displayed > > > > > > > > > > > > (unless, > > > > > > > > > > > > or > > > > > > > > > > > > course, the user explicitly chose to add > > > > > > > > > > > > another > > > > > > > > > > > > row) > > > > > > > > > > > > - All (full) rows will have both [+] and [-] > > > > > > > > > > > > buttons > > > > > > > > > > > > next > > > > > > > > > > > > to > > > > > > > > > > > > them > > > > > > > > > > > > > > > > > > I should have probably elaborated more on this. To > > > > > > > > > me, > > > > > > > > > UI > > > > > > > > > with > > > > > > > > > less > > > > > > > > > elements looks cleaner and prettier even when one of > > > > > > > > > them > > > > > > > > > stands > > > > > > > > > out. > > > > > > > > > There's also nothing wrong with standing out if the > > > > > > > > > element > > > > > > > > > has > > > > > > > > > "special" meaning (one add vs bunch of modify). > > > > > > > > > > > > > > > > > > Specifically, this looks cleaner to my eyes: > > > > > > > > > > > > > > > > > > [ key1 |v] [ value ] [-] > > > > > > > > > [ key2 |v] [ value ] [-] > > > > > > > > > [ key3 |v] [ value ] [-] > > > > > > > > > [ "Please select a key..." |v] > > > > > > > > > > > > > > > > > > than > > > > > > > > > > > > > > > > > > [ key1 |v] [ value ] [+] [-] > > > > > > > > > [ key2 |v] [ value ] [+] [-] > > > > > > > > > [ key3 |v] [ value ] [+] [-] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Note that in your suggestion above, you cannot insert a > > > > > > > > new > > > > > > > > key > > > > > > > > in > > > > > > > > between existing keys - only at the end; so > > > > > > > > although "cleaner", it has less functionality (depends > > > > > > > > also > > > > > > > > on > > > > > > > > the > > > > > > > > sorting, which is another issue; if there is > > > > > > > > auto-sorting, > > > > > > > > it > > > > > > > > doesn't matter). > > > > > > > > It is also a matter of taste, I guess, so no absolute > > > > > > > > right > > > > > > > > or > > > > > > > > wrong > > > > > > > > here IMO. > > > > > > > > [Others - you are welcome to comment as well] > > > > > > > > > > > > > > +1 > > > > > > > > > > > > > > another tiny comment: > > > > > > > can the empty line contain all the fields from initial > > > > > > > state > > > > > > > [["please select a key..."][field(empty)][+][-]] > > > > > > > instead of showing them only after selecting a key. > > > > > > > [["please select a key..."]] > > > > > > > > > > > > > > both of these scenarios are liable, > > > > > > > I can select a key, regret (change back to [please select > > > > > > > a > > > > > > > key]) > > > > > > > and > > > > > > > the field and buttons are still visible. > > > > > > > > > > > > > > so for the sake of complexity, I prefer to have only one. > > > > > > > > > > > > * Note that the field input control type (text-box, > > > > > > drop-down) > > > > > > depends on the key anyway (more accurately, on the > > > > > > validation > > > > > > regular expression of the key), so what are you going to > > > > > > show > > > > > > in > > > > > > case of "please select a key..."? > > > > > > > > > > empty text-box > > > > > > > > > > > > > > > > > * Need to make sure that validation fails in case field > > > > > > value > > > > > > is > > > > > > not > > > > > > empty and key is "please select a key...". > > > > > > > > > > > > > > I would prefer to just disable the value input field and do > > > > re-validation upon change of key (clear the value if it fails > > > > validation > > > > against a new key) or server-side when it is changed (clear the > > > > key-value pair altogether). > > > > > > +1 for disabling > > > -1 for clearing - it is not advised to clear a field if its fails > > > on > > > validation. Actually while implementing it, having a disabled field makes the user think why it's disabled, it is a bit confusing + less minimal :) I suggest to leave it as Einav's initial proposal. > > > > > > > > > > > David > > > > > > > > > > Due to both of these reasons, I prefer to not show an input > > > > > > control > > > > > > at all in this case. > > > > > > > > > > still, I don't see any difference, except adding > > > > > complexity/devel-time/bugs later on. > > > > > plus I think it's nicer. > > > > > > > > > > > > > > > > > * No problem of having a "+" button there; however, need to > > > > > > make > > > > > > sure > > > > > > that in case there is only one row in the sheet and it is > > > > > > with > > > > > > "please select a key...", the "-" button should be either > > > > > > hidden > > > > > > or > > > > > > disabled (or non-responsive), since we can't remove the > > > > > > last > > > > > > row. > > > > Don't forget to take this ^^^ also under consideration. > > silence means agreement :) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If the [+] button in my proposal is just greyed > > > > > > > > > > > out > > > > > > > > > > > instead > > > > > > > > > > > of > > > > > > > > > > > ommited, > > > > > > > > > > > it could satisfy both requirements. > > > > > > > > > > > > > > > > > > > > Almost; the "please select a key..." row is still > > > > > > > > > > always > > > > > > > > > > displayed; > > > > > > > > > > question is if we want to save a button-click (your > > > > > > > > > > suggestion) > > > > > > > > > > or > > > > > > > > > > to have a "cleaner" sheet (my suggestion). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > i.e., instead of your suggestion, which looks > > > > > > > > > > > > like > > > > > > > > > > > > this: > > > > > > > > > > > > > > > > > > > > > > > > [ key1 |v] [ value ] [+] > > > > > > > > > > > > [-] > > > > > > > > > > > > [ key2 |v] [ value ] [+] > > > > > > > > > > > > [-] > > > > > > > > > > > > [ key3 |v] [ value ] > > > > > > > > > > > > [-] > > > > > > > > > > > > [ "please select a key..." |v] > > > > > > > > > > > > > > > > > > > > > > > > it will be "prettier" like this: > > > > > > > > > > > > > > > > > > > > > > > > [ key1 |v] [ value ] [+] > > > > > > > > > > > > [-] > > > > > > > > > > > > [ key2 |v] [ value ] [+] > > > > > > > > > > > > [-] > > > > > > > > > > > > [ key3 |v] [ value ] [+] > > > > > > > > > > > > [-] > > > > > > > > > > > > > > > > > > > > > > > > and only if clicking on [+], it will be: > > > > > > > > > > > > > > > > > > > > > > > > [ key1 |v] [ value ] [+] > > > > > > > > > > > > [-] > > > > > > > > > > > > [ key2 |v] [ value ] [+] > > > > > > > > > > > > [-] > > > > > > > > > > > > [ key3 |v] [ value ] [+] > > > > > > > > > > > > [-] > > > > > > > > > > > > [ "please select a key..." |v] > > > > > > > > > > > > > > > > > > > > > > > > I believe that auto-sorting can be confusing, > > > > > > > > > > > > as > > > > > > > > > > > > it > > > > > > > > > > > > can > > > > > > > > > > > > result > > > > > > > > > > > > in > > > > > > > > > > > > rows "jumping" up and down whenever changing > > > > > > > > > > > > the > > > > > > > > > > > > selection(s) > > > > > > > > > > > > in > > > > > > > > > > > > the Key drop-down(s), > > > > > > > > > > > > > > > > > > > > > > this could be sort of mitigated by sorting > > > > > > > > > > > server-side > > > > > > > > > > > upon > > > > > > > > > > > modification. > > > > > > > > > > > > > > > > > > > > > > > therefore I don't think it is a good idea to > > > > > > > > > > > > implement > > > > > > > > > > > > it > > > > > > > > > > > > here. > > > > > > > > > > > > > > > > > > > > > > OTOH if we're to be manual sorting friendly, we > > > > > > > > > > > should > > > > > > > > > > > allow > > > > > > > > > > > rearranging > > > > > > > > > > > of the rows by drag & drop or by some sort of > > > > > > > > > > > move > > > > > > > > > > > up/down > > > > > > > > > > > buttons > > > > > > > > > > > and > > > > > > > > > > > the dialog would start to be cluttered. > > > > > > > > > > > > > > > > > > > > > > I don't really like either of these but auto-sort > > > > > > > > > > > is > > > > > > > > > > > slightly > > > > > > > > > > > better > > > > > > > > > > > IMO > > > > > > > > > > > as it is kept consistent accross various VMs > > > > > > > > > > > without > > > > > > > > > > > user > > > > > > > > > > > interaction. > > > > > > > > > > > > > > > > > > > > Indeed, auto-sort will keep the order consistent > > > > > > > > > > across > > > > > > > > > > all > > > > > > > > > > VMs. > > > > > > > > > > However, maybe the user would like to see the > > > > > > > > > > properties > > > > > > > > > > in > > > > > > > > > > the > > > > > > > > > > order in which he filled them; in this case, your > > > > > > > > > > suggestion > > > > > > > > > > of > > > > > > > > > > "move up/down buttons" is probably relevant here. > > > > > > > > > > > > > > > > > > > > I believe that the majority of use-cases won't > > > > > > > > > > require > > > > > > > > > > more > > > > > > > > > > than > > > > > > > > > > 2 > > > > > > > > > > or 3 custom properties per VM, so sorting won't be > > > > > > > > > > that > > > > > > > > > > critical, > > > > > > > > > > therefore I assume we can start without it; I will > > > > > > > > > > add > > > > > > > > > > "sorting" > > > > > > > > > > to the "open issues" section in the wiki page. > > > > > > > > > > > > > > > > > > > > > > > > > > > > That seems as more argument in favor of auto sorting. > > > > > > > > > > > > > > > > Or no sorting at all (i.e. simply display in order of > > > > > > > > filling)... > > > > > > > > In any case, open issue has been added to the wiki. > > > > > > > > > > > > > > > > > > > > > > > > > > David > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > David > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > David > > > > > > > > > > > > > > > > > > > > > > > > > > > ---- > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > Einav > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > Engine-devel mailing list > > > > > > > > > > > > > > Engine-devel at ovirt.org > > > > > > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > > David Ja?a, RHCE > > > > > > > > > > > > > > > > > > > > > > > > > > SPICE QE based in Brno > > > > > > > > > > > > > GPG Key: 22C33E24 > > > > > > > > > > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 > > > > > > > > > > > > > B125 > > > > > > > > > > > > > CD00 > > > > > > > > > > > > > 22C3 > > > > > > > > > > > > > 3E24 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > Engine-devel mailing list > > > > > > > > > > > > > Engine-devel at ovirt.org > > > > > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > David Ja?a, RHCE > > > > > > > > > > > > > > > > > > > > > > SPICE QE based in Brno > > > > > > > > > > > GPG Key: 22C33E24 > > > > > > > > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 > > > > > > > > > > > CD00 > > > > > > > > > > > 22C3 > > > > > > > > > > > 3E24 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > Engine-devel mailing list > > > > > > > > > > Engine-devel at ovirt.org > > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > David Ja?a, RHCE > > > > > > > > > > > > > > > > > > SPICE QE based in Brno > > > > > > > > > GPG Key: 22C33E24 > > > > > > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 > > > > > > > > > 22C3 > > > > > > > > > 3E24 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Engine-devel mailing list > > > > > > > > > Engine-devel at ovirt.org > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > David Ja?a, RHCE > > > > > > > > SPICE QE based in Brno > > > > GPG Key: 22C33E24 > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24 > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Engine-devel mailing list > > > Engine-devel at ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From juan.hernandez at redhat.com Sun May 20 13:29:07 2012 From: juan.hernandez at redhat.com (Juan Hernandez) Date: Sun, 20 May 2012 15:29:07 +0200 Subject: [Engine-devel] IMPORTANT: Root web application moved In-Reply-To: <603b3df9-3cf0-4e66-9f6a-7e8de94f8a23@zmail02.collab.prod.int.phx2.redhat.com> References: <603b3df9-3cf0-4e66-9f6a-7e8de94f8a23@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <4FB8F1A3.1090404@redhat.com> On 05/20/2012 10:49 AM, Oved Ourfalli wrote: > Hey, > > Is there a reason not to push the changes in standalone.xml (true-->false) as a patch? I think there is no reason. I already submitted the change to gerrit: http://gerrit.ovirt.org/4524 > > Thank you, > Oved > > ----- Original Message ----- >> From: "Juan Hernandez" >> To: engine-devel at ovirt.org, shireesh at redhat.com >> Sent: Thursday, May 17, 2012 11:13:50 PM >> Subject: [Engine-devel] IMPORTANT: Root web application moved >> >> Hello, >> >> I have recently merged a change that moves the root web application >> to >> the .ear directory: >> >> http://gerrit.ovirt.org/3782 >> >> This change could break your environment if you apply the patch and >> you >> don't do a clean installation. You may find an error like this in >> your >> server log and the application can fail to deploy: >> >> JBAS014777: Services which failed to start: service >> jboss.web.deployment.default-host./: >> org.jboss.msc.service.StartException in service >> jboss.web.deployment.default-host./: Failed to start service >> >> That means that you have more than one / application. Please make >> sure >> that you don't have the old ROOT.war in your deployment directory. >> Just >> remove it and the corresponding ROOT.war.dodeploy file. >> >> Also make sure that you don't have the following parameter in your >> standalone.xml file: >> >> enable-welcome-root="true" >> >> Change the value to "false". >> >> None of this actions are needed if you are building new RPMs and >> doing a >> clean installation. >> >> If you still have problems starting the application server after >> applying this change please let me know. >> >> Regards, >> Juan Hernandez >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> From ecohen at redhat.com Sun May 20 13:47:24 2012 From: ecohen at redhat.com (Einav Cohen) Date: Sun, 20 May 2012 09:47:24 -0400 (EDT) Subject: [Engine-devel] custom properties sheet feature page In-Reply-To: <046d8552-19d5-452a-ad86-f89f1890d2fe@zmail14.collab.prod.int.phx2.redhat.com> Message-ID: [top posting] Mock-ups have been updated according to this thread. You can check it in the feature page: http://www.ovirt.org/wiki/Features/CustomPropertiesSheet If you have any further comments, please share. ---- Thanks, Einav ----- Original Message ----- > From: "Gilad Chaplik" > To: "David Ja?a" > Cc: "Einav Cohen" , "Eldan Hildesheim" , engine-devel at ovirt.org, "Eldan > Hildesheim" , "Simon Grinberg" > Sent: Sunday, May 20, 2012 3:50:15 PM > Subject: Re: [Engine-devel] custom properties sheet feature page > > > ----- Original Message ----- > > From: "Gilad Chaplik" > > To: "Einav Cohen" > > Cc: "David Ja?a" , "Eldan Hildesheim" > > , engine-devel at ovirt.org, "Eldan > > Hildesheim" , "Simon Grinberg" > > > > Sent: Friday, May 18, 2012 1:15:16 PM > > Subject: Re: [Engine-devel] custom properties sheet feature page > > > > > > ----- Original Message ----- > > > From: "Einav Cohen" > > > To: "Gilad Chaplik" > > > Cc: "Eldan Hildesheim" , > > > engine-devel at ovirt.org, > > > "Simon Grinberg" , "Eldan > > > Hildesheim" , "David Ja?a" > > > > > > Sent: Friday, May 18, 2012 1:02:03 PM > > > Subject: Re: [Engine-devel] custom properties sheet feature page > > > > > > > ----- Original Message ----- > > > > From: "Gilad Chaplik" > > > > Sent: Friday, May 18, 2012 12:56:00 PM > > > > > > > > ----- Original Message ----- > > > > > From: "David Ja?a" > > > > > To: "Gilad Chaplik" > > > > > Cc: "Einav Cohen" , > > > > > engine-devel at ovirt.org, > > > > > "Miki Kenneth" , "Andrew Cathrow" > > > > > , "Simon Grinberg" > > > > > , > > > > > "Eldan Hildesheim" , "Eldan > > > > > Hildesheim" > > > > > Sent: Friday, May 18, 2012 12:51:43 PM > > > > > Subject: Re: [Engine-devel] custom properties sheet feature > > > > > page > > > > > > > > > > Gilad Chaplik p??e v P? 18. 05. 2012 v 05:44 -0400: > > > > > > ----- Original Message ----- > > > > > > > From: "Einav Cohen" > > > > > > > To: "Gilad Chaplik" > > > > > > > Cc: engine-devel at ovirt.org, "David Ja?a" > > > > > > > , > > > > > > > "Miki Kenneth" , "Andrew Cathrow" > > > > > > > , "Simon Grinberg" > > > > > > > , > > > > > > > "Eldan Hildesheim" , "Eldan > > > > > > > Hildesheim" > > > > > > > Sent: Friday, May 18, 2012 12:35:34 PM > > > > > > > Subject: Re: [Engine-devel] custom properties sheet > > > > > > > feature > > > > > > > page > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Gilad Chaplik" > > > > > > > > Sent: Friday, May 18, 2012 12:25:45 PM > > > > > > > > > > > > > > > > inline > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Gilad. > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > From: "Einav Cohen" > > > > > > > > > To: "David Ja?a" , "Miki Kenneth" > > > > > > > > > , "Andrew Cathrow" > > > > > > > > > , > > > > > > > > > "Simon Grinberg" , "Eldan > > > > > > > > > Hildesheim" > > > > > > > > > , "Eldan Hildesheim" > > > > > > > > > , "Gilad Chaplik" > > > > > > > > > > > > > > > > > > Cc: engine-devel at ovirt.org > > > > > > > > > Sent: Friday, May 18, 2012 12:12:54 PM > > > > > > > > > Subject: Re: [Engine-devel] custom properties sheet > > > > > > > > > feature > > > > > > > > > page > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > From: "David Ja?a" > > > > > > > > > > Sent: Friday, May 18, 2012 11:33:44 AM > > > > > > > > > > > > > > > > > > > > Einav Cohen p??e v ?t 17. 05. 2012 v 10:14 -0400: > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > From: "David Ja?a" > > > > > > > > > > > > Sent: Thursday, May 17, 2012 4:44:10 PM > > > > > > > > > > > > > > > > > > > > > > > > Einav Cohen p??e v ?t 17. 05. 2012 v 09:30 > > > > > > > > > > > > -0400: > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > From: "David Ja?a" > > > > > > > > > > > > > > Sent: Thursday, May 17, 2012 3:40:19 PM > > > > > > > > > > > > > > > > > > > > > > > > > > > > Einav Cohen p??e v ?t 17. 05. 2012 v 08:10 > > > > > > > > > > > > > > -0400: > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please review/comment on the Custom > > > > > > > > > > > > > > > Properties > > > > > > > > > > > > > > > Sheet > > > > > > > > > > > > > > > feature > > > > > > > > > > > > > > > page: > > > > > > > > > > > > > > > http://www.ovirt.org/wiki/Features/CustomPropertiesSheet > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Just my $0.02: > > > > > > > > > > > > > > > > > > > > > > > > > > > > The table could have always empty row at > > > > > > > > > > > > > > the > > > > > > > > > > > > > > bottom, > > > > > > > > > > > > > > eliminating > > > > > > > > > > > > > > one > > > > > > > > > > > > > > or > > > > > > > > > > > > > > all [+] buttons and saving user one > > > > > > > > > > > > > > needless > > > > > > > > > > > > > > click: > > > > > > > > > > > > > > > > > > > > > > > > > > > > [ key1 |v] [ value ] > > > > > > > > > > > > > > [+] > > > > > > > > > > > > > > [-] > > > > > > > > > > > > > > [ key2 |v] [ value ] > > > > > > > > > > > > > > [+] > > > > > > > > > > > > > > [-] > > > > > > > > > > > > > > [ key3 |v] [ value ] > > > > > > > > > > > > > > [-] > > > > > > > > > > > > > > [ "please select a key..." |v] > > > > > > > > > > > > > > > > > > > > > > > > > > > > The [+] buttons at first and second rows > > > > > > > > > > > > > > would > > > > > > > > > > > > > > allow > > > > > > > > > > > > > > user > > > > > > > > > > > > > > to > > > > > > > > > > > > > > insert a > > > > > > > > > > > > > > row at specified location to make easy > > > > > > > > > > > > > > custom > > > > > > > > > > > > > > sorting > > > > > > > > > > > > > > of > > > > > > > > > > > > > > the > > > > > > > > > > > > > > properties > > > > > > > > > > > > > > (not applicable if properties are > > > > > > > > > > > > > > auto-sorted, > > > > > > > > > > > > > > in > > > > > > > > > > > > > > that > > > > > > > > > > > > > > case, > > > > > > > > > > > > > > all > > > > > > > > > > > > > > [+] > > > > > > > > > > > > > > buttons can be actually removed). > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for the input, David. This is an > > > > > > > > > > > > > interesting > > > > > > > > > > > > > idea. > > > > > > > > > > > > > > > > > > > > > > > > > > Indeed, when choosing a key in the last row, > > > > > > > > > > > > > we > > > > > > > > > > > > > can > > > > > > > > > > > > > automatically > > > > > > > > > > > > > add a new "please select a key..." row, which > > > > > > > > > > > > > actually > > > > > > > > > > > > > saves > > > > > > > > > > > > > the > > > > > > > > > > > > > user a button-click for adding a new row. > > > > > > > > > > > > > > > > > > > > > > > > > > On the other hand, from graphic-design point > > > > > > > > > > > > > of > > > > > > > > > > > > > view, > > > > > > > > > > > > > it > > > > > > > > > > > > > will > > > > > > > > > > > > > look > > > > > > > > > > > > > more consistent and "pretty" if: > > > > > > > > > > > > > - The "please select a key..." row won't be > > > > > > > > > > > > > displayed > > > > > > > > > > > > > (unless, > > > > > > > > > > > > > or > > > > > > > > > > > > > course, the user explicitly chose to add > > > > > > > > > > > > > another > > > > > > > > > > > > > row) > > > > > > > > > > > > > - All (full) rows will have both [+] and [-] > > > > > > > > > > > > > buttons > > > > > > > > > > > > > next > > > > > > > > > > > > > to > > > > > > > > > > > > > them > > > > > > > > > > > > > > > > > > > > I should have probably elaborated more on this. To > > > > > > > > > > me, > > > > > > > > > > UI > > > > > > > > > > with > > > > > > > > > > less > > > > > > > > > > elements looks cleaner and prettier even when one > > > > > > > > > > of > > > > > > > > > > them > > > > > > > > > > stands > > > > > > > > > > out. > > > > > > > > > > There's also nothing wrong with standing out if the > > > > > > > > > > element > > > > > > > > > > has > > > > > > > > > > "special" meaning (one add vs bunch of modify). > > > > > > > > > > > > > > > > > > > > Specifically, this looks cleaner to my eyes: > > > > > > > > > > > > > > > > > > > > [ key1 |v] [ value ] [-] > > > > > > > > > > [ key2 |v] [ value ] [-] > > > > > > > > > > [ key3 |v] [ value ] [-] > > > > > > > > > > [ "Please select a key..." |v] > > > > > > > > > > > > > > > > > > > > than > > > > > > > > > > > > > > > > > > > > [ key1 |v] [ value ] [+] [-] > > > > > > > > > > [ key2 |v] [ value ] [+] [-] > > > > > > > > > > [ key3 |v] [ value ] [+] [-] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Note that in your suggestion above, you cannot insert > > > > > > > > > a > > > > > > > > > new > > > > > > > > > key > > > > > > > > > in > > > > > > > > > between existing keys - only at the end; so > > > > > > > > > although "cleaner", it has less functionality > > > > > > > > > (depends > > > > > > > > > also > > > > > > > > > on > > > > > > > > > the > > > > > > > > > sorting, which is another issue; if there is > > > > > > > > > auto-sorting, > > > > > > > > > it > > > > > > > > > doesn't matter). > > > > > > > > > It is also a matter of taste, I guess, so no absolute > > > > > > > > > right > > > > > > > > > or > > > > > > > > > wrong > > > > > > > > > here IMO. > > > > > > > > > [Others - you are welcome to comment as well] > > > > > > > > > > > > > > > > +1 > > > > > > > > > > > > > > > > another tiny comment: > > > > > > > > can the empty line contain all the fields from initial > > > > > > > > state > > > > > > > > [["please select a key..."][field(empty)][+][-]] > > > > > > > > instead of showing them only after selecting a key. > > > > > > > > [["please select a key..."]] > > > > > > > > > > > > > > > > both of these scenarios are liable, > > > > > > > > I can select a key, regret (change back to [please > > > > > > > > select > > > > > > > > a > > > > > > > > key]) > > > > > > > > and > > > > > > > > the field and buttons are still visible. > > > > > > > > > > > > > > > > so for the sake of complexity, I prefer to have only > > > > > > > > one. > > > > > > > > > > > > > > * Note that the field input control type (text-box, > > > > > > > drop-down) > > > > > > > depends on the key anyway (more accurately, on the > > > > > > > validation > > > > > > > regular expression of the key), so what are you going to > > > > > > > show > > > > > > > in > > > > > > > case of "please select a key..."? > > > > > > > > > > > > empty text-box > > > > > > > > > > > > > > > > > > > > * Need to make sure that validation fails in case field > > > > > > > value > > > > > > > is > > > > > > > not > > > > > > > empty and key is "please select a key...". > > > > > > > > > > > > > > > > > I would prefer to just disable the value input field and do > > > > > re-validation upon change of key (clear the value if it fails > > > > > validation > > > > > against a new key) or server-side when it is changed (clear > > > > > the > > > > > key-value pair altogether). > > > > > > > > +1 for disabling > > > > -1 for clearing - it is not advised to clear a field if its > > > > fails > > > > on > > > > validation. > > Actually while implementing it, having a disabled field makes the > user think why it's disabled, it is a bit confusing + less minimal > :) > I suggest to leave it as Einav's initial proposal. > > > > > > > > > > > > > > > > David > > > > > > > > > > > > Due to both of these reasons, I prefer to not show an > > > > > > > input > > > > > > > control > > > > > > > at all in this case. > > > > > > > > > > > > still, I don't see any difference, except adding > > > > > > complexity/devel-time/bugs later on. > > > > > > plus I think it's nicer. > > > > > > > > > > > > > > > > > > > > * No problem of having a "+" button there; however, need > > > > > > > to > > > > > > > make > > > > > > > sure > > > > > > > that in case there is only one row in the sheet and it is > > > > > > > with > > > > > > > "please select a key...", the "-" button should be either > > > > > > > hidden > > > > > > > or > > > > > > > disabled (or non-responsive), since we can't remove the > > > > > > > last > > > > > > > row. > > > > > > Don't forget to take this ^^^ also under consideration. > > > > silence means agreement :) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If the [+] button in my proposal is just greyed > > > > > > > > > > > > out > > > > > > > > > > > > instead > > > > > > > > > > > > of > > > > > > > > > > > > ommited, > > > > > > > > > > > > it could satisfy both requirements. > > > > > > > > > > > > > > > > > > > > > > Almost; the "please select a key..." row is still > > > > > > > > > > > always > > > > > > > > > > > displayed; > > > > > > > > > > > question is if we want to save a button-click > > > > > > > > > > > (your > > > > > > > > > > > suggestion) > > > > > > > > > > > or > > > > > > > > > > > to have a "cleaner" sheet (my suggestion). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > i.e., instead of your suggestion, which looks > > > > > > > > > > > > > like > > > > > > > > > > > > > this: > > > > > > > > > > > > > > > > > > > > > > > > > > [ key1 |v] [ value ] [+] > > > > > > > > > > > > > [-] > > > > > > > > > > > > > [ key2 |v] [ value ] [+] > > > > > > > > > > > > > [-] > > > > > > > > > > > > > [ key3 |v] [ value ] > > > > > > > > > > > > > [-] > > > > > > > > > > > > > [ "please select a key..." |v] > > > > > > > > > > > > > > > > > > > > > > > > > > it will be "prettier" like this: > > > > > > > > > > > > > > > > > > > > > > > > > > [ key1 |v] [ value ] [+] > > > > > > > > > > > > > [-] > > > > > > > > > > > > > [ key2 |v] [ value ] [+] > > > > > > > > > > > > > [-] > > > > > > > > > > > > > [ key3 |v] [ value ] [+] > > > > > > > > > > > > > [-] > > > > > > > > > > > > > > > > > > > > > > > > > > and only if clicking on [+], it will be: > > > > > > > > > > > > > > > > > > > > > > > > > > [ key1 |v] [ value ] [+] > > > > > > > > > > > > > [-] > > > > > > > > > > > > > [ key2 |v] [ value ] [+] > > > > > > > > > > > > > [-] > > > > > > > > > > > > > [ key3 |v] [ value ] [+] > > > > > > > > > > > > > [-] > > > > > > > > > > > > > [ "please select a key..." |v] > > > > > > > > > > > > > > > > > > > > > > > > > > I believe that auto-sorting can be confusing, > > > > > > > > > > > > > as > > > > > > > > > > > > > it > > > > > > > > > > > > > can > > > > > > > > > > > > > result > > > > > > > > > > > > > in > > > > > > > > > > > > > rows "jumping" up and down whenever changing > > > > > > > > > > > > > the > > > > > > > > > > > > > selection(s) > > > > > > > > > > > > > in > > > > > > > > > > > > > the Key drop-down(s), > > > > > > > > > > > > > > > > > > > > > > > > this could be sort of mitigated by sorting > > > > > > > > > > > > server-side > > > > > > > > > > > > upon > > > > > > > > > > > > modification. > > > > > > > > > > > > > > > > > > > > > > > > > therefore I don't think it is a good idea to > > > > > > > > > > > > > implement > > > > > > > > > > > > > it > > > > > > > > > > > > > here. > > > > > > > > > > > > > > > > > > > > > > > > OTOH if we're to be manual sorting friendly, we > > > > > > > > > > > > should > > > > > > > > > > > > allow > > > > > > > > > > > > rearranging > > > > > > > > > > > > of the rows by drag & drop or by some sort of > > > > > > > > > > > > move > > > > > > > > > > > > up/down > > > > > > > > > > > > buttons > > > > > > > > > > > > and > > > > > > > > > > > > the dialog would start to be cluttered. > > > > > > > > > > > > > > > > > > > > > > > > I don't really like either of these but > > > > > > > > > > > > auto-sort > > > > > > > > > > > > is > > > > > > > > > > > > slightly > > > > > > > > > > > > better > > > > > > > > > > > > IMO > > > > > > > > > > > > as it is kept consistent accross various VMs > > > > > > > > > > > > without > > > > > > > > > > > > user > > > > > > > > > > > > interaction. > > > > > > > > > > > > > > > > > > > > > > Indeed, auto-sort will keep the order consistent > > > > > > > > > > > across > > > > > > > > > > > all > > > > > > > > > > > VMs. > > > > > > > > > > > However, maybe the user would like to see the > > > > > > > > > > > properties > > > > > > > > > > > in > > > > > > > > > > > the > > > > > > > > > > > order in which he filled them; in this case, your > > > > > > > > > > > suggestion > > > > > > > > > > > of > > > > > > > > > > > "move up/down buttons" is probably relevant here. > > > > > > > > > > > > > > > > > > > > > > I believe that the majority of use-cases won't > > > > > > > > > > > require > > > > > > > > > > > more > > > > > > > > > > > than > > > > > > > > > > > 2 > > > > > > > > > > > or 3 custom properties per VM, so sorting won't > > > > > > > > > > > be > > > > > > > > > > > that > > > > > > > > > > > critical, > > > > > > > > > > > therefore I assume we can start without it; I > > > > > > > > > > > will > > > > > > > > > > > add > > > > > > > > > > > "sorting" > > > > > > > > > > > to the "open issues" section in the wiki page. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > That seems as more argument in favor of auto > > > > > > > > > > sorting. > > > > > > > > > > > > > > > > > > Or no sorting at all (i.e. simply display in order of > > > > > > > > > filling)... > > > > > > > > > In any case, open issue has been added to the wiki. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > David > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > David > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > David > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ---- > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > Einav > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > > Engine-devel mailing list > > > > > > > > > > > > > > > Engine-devel at ovirt.org > > > > > > > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > David Ja?a, RHCE > > > > > > > > > > > > > > > > > > > > > > > > > > > > SPICE QE based in Brno > > > > > > > > > > > > > > GPG Key: 22C33E24 > > > > > > > > > > > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 > > > > > > > > > > > > > > B125 > > > > > > > > > > > > > > CD00 > > > > > > > > > > > > > > 22C3 > > > > > > > > > > > > > > 3E24 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > Engine-devel mailing list > > > > > > > > > > > > > > Engine-devel at ovirt.org > > > > > > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > David Ja?a, RHCE > > > > > > > > > > > > > > > > > > > > > > > > SPICE QE based in Brno > > > > > > > > > > > > GPG Key: 22C33E24 > > > > > > > > > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 > > > > > > > > > > > > CD00 > > > > > > > > > > > > 22C3 > > > > > > > > > > > > 3E24 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > Engine-devel mailing list > > > > > > > > > > > Engine-devel at ovirt.org > > > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > David Ja?a, RHCE > > > > > > > > > > > > > > > > > > > > SPICE QE based in Brno > > > > > > > > > > GPG Key: 22C33E24 > > > > > > > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 > > > > > > > > > > CD00 > > > > > > > > > > 22C3 > > > > > > > > > > 3E24 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > Engine-devel mailing list > > > > > > > > > > Engine-devel at ovirt.org > > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > David Ja?a, RHCE > > > > > > > > > > SPICE QE based in Brno > > > > > GPG Key: 22C33E24 > > > > > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 > > > > > 3E24 > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Engine-devel mailing list > > > > Engine-devel at ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > From mpastern at redhat.com Sun May 20 13:57:13 2012 From: mpastern at redhat.com (Michael Pasternak) Date: Sun, 20 May 2012 16:57:13 +0300 Subject: [Engine-devel] DiskImage public mupper Message-ID: <4FB8F839.2020808@redhat.com> what should be exposed to user as disk.id: DiskImage.id or DiskImage.ImageId ? -- Michael Pasternak RedHat, ENG-Virtualization R&D From mkublin at redhat.com Sun May 20 13:55:26 2012 From: mkublin at redhat.com (Michael Kublin) Date: Sun, 20 May 2012 09:55:26 -0400 (EDT) Subject: [Engine-devel] DiskImage public mupper In-Reply-To: <4FB8F839.2020808@redhat.com> Message-ID: both, id - it is a common id for all images that a disk point of them, and ImageId it is a current image ----- Original Message ----- From: "Michael Pasternak" To: "Michael Kublin" , "Yair Zaslavsky" Cc: "engine-devel" Sent: Sunday, May 20, 2012 4:57:13 PM Subject: DiskImage public mupper what should be exposed to user as disk.id: DiskImage.id or DiskImage.ImageId ? -- Michael Pasternak RedHat, ENG-Virtualization R&D From mpastern at redhat.com Sun May 20 14:08:22 2012 From: mpastern at redhat.com (Michael Pasternak) Date: Sun, 20 May 2012 17:08:22 +0300 Subject: [Engine-devel] DiskImage public mapper In-Reply-To: References: Message-ID: <4FB8FAD6.50909@redhat.com> On 05/20/2012 04:55 PM, Michael Kublin wrote: > both, id - it is a common id for all images that a disk point of them, and ImageId it is a current image if so i have doubts about cloning vm from template impl, as parameters class in BackendVmsResource:182 that receives HashMap as collection of disks to clone has "current image" id as key, Yair shouldn't it be /id/ rather than /ImageId/? > > ----- Original Message ----- > From: "Michael Pasternak" > To: "Michael Kublin" , "Yair Zaslavsky" > Cc: "engine-devel" > Sent: Sunday, May 20, 2012 4:57:13 PM > Subject: DiskImage public mupper > > what should be exposed to user as disk.id: DiskImage.id or DiskImage.ImageId ? -- Michael Pasternak RedHat, ENG-Virtualization R&D From mkublin at redhat.com Sun May 20 14:22:13 2012 From: mkublin at redhat.com (Michael Kublin) Date: Sun, 20 May 2012 10:22:13 -0400 (EDT) Subject: [Engine-devel] DiskImage public mapper In-Reply-To: <4FB8FAD6.50909@redhat.com> Message-ID: <656768dc-e678-447f-ad3e-af894ab8fd0b@zmail14.collab.prod.int.phx2.redhat.com> Yep, it is should be id, I aware about these and Ori already asked me to change it, I will change these very soon ----- Original Message ----- From: "Michael Pasternak" To: "Yair Zaslavsky" Cc: "Michael Kublin" , "engine-devel" Sent: Sunday, May 20, 2012 5:08:22 PM Subject: Re: DiskImage public mapper On 05/20/2012 04:55 PM, Michael Kublin wrote: > both, id - it is a common id for all images that a disk point of them, and ImageId it is a current image if so i have doubts about cloning vm from template impl, as parameters class in BackendVmsResource:182 that receives HashMap as collection of disks to clone has "current image" id as key, Yair shouldn't it be /id/ rather than /ImageId/? > > ----- Original Message ----- > From: "Michael Pasternak" > To: "Michael Kublin" , "Yair Zaslavsky" > Cc: "engine-devel" > Sent: Sunday, May 20, 2012 4:57:13 PM > Subject: DiskImage public mupper > > what should be exposed to user as disk.id: DiskImage.id or DiskImage.ImageId ? -- Michael Pasternak RedHat, ENG-Virtualization R&D From mpastern at redhat.com Sun May 20 14:31:58 2012 From: mpastern at redhat.com (Michael Pasternak) Date: Sun, 20 May 2012 17:31:58 +0300 Subject: [Engine-devel] DiskImage public mapper In-Reply-To: <656768dc-e678-447f-ad3e-af894ab8fd0b@zmail14.collab.prod.int.phx2.redhat.com> References: <656768dc-e678-447f-ad3e-af894ab8fd0b@zmail14.collab.prod.int.phx2.redhat.com> Message-ID: <4FB9005E.40805@redhat.com> note: i partly changed it in [1] fixing bug. [1] http://gerrit.ovirt.org/#change,4572 On 05/20/2012 05:22 PM, Michael Kublin wrote: > Yep, it is should be id, I aware about these and Ori already asked me to change it, I will change these very soon > > ----- Original Message ----- > From: "Michael Pasternak" > To: "Yair Zaslavsky" > Cc: "Michael Kublin" , "engine-devel" > Sent: Sunday, May 20, 2012 5:08:22 PM > Subject: Re: DiskImage public mapper > > On 05/20/2012 04:55 PM, Michael Kublin wrote: >> both, id - it is a common id for all images that a disk point of them, and ImageId it is a current image > > if so i have doubts about cloning vm from template impl, as parameters class in BackendVmsResource:182 > that receives HashMap as collection of disks to clone has "current image" id as key, > > Yair shouldn't it be /id/ rather than /ImageId/? > >> >> ----- Original Message ----- >> From: "Michael Pasternak" >> To: "Michael Kublin" , "Yair Zaslavsky" >> Cc: "engine-devel" >> Sent: Sunday, May 20, 2012 4:57:13 PM >> Subject: DiskImage public mupper >> >> what should be exposed to user as disk.id: DiskImage.id or DiskImage.ImageId ? > > -- Michael Pasternak RedHat, ENG-Virtualization R&D From oschreib at redhat.com Sun May 20 14:39:31 2012 From: oschreib at redhat.com (Ofer Schreiber) Date: Sun, 20 May 2012 10:39:31 -0400 (EDT) Subject: [Engine-devel] F17 maven build failure In-Reply-To: Message-ID: <8a62eb8a-47f5-4936-a8b3-338f3c8f0b30@zmail14.collab.prod.int.phx2.redhat.com> Hey, I'm trying to build ovirt-engine in Fedora 17, and getting the following error: [INFO] oVirt Modules - manager ........................... FAILURE [1:05.421s] .... [ERROR] Failed to execute goal org.apache.maven.plugins:maven-checkstyle-plugin:2.6:check (default) on project manager-modules: Execution default of goal org.apache.maven.plugins:maven-checkstyle-plugin:2.6:check failed: Plugin org.apache.maven.plugins:maven-checkstyle-plugin:2.6 or one of its dependencies could not be resolved: The following artifacts could not be resolved: checkstyle:checkstyle:jar:5.0, antlr:antlr:jar:2.7.6, commons-beanutils:commons-beanutils-core:jar:1.7.0, com.google.collections:google-collections:jar:0.9: Could not find artifact checkstyle:checkstyle:jar:5.0 -> [Help 1] Any idea how can I resolve it? --- Ofer Schreiber From ovedo at redhat.com Sun May 20 15:03:33 2012 From: ovedo at redhat.com (Oved Ourfalli) Date: Sun, 20 May 2012 11:03:33 -0400 (EDT) Subject: [Engine-devel] IMPORTANT: Root web application moved In-Reply-To: <4FB8F1A3.1090404@redhat.com> Message-ID: <9759190a-5f01-4d3b-a523-a70a027c2fde@zmail02.collab.prod.int.phx2.redhat.com> Your fix is now merged. Everyone - please note that in order to apply the fix in your environment you need to run the maven build with -Psetup (just do the command you always do, and add the "setup" to the profiles in the -P option). However, it will only work if you upgraded your Jboss to 7.1.1, so make sure you upgrade! If you are still working with jboss 7.1.0 then it will fail to parse the jboss configuration. Regards, Oved ----- Original Message ----- > From: "Juan Hernandez" > To: "Oved Ourfalli" > Cc: engine-devel at ovirt.org > Sent: Sunday, May 20, 2012 4:29:07 PM > Subject: Re: [Engine-devel] IMPORTANT: Root web application moved > > On 05/20/2012 10:49 AM, Oved Ourfalli wrote: > > Hey, > > > > Is there a reason not to push the changes in standalone.xml > > (true-->false) as a patch? > > I think there is no reason. I already submitted the change to gerrit: > > http://gerrit.ovirt.org/4524 > > > > > Thank you, > > Oved > > > > ----- Original Message ----- > >> From: "Juan Hernandez" > >> To: engine-devel at ovirt.org, shireesh at redhat.com > >> Sent: Thursday, May 17, 2012 11:13:50 PM > >> Subject: [Engine-devel] IMPORTANT: Root web application moved > >> > >> Hello, > >> > >> I have recently merged a change that moves the root web > >> application > >> to > >> the .ear directory: > >> > >> http://gerrit.ovirt.org/3782 > >> > >> This change could break your environment if you apply the patch > >> and > >> you > >> don't do a clean installation. You may find an error like this in > >> your > >> server log and the application can fail to deploy: > >> > >> JBAS014777: Services which failed to start: service > >> jboss.web.deployment.default-host./: > >> org.jboss.msc.service.StartException in service > >> jboss.web.deployment.default-host./: Failed to start service > >> > >> That means that you have more than one / application. Please make > >> sure > >> that you don't have the old ROOT.war in your deployment directory. > >> Just > >> remove it and the corresponding ROOT.war.dodeploy file. > >> > >> Also make sure that you don't have the following parameter in your > >> standalone.xml file: > >> > >> enable-welcome-root="true" > >> > >> Change the value to "false". > >> > >> None of this actions are needed if you are building new RPMs and > >> doing a > >> clean installation. > >> > >> If you still have problems starting the application server after > >> applying this change please let me know. > >> > >> Regards, > >> Juan Hernandez > >> _______________________________________________ > >> Engine-devel mailing list > >> Engine-devel at ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/engine-devel > >> > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From jhernand at redhat.com Sun May 20 15:54:00 2012 From: jhernand at redhat.com (Juan Hernandez) Date: Sun, 20 May 2012 17:54:00 +0200 Subject: [Engine-devel] F17 maven build failure In-Reply-To: <8a62eb8a-47f5-4936-a8b3-338f3c8f0b30@zmail14.collab.prod.int.phx2.redhat.com> References: <8a62eb8a-47f5-4936-a8b3-338f3c8f0b30@zmail14.collab.prod.int.phx2.redhat.com> Message-ID: <4FB91398.9040602@redhat.com> On 05/20/2012 04:39 PM, Ofer Schreiber wrote: > I'm trying to build ovirt-engine in Fedora 17, and getting the following error: > > [INFO] oVirt Modules - manager ........................... FAILURE [1:05.421s] > .... > > [ERROR] Failed to execute goal org.apache.maven.plugins:maven-checkstyle-plugin:2.6:check (default) on project manager-modules: Execution default of goal org.apache.maven.plugins:maven-checkstyle-plugin:2.6:check failed: Plugin org.apache.maven.plugins:maven-checkstyle-plugin:2.6 or one of its dependencies could not be resolved: The following artifacts could not be resolved: checkstyle:checkstyle:jar:5.0, antlr:antlr:jar:2.7.6, commons-beanutils:commons-beanutils-core:jar:1.7.0, com.google.collections:google-collections:jar:0.9: Could not find artifact checkstyle:checkstyle:jar:5.0 -> [Help 1] > > Any idea how can I resolve it? Are you building with regular "mvn" or with "mvn-rpmbuild"? If you are using the later you will have to update to checkstyle 5.5 and to maven-checkstyle-plugin 2.9.1, as those are what are available in Fedora 17. In addition the gid:aid of checkstyle changed from checkstyle:checkstyle to com.puppycrawl.tools:checkstyle somewhere between 5.0 and 5.5. -- Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3?D, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat S.L. From oschreib at redhat.com Sun May 20 17:29:51 2012 From: oschreib at redhat.com (Ofer Schreiber) Date: Sun, 20 May 2012 13:29:51 -0400 (EDT) Subject: [Engine-devel] F17 maven build failure In-Reply-To: <4FB91398.9040602@redhat.com> References: <8a62eb8a-47f5-4936-a8b3-338f3c8f0b30@zmail14.collab.prod.int.phx2.redhat.com> <4FB91398.9040602@redhat.com> Message-ID: I'm using the regular mvn install command, should I do some changes in the main pom file? On 20 May 2012, at 18:54, Juan Hernandez wrote: > On 05/20/2012 04:39 PM, Ofer Schreiber wrote: >> I'm trying to build ovirt-engine in Fedora 17, and getting the following error: >> >> [INFO] oVirt Modules - manager ........................... FAILURE [1:05.421s] >> .... >> >> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-checkstyle-plugin:2.6:check (default) on project manager-modules: Execution default of goal org.apache.maven.plugins:maven-checkstyle-plugin:2.6:check failed: Plugin org.apache.maven.plugins:maven-checkstyle-plugin:2.6 or one of its dependencies could not be resolved: The following artifacts could not be resolved: checkstyle:checkstyle:jar:5.0, antlr:antlr:jar:2.7.6, commons-beanutils:commons-beanutils-core:jar:1.7.0, com.google.collections:google-collections:jar:0.9: Could not find artifact checkstyle:checkstyle:jar:5.0 -> [Help 1] >> >> Any idea how can I resolve it? > > Are you building with regular "mvn" or with "mvn-rpmbuild"? > > If you are using the later you will have to update to checkstyle 5.5 and to maven-checkstyle-plugin 2.9.1, as those are what are available in Fedora 17. In addition the gid:aid of checkstyle changed from checkstyle:checkstyle to com.puppycrawl.tools:checkstyle somewhere between 5.0 and 5.5. > > -- > Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3?D, 28016 Madrid, Spain > Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat S.L. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlaor at redhat.com Sun May 20 18:41:59 2012 From: dlaor at redhat.com (Dor Laor) Date: Sun, 20 May 2012 21:41:59 +0300 Subject: [Engine-devel] CPU Pinning @engine In-Reply-To: <4FB55C52.5000609@redhat.com> References: <8cec63b1-c0e9-4914-be11-de2bfbabc85a@abaron.usersys.redhat.com> <4FB55C52.5000609@redhat.com> Message-ID: <4FB93AF7.4000708@redhat.com> On 05/17/2012 11:15 PM, Doron Fediuck wrote: > On 17/05/12 20:28, Ayal Baron wrote: >> "Live migration will not be supported for such VM's." >> >> Migration will work on homogeneous clusters so this should not be enforced (not limited to VMs which are pinned to host) just give a warning. >> > I agree, but if we wish to ping vCPUx to pCPUy in host a, we cannot ensure to have the same in host b, > since it may have pCPUy too busy, so performance will degrade. Also, I hope you saw my general comment Performance may degrade on any migration to loaded host regardless of pinning. There is not need to forbid migration. Instead, the SLA assurance policy should verify the dedicated resources and match the target w/ the guarantee and decide according to this. > about starting with a humble solution and gradually improving. In this context (auto)numa can help us, > so we better do numa than handle migration for basic mode, risking performance issues. > >> >> ----- Original Message ----- >>> From: "Doron Fediuck" >>> To: engine-devel at ovirt.org >>> Sent: Thursday, May 17, 2012 2:42:46 PM >>> Subject: [Engine-devel] CPU Pinning @engine >>> >>> Hi All, >>> Currently the VDSM has a CPU pinning hook. >>> We'd like to add better support of it into the engine itself. >>> Here's a design draft to cover it: >>> http://www.ovirt.org/wiki/Features/Design/cpu-pinning >>> >>> Please review and comment if needed. >>> >>> Thanks! >>> -- >>> >>> /d >>> >>> Never say "OOPS!" always say "Ah, Interesting!" >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel at ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel > > From jhernand at redhat.com Sun May 20 19:20:53 2012 From: jhernand at redhat.com (Juan Hernandez) Date: Sun, 20 May 2012 21:20:53 +0200 Subject: [Engine-devel] F17 maven build failure In-Reply-To: References: <8a62eb8a-47f5-4936-a8b3-338f3c8f0b30@zmail14.collab.prod.int.phx2.redhat.com> <4FB91398.9040602@redhat.com> Message-ID: <4FB94415.3040209@redhat.com> On 05/20/2012 07:29 PM, Ofer Schreiber wrote: > I'm using the regular mvn install command, should I do some changes in the main pom file? I think that this is probably a bug in maven, but one that we are triggering due to the fact that we assign different identifiers to the repositories used for normal artifacts and the repositories used for plugins. Can you try the attached patch and let me know if it fixes your problem? > On 20 May 2012, at 18:54, Juan Hernandez wrote: > >> On 05/20/2012 04:39 PM, Ofer Schreiber wrote: >>> I'm trying to build ovirt-engine in Fedora 17, and getting the following error: >>> >>> [INFO] oVirt Modules - manager ........................... FAILURE [1:05.421s] >>> .... >>> >>> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-checkstyle-plugin:2.6:check (default) on project manager-modules: Execution default of goal org.apache.maven.plugins:maven-checkstyle-plugin:2.6:check failed: Plugin org.apache.maven.plugins:maven-checkstyle-plugin:2.6 or one of its dependencies could not be resolved: The following artifacts could not be resolved: checkstyle:checkstyle:jar:5.0, antlr:antlr:jar:2.7.6, commons-beanutils:commons-beanutils-core:jar:1.7.0, com.google.collections:google-collections:jar:0.9: Could not find artifact checkstyle:checkstyle:jar:5.0 -> [Help 1] >>> >>> Any idea how can I resolve it? >> >> Are you building with regular "mvn" or with "mvn-rpmbuild"? >> >> If you are using the later you will have to update to checkstyle 5.5 and to maven-checkstyle-plugin 2.9.1, as those are what are available in Fedora 17. In addition the gid:aid of checkstyle changed from checkstyle:checkstyle to com.puppycrawl.tools:checkstyle somewhere between 5.0 and 5.5. -- Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3?D, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat S.L. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-core-Use-same-ids-for-artifacts-and-plugins.patch Type: text/x-patch Size: 1679 bytes Desc: not available URL: From dfediuck at redhat.com Sun May 20 21:49:08 2012 From: dfediuck at redhat.com (Doron Fediuck) Date: Mon, 21 May 2012 00:49:08 +0300 Subject: [Engine-devel] CPU Pinning @engine In-Reply-To: <4FB93AF7.4000708@redhat.com> References: <8cec63b1-c0e9-4914-be11-de2bfbabc85a@abaron.usersys.redhat.com> <4FB55C52.5000609@redhat.com> <4FB93AF7.4000708@redhat.com> Message-ID: <4FB966D4.1030902@redhat.com> On 20/05/12 21:41, Dor Laor wrote: > On 05/17/2012 11:15 PM, Doron Fediuck wrote: >> On 17/05/12 20:28, Ayal Baron wrote: >>> "Live migration will not be supported for such VM's." >>> >>> Migration will work on homogeneous clusters so this should not be enforced (not limited to VMs which are pinned to host) just give a warning. >>> >> I agree, but if we wish to ping vCPUx to pCPUy in host a, we cannot ensure to have the same in host b, >> since it may have pCPUy too busy, so performance will degrade. Also, I hope you saw my general comment > > Performance may degrade on any migration to loaded host regardless of pinning. > > There is not need to forbid migration. Instead, the SLA assurance policy should verify the dedicated resources and match the target w/ the guarantee and decide according to this. > Thanks for the input. We may start with migration blocked in a configurable manner, so people who wish migrate to work will simply set the relevant configuration key. As for looking for a matched CPU, will add it as p2. >> about starting with a humble solution and gradually improving. In this context (auto)numa can help us, >> so we better do numa than handle migration for basic mode, risking performance issues. >> >>> >>> ----- Original Message ----- >>>> From: "Doron Fediuck" >>>> To: engine-devel at ovirt.org >>>> Sent: Thursday, May 17, 2012 2:42:46 PM >>>> Subject: [Engine-devel] CPU Pinning @engine >>>> >>>> Hi All, >>>> Currently the VDSM has a CPU pinning hook. >>>> We'd like to add better support of it into the engine itself. >>>> Here's a design draft to cover it: >>>> http://www.ovirt.org/wiki/Features/Design/cpu-pinning >>>> >>>> Please review and comment if needed. >>>> >>>> Thanks! >>>> -- >>>> >>>> /d >>>> >>>> Never say "OOPS!" always say "Ah, Interesting!" >>>> _______________________________________________ >>>> Engine-devel mailing list >>>> Engine-devel at ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>> >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel at ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >> >> > -- /d Never say "OOPS!" always say "Ah, Interesting!" From acathrow at redhat.com Sun May 20 22:45:10 2012 From: acathrow at redhat.com (Andrew Cathrow) Date: Sun, 20 May 2012 18:45:10 -0400 (EDT) Subject: [Engine-devel] CPU Pinning @engine In-Reply-To: <4FB966D4.1030902@redhat.com> Message-ID: <3818ff2c-7931-4c54-9278-5ceab9790a82@zmail07.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Doron Fediuck" > To: dlaor at redhat.com > Cc: engine-devel at ovirt.org > Sent: Sunday, May 20, 2012 5:49:08 PM > Subject: Re: [Engine-devel] CPU Pinning @engine > > On 20/05/12 21:41, Dor Laor wrote: > > On 05/17/2012 11:15 PM, Doron Fediuck wrote: > >> On 17/05/12 20:28, Ayal Baron wrote: > >>> "Live migration will not be supported for such VM's." > >>> > >>> Migration will work on homogeneous clusters so this should not be > >>> enforced (not limited to VMs which are pinned to host) just give > >>> a warning. > >>> > >> I agree, but if we wish to ping vCPUx to pCPUy in host a, we > >> cannot ensure to have the same in host b, > >> since it may have pCPUy too busy, so performance will degrade. > >> Also, I hope you saw my general comment > > > > Performance may degrade on any migration to loaded host regardless > > of pinning. > > > > There is not need to forbid migration. Instead, the SLA assurance > > policy should verify the dedicated resources and match the target > > w/ the guarantee and decide according to this. > > > Thanks for the input. > We may start with migration blocked in a configurable manner, so > people who wish migrate to work > will simply set the relevant configuration key. > As for looking for a matched CPU, will add it as p2. We shouldn't block migration If a user wants to not migrate a cpu pinned VM then let them use the non-migratable flag in the UI. > > >> about starting with a humble solution and gradually improving. In > >> this context (auto)numa can help us, > >> so we better do numa than handle migration for basic mode, risking > >> performance issues. > >> > >>> > >>> ----- Original Message ----- > >>>> From: "Doron Fediuck" > >>>> To: engine-devel at ovirt.org > >>>> Sent: Thursday, May 17, 2012 2:42:46 PM > >>>> Subject: [Engine-devel] CPU Pinning @engine > >>>> > >>>> Hi All, > >>>> Currently the VDSM has a CPU pinning hook. > >>>> We'd like to add better support of it into the engine itself. > >>>> Here's a design draft to cover it: > >>>> http://www.ovirt.org/wiki/Features/Design/cpu-pinning > >>>> > >>>> Please review and comment if needed. > >>>> > >>>> Thanks! > >>>> -- > >>>> > >>>> /d > >>>> > >>>> Never say "OOPS!" always say "Ah, Interesting!" > >>>> _______________________________________________ > >>>> Engine-devel mailing list > >>>> Engine-devel at ovirt.org > >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > >>>> > >>> _______________________________________________ > >>> Engine-devel mailing list > >>> Engine-devel at ovirt.org > >>> http://lists.ovirt.org/mailman/listinfo/engine-devel > >> > >> > > > > > -- > > /d > > Never say "OOPS!" always say "Ah, Interesting!" > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From gchaplik at redhat.com Mon May 21 05:32:15 2012 From: gchaplik at redhat.com (Gilad Chaplik) Date: Mon, 21 May 2012 01:32:15 -0400 (EDT) Subject: [Engine-devel] CPU Pinning @engine In-Reply-To: <4FB4E436.50100@redhat.com> Message-ID: Hi Doron, one suggestion regarding the ui, we can reuse the key-value widget we did in Custom Properties Sheet (http://www.ovirt.org/wiki/Features/CustomPropertiesSheet) instead of the text box ([vcpu - dropdown][value - textbox][+][-]). just need to know the number of vcpus (keys in that case). Thanks, Gilad. ----- Original Message ----- > From: "Doron Fediuck" > To: engine-devel at ovirt.org > Sent: Thursday, May 17, 2012 2:42:46 PM > Subject: [Engine-devel] CPU Pinning @engine > > Hi All, > Currently the VDSM has a CPU pinning hook. > We'd like to add better support of it into the engine itself. > Here's a design draft to cover it: > http://www.ovirt.org/wiki/Features/Design/cpu-pinning > > Please review and comment if needed. > > Thanks! > -- > > /d > > Never say "OOPS!" always say "Ah, Interesting!" > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From mkolesni at redhat.com Mon May 21 07:18:30 2012 From: mkolesni at redhat.com (Mike Kolesnik) Date: Mon, 21 May 2012 03:18:30 -0400 (EDT) Subject: [Engine-devel] MAC address validation In-Reply-To: Message-ID: Hi, We have a bug open on engine to validate MAC address: https://bugzilla.redhat.com/show_bug.cgi?id=756437 The format supported by engine (for Ethernet) is FF:FF:FF:FF:FF:FF (F is any hex char). Is there any other format we must support? Regards, Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From ykaul at redhat.com Mon May 21 07:25:28 2012 From: ykaul at redhat.com (Yaniv Kaul) Date: Mon, 21 May 2012 10:25:28 +0300 Subject: [Engine-devel] MAC address validation In-Reply-To: References: Message-ID: <4FB9EDE8.9060707@redhat.com> On 05/21/2012 10:18 AM, Mike Kolesnik wrote: > Hi, > > We have a bug open on engine to validate MAC address: > https://bugzilla.redhat.com/show_bug.cgi?id=756437 > The format supported by engine (for Ethernet) is FF:FF:FF:FF:FF:FF (F > is any hex char). It's not all F's: I suspect there are some reserved ones which libvirt/qemu won't allow to use (but I never remember which. I suspect 00: ... doesn't work, but I may be wrong). > > Is there any other format we must support? Good timing. See https://bugzilla.redhat.com/show_bug.cgi?id=823397 which was opened a second ago, for Infiniband HCA's MAC address. Y. > > Regards, > Mike > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfediuck at redhat.com Mon May 21 07:58:42 2012 From: dfediuck at redhat.com (Doron Fediuck) Date: Mon, 21 May 2012 10:58:42 +0300 Subject: [Engine-devel] CPU Pinning @engine In-Reply-To: <3818ff2c-7931-4c54-9278-5ceab9790a82@zmail07.collab.prod.int.phx2.redhat.com> References: <3818ff2c-7931-4c54-9278-5ceab9790a82@zmail07.collab.prod.int.phx2.redhat.com> Message-ID: <4FB9F5B2.5000006@redhat.com> On 21/05/12 01:45, Andrew Cathrow wrote: > > > ----- Original Message ----- >> From: "Doron Fediuck" >> To: dlaor at redhat.com >> Cc: engine-devel at ovirt.org >> Sent: Sunday, May 20, 2012 5:49:08 PM >> Subject: Re: [Engine-devel] CPU Pinning @engine >> >> On 20/05/12 21:41, Dor Laor wrote: >>> On 05/17/2012 11:15 PM, Doron Fediuck wrote: >>>> On 17/05/12 20:28, Ayal Baron wrote: >>>>> "Live migration will not be supported for such VM's." >>>>> >>>>> Migration will work on homogeneous clusters so this should not be >>>>> enforced (not limited to VMs which are pinned to host) just give >>>>> a warning. >>>>> >>>> I agree, but if we wish to ping vCPUx to pCPUy in host a, we >>>> cannot ensure to have the same in host b, >>>> since it may have pCPUy too busy, so performance will degrade. >>>> Also, I hope you saw my general comment >>> >>> Performance may degrade on any migration to loaded host regardless >>> of pinning. >>> >>> There is not need to forbid migration. Instead, the SLA assurance >>> policy should verify the dedicated resources and match the target >>> w/ the guarantee and decide according to this. >>> >> Thanks for the input. >> We may start with migration blocked in a configurable manner, so >> people who wish migrate to work >> will simply set the relevant configuration key. >> As for looking for a matched CPU, will add it as p2. > > We shouldn't block migration > If a user wants to not migrate a cpu pinned VM then let them use the non-migratable flag in the UI. > We're not blocking migration, we're allowing pinning (for now) only for non-migrative VM's. For p2 we'll verify destination host has the relevant pinning capacity, which will allow pinning for migrative VM's as well. > >> >>>> about starting with a humble solution and gradually improving. In >>>> this context (auto)numa can help us, >>>> so we better do numa than handle migration for basic mode, risking >>>> performance issues. >>>> >>>>> >>>>> ----- Original Message ----- >>>>>> From: "Doron Fediuck" >>>>>> To: engine-devel at ovirt.org >>>>>> Sent: Thursday, May 17, 2012 2:42:46 PM >>>>>> Subject: [Engine-devel] CPU Pinning @engine >>>>>> >>>>>> Hi All, >>>>>> Currently the VDSM has a CPU pinning hook. >>>>>> We'd like to add better support of it into the engine itself. >>>>>> Here's a design draft to cover it: >>>>>> http://www.ovirt.org/wiki/Features/Design/cpu-pinning >>>>>> >>>>>> Please review and comment if needed. >>>>>> >>>>>> Thanks! >>>>>> -- >>>>>> >>>>>> /d >>>>>> >>>>>> Never say "OOPS!" always say "Ah, Interesting!" >>>>>> _______________________________________________ >>>>>> Engine-devel mailing list >>>>>> Engine-devel at ovirt.org >>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>> >>>>> _______________________________________________ >>>>> Engine-devel mailing list >>>>> Engine-devel at ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>> >>>> >>> >> >> >> -- >> >> /d >> >> Never say "OOPS!" always say "Ah, Interesting!" >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> -- /d "Forty-two," said Deep Thought, with infinite majesty and calm. --Douglas Adams, The Hitchhiker's Guide to the Galaxy From dfediuck at redhat.com Mon May 21 08:00:00 2012 From: dfediuck at redhat.com (Doron Fediuck) Date: Mon, 21 May 2012 11:00:00 +0300 Subject: [Engine-devel] CPU Pinning @engine In-Reply-To: References: Message-ID: <4FB9F600.9000302@redhat.com> On 21/05/12 08:32, Gilad Chaplik wrote: > Hi Doron, > > one suggestion regarding the ui, > we can reuse the key-value widget we did in Custom Properties Sheet (http://www.ovirt.org/wiki/Features/CustomPropertiesSheet) instead of the text box ([vcpu - dropdown][value - textbox][+][-]). > just need to know the number of vcpus (keys in that case). > The vcpu number changes based on the relevant VM, and we should consider a more generic case of vcpu set. So, although the idea is nice, we can't use it. > Thanks, > Gilad. > > ----- Original Message ----- >> From: "Doron Fediuck" >> To: engine-devel at ovirt.org >> Sent: Thursday, May 17, 2012 2:42:46 PM >> Subject: [Engine-devel] CPU Pinning @engine >> >> Hi All, >> Currently the VDSM has a CPU pinning hook. >> We'd like to add better support of it into the engine itself. >> Here's a design draft to cover it: >> http://www.ovirt.org/wiki/Features/Design/cpu-pinning >> >> Please review and comment if needed. >> >> Thanks! >> -- >> >> /d >> >> Never say "OOPS!" always say "Ah, Interesting!" >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> -- /d "Forty-two," said Deep Thought, with infinite majesty and calm. --Douglas Adams, The Hitchhiker's Guide to the Galaxy From dlaor at redhat.com Mon May 21 08:01:58 2012 From: dlaor at redhat.com (Dor Laor) Date: Mon, 21 May 2012 11:01:58 +0300 Subject: [Engine-devel] CPU Pinning @engine In-Reply-To: <4FB9F5B2.5000006@redhat.com> References: <3818ff2c-7931-4c54-9278-5ceab9790a82@zmail07.collab.prod.int.phx2.redhat.com> <4FB9F5B2.5000006@redhat.com> Message-ID: <4FB9F676.2040100@redhat.com> On 05/21/2012 10:58 AM, Doron Fediuck wrote: > On 21/05/12 01:45, Andrew Cathrow wrote: >> >> >> ----- Original Message ----- >>> From: "Doron Fediuck" >>> To: dlaor at redhat.com >>> Cc: engine-devel at ovirt.org >>> Sent: Sunday, May 20, 2012 5:49:08 PM >>> Subject: Re: [Engine-devel] CPU Pinning @engine >>> >>> On 20/05/12 21:41, Dor Laor wrote: >>>> On 05/17/2012 11:15 PM, Doron Fediuck wrote: >>>>> On 17/05/12 20:28, Ayal Baron wrote: >>>>>> "Live migration will not be supported for such VM's." >>>>>> >>>>>> Migration will work on homogeneous clusters so this should not be >>>>>> enforced (not limited to VMs which are pinned to host) just give >>>>>> a warning. >>>>>> >>>>> I agree, but if we wish to ping vCPUx to pCPUy in host a, we >>>>> cannot ensure to have the same in host b, >>>>> since it may have pCPUy too busy, so performance will degrade. >>>>> Also, I hope you saw my general comment >>>> >>>> Performance may degrade on any migration to loaded host regardless >>>> of pinning. >>>> >>>> There is not need to forbid migration. Instead, the SLA assurance >>>> policy should verify the dedicated resources and match the target >>>> w/ the guarantee and decide according to this. >>>> >>> Thanks for the input. >>> We may start with migration blocked in a configurable manner, so >>> people who wish migrate to work >>> will simply set the relevant configuration key. >>> As for looking for a matched CPU, will add it as p2. >> >> We shouldn't block migration >> If a user wants to not migrate a cpu pinned VM then let them use the non-migratable flag in the UI. >> > We're not blocking migration, we're allowing pinning (for now) only for non-migrative VM's. > For p2 we'll verify destination host has the relevant pinning capacity, which will allow > pinning for migrative VM's as well. IMHO the order should be the opposite - if the user likes to migrate a pinned VM, let him (you can pop some message if you like). > >> >>> >>>>> about starting with a humble solution and gradually improving. In >>>>> this context (auto)numa can help us, >>>>> so we better do numa than handle migration for basic mode, risking >>>>> performance issues. >>>>> >>>>>> >>>>>> ----- Original Message ----- >>>>>>> From: "Doron Fediuck" >>>>>>> To: engine-devel at ovirt.org >>>>>>> Sent: Thursday, May 17, 2012 2:42:46 PM >>>>>>> Subject: [Engine-devel] CPU Pinning @engine >>>>>>> >>>>>>> Hi All, >>>>>>> Currently the VDSM has a CPU pinning hook. >>>>>>> We'd like to add better support of it into the engine itself. >>>>>>> Here's a design draft to cover it: >>>>>>> http://www.ovirt.org/wiki/Features/Design/cpu-pinning >>>>>>> >>>>>>> Please review and comment if needed. >>>>>>> >>>>>>> Thanks! >>>>>>> -- >>>>>>> >>>>>>> /d >>>>>>> >>>>>>> Never say "OOPS!" always say "Ah, Interesting!" >>>>>>> _______________________________________________ >>>>>>> Engine-devel mailing list >>>>>>> Engine-devel at ovirt.org >>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>>> >>>>>> _______________________________________________ >>>>>> Engine-devel mailing list >>>>>> Engine-devel at ovirt.org >>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>> >>>>> >>>> >>> >>> >>> -- >>> >>> /d >>> >>> Never say "OOPS!" always say "Ah, Interesting!" >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel at ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> > > From dfediuck at redhat.com Mon May 21 08:08:33 2012 From: dfediuck at redhat.com (Doron Fediuck) Date: Mon, 21 May 2012 11:08:33 +0300 Subject: [Engine-devel] CPU Pinning @engine In-Reply-To: <4FB9F676.2040100@redhat.com> References: <3818ff2c-7931-4c54-9278-5ceab9790a82@zmail07.collab.prod.int.phx2.redhat.com> <4FB9F5B2.5000006@redhat.com> <4FB9F676.2040100@redhat.com> Message-ID: <4FB9F801.6000109@redhat.com> On 21/05/12 11:01, Dor Laor wrote: > On 05/21/2012 10:58 AM, Doron Fediuck wrote: >> On 21/05/12 01:45, Andrew Cathrow wrote: >>> >>> >>> ----- Original Message ----- >>>> From: "Doron Fediuck" >>>> To: dlaor at redhat.com >>>> Cc: engine-devel at ovirt.org >>>> Sent: Sunday, May 20, 2012 5:49:08 PM >>>> Subject: Re: [Engine-devel] CPU Pinning @engine >>>> >>>> On 20/05/12 21:41, Dor Laor wrote: >>>>> On 05/17/2012 11:15 PM, Doron Fediuck wrote: >>>>>> On 17/05/12 20:28, Ayal Baron wrote: >>>>>>> "Live migration will not be supported for such VM's." >>>>>>> >>>>>>> Migration will work on homogeneous clusters so this should not be >>>>>>> enforced (not limited to VMs which are pinned to host) just give >>>>>>> a warning. >>>>>>> >>>>>> I agree, but if we wish to ping vCPUx to pCPUy in host a, we >>>>>> cannot ensure to have the same in host b, >>>>>> since it may have pCPUy too busy, so performance will degrade. >>>>>> Also, I hope you saw my general comment >>>>> >>>>> Performance may degrade on any migration to loaded host regardless >>>>> of pinning. >>>>> >>>>> There is not need to forbid migration. Instead, the SLA assurance >>>>> policy should verify the dedicated resources and match the target >>>>> w/ the guarantee and decide according to this. >>>>> >>>> Thanks for the input. >>>> We may start with migration blocked in a configurable manner, so >>>> people who wish migrate to work >>>> will simply set the relevant configuration key. >>>> As for looking for a matched CPU, will add it as p2. >>> >>> We shouldn't block migration >>> If a user wants to not migrate a cpu pinned VM then let them use the non-migratable flag in the UI. >>> >> We're not blocking migration, we're allowing pinning (for now) only for non-migrative VM's. >> For p2 we'll verify destination host has the relevant pinning capacity, which will allow >> pinning for migrative VM's as well. > > > IMHO the order should be the opposite - if the user likes to migrate a pinned VM, let him (you can pop some message if you like). I'll check it with UI guys (AFAIK engine UI has no pop-ups). Also, I prefer safe than sorry. So start with a safe working pinning for pinned-to-host VMs, and then push the envelope. > >> >>> >>>> >>>>>> about starting with a humble solution and gradually improving. In >>>>>> this context (auto)numa can help us, >>>>>> so we better do numa than handle migration for basic mode, risking >>>>>> performance issues. >>>>>> >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>>> From: "Doron Fediuck" >>>>>>>> To: engine-devel at ovirt.org >>>>>>>> Sent: Thursday, May 17, 2012 2:42:46 PM >>>>>>>> Subject: [Engine-devel] CPU Pinning @engine >>>>>>>> >>>>>>>> Hi All, >>>>>>>> Currently the VDSM has a CPU pinning hook. >>>>>>>> We'd like to add better support of it into the engine itself. >>>>>>>> Here's a design draft to cover it: >>>>>>>> http://www.ovirt.org/wiki/Features/Design/cpu-pinning >>>>>>>> >>>>>>>> Please review and comment if needed. >>>>>>>> >>>>>>>> Thanks! >>>>>>>> -- >>>>>>>> >>>>>>>> /d >>>>>>>> >>>>>>>> Never say "OOPS!" always say "Ah, Interesting!" >>>>>>>> _______________________________________________ >>>>>>>> Engine-devel mailing list >>>>>>>> Engine-devel at ovirt.org >>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Engine-devel mailing list >>>>>>> Engine-devel at ovirt.org >>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> /d >>>> >>>> Never say "OOPS!" always say "Ah, Interesting!" >>>> _______________________________________________ >>>> Engine-devel mailing list >>>> Engine-devel at ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>> >> >> > -- /d "Air conditioned environment - Do NOT open Windows!" From mkenneth at redhat.com Mon May 21 08:08:44 2012 From: mkenneth at redhat.com (Miki Kenneth) Date: Mon, 21 May 2012 04:08:44 -0400 (EDT) Subject: [Engine-devel] CPU Pinning @engine In-Reply-To: <4FB9F676.2040100@redhat.com> Message-ID: <0a1131d8-5c56-41ff-9ae7-3b1f3f43b105@mkenneth.csb> ----- Original Message ----- > From: "Dor Laor" > To: "Doron Fediuck" > Cc: engine-devel at ovirt.org > Sent: Monday, May 21, 2012 11:01:58 AM > Subject: Re: [Engine-devel] CPU Pinning @engine > > On 05/21/2012 10:58 AM, Doron Fediuck wrote: > > On 21/05/12 01:45, Andrew Cathrow wrote: > >> > >> > >> ----- Original Message ----- > >>> From: "Doron Fediuck" > >>> To: dlaor at redhat.com > >>> Cc: engine-devel at ovirt.org > >>> Sent: Sunday, May 20, 2012 5:49:08 PM > >>> Subject: Re: [Engine-devel] CPU Pinning @engine > >>> > >>> On 20/05/12 21:41, Dor Laor wrote: > >>>> On 05/17/2012 11:15 PM, Doron Fediuck wrote: > >>>>> On 17/05/12 20:28, Ayal Baron wrote: > >>>>>> "Live migration will not be supported for such VM's." > >>>>>> > >>>>>> Migration will work on homogeneous clusters so this should not > >>>>>> be > >>>>>> enforced (not limited to VMs which are pinned to host) just > >>>>>> give > >>>>>> a warning. > >>>>>> > >>>>> I agree, but if we wish to ping vCPUx to pCPUy in host a, we > >>>>> cannot ensure to have the same in host b, > >>>>> since it may have pCPUy too busy, so performance will degrade. > >>>>> Also, I hope you saw my general comment > >>>> > >>>> Performance may degrade on any migration to loaded host > >>>> regardless > >>>> of pinning. > >>>> > >>>> There is not need to forbid migration. Instead, the SLA > >>>> assurance > >>>> policy should verify the dedicated resources and match the > >>>> target > >>>> w/ the guarantee and decide according to this. > >>>> > >>> Thanks for the input. > >>> We may start with migration blocked in a configurable manner, so > >>> people who wish migrate to work > >>> will simply set the relevant configuration key. > >>> As for looking for a matched CPU, will add it as p2. > >> > >> We shouldn't block migration > >> If a user wants to not migrate a cpu pinned VM then let them use > >> the non-migratable flag in the UI. > >> > > We're not blocking migration, we're allowing pinning (for now) only > > for non-migrative VM's. > > For p2 we'll verify destination host has the relevant pinning > > capacity, which will allow > > pinning for migrative VM's as well. > > > IMHO the order should be the opposite - if the user likes to migrate > a > pinned VM, let him (you can pop some message if you like). +1. > > > > >> > >>> > >>>>> about starting with a humble solution and gradually improving. > >>>>> In > >>>>> this context (auto)numa can help us, > >>>>> so we better do numa than handle migration for basic mode, > >>>>> risking > >>>>> performance issues. > >>>>> > >>>>>> > >>>>>> ----- Original Message ----- > >>>>>>> From: "Doron Fediuck" > >>>>>>> To: engine-devel at ovirt.org > >>>>>>> Sent: Thursday, May 17, 2012 2:42:46 PM > >>>>>>> Subject: [Engine-devel] CPU Pinning @engine > >>>>>>> > >>>>>>> Hi All, > >>>>>>> Currently the VDSM has a CPU pinning hook. > >>>>>>> We'd like to add better support of it into the engine itself. > >>>>>>> Here's a design draft to cover it: > >>>>>>> http://www.ovirt.org/wiki/Features/Design/cpu-pinning > >>>>>>> > >>>>>>> Please review and comment if needed. > >>>>>>> > >>>>>>> Thanks! > >>>>>>> -- > >>>>>>> > >>>>>>> /d > >>>>>>> > >>>>>>> Never say "OOPS!" always say "Ah, Interesting!" > >>>>>>> _______________________________________________ > >>>>>>> Engine-devel mailing list > >>>>>>> Engine-devel at ovirt.org > >>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > >>>>>>> > >>>>>> _______________________________________________ > >>>>>> Engine-devel mailing list > >>>>>> Engine-devel at ovirt.org > >>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > >>>>> > >>>>> > >>>> > >>> > >>> > >>> -- > >>> > >>> /d > >>> > >>> Never say "OOPS!" always say "Ah, Interesting!" > >>> _______________________________________________ > >>> Engine-devel mailing list > >>> Engine-devel at ovirt.org > >>> http://lists.ovirt.org/mailman/listinfo/engine-devel > >>> > > > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From ykaul at redhat.com Mon May 21 08:16:45 2012 From: ykaul at redhat.com (Yaniv Kaul) Date: Mon, 21 May 2012 11:16:45 +0300 Subject: [Engine-devel] CPU Pinning @engine In-Reply-To: <4FB9F801.6000109@redhat.com> References: <3818ff2c-7931-4c54-9278-5ceab9790a82@zmail07.collab.prod.int.phx2.redhat.com> <4FB9F5B2.5000006@redhat.com> <4FB9F676.2040100@redhat.com> <4FB9F801.6000109@redhat.com> Message-ID: <4FB9F9ED.7000709@redhat.com> On 05/21/2012 11:08 AM, Doron Fediuck wrote: > On 21/05/12 11:01, Dor Laor wrote: >> On 05/21/2012 10:58 AM, Doron Fediuck wrote: >>> On 21/05/12 01:45, Andrew Cathrow wrote: >>>> >>>> ----- Original Message ----- >>>>> From: "Doron Fediuck" >>>>> To: dlaor at redhat.com >>>>> Cc: engine-devel at ovirt.org >>>>> Sent: Sunday, May 20, 2012 5:49:08 PM >>>>> Subject: Re: [Engine-devel] CPU Pinning @engine >>>>> >>>>> On 20/05/12 21:41, Dor Laor wrote: >>>>>> On 05/17/2012 11:15 PM, Doron Fediuck wrote: >>>>>>> On 17/05/12 20:28, Ayal Baron wrote: >>>>>>>> "Live migration will not be supported for such VM's." >>>>>>>> >>>>>>>> Migration will work on homogeneous clusters so this should not be >>>>>>>> enforced (not limited to VMs which are pinned to host) just give >>>>>>>> a warning. >>>>>>>> >>>>>>> I agree, but if we wish to ping vCPUx to pCPUy in host a, we >>>>>>> cannot ensure to have the same in host b, >>>>>>> since it may have pCPUy too busy, so performance will degrade. >>>>>>> Also, I hope you saw my general comment >>>>>> Performance may degrade on any migration to loaded host regardless >>>>>> of pinning. >>>>>> >>>>>> There is not need to forbid migration. Instead, the SLA assurance >>>>>> policy should verify the dedicated resources and match the target >>>>>> w/ the guarantee and decide according to this. >>>>>> >>>>> Thanks for the input. >>>>> We may start with migration blocked in a configurable manner, so >>>>> people who wish migrate to work >>>>> will simply set the relevant configuration key. >>>>> As for looking for a matched CPU, will add it as p2. >>>> We shouldn't block migration >>>> If a user wants to not migrate a cpu pinned VM then let them use the non-migratable flag in the UI. >>>> >>> We're not blocking migration, we're allowing pinning (for now) only for non-migrative VM's. >>> For p2 we'll verify destination host has the relevant pinning capacity, which will allow >>> pinning for migrative VM's as well. >> >> IMHO the order should be the opposite - if the user likes to migrate a pinned VM, let him (you can pop some message if you like). > I'll check it with UI guys (AFAIK engine UI has no pop-ups). > Also, I prefer safe than sorry. So start with a safe working pinning for pinned-to-host VMs, and then push the envelope. Safe is letting the user migrate. It may or may not succeed (I'd worry it may put a host into Error state - I hope we've removed this state). Sorry is when you wish you had done so initially. ;-) Y. > >>>>>>> about starting with a humble solution and gradually improving. In >>>>>>> this context (auto)numa can help us, >>>>>>> so we better do numa than handle migration for basic mode, risking >>>>>>> performance issues. >>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>>> From: "Doron Fediuck" >>>>>>>>> To: engine-devel at ovirt.org >>>>>>>>> Sent: Thursday, May 17, 2012 2:42:46 PM >>>>>>>>> Subject: [Engine-devel] CPU Pinning @engine >>>>>>>>> >>>>>>>>> Hi All, >>>>>>>>> Currently the VDSM has a CPU pinning hook. >>>>>>>>> We'd like to add better support of it into the engine itself. >>>>>>>>> Here's a design draft to cover it: >>>>>>>>> http://www.ovirt.org/wiki/Features/Design/cpu-pinning >>>>>>>>> >>>>>>>>> Please review and comment if needed. >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> -- >>>>>>>>> >>>>>>>>> /d >>>>>>>>> >>>>>>>>> Never say "OOPS!" always say "Ah, Interesting!" >>>>>>>>> _______________________________________________ >>>>>>>>> Engine-devel mailing list >>>>>>>>> Engine-devel at ovirt.org >>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Engine-devel mailing list >>>>>>>> Engine-devel at ovirt.org >>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>>> >>>>> >>>>> -- >>>>> >>>>> /d >>>>> >>>>> Never say "OOPS!" always say "Ah, Interesting!" >>>>> _______________________________________________ >>>>> Engine-devel mailing list >>>>> Engine-devel at ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>> >>> > From dfediuck at redhat.com Mon May 21 08:53:39 2012 From: dfediuck at redhat.com (Doron Fediuck) Date: Mon, 21 May 2012 11:53:39 +0300 Subject: [Engine-devel] CPU Pinning @engine In-Reply-To: <4FB9F9ED.7000709@redhat.com> References: <3818ff2c-7931-4c54-9278-5ceab9790a82@zmail07.collab.prod.int.phx2.redhat.com> <4FB9F5B2.5000006@redhat.com> <4FB9F676.2040100@redhat.com> <4FB9F801.6000109@redhat.com> <4FB9F9ED.7000709@redhat.com> Message-ID: <4FBA0293.6000402@redhat.com> On 21/05/12 11:16, Yaniv Kaul wrote: > On 05/21/2012 11:08 AM, Doron Fediuck wrote: >> On 21/05/12 11:01, Dor Laor wrote: >>> On 05/21/2012 10:58 AM, Doron Fediuck wrote: >>>> On 21/05/12 01:45, Andrew Cathrow wrote: >>>>> >>>>> ----- Original Message ----- >>>>>> From: "Doron Fediuck" >>>>>> To: dlaor at redhat.com >>>>>> Cc: engine-devel at ovirt.org >>>>>> Sent: Sunday, May 20, 2012 5:49:08 PM >>>>>> Subject: Re: [Engine-devel] CPU Pinning @engine >>>>>> >>>>>> On 20/05/12 21:41, Dor Laor wrote: >>>>>>> On 05/17/2012 11:15 PM, Doron Fediuck wrote: >>>>>>>> On 17/05/12 20:28, Ayal Baron wrote: >>>>>>>>> "Live migration will not be supported for such VM's." >>>>>>>>> >>>>>>>>> Migration will work on homogeneous clusters so this should not be >>>>>>>>> enforced (not limited to VMs which are pinned to host) just give >>>>>>>>> a warning. >>>>>>>>> >>>>>>>> I agree, but if we wish to ping vCPUx to pCPUy in host a, we >>>>>>>> cannot ensure to have the same in host b, >>>>>>>> since it may have pCPUy too busy, so performance will degrade. >>>>>>>> Also, I hope you saw my general comment >>>>>>> Performance may degrade on any migration to loaded host regardless >>>>>>> of pinning. >>>>>>> >>>>>>> There is not need to forbid migration. Instead, the SLA assurance >>>>>>> policy should verify the dedicated resources and match the target >>>>>>> w/ the guarantee and decide according to this. >>>>>>> >>>>>> Thanks for the input. >>>>>> We may start with migration blocked in a configurable manner, so >>>>>> people who wish migrate to work >>>>>> will simply set the relevant configuration key. >>>>>> As for looking for a matched CPU, will add it as p2. >>>>> We shouldn't block migration >>>>> If a user wants to not migrate a cpu pinned VM then let them use the non-migratable flag in the UI. >>>>> >>>> We're not blocking migration, we're allowing pinning (for now) only for non-migrative VM's. >>>> For p2 we'll verify destination host has the relevant pinning capacity, which will allow >>>> pinning for migrative VM's as well. >>> >>> IMHO the order should be the opposite - if the user likes to migrate a pinned VM, let him (you can pop some message if you like). >> I'll check it with UI guys (AFAIK engine UI has no pop-ups). >> Also, I prefer safe than sorry. So start with a safe working pinning for pinned-to-host VMs, and then push the envelope. > > Safe is letting the user migrate. It may or may not succeed (I'd worry it may put a host into Error state - I hope we've removed this state). This is a pure speculation. If I'm pinning a specific VM to a specific host, and its vCPUS into specific pCPUs, how can live migration be considered a safe thing? If I pinned to host, this is a violation of my request. Now, let's say I didn't pin to host, but I ask for specific vCPUS pinning into specific pCPUs. For now, there's no guarantee the destination host will have a relevant CPU capacity (maybe even topology), so CPU pinning may not work, which is also a violation of my request. Is live migration really the safe thing to do here??? Why not alert me so I could manually migrate to where I think is better? Having that said, I'm reminding you the somewhere earlier in this thread I wrote we'll make the constraint of cpu pinning allowed only on pinned-to-host VMs configurable, so people who wish to walk on wild side, can give it a go. > Sorry is when you wish you had done so initially. ;-) In this case, I disagree as this is configurable. > Y. > > >> >>>>>>>> about starting with a humble solution and gradually improving. In >>>>>>>> this context (auto)numa can help us, >>>>>>>> so we better do numa than handle migration for basic mode, risking >>>>>>>> performance issues. >>>>>>>> >>>>>>>>> ----- Original Message ----- >>>>>>>>>> From: "Doron Fediuck" >>>>>>>>>> To: engine-devel at ovirt.org >>>>>>>>>> Sent: Thursday, May 17, 2012 2:42:46 PM >>>>>>>>>> Subject: [Engine-devel] CPU Pinning @engine >>>>>>>>>> >>>>>>>>>> Hi All, >>>>>>>>>> Currently the VDSM has a CPU pinning hook. >>>>>>>>>> We'd like to add better support of it into the engine itself. >>>>>>>>>> Here's a design draft to cover it: >>>>>>>>>> http://www.ovirt.org/wiki/Features/Design/cpu-pinning >>>>>>>>>> >>>>>>>>>> Please review and comment if needed. >>>>>>>>>> >>>>>>>>>> Thanks! >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>>> /d >>>>>>>>>> >>>>>>>>>> Never say "OOPS!" always say "Ah, Interesting!" >>>>>>>>>> _______________________________________________ >>>>>>>>>> Engine-devel mailing list >>>>>>>>>> Engine-devel at ovirt.org >>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Engine-devel mailing list >>>>>>>>> Engine-devel at ovirt.org >>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> /d >>>>>> >>>>>> Never say "OOPS!" always say "Ah, Interesting!" >>>>>> _______________________________________________ >>>>>> Engine-devel mailing list >>>>>> Engine-devel at ovirt.org >>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>> >>>> >> > -- /d Why doesn't DOS ever say "EXCELLENT command or filename!" From ykaul at redhat.com Mon May 21 09:18:29 2012 From: ykaul at redhat.com (Yaniv Kaul) Date: Mon, 21 May 2012 12:18:29 +0300 Subject: [Engine-devel] CPU Pinning @engine In-Reply-To: <4FBA0293.6000402@redhat.com> References: <3818ff2c-7931-4c54-9278-5ceab9790a82@zmail07.collab.prod.int.phx2.redhat.com> <4FB9F5B2.5000006@redhat.com> <4FB9F676.2040100@redhat.com> <4FB9F801.6000109@redhat.com> <4FB9F9ED.7000709@redhat.com> <4FBA0293.6000402@redhat.com> Message-ID: <4FBA0865.9000100@redhat.com> On 05/21/2012 11:53 AM, Doron Fediuck wrote: > On 21/05/12 11:16, Yaniv Kaul wrote: >> On 05/21/2012 11:08 AM, Doron Fediuck wrote: >>> On 21/05/12 11:01, Dor Laor wrote: >>>> On 05/21/2012 10:58 AM, Doron Fediuck wrote: >>>>> On 21/05/12 01:45, Andrew Cathrow wrote: >>>>>> ----- Original Message ----- >>>>>>> From: "Doron Fediuck" >>>>>>> To: dlaor at redhat.com >>>>>>> Cc: engine-devel at ovirt.org >>>>>>> Sent: Sunday, May 20, 2012 5:49:08 PM >>>>>>> Subject: Re: [Engine-devel] CPU Pinning @engine >>>>>>> >>>>>>> On 20/05/12 21:41, Dor Laor wrote: >>>>>>>> On 05/17/2012 11:15 PM, Doron Fediuck wrote: >>>>>>>>> On 17/05/12 20:28, Ayal Baron wrote: >>>>>>>>>> "Live migration will not be supported for such VM's." >>>>>>>>>> >>>>>>>>>> Migration will work on homogeneous clusters so this should not be >>>>>>>>>> enforced (not limited to VMs which are pinned to host) just give >>>>>>>>>> a warning. >>>>>>>>>> >>>>>>>>> I agree, but if we wish to ping vCPUx to pCPUy in host a, we >>>>>>>>> cannot ensure to have the same in host b, >>>>>>>>> since it may have pCPUy too busy, so performance will degrade. >>>>>>>>> Also, I hope you saw my general comment >>>>>>>> Performance may degrade on any migration to loaded host regardless >>>>>>>> of pinning. >>>>>>>> >>>>>>>> There is not need to forbid migration. Instead, the SLA assurance >>>>>>>> policy should verify the dedicated resources and match the target >>>>>>>> w/ the guarantee and decide according to this. >>>>>>>> >>>>>>> Thanks for the input. >>>>>>> We may start with migration blocked in a configurable manner, so >>>>>>> people who wish migrate to work >>>>>>> will simply set the relevant configuration key. >>>>>>> As for looking for a matched CPU, will add it as p2. >>>>>> We shouldn't block migration >>>>>> If a user wants to not migrate a cpu pinned VM then let them use the non-migratable flag in the UI. >>>>>> >>>>> We're not blocking migration, we're allowing pinning (for now) only for non-migrative VM's. >>>>> For p2 we'll verify destination host has the relevant pinning capacity, which will allow >>>>> pinning for migrative VM's as well. >>>> IMHO the order should be the opposite - if the user likes to migrate a pinned VM, let him (you can pop some message if you like). >>> I'll check it with UI guys (AFAIK engine UI has no pop-ups). >>> Also, I prefer safe than sorry. So start with a safe working pinning for pinned-to-host VMs, and then push the envelope. >> Safe is letting the user migrate. It may or may not succeed (I'd worry it may put a host into Error state - I hope we've removed this state). > This is a pure speculation. If I'm pinning a specific VM to a specific host, and its vCPUS into specific pCPUs, > how can live migration be considered a safe thing? If I pinned to host, this is a violation of my request. Now, let's say > I didn't pin to host, but I ask for specific vCPUS pinning into specific pCPUs. For now, there's no guarantee the destination > host will have a relevant CPU capacity (maybe even topology), so CPU pinning may not work, which is also a violation of > my request. Is live migration really the safe thing to do here??? Why not alert me so I could manually migrate to where I think > is better? > Having that said, I'm reminding you the somewhere earlier in this thread I wrote we'll make the constraint of cpu pinning > allowed only on pinned-to-host VMs configurable, so people who wish to walk on wild side, can give it a go. I think the consensus of the thread is that you should allow pin vCPUs to pCPUs even if the VM is not pinned to host. If the user wants to ensure it will not migrate, he should mark the VM as non migratable. Otherwise, it may migrate, and will succeed - if it can meet the same pinning requirements on the destination, or fail - and then no harm done. If migration succeeds without meeting the pinning requirements on the destination, I see this as a libvirt bug. Y. > >> Sorry is when you wish you had done so initially. ;-) > In this case, I disagree as this is configurable. > >> Y. >> >> >>>>>>>>> about starting with a humble solution and gradually improving. In >>>>>>>>> this context (auto)numa can help us, >>>>>>>>> so we better do numa than handle migration for basic mode, risking >>>>>>>>> performance issues. >>>>>>>>> >>>>>>>>>> ----- Original Message ----- >>>>>>>>>>> From: "Doron Fediuck" >>>>>>>>>>> To: engine-devel at ovirt.org >>>>>>>>>>> Sent: Thursday, May 17, 2012 2:42:46 PM >>>>>>>>>>> Subject: [Engine-devel] CPU Pinning @engine >>>>>>>>>>> >>>>>>>>>>> Hi All, >>>>>>>>>>> Currently the VDSM has a CPU pinning hook. >>>>>>>>>>> We'd like to add better support of it into the engine itself. >>>>>>>>>>> Here's a design draft to cover it: >>>>>>>>>>> http://www.ovirt.org/wiki/Features/Design/cpu-pinning >>>>>>>>>>> >>>>>>>>>>> Please review and comment if needed. >>>>>>>>>>> >>>>>>>>>>> Thanks! >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>>> /d >>>>>>>>>>> >>>>>>>>>>> Never say "OOPS!" always say "Ah, Interesting!" >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Engine-devel mailing list >>>>>>>>>>> Engine-devel at ovirt.org >>>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Engine-devel mailing list >>>>>>>>>> Engine-devel at ovirt.org >>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>>> -- >>>>>>> >>>>>>> /d >>>>>>> >>>>>>> Never say "OOPS!" always say "Ah, Interesting!" >>>>>>> _______________________________________________ >>>>>>> Engine-devel mailing list >>>>>>> Engine-devel at ovirt.org >>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>>> > From dfediuck at redhat.com Mon May 21 09:40:33 2012 From: dfediuck at redhat.com (Doron Fediuck) Date: Mon, 21 May 2012 12:40:33 +0300 Subject: [Engine-devel] CPU Pinning @engine In-Reply-To: <4FBA0865.9000100@redhat.com> References: <3818ff2c-7931-4c54-9278-5ceab9790a82@zmail07.collab.prod.int.phx2.redhat.com> <4FB9F5B2.5000006@redhat.com> <4FB9F676.2040100@redhat.com> <4FB9F801.6000109@redhat.com> <4FB9F9ED.7000709@redhat.com> <4FBA0293.6000402@redhat.com> <4FBA0865.9000100@redhat.com> Message-ID: <4FBA0D91.3010905@redhat.com> On 21/05/12 12:18, Yaniv Kaul wrote: > On 05/21/2012 11:53 AM, Doron Fediuck wrote: >> On 21/05/12 11:16, Yaniv Kaul wrote: >>> On 05/21/2012 11:08 AM, Doron Fediuck wrote: >>>> On 21/05/12 11:01, Dor Laor wrote: >>>>> On 05/21/2012 10:58 AM, Doron Fediuck wrote: >>>>>> On 21/05/12 01:45, Andrew Cathrow wrote: >>>>>>> ----- Original Message ----- >>>>>>>> From: "Doron Fediuck" >>>>>>>> To: dlaor at redhat.com >>>>>>>> Cc: engine-devel at ovirt.org >>>>>>>> Sent: Sunday, May 20, 2012 5:49:08 PM >>>>>>>> Subject: Re: [Engine-devel] CPU Pinning @engine >>>>>>>> >>>>>>>> On 20/05/12 21:41, Dor Laor wrote: >>>>>>>>> On 05/17/2012 11:15 PM, Doron Fediuck wrote: >>>>>>>>>> On 17/05/12 20:28, Ayal Baron wrote: >>>>>>>>>>> "Live migration will not be supported for such VM's." >>>>>>>>>>> >>>>>>>>>>> Migration will work on homogeneous clusters so this should not be >>>>>>>>>>> enforced (not limited to VMs which are pinned to host) just give >>>>>>>>>>> a warning. >>>>>>>>>>> >>>>>>>>>> I agree, but if we wish to ping vCPUx to pCPUy in host a, we >>>>>>>>>> cannot ensure to have the same in host b, >>>>>>>>>> since it may have pCPUy too busy, so performance will degrade. >>>>>>>>>> Also, I hope you saw my general comment >>>>>>>>> Performance may degrade on any migration to loaded host regardless >>>>>>>>> of pinning. >>>>>>>>> >>>>>>>>> There is not need to forbid migration. Instead, the SLA assurance >>>>>>>>> policy should verify the dedicated resources and match the target >>>>>>>>> w/ the guarantee and decide according to this. >>>>>>>>> >>>>>>>> Thanks for the input. >>>>>>>> We may start with migration blocked in a configurable manner, so >>>>>>>> people who wish migrate to work >>>>>>>> will simply set the relevant configuration key. >>>>>>>> As for looking for a matched CPU, will add it as p2. >>>>>>> We shouldn't block migration >>>>>>> If a user wants to not migrate a cpu pinned VM then let them use the non-migratable flag in the UI. >>>>>>> >>>>>> We're not blocking migration, we're allowing pinning (for now) only for non-migrative VM's. >>>>>> For p2 we'll verify destination host has the relevant pinning capacity, which will allow >>>>>> pinning for migrative VM's as well. >>>>> IMHO the order should be the opposite - if the user likes to migrate a pinned VM, let him (you can pop some message if you like). >>>> I'll check it with UI guys (AFAIK engine UI has no pop-ups). >>>> Also, I prefer safe than sorry. So start with a safe working pinning for pinned-to-host VMs, and then push the envelope. >>> Safe is letting the user migrate. It may or may not succeed (I'd worry it may put a host into Error state - I hope we've removed this state). >> This is a pure speculation. If I'm pinning a specific VM to a specific host, and its vCPUS into specific pCPUs, >> how can live migration be considered a safe thing? If I pinned to host, this is a violation of my request. Now, let's say >> I didn't pin to host, but I ask for specific vCPUS pinning into specific pCPUs. For now, there's no guarantee the destination >> host will have a relevant CPU capacity (maybe even topology), so CPU pinning may not work, which is also a violation of >> my request. Is live migration really the safe thing to do here??? Why not alert me so I could manually migrate to where I think >> is better? >> Having that said, I'm reminding you the somewhere earlier in this thread I wrote we'll make the constraint of cpu pinning >> allowed only on pinned-to-host VMs configurable, so people who wish to walk on wild side, can give it a go. > > I think the consensus of the thread is that you should allow pin vCPUs to pCPUs even if the VM is not pinned to host. > If the user wants to ensure it will not migrate, he should mark the VM as non migratable. > Otherwise, it may migrate, and will succeed - if it can meet the same pinning requirements on the destination, or fail - and then no harm done. > If migration succeeds without meeting the pinning requirements on the destination, I see this as a libvirt bug. > Y. Basically I already said cpu-pin is allowed for migrative VM's once configuring it. So basically what you're saying is that if such migration works, while loosing cpu-pin, it's a libvirt bug. I can live with that. I hope Daniel agrees with you. > >> >>> Sorry is when you wish you had done so initially. ;-) >> In this case, I disagree as this is configurable. >> >>> Y. >>> >>> >>>>>>>>>> about starting with a humble solution and gradually improving. In >>>>>>>>>> this context (auto)numa can help us, >>>>>>>>>> so we better do numa than handle migration for basic mode, risking >>>>>>>>>> performance issues. >>>>>>>>>> >>>>>>>>>>> ----- Original Message ----- >>>>>>>>>>>> From: "Doron Fediuck" >>>>>>>>>>>> To: engine-devel at ovirt.org >>>>>>>>>>>> Sent: Thursday, May 17, 2012 2:42:46 PM >>>>>>>>>>>> Subject: [Engine-devel] CPU Pinning @engine >>>>>>>>>>>> >>>>>>>>>>>> Hi All, >>>>>>>>>>>> Currently the VDSM has a CPU pinning hook. >>>>>>>>>>>> We'd like to add better support of it into the engine itself. >>>>>>>>>>>> Here's a design draft to cover it: >>>>>>>>>>>> http://www.ovirt.org/wiki/Features/Design/cpu-pinning >>>>>>>>>>>> >>>>>>>>>>>> Please review and comment if needed. >>>>>>>>>>>> >>>>>>>>>>>> Thanks! >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>> /d >>>>>>>>>>>> >>>>>>>>>>>> Never say "OOPS!" always say "Ah, Interesting!" >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Engine-devel mailing list >>>>>>>>>>>> Engine-devel at ovirt.org >>>>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Engine-devel mailing list >>>>>>>>>>> Engine-devel at ovirt.org >>>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>>>> -- >>>>>>>> >>>>>>>> /d >>>>>>>> >>>>>>>> Never say "OOPS!" always say "Ah, Interesting!" >>>>>>>> _______________________________________________ >>>>>>>> Engine-devel mailing list >>>>>>>> Engine-devel at ovirt.org >>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>>>> >> > -- /d "The answer, my friend, is blowing in the wind" --Bob Dylan, Blowin' in the Wind (1963) From emesika at redhat.com Mon May 21 09:43:45 2012 From: emesika at redhat.com (Eli Mesika) Date: Mon, 21 May 2012 05:43:45 -0400 (EDT) Subject: [Engine-devel] MAC address validation In-Reply-To: Message-ID: <5067c4a2-ca13-4744-8c19-b1c057587fce@zmail13.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Mike Kolesnik" > To: "engine-devel" > Sent: Monday, May 21, 2012 10:18:30 AM > Subject: [Engine-devel] MAC address validation > > > > Hi, > > We have a bug open on engine to validate MAC address: > https://bugzilla.redhat.com/show_bug.cgi?id=756437 > The format supported by engine (for Ethernet) is FF:FF:FF:FF:FF:FF (F > is any hex char). > > Is there any other format we must support? IMHO we should support also the '-' delimiter (i.e. FF-FF-FF-FF-FF-FF). (See IEEE 802 standard) > > > Regards, > Mike > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From gkotton at redhat.com Mon May 21 09:45:00 2012 From: gkotton at redhat.com (Gary Kotton) Date: Mon, 21 May 2012 12:45:00 +0300 Subject: [Engine-devel] MAC address validation In-Reply-To: <5067c4a2-ca13-4744-8c19-b1c057587fce@zmail13.collab.prod.int.phx2.redhat.com> References: <5067c4a2-ca13-4744-8c19-b1c057587fce@zmail13.collab.prod.int.phx2.redhat.com> Message-ID: <4FBA0E9C.90808@redhat.com> On 05/21/2012 12:43 PM, Eli Mesika wrote: > > ----- Original Message ----- >> From: "Mike Kolesnik" >> To: "engine-devel" >> Sent: Monday, May 21, 2012 10:18:30 AM >> Subject: [Engine-devel] MAC address validation >> >> >> >> Hi, >> >> We have a bug open on engine to validate MAC address: >> https://bugzilla.redhat.com/show_bug.cgi?id=756437 >> The format supported by engine (for Ethernet) is FF:FF:FF:FF:FF:FF (F >> is any hex char). >> >> Is there any other format we must support? > > IMHO we should support also the '-' delimiter (i.e. FF-FF-FF-FF-FF-FF). > (See IEEE 802 standard) The A-F can also be lowercase > >> >> Regards, >> Mike >> >> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From ecohen at redhat.com Mon May 21 10:34:32 2012 From: ecohen at redhat.com (Einav Cohen) Date: Mon, 21 May 2012 06:34:32 -0400 (EDT) Subject: [Engine-devel] Advanced Nfs Options + NFSv4 GUI mockup In-Reply-To: <669e3a76-e65c-49df-8c4e-125945cf14ee@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4bed8708-cd0c-49fe-85db-8d2e46929461@zmail04.collab.prod.int.phx2.redhat.com> Please review the mock-up on the feature page: http://www.ovirt.org/wiki/Features/AdvancedNfsOptions#User_Experience Comments are welcome. ---- Thanks, Einav From gjansen at redhat.com Mon May 21 10:40:40 2012 From: gjansen at redhat.com (Geert Jansen) Date: Mon, 21 May 2012 12:40:40 +0200 Subject: [Engine-devel] Advanced Nfs Options + NFSv4 GUI mockup In-Reply-To: <4bed8708-cd0c-49fe-85db-8d2e46929461@zmail04.collab.prod.int.phx2.redhat.com> References: <4bed8708-cd0c-49fe-85db-8d2e46929461@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4FBA1BA8.9060508@redhat.com> Hi, On 05/21/2012 12:34 PM, Einav Cohen wrote: > Please review the mock-up on the feature page: > http://www.ovirt.org/wiki/Features/AdvancedNfsOptions#User_Experience > > Comments are welcome. i was wondering why you have pulled out retrans and timeout? Are these the most important ones? Regards, Geert From ecohen at redhat.com Mon May 21 10:44:40 2012 From: ecohen at redhat.com (Einav Cohen) Date: Mon, 21 May 2012 06:44:40 -0400 (EDT) Subject: [Engine-devel] Advanced Nfs Options + NFSv4 GUI mockup In-Reply-To: <4FBA1BA8.9060508@redhat.com> Message-ID: <33ac9555-6b14-435c-850a-bd79707d4613@zmail04.collab.prod.int.phx2.redhat.com> > ----- Original Message ----- > From: "Geert Jansen" > Sent: Monday, May 21, 2012 1:40:40 PM > > Hi, > > On 05/21/2012 12:34 PM, Einav Cohen wrote: > > Please review the mock-up on the feature page: > > http://www.ovirt.org/wiki/Features/AdvancedNfsOptions#User_Experience > > > > Comments are welcome. > > i was wondering why you have pulled out retrans and timeout? Are > these > the most important ones? Sorry - not sure I got you. Can you please clarify your question? > > Regards, > Geert > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > From elad at tonian.com Mon May 21 10:44:31 2012 From: elad at tonian.com (Elad Tabak) Date: Mon, 21 May 2012 13:44:31 +0300 Subject: [Engine-devel] Engine DB - user locked Message-ID: Hi, After an attempt to clear the DB by running './create_db_devel.sh -u postgres', I got an error: *Failed to create database engine* I then run 'dropdb -U postgres engine', and then 'create_db_devel.sh' again, but still I get the same error. When I tried to login from the admin web interface, I get authentication error. This is from the jboss log: USER_FAILED_TO_AUTHENTICATE_ACCOUNT_IS_LOCKED_OR_DISABLED I also tried running './create_db_devel.sh -u postgres -d engine_new', but it gives the same error ("Failed to create database engine_new"). I tried restarting the posgresql service, it didn't help. Please advice. Thanks, Elad -------------- next part -------------- An HTML attachment was scrubbed... URL: From yzaslavs at redhat.com Mon May 21 10:49:57 2012 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Mon, 21 May 2012 13:49:57 +0300 Subject: [Engine-devel] Advanced Nfs Options + NFSv4 GUI mockup In-Reply-To: <4bed8708-cd0c-49fe-85db-8d2e46929461@zmail04.collab.prod.int.phx2.redhat.com> References: <4bed8708-cd0c-49fe-85db-8d2e46929461@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4FBA1DD5.6070106@redhat.com> On 05/21/2012 01:34 PM, Einav Cohen wrote: > Please review the mock-up on the feature page: > http://www.ovirt.org/wiki/Features/AdvancedNfsOptions#User_Experience > > Comments are welcome. Very minor comment - IMHO Retrans and Timeo should be bigger than 0. > > ---- > Thanks, > Einav > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From yzaslavs at redhat.com Mon May 21 10:50:35 2012 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Mon, 21 May 2012 13:50:35 +0300 Subject: [Engine-devel] Engine DB - user locked In-Reply-To: References: Message-ID: <4FBA1DFB.4010504@redhat.com> On 05/21/2012 01:44 PM, Elad Tabak wrote: > Hi, > After an attempt to clear the DB by running './create_db_devel.sh -u > postgres', I got an error: > *Failed to create database engine* > I then run 'dropdb -U postgres engine', and then 'create_db_devel.sh' > again, but still I get the same error. > When I tried to login from the admin web interface, I get authentication > error. This is from the jboss log: > USER_FAILED_TO_AUTHENTICATE_ACCOUNT_IS_LOCKED_OR_DISABLED > > I also tried running './create_db_devel.sh -u postgres -d engine_new', > but it gives the same error ("Failed to create database engine_new"). > I tried restarting the posgresql service, it didn't help. > > Please advice. > > Thanks, > Elad Elad - are you trying to authenticate with Active directory? Kind regards, Yair > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From mkenneth at redhat.com Mon May 21 10:49:10 2012 From: mkenneth at redhat.com (Miki Kenneth) Date: Mon, 21 May 2012 06:49:10 -0400 (EDT) Subject: [Engine-devel] MAC address validation In-Reply-To: <4FBA0E9C.90808@redhat.com> Message-ID: the most common delimiters are : and - delimiters. I don't recall any other delimiter needed. for the values: hexa-characters (lower and upper case). ----- Original Message ----- > From: "Gary Kotton" > To: engine-devel at ovirt.org > Sent: Monday, May 21, 2012 12:45:00 PM > Subject: Re: [Engine-devel] MAC address validation > > > On 05/21/2012 12:43 PM, Eli Mesika wrote: > > > > ----- Original Message ----- > >> From: "Mike Kolesnik" > >> To: "engine-devel" > >> Sent: Monday, May 21, 2012 10:18:30 AM > >> Subject: [Engine-devel] MAC address validation > >> > >> > >> > >> Hi, > >> > >> We have a bug open on engine to validate MAC address: > >> https://bugzilla.redhat.com/show_bug.cgi?id=756437 > >> The format supported by engine (for Ethernet) is FF:FF:FF:FF:FF:FF > >> (F > >> is any hex char). > >> > >> Is there any other format we must support? > > > > IMHO we should support also the '-' delimiter (i.e. > > FF-FF-FF-FF-FF-FF). > > (See IEEE 802 standard) > The A-F can also be lowercase > > > >> > >> Regards, > >> Mike > >> > >> > >> _______________________________________________ > >> Engine-devel mailing list > >> Engine-devel at ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/engine-devel > >> > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From mkenneth at redhat.com Mon May 21 10:54:25 2012 From: mkenneth at redhat.com (Miki Kenneth) Date: Mon, 21 May 2012 06:54:25 -0400 (EDT) Subject: [Engine-devel] Advanced Nfs Options + NFSv4 GUI mockup In-Reply-To: <4bed8708-cd0c-49fe-85db-8d2e46929461@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <683da088-59c5-450f-90ee-e5d319526fb2@mkenneth.csb> Need to have units on the Retrans and Timout. Is tooltip will be available with the correct values? ----- Original Message ----- > From: "Einav Cohen" > To: "Ayal Baron" , "Eldan Hildesheim" , "Eldan Hildesheim" > , "Miki Kenneth" , "Andrew Cathrow" , "Simon Grinberg" > , "Alexey Chub" > Cc: engine-devel at ovirt.org > Sent: Monday, May 21, 2012 1:34:32 PM > Subject: Advanced Nfs Options + NFSv4 GUI mockup > > Please review the mock-up on the feature page: > http://www.ovirt.org/wiki/Features/AdvancedNfsOptions#User_Experience > > Comments are welcome. > > ---- > Thanks, > Einav > From ecohen at redhat.com Mon May 21 11:00:11 2012 From: ecohen at redhat.com (Einav Cohen) Date: Mon, 21 May 2012 07:00:11 -0400 (EDT) Subject: [Engine-devel] Advanced Nfs Options + NFSv4 GUI mockup In-Reply-To: <4FBA1DD5.6070106@redhat.com> Message-ID: > ----- Original Message ----- > From: "Yair Zaslavsky" > Sent: Monday, May 21, 2012 1:49:57 PM > > On 05/21/2012 01:34 PM, Einav Cohen wrote: > > Please review the mock-up on the feature page: > > http://www.ovirt.org/wiki/Features/AdvancedNfsOptions#User_Experience > > > > Comments are welcome. > > Very minor comment - IMHO Retrans and Timeo should be bigger than 0. Timeout - right. Retrans - not sure; Ayal? > > > > > ---- > > Thanks, > > Einav > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From ecohen at redhat.com Mon May 21 11:09:42 2012 From: ecohen at redhat.com (Einav Cohen) Date: Mon, 21 May 2012 07:09:42 -0400 (EDT) Subject: [Engine-devel] Advanced Nfs Options + NFSv4 GUI mockup In-Reply-To: <683da088-59c5-450f-90ee-e5d319526fb2@mkenneth.csb> Message-ID: <6995312f-9451-4009-92ba-e8233a1b0139@zmail04.collab.prod.int.phx2.redhat.com> > ----- Original Message ----- > From: "Miki Kenneth" > Sent: Monday, May 21, 2012 1:54:25 PM > > Need to have units on the Retrans and Timout. > Is tooltip will be available with the correct values? Retrans doesn't have units. Timeout should be in seconds (Yair: backend api parameter is in seconds?) No need for a tool-tip - we can add it in parenthesis. mock-up updated. > > ----- Original Message ----- > > From: "Einav Cohen" > > To: "Ayal Baron" , "Eldan Hildesheim" > > , "Eldan Hildesheim" > > , "Miki Kenneth" , "Andrew > > Cathrow" , "Simon Grinberg" > > , "Alexey Chub" > > Cc: engine-devel at ovirt.org > > Sent: Monday, May 21, 2012 1:34:32 PM > > Subject: Advanced Nfs Options + NFSv4 GUI mockup > > > > Please review the mock-up on the feature page: > > http://www.ovirt.org/wiki/Features/AdvancedNfsOptions#User_Experience > > > > Comments are welcome. > > > > ---- > > Thanks, > > Einav > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > From mkenneth at redhat.com Mon May 21 11:12:12 2012 From: mkenneth at redhat.com (Miki Kenneth) Date: Mon, 21 May 2012 07:12:12 -0400 (EDT) Subject: [Engine-devel] Advanced Nfs Options + NFSv4 GUI mockup In-Reply-To: <6995312f-9451-4009-92ba-e8233a1b0139@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <389b40a5-9d40-4e77-a19f-f6441f25f8a6@mkenneth.csb> ----- Original Message ----- > From: "Einav Cohen" > To: "Miki Kenneth" , "Yair Zaslavsky" > Cc: "Eldan Hildesheim" , engine-devel at ovirt.org, "Simon Grinberg" , "Eldan > Hildesheim" > Sent: Monday, May 21, 2012 2:09:42 PM > Subject: Re: [Engine-devel] Advanced Nfs Options + NFSv4 GUI mockup > > > ----- Original Message ----- > > From: "Miki Kenneth" > > Sent: Monday, May 21, 2012 1:54:25 PM > > > > Need to have units on the Retrans and Timout. > > Is tooltip will be available with the correct values? > > Retrans doesn't have units. i guess we need to explain something like # of retransmits? > Timeout should be in seconds (Yair: backend api parameter is in > seconds?) > No need for a tool-tip - we can add it in parenthesis. > mock-up updated. > > > > > ----- Original Message ----- > > > From: "Einav Cohen" > > > To: "Ayal Baron" , "Eldan Hildesheim" > > > , "Eldan Hildesheim" > > > , "Miki Kenneth" , "Andrew > > > Cathrow" , "Simon Grinberg" > > > , "Alexey Chub" > > > Cc: engine-devel at ovirt.org > > > Sent: Monday, May 21, 2012 1:34:32 PM > > > Subject: Advanced Nfs Options + NFSv4 GUI mockup > > > > > > Please review the mock-up on the feature page: > > > http://www.ovirt.org/wiki/Features/AdvancedNfsOptions#User_Experience > > > > > > Comments are welcome. > > > > > > ---- > > > Thanks, > > > Einav > > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > From rgolan at redhat.com Mon May 21 11:23:08 2012 From: rgolan at redhat.com (Roy Golan) Date: Mon, 21 May 2012 14:23:08 +0300 Subject: [Engine-devel] Engine DB - user locked In-Reply-To: <4FBA1DFB.4010504@redhat.com> References: <4FBA1DFB.4010504@redhat.com> Message-ID: <4FBA259C.1030808@redhat.com> On 05/21/2012 01:50 PM, Yair Zaslavsky wrote: > On 05/21/2012 01:44 PM, Elad Tabak wrote: >> Hi, >> After an attempt to clear the DB by running './create_db_devel.sh -u >> postgres', I got an error: >> *Failed to create database engine* >> I then run 'dropdb -U postgres engine', and then 'create_db_devel.sh' >> again, but still I get the same error. >> When I tried to login from the admin web interface, I get authentication >> error. This is from the jboss log: >> USER_FAILED_TO_AUTHENTICATE_ACCOUNT_IS_LOCKED_OR_DISABLED >> >> I also tried running './create_db_devel.sh -u postgres -d engine_new', >> but it gives the same error ("Failed to create database engine_new"). >> I tried restarting the posgresql service, it didn't help. >> >> Please advice. >> >> Thanks, >> Elad > Elad - are you trying to authenticate with Active directory? there's a good chance your /usr/local/jboss/standalone/configutration/standalone.xml is pointing to a different DB otherwise I can figure out how create_db_devel.sh have put the domain values for you. pls paste the engine.log and the output of: grep ovirt /usr/local/jboss/standalone/configuration/standalone.xml > > Kind regards, > Yair > >> >> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From rgolan at redhat.com Mon May 21 11:24:27 2012 From: rgolan at redhat.com (Roy Golan) Date: Mon, 21 May 2012 14:24:27 +0300 Subject: [Engine-devel] Engine DB - user locked In-Reply-To: <4FBA259C.1030808@redhat.com> References: <4FBA1DFB.4010504@redhat.com> <4FBA259C.1030808@redhat.com> Message-ID: <4FBA25EB.3030802@redhat.com> On 05/21/2012 02:23 PM, Roy Golan wrote: > On 05/21/2012 01:50 PM, Yair Zaslavsky wrote: >> On 05/21/2012 01:44 PM, Elad Tabak wrote: >>> Hi, >>> After an attempt to clear the DB by running './create_db_devel.sh -u >>> postgres', I got an error: >>> *Failed to create database engine* >>> I then run 'dropdb -U postgres engine', and then 'create_db_devel.sh' >>> again, but still I get the same error. >>> When I tried to login from the admin web interface, I get >>> authentication >>> error. This is from the jboss log: >>> USER_FAILED_TO_AUTHENTICATE_ACCOUNT_IS_LOCKED_OR_DISABLED >>> >>> I also tried running './create_db_devel.sh -u postgres -d engine_new', >>> but it gives the same error ("Failed to create database engine_new"). >>> I tried restarting the posgresql service, it didn't help. >>> >>> Please advice. >>> >>> Thanks, >>> Elad >> Elad - are you trying to authenticate with Active directory? > there's a good chance your > /usr/local/jboss/standalone/configutration/standalone.xml is pointing > to a different DB otherwise I can figure out how create_db_devel.sh > have put the domain values for you. > pls paste the engine.log and the output of: > grep ovirt /usr/local/jboss/standalone/configuration/standalone.xml oops its grep postgresql /usr/local/jboss/standalone/configuration/standalone.xml > >> >> Kind regards, >> Yair >> >>> >>> >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel at ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From ecohen at redhat.com Mon May 21 11:30:32 2012 From: ecohen at redhat.com (Einav Cohen) Date: Mon, 21 May 2012 07:30:32 -0400 (EDT) Subject: [Engine-devel] Advanced Nfs Options + NFSv4 GUI mockup In-Reply-To: <389b40a5-9d40-4e77-a19f-f6441f25f8a6@mkenneth.csb> Message-ID: <9b7dc2f9-46c7-4537-8d80-49a86d68bad7@zmail04.collab.prod.int.phx2.redhat.com> > ----- Original Message ----- > From: "Miki Kenneth" > Sent: Monday, May 21, 2012 2:12:12 PM > > ----- Original Message ----- > > From: "Einav Cohen" > > To: "Miki Kenneth" , "Yair Zaslavsky" > > > > Cc: "Eldan Hildesheim" , engine-devel at ovirt.org, > > "Simon Grinberg" , "Eldan > > Hildesheim" > > Sent: Monday, May 21, 2012 2:09:42 PM > > Subject: Re: [Engine-devel] Advanced Nfs Options + NFSv4 GUI mockup > > > > > ----- Original Message ----- > > > From: "Miki Kenneth" > > > Sent: Monday, May 21, 2012 1:54:25 PM > > > > > > Need to have units on the Retrans and Timout. > > > Is tooltip will be available with the correct values? > > > > Retrans doesn't have units. > i guess we need to explain something like # of retransmits? Updated mock-up. [I believe that nothing more is needed; people that define an NFS storage domain should generally know what retrans is, I think] > > Timeout should be in seconds (Yair: backend api parameter is in > > seconds?) > > No need for a tool-tip - we can add it in parenthesis. > > mock-up updated. > > > > > > > > ----- Original Message ----- > > > > From: "Einav Cohen" > > > > To: "Ayal Baron" , "Eldan Hildesheim" > > > > , "Eldan Hildesheim" > > > > , "Miki Kenneth" , > > > > "Andrew > > > > Cathrow" , "Simon Grinberg" > > > > , "Alexey Chub" > > > > Cc: engine-devel at ovirt.org > > > > Sent: Monday, May 21, 2012 1:34:32 PM > > > > Subject: Advanced Nfs Options + NFSv4 GUI mockup > > > > > > > > Please review the mock-up on the feature page: > > > > http://www.ovirt.org/wiki/Features/AdvancedNfsOptions#User_Experience > > > > > > > > Comments are welcome. > > > > > > > > ---- > > > > Thanks, > > > > Einav > > > > > > > _______________________________________________ > > > Engine-devel mailing list > > > Engine-devel at ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > From gjansen at redhat.com Mon May 21 11:44:09 2012 From: gjansen at redhat.com (Geert Jansen) Date: Mon, 21 May 2012 13:44:09 +0200 Subject: [Engine-devel] Advanced Nfs Options + NFSv4 GUI mockup In-Reply-To: <33ac9555-6b14-435c-850a-bd79707d4613@zmail04.collab.prod.int.phx2.redhat.com> References: <33ac9555-6b14-435c-850a-bd79707d4613@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4FBA2A89.4010001@redhat.com> On 05/21/2012 12:44 PM, Einav Cohen wrote: >> i was wondering why you have pulled out retrans and timeout? Are >> these >> the most important ones? > > Sorry - not sure I got you. Can you please clarify your question? Sorry, I meant, why do retrans and timeout have their own input boxes, while the other options need to be set via the 'mount options' box. There's quite a few other important nfs options like tcp, rsize, wsize, and possibly nointr and hard. I was wondering why we took these specific two and gave them their separate boxes but not the other ones. Regards, Geert From ecohen at redhat.com Mon May 21 11:49:40 2012 From: ecohen at redhat.com (Einav Cohen) Date: Mon, 21 May 2012 07:49:40 -0400 (EDT) Subject: [Engine-devel] Advanced Nfs Options + NFSv4 GUI mockup In-Reply-To: <4FBA2A89.4010001@redhat.com> Message-ID: > ----- Original Message ----- > From: "Geert Jansen" > Sent: Monday, May 21, 2012 2:44:09 PM > > > On 05/21/2012 12:44 PM, Einav Cohen wrote: > > >> i was wondering why you have pulled out retrans and timeout? Are > >> these > >> the most important ones? > > > > Sorry - not sure I got you. Can you please clarify your question? > > Sorry, I meant, why do retrans and timeout have their own input > boxes, > while the other options need to be set via the 'mount options' box. > There's quite a few other important nfs options like tcp, rsize, > wsize, > and possibly nointr and hard. I was wondering why we took these > specific > two and gave them their separate boxes but not the other ones. Retrans and Timeout got separate boxes since they have separate parameters in the api (GUI was determined by api). Ayal - any reason for these specific two values having parameters of their own? > > Regards, > Geert > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > From lpeer at redhat.com Mon May 21 11:55:31 2012 From: lpeer at redhat.com (Livnat Peer) Date: Mon, 21 May 2012 14:55:31 +0300 Subject: [Engine-devel] port mirroring REST API Message-ID: <4FBA2D33.9050805@redhat.com> Hi All, After digging into the port mirroring feature I suggest a different modeling of it in the API. The current modeling is to add to vnic a boolean property of port-mirroring, e.g. api/vms/{vm-id}/nics ... true This modeling imply 2 limitations: 1. The vnic must be connected to the network it wants to monitor 2. the nic can mirror only a single network Both of the above limitations are correct to the current implementation. Going forward we might want to introduce the above functionalities and the above modeling won't hold. Instead of the above I suggest to change the port-mirroring property to a list of networks. ... .... In this version we'll validate that the network under port-mirroring is equal to the network the vnic is connected to, in future versions we can remove this validation without changing the API. Thanks, Livnat From elad at tonian.com Mon May 21 11:55:09 2012 From: elad at tonian.com (Elad Tabak) Date: Mon, 21 May 2012 14:55:09 +0300 Subject: [Engine-devel] Engine DB - user locked In-Reply-To: <4FBA25EB.3030802@redhat.com> References: <4FBA1DFB.4010504@redhat.com> <4FBA259C.1030808@redhat.com> <4FBA25EB.3030802@redhat.com> Message-ID: I don't have external director server. I'm trying to login using the default username (admin) which used to work before I run the create db script. [elad at ovirt dbscripts]$ grep postgresql /usr/share/jboss-as/standalone/configuration/standalone.xml jdbc:postgresql://localhost:5432/engine postgresql org.postgresql.xa.PGXADataSource Attached engine.log On Mon, May 21, 2012 at 2:24 PM, Roy Golan wrote: > On 05/21/2012 02:23 PM, Roy Golan wrote: > >> On 05/21/2012 01:50 PM, Yair Zaslavsky wrote: >> >>> On 05/21/2012 01:44 PM, Elad Tabak wrote: >>> >>>> Hi, >>>> After an attempt to clear the DB by running './create_db_devel.sh -u >>>> postgres', I got an error: >>>> *Failed to create database engine* >>>> I then run 'dropdb -U postgres engine', and then 'create_db_devel.sh' >>>> again, but still I get the same error. >>>> When I tried to login from the admin web interface, I get authentication >>>> error. This is from the jboss log: >>>> USER_FAILED_TO_AUTHENTICATE_**ACCOUNT_IS_LOCKED_OR_DISABLED >>>> >>>> I also tried running './create_db_devel.sh -u postgres -d engine_new', >>>> but it gives the same error ("Failed to create database engine_new"). >>>> I tried restarting the posgresql service, it didn't help. >>>> >>>> Please advice. >>>> >>>> Thanks, >>>> Elad >>>> >>> Elad - are you trying to authenticate with Active directory? >>> >> there's a good chance your /usr/local/jboss/standalone/**configutration/standalone.xml >> is pointing to a different DB otherwise I can figure out how >> create_db_devel.sh have put the domain values for you. >> pls paste the engine.log and the output of: >> grep ovirt /usr/local/jboss/standalone/**configuration/standalone.xml >> > oops its grep postgresql /usr/local/jboss/standalone/** > configuration/standalone.xml > >> >> >>> Kind regards, >>> Yair >>> >>> >>>> >>>> ______________________________**_________________ >>>> Engine-devel mailing list >>>> Engine-devel at ovirt.org >>>> http://lists.ovirt.org/**mailman/listinfo/engine-devel >>>> >>> ______________________________**_________________ >>> Engine-devel mailing list >>> Engine-devel at ovirt.org >>> http://lists.ovirt.org/**mailman/listinfo/engine-devel >>> >> >> ______________________________**_________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/**mailman/listinfo/engine-devel >> > > ______________________________**_________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/**mailman/listinfo/engine-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: engine.log Type: application/octet-stream Size: 539627 bytes Desc: not available URL: From mpastern at redhat.com Mon May 21 12:38:09 2012 From: mpastern at redhat.com (Michael Pasternak) Date: Mon, 21 May 2012 15:38:09 +0300 Subject: [Engine-devel] port mirroring REST API In-Reply-To: <4FBA2D33.9050805@redhat.com> References: <4FBA2D33.9050805@redhat.com> Message-ID: <4FBA3731.40509@redhat.com> Hi Livnat, On 05/21/2012 02:55 PM, Livnat Peer wrote: > Hi All, > > After digging into the port mirroring feature I suggest a different > modeling of it in the API. > > The current modeling is to add to vnic a boolean property of > port-mirroring, e.g. > > api/vms/{vm-id}/nics > > > > ... > > true > > > > This modeling imply 2 limitations: > 1. The vnic must be connected to the network it wants to monitor > 2. the nic can mirror only a single network > > Both of the above limitations are correct to the current implementation. > Going forward we might want to introduce the above functionalities and > the above modeling won't hold. > Instead of the above I suggest to change the port-mirroring property to > a list of networks. > > > > ... > > > > .... > > > > > In this version we'll validate that the network under port-mirroring is > equal to the network the vnic is connected to, in future versions we can > remove this validation without changing the API. iiuc you saying that in future vnic might be connected to several networks simultaneously? > > > > Thanks, Livnat -- Michael Pasternak RedHat, ENG-Virtualization R&D From shaharh at redhat.com Mon May 21 12:54:56 2012 From: shaharh at redhat.com (Shahar Havivi) Date: Mon, 21 May 2012 15:54:56 +0300 Subject: [Engine-devel] port mirroring REST API In-Reply-To: <4FBA3731.40509@redhat.com> References: <4FBA2D33.9050805@redhat.com> <4FBA3731.40509@redhat.com> Message-ID: <20120521125455.GB13795@redhat.com> On 21.05.12 15:38, Michael Pasternak wrote: > > Hi Livnat, > > On 05/21/2012 02:55 PM, Livnat Peer wrote: > > Hi All, > > > > After digging into the port mirroring feature I suggest a different > > modeling of it in the API. > > > > The current modeling is to add to vnic a boolean property of > > port-mirroring, e.g. > > > > api/vms/{vm-id}/nics > > > > > > > > ... > > > > true > > > > > > > > This modeling imply 2 limitations: > > 1. The vnic must be connected to the network it wants to monitor > > 2. the nic can mirror only a single network > > > > Both of the above limitations are correct to the current implementation. > > Going forward we might want to introduce the above functionalities and > > the above modeling won't hold. > > Instead of the above I suggest to change the port-mirroring property to > > a list of networks. > > > > > > > > ... > > > > > > > > .... > > > > > > > > > > In this version we'll validate that the network under port-mirroring is > > equal to the network the vnic is connected to, in future versions we can > > remove this validation without changing the API. > > iiuc you saying that in future vnic might be connected to several > networks simultaneously? yes, maybe in next version > > > > > > > > > Thanks, Livnat > > > -- > > Michael Pasternak > RedHat, ENG-Virtualization R&D From dfediuck at redhat.com Mon May 21 12:59:07 2012 From: dfediuck at redhat.com (Doron Fediuck) Date: Mon, 21 May 2012 15:59:07 +0300 Subject: [Engine-devel] Advanced Nfs Options + NFSv4 GUI mockup In-Reply-To: References: Message-ID: <4FBA3C1B.9020108@redhat.com> On 21/05/12 14:49, Einav Cohen wrote: >> ----- Original Message ----- >> From: "Geert Jansen" >> Sent: Monday, May 21, 2012 2:44:09 PM >> >> >> On 05/21/2012 12:44 PM, Einav Cohen wrote: >> >>>> i was wondering why you have pulled out retrans and timeout? Are >>>> these >>>> the most important ones? >>> >>> Sorry - not sure I got you. Can you please clarify your question? >> >> Sorry, I meant, why do retrans and timeout have their own input >> boxes, >> while the other options need to be set via the 'mount options' box. >> There's quite a few other important nfs options like tcp, rsize, >> wsize, >> and possibly nointr and hard. I was wondering why we took these >> specific >> two and gave them their separate boxes but not the other ones. > > Retrans and Timeout got separate boxes since they have separate parameters in the api (GUI was determined by api). > Ayal - any reason for these specific two values having parameters of their own? > Reading some of the thread and reviews I can say that these 3 options (version, retrans and timeo) are advanced NFS features, which in most cases should not be used at all. VDSM has very good defaults, and in some specific cases there's a need to change these defaults. Only in such case these options should be modified. >> >> Regards, >> Geert >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> >> >> > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel -- /d "Hi, my name is Any Key. Please don't hit me!" From rgolan at redhat.com Mon May 21 13:05:53 2012 From: rgolan at redhat.com (Roy Golan) Date: Mon, 21 May 2012 16:05:53 +0300 Subject: [Engine-devel] Engine DB - user locked In-Reply-To: References: <4FBA1DFB.4010504@redhat.com> <4FBA259C.1030808@redhat.com> <4FBA25EB.3030802@redhat.com> Message-ID: <4FBA3DB1.107@redhat.com> On 05/21/2012 02:55 PM, Elad Tabak wrote: > I don't have external director server. I'm trying to login using the > default username (admin) which used to work before I run the create db > script. > > [elad at ovirt dbscripts]$ grep postgresql > /usr/share/jboss-as/standalone/configuration/standalone.xml > jdbc:postgresql://localhost:5432/engine > postgresql > > org.postgresql.xa.PGXADataSource > > Attached engine.log > try this: psql ovirt postgres -c "update vdc_options set option_value='123' where option_name = 'AdminPassword';" then login with admin/123 > > On Mon, May 21, 2012 at 2:24 PM, Roy Golan > wrote: > > On 05/21/2012 02:23 PM, Roy Golan wrote: > > On 05/21/2012 01:50 PM, Yair Zaslavsky wrote: > > On 05/21/2012 01:44 PM, Elad Tabak wrote: > > Hi, > After an attempt to clear the DB by running > './create_db_devel.sh -u > postgres', I got an error: > *Failed to create database engine* > I then run 'dropdb -U postgres engine', and then > 'create_db_devel.sh' > again, but still I get the same error. > When I tried to login from the admin web interface, I > get authentication > error. This is from the jboss log: > USER_FAILED_TO_AUTHENTICATE_ACCOUNT_IS_LOCKED_OR_DISABLED > > I also tried running './create_db_devel.sh -u postgres > -d engine_new', > but it gives the same error ("Failed to create > database engine_new"). > I tried restarting the posgresql service, it didn't help. > > Please advice. > > Thanks, > Elad > > Elad - are you trying to authenticate with Active directory? > > there's a good chance your > /usr/local/jboss/standalone/configutration/standalone.xml is > pointing to a different DB otherwise I can figure out how > create_db_devel.sh have put the domain values for you. > pls paste the engine.log and the output of: > grep ovirt > /usr/local/jboss/standalone/configuration/standalone.xml > > oops its grep postgresql > /usr/local/jboss/standalone/configuration/standalone.xml > > > > Kind regards, > Yair > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecohen at redhat.com Mon May 21 13:09:20 2012 From: ecohen at redhat.com (Einav Cohen) Date: Mon, 21 May 2012 09:09:20 -0400 (EDT) Subject: [Engine-devel] Advanced Nfs Options + NFSv4 GUI mockup In-Reply-To: <4FBA3C1B.9020108@redhat.com> Message-ID: <1c9e58b2-5063-4611-9a93-17d4b30323df@zmail04.collab.prod.int.phx2.redhat.com> > ----- Original Message ----- > From: "Doron Fediuck" > Sent: Monday, May 21, 2012 3:59:07 PM > > On 21/05/12 14:49, Einav Cohen wrote: > >> ----- Original Message ----- > >> From: "Geert Jansen" > >> Sent: Monday, May 21, 2012 2:44:09 PM > >> > >> > >> On 05/21/2012 12:44 PM, Einav Cohen wrote: > >> > >>>> i was wondering why you have pulled out retrans and timeout? Are > >>>> these > >>>> the most important ones? > >>> > >>> Sorry - not sure I got you. Can you please clarify your question? > >> > >> Sorry, I meant, why do retrans and timeout have their own input > >> boxes, > >> while the other options need to be set via the 'mount options' > >> box. > >> There's quite a few other important nfs options like tcp, rsize, > >> wsize, > >> and possibly nointr and hard. I was wondering why we took these > >> specific > >> two and gave them their separate boxes but not the other ones. > > > > Retrans and Timeout got separate boxes since they have separate > > parameters in the api (GUI was determined by api). > > Ayal - any reason for these specific two values having parameters > > of their own? > > > Reading some of the thread and reviews I can say that these 3 options > (version, retrans and timeo) > are advanced NFS features, which in most cases should not be used at > all. VDSM has very good defaults, > and in some specific cases there's a need to change these defaults. > Only in such case these options > should be modified. No question that vdsm has very good defaults and only rarely should they be modified. However, why not change everything via "mount options"? why do we have separate parameters specifically for "retrans" and "timeout" (in addition to "mount options")? As Geert said, we have also tcp, rsize, wsize, etc. So why "retrans" and "timeout" got parameters of their own and the others didn't (i.e. if there is a need to change tcp, rsize, wsize, the only way to do it is via the generic "mount options")? > > >> > >> Regards, > >> Geert > >> _______________________________________________ > >> Engine-devel mailing list > >> Engine-devel at ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/engine-devel > >> > >> > >> > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > -- > > /d > > "Hi, my name is Any Key. Please don't hit me!" > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > From mpastern at redhat.com Mon May 21 13:19:03 2012 From: mpastern at redhat.com (Michael Pasternak) Date: Mon, 21 May 2012 16:19:03 +0300 Subject: [Engine-devel] port mirroring REST API In-Reply-To: <20120521125455.GB13795@redhat.com> References: <4FBA2D33.9050805@redhat.com> <4FBA3731.40509@redhat.com> <20120521125455.GB13795@redhat.com> Message-ID: <4FBA40C7.8050909@redhat.com> On 05/21/2012 03:54 PM, Shahar Havivi wrote: > On 21.05.12 15:38, Michael Pasternak wrote: >> >> Hi Livnat, >> >> On 05/21/2012 02:55 PM, Livnat Peer wrote: >>> Hi All, >>> >>> After digging into the port mirroring feature I suggest a different >>> modeling of it in the API. >>> >>> The current modeling is to add to vnic a boolean property of >>> port-mirroring, e.g. >>> >>> api/vms/{vm-id}/nics >>> >>> >>> >>> ... >>> >>> true >>> >>> >>> >>> This modeling imply 2 limitations: >>> 1. The vnic must be connected to the network it wants to monitor >>> 2. the nic can mirror only a single network >>> >>> Both of the above limitations are correct to the current implementation. >>> Going forward we might want to introduce the above functionalities and >>> the above modeling won't hold. >>> Instead of the above I suggest to change the port-mirroring property to >>> a list of networks. >>> >>> >>> >>> ... >>> >>> >>> >>> .... >>> >>> >>> >>> >>> In this version we'll validate that the network under port-mirroring is >>> equal to the network the vnic is connected to, in future versions we can >>> remove this validation without changing the API. >> >> iiuc you saying that in future vnic might be connected to several >> networks simultaneously? > yes, maybe in next version in this case, api should be changed as at the moment we permit single network peer vnic, another option may be: ... true true this way we won't have to double network references, only disadvantage of this approach is abuse of network link, but we already have such precedents in api. >> >>> >>> >>> >>> Thanks, Livnat >> >> >> -- >> >> Michael Pasternak >> RedHat, ENG-Virtualization R&D -- Michael Pasternak RedHat, ENG-Virtualization R&D From dfediuck at redhat.com Mon May 21 13:12:35 2012 From: dfediuck at redhat.com (Doron Fediuck) Date: Mon, 21 May 2012 16:12:35 +0300 Subject: [Engine-devel] Advanced Nfs Options + NFSv4 GUI mockup In-Reply-To: <1c9e58b2-5063-4611-9a93-17d4b30323df@zmail04.collab.prod.int.phx2.redhat.com> References: <1c9e58b2-5063-4611-9a93-17d4b30323df@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4FBA3F43.7040201@redhat.com> On 21/05/12 16:09, Einav Cohen wrote: >> ----- Original Message ----- >> From: "Doron Fediuck" >> Sent: Monday, May 21, 2012 3:59:07 PM >> >> On 21/05/12 14:49, Einav Cohen wrote: >>>> ----- Original Message ----- >>>> From: "Geert Jansen" >>>> Sent: Monday, May 21, 2012 2:44:09 PM >>>> >>>> >>>> On 05/21/2012 12:44 PM, Einav Cohen wrote: >>>> >>>>>> i was wondering why you have pulled out retrans and timeout? Are >>>>>> these >>>>>> the most important ones? >>>>> >>>>> Sorry - not sure I got you. Can you please clarify your question? >>>> >>>> Sorry, I meant, why do retrans and timeout have their own input >>>> boxes, >>>> while the other options need to be set via the 'mount options' >>>> box. >>>> There's quite a few other important nfs options like tcp, rsize, >>>> wsize, >>>> and possibly nointr and hard. I was wondering why we took these >>>> specific >>>> two and gave them their separate boxes but not the other ones. >>> >>> Retrans and Timeout got separate boxes since they have separate >>> parameters in the api (GUI was determined by api). >>> Ayal - any reason for these specific two values having parameters >>> of their own? >>> >> Reading some of the thread and reviews I can say that these 3 options >> (version, retrans and timeo) >> are advanced NFS features, which in most cases should not be used at >> all. VDSM has very good defaults, >> and in some specific cases there's a need to change these defaults. >> Only in such case these options >> should be modified. > > No question that vdsm has very good defaults and only rarely should they be modified. > However, why not change everything via "mount options"? why do we have separate parameters specifically for "retrans" and "timeout" (in addition to "mount options")? As Geert said, we have also tcp, rsize, wsize, etc. So why "retrans" and "timeout" got parameters of their own and the others didn't (i.e. if there is a need to change tcp, rsize, wsize, the only way to do it is via the generic "mount options")? I think it has to do w/ the vdsm implementation of it, maybe also connection management in the backend. But I think Livnat may have some better understandings of that. > >> >>>> >>>> Regards, >>>> Geert >>>> _______________________________________________ >>>> Engine-devel mailing list >>>> Engine-devel at ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>> >>>> >>>> >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel at ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >> >> >> -- >> >> /d >> >> "Hi, my name is Any Key. Please don't hit me!" >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> >> >> -- /d Why doesn't DOS ever say "EXCELLENT command or filename!" From ykaul at redhat.com Mon May 21 13:14:29 2012 From: ykaul at redhat.com (Yaniv Kaul) Date: Mon, 21 May 2012 16:14:29 +0300 Subject: [Engine-devel] Advanced Nfs Options + NFSv4 GUI mockup In-Reply-To: <1c9e58b2-5063-4611-9a93-17d4b30323df@zmail04.collab.prod.int.phx2.redhat.com> References: <1c9e58b2-5063-4611-9a93-17d4b30323df@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4FBA3FB5.8000207@redhat.com> On 05/21/2012 04:09 PM, Einav Cohen wrote: >> ----- Original Message ----- >> From: "Doron Fediuck" >> Sent: Monday, May 21, 2012 3:59:07 PM >> >> On 21/05/12 14:49, Einav Cohen wrote: >>>> ----- Original Message ----- >>>> From: "Geert Jansen" >>>> Sent: Monday, May 21, 2012 2:44:09 PM >>>> >>>> >>>> On 05/21/2012 12:44 PM, Einav Cohen wrote: >>>> >>>>>> i was wondering why you have pulled out retrans and timeout? Are >>>>>> these >>>>>> the most important ones? >>>>> Sorry - not sure I got you. Can you please clarify your question? >>>> Sorry, I meant, why do retrans and timeout have their own input >>>> boxes, >>>> while the other options need to be set via the 'mount options' >>>> box. >>>> There's quite a few other important nfs options like tcp, rsize, >>>> wsize, >>>> and possibly nointr and hard. I was wondering why we took these >>>> specific >>>> two and gave them their separate boxes but not the other ones. >>> Retrans and Timeout got separate boxes since they have separate >>> parameters in the api (GUI was determined by api). >>> Ayal - any reason for these specific two values having parameters >>> of their own? >>> >> Reading some of the thread and reviews I can say that these 3 options >> (version, retrans and timeo) >> are advanced NFS features, which in most cases should not be used at >> all. VDSM has very good defaults, >> and in some specific cases there's a need to change these defaults. >> Only in such case these options >> should be modified. > No question that vdsm has very good defaults and only rarely should they be modified. > However, why not change everything via "mount options"? why do we have separate parameters specifically for "retrans" and "timeout" (in addition to "mount options")? As Geert said, we have also tcp, rsize, wsize, etc. So why "retrans" and "timeout" got parameters of their own and the others didn't (i.e. if there is a need to change tcp, rsize, wsize, the only way to do it is via the generic "mount options")? While I agree they could be collapsed, practically, we've never heard of requests to any other parameters but those two, plus: - hard mount instead of soft. Probably not going to happen soon. Requires a lot more changes everywhere. - udp instead of tcp - bahhh.. We are in the 21st century, shouldn't be needed. But there are other params we may need in the future, which is why we have the additional options field. Y. > >>>> Regards, >>>> Geert >>>> _______________________________________________ >>>> Engine-devel mailing list >>>> Engine-devel at ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>> >>>> >>>> >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel at ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >> >> -- >> >> /d >> >> "Hi, my name is Any Key. Please don't hit me!" >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> >> >> > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From lpeer at redhat.com Mon May 21 13:22:02 2012 From: lpeer at redhat.com (Livnat Peer) Date: Mon, 21 May 2012 16:22:02 +0300 Subject: [Engine-devel] port mirroring REST API In-Reply-To: <4FBA40C7.8050909@redhat.com> References: <4FBA2D33.9050805@redhat.com> <4FBA3731.40509@redhat.com> <20120521125455.GB13795@redhat.com> <4FBA40C7.8050909@redhat.com> Message-ID: <4FBA417A.5030602@redhat.com> On 21/05/12 16:19, Michael Pasternak wrote: > On 05/21/2012 03:54 PM, Shahar Havivi wrote: >> On 21.05.12 15:38, Michael Pasternak wrote: >>> >>> Hi Livnat, >>> >>> On 05/21/2012 02:55 PM, Livnat Peer wrote: >>>> Hi All, >>>> >>>> After digging into the port mirroring feature I suggest a different >>>> modeling of it in the API. >>>> >>>> The current modeling is to add to vnic a boolean property of >>>> port-mirroring, e.g. >>>> >>>> api/vms/{vm-id}/nics >>>> >>>> >>>> >>>> ... >>>> >>>> true >>>> >>>> >>>> >>>> This modeling imply 2 limitations: >>>> 1. The vnic must be connected to the network it wants to monitor >>>> 2. the nic can mirror only a single network >>>> >>>> Both of the above limitations are correct to the current implementation. >>>> Going forward we might want to introduce the above functionalities and >>>> the above modeling won't hold. >>>> Instead of the above I suggest to change the port-mirroring property to >>>> a list of networks. >>>> >>>> >>>> >>>> ... >>>> >>>> >>>> >>>> .... >>>> >>>> >>>> >>>> >>>> In this version we'll validate that the network under port-mirroring is >>>> equal to the network the vnic is connected to, in future versions we can >>>> remove this validation without changing the API. >>> >>> iiuc you saying that in future vnic might be connected to several >>> networks simultaneously? >> yes, maybe in next version > > in this case, api should be changed as at the moment we permit single network > peer vnic, another option may be: > > > > ... > > > true > > > true > > > > > > this way we won't have to double network references, only disadvantage > of this approach is abuse of network link, but we already have such > precedents in api. Hi Michael, One of the issues I raised was to avoid association between the network the nic is attached to and the networks the nic can monitor. The implementation in VDSM does not require that the nic will be connected to the network in order to monitor it. So going forward we might connect the VM nic to intrusion-detection-network while the monitoring will be for red network and blue network. Thanks, Livnat > >>> >>>> >>>> >>>> >>>> Thanks, Livnat >>> >>> >>> -- >>> >>> Michael Pasternak >>> RedHat, ENG-Virtualization R&D > > From mpastern at redhat.com Mon May 21 13:36:53 2012 From: mpastern at redhat.com (Michael Pasternak) Date: Mon, 21 May 2012 16:36:53 +0300 Subject: [Engine-devel] port mirroring REST API In-Reply-To: <4FBA417A.5030602@redhat.com> References: <4FBA2D33.9050805@redhat.com> <4FBA3731.40509@redhat.com> <20120521125455.GB13795@redhat.com> <4FBA40C7.8050909@redhat.com> <4FBA417A.5030602@redhat.com> Message-ID: <4FBA44F5.8080301@redhat.com> On 05/21/2012 04:22 PM, Livnat Peer wrote: > On 21/05/12 16:19, Michael Pasternak wrote: >> On 05/21/2012 03:54 PM, Shahar Havivi wrote: >>> On 21.05.12 15:38, Michael Pasternak wrote: >>>> >>>> Hi Livnat, >>>> >>>> On 05/21/2012 02:55 PM, Livnat Peer wrote: >>>>> Hi All, >>>>> >>>>> After digging into the port mirroring feature I suggest a different >>>>> modeling of it in the API. >>>>> >>>>> The current modeling is to add to vnic a boolean property of >>>>> port-mirroring, e.g. >>>>> >>>>> api/vms/{vm-id}/nics >>>>> >>>>> >>>>> >>>>> ... >>>>> >>>>> true >>>>> >>>>> >>>>> >>>>> This modeling imply 2 limitations: >>>>> 1. The vnic must be connected to the network it wants to monitor >>>>> 2. the nic can mirror only a single network >>>>> >>>>> Both of the above limitations are correct to the current implementation. >>>>> Going forward we might want to introduce the above functionalities and >>>>> the above modeling won't hold. >>>>> Instead of the above I suggest to change the port-mirroring property to >>>>> a list of networks. >>>>> >>>>> >>>>> >>>>> ... >>>>> >>>>> >>>>> >>>>> .... >>>>> >>>>> >>>>> >>>>> >>>>> In this version we'll validate that the network under port-mirroring is >>>>> equal to the network the vnic is connected to, in future versions we can >>>>> remove this validation without changing the API. >>>> >>>> iiuc you saying that in future vnic might be connected to several >>>> networks simultaneously? >>> yes, maybe in next version >> >> in this case, api should be changed as at the moment we permit single network >> peer vnic, another option may be: >> >> >> >> ... >> >> >> true >> >> >> true >> >> >> >> >> >> this way we won't have to double network references, only disadvantage >> of this approach is abuse of network link, but we already have such >> precedents in api. > > Hi Michael, > > One of the issues I raised was to avoid association between the network > the nic is attached to and the networks the nic can monitor. > > The implementation in VDSM does not require that the nic will be > connected to the network in order to monitor it. So going forward we > might connect the VM nic to intrusion-detection-network while the > monitoring will be for red network and blue network. > > > Thanks, Livnat in this case +1 on your design. > > >> >>>> >>>>> >>>>> >>>>> >>>>> Thanks, Livnat >>>> >>>> >>>> -- >>>> >>>> Michael Pasternak >>>> RedHat, ENG-Virtualization R&D >> >> > -- Michael Pasternak RedHat, ENG-Virtualization R&D From shaharh at redhat.com Mon May 21 13:37:36 2012 From: shaharh at redhat.com (Shahar Havivi) Date: Mon, 21 May 2012 16:37:36 +0300 Subject: [Engine-devel] port mirroring REST API In-Reply-To: <4FBA44F5.8080301@redhat.com> References: <4FBA2D33.9050805@redhat.com> <4FBA3731.40509@redhat.com> <20120521125455.GB13795@redhat.com> <4FBA40C7.8050909@redhat.com> <4FBA417A.5030602@redhat.com> <4FBA44F5.8080301@redhat.com> Message-ID: <20120521133734.GC13795@redhat.com> On 21.05.12 16:36, Michael Pasternak wrote: > On 05/21/2012 04:22 PM, Livnat Peer wrote: > > On 21/05/12 16:19, Michael Pasternak wrote: > >> On 05/21/2012 03:54 PM, Shahar Havivi wrote: > >>> On 21.05.12 15:38, Michael Pasternak wrote: > >>>> > >>>> Hi Livnat, > >>>> > >>>> On 05/21/2012 02:55 PM, Livnat Peer wrote: > >>>>> Hi All, > >>>>> > >>>>> After digging into the port mirroring feature I suggest a different > >>>>> modeling of it in the API. > >>>>> > >>>>> The current modeling is to add to vnic a boolean property of > >>>>> port-mirroring, e.g. > >>>>> > >>>>> api/vms/{vm-id}/nics > >>>>> > >>>>> > >>>>> > >>>>> ... > >>>>> > >>>>> true > >>>>> > >>>>> > >>>>> > >>>>> This modeling imply 2 limitations: > >>>>> 1. The vnic must be connected to the network it wants to monitor > >>>>> 2. the nic can mirror only a single network > >>>>> > >>>>> Both of the above limitations are correct to the current implementation. > >>>>> Going forward we might want to introduce the above functionalities and > >>>>> the above modeling won't hold. > >>>>> Instead of the above I suggest to change the port-mirroring property to > >>>>> a list of networks. > >>>>> > >>>>> > >>>>> > >>>>> ... > >>>>> > >>>>> > >>>>> > >>>>> .... > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> In this version we'll validate that the network under port-mirroring is > >>>>> equal to the network the vnic is connected to, in future versions we can > >>>>> remove this validation without changing the API. > >>>> > >>>> iiuc you saying that in future vnic might be connected to several > >>>> networks simultaneously? > >>> yes, maybe in next version > >> > >> in this case, api should be changed as at the moment we permit single network > >> peer vnic, another option may be: > >> > >> > >> > >> ... > >> > >> > >> true > >> > >> > >> true > >> > >> > >> > >> > >> > >> this way we won't have to double network references, only disadvantage > >> of this approach is abuse of network link, but we already have such > >> precedents in api. > > > > Hi Michael, > > > > One of the issues I raised was to avoid association between the network > > the nic is attached to and the networks the nic can monitor. > > > > The implementation in VDSM does not require that the nic will be > > connected to the network in order to monitor it. So going forward we > > might connect the VM nic to intrusion-detection-network while the > > monitoring will be for red network and blue network. > > > > > > Thanks, Livnat > > in this case +1 on your design. Michael this mean that we are using Livnats design: ... .... and the engine stays with the same api, which mean that we need to "translate" to the engine the value true in VmInterface and "translate" back from the engine from boolean to network. is that ok with you? > > > > > > >> > >>>> > >>>>> > >>>>> > >>>>> > >>>>> Thanks, Livnat > >>>> > >>>> > >>>> -- > >>>> > >>>> Michael Pasternak > >>>> RedHat, ENG-Virtualization R&D > >> > >> > > > > > -- > > Michael Pasternak > RedHat, ENG-Virtualization R&D From mpastern at redhat.com Mon May 21 13:50:41 2012 From: mpastern at redhat.com (Michael Pasternak) Date: Mon, 21 May 2012 16:50:41 +0300 Subject: [Engine-devel] port mirroring REST API In-Reply-To: <20120521133734.GC13795@redhat.com> References: <4FBA2D33.9050805@redhat.com> <4FBA3731.40509@redhat.com> <20120521125455.GB13795@redhat.com> <4FBA40C7.8050909@redhat.com> <4FBA417A.5030602@redhat.com> <4FBA44F5.8080301@redhat.com> <20120521133734.GC13795@redhat.com> Message-ID: <4FBA4831.9020904@redhat.com> On 05/21/2012 04:37 PM, Shahar Havivi wrote: >> in this case +1 on your design. > Michael this mean that we are using Livnats design: yes > > > ... > > > > .... > > > > and the engine stays with the same api, which mean that we need to "translate" > to the engine the value true in VmInterface and "translate" back from the > engine from boolean to network. > is that ok with you? > yep. -- Michael Pasternak RedHat, ENG-Virtualization R&D From oschreib at redhat.com Mon May 21 13:58:13 2012 From: oschreib at redhat.com (Ofer Schreiber) Date: Mon, 21 May 2012 09:58:13 -0400 (EDT) Subject: [Engine-devel] F17 maven build failure In-Reply-To: <4FB94415.3040209@redhat.com> Message-ID: <07690cb4-1c9c-4d23-aa87-3c3153631ae5@zmail14.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > On 05/20/2012 07:29 PM, Ofer Schreiber wrote: > > I'm using the regular mvn install command, should I do some changes > > in the main pom file? > > I think that this is probably a bug in maven, but one that we are > triggering due to the fact that we assign different identifiers to > the > repositories used for normal artifacts and the repositories used for > plugins. Can you try the attached patch and let me know if it fixes > your > problem? Indeed, Thanks! what about a patch in gerrit about it? > > > On 20 May 2012, at 18:54, Juan Hernandez > > wrote: > > > >> On 05/20/2012 04:39 PM, Ofer Schreiber wrote: > >>> I'm trying to build ovirt-engine in Fedora 17, and getting the > >>> following error: > >>> > >>> [INFO] oVirt Modules - manager ........................... > >>> FAILURE [1:05.421s] > >>> .... > >>> > >>> [ERROR] Failed to execute goal > >>> org.apache.maven.plugins:maven-checkstyle-plugin:2.6:check > >>> (default) on project manager-modules: Execution default of goal > >>> org.apache.maven.plugins:maven-checkstyle-plugin:2.6:check > >>> failed: Plugin > >>> org.apache.maven.plugins:maven-checkstyle-plugin:2.6 or one of > >>> its dependencies could not be resolved: The following artifacts > >>> could not be resolved: checkstyle:checkstyle:jar:5.0, > >>> antlr:antlr:jar:2.7.6, > >>> commons-beanutils:commons-beanutils-core:jar:1.7.0, > >>> com.google.collections:google-collections:jar:0.9: Could not > >>> find artifact checkstyle:checkstyle:jar:5.0 -> [Help 1] > >>> > >>> Any idea how can I resolve it? > >> > >> Are you building with regular "mvn" or with "mvn-rpmbuild"? > >> > >> If you are using the later you will have to update to checkstyle > >> 5.5 and to maven-checkstyle-plugin 2.9.1, as those are what are > >> available in Fedora 17. In addition the gid:aid of checkstyle > >> changed from checkstyle:checkstyle to > >> com.puppycrawl.tools:checkstyle somewhere between 5.0 and 5.5. > > -- > Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta > 3?D, 28016 Madrid, Spain > Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat > S.L. > From jhernand at redhat.com Mon May 21 14:05:07 2012 From: jhernand at redhat.com (Juan Hernandez) Date: Mon, 21 May 2012 16:05:07 +0200 Subject: [Engine-devel] F17 maven build failure In-Reply-To: <07690cb4-1c9c-4d23-aa87-3c3153631ae5@zmail14.collab.prod.int.phx2.redhat.com> References: <07690cb4-1c9c-4d23-aa87-3c3153631ae5@zmail14.collab.prod.int.phx2.redhat.com> Message-ID: <4FBA4B93.4050205@redhat.com> On 05/21/2012 03:58 PM, Ofer Schreiber wrote: > > > ----- Original Message ----- >> On 05/20/2012 07:29 PM, Ofer Schreiber wrote: >>> I'm using the regular mvn install command, should I do some changes >>> in the main pom file? >> >> I think that this is probably a bug in maven, but one that we are >> triggering due to the fact that we assign different identifiers to >> the >> repositories used for normal artifacts and the repositories used for >> plugins. Can you try the attached patch and let me know if it fixes >> your >> problem? > > Indeed, Thanks! > what about a patch in gerrit about it? Yes, of course: http://gerrit.ovirt.org/4623 >>> On 20 May 2012, at 18:54, Juan Hernandez >>> wrote: >>> >>>> On 05/20/2012 04:39 PM, Ofer Schreiber wrote: >>>>> I'm trying to build ovirt-engine in Fedora 17, and getting the >>>>> following error: >>>>> >>>>> [INFO] oVirt Modules - manager ........................... >>>>> FAILURE [1:05.421s] >>>>> .... >>>>> >>>>> [ERROR] Failed to execute goal >>>>> org.apache.maven.plugins:maven-checkstyle-plugin:2.6:check >>>>> (default) on project manager-modules: Execution default of goal >>>>> org.apache.maven.plugins:maven-checkstyle-plugin:2.6:check >>>>> failed: Plugin >>>>> org.apache.maven.plugins:maven-checkstyle-plugin:2.6 or one of >>>>> its dependencies could not be resolved: The following artifacts >>>>> could not be resolved: checkstyle:checkstyle:jar:5.0, >>>>> antlr:antlr:jar:2.7.6, >>>>> commons-beanutils:commons-beanutils-core:jar:1.7.0, >>>>> com.google.collections:google-collections:jar:0.9: Could not >>>>> find artifact checkstyle:checkstyle:jar:5.0 -> [Help 1] >>>>> >>>>> Any idea how can I resolve it? >>>> >>>> Are you building with regular "mvn" or with "mvn-rpmbuild"? >>>> >>>> If you are using the later you will have to update to checkstyle >>>> 5.5 and to maven-checkstyle-plugin 2.9.1, as those are what are >>>> available in Fedora 17. In addition the gid:aid of checkstyle >>>> changed from checkstyle:checkstyle to >>>> com.puppycrawl.tools:checkstyle somewhere between 5.0 and 5.5. >> >> -- >> Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta >> 3?D, 28016 Madrid, Spain >> Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat >> S.L. >> -- Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3?D, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat S.L. From apahim at redhat.com Mon May 21 14:52:34 2012 From: apahim at redhat.com (Amador pahim) Date: Mon, 21 May 2012 11:52:34 -0300 Subject: [Engine-devel] LOCALFS path validation Message-ID: <4FBA56B2.8010203@redhat.com> Hello, I'm starting to know the engine code. I chose a little unstandardized behaviour to follow through the devel process. I have a patch and I'd like to know if you fell relevant to correct this issue: - Description: Adding a LOCAL storage [1], webadmin does not validate path against regex, sendind the invalid path (with final slash) to vdsm [2] [3]. But, adding a NFS storage, the path is validated before contacting vdsm [4] avoiding extra vdsm processing and quickly/clearly informing user about what's wrong. - Expected result: Same behaviour to NFS and LOCALFS storage path validation. Validate LOCALFS path in webadmin before send it to vdsm [5]. - Newbie doubt: Wouldn't be better to validate the both local and nfs path on the backend, achieving all user interfaces/APIs? [1] - https://picasaweb.google.com/lh/photo/FWNiou2Y12GZO3AjfCH6K7QAv8cs6edaj3fEcMleB60 [2] - https://picasaweb.google.com/lh/photo/Pof6Z8ohgQAkRTDpEJKG-LQAv8cs6edaj3fEcMleB60 [3] - https://gist.github.com/2762656 [4] - https://picasaweb.google.com/lh/photo/Fd3zWegWE0T5C2tDo_tPZrQAv8cs6edaj3fEcMleB60 [5] - https://picasaweb.google.com/lh/photo/PgzYrZHkkvm-WtFk_UFZLrQAv8cs6edaj3fEcMleB60 I look forward to hearing your comments. Best Regards, -- Pahim -------------- next part -------------- An HTML attachment was scrubbed... URL: From gchaplik at redhat.com Mon May 21 18:37:15 2012 From: gchaplik at redhat.com (Gilad Chaplik) Date: Mon, 21 May 2012 14:37:15 -0400 (EDT) Subject: [Engine-devel] LOCALFS path validation In-Reply-To: <4FBA56B2.8010203@redhat.com> Message-ID: Hi Pahim, Thanks for the input! Comments inline. Thanks, Gilad. ----- Original Message ----- > From: "Amador pahim" > To: engine-devel at ovirt.org > Sent: Monday, May 21, 2012 5:52:34 PM > Subject: [Engine-devel] LOCALFS path validation > > > Hello, > > I'm starting to know the engine code. I chose a little unstandardized > behaviour to follow through the devel process. I have a patch and > I'd like to know if you fell relevant to correct this issue: > > - Description: Adding a LOCAL storage [1], webadmin does not validate > path against regex, sendind the invalid path (with final slash) to > vdsm [2] [3]. But, adding a NFS storage, the path is validated > before contacting vdsm [4] avoiding extra vdsm processing and > quickly/clearly informing user about what's wrong. > > - Expected result: Same behaviour to NFS and LOCALFS storage path > validation. Validate LOCALFS path in webadmin before send it to vdsm > [5]. you may and should send a patch :) > > - Newbie doubt: Wouldn't be better to validate the both local and nfs > path on the backend, achieving all user interfaces/APIs? Because we have a rich client app (gwt), we can perform the validation also in the client side very easily, we do that to avoid unnecessary calls to the backend side, and to have a better & responsive ui (client side validation is performed instantly - without the need to wait). Anyway, every validation performed in the client side needs to be performed also in backend side (for api, and other reasons (security?)). > > [1] - > https://picasaweb.google.com/lh/photo/FWNiou2Y12GZO3AjfCH6K7QAv8cs6edaj3fEcMleB60 > [2] - > https://picasaweb.google.com/lh/photo/Pof6Z8ohgQAkRTDpEJKG-LQAv8cs6edaj3fEcMleB60 > [3] - https://gist.github.com/2762656 > [4] - > https://picasaweb.google.com/lh/photo/Fd3zWegWE0T5C2tDo_tPZrQAv8cs6edaj3fEcMleB60 > [5] - > https://picasaweb.google.com/lh/photo/PgzYrZHkkvm-WtFk_UFZLrQAv8cs6edaj3fEcMleB60 > > I look forward to hearing your comments. > > Best Regards, > -- > Pahim > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From elad at tonian.com Mon May 21 13:48:04 2012 From: elad at tonian.com (Elad Tabak) Date: Mon, 21 May 2012 16:48:04 +0300 Subject: [Engine-devel] Engine DB - user locked In-Reply-To: <4FBA3DB1.107@redhat.com> References: <4FBA1DFB.4010504@redhat.com> <4FBA259C.1030808@redhat.com> <4FBA25EB.3030802@redhat.com> <4FBA3DB1.107@redhat.com> Message-ID: Thanks, that seems to solve the problem! :) On Mon, May 21, 2012 at 4:05 PM, Roy Golan wrote: > On 05/21/2012 02:55 PM, Elad Tabak wrote: > > I don't have external director server. I'm trying to login using the > default username (admin) which used to work before I run the create db > script. > > [elad at ovirt dbscripts]$ grep postgresql > /usr/share/jboss-as/standalone/configuration/standalone.xml > > jdbc:postgresql://localhost:5432/engine > postgresql > > > org.postgresql.xa.PGXADataSource > > Attached engine.log > > try this: > psql ovirt postgres -c "update vdc_options set option_value='123' where > option_name = 'AdminPassword';" > > then login with admin/123 > > > On Mon, May 21, 2012 at 2:24 PM, Roy Golan wrote: > >> On 05/21/2012 02:23 PM, Roy Golan wrote: >> >>> On 05/21/2012 01:50 PM, Yair Zaslavsky wrote: >>> >>>> On 05/21/2012 01:44 PM, Elad Tabak wrote: >>>> >>>>> Hi, >>>>> After an attempt to clear the DB by running './create_db_devel.sh -u >>>>> postgres', I got an error: >>>>> *Failed to create database engine* >>>>> I then run 'dropdb -U postgres engine', and then 'create_db_devel.sh' >>>>> again, but still I get the same error. >>>>> When I tried to login from the admin web interface, I get >>>>> authentication >>>>> error. This is from the jboss log: >>>>> USER_FAILED_TO_AUTHENTICATE_ACCOUNT_IS_LOCKED_OR_DISABLED >>>>> >>>>> I also tried running './create_db_devel.sh -u postgres -d engine_new', >>>>> but it gives the same error ("Failed to create database engine_new"). >>>>> I tried restarting the posgresql service, it didn't help. >>>>> >>>>> Please advice. >>>>> >>>>> Thanks, >>>>> Elad >>>>> >>>> Elad - are you trying to authenticate with Active directory? >>>> >>> there's a good chance your >>> /usr/local/jboss/standalone/configutration/standalone.xml is pointing to a >>> different DB otherwise I can figure out how create_db_devel.sh have put the >>> domain values for you. >>> pls paste the engine.log and the output of: >>> grep ovirt /usr/local/jboss/standalone/configuration/standalone.xml >>> >> oops its grep postgresql >> /usr/local/jboss/standalone/configuration/standalone.xml >> >>> >>> >>>> Kind regards, >>>> Yair >>>> >>>> >>>>> >>>>> _______________________________________________ >>>>> Engine-devel mailing list >>>>> Engine-devel at ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>> >>>> _______________________________________________ >>>> Engine-devel mailing list >>>> Engine-devel at ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>> >>> >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel at ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> >> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lpeer at redhat.com Tue May 22 08:45:38 2012 From: lpeer at redhat.com (Livnat Peer) Date: Tue, 22 May 2012 11:45:38 +0300 Subject: [Engine-devel] network features review Message-ID: <4FBB5232.8060004@redhat.com> Hi All, This is a summary of comments we(*) gathered while reviewing the current network related functionality in oVirt, we'll open the relevant RFE/Bugs but wanted to share first to get comments: Default Gateway: ---------------- current status - In the UI/API we expose to the user the possibility to configure the default gateway for the host. We expose this option only when editing the management network. comments - Apparently we do not configure the host default gateway but the network gateway. 1. We need to fix the phrasing to gateway (not default gateway) 2. Why do we block it for networks which are not the management network 3. We need to support configuring the host default gateway. Non VM (Bridge-less) Network: ----------------------------- current status - During bootstrap we configure the management network on the host. We did not implement configuring bridge-less management network during bootstrap. comments - 1. Supporting bridge-less network is a new feature,the design of this feature did not include changing the bootstrap process which make this feature non-useful when it comes to management network. Today one can edit a network only when it is not attached to clusters, at this point you can change the management network to be non-VM network, the problem is that we configure the management network on the host during bootstrap and we do not get a parameter if to create a bridge or not (we always create a bridge). What we end up with is - we can't change the management network once we added clusters/hosts but if changing it before attaching a cluster we ignore it in the bootstrap process. Check connectivity: -------------------- current status - The 'check connectivity' functionality is available only when editing the management network, it validates that we did not loose connectivity to the host, if we did the changes are rolled backed automatically. comments - 1. Sometimes when changing configuration of another network we can 'damage' the connectivity to the host. We want to expose the check connectivity functionality on any network configuration change. VLAN tagging of management Network ----------------------------------- current status - The user can set a VLAN tag on the management network. comments - 1. Any configuration of the management network needs support in the bootstrap process (see explanation above for bridge-less network) 2. In case of VLAN tagging it is even more complicated, when adding a host to oVirt we add it's address and it can not be changed after the host was added to the system. in the bootstrap process we set the management network on the nic oVirt engine used to ssh through, unless the VLAN device is already configured and the IP used for the ssh is already on this VLAN (for which it will work) we can't set the network to be on another IP address. Rollback network configuration: -------------------------------- current status - We have the option to make changes to the host network configuration and not persist the changes (they won't survive machine reboot) comments - 1. We are missing the functionality of rolling back the changes (without rebooting the machine), this functionality is the complementary behavior of 'save network configuration'. Predefined bonds: ----------------- current status - In the bootstrap process we create bonds0-5 on the hosts and then we use them when creating a bond on the host comments - 1. Creating the bonds in the host during the bootstrap process is not needed and we can let the user choose the bond name (limited to bondX) and create bonds only upon request. Editing Network properties while Network is attached to cluster/s ------------------------------------------------------------------ current status - Changing the network properties is blocked if the network is attached to a cluster. comments - 1. We should relax this approach. to start with we can enable editing when there are no active hosts in the cluster/s. doing more than the above requires substantially more work both in VDSM and engine. Thank you, Livnat (*) we == {Dan Kenigsberg, Igor Lvovsky, Mike Kolesnik, Moti Asayag, Muli Salem, Alona Kaplan, Livnat Peer} (**) We have even longer list for the UI changes needed, for them we'll open bugs directly to avoid another long email. From eedri at redhat.com Tue May 22 09:49:37 2012 From: eedri at redhat.com (Eyal Edri) Date: Tue, 22 May 2012 05:49:37 -0400 (EDT) Subject: [Engine-devel] [oVirt Jenkins] ovirt_engine_find_bugs - Build # 915 - Still Unstable! In-Reply-To: <858338111.401337677895927.JavaMail.jenkins@ip-10-114-123-188> Message-ID: <26a5febe-ee42-42a2-aaad-9752147a512b@zmail17.collab.prod.int.phx2.redhat.com> FYI, These set of patches introduced new HIGH findbugs warnings: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/913/changes: webadmin: Gluster Volume Options - populating from help xml (details) webadmin: Gluster Brick sub tab - removing columns (details) webadmin: Support for mode specific Tabs and Sub Tabs (details) restapi: Gluster Resources Implementation classes (details) restapi: RSDL metadata for gluster related REST api (details) restapi: Gluster Volumes Collection implementation (details) engine: Add ID fields to gluster brick and option (details) webadmin: Gluster Volume - add bricks enabling (#823284) (details) webadmin: Gluster Volume - upadting actions (#823273) (details) webadmin: Gluster Volume - validations fixed (#823277) (details) bugs appear to be in GlusterVolumeEntity.java: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/913/findbugsResult/HIGH/source.676/#375 http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/913/findbugsResult/HIGH/? Please review and handle, Eyal Edri oVirt Infra Team ----- Original Message ----- > From: "Jenkins oVirt Server" > To: eedri at redhat.com, engine-patches at ovirt.org, oliel at redhat.com, yzaslavs at redhat.com, amureini at redhat.com, > dfediuck at redhat.com > Sent: Tuesday, May 22, 2012 12:11:33 PM > Subject: [oVirt Jenkins] ovirt_engine_find_bugs - Build # 915 - Still Unstable! > > Project: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/ > Build: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/915/ > Build Number: 915 > Build Status: Still Unstable > Triggered By: Started by upstream project "ovirt_engine" build number > 1,240 > > ------------------------------------- > Changes Since Last Success: > ------------------------------------- > Changes for Build #913 > [gchaplik] webadmin: Gluster Volume Options - populating from help > xml > > [gchaplik] webadmin: Gluster Brick sub tab - removing columns > > [gchaplik] webadmin: Support for mode specific Tabs and Sub Tabs > > [sanjal] restapi: Gluster Resources Implementation classes > > [sanjal] restapi: RSDL metadata for gluster related REST api > > [sanjal] restapi: Gluster Volumes Collection implementation > > [sanjal] engine: Add ID fields to gluster brick and option > > [gchaplik] webadmin: Gluster Volume - add bricks enabling (#823284) > > [gchaplik] webadmin: Gluster Volume - upadting actions (#823273) > > [gchaplik] webadmin: Gluster Volume - validations fixed (#823277) > > > Changes for Build #914 > [emesika] core:dbfunctions.sh script needs to be compatible with DWH > > [mpastern] restapi: fix rsdl regression > > > Changes for Build #915 > [dfediuck] core: Use same ids for artifacts and plugins > > [amureini] core: Allow admin permissions in user views > > [amureini] core: Roles commands cleanup > > [amureini] core: Cleanup Permissions Commands > > [amureini] core: Roles commands - use the cached getRole() > > [amureini] core: is_inheritable property to MLA entities > > > > > ----------------- > Failed Tests: > ----------------- > No tests ran. > > ------------------ > Build Log: > ------------------ > [...truncated 4148 lines...] > [INFO] Assembling webapp [userportal] in > [/ephemeral0/ovirt_engine_find_bugs/frontend/webadmin/modules/userportal-gwtp/target/userportal-3.1.0-0001] > [INFO] Processing war project > [INFO] Copying webapp resources > [/ephemeral0/ovirt_engine_find_bugs/frontend/webadmin/modules/userportal-gwtp/src/main/webapp] > [INFO] Webapp assembled in [147 msecs] > [INFO] Building war: > /ephemeral0/ovirt_engine_find_bugs/frontend/webadmin/modules/userportal-gwtp/target/userportal-3.1.0-0001.war > [INFO] WEB-INF/web.xml already added, skipping > [INFO] > [INFO] --- maven-install-plugin:2.3.1:install (default-install) @ > userportal --- > [INFO] Installing > /ephemeral0/ovirt_engine_find_bugs/frontend/webadmin/modules/userportal-gwtp/target/userportal-3.1.0-0001.war > to > /home/jenkins/workspace/ovirt_engine_find_bugs/.repository/org/ovirt/engine/ui/userportal/3.1.0-0001/userportal-3.1.0-0001.war > [INFO] Installing > /ephemeral0/ovirt_engine_find_bugs/frontend/webadmin/modules/userportal-gwtp/pom.xml > to > /home/jenkins/workspace/ovirt_engine_find_bugs/.repository/org/ovirt/engine/ui/userportal/3.1.0-0001/userportal-3.1.0-0001.pom > [INFO] > [INFO] --- findbugs-maven-plugin:2.4.0:findbugs (default-cli) @ > userportal --- > [INFO] Fork Value is true > [INFO] > [INFO] --- maven-checkstyle-plugin:2.6:check (default) @ webadmin --- > [INFO] Starting audit... > Audit done. > > [INFO] > [INFO] --- maven-resources-plugin:2.5:testResources > (default-testResources) @ webadmin --- > [debug] execute contextualize > [INFO] Using 'UTF-8' encoding to copy filtered resources. > [INFO] skip non existing resourceDirectory > /ephemeral0/ovirt_engine_find_bugs/frontend/webadmin/modules/webadmin/src/test/resources > [INFO] > [INFO] --- maven-compiler-plugin:2.3.2:testCompile > (default-testCompile) @ webadmin --- > [INFO] No sources to compile > [INFO] > [INFO] --- maven-surefire-plugin:2.10:test (default-test) @ webadmin > --- > [INFO] Tests are skipped. > [INFO] > [INFO] --- maven-war-plugin:2.1.1:war (default-war) @ webadmin --- > [INFO] Packaging webapp > [INFO] Assembling webapp [webadmin] in > [/ephemeral0/ovirt_engine_find_bugs/frontend/webadmin/modules/webadmin/target/webadmin-3.1.0-0001] > [INFO] Processing war project > [INFO] Copying webapp resources > [/ephemeral0/ovirt_engine_find_bugs/frontend/webadmin/modules/webadmin/src/main/webapp] > [INFO] Webapp assembled in [147 msecs] > OpenJDK 64-Bit Server VM warning: CodeCache is full. Compiler has > been disabled. > OpenJDK 64-Bit Server VM warning: Try increasing the code cache size > using -XX:ReservedCodeCacheSize= > [INFO] Building war: > /ephemeral0/ovirt_engine_find_bugs/frontend/webadmin/modules/webadmin/target/webadmin-3.1.0-0001.war > [INFO] WEB-INF/web.xml already added, skipping > [INFO] > [INFO] --- maven-install-plugin:2.3.1:install (default-install) @ > webadmin --- > [INFO] Installing > /ephemeral0/ovirt_engine_find_bugs/frontend/webadmin/modules/webadmin/target/webadmin-3.1.0-0001.war > to > /home/jenkins/workspace/ovirt_engine_find_bugs/.repository/org/ovirt/engine/ui/webadmin/3.1.0-0001/webadmin-3.1.0-0001.war > [INFO] Installing > /ephemeral0/ovirt_engine_find_bugs/frontend/webadmin/modules/webadmin/pom.xml > to > /home/jenkins/workspace/ovirt_engine_find_bugs/.repository/org/ovirt/engine/ui/webadmin/3.1.0-0001/webadmin-3.1.0-0001.pom > [INFO] > [INFO] --- findbugs-maven-plugin:2.4.0:findbugs (default-cli) @ > webadmin --- > [INFO] Fork Value is true > [java] Warnings generated: 14 > [INFO] Done FindBugs Analysis.... > [java] Warnings generated: 56 > [INFO] Done FindBugs Analysis.... > [INFO] > [INFO] > ------------------------------------------------------------------------ > [INFO] Building oVirt Server EAR 3.1.0-0001 > [INFO] > ------------------------------------------------------------------------ > [WARNING] The POM for > org.codehaus.mojo:gwt-maven-plugin:jar:1.3.2.google is missing, no > dependency information available > [WARNING] Failed to retrieve plugin descriptor for > org.codehaus.mojo:gwt-maven-plugin:1.3.2.google: Plugin > org.codehaus.mojo:gwt-maven-plugin:1.3.2.google or one of its > dependencies could not be resolved: Failed to read artifact > descriptor for org.codehaus.mojo:gwt-maven-plugin:jar:1.3.2.google > [WARNING] > ***************************************************************** > [WARNING] * Your build is requesting parallel execution, but project > * > [WARNING] * contains the following plugin(s) that are not marked as > * > [WARNING] * @threadSafe to support parallel building. > * > [WARNING] * While this /may/ work fine, please look for plugin > updates * > [WARNING] * and/or request plugins be made thread-safe. > * > [WARNING] * If reporting an issue, report it against the plugin in > * > [WARNING] * question, not against maven-core > * > [WARNING] > ***************************************************************** > [WARNING] The following plugins are not marked @threadSafe in oVirt > Server EAR: > [WARNING] org.apache.maven.plugins:maven-dependency-plugin:2.1 > [WARNING] > ***************************************************************** > [INFO] > [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ > engine-server-ear --- > [INFO] Deleting /ephemeral0/ovirt_engine_find_bugs/ear/target > [INFO] > [INFO] --- maven-ear-plugin:2.6:generate-application-xml > (default-generate-application-xml) @ engine-server-ear --- > [INFO] Generating application.xml > [INFO] > [INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) > @ engine-server-ear --- > [INFO] Using 'UTF-8' encoding to copy filtered resources. > [INFO] skip non existing resourceDirectory > /ephemeral0/ovirt_engine_find_bugs/ear/src/main/java > [INFO] skip non existing resourceDirectory > /ephemeral0/ovirt_engine_find_bugs/ear/src/main/resources > [INFO] > [INFO] --- maven-ear-plugin:2.6:ear (default-ear) @ engine-server-ear > --- > [INFO] Copying artifact[jar:org.ovirt.engine.core:common:3.1.0-0001] > to[lib/engine-common.jar] > [INFO] Copying artifact[jar:org.ovirt.engine.core:compat:3.1.0-0001] > to[lib/engine-compat.jar] > [INFO] Copying artifact[jar:org.ovirt.engine.core:dal:3.1.0-0001] > to[lib/engine-dal.jar] > [INFO] Copying artifact[jar:org.ovirt.engine.core:utils:3.1.0-0001] > to[lib/engine-utils.jar] > [INFO] Copying > artifact[jar:org.ovirt.engine.core:engineencryptutils:3.1.0-0001] > to[lib/engine-encryptutils.jar] > [INFO] Copying > artifact[jar:org.ovirt.engine.core:vdsbroker:3.1.0-0001] > to[lib/engine-vdsbroker.jar] > [INFO] Copying > artifact[war:org.ovirt.engine.core:root-war:3.1.0-0001] to[root.war] > (unpacked) > [INFO] Copying artifact[war:org.ovirt.engine.ui:rmw-war:3.1.0-0001] > to[ovirtengineweb.war] (unpacked) > [INFO] Copying artifact[war:org.ovirt.engine.ui:rm-war:3.1.0-0001] > to[ovirtengine.war] (unpacked) > [INFO] Copying > artifact[war:org.ovirt.engine.ui:components-war:3.1.0-0001] > to[components.war] (unpacked) > [INFO] Copying > artifact[war:org.ovirt.engine.api:restapi-webapp:3.1.0-0001] > to[restapi.war] (unpacked) > [INFO] Copying > artifact[war:org.ovirt.engine.ui:userportal:3.1.0-0001] > to[userportal.war] (unpacked) > [INFO] Copying artifact[war:org.ovirt.engine.ui:webadmin:3.1.0-0001] > to[webadmin.war] (unpacked) > [INFO] Copying > artifact[ejb:org.ovirt.engine.ui:genericapi:3.1.0-0001] > to[engine-genericapi.jar] (unpacked) > [INFO] Copying > artifact[ejb:org.ovirt.engine.core:scheduler:3.1.0-0001] > to[engine-scheduler.jar] (unpacked) > [INFO] Copying artifact[ejb:org.ovirt.engine.core:bll:3.1.0-0001] > to[engine-bll.jar] (unpacked) > [INFO] Copying artifact[jar:commons-codec:commons-codec:1.4] > to[lib/commons-codec-1.4.jar] > [INFO] Copying > artifact[jar:org.hibernate:hibernate-validator:4.0.2.GA] > to[lib/hibernate-validator-4.0.2.GA.jar] > [INFO] Copying artifact[jar:javax.validation:validation-api:1.0.0.GA] > to[lib/validation-api-1.0.0.GA.jar] > [INFO] Copying artifact[jar:org.slf4j:slf4j-api:1.5.6] > to[lib/slf4j-api-1.5.6.jar] > [INFO] Copying artifact[jar:javax.xml.bind:jaxb-api:2.1] > to[lib/jaxb-api-2.1.jar] > [INFO] Copying artifact[jar:javax.xml.stream:stax-api:1.0-2] > to[lib/stax-api-1.0-2.jar] > [INFO] Copying artifact[jar:javax.activation:activation:1.1] > to[lib/activation-1.1.jar] > [INFO] Copying artifact[jar:com.sun.xml.bind:jaxb-impl:2.1.3] > to[lib/jaxb-impl-2.1.3.jar] > [INFO] Copying > artifact[jar:org.hibernate:hibernate-annotations:3.4.0.GA] > to[lib/hibernate-annotations-3.4.0.GA.jar] > [INFO] Copying artifact[jar:org.hibernate:ejb3-persistence:1.0.2.GA] > to[lib/ejb3-persistence-1.0.2.GA.jar] > [INFO] Copying > artifact[jar:org.hibernate:hibernate-commons-annotations:3.1.0.GA] > to[lib/hibernate-commons-annotations-3.1.0.GA.jar] > [INFO] Copying artifact[jar:org.hibernate:hibernate-core:3.3.0.SP1] > to[lib/hibernate-core-3.3.0.SP1.jar] > [INFO] Copying artifact[jar:antlr:antlr:2.7.6] > to[lib/antlr-2.7.6.jar] > [INFO] Copying artifact[jar:dom4j:dom4j:1.6.1] > to[lib/dom4j-1.6.1.jar] > [INFO] Copying artifact[jar:xml-apis:xml-apis:1.0.b2] > to[lib/xml-apis-1.0.b2.jar] > [INFO] Copying > artifact[jar:org.codehaus.jackson:jackson-mapper-asl:1.9.4] > to[lib/jackson-mapper-asl-1.9.4.jar] > [INFO] Copying > artifact[jar:org.codehaus.jackson:jackson-core-asl:1.9.4] > to[lib/jackson-core-asl-1.9.4.jar] > [INFO] Copying > artifact[jar:org.jboss.spec.javax.interceptor:jboss-interceptors-api_1.1_spec:1.0.0.Final] > to[lib/jboss-interceptors-api_1.1_spec-1.0.0.Final.jar] > [INFO] Copying > artifact[jar:org.ovirt.engine.core:engine-tools-common:3.1.0-0001] > to[lib/engine-tools-common-3.1.0-0001.jar] > [INFO] Copying > artifact[jar:commons-beanutils:commons-beanutils:1.8.2] > to[lib/commons-beanutils-1.8.2.jar] > [INFO] Copying artifact[jar:com.jcraft:jsch:0.1.42] > to[lib/jsch-0.1.42.jar] > [INFO] Copying artifact[jar:org.apache.mina:mina-core:2.0.1] > to[lib/mina-core-2.0.1.jar] > [INFO] Copying artifact[jar:org.apache.sshd:sshd-core:0.6.0] > to[lib/sshd-core-0.6.0.jar] > [INFO] Copying artifact[jar:commons-lang:commons-lang:2.4] > to[lib/commons-lang-2.4.jar] > [INFO] Copying artifact[jar:org.apache.xmlrpc:xmlrpc-client:3.1.3] > to[lib/xmlrpc-client-3.1.3.jar] > [INFO] Copying artifact[jar:org.apache.xmlrpc:xmlrpc-common:3.1.3] > to[lib/xmlrpc-common-3.1.3.jar] > [INFO] Copying > artifact[jar:org.apache.ws.commons.util:ws-commons-util:1.0.2] > to[lib/ws-commons-util-1.0.2.jar] > [INFO] Copying > artifact[jar:org.springframework:spring-jdbc:2.5.6.SEC02] > to[lib/spring-jdbc-2.5.6.SEC02.jar] > [INFO] Copying > artifact[jar:org.springframework:spring-tx:2.5.6.SEC02] > to[lib/spring-tx-2.5.6.SEC02.jar] > [INFO] Copying > artifact[jar:org.springframework.ldap:spring-ldap-core:1.3.0.RELEASE] > to[lib/spring-ldap-core-1.3.0.RELEASE.jar] > [INFO] Copying > artifact[jar:commons-httpclient:commons-httpclient:3.1] > to[lib/commons-httpclient-3.1.jar] > [INFO] Copying artifact[jar:org.quartz-scheduler:quartz:2.1.2] > to[lib/quartz-2.1.2.jar] > [INFO] Copying artifact[jar:c3p0:c3p0:0.9.1.1] > to[lib/c3p0-0.9.1.1.jar] > [INFO] Copying > artifact[jar:org.ovirt.engine.core:searchbackend:3.1.0-0001] > to[lib/searchbackend-3.1.0-0001.jar] > [INFO] Copying > artifact[jar:commons-collections:commons-collections:3.1] > to[lib/commons-collections-3.1.jar] > [INFO] Copying > artifact[jar:org.springframework:spring-core:2.5.6.SEC02] > to[lib/spring-core-2.5.6.SEC02.jar] > [INFO] Copying > artifact[jar:org.springframework:spring-beans:2.5.6.SEC02] > to[lib/spring-beans-2.5.6.SEC02.jar] > [INFO] Copying > artifact[jar:org.springframework:spring-context:2.5.6.SEC02] > to[lib/spring-context-2.5.6.SEC02.jar] > [INFO] Copying artifact[jar:aopalliance:aopalliance:1.0] > to[lib/aopalliance-1.0.jar] > [INFO] Copying > artifact[jar:org.springframework:spring-agent:2.5.6.SEC02] > to[lib/spring-agent-2.5.6.SEC02.jar] > [INFO] Copying > artifact[jar:org.springframework:spring-aop:2.5.6.SEC02] > to[lib/spring-aop-2.5.6.SEC02.jar] > [INFO] Copy ear sources to > /ephemeral0/ovirt_engine_find_bugs/ear/target/engine > [INFO] Could not find manifest file: > /ephemeral0/ovirt_engine_find_bugs/ear/target/engine/META-INF/MANIFEST.MF > - Generating one > [INFO] Building jar: > /ephemeral0/ovirt_engine_find_bugs/ear/target/engine.ear > [INFO] > [INFO] --- maven-dependency-plugin:2.1:copy (copy-quartz-jar) @ > engine-server-ear --- > [INFO] Configured Artifact: org.quartz-scheduler:quartz:2.1.2:jar > [INFO] Copying quartz-2.1.2.jar to > /ephemeral0/ovirt_engine_find_bugs/ear/target/quartz/quartz-2.1.2.jar > [INFO] > [INFO] --- maven-install-plugin:2.3.1:install (default-install) @ > engine-server-ear --- > [INFO] Installing > /ephemeral0/ovirt_engine_find_bugs/ear/target/engine.ear to > /home/jenkins/workspace/ovirt_engine_find_bugs/.repository/org/ovirt/engine/engine-server-ear/3.1.0-0001/engine-server-ear-3.1.0-0001.ear > [INFO] Installing /ephemeral0/ovirt_engine_find_bugs/ear/pom.xml to > /home/jenkins/workspace/ovirt_engine_find_bugs/.repository/org/ovirt/engine/engine-server-ear/3.1.0-0001/engine-server-ear-3.1.0-0001.pom > [INFO] > [INFO] --- findbugs-maven-plugin:2.4.0:findbugs (default-cli) @ > engine-server-ear --- > [INFO] > ------------------------------------------------------------------------ > [INFO] Reactor Summary: > [INFO] > [INFO] oVirt Engine Root Project ......................... SUCCESS > [11.175s] > [INFO] oVirt Build Tools root ............................ SUCCESS > [0.154s] > [INFO] oVirt checkstyle .................................. SUCCESS > [2.925s] > [INFO] oVirt Checkstyle Checks ........................... SUCCESS > [32.541s] > [INFO] oVirt Modules - backend ........................... SUCCESS > [0.137s] > [INFO] oVirt Manager ..................................... SUCCESS > [0.633s] > [INFO] oVirt Modules - manager ........................... SUCCESS > [1.512s] > [INFO] CSharp Compatibility .............................. SUCCESS > [1:18.689s] > [INFO] Encryption Libraries .............................. SUCCESS > [42.599s] > [INFO] oVirt Tools ....................................... SUCCESS > [0.205s] > [INFO] oVirt Tools Common Library ........................ SUCCESS > [25.939s] > [INFO] Common Code ....................................... SUCCESS > [2:09.368s] > [INFO] Common utilities .................................. SUCCESS > [1:43.075s] > [INFO] Data Access Layer ................................. SUCCESS > [1:39.624s] > [INFO] engine beans ...................................... SUCCESS > [0.237s] > [INFO] engine scheduler bean ............................. SUCCESS > [40.875s] > [INFO] Vds broker ........................................ SUCCESS > [1:44.474s] > [INFO] Search Backend .................................... SUCCESS > [59.374s] > [INFO] Backend Logic @Service bean ....................... SUCCESS > [2:17.939s] > [INFO] oVirt RESTful API Backend Integration ............. SUCCESS > [0.154s] > [INFO] oVirt RESTful API interface ....................... SUCCESS > [0.315s] > [INFO] oVirt Engine API Definition ....................... SUCCESS > [1:32.846s] > [INFO] oVirt Engine API Commom Parent POM ................ SUCCESS > [0.328s] > [INFO] oVirt Engine API Common JAX-RS .................... SUCCESS > [58.151s] > [INFO] oVirt RESTful API Backend Integration Type Mappers SUCCESS > [1:29.592s] > [INFO] oVirt RESTful API Backend Integration JAX-RS Resources > SUCCESS [1:34.159s] > [INFO] oVirt RESTful API Backend Integration Webapp ...... SUCCESS > [12.297s] > [INFO] oVirt Engine Web Root ............................. SUCCESS > [33.235s] > [INFO] oVirt Configuration Tool .......................... SUCCESS > [46.202s] > [INFO] Notifier Service package .......................... SUCCESS > [0.143s] > [INFO] Notifier Service .................................. SUCCESS > [56.794s] > [INFO] Notifier Service Resources ........................ SUCCESS > [9.712s] > [INFO] oVirt Modules - frontend .......................... SUCCESS > [3.064s] > [INFO] oVirt APIs ........................................ SUCCESS > [1.472s] > [INFO] oVirt generic API ................................. SUCCESS > [32.572s] > [INFO] oVirt Modules - webadmin .......................... SUCCESS > [0.146s] > [INFO] oVirt Modules - ui ................................ SUCCESS > [0.250s] > [INFO] Extensions for GWT ................................ SUCCESS > [1:17.416s] > [INFO] UI Utils Compatibility (for UICommon) ............. SUCCESS > [47.857s] > [INFO] Frontend for GWT UI Projects ...................... SUCCESS > [47.153s] > [INFO] UICommon .......................................... SUCCESS > [3:17.484s] > [INFO] UICommonWeb ....................................... SUCCESS > [3:41.508s] > [INFO] oVirt GWT UI common infrastructure ................ SUCCESS > [1:44.412s] > [INFO] WebAdmin .......................................... SUCCESS > [3:28.888s] > [INFO] UserPortal ........................................ SUCCESS > [2:12.619s] > [INFO] oVirt WARs ........................................ SUCCESS > [0.134s] > [INFO] WPF Application Module ............................ SUCCESS > [8.143s] > [INFO] oVirt Web Application Module ...................... SUCCESS > [32.504s] > [INFO] Components Web Application Module ................. SUCCESS > [6.230s] > [INFO] oVirt Server EAR .................................. SUCCESS > [17.227s] > [INFO] > ------------------------------------------------------------------------ > [INFO] BUILD SUCCESS > [INFO] > ------------------------------------------------------------------------ > [INFO] Total time: 23:52.051s (Wall Clock) > [INFO] Finished at: Tue May 22 05:10:14 EDT 2012 > [INFO] Final Memory: 302M/781M > [INFO] > ------------------------------------------------------------------------ > [FINDBUGS] Collecting findbugs analysis files... > [FINDBUGS] Parsing 30 files in > /home/jenkins/workspace/ovirt_engine_find_bugs > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/beans/scheduler/target/findbugsXml.xml > of module with 1 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/beans/vdsbroker/target/findbugsXml.xml > of module with 0 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/bll/target/findbugsXml.xml > of module with 439 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/common/target/findbugsXml.xml > of module with 335 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/compat/target/findbugsXml.xml > of module with 71 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/dal/target/findbugsXml.xml > of module with 27 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/engineencryptutils/target/findbugsXml.xml > of module with 10 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/restapi/interface/common/jaxrs/target/findbugsXml.xml > of module with 18 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/restapi/interface/definition/target/findbugsXml.xml > of module with 1 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/restapi/jaxrs/target/findbugsXml.xml > of module with 23 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/restapi/types/target/findbugsXml.xml > of module with 10 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/root/target/findbugsXml.xml > of module with 5 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/searchbackend/target/findbugsXml.xml > of module with 13 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/utils/target/findbugsXml.xml > of module with 122 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/vdsbroker/target/findbugsXml.xml > of module with 238 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/tools/engine-config/target/findbugsXml.xml > of module with 7 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/tools/engine-notifier/engine-notifier-service/target/findbugsXml.xml > of module with 11 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/tools/engine-tools-common/target/findbugsXml.xml > of module with 0 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/build-tools-root/ovirt-checkstyle-extension/target/findbugsXml.xml > of module with 1 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/api/genericapi/target/findbugsXml.xml > of module with 1 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/wars/rmw-war/target/findbugsXml.xml > of module with 0 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/frontend/target/findbugsXml.xml > of module with 21 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/gwt-common/target/findbugsXml.xml > of module with 65 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/gwt-extension/target/findbugsXml.xml > of module with 29 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/uicommon/target/findbugsXml.xml > of module with 420 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/uicommonweb/target/findbugsXml.xml > of module with 602 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/uicompat/target/findbugsXml.xml > of module with 40 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/userportal-gwtp/target/findbugsXml.xml > of module with 14 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/userportal/target/findbugsXml.xml > of module with 118 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/webadmin/target/findbugsXml.xml > of module with 56 warnings. > [FINDBUGS] Computing warning deltas based on reference build #912 > [FINDBUGS] Using set difference to compute new warnings > Build step 'Publish FindBugs analysis results' changed build result > to UNSTABLE > Email was triggered for: Unstable > Sending email for trigger: Unstable > > From atal at redhat.com Tue May 22 11:35:06 2012 From: atal at redhat.com (avi tal) Date: Tue, 22 May 2012 14:35:06 +0300 Subject: [Engine-devel] network features review In-Reply-To: <4FBB5232.8060004@redhat.com> References: <4FBB5232.8060004@redhat.com> Message-ID: <4FBB79EA.3040404@redhat.com> On 05/22/2012 11:45 AM, Livnat Peer wrote: > Hi All, > > This is a summary of comments we(*) gathered while reviewing the current > network related functionality in oVirt, we'll open the relevant RFE/Bugs > but wanted to share first to get comments: > > > Default Gateway: > ---------------- > current status - > In the UI/API we expose to the user the possibility to configure the > default gateway for the host. We expose this option only when editing > the management network. > > comments - > Apparently we do not configure the host default gateway but the > network gateway. > > 1. We need to fix the phrasing to gateway (not default gateway) not true. especially in linux we configure "default gateway". unlike windows which holds gateway for each interface, linux holds only one default gateway. > 2. Why do we block it for networks which are not the management network because otherwise will have to hold the rhevm in the same network with the hosts. only rhevm bridge is protected from remove and if we'll have gateway configured under other network, removing the network will cause losing of our connectivity to the host (in case rhevm and host are in different networks). > 3. We need to support configuring the host default gateway. ^^ 1. > > > Non VM (Bridge-less) Network: > ----------------------------- > current status - > During bootstrap we configure the management network on the host. We did > not implement configuring bridge-less management network during bootstrap. > > comments - > 1. Supporting bridge-less network is a new feature,the design of this > feature did not include changing the bootstrap process which make this > feature non-useful when it comes to management network. > > Today one can edit a network only when it is not attached to clusters, > at this point you can change the management network to be non-VM > network, the problem is that we configure the management network on the > host during bootstrap and we do not get a parameter if to create a > bridge or not (we always create a bridge). > > What we end up with is - we can't change the management network once we > added clusters/hosts but if changing it before attaching a cluster we > ignore it in the bootstrap process. Agree, actually bootstrap should configure rhevm network as bridgeless network by default. We should be able to convert rhevm to bridged network after installVds. > > > Check connectivity: > -------------------- > current status - > The 'check connectivity' functionality is available only when editing > the management network, it validates that we did not loose connectivity > to the host, if we did the changes are rolled backed automatically. > > comments - > 1. Sometimes when changing configuration of another network we can > 'damage' the connectivity to the host. We want to expose the check > connectivity functionality on any network configuration change. I believe we should think about the entire check connectivity mechanism. Check connectivity shouldn't rely on the UI check box, it should also run automatically in some cases: 1. edit mgmt network 2. edit other network gateway (if we'll be allowed). 3. MUST, when configuring DHCP on different networks. 4. when running SetupNetwork. because it forces the user to send the management network every time he'd like to update the network. 5. remove network. we should be able to check route table before removing network and if the specific network holds the GATEWAY we should run check connectivity, not before we alert the user. In general, gateway should always be monitored by engine and store in DB: which interface holds the gateway etc'. When we'll be able to do so, we should manage this network (that holds the GW) as a "protected network". And also expose it to the UI. > > VLAN tagging of management Network > ----------------------------------- > > current status - > The user can set a VLAN tag on the management network. > > comments - > 1. Any configuration of the management network needs support in the > bootstrap process (see explanation above for bridge-less network) > 2. In case of VLAN tagging it is even more complicated, when adding a > host to oVirt we add it's address and it can not be changed after the > host was added to the system. in the bootstrap process we set the > management network on the nic oVirt engine used to ssh through, unless > the VLAN device is already configured and the IP used for the ssh is > already on this VLAN (for which it will work) we can't set the network > to be on another IP address. > > Rollback network configuration: > -------------------------------- > current status - > We have the option to make changes to the host network configuration > and not persist the changes (they won't survive machine reboot) > > comments - > 1. We are missing the functionality of rolling back the changes (without > rebooting the machine), this functionality is the complementary behavior > of 'save network configuration'. > > > Predefined bonds: > ----------------- > current status - > In the bootstrap process we create bonds0-5 on the hosts and then > we use them when creating a bond on the host > > comments - > 1. Creating the bonds in the host during the bootstrap process is not > needed and we can let the user choose the bond name (limited to bondX) > and create bonds only upon request. > > > Editing Network properties while Network is attached to cluster/s > ------------------------------------------------------------------ > current status - > Changing the network properties is blocked if the network is attached to > a cluster. > > comments - > 1. We should relax this approach. to start with we can enable editing > when there are no active hosts in the cluster/s. > > doing more than the above requires substantially more work both in VDSM > and engine. > > > > Thank you, Livnat > > > (*) we == {Dan Kenigsberg, Igor Lvovsky, Mike Kolesnik, Moti Asayag, > Muli Salem, Alona Kaplan, Livnat Peer} > > (**) We have even longer list for the UI changes needed, for them we'll > open bugs directly to avoid another long email. > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From ilvovsky at redhat.com Tue May 22 11:52:33 2012 From: ilvovsky at redhat.com (Igor Lvovsky) Date: Tue, 22 May 2012 07:52:33 -0400 (EDT) Subject: [Engine-devel] network features review In-Reply-To: <4FBB5232.8060004@redhat.com> References: <4FBB5232.8060004@redhat.com> Message-ID: <06af01cd3812$23d21630$6b764290$@com> > -----Original Message----- > From: engine-devel-bounces at ovirt.org [mailto:engine-devel-bounces at ovirt.org] > On Behalf Of Livnat Peer > Sent: Tuesday, May 22, 2012 11:46 AM > To: engine-devel at ovirt.org > Subject: [Engine-devel] network features review > > Hi All, > > This is a summary of comments we(*) gathered while reviewing the current > network related functionality in oVirt, we'll open the relevant RFE/Bugs but > wanted to share first to get comments: > > > Default Gateway: > ---------------- > current status - > In the UI/API we expose to the user the possibility to configure the > default gateway for the host. We expose this option only when editing > the management network. > > comments - > Apparently we do not configure the host default gateway but the network > gateway. > > 1. We need to fix the phrasing to gateway (not default gateway) 2. Why do we > block it for networks which are not the management network 3. We need to > support configuring the host default gateway. > > > Non VM (Bridge-less) Network: > ----------------------------- > current status - > During bootstrap we configure the management network on the host. We did not > implement configuring bridge-less management network during bootstrap. > > comments - > 1. Supporting bridge-less network is a new feature,the design of this feature > did not include changing the bootstrap process which make this feature non- > useful when it comes to management network. > > Today one can edit a network only when it is not attached to clusters, at this > point you can change the management network to be non-VM network, the problem > is that we configure the management network on the host during bootstrap and > we do not get a parameter if to create a bridge or not (we always create a > bridge). > > What we end up with is - we can't change the management network once we added > clusters/hosts but if changing it before attaching a cluster we ignore it in > the bootstrap process. > > > Check connectivity: > -------------------- > current status - > The 'check connectivity' functionality is available only when editing the > management network, it validates that we did not loose connectivity to the > host, if we did the changes are rolled backed automatically. > > comments - > 1. Sometimes when changing configuration of another network we can 'damage' > the connectivity to the host. We want to expose the check connectivity > functionality on any network configuration change. > > VLAN tagging of management Network > ----------------------------------- > > current status - > The user can set a VLAN tag on the management network. > > comments - > 1. Any configuration of the management network needs support in the bootstrap > process (see explanation above for bridge-less network) 2. In case of VLAN > tagging it is even more complicated, when adding a host to oVirt we add it's > address and it can not be changed after the host was added to the system. in > the bootstrap process we set the management network on the nic oVirt engine > used to ssh through, unless the VLAN device is already configured and the IP > used for the ssh is already on this VLAN (for which it will work) we can't set > the network to be on another IP address. > > Rollback network configuration: > -------------------------------- > current status - > We have the option to make changes to the host network configuration and not > persist the changes (they won't survive machine reboot) Actually, I think they will not survive even vdsm restart. > > comments - > 1. We are missing the functionality of rolling back the changes (without > rebooting the machine), As above, without vdsm restart, not necessarily machine reboot > this functionality is the complementary behavior of > 'save network configuration'. > > > Predefined bonds: > ----------------- > current status - > In the bootstrap process we create bonds0-5 on the hosts and then we use them > when creating a bond on the host > > comments - > 1. Creating the bonds in the host during the bootstrap process is not needed > and we can let the user choose the bond name (limited to bondX) and create > bonds only upon request. > > > Editing Network properties while Network is attached to cluster/s > ------------------------------------------------------------------ > current status - > Changing the network properties is blocked if the network is attached to a > cluster. > > comments - > 1. We should relax this approach. to start with we can enable editing when > there are no active hosts in the cluster/s. > > doing more than the above requires substantially more work both in VDSM and > engine. > > > > Thank you, Livnat > > > (*) we == {Dan Kenigsberg, Igor Lvovsky, Mike Kolesnik, Moti Asayag, Muli > Salem, Alona Kaplan, Livnat Peer} > > (**) We have even longer list for the UI changes needed, for them we'll open > bugs directly to avoid another long email. > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From lpeer at redhat.com Tue May 22 12:06:56 2012 From: lpeer at redhat.com (Livnat Peer) Date: Tue, 22 May 2012 15:06:56 +0300 Subject: [Engine-devel] network features review In-Reply-To: <4FBB79EA.3040404@redhat.com> References: <4FBB5232.8060004@redhat.com> <4FBB79EA.3040404@redhat.com> Message-ID: <4FBB8160.1090206@redhat.com> On 22/05/12 14:35, avi tal wrote: > On 05/22/2012 11:45 AM, Livnat Peer wrote: >> Hi All, >> >> This is a summary of comments we(*) gathered while reviewing the current >> network related functionality in oVirt, we'll open the relevant RFE/Bugs >> but wanted to share first to get comments: >> >> >> Default Gateway: >> ---------------- >> current status - >> In the UI/API we expose to the user the possibility to configure the >> default gateway for the host. We expose this option only when editing >> the management network. >> >> comments - >> Apparently we do not configure the host default gateway but the >> network gateway. >> >> 1. We need to fix the phrasing to gateway (not default gateway) > not true. especially in linux we configure "default gateway". unlike > windows which holds gateway for each interface, linux holds only one > default gateway. I'll leave this one to Danken. >> 2. Why do we block it for networks which are not the management network > because otherwise will have to hold the rhevm in the same network with > the hosts. > only rhevm bridge is protected from remove and if we'll have gateway > configured under other network, removing the network will cause losing > of our connectivity to the host (in case rhevm and host are in different > networks). >> 3. We need to support configuring the host default gateway. > ^^ 1. >> >> >> Non VM (Bridge-less) Network: >> ----------------------------- >> current status - >> During bootstrap we configure the management network on the host. We did >> not implement configuring bridge-less management network during >> bootstrap. >> >> comments - >> 1. Supporting bridge-less network is a new feature,the design of this >> feature did not include changing the bootstrap process which make this >> feature non-useful when it comes to management network. >> >> Today one can edit a network only when it is not attached to clusters, >> at this point you can change the management network to be non-VM >> network, the problem is that we configure the management network on the >> host during bootstrap and we do not get a parameter if to create a >> bridge or not (we always create a bridge). >> >> What we end up with is - we can't change the management network once we >> added clusters/hosts but if changing it before attaching a cluster we >> ignore it in the bootstrap process. > Agree, actually bootstrap should configure rhevm network as bridgeless > network by default. > We should be able to convert rhevm to bridged network after installVds. >> >> >> Check connectivity: >> -------------------- >> current status - >> The 'check connectivity' functionality is available only when editing >> the management network, it validates that we did not loose connectivity >> to the host, if we did the changes are rolled backed automatically. >> >> comments - >> 1. Sometimes when changing configuration of another network we can >> 'damage' the connectivity to the host. We want to expose the check >> connectivity functionality on any network configuration change. > I believe we should think about the entire check connectivity mechanism. > Check connectivity shouldn't rely on the UI check box, it should also > run automatically in some cases: It should not run automatically because what it does is not only check connectivity but also rolls back changes if we loose connectivity. Let's assume the administrator would like to move the management from one network to another, he is doing the configuration through RHEVM, looses connectivity and then goes and physically changes the cables. In the above case it is ok to loose connectivity and I don't want my changes to roll back. > 1. edit mgmt network > 2. edit other network gateway (if we'll be allowed). > 3. MUST, when configuring DHCP on different networks. > 4. when running SetupNetwork. because it forces the user to send the > management network every time he'd like to update the network. > 5. remove network. we should be able to check route table before > removing network and if the specific network holds the GATEWAY we should > run check connectivity, not before we alert the user. > > In general, gateway should always be monitored by engine and store in > DB: which interface holds the gateway etc'. > When we'll be able to do so, we should manage this network (that holds > the GW) as a "protected network". > And also expose it to the UI. >> >> VLAN tagging of management Network >> ----------------------------------- >> >> current status - >> The user can set a VLAN tag on the management network. >> >> comments - >> 1. Any configuration of the management network needs support in the >> bootstrap process (see explanation above for bridge-less network) >> 2. In case of VLAN tagging it is even more complicated, when adding a >> host to oVirt we add it's address and it can not be changed after the >> host was added to the system. in the bootstrap process we set the >> management network on the nic oVirt engine used to ssh through, unless >> the VLAN device is already configured and the IP used for the ssh is >> already on this VLAN (for which it will work) we can't set the network >> to be on another IP address. >> >> Rollback network configuration: >> -------------------------------- >> current status - >> We have the option to make changes to the host network configuration >> and not persist the changes (they won't survive machine reboot) >> >> comments - >> 1. We are missing the functionality of rolling back the changes (without >> rebooting the machine), this functionality is the complementary behavior >> of 'save network configuration'. >> >> >> Predefined bonds: >> ----------------- >> current status - >> In the bootstrap process we create bonds0-5 on the hosts and then >> we use them when creating a bond on the host >> >> comments - >> 1. Creating the bonds in the host during the bootstrap process is not >> needed and we can let the user choose the bond name (limited to bondX) >> and create bonds only upon request. >> >> >> Editing Network properties while Network is attached to cluster/s >> ------------------------------------------------------------------ >> current status - >> Changing the network properties is blocked if the network is attached to >> a cluster. >> >> comments - >> 1. We should relax this approach. to start with we can enable editing >> when there are no active hosts in the cluster/s. >> >> doing more than the above requires substantially more work both in VDSM >> and engine. >> >> >> >> Thank you, Livnat >> >> >> (*) we == {Dan Kenigsberg, Igor Lvovsky, Mike Kolesnik, Moti Asayag, >> Muli Salem, Alona Kaplan, Livnat Peer} >> >> (**) We have even longer list for the UI changes needed, for them we'll >> open bugs directly to avoid another long email. >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel > From eedri at redhat.com Tue May 22 12:33:16 2012 From: eedri at redhat.com (Eyal Edri) Date: Tue, 22 May 2012 08:33:16 -0400 (EDT) Subject: [Engine-devel] [oVirt Jenkins] ovirt_engine_find_bugs - Build # 915 - Still Unstable! In-Reply-To: <26a5febe-ee42-42a2-aaad-9752147a512b@zmail17.collab.prod.int.phx2.redhat.com> Message-ID: <1062332a-4565-4a8d-abe3-623208eec737@zmail17.collab.prod.int.phx2.redhat.com> FYI, In order to test if your commit adds new findbugs warning (before you commit it), please run the following mvn command: #mvn install -DskipTests findbugs:findbugs. the results can be checked manually in the xml files or via the findbugs plugin to jenkins. we hope to add jenkins verification jobs on gerrit patches soon, once we'll have more powerfull jenkins slaves to handle the extra load from multiple gerrit patches. Eyal. ----- Original Message ----- > From: "Eyal Edri" > To: engine-devel at ovirt.org > Cc: engine-patches at ovirt.org > Sent: Tuesday, May 22, 2012 12:49:37 PM > Subject: Re: [oVirt Jenkins] ovirt_engine_find_bugs - Build # 915 - Still Unstable! > > FYI, > > These set of patches introduced new HIGH findbugs warnings: > > http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/913/changes: > > > webadmin: Gluster Volume Options - populating from help xml (details) > webadmin: Gluster Brick sub tab - removing columns (details) > webadmin: Support for mode specific Tabs and Sub Tabs (details) > restapi: Gluster Resources Implementation classes (details) > restapi: RSDL metadata for gluster related REST api (details) > restapi: Gluster Volumes Collection implementation (details) > engine: Add ID fields to gluster brick and option (details) > webadmin: Gluster Volume - add bricks enabling (#823284) (details) > webadmin: Gluster Volume - upadting actions (#823273) (details) > webadmin: Gluster Volume - validations fixed (#823277) (details) > > bugs appear to be in GlusterVolumeEntity.java: > > http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/913/findbugsResult/HIGH/source.676/#375 > http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/913/findbugsResult/HIGH/? > > Please review and handle, > > Eyal Edri > oVirt Infra Team > > > ----- Original Message ----- > > From: "Jenkins oVirt Server" > > To: eedri at redhat.com, engine-patches at ovirt.org, oliel at redhat.com, > > yzaslavs at redhat.com, amureini at redhat.com, > > dfediuck at redhat.com > > Sent: Tuesday, May 22, 2012 12:11:33 PM > > Subject: [oVirt Jenkins] ovirt_engine_find_bugs - Build # 915 - > > Still Unstable! > > > > Project: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/ > > Build: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/915/ > > Build Number: 915 > > Build Status: Still Unstable > > Triggered By: Started by upstream project "ovirt_engine" build > > number > > 1,240 > > > > ------------------------------------- > > Changes Since Last Success: > > ------------------------------------- > > Changes for Build #913 > > [gchaplik] webadmin: Gluster Volume Options - populating from help > > xml > > > > [gchaplik] webadmin: Gluster Brick sub tab - removing columns > > > > [gchaplik] webadmin: Support for mode specific Tabs and Sub Tabs > > > > [sanjal] restapi: Gluster Resources Implementation classes > > > > [sanjal] restapi: RSDL metadata for gluster related REST api > > > > [sanjal] restapi: Gluster Volumes Collection implementation > > > > [sanjal] engine: Add ID fields to gluster brick and option > > > > [gchaplik] webadmin: Gluster Volume - add bricks enabling (#823284) > > > > [gchaplik] webadmin: Gluster Volume - upadting actions (#823273) > > > > [gchaplik] webadmin: Gluster Volume - validations fixed (#823277) > > > > > > Changes for Build #914 > > [emesika] core:dbfunctions.sh script needs to be compatible with > > DWH > > > > [mpastern] restapi: fix rsdl regression > > > > > > Changes for Build #915 > > [dfediuck] core: Use same ids for artifacts and plugins > > > > [amureini] core: Allow admin permissions in user views > > > > [amureini] core: Roles commands cleanup > > > > [amureini] core: Cleanup Permissions Commands > > > > [amureini] core: Roles commands - use the cached getRole() > > > > [amureini] core: is_inheritable property to MLA entities > > > > > > > > > > ----------------- > > Failed Tests: > > ----------------- > > No tests ran. > > > > ------------------ > > Build Log: > > ------------------ > > [...truncated 4148 lines...] > > [INFO] Assembling webapp [userportal] in > > [/ephemeral0/ovirt_engine_find_bugs/frontend/webadmin/modules/userportal-gwtp/target/userportal-3.1.0-0001] > > [INFO] Processing war project > > [INFO] Copying webapp resources > > [/ephemeral0/ovirt_engine_find_bugs/frontend/webadmin/modules/userportal-gwtp/src/main/webapp] > > [INFO] Webapp assembled in [147 msecs] > > [INFO] Building war: > > /ephemeral0/ovirt_engine_find_bugs/frontend/webadmin/modules/userportal-gwtp/target/userportal-3.1.0-0001.war > > [INFO] WEB-INF/web.xml already added, skipping > > [INFO] > > [INFO] --- maven-install-plugin:2.3.1:install (default-install) @ > > userportal --- > > [INFO] Installing > > /ephemeral0/ovirt_engine_find_bugs/frontend/webadmin/modules/userportal-gwtp/target/userportal-3.1.0-0001.war > > to > > /home/jenkins/workspace/ovirt_engine_find_bugs/.repository/org/ovirt/engine/ui/userportal/3.1.0-0001/userportal-3.1.0-0001.war > > [INFO] Installing > > /ephemeral0/ovirt_engine_find_bugs/frontend/webadmin/modules/userportal-gwtp/pom.xml > > to > > /home/jenkins/workspace/ovirt_engine_find_bugs/.repository/org/ovirt/engine/ui/userportal/3.1.0-0001/userportal-3.1.0-0001.pom > > [INFO] > > [INFO] --- findbugs-maven-plugin:2.4.0:findbugs (default-cli) @ > > userportal --- > > [INFO] Fork Value is true > > [INFO] > > [INFO] --- maven-checkstyle-plugin:2.6:check (default) @ webadmin > > --- > > [INFO] Starting audit... > > Audit done. > > > > [INFO] > > [INFO] --- maven-resources-plugin:2.5:testResources > > (default-testResources) @ webadmin --- > > [debug] execute contextualize > > [INFO] Using 'UTF-8' encoding to copy filtered resources. > > [INFO] skip non existing resourceDirectory > > /ephemeral0/ovirt_engine_find_bugs/frontend/webadmin/modules/webadmin/src/test/resources > > [INFO] > > [INFO] --- maven-compiler-plugin:2.3.2:testCompile > > (default-testCompile) @ webadmin --- > > [INFO] No sources to compile > > [INFO] > > [INFO] --- maven-surefire-plugin:2.10:test (default-test) @ > > webadmin > > --- > > [INFO] Tests are skipped. > > [INFO] > > [INFO] --- maven-war-plugin:2.1.1:war (default-war) @ webadmin --- > > [INFO] Packaging webapp > > [INFO] Assembling webapp [webadmin] in > > [/ephemeral0/ovirt_engine_find_bugs/frontend/webadmin/modules/webadmin/target/webadmin-3.1.0-0001] > > [INFO] Processing war project > > [INFO] Copying webapp resources > > [/ephemeral0/ovirt_engine_find_bugs/frontend/webadmin/modules/webadmin/src/main/webapp] > > [INFO] Webapp assembled in [147 msecs] > > OpenJDK 64-Bit Server VM warning: CodeCache is full. Compiler has > > been disabled. > > OpenJDK 64-Bit Server VM warning: Try increasing the code cache > > size > > using -XX:ReservedCodeCacheSize= > > [INFO] Building war: > > /ephemeral0/ovirt_engine_find_bugs/frontend/webadmin/modules/webadmin/target/webadmin-3.1.0-0001.war > > [INFO] WEB-INF/web.xml already added, skipping > > [INFO] > > [INFO] --- maven-install-plugin:2.3.1:install (default-install) @ > > webadmin --- > > [INFO] Installing > > /ephemeral0/ovirt_engine_find_bugs/frontend/webadmin/modules/webadmin/target/webadmin-3.1.0-0001.war > > to > > /home/jenkins/workspace/ovirt_engine_find_bugs/.repository/org/ovirt/engine/ui/webadmin/3.1.0-0001/webadmin-3.1.0-0001.war > > [INFO] Installing > > /ephemeral0/ovirt_engine_find_bugs/frontend/webadmin/modules/webadmin/pom.xml > > to > > /home/jenkins/workspace/ovirt_engine_find_bugs/.repository/org/ovirt/engine/ui/webadmin/3.1.0-0001/webadmin-3.1.0-0001.pom > > [INFO] > > [INFO] --- findbugs-maven-plugin:2.4.0:findbugs (default-cli) @ > > webadmin --- > > [INFO] Fork Value is true > > [java] Warnings generated: 14 > > [INFO] Done FindBugs Analysis.... > > [java] Warnings generated: 56 > > [INFO] Done FindBugs Analysis.... > > [INFO] > > [INFO] > > ------------------------------------------------------------------------ > > [INFO] Building oVirt Server EAR 3.1.0-0001 > > [INFO] > > ------------------------------------------------------------------------ > > [WARNING] The POM for > > org.codehaus.mojo:gwt-maven-plugin:jar:1.3.2.google is missing, no > > dependency information available > > [WARNING] Failed to retrieve plugin descriptor for > > org.codehaus.mojo:gwt-maven-plugin:1.3.2.google: Plugin > > org.codehaus.mojo:gwt-maven-plugin:1.3.2.google or one of its > > dependencies could not be resolved: Failed to read artifact > > descriptor for org.codehaus.mojo:gwt-maven-plugin:jar:1.3.2.google > > [WARNING] > > ***************************************************************** > > [WARNING] * Your build is requesting parallel execution, but > > project > > * > > [WARNING] * contains the following plugin(s) that are not marked as > > * > > [WARNING] * @threadSafe to support parallel building. > > * > > [WARNING] * While this /may/ work fine, please look for plugin > > updates * > > [WARNING] * and/or request plugins be made thread-safe. > > * > > [WARNING] * If reporting an issue, report it against the plugin in > > * > > [WARNING] * question, not against maven-core > > * > > [WARNING] > > ***************************************************************** > > [WARNING] The following plugins are not marked @threadSafe in oVirt > > Server EAR: > > [WARNING] org.apache.maven.plugins:maven-dependency-plugin:2.1 > > [WARNING] > > ***************************************************************** > > [INFO] > > [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ > > engine-server-ear --- > > [INFO] Deleting /ephemeral0/ovirt_engine_find_bugs/ear/target > > [INFO] > > [INFO] --- maven-ear-plugin:2.6:generate-application-xml > > (default-generate-application-xml) @ engine-server-ear --- > > [INFO] Generating application.xml > > [INFO] > > [INFO] --- maven-resources-plugin:2.4.3:resources > > (default-resources) > > @ engine-server-ear --- > > [INFO] Using 'UTF-8' encoding to copy filtered resources. > > [INFO] skip non existing resourceDirectory > > /ephemeral0/ovirt_engine_find_bugs/ear/src/main/java > > [INFO] skip non existing resourceDirectory > > /ephemeral0/ovirt_engine_find_bugs/ear/src/main/resources > > [INFO] > > [INFO] --- maven-ear-plugin:2.6:ear (default-ear) @ > > engine-server-ear > > --- > > [INFO] Copying > > artifact[jar:org.ovirt.engine.core:common:3.1.0-0001] > > to[lib/engine-common.jar] > > [INFO] Copying > > artifact[jar:org.ovirt.engine.core:compat:3.1.0-0001] > > to[lib/engine-compat.jar] > > [INFO] Copying artifact[jar:org.ovirt.engine.core:dal:3.1.0-0001] > > to[lib/engine-dal.jar] > > [INFO] Copying artifact[jar:org.ovirt.engine.core:utils:3.1.0-0001] > > to[lib/engine-utils.jar] > > [INFO] Copying > > artifact[jar:org.ovirt.engine.core:engineencryptutils:3.1.0-0001] > > to[lib/engine-encryptutils.jar] > > [INFO] Copying > > artifact[jar:org.ovirt.engine.core:vdsbroker:3.1.0-0001] > > to[lib/engine-vdsbroker.jar] > > [INFO] Copying > > artifact[war:org.ovirt.engine.core:root-war:3.1.0-0001] > > to[root.war] > > (unpacked) > > [INFO] Copying artifact[war:org.ovirt.engine.ui:rmw-war:3.1.0-0001] > > to[ovirtengineweb.war] (unpacked) > > [INFO] Copying artifact[war:org.ovirt.engine.ui:rm-war:3.1.0-0001] > > to[ovirtengine.war] (unpacked) > > [INFO] Copying > > artifact[war:org.ovirt.engine.ui:components-war:3.1.0-0001] > > to[components.war] (unpacked) > > [INFO] Copying > > artifact[war:org.ovirt.engine.api:restapi-webapp:3.1.0-0001] > > to[restapi.war] (unpacked) > > [INFO] Copying > > artifact[war:org.ovirt.engine.ui:userportal:3.1.0-0001] > > to[userportal.war] (unpacked) > > [INFO] Copying > > artifact[war:org.ovirt.engine.ui:webadmin:3.1.0-0001] > > to[webadmin.war] (unpacked) > > [INFO] Copying > > artifact[ejb:org.ovirt.engine.ui:genericapi:3.1.0-0001] > > to[engine-genericapi.jar] (unpacked) > > [INFO] Copying > > artifact[ejb:org.ovirt.engine.core:scheduler:3.1.0-0001] > > to[engine-scheduler.jar] (unpacked) > > [INFO] Copying artifact[ejb:org.ovirt.engine.core:bll:3.1.0-0001] > > to[engine-bll.jar] (unpacked) > > [INFO] Copying artifact[jar:commons-codec:commons-codec:1.4] > > to[lib/commons-codec-1.4.jar] > > [INFO] Copying > > artifact[jar:org.hibernate:hibernate-validator:4.0.2.GA] > > to[lib/hibernate-validator-4.0.2.GA.jar] > > [INFO] Copying > > artifact[jar:javax.validation:validation-api:1.0.0.GA] > > to[lib/validation-api-1.0.0.GA.jar] > > [INFO] Copying artifact[jar:org.slf4j:slf4j-api:1.5.6] > > to[lib/slf4j-api-1.5.6.jar] > > [INFO] Copying artifact[jar:javax.xml.bind:jaxb-api:2.1] > > to[lib/jaxb-api-2.1.jar] > > [INFO] Copying artifact[jar:javax.xml.stream:stax-api:1.0-2] > > to[lib/stax-api-1.0-2.jar] > > [INFO] Copying artifact[jar:javax.activation:activation:1.1] > > to[lib/activation-1.1.jar] > > [INFO] Copying artifact[jar:com.sun.xml.bind:jaxb-impl:2.1.3] > > to[lib/jaxb-impl-2.1.3.jar] > > [INFO] Copying > > artifact[jar:org.hibernate:hibernate-annotations:3.4.0.GA] > > to[lib/hibernate-annotations-3.4.0.GA.jar] > > [INFO] Copying > > artifact[jar:org.hibernate:ejb3-persistence:1.0.2.GA] > > to[lib/ejb3-persistence-1.0.2.GA.jar] > > [INFO] Copying > > artifact[jar:org.hibernate:hibernate-commons-annotations:3.1.0.GA] > > to[lib/hibernate-commons-annotations-3.1.0.GA.jar] > > [INFO] Copying artifact[jar:org.hibernate:hibernate-core:3.3.0.SP1] > > to[lib/hibernate-core-3.3.0.SP1.jar] > > [INFO] Copying artifact[jar:antlr:antlr:2.7.6] > > to[lib/antlr-2.7.6.jar] > > [INFO] Copying artifact[jar:dom4j:dom4j:1.6.1] > > to[lib/dom4j-1.6.1.jar] > > [INFO] Copying artifact[jar:xml-apis:xml-apis:1.0.b2] > > to[lib/xml-apis-1.0.b2.jar] > > [INFO] Copying > > artifact[jar:org.codehaus.jackson:jackson-mapper-asl:1.9.4] > > to[lib/jackson-mapper-asl-1.9.4.jar] > > [INFO] Copying > > artifact[jar:org.codehaus.jackson:jackson-core-asl:1.9.4] > > to[lib/jackson-core-asl-1.9.4.jar] > > [INFO] Copying > > artifact[jar:org.jboss.spec.javax.interceptor:jboss-interceptors-api_1.1_spec:1.0.0.Final] > > to[lib/jboss-interceptors-api_1.1_spec-1.0.0.Final.jar] > > [INFO] Copying > > artifact[jar:org.ovirt.engine.core:engine-tools-common:3.1.0-0001] > > to[lib/engine-tools-common-3.1.0-0001.jar] > > [INFO] Copying > > artifact[jar:commons-beanutils:commons-beanutils:1.8.2] > > to[lib/commons-beanutils-1.8.2.jar] > > [INFO] Copying artifact[jar:com.jcraft:jsch:0.1.42] > > to[lib/jsch-0.1.42.jar] > > [INFO] Copying artifact[jar:org.apache.mina:mina-core:2.0.1] > > to[lib/mina-core-2.0.1.jar] > > [INFO] Copying artifact[jar:org.apache.sshd:sshd-core:0.6.0] > > to[lib/sshd-core-0.6.0.jar] > > [INFO] Copying artifact[jar:commons-lang:commons-lang:2.4] > > to[lib/commons-lang-2.4.jar] > > [INFO] Copying artifact[jar:org.apache.xmlrpc:xmlrpc-client:3.1.3] > > to[lib/xmlrpc-client-3.1.3.jar] > > [INFO] Copying artifact[jar:org.apache.xmlrpc:xmlrpc-common:3.1.3] > > to[lib/xmlrpc-common-3.1.3.jar] > > [INFO] Copying > > artifact[jar:org.apache.ws.commons.util:ws-commons-util:1.0.2] > > to[lib/ws-commons-util-1.0.2.jar] > > [INFO] Copying > > artifact[jar:org.springframework:spring-jdbc:2.5.6.SEC02] > > to[lib/spring-jdbc-2.5.6.SEC02.jar] > > [INFO] Copying > > artifact[jar:org.springframework:spring-tx:2.5.6.SEC02] > > to[lib/spring-tx-2.5.6.SEC02.jar] > > [INFO] Copying > > artifact[jar:org.springframework.ldap:spring-ldap-core:1.3.0.RELEASE] > > to[lib/spring-ldap-core-1.3.0.RELEASE.jar] > > [INFO] Copying > > artifact[jar:commons-httpclient:commons-httpclient:3.1] > > to[lib/commons-httpclient-3.1.jar] > > [INFO] Copying artifact[jar:org.quartz-scheduler:quartz:2.1.2] > > to[lib/quartz-2.1.2.jar] > > [INFO] Copying artifact[jar:c3p0:c3p0:0.9.1.1] > > to[lib/c3p0-0.9.1.1.jar] > > [INFO] Copying > > artifact[jar:org.ovirt.engine.core:searchbackend:3.1.0-0001] > > to[lib/searchbackend-3.1.0-0001.jar] > > [INFO] Copying > > artifact[jar:commons-collections:commons-collections:3.1] > > to[lib/commons-collections-3.1.jar] > > [INFO] Copying > > artifact[jar:org.springframework:spring-core:2.5.6.SEC02] > > to[lib/spring-core-2.5.6.SEC02.jar] > > [INFO] Copying > > artifact[jar:org.springframework:spring-beans:2.5.6.SEC02] > > to[lib/spring-beans-2.5.6.SEC02.jar] > > [INFO] Copying > > artifact[jar:org.springframework:spring-context:2.5.6.SEC02] > > to[lib/spring-context-2.5.6.SEC02.jar] > > [INFO] Copying artifact[jar:aopalliance:aopalliance:1.0] > > to[lib/aopalliance-1.0.jar] > > [INFO] Copying > > artifact[jar:org.springframework:spring-agent:2.5.6.SEC02] > > to[lib/spring-agent-2.5.6.SEC02.jar] > > [INFO] Copying > > artifact[jar:org.springframework:spring-aop:2.5.6.SEC02] > > to[lib/spring-aop-2.5.6.SEC02.jar] > > [INFO] Copy ear sources to > > /ephemeral0/ovirt_engine_find_bugs/ear/target/engine > > [INFO] Could not find manifest file: > > /ephemeral0/ovirt_engine_find_bugs/ear/target/engine/META-INF/MANIFEST.MF > > - Generating one > > [INFO] Building jar: > > /ephemeral0/ovirt_engine_find_bugs/ear/target/engine.ear > > [INFO] > > [INFO] --- maven-dependency-plugin:2.1:copy (copy-quartz-jar) @ > > engine-server-ear --- > > [INFO] Configured Artifact: org.quartz-scheduler:quartz:2.1.2:jar > > [INFO] Copying quartz-2.1.2.jar to > > /ephemeral0/ovirt_engine_find_bugs/ear/target/quartz/quartz-2.1.2.jar > > [INFO] > > [INFO] --- maven-install-plugin:2.3.1:install (default-install) @ > > engine-server-ear --- > > [INFO] Installing > > /ephemeral0/ovirt_engine_find_bugs/ear/target/engine.ear to > > /home/jenkins/workspace/ovirt_engine_find_bugs/.repository/org/ovirt/engine/engine-server-ear/3.1.0-0001/engine-server-ear-3.1.0-0001.ear > > [INFO] Installing /ephemeral0/ovirt_engine_find_bugs/ear/pom.xml to > > /home/jenkins/workspace/ovirt_engine_find_bugs/.repository/org/ovirt/engine/engine-server-ear/3.1.0-0001/engine-server-ear-3.1.0-0001.pom > > [INFO] > > [INFO] --- findbugs-maven-plugin:2.4.0:findbugs (default-cli) @ > > engine-server-ear --- > > [INFO] > > ------------------------------------------------------------------------ > > [INFO] Reactor Summary: > > [INFO] > > [INFO] oVirt Engine Root Project ......................... SUCCESS > > [11.175s] > > [INFO] oVirt Build Tools root ............................ SUCCESS > > [0.154s] > > [INFO] oVirt checkstyle .................................. SUCCESS > > [2.925s] > > [INFO] oVirt Checkstyle Checks ........................... SUCCESS > > [32.541s] > > [INFO] oVirt Modules - backend ........................... SUCCESS > > [0.137s] > > [INFO] oVirt Manager ..................................... SUCCESS > > [0.633s] > > [INFO] oVirt Modules - manager ........................... SUCCESS > > [1.512s] > > [INFO] CSharp Compatibility .............................. SUCCESS > > [1:18.689s] > > [INFO] Encryption Libraries .............................. SUCCESS > > [42.599s] > > [INFO] oVirt Tools ....................................... SUCCESS > > [0.205s] > > [INFO] oVirt Tools Common Library ........................ SUCCESS > > [25.939s] > > [INFO] Common Code ....................................... SUCCESS > > [2:09.368s] > > [INFO] Common utilities .................................. SUCCESS > > [1:43.075s] > > [INFO] Data Access Layer ................................. SUCCESS > > [1:39.624s] > > [INFO] engine beans ...................................... SUCCESS > > [0.237s] > > [INFO] engine scheduler bean ............................. SUCCESS > > [40.875s] > > [INFO] Vds broker ........................................ SUCCESS > > [1:44.474s] > > [INFO] Search Backend .................................... SUCCESS > > [59.374s] > > [INFO] Backend Logic @Service bean ....................... SUCCESS > > [2:17.939s] > > [INFO] oVirt RESTful API Backend Integration ............. SUCCESS > > [0.154s] > > [INFO] oVirt RESTful API interface ....................... SUCCESS > > [0.315s] > > [INFO] oVirt Engine API Definition ....................... SUCCESS > > [1:32.846s] > > [INFO] oVirt Engine API Commom Parent POM ................ SUCCESS > > [0.328s] > > [INFO] oVirt Engine API Common JAX-RS .................... SUCCESS > > [58.151s] > > [INFO] oVirt RESTful API Backend Integration Type Mappers SUCCESS > > [1:29.592s] > > [INFO] oVirt RESTful API Backend Integration JAX-RS Resources > > SUCCESS [1:34.159s] > > [INFO] oVirt RESTful API Backend Integration Webapp ...... SUCCESS > > [12.297s] > > [INFO] oVirt Engine Web Root ............................. SUCCESS > > [33.235s] > > [INFO] oVirt Configuration Tool .......................... SUCCESS > > [46.202s] > > [INFO] Notifier Service package .......................... SUCCESS > > [0.143s] > > [INFO] Notifier Service .................................. SUCCESS > > [56.794s] > > [INFO] Notifier Service Resources ........................ SUCCESS > > [9.712s] > > [INFO] oVirt Modules - frontend .......................... SUCCESS > > [3.064s] > > [INFO] oVirt APIs ........................................ SUCCESS > > [1.472s] > > [INFO] oVirt generic API ................................. SUCCESS > > [32.572s] > > [INFO] oVirt Modules - webadmin .......................... SUCCESS > > [0.146s] > > [INFO] oVirt Modules - ui ................................ SUCCESS > > [0.250s] > > [INFO] Extensions for GWT ................................ SUCCESS > > [1:17.416s] > > [INFO] UI Utils Compatibility (for UICommon) ............. SUCCESS > > [47.857s] > > [INFO] Frontend for GWT UI Projects ...................... SUCCESS > > [47.153s] > > [INFO] UICommon .......................................... SUCCESS > > [3:17.484s] > > [INFO] UICommonWeb ....................................... SUCCESS > > [3:41.508s] > > [INFO] oVirt GWT UI common infrastructure ................ SUCCESS > > [1:44.412s] > > [INFO] WebAdmin .......................................... SUCCESS > > [3:28.888s] > > [INFO] UserPortal ........................................ SUCCESS > > [2:12.619s] > > [INFO] oVirt WARs ........................................ SUCCESS > > [0.134s] > > [INFO] WPF Application Module ............................ SUCCESS > > [8.143s] > > [INFO] oVirt Web Application Module ...................... SUCCESS > > [32.504s] > > [INFO] Components Web Application Module ................. SUCCESS > > [6.230s] > > [INFO] oVirt Server EAR .................................. SUCCESS > > [17.227s] > > [INFO] > > ------------------------------------------------------------------------ > > [INFO] BUILD SUCCESS > > [INFO] > > ------------------------------------------------------------------------ > > [INFO] Total time: 23:52.051s (Wall Clock) > > [INFO] Finished at: Tue May 22 05:10:14 EDT 2012 > > [INFO] Final Memory: 302M/781M > > [INFO] > > ------------------------------------------------------------------------ > > [FINDBUGS] Collecting findbugs analysis files... > > [FINDBUGS] Parsing 30 files in > > /home/jenkins/workspace/ovirt_engine_find_bugs > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/beans/scheduler/target/findbugsXml.xml > > of module with 1 warnings. > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/beans/vdsbroker/target/findbugsXml.xml > > of module with 0 warnings. > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/bll/target/findbugsXml.xml > > of module with 439 warnings. > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/common/target/findbugsXml.xml > > of module with 335 warnings. > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/compat/target/findbugsXml.xml > > of module with 71 warnings. > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/dal/target/findbugsXml.xml > > of module with 27 warnings. > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/engineencryptutils/target/findbugsXml.xml > > of module with 10 warnings. > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/restapi/interface/common/jaxrs/target/findbugsXml.xml > > of module with 18 warnings. > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/restapi/interface/definition/target/findbugsXml.xml > > of module with 1 warnings. > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/restapi/jaxrs/target/findbugsXml.xml > > of module with 23 warnings. > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/restapi/types/target/findbugsXml.xml > > of module with 10 warnings. > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/root/target/findbugsXml.xml > > of module with 5 warnings. > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/searchbackend/target/findbugsXml.xml > > of module with 13 warnings. > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/utils/target/findbugsXml.xml > > of module with 122 warnings. > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/vdsbroker/target/findbugsXml.xml > > of module with 238 warnings. > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/tools/engine-config/target/findbugsXml.xml > > of module with 7 warnings. > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/tools/engine-notifier/engine-notifier-service/target/findbugsXml.xml > > of module with 11 warnings. > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/tools/engine-tools-common/target/findbugsXml.xml > > of module with 0 warnings. > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs/build-tools-root/ovirt-checkstyle-extension/target/findbugsXml.xml > > of module with 1 warnings. > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/api/genericapi/target/findbugsXml.xml > > of module with 1 warnings. > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/wars/rmw-war/target/findbugsXml.xml > > of module with 0 warnings. > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/frontend/target/findbugsXml.xml > > of module with 21 warnings. > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/gwt-common/target/findbugsXml.xml > > of module with 65 warnings. > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/gwt-extension/target/findbugsXml.xml > > of module with 29 warnings. > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/uicommon/target/findbugsXml.xml > > of module with 420 warnings. > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/uicommonweb/target/findbugsXml.xml > > of module with 602 warnings. > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/uicompat/target/findbugsXml.xml > > of module with 40 warnings. > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/userportal-gwtp/target/findbugsXml.xml > > of module with 14 warnings. > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/userportal/target/findbugsXml.xml > > of module with 118 warnings. > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/webadmin/target/findbugsXml.xml > > of module with 56 warnings. > > [FINDBUGS] Computing warning deltas based on reference build #912 > > [FINDBUGS] Using set difference to compute new warnings > > Build step 'Publish FindBugs analysis results' changed build result > > to UNSTABLE > > Email was triggered for: Unstable > > Sending email for trigger: Unstable > > > > From masayag at redhat.com Tue May 22 12:39:10 2012 From: masayag at redhat.com (Moti Asayag) Date: Tue, 22 May 2012 15:39:10 +0300 Subject: [Engine-devel] network features review In-Reply-To: <4FBB5232.8060004@redhat.com> References: <4FBB5232.8060004@redhat.com> Message-ID: <4FBB88EE.8070406@redhat.com> On 05/22/2012 11:45 AM, Livnat Peer wrote: > Hi All, > > This is a summary of comments we(*) gathered while reviewing the current > network related functionality in oVirt, we'll open the relevant RFE/Bugs > but wanted to share first to get comments: > > > Default Gateway: > ---------------- > current status - > In the UI/API we expose to the user the possibility to configure the > default gateway for the host. We expose this option only when editing > the management network. > > comments - > Apparently we do not configure the host default gateway but the > network gateway. > > 1. We need to fix the phrasing to gateway (not default gateway) > 2. Why do we block it for networks which are not the management network > 3. We need to support configuring the host default gateway. > > > Non VM (Bridge-less) Network: > ----------------------------- > current status - > During bootstrap we configure the management network on the host. We did > not implement configuring bridge-less management network during bootstrap. > > comments - > 1. Supporting bridge-less network is a new feature,the design of this > feature did not include changing the bootstrap process which make this > feature non-useful when it comes to management network. > > Today one can edit a network only when it is not attached to clusters, > at this point you can change the management network to be non-VM > network, the problem is that we configure the management network on the > host during bootstrap and we do not get a parameter if to create a > bridge or not (we always create a bridge). > > What we end up with is - we can't change the management network once we > added clusters/hosts but if changing it before attaching a cluster we > ignore it in the bootstrap process. > > > Check connectivity: > -------------------- > current status - > The 'check connectivity' functionality is available only when editing > the management network, it validates that we did not loose connectivity > to the host, if we did the changes are rolled backed automatically. > > comments - > 1. Sometimes when changing configuration of another network we can > 'damage' the connectivity to the host. We want to expose the check > connectivity functionality on any network configuration change. > > VLAN tagging of management Network > ----------------------------------- > > current status - > The user can set a VLAN tag on the management network. > > comments - > 1. Any configuration of the management network needs support in the > bootstrap process (see explanation above for bridge-less network) > 2. In case of VLAN tagging it is even more complicated, when adding a > host to oVirt we add it's address and it can not be changed after the > host was added to the system. in the bootstrap process we set the > management network on the nic oVirt engine used to ssh through, unless > the VLAN device is already configured and the IP used for the ssh is > already on this VLAN (for which it will work) we can't set the network > to be on another IP address. > The host IP can be change, however it requires re-installing the host, that runs the bootstrap script. > Rollback network configuration: > -------------------------------- > current status - > We have the option to make changes to the host network configuration > and not persist the changes (they won't survive machine reboot) > > comments - > 1. We are missing the functionality of rolling back the changes (without > rebooting the machine), this functionality is the complementary behavior > of 'save network configuration'. > > > Predefined bonds: > ----------------- > current status - > In the bootstrap process we create bonds0-5 on the hosts and then > we use them when creating a bond on the host minor correction: There are 5 bonds, named bond0-4. > > comments - > 1. Creating the bonds in the host during the bootstrap process is not > needed and we can let the user choose the bond name (limited to bondX) > and create bonds only upon request. > > > Editing Network properties while Network is attached to cluster/s > ------------------------------------------------------------------ > current status - > Changing the network properties is blocked if the network is attached to > a cluster. > > comments - > 1. We should relax this approach. to start with we can enable editing > when there are no active hosts in the cluster/s. Modifying a cluster network with hosts in it seems problematic, since we'd have to propagate the network changes to the hosts. E.g. updating a network to be bridge-less, or tagging a network. Perhaps we should allow updating a network only if the clusters have no hosts at all. > > doing more than the above requires substantially more work both in VDSM > and engine. > Another missing behavior is the capability to refresh Host nics by demand. At the moment it is enabled by activating a host, which requires moving the host to maintenance first or when facing network issues. Else, changes on host nics will not reflect to the ovirt-engine. > > > Thank you, Livnat > > > (*) we == {Dan Kenigsberg, Igor Lvovsky, Mike Kolesnik, Moti Asayag, > Muli Salem, Alona Kaplan, Livnat Peer} > > (**) We have even longer list for the UI changes needed, for them we'll > open bugs directly to avoid another long email. > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From atal at redhat.com Tue May 22 12:53:56 2012 From: atal at redhat.com (avi tal) Date: Tue, 22 May 2012 15:53:56 +0300 Subject: [Engine-devel] network features review In-Reply-To: <4FBB8160.1090206@redhat.com> References: <4FBB5232.8060004@redhat.com> <4FBB79EA.3040404@redhat.com> <4FBB8160.1090206@redhat.com> Message-ID: <4FBB8C64.8050301@redhat.com> On 05/22/2012 03:06 PM, Livnat Peer wrote: > On 22/05/12 14:35, avi tal wrote: >> On 05/22/2012 11:45 AM, Livnat Peer wrote: >>> Hi All, >>> >>> This is a summary of comments we(*) gathered while reviewing the current >>> network related functionality in oVirt, we'll open the relevant RFE/Bugs >>> but wanted to share first to get comments: >>> >>> >>> Default Gateway: >>> ---------------- >>> current status - >>> In the UI/API we expose to the user the possibility to configure the >>> default gateway for the host. We expose this option only when editing >>> the management network. >>> >>> comments - >>> Apparently we do not configure the host default gateway but the >>> network gateway. >>> >>> 1. We need to fix the phrasing to gateway (not default gateway) >> not true. especially in linux we configure "default gateway". unlike >> windows which holds gateway for each interface, linux holds only one >> default gateway. > I'll leave this one to Danken. Running POC in my machine: # cat ifcfg-eth1 DEVICE=eth1 ONBOOT=yes BOOTPROTO=static IPADDR=X.Y.129.10 NETMASK=255.255.255.0 GATEWAY=X.Y.129.254 # cat ifcfg-eth2 DEVICE=eth2 ONBOOT=yes BOOTPROTO=static IPADDR=X.Y.127.10 NETMASK=255.255.255.0 GATEWAY=X.Y.127.254 # cat /etc/sysconfig/network NETWORKING=yes HOSTNAME=... GATEWAY=X.Y.128.254 # service network restart # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface X.Y.129.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 X.Y.127.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2 169.254.0.0 0.0.0.0 255.255.0.0 U 1003 0 0 eth1 169.254.0.0 0.0.0.0 255.255.0.0 U 1004 0 0 eth2 169.254.0.0 0.0.0.0 255.255.0.0 U 1005 0 0 eth3 0.0.0.0 X.Y.127.254 0.0.0.0 UG 0 0 0 eth2 NOTE: we can add static routing to each interface using route- > >>> 2. Why do we block it for networks which are not the management network >> because otherwise will have to hold the rhevm in the same network with >> the hosts. >> only rhevm bridge is protected from remove and if we'll have gateway >> configured under other network, removing the network will cause losing >> of our connectivity to the host (in case rhevm and host are in different >> networks). >>> 3. We need to support configuring the host default gateway. >> ^^ 1. >>> >>> Non VM (Bridge-less) Network: >>> ----------------------------- >>> current status - >>> During bootstrap we configure the management network on the host. We did >>> not implement configuring bridge-less management network during >>> bootstrap. >>> >>> comments - >>> 1. Supporting bridge-less network is a new feature,the design of this >>> feature did not include changing the bootstrap process which make this >>> feature non-useful when it comes to management network. >>> >>> Today one can edit a network only when it is not attached to clusters, >>> at this point you can change the management network to be non-VM >>> network, the problem is that we configure the management network on the >>> host during bootstrap and we do not get a parameter if to create a >>> bridge or not (we always create a bridge). >>> >>> What we end up with is - we can't change the management network once we >>> added clusters/hosts but if changing it before attaching a cluster we >>> ignore it in the bootstrap process. >> Agree, actually bootstrap should configure rhevm network as bridgeless >> network by default. >> We should be able to convert rhevm to bridged network after installVds. >>> >>> Check connectivity: >>> -------------------- >>> current status - >>> The 'check connectivity' functionality is available only when editing >>> the management network, it validates that we did not loose connectivity >>> to the host, if we did the changes are rolled backed automatically. >>> >>> comments - >>> 1. Sometimes when changing configuration of another network we can >>> 'damage' the connectivity to the host. We want to expose the check >>> connectivity functionality on any network configuration change. >> I believe we should think about the entire check connectivity mechanism. >> Check connectivity shouldn't rely on the UI check box, it should also >> run automatically in some cases: > > It should not run automatically because what it does is not only check > connectivity but also rolls back changes if we loose connectivity. > > Let's assume the administrator would like to move the management from > one network to another, he is doing the configuration through RHEVM, > looses connectivity and then goes and physically changes the cables. > > In the above case it is ok to loose connectivity and I don't want my > changes to roll back. > > >> 1. edit mgmt network >> 2. edit other network gateway (if we'll be allowed). >> 3. MUST, when configuring DHCP on different networks. >> 4. when running SetupNetwork. because it forces the user to send the >> management network every time he'd like to update the network. >> 5. remove network. we should be able to check route table before >> removing network and if the specific network holds the GATEWAY we should >> run check connectivity, not before we alert the user. >> >> In general, gateway should always be monitored by engine and store in >> DB: which interface holds the gateway etc'. >> When we'll be able to do so, we should manage this network (that holds >> the GW) as a "protected network". >> And also expose it to the UI. >>> VLAN tagging of management Network >>> ----------------------------------- >>> >>> current status - >>> The user can set a VLAN tag on the management network. >>> >>> comments - >>> 1. Any configuration of the management network needs support in the >>> bootstrap process (see explanation above for bridge-less network) >>> 2. In case of VLAN tagging it is even more complicated, when adding a >>> host to oVirt we add it's address and it can not be changed after the >>> host was added to the system. in the bootstrap process we set the >>> management network on the nic oVirt engine used to ssh through, unless >>> the VLAN device is already configured and the IP used for the ssh is >>> already on this VLAN (for which it will work) we can't set the network >>> to be on another IP address. >>> >>> Rollback network configuration: >>> -------------------------------- >>> current status - >>> We have the option to make changes to the host network configuration >>> and not persist the changes (they won't survive machine reboot) >>> >>> comments - >>> 1. We are missing the functionality of rolling back the changes (without >>> rebooting the machine), this functionality is the complementary behavior >>> of 'save network configuration'. >>> >>> >>> Predefined bonds: >>> ----------------- >>> current status - >>> In the bootstrap process we create bonds0-5 on the hosts and then >>> we use them when creating a bond on the host >>> >>> comments - >>> 1. Creating the bonds in the host during the bootstrap process is not >>> needed and we can let the user choose the bond name (limited to bondX) >>> and create bonds only upon request. >>> >>> >>> Editing Network properties while Network is attached to cluster/s >>> ------------------------------------------------------------------ >>> current status - >>> Changing the network properties is blocked if the network is attached to >>> a cluster. >>> >>> comments - >>> 1. We should relax this approach. to start with we can enable editing >>> when there are no active hosts in the cluster/s. >>> >>> doing more than the above requires substantially more work both in VDSM >>> and engine. >>> >>> >>> >>> Thank you, Livnat >>> >>> >>> (*) we == {Dan Kenigsberg, Igor Lvovsky, Mike Kolesnik, Moti Asayag, >>> Muli Salem, Alona Kaplan, Livnat Peer} >>> >>> (**) We have even longer list for the UI changes needed, for them we'll >>> open bugs directly to avoid another long email. >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel at ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel From lpeer at redhat.com Tue May 22 13:02:11 2012 From: lpeer at redhat.com (Livnat Peer) Date: Tue, 22 May 2012 16:02:11 +0300 Subject: [Engine-devel] network features review In-Reply-To: <4FBB88EE.8070406@redhat.com> References: <4FBB5232.8060004@redhat.com> <4FBB88EE.8070406@redhat.com> Message-ID: <4FBB8E53.9030004@redhat.com> On 22/05/12 15:39, Moti Asayag wrote: > On 05/22/2012 11:45 AM, Livnat Peer wrote: >> Hi All, >> >> This is a summary of comments we(*) gathered while reviewing the current >> network related functionality in oVirt, we'll open the relevant RFE/Bugs >> but wanted to share first to get comments: >> >> >> Default Gateway: >> ---------------- >> current status - >> In the UI/API we expose to the user the possibility to configure the >> default gateway for the host. We expose this option only when editing >> the management network. >> >> comments - >> Apparently we do not configure the host default gateway but the >> network gateway. >> >> 1. We need to fix the phrasing to gateway (not default gateway) >> 2. Why do we block it for networks which are not the management network >> 3. We need to support configuring the host default gateway. >> >> >> Non VM (Bridge-less) Network: >> ----------------------------- >> current status - >> During bootstrap we configure the management network on the host. We did >> not implement configuring bridge-less management network during bootstrap. >> >> comments - >> 1. Supporting bridge-less network is a new feature,the design of this >> feature did not include changing the bootstrap process which make this >> feature non-useful when it comes to management network. >> >> Today one can edit a network only when it is not attached to clusters, >> at this point you can change the management network to be non-VM >> network, the problem is that we configure the management network on the >> host during bootstrap and we do not get a parameter if to create a >> bridge or not (we always create a bridge). >> >> What we end up with is - we can't change the management network once we >> added clusters/hosts but if changing it before attaching a cluster we >> ignore it in the bootstrap process. >> >> >> Check connectivity: >> -------------------- >> current status - >> The 'check connectivity' functionality is available only when editing >> the management network, it validates that we did not loose connectivity >> to the host, if we did the changes are rolled backed automatically. >> >> comments - >> 1. Sometimes when changing configuration of another network we can >> 'damage' the connectivity to the host. We want to expose the check >> connectivity functionality on any network configuration change. >> >> VLAN tagging of management Network >> ----------------------------------- >> >> current status - >> The user can set a VLAN tag on the management network. >> >> comments - >> 1. Any configuration of the management network needs support in the >> bootstrap process (see explanation above for bridge-less network) >> 2. In case of VLAN tagging it is even more complicated, when adding a >> host to oVirt we add it's address and it can not be changed after the >> host was added to the system. in the bootstrap process we set the >> management network on the nic oVirt engine used to ssh through, unless >> the VLAN device is already configured and the IP used for the ssh is >> already on this VLAN (for which it will work) we can't set the network >> to be on another IP address. >> > > The host IP can be change, however it requires re-installing the host, > that runs the bootstrap script. > yes, thanks for the clarification. >> Rollback network configuration: >> -------------------------------- >> current status - >> We have the option to make changes to the host network configuration >> and not persist the changes (they won't survive machine reboot) >> >> comments - >> 1. We are missing the functionality of rolling back the changes (without >> rebooting the machine), this functionality is the complementary behavior >> of 'save network configuration'. >> >> >> Predefined bonds: >> ----------------- >> current status - >> In the bootstrap process we create bonds0-5 on the hosts and then >> we use them when creating a bond on the host > > minor correction: There are 5 bonds, named bond0-4. > >> >> comments - >> 1. Creating the bonds in the host during the bootstrap process is not >> needed and we can let the user choose the bond name (limited to bondX) >> and create bonds only upon request. >> >> >> Editing Network properties while Network is attached to cluster/s >> ------------------------------------------------------------------ >> current status - >> Changing the network properties is blocked if the network is attached to >> a cluster. >> >> comments - >> 1. We should relax this approach. to start with we can enable editing >> when there are no active hosts in the cluster/s. > > Modifying a cluster network with hosts in it seems problematic, since > we'd have to propagate the network changes to the hosts. E.g. updating a > network to be bridge-less, or tagging a network. > > Perhaps we should allow updating a network only if the clusters have no > hosts at all. > yes, I agree. >> >> doing more than the above requires substantially more work both in VDSM >> and engine. >> > > Another missing behavior is the capability to refresh Host nics by > demand. At the moment it is enabled by activating a host, which requires > moving the host to maintenance first or when facing network issues. > Else, changes on host nics will not reflect to the ovirt-engine. > I agree this functionality comes from different areas, not only networking, running getVdsCaps on demand. >> >> >> Thank you, Livnat >> >> >> (*) we == {Dan Kenigsberg, Igor Lvovsky, Mike Kolesnik, Moti Asayag, >> Muli Salem, Alona Kaplan, Livnat Peer} >> >> (**) We have even longer list for the UI changes needed, for them we'll >> open bugs directly to avoid another long email. >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel > From rluxenbe at redhat.com Tue May 22 08:47:50 2012 From: rluxenbe at redhat.com (Roni Luxenberg) Date: Tue, 22 May 2012 04:47:50 -0400 (EDT) Subject: [Engine-devel] oVirt and Quantum In-Reply-To: <4FB5878D.1040209@redhat.com> Message-ID: ----- Original Message ----- > On 05/15/2012 02:55 PM, Irena Berezovsky wrote: > ... > > >> ovirt engine keeps it. how would one query by it though? what api > >> and credentials would they be using to do so? > >> [IB] I think it should be accessible via REST and SDK . > >> I guess it should use admin credentials, but not sure. > > > > REST doesn't support lookup by every property and the is search for > > vnics/ports. > > so a modeling question. > > I'm not sure i like the concept of providing an administrative user > > credentials to all hosts, or of managing a password change in this > > case. > > not sure hosts should use the REST API, or another API intended for > > bi-directional communication with engine, secured in the same way > > the xml/rpc is secured. > > > > [IB2] Considering Quantum plugin implementation, I guess that may > > also handle physical Network configuration (Network between > > Hypervisors). In such case Quantum Plugin will need to resolve for > > VIF UUID plugged to certain network on what Server it is deployed. > > I think is the best way is to get it via SDK or REST. Do you have > > any suggestion? > > from what i understand, this isn't about using quantum for the non vm > networks (management, storage, live migration, etc.) I don't think it is advisable to spread networking configuration and monitoring all over the place. ultimately all network configuration including physical and non vm networks should be owned by a single "network manager", so I think we should aim for augmenting quantum to support that. > we need to find a solution to passing needed info for agents/drivers > through supported communication channels. > yes, the REST API is there, but i don't see a provisioning process > providing hosts with credentials to access the REST API (or as > specified > above, REST API having a query to match the requested information). > > OTOH, it could make sense to have hosts pull various type of > configuration information relevant to them from ovirt engine via an > api > limited to hosts, based on their hosts certificates. > then have agents use this as the supported communication channel. > I think that agents/drivers should only be able to talk back home to the plugin that supervise them. The quantum plugin, in turn, can access ovirt through REST api to get/extract any information needed. > >> > >>>> VM Migrate: > >>>> Even though it's just an initial suggestion, I think that VM > >>>> migration use case should be elaborated also for 'else' cases. > >>>> What > >>>> happens if target Host does not support Quantum? What happens if > >>>> target host fails to run VM? Another issue is a lack of calls to > >>>> Quantum. For my understanding (but I can be wrong) in OpenStack > >>>> it > >>>> will issue unplug and plug attachment calls. > >>> I agree. The goal here should be VM uptime and connectivity. If > >>> the > >>> "network" connectivity can be support but in a limited fashion > >>> then > >>> great - the migration can take place - this should nonetheless > >>> only > >>> be done when there is no other option. The live migration > >>> algorithm > >>> may have to be tweaked to support this. > >> > >> we do not assume involvement in engine in live migration today > >> other than issuing a 'migrate' command to source host, or host > >> needing information from engine to perform the live migration. > >> there must be a very good reason to break this assumption. > >> [IB] If this assumption should be in place, maybe it worth to > >> consider to invoke 'create port' and 'plug interface' Quantum > >> calls from VDSM node and not from oVirt engine. This this the > >> model in OpenStack. Nova-compute invokes 'create port' and 'plug > >> interface' Quantum calls. > >> It is described in the following doc: > >> http://wiki.openstack.org/QuantumAPIUseCases > > > > I'm not sure i like that better. > > would it be possible for engine to pre-provision the port on more > > than one host? > > [IB2] For my understanding, definition of port on the Network just > > defines a logical port and does not apply the physical location. > > Regarding the interface plugging it probably should work for > > plugging same interface more than once temporarily during VM > > migration phase. > > if it doesn't provide physical location, then i am not sure i > understand > why another call is required to begin with? The 'plug interface' is used to instantiate and configure the logical network/port on the destination host as well as on the fabric the host is connected to (adjacent switch, etc.) Thanks, Roni From danken at redhat.com Tue May 22 13:54:09 2012 From: danken at redhat.com (Dan Kenigsberg) Date: Tue, 22 May 2012 16:54:09 +0300 Subject: [Engine-devel] network features review In-Reply-To: <4FBB8C64.8050301@redhat.com> References: <4FBB5232.8060004@redhat.com> <4FBB79EA.3040404@redhat.com> <4FBB8160.1090206@redhat.com> <4FBB8C64.8050301@redhat.com> Message-ID: <20120522135408.GD14013@redhat.com> On Tue, May 22, 2012 at 03:53:56PM +0300, avi tal wrote: > On 05/22/2012 03:06 PM, Livnat Peer wrote: > >On 22/05/12 14:35, avi tal wrote: > >>On 05/22/2012 11:45 AM, Livnat Peer wrote: > >>>Hi All, > >>> > >>>This is a summary of comments we(*) gathered while reviewing the current > >>>network related functionality in oVirt, we'll open the relevant RFE/Bugs > >>>but wanted to share first to get comments: > >>> > >>> > >>>Default Gateway: > >>>---------------- > >>>current status - > >>> In the UI/API we expose to the user the possibility to configure the > >>> default gateway for the host. We expose this option only when editing > >>> the management network. > >>> > >>>comments - > >>>Apparently we do not configure the host default gateway but the > >>>network gateway. > >>> > >>>1. We need to fix the phrasing to gateway (not default gateway) > >>not true. especially in linux we configure "default gateway". unlike > >>windows which holds gateway for each interface, linux holds only one > >>default gateway. > >I'll leave this one to Danken. > > Running POC in my machine: > # cat ifcfg-eth1 > DEVICE=eth1 > ONBOOT=yes > BOOTPROTO=static > IPADDR=X.Y.129.10 > NETMASK=255.255.255.0 > GATEWAY=X.Y.129.254 > > # cat ifcfg-eth2 > DEVICE=eth2 > ONBOOT=yes > BOOTPROTO=static > IPADDR=X.Y.127.10 > NETMASK=255.255.255.0 > GATEWAY=X.Y.127.254 > > # cat /etc/sysconfig/network > NETWORKING=yes > HOSTNAME=... > GATEWAY=X.Y.128.254 > > # service network restart > # route -n > Kernel IP routing table > Destination Gateway Genmask Flags Metric Ref > Use Iface > X.Y.129.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 > X.Y.127.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2 > 169.254.0.0 0.0.0.0 255.255.0.0 U 1003 0 0 eth1 > 169.254.0.0 0.0.0.0 255.255.0.0 U 1004 0 0 eth2 > 169.254.0.0 0.0.0.0 255.255.0.0 U 1005 0 0 eth3 > 0.0.0.0 X.Y.127.254 0.0.0.0 UG 0 0 0 eth2 > > > NOTE: we can add static routing to each interface using route- I am afraid that I've been misleading Livnat and Simon in private communications. I've repressed this fact for a long while, but apparently initscripts's usage of GATEWAY, be it in interface or hostwide config, is to set the host's default gateway. /etc/sysconfig/network-scripts/ifup-eth : if [ -n "${GATEWAY}" ] ...; then ip route replace default ${METRIC:+metric $METRIC} \ via ${GATEWAY} ${WINDOW:+window $WINDOW} ${SRC} \ ${GATEWAYDEV:+dev $GATEWAYDEV} ... This means that oVirt's current behavior is ok as it is - we set GATEWAY for a single network that is always on, and thus control the host's default gateway. From dfediuck at redhat.com Tue May 22 14:05:33 2012 From: dfediuck at redhat.com (Doron Fediuck) Date: Tue, 22 May 2012 17:05:33 +0300 Subject: [Engine-devel] CPU Pinning @engine In-Reply-To: <4FBA0D91.3010905@redhat.com> References: <3818ff2c-7931-4c54-9278-5ceab9790a82@zmail07.collab.prod.int.phx2.redhat.com> <4FB9F5B2.5000006@redhat.com> <4FB9F676.2040100@redhat.com> <4FB9F801.6000109@redhat.com> <4FB9F9ED.7000709@redhat.com> <4FBA0293.6000402@redhat.com> <4FBA0865.9000100@redhat.com> <4FBA0D91.3010905@redhat.com> Message-ID: <4FBB9D2D.5070106@redhat.com> On 21/05/12 12:40, Doron Fediuck wrote: > On 21/05/12 12:18, Yaniv Kaul wrote: >> On 05/21/2012 11:53 AM, Doron Fediuck wrote: >>> On 21/05/12 11:16, Yaniv Kaul wrote: >>>> On 05/21/2012 11:08 AM, Doron Fediuck wrote: >>>>> On 21/05/12 11:01, Dor Laor wrote: >>>>>> On 05/21/2012 10:58 AM, Doron Fediuck wrote: >>>>>>> On 21/05/12 01:45, Andrew Cathrow wrote: >>>>>>>> ----- Original Message ----- >>>>>>>>> From: "Doron Fediuck" >>>>>>>>> To: dlaor at redhat.com >>>>>>>>> Cc: engine-devel at ovirt.org >>>>>>>>> Sent: Sunday, May 20, 2012 5:49:08 PM >>>>>>>>> Subject: Re: [Engine-devel] CPU Pinning @engine >>>>>>>>> >>>>>>>>> On 20/05/12 21:41, Dor Laor wrote: >>>>>>>>>> On 05/17/2012 11:15 PM, Doron Fediuck wrote: >>>>>>>>>>> On 17/05/12 20:28, Ayal Baron wrote: >>>>>>>>>>>> "Live migration will not be supported for such VM's." >>>>>>>>>>>> >>>>>>>>>>>> Migration will work on homogeneous clusters so this should not be >>>>>>>>>>>> enforced (not limited to VMs which are pinned to host) just give >>>>>>>>>>>> a warning. >>>>>>>>>>>> >>>>>>>>>>> I agree, but if we wish to ping vCPUx to pCPUy in host a, we >>>>>>>>>>> cannot ensure to have the same in host b, >>>>>>>>>>> since it may have pCPUy too busy, so performance will degrade. >>>>>>>>>>> Also, I hope you saw my general comment >>>>>>>>>> Performance may degrade on any migration to loaded host regardless >>>>>>>>>> of pinning. >>>>>>>>>> >>>>>>>>>> There is not need to forbid migration. Instead, the SLA assurance >>>>>>>>>> policy should verify the dedicated resources and match the target >>>>>>>>>> w/ the guarantee and decide according to this. >>>>>>>>>> >>>>>>>>> Thanks for the input. >>>>>>>>> We may start with migration blocked in a configurable manner, so >>>>>>>>> people who wish migrate to work >>>>>>>>> will simply set the relevant configuration key. >>>>>>>>> As for looking for a matched CPU, will add it as p2. >>>>>>>> We shouldn't block migration >>>>>>>> If a user wants to not migrate a cpu pinned VM then let them use the non-migratable flag in the UI. >>>>>>>> >>>>>>> We're not blocking migration, we're allowing pinning (for now) only for non-migrative VM's. >>>>>>> For p2 we'll verify destination host has the relevant pinning capacity, which will allow >>>>>>> pinning for migrative VM's as well. >>>>>> IMHO the order should be the opposite - if the user likes to migrate a pinned VM, let him (you can pop some message if you like). >>>>> I'll check it with UI guys (AFAIK engine UI has no pop-ups). >>>>> Also, I prefer safe than sorry. So start with a safe working pinning for pinned-to-host VMs, and then push the envelope. >>>> Safe is letting the user migrate. It may or may not succeed (I'd worry it may put a host into Error state - I hope we've removed this state). >>> This is a pure speculation. If I'm pinning a specific VM to a specific host, and its vCPUS into specific pCPUs, >>> how can live migration be considered a safe thing? If I pinned to host, this is a violation of my request. Now, let's say >>> I didn't pin to host, but I ask for specific vCPUS pinning into specific pCPUs. For now, there's no guarantee the destination >>> host will have a relevant CPU capacity (maybe even topology), so CPU pinning may not work, which is also a violation of >>> my request. Is live migration really the safe thing to do here??? Why not alert me so I could manually migrate to where I think >>> is better? >>> Having that said, I'm reminding you the somewhere earlier in this thread I wrote we'll make the constraint of cpu pinning >>> allowed only on pinned-to-host VMs configurable, so people who wish to walk on wild side, can give it a go. >> >> I think the consensus of the thread is that you should allow pin vCPUs to pCPUs even if the VM is not pinned to host. >> If the user wants to ensure it will not migrate, he should mark the VM as non migratable. >> Otherwise, it may migrate, and will succeed - if it can meet the same pinning requirements on the destination, or fail - and then no harm done. >> If migration succeeds without meeting the pinning requirements on the destination, I see this as a libvirt bug. >> Y. > Basically I already said cpu-pin is allowed for migrative VM's once configuring it. > So basically what you're saying is that if such migration works, while loosing cpu-pin, it's a libvirt bug. > I can live with that. I hope Daniel agrees with you. > Design updated, so pinning is not blocked, unless user will block it (pin to host, etc). UI will be updated shortly. Please review- http://www.ovirt.org/wiki/Features/Design/cpu-pinning >> >>> >>>> Sorry is when you wish you had done so initially. ;-) >>> In this case, I disagree as this is configurable. >>> >>>> Y. >>>> >>>> >>>>>>>>>>> about starting with a humble solution and gradually improving. In >>>>>>>>>>> this context (auto)numa can help us, >>>>>>>>>>> so we better do numa than handle migration for basic mode, risking >>>>>>>>>>> performance issues. >>>>>>>>>>> >>>>>>>>>>>> ----- Original Message ----- >>>>>>>>>>>>> From: "Doron Fediuck" >>>>>>>>>>>>> To: engine-devel at ovirt.org >>>>>>>>>>>>> Sent: Thursday, May 17, 2012 2:42:46 PM >>>>>>>>>>>>> Subject: [Engine-devel] CPU Pinning @engine >>>>>>>>>>>>> >>>>>>>>>>>>> Hi All, >>>>>>>>>>>>> Currently the VDSM has a CPU pinning hook. >>>>>>>>>>>>> We'd like to add better support of it into the engine itself. >>>>>>>>>>>>> Here's a design draft to cover it: >>>>>>>>>>>>> http://www.ovirt.org/wiki/Features/Design/cpu-pinning >>>>>>>>>>>>> >>>>>>>>>>>>> Please review and comment if needed. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks! >>>>>>>>>>>>> -- >>>>>>>>>>>>> >>>>>>>>>>>>> /d >>>>>>>>>>>>> >>>>>>>>>>>>> Never say "OOPS!" always say "Ah, Interesting!" >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Engine-devel mailing list >>>>>>>>>>>>> Engine-devel at ovirt.org >>>>>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Engine-devel mailing list >>>>>>>>>>>> Engine-devel at ovirt.org >>>>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>>>>> -- >>>>>>>>> >>>>>>>>> /d >>>>>>>>> >>>>>>>>> Never say "OOPS!" always say "Ah, Interesting!" >>>>>>>>> _______________________________________________ >>>>>>>>> Engine-devel mailing list >>>>>>>>> Engine-devel at ovirt.org >>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>>>>> >>> >> > > -- /d "Hi, my name is Any Key. Please don't hit me!" From simon at redhat.com Tue May 22 14:42:47 2012 From: simon at redhat.com (Simon Grinberg) Date: Tue, 22 May 2012 10:42:47 -0400 (EDT) Subject: [Engine-devel] network features review In-Reply-To: <20120522135408.GD14013@redhat.com> Message-ID: <633ede84-6798-40ca-989e-b85e3840a120@zmail17.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Dan Kenigsberg" > To: "avi tal" > Cc: engine-devel at ovirt.org > Sent: Tuesday, May 22, 2012 4:54:09 PM > Subject: Re: [Engine-devel] network features review > > On Tue, May 22, 2012 at 03:53:56PM +0300, avi tal wrote: > > On 05/22/2012 03:06 PM, Livnat Peer wrote: > > >On 22/05/12 14:35, avi tal wrote: > > >>On 05/22/2012 11:45 AM, Livnat Peer wrote: > > >>>Hi All, > > >>> > > >>>This is a summary of comments we(*) gathered while reviewing the > > >>>current > > >>>network related functionality in oVirt, we'll open the relevant > > >>>RFE/Bugs > > >>>but wanted to share first to get comments: > > >>> > > >>> > > >>>Default Gateway: > > >>>---------------- > > >>>current status - > > >>> In the UI/API we expose to the user the possibility to > > >>> configure the > > >>> default gateway for the host. We expose this option only > > >>> when editing > > >>> the management network. > > >>> > > >>>comments - > > >>>Apparently we do not configure the host default gateway but the > > >>>network gateway. > > >>> > > >>>1. We need to fix the phrasing to gateway (not default gateway) > > >>not true. especially in linux we configure "default gateway". > > >>unlike > > >>windows which holds gateway for each interface, linux holds only > > >>one > > >>default gateway. > > >I'll leave this one to Danken. > > > > Running POC in my machine: > > # cat ifcfg-eth1 > > DEVICE=eth1 > > ONBOOT=yes > > BOOTPROTO=static > > IPADDR=X.Y.129.10 > > NETMASK=255.255.255.0 > > GATEWAY=X.Y.129.254 > > > > # cat ifcfg-eth2 > > DEVICE=eth2 > > ONBOOT=yes > > BOOTPROTO=static > > IPADDR=X.Y.127.10 > > NETMASK=255.255.255.0 > > GATEWAY=X.Y.127.254 > > > > # cat /etc/sysconfig/network > > NETWORKING=yes > > HOSTNAME=... > > GATEWAY=X.Y.128.254 > > > > # service network restart > > # route -n > > Kernel IP routing table > > Destination Gateway Genmask Flags Metric Ref > > Use Iface > > X.Y.129.0 0.0.0.0 255.255.255.0 U 0 0 > > 0 eth1 > > X.Y.127.0 0.0.0.0 255.255.255.0 U 0 0 > > 0 eth2 > > 169.254.0.0 0.0.0.0 255.255.0.0 U 1003 0 > > 0 eth1 > > 169.254.0.0 0.0.0.0 255.255.0.0 U 1004 0 > > 0 eth2 > > 169.254.0.0 0.0.0.0 255.255.0.0 U 1005 0 > > 0 eth3 > > 0.0.0.0 X.Y.127.254 0.0.0.0 UG 0 0 > > 0 eth2 > > > > > > NOTE: we can add static routing to each interface using > > route- > > I am afraid that I've been misleading Livnat and Simon in private > communications. I've repressed this fact for a long while, but > apparently > initscripts's usage of GATEWAY, be it in interface or hostwide > config, is to > set the host's default gateway. > /etc/sysconfig/network-scripts/ifup-eth : > > if [ -n "${GATEWAY}" ] ...; then > ip route replace default ${METRIC:+metric $METRIC} \ > via ${GATEWAY} ${WINDOW:+window $WINDOW} ${SRC} \ > ${GATEWAYDEV:+dev $GATEWAYDEV} ... > > > This means that oVirt's current behavior is ok as it is - we set > GATEWAY > for a single network that is always on, and thus control the host's > default gateway. Did not read the entire thread yet, but just relating to this one. Current behaviour is not OK in any case, engine only supports setting default gateway on the management network - not on a selected network. This is not always the case. Actually many times the management network will be segregated where the engine and the nodes are on the same VLAN - no need for default gateway, while the clients are on the remote network thus the default gateway is requested to be on the Display network. The simple solution to properly support a single default gateway as interface independent is to place it in /etc/sysconfig/network. And remove it from a specific network dialogue. Make it a host level config. The only misleading information you gave is that if engine will provide a GATEWAY per network and then a hosts level config in /etc/sysconfig/network this will allow for per network gateway + one default gateway. This is not the case and when testing that I realized it does not work. This is why I did not open the RFE we've discussed I'm still investigating how to support multiple gateways, probably through iproute2 policy tables. However this change is not trivial so I recommend ATM to focus on the relevantly minor change of setting host level gateway and not network level. Simon. > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From sanjal at redhat.com Tue May 22 16:43:04 2012 From: sanjal at redhat.com (Shireesh Anjal) Date: Tue, 22 May 2012 12:43:04 -0400 (EDT) Subject: [Engine-devel] is gerrit.ovirt.org down? In-Reply-To: <266328e5-a63a-4e7d-a58f-7cba03273436@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <15e4c1ee-66c5-4565-aadd-26c1d8f3766a@zmail01.collab.prod.int.phx2.redhat.com> I have been unable to access the web UI or work with the repository for around half an hour now... ~Shireesh From shuming at linux.vnet.ibm.com Tue May 22 16:46:54 2012 From: shuming at linux.vnet.ibm.com (Shu Ming) Date: Wed, 23 May 2012 00:46:54 +0800 Subject: [Engine-devel] is gerrit.ovirt.org down? In-Reply-To: <15e4c1ee-66c5-4565-aadd-26c1d8f3766a@zmail01.collab.prod.int.phx2.redhat.com> References: <15e4c1ee-66c5-4565-aadd-26c1d8f3766a@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <4FBBC2FE.1040807@linux.vnet.ibm.com> It seems the ping latency is high. C:\Documents and Settings\Administrator>ping gerrit.ovirt.org Pinging gerrit.ovirt.org [107.22.212.69] with 32 bytes of data: Reply from 107.22.212.69: bytes=32 time=388ms TTL=46 Reply from 107.22.212.69: bytes=32 time=373ms TTL=46 Reply from 107.22.212.69: bytes=32 time=369ms TTL=46 Reply from 107.22.212.69: bytes=32 time=369ms TTL=46 Ping statistics for 107.22.212.69: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 369ms, Maximum = 388ms, Average = 374ms C:\Documents and Settings\Administrator> On 2012-5-23 0:43, Shireesh Anjal wrote: > I have been unable to access the web UI or work with the repository for around half an hour now... > > ~Shireesh > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > -- Shu Ming IBM China Systems and Technology Laboratory From snmishra at linux.vnet.ibm.com Tue May 22 17:02:05 2012 From: snmishra at linux.vnet.ibm.com (snmishra at linux.vnet.ibm.com) Date: Tue, 22 May 2012 13:02:05 -0400 Subject: [Engine-devel] is gerrit.ovirt.org down? In-Reply-To: <15e4c1ee-66c5-4565-aadd-26c1d8f3766a@zmail01.collab.prod.int.phx2.redhat.com> References: <15e4c1ee-66c5-4565-aadd-26c1d8f3766a@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <20120522130205.Horde.Q8UqOpir309Pu8aNyhnFBxA@imap.linux.ibm.com> Works for me. -Sharad Quoting Shireesh Anjal : > I have been unable to access the web UI or work with the repository > for around half an hour now... > > ~Shireesh > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From simon at redhat.com Tue May 22 17:31:37 2012 From: simon at redhat.com (Simon Grinberg) Date: Tue, 22 May 2012 13:31:37 -0400 (EDT) Subject: [Engine-devel] network features review In-Reply-To: <4FBB8E53.9030004@redhat.com> Message-ID: <9357a0cb-213a-4965-b5b5-00b84baf67f7@zmail17.collab.prod.int.phx2.redhat.com> Please forgive the late response and the lengthy remarks, some you may not like :) ----- Original Message ----- > From: "Livnat Peer" > To: "Moti Asayag" > Cc: engine-devel at ovirt.org > Sent: Tuesday, May 22, 2012 4:02:11 PM > Subject: Re: [Engine-devel] network features review > > On 22/05/12 15:39, Moti Asayag wrote: > > On 05/22/2012 11:45 AM, Livnat Peer wrote: > >> Hi All, > >> > >> This is a summary of comments we(*) gathered while reviewing the > >> current > >> network related functionality in oVirt, we'll open the relevant > >> RFE/Bugs > >> but wanted to share first to get comments: > >> > >> > >> Default Gateway: > >> ---------------- > >> current status - > >> In the UI/API we expose to the user the possibility to configure > >> the > >> default gateway for the host. We expose this option only when > >> editing > >> the management network. > >> > >> comments - > >> Apparently we do not configure the host default gateway but the > >> network gateway. > >> > >> 1. We need to fix the phrasing to gateway (not default gateway) > >> 2. Why do we block it for networks which are not the management > >> network > >> 3. We need to support configuring the host default gateway. > >> > >> > >> Non VM (Bridge-less) Network: > >> ----------------------------- > >> current status - > >> During bootstrap we configure the management network on the host. > >> We did > >> not implement configuring bridge-less management network during > >> bootstrap. > >> > >> comments - > >> 1. Supporting bridge-less network is a new feature,the design of > >> this > >> feature did not include changing the bootstrap process which make > >> this > >> feature non-useful when it comes to management network. Bootstarp does not support most of the possible network configuration. It will fail if there is already a non bridged bond/Vlan etc. I think that what should be done here is nothing, the bootstrap need not touch the network configuration at all. All the admin has to do is verify that the host has connectivity to the engine Then 1. On initial setup on the engine side, before adding any host allow to edit the management network properties. (Vlan/VM network/MTU etc) 2. Allow to add the host 3. Use setup-networks to assign the management network according to the topology selected by the admin. It can be done easily by allowing the user to detach it and then attach. As long as it is within the context of the edit menu before he hits OK this is allowed. The above should allow for any supported network configuration to be applied without all the issues and limitations around that ATM. It also simplifies the bootstrap - it does not care about network. > >> > >> Today one can edit a network only when it is not attached to > >> clusters, > >> at this point you can change the management network to be non-VM > >> network, the problem is that we configure the management network > >> on the > >> host during bootstrap and we do not get a parameter if to create a > >> bridge or not (we always create a bridge). See the suggestion above it also solves this scenario. > >> > >> What we end up with is - we can't change the management network > >> once we > >> added clusters/hosts but if changing it before attaching a cluster > >> we > >> ignore it in the bootstrap process. > >> > >> > >> Check connectivity: > >> -------------------- > >> current status - > >> The 'check connectivity' functionality is available only when > >> editing > >> the management network, it validates that we did not loose > >> connectivity > >> to the host, if we did the changes are rolled backed > >> automatically. > >> > >> comments - > >> 1. Sometimes when changing configuration of another network we can > >> 'damage' the connectivity to the host. We want to expose the check > >> connectivity functionality on any network configuration change. Agree, and this is should be always the default. > >> > >> VLAN tagging of management Network > >> ----------------------------------- > >> > >> current status - > >> The user can set a VLAN tag on the management network. > >> > >> comments - > >> 1. Any configuration of the management network needs support in > >> the bootstrap process (see explanation above for bridge-less network) > >> 2. In case of VLAN tagging it is even more complicated, Again the solution suggested above solves this too. >>>> when > >> adding a> >> host to oVirt we add it's address and it can not be changed after > >> the host was added to the system. in the bootstrap process we set the > >> management network on the nic oVirt engine used to ssh through, > >> unless the VLAN device is already configured and the IP used for the ssh > >> is already on this VLAN (for which it will work) we can't set the > >> network to be on another IP address. If the IP is on the same network - you should be able to do so. But this is not the problem, usually the need to change an IP is not during host/node installation, so there is no problem here, if the user wants a different IP at installation phase he need to set it before he adds the host/node, thus you only need to worry about IP changes for already added host (see comment below) > >> > > > > The host IP can be change, however it requires re-installing the > > host, that runs the bootstrap script. > > > > yes, thanks for the clarification. As I recall this is true if the cert is created based on IP and not FQDN. The re-install is required to replace the certs. What should be done is to use FQDN to create the certs and not the IP. This should allow for change of the rhevm network IP as long as it resolves to the same FQDN. I think this was fixed when installing using boot strap or add a node from the New host button (But can't be sure). When doing from the node, then last time I checked it still uses the IP of the host. > > >> Rollback network configuration: > >> -------------------------------- > >> current status - > >> We have the option to make changes to the host network > >> configuration > >> and not persist the changes (they won't survive machine reboot) > >> > >> comments - > >> 1. We are missing the functionality of rolling back the changes > >> (without > >> rebooting the machine), this functionality is the complementary > >> behavior > >> of 'save network configuration'. Also missing indication that a network topology change has been applied but not saved. This lead into situations where after setting a configuration and it works the user forgets to save. Everything works well until the first reboot of the node/host. This may happen days/weeks/months after the actual configuration has been changed so the user may not understand what has happened (/me old geezer with bad memory has done it more then once :)) > >> > >> > >> Predefined bonds: > >> ----------------- > >> current status - > >> In the bootstrap process we create bonds0-5 on the hosts and then > >> we use them when creating a bond on the host > > > > minor correction: There are 5 bonds, named bond0-4. > > > >> > >> comments - > >> 1. Creating the bonds in the host during the bootstrap process is > >> not > >> needed and we can let the user choose the bond name (limited to > >> bondX) > >> and create bonds only upon request. > >> > >> > >> Editing Network properties while Network is attached to cluster/s > >> ------------------------------------------------------------------ > >> current status - > >> Changing the network properties is blocked if the network is > >> attached to > >> a cluster. > >> > >> comments - > >> 1. We should relax this approach. to start with we can enable > >> editing > >> when there are no active hosts in the cluster/s. +1 > > > > Modifying a cluster network with hosts in it seems problematic, > > since > > we'd have to propagate the network changes to the hosts. E.g. > > updating a > > network to be bridge-less, or tagging a network. > > > > Perhaps we should allow updating a network only if the clusters > > have no > > hosts at all. I like the first option better. I understand the complexity of having mixed mode so I won't dare suggesting doing the propagation on live hosts (Though on some properties this should be possible) however you can relax the above a bit and just request maintenance. Then upon activation, if networks properties are different then the current definition update the host (actually you don't have to check, just send new topo) There is a difference between placing 100 hosts into maintenance and between placing into maintenance, removing them, change definition and then re-adding. I just changed 3 host and it was irritating. I had to: 1. Place them all into maintenance 2. Move them into temp cluster with no network requirements 3. Change the network 4. Move the hosts back 5. Activate. With the suggest above only steps 1 and 5 are required. > > > > yes, I agree. > > >> > >> doing more than the above requires substantially more work both in > >> VDSM > >> and engine. Not that much considering what the user will have to do (look at the suggested solution) - it will pay back after the first user that forgot to set a network as vm-network after adding few hosts and calls support. > >> > > > > Another missing behavior is the capability to refresh Host nics by > > demand. At the moment it is enabled by activating a host, which > > requires > > moving the host to maintenance first or when facing network issues. > > Else, changes on host nics will not reflect to the ovirt-engine. > > > > I agree this functionality comes from different areas, not only > networking, running getVdsCaps on demand. getVdsCaps is nothing compared to getAllVmsStats and you do the later every 10 seconds right? so why bother with on demand, why not just read it once a minute? When the update logic was created hot plug HW, virtual devices (NICs), etc was only a musing new comer, now with UCS and it's like it is a reality. There is no reason not to just update periodically. > > > >> > >> > >> Thank you, Livnat > >> > >> > >> (*) we == {Dan Kenigsberg, Igor Lvovsky, Mike Kolesnik, Moti > >> Asayag, > >> Muli Salem, Alona Kaplan, Livnat Peer} > >> > >> (**) We have even longer list for the UI changes needed, for them > >> we'll > >> open bugs directly to avoid another long email. > >> _______________________________________________ > >> Engine-devel mailing list > >> Engine-devel at ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From lhornyak at redhat.com Tue May 22 17:46:41 2012 From: lhornyak at redhat.com (Laszlo Hornyak) Date: Tue, 22 May 2012 13:46:41 -0400 (EDT) Subject: [Engine-devel] is gerrit.ovirt.org down? In-Reply-To: <20120522130205.Horde.Q8UqOpir309Pu8aNyhnFBxA@imap.linux.ibm.com> Message-ID: <67eee0b3-62bf-4255-8b6b-4ed2a1853b3b@zmail01.collab.prod.int.phx2.redhat.com> It was unavailable for a while. Someone said amazon does this sometimes. It always comes back after a couple of minutes and for a few more minutes it is terribly slow. ----- Original Message ----- > From: snmishra at linux.vnet.ibm.com > To: "Shireesh Anjal" > Cc: engine-devel at ovirt.org > Sent: Tuesday, May 22, 2012 7:02:05 PM > Subject: Re: [Engine-devel] is gerrit.ovirt.org down? > > > Works for me. > > -Sharad > > Quoting Shireesh Anjal : > > > I have been unable to access the web UI or work with the repository > > for around half an hour now... > > > > ~Shireesh > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From dfediuck at redhat.com Wed May 23 09:59:53 2012 From: dfediuck at redhat.com (Doron Fediuck) Date: Wed, 23 May 2012 12:59:53 +0300 Subject: [Engine-devel] Maven 3 here we come! Message-ID: <4FBCB519.60606@redhat.com> Hi all, As discussed last month[1], we had to deal with some issues which turned out to be a Maven bug. Thanks to Juan and Asaf's work, our current sources now build properly using Maven 3. So you're all invited to migrate into Maven 3. Other than upgrading your local maven package no other action is needed. For now, Maven 2 will also work for you, but I expect in the future we'd like to make use of some advanced features, so migration to 3 is recommended. Talking about advanced features, an interesting challenge is feedback on parallel builds [2]. So whoever wants to try it out and report if it improves run time without breaking anything, will be appreciated. Happy migration! [1]http://lists.ovirt.org/pipermail/arch/2012-April/000490.html [2] https://cwiki.apache.org/MAVEN/parallel-builds-in-maven-3.html -- /d "Email returned to sender -- insufficient voltage." From eedri at redhat.com Wed May 23 10:26:31 2012 From: eedri at redhat.com (Eyal Edri) Date: Wed, 23 May 2012 06:26:31 -0400 (EDT) Subject: [Engine-devel] Maven 3 here we come! In-Reply-To: <4FBCB519.60606@redhat.com> Message-ID: <92d79202-3390-4994-ad8f-6bd99030a5d0@zmail17.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Doron Fediuck" > To: engine-devel at ovirt.org > Cc: "" > Sent: Wednesday, May 23, 2012 12:59:53 PM > Subject: [Engine-devel] Maven 3 here we come! > > Hi all, > As discussed last month[1], we had to deal with some issues which > turned out to be a Maven bug. > Thanks to Juan and Asaf's work, our current sources now build > properly using Maven 3. > So you're all invited to migrate into Maven 3. Other than upgrading > your local maven package > no other action is needed. > > For now, Maven 2 will also work for you, but I expect in the future > we'd like to make use > of some advanced features, so migration to 3 is recommended. > > Talking about advanced features, an interesting challenge is feedback > on parallel builds [2]. > So whoever wants to try it out and report if it improves run time > without breaking anything, > will be appreciated. > > Happy migration! > > [1]http://lists.ovirt.org/pipermail/arch/2012-April/000490.html > [2] https://cwiki.apache.org/MAVEN/parallel-builds-in-maven-3.html > -- +1 on the move and testing out new features! > > /d > > "Email returned to sender -- insufficient voltage." > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From simon at redhat.com Wed May 23 12:43:56 2012 From: simon at redhat.com (Simon Grinberg) Date: Wed, 23 May 2012 08:43:56 -0400 (EDT) Subject: [Engine-devel] restapi: New params for import VM/Template In-Reply-To: <682d97c4-f61a-4112-8dab-5d24f06d21af@zmail14.collab.prod.int.phx2.redhat.com> Message-ID: <813c76ea-b248-4679-9dea-0452068bb5ca@zmail17.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Gilad Chaplik" > To: "Simon Grinberg" > Cc: "Michael Pasternak" , "engine-devel" , "Itamar Heim" > , "Livnat Peer" , "Ori Liel" > Sent: Thursday, May 17, 2012 10:21:51 AM > Subject: Re: [Engine-devel] restapi: New params for import VM/Template > > cc'ing Simon, > > Hi Simon, > > I remember we talked about why the engine can't decide implicitly if > to clone the vm or not - it should be the user call? > Can you share your opinion about that? Sorry for missing on that. First reason informative - User should know what he and we are doing. Example: * Setup2 already has vm named Kuku imported few months back or by another admin * The admin that usually works on setup1, decides it's time to move the VM to setup2 (for any reason), so he exports kuku and then imports into setup1 * We automatically import as Kuku1 * Admin searches for the name kuku and starts it - he is now working on the old one without knowing it. The above can cause confusion, lost time to understand why kuku is not working as expected and/or lost time to fix the err when trying to merge data from the currently running kuku and kuku1 which is the VM the user actually wanted to use. We must stop and ask. The question should be very similar to file copy on decent OSs - Override, save as, cancel. So does the API for this operation. * The above also leads to also question if importing a VM with the same name as a vm in the system, even though it is clear it's a different VM (different GUID/image ID etc) Second reason - prevent user error: User writes a script, by mistake he tries to copy the same VM over and over (he meant other VMs or just wrong stop condition), he can easily fill out his storage domain, or waste a lot of time before discovering the mistake since we don't return error but silently clone as new, Again the options above should be suffice to prevent that, if the user decides to to use with the force overrider or always clone, that is his problem. Third one, convenience: Assume a user has a VM on setup1, and wants a similar but not identical setup2. The reason is that he may want some day to move the VM to setup2. There is no support at all for this scenario. it will be either, the VM is imported as is and if he wants to move over the original VM it will have to be cloned (Thus changed). Or he can import and clone now (redundant copy operation) - The use case here is similar for the clone VM functionality but the clone is into a different setup. We should not always assume that it's fine to have identical VMs on different setups. I can think of some more if it's really necessary : Bottom line: Having this now will save at least 3 RFEs coming from the reasoning above and in a very reasonable price. All we have to do is to allow a checkbox in the import menu and stop assuming that we know better then the user what he wants to do. If you have a functionality that on one hand makes a novice user life easier while on the other hand may restrict advanced users, allow to choose - just have the defaults set to the case you think is the most common. The said above assumes clone on import changes everything including image IDs otherwise all the said above is a moot point. * Now in more advanced scenarios, use may be able to change everything he's allowed to change - same as when he does "Clone VM from template". But this is extension to simple clone case, with the price of going to the VM properties and edit it is solvable. * If override is complex for now, then reject if not specifically stated to clone (in the API) and Question to Copy As or Cancel is also reasonable. The user can always choose cancel and delete before trying again. > > Thanks, > Gilad. > > ----- Original Message ----- > > From: "Livnat Peer" > > To: "Gilad Chaplik" > > Cc: "Michael Pasternak" , "engine-devel" > > , "Itamar Heim" > > > > Sent: Thursday, May 17, 2012 9:43:45 AM > > Subject: Re: [Engine-devel] restapi: New params for import > > VM/Template > > > > > > > > > > Going FW it would be nice to override parameters in import > > > vm/template > > > > > > I agree with you and that's why - > > > > As a user I don't think there should be a difference in the API > > between: > > - Importing a VM and changing it's name > > - Importing a VM for the second time > > > > The reason you want to add artificial difference between the two > > scenarios above is because currently there are implementations > > limitations (changing the image ID while importing is not supported > > yet) > > > > I think that we should solve the limitations in the implementation > > instead of making our API cumbersome (implicit clone by name and > > adding > > some clone entity are both bad IMO). > > > > > > > > Livnat > > > > > From simon at redhat.com Wed May 23 15:53:46 2012 From: simon at redhat.com (Simon Grinberg) Date: Wed, 23 May 2012 11:53:46 -0400 (EDT) Subject: [Engine-devel] custom properties sheet feature page In-Reply-To: <4FB580A9.8090208@redhat.com> Message-ID: ----- Original Message ----- > From: "Itamar Heim" > To: "Einav Cohen" > Cc: "Andrew Cathrow" , "Eldan Hildesheim" , engine-devel at ovirt.org, "Simon > Grinberg" , "Eldan Hildesheim" > Sent: Friday, May 18, 2012 1:50:17 AM > Subject: Re: [Engine-devel] custom properties sheet feature page > > On 05/17/2012 04:08 PM, Einav Cohen wrote: > ... > >>> Hi, > >>> > >>> Please review/comment on the Custom Properties Sheet feature > >>> page: > >>> http://www.ovirt.org/wiki/Features/CustomPropertiesSheet > >>> > >> > >> It looks great. > >> Are all the keys going to be exposed in the dropdown, or will we > >> have > >> private keys that the user has to know about? > > > > All keys will be exposed; not sure what you mean by "private", but > > all keys are treated the same today. > > If we want some kind of differentiation between the keys, it is a > > another feature... > > [I could, of course, be missing something, please clarify if I did] > > > > in the future, we may want to give permissions to which users are > allowed to use which custom properties. > not relevant for now. Is this cool looking design be also available from the user portal? If so how do you prevent any user that just have permission to Edit VMs to do damage? With custom property you can do almost anything. Consider the case where there is a hook that allows to directly attach a LUN/Add Tap/more destructive options. It is intended for use of the sys admins but any user can use. You would say correctly that this was always the case. But with the old textbox interface the user would need to know that the option exists. Now we actually tell him what he can use. Cool for the webadmin / kind'a dangerous from the user portal until you get permissions per users feature for it. The minimum that is needed is an option to disable this properties tab in the user portal. Better have MLA for using properties at all if per property can't be accommodated. From ecohen at redhat.com Wed May 23 15:58:55 2012 From: ecohen at redhat.com (Einav Cohen) Date: Wed, 23 May 2012 11:58:55 -0400 (EDT) Subject: [Engine-devel] custom properties sheet feature page In-Reply-To: Message-ID: <95f782cc-e39a-4248-8deb-e97b22043ecc@zmail04.collab.prod.int.phx2.redhat.com> > ----- Original Message ----- > From: "Simon Grinberg" > Sent: Wednesday, May 23, 2012 6:53:46 PM > > ----- Original Message ----- > > From: "Itamar Heim" > > To: "Einav Cohen" > > Cc: "Andrew Cathrow" , "Eldan Hildesheim" > > , engine-devel at ovirt.org, "Simon > > Grinberg" , "Eldan Hildesheim" > > > > Sent: Friday, May 18, 2012 1:50:17 AM > > Subject: Re: [Engine-devel] custom properties sheet feature page > > > > On 05/17/2012 04:08 PM, Einav Cohen wrote: > > ... > > >>> Hi, > > >>> > > >>> Please review/comment on the Custom Properties Sheet feature > > >>> page: > > >>> http://www.ovirt.org/wiki/Features/CustomPropertiesSheet > > >>> > > >> > > >> It looks great. > > >> Are all the keys going to be exposed in the dropdown, or will we > > >> have > > >> private keys that the user has to know about? > > > > > > All keys will be exposed; not sure what you mean by "private", > > > but > > > all keys are treated the same today. > > > If we want some kind of differentiation between the keys, it is a > > > another feature... > > > [I could, of course, be missing something, please clarify if I > > > did] > > > > > > > in the future, we may want to give permissions to which users are > > allowed to use which custom properties. > > not relevant for now. > > Is this cool looking design be also available from the user portal? custom properties aren't available in the user portal. > If so how do you prevent any user that just have permission to Edit > VMs to do damage? With custom property you can do almost anything. > > Consider the case where there is a hook that allows to directly > attach a LUN/Add Tap/more destructive options. It is intended for > use of the sys admins but any user can use. > > You would say correctly that this was always the case. But with the > old textbox interface the user would need to know that the option > exists. Now we actually tell him what he can use. > > Cool for the webadmin / kind'a dangerous from the user portal until > you get permissions per users feature for it. > > The minimum that is needed is an option to disable this properties > tab in the user portal. > Better have MLA for using properties at all if per property can't be > accommodated. > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > From snmishra at linux.vnet.ibm.com Wed May 23 16:58:17 2012 From: snmishra at linux.vnet.ibm.com (snmishra at linux.vnet.ibm.com) Date: Wed, 23 May 2012 12:58:17 -0400 Subject: [Engine-devel] Maven 3 here we come! In-Reply-To: <92d79202-3390-4994-ad8f-6bd99030a5d0@zmail17.collab.prod.int.phx2.redhat.com> References: <92d79202-3390-4994-ad8f-6bd99030a5d0@zmail17.collab.prod.int.phx2.redhat.com> Message-ID: <20120523125817.Horde.WliYBpir309PvRcp7m2hSzA@imap.linux.ibm.com> New to maven. Using rhel6.2, and installed maven 3.0.4. Changed path to pick this version instead of 2.2.1 I was using before. when running "mvn clean install" I see - Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-install-plugin/2.3.1/maven-install-plugin-2.3.1.pom It doesn't look right, shouldn't it be maven3 instead of maven2 ? Do we need to update the "Maven personal settings" section on http://www.ovirt.org/wiki/Building_Ovirt_Engine At least the part where it says "maven 3.x will not work". How about ~/.m2/settings.xml ? -Sharad Quoting Eyal Edri : > ----- Original Message ----- >> From: "Doron Fediuck" >> To: engine-devel at ovirt.org >> Cc: "" >> Sent: Wednesday, May 23, 2012 12:59:53 PM >> Subject: [Engine-devel] Maven 3 here we come! >> >> Hi all, >> As discussed last month[1], we had to deal with some issues which >> turned out to be a Maven bug. >> Thanks to Juan and Asaf's work, our current sources now build >> properly using Maven 3. >> So you're all invited to migrate into Maven 3. Other than upgrading >> your local maven package >> no other action is needed. >> >> For now, Maven 2 will also work for you, but I expect in the future >> we'd like to make use >> of some advanced features, so migration to 3 is recommended. >> >> Talking about advanced features, an interesting challenge is feedback >> on parallel builds [2]. >> So whoever wants to try it out and report if it improves run time >> without breaking anything, >> will be appreciated. >> >> Happy migration! >> >> [1]http://lists.ovirt.org/pipermail/arch/2012-April/000490.html >> [2] https://cwiki.apache.org/MAVEN/parallel-builds-in-maven-3.html >> -- > > +1 on the move and testing out new features! > >> >> /d >> >> "Email returned to sender -- insufficient voltage." >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From ykaul at redhat.com Wed May 23 20:04:12 2012 From: ykaul at redhat.com (Yaniv Kaul) Date: Wed, 23 May 2012 23:04:12 +0300 Subject: [Engine-devel] Maven 3 here we come! In-Reply-To: <4FBCB519.60606@redhat.com> References: <4FBCB519.60606@redhat.com> Message-ID: <4FBD42BC.3040808@redhat.com> On 05/23/2012 12:59 PM, Doron Fediuck wrote: > Hi all, > As discussed last month[1], we had to deal with some issues which turned out to be a Maven bug. > Thanks to Juan and Asaf's work, our current sources now build properly using Maven 3. > So you're all invited to migrate into Maven 3. Other than upgrading your local maven package > no other action is needed. > > For now, Maven 2 will also work for you, but I expect in the future we'd like to make use > of some advanced features, so migration to 3 is recommended. > > Talking about advanced features, an interesting challenge is feedback on parallel builds [2]. I'm not happy with parallel builds - it creates more java processes, each taking quite a bit of memory. This, in turn, causes them to swap, making everything crawl. Took me 22 minutes to compile the webadmin and additional 21 minutes for the user portal, with -T 4. I've had 3.5GB of swap used (and 7GB resident memory with 'java' processes running around). It usually takes me The command line I've used was: mvn -T 4 clean install -Pgwt-admin,gwt-user -DskipTests=true -Dmaven.test.skip=true As opposed to 7+ 3 minutes without '-T 4'. Y. > So whoever wants to try it out and report if it improves run time without breaking anything, > will be appreciated. > > Happy migration! > > [1]http://lists.ovirt.org/pipermail/arch/2012-April/000490.html > [2]https://cwiki.apache.org/MAVEN/parallel-builds-in-maven-3.html From eedri at redhat.com Thu May 24 05:39:28 2012 From: eedri at redhat.com (Eyal Edri) Date: Thu, 24 May 2012 01:39:28 -0400 (EDT) Subject: [Engine-devel] Maven 3 here we come! In-Reply-To: <4FBD42BC.3040808@redhat.com> Message-ID: <8d85c9c0-3207-412e-8953-b317a3b43d50@zmail17.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Yaniv Kaul" > To: "Doron Fediuck" > Cc: engine-devel at ovirt.org, "" > Sent: Wednesday, May 23, 2012 11:04:12 PM > Subject: Re: [Engine-devel] Maven 3 here we come! > > On 05/23/2012 12:59 PM, Doron Fediuck wrote: > > Hi all, > > As discussed last month[1], we had to deal with some issues which > > turned out to be a Maven bug. > > Thanks to Juan and Asaf's work, our current sources now build > > properly using Maven 3. > > So you're all invited to migrate into Maven 3. Other than upgrading > > your local maven package > > no other action is needed. > > > > For now, Maven 2 will also work for you, but I expect in the future > > we'd like to make use > > of some advanced features, so migration to 3 is recommended. > > > > Talking about advanced features, an interesting challenge is > > feedback on parallel builds [2]. > > I'm not happy with parallel builds - it creates more java processes, > each taking quite a bit of memory. This, in turn, causes them to > swap, > making everything crawl. > Took me 22 minutes to compile the webadmin and additional 21 minutes > for > the user portal, with -T 4. I've had 3.5GB of swap used (and 7GB > resident memory with 'java' processes running around). > It usually takes me > > The command line I've used was: > mvn -T 4 clean install -Pgwt-admin,gwt-user -DskipTests=true > -Dmaven.test.skip=true > Have you tried using the mvn -T 1C option (to run one thread per core?) On some builds it reduced my compilation time in a few min, but it wasn't consistent. also, maven says that some of the modules are not thread-safe and he will run then sequentially, so perhaps if the modules were re-factored to fit parallel builds, only then we'll see real improvement. > > As opposed to 7+ 3 minutes without '-T 4'. > > Y. > > > So whoever wants to try it out and report if it improves run time > > without breaking anything, > > will be appreciated. > > > > Happy migration! > > > > [1]http://lists.ovirt.org/pipermail/arch/2012-April/000490.html > > [2]https://cwiki.apache.org/MAVEN/parallel-builds-in-maven-3.html > > > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch > From dfediuck at redhat.com Thu May 24 06:50:32 2012 From: dfediuck at redhat.com (Doron Fediuck) Date: Thu, 24 May 2012 09:50:32 +0300 Subject: [Engine-devel] Maven 3 here we come! In-Reply-To: <20120523125817.Horde.WliYBpir309PvRcp7m2hSzA@imap.linux.ibm.com> References: <92d79202-3390-4994-ad8f-6bd99030a5d0@zmail17.collab.prod.int.phx2.redhat.com> <20120523125817.Horde.WliYBpir309PvRcp7m2hSzA@imap.linux.ibm.com> Message-ID: <4FBDDA38.4040200@redhat.com> On 23/05/12 19:58, snmishra at linux.vnet.ibm.com wrote: > > New to maven. Using rhel6.2, and installed maven 3.0.4. Changed path to pick this version instead of 2.2.1 I was using before. > > when running "mvn clean install" I see - > > Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-install-plugin/2.3.1/maven-install-plugin-2.3.1.pom > > It doesn't look right, shouldn't it be maven3 instead of maven2 ? Sharad, Maven works with plugins for various tasks. Each plugin is a Maven artifact with its own version. The install plugin handles installation tasks to local repository. You can read more about it here: http://maven.apache.org/plugins/maven-install-plugin/ So in this case, your Maven 3 is using a plugin called maven-install, and the /plugin's/ version is 2.3.1. That's perfectly fine. > > Do we need to update the "Maven personal settings" section on http://www.ovirt.org/wiki/Building_Ovirt_Engine > > At least the part where it says "maven 3.x will not work". How about ~/.m2/settings.xml ? Thanks for the reminder- wiki updated. No change needed for the settings.xml file, or its location. > > -Sharad > > Quoting Eyal Edri : > >> ----- Original Message ----- >>> From: "Doron Fediuck" >>> To: engine-devel at ovirt.org >>> Cc: "" >>> Sent: Wednesday, May 23, 2012 12:59:53 PM >>> Subject: [Engine-devel] Maven 3 here we come! >>> >>> Hi all, >>> As discussed last month[1], we had to deal with some issues which >>> turned out to be a Maven bug. >>> Thanks to Juan and Asaf's work, our current sources now build >>> properly using Maven 3. >>> So you're all invited to migrate into Maven 3. Other than upgrading >>> your local maven package >>> no other action is needed. >>> >>> For now, Maven 2 will also work for you, but I expect in the future >>> we'd like to make use >>> of some advanced features, so migration to 3 is recommended. >>> >>> Talking about advanced features, an interesting challenge is feedback >>> on parallel builds [2]. >>> So whoever wants to try it out and report if it improves run time >>> without breaking anything, >>> will be appreciated. >>> >>> Happy migration! >>> >>> [1]http://lists.ovirt.org/pipermail/arch/2012-April/000490.html >>> [2] https://cwiki.apache.org/MAVEN/parallel-builds-in-maven-3.html >>> -- >> >> +1 on the move and testing out new features! >> >>> >>> /d >>> >>> "Email returned to sender -- insufficient voltage." >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel at ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel > > > -- /d "This message is made with 100% recycled electrons. No new atoms were destroyed in the making of this message." From abaron at redhat.com Thu May 24 07:02:58 2012 From: abaron at redhat.com (Ayal Baron) Date: Thu, 24 May 2012 03:02:58 -0400 (EDT) Subject: [Engine-devel] CPU Pinning @engine In-Reply-To: <4FBB9D2D.5070106@redhat.com> Message-ID: > Design updated, so pinning is not blocked, unless user will block it > (pin to host, etc). > UI will be updated shortly. Please review- > http://www.ovirt.org/wiki/Features/Design/cpu-pinning What happens if VM is not pinned to host but the other checkbox with the very long description is checked (i.e. only user initiated migrations), upon startup the system would automatically choose a host but from that point on not migrate unless user chooses to do so? The different combinations of the following leave me feeling that this is over complicated (or presented in a confusing manner): 1. Specific host 2. Run VM on Selected Host 3. Allow VM migration only upon Administrator... a. Is 1 supposed to be "Preferred host" ? i.e. should run on it if possible but not mandate it (and auto migrate is enabled and also probably also auto migrate back to it when possible) b. if using 1 + 2 - Vm is pinned to host? ("Run VM on Selected Host" is the wrong terminology imo) c. if using 1 + 3 - VM preferred host is specified (could start on different host in case of pressure) and no auto migrate (if started on non preferred host then will not auto-migrate to preferred host) d. ~1 (not specific host) + 3 - start wherever but only user initiated migrations are allowed. e. I assume 2+3 cannot coexist as well as ~1+2 f. ~1 + ~3 - Regular VM (system chooses where to run it and it auto migrates). From dlaor at redhat.com Thu May 24 07:25:35 2012 From: dlaor at redhat.com (Dor Laor) Date: Thu, 24 May 2012 10:25:35 +0300 Subject: [Engine-devel] CPU Pinning @engine In-Reply-To: References: Message-ID: <4FBDE26F.1000007@redhat.com> On 05/24/2012 10:02 AM, Ayal Baron wrote: > > >> Design updated, so pinning is not blocked, unless user will block it >> (pin to host, etc). >> UI will be updated shortly. Please review- >> http://www.ovirt.org/wiki/Features/Design/cpu-pinning > > What happens if VM is not pinned to host but the other checkbox with the very long description is checked (i.e. only user initiated migrations), upon startup the system would automatically choose a host but from that point on not migrate unless user chooses to do so? > > The different combinations of the following leave me feeling that this is over complicated (or presented in a confusing manner): > 1. Specific host > 2. Run VM on Selected Host > 3. Allow VM migration only upon Administrator... I'm didn't fully understand the above options - what's the diff between 1 and 2? You're right it's all pretty complicated. The friendliest thing one can do (but takes time) is a graphical presentation: The GUI presents various icons that represents all the host in the cluster (when there are plenty of hosts, it can bunch them together and write the number underneath). When a user selects a pinning string, the GUI automatically shows the group of hosts that match this pinning (removes the ones not relevant). Eventually the user can choose whether there are enough matching hosts to allow migration+cpu_pinning or only admin manual migration. About the pinning string, it's gets messy defining exclusion (can you exclude several pcups?). Again GUI should come to the rescue and you should have a drag and drop graphical tool where you drag vcpus on a group of pcpus. I've done a similar thing in a previous company I worked for and it was really simple and neat for the user. > > a. Is 1 supposed to be "Preferred host" ? i.e. should run on it if possible but not mandate it (and auto migrate is enabled and also probably also auto migrate back to it when possible) > b. if using 1 + 2 - Vm is pinned to host? ("Run VM on Selected Host" is the wrong terminology imo) > c. if using 1 + 3 - VM preferred host is specified (could start on different host in case of pressure) and no auto migrate (if started on non preferred host then will not auto-migrate to preferred host) > d. ~1 (not specific host) + 3 - start wherever but only user initiated migrations are allowed. > e. I assume 2+3 cannot coexist as well as ~1+2 > f. ~1 + ~3 - Regular VM (system chooses where to run it and it auto migrates). > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From mpastern at redhat.com Thu May 24 07:53:03 2012 From: mpastern at redhat.com (Michael Pasternak) Date: Thu, 24 May 2012 10:53:03 +0300 Subject: [Engine-devel] planned changes for api capabilities resource Message-ID: <4FBDE8DF.5010100@redhat.com> the motivation: =============== 1. current design is not restfull 2. is not consistent with the rest of api impl. impacts: ======== as this resource not used programmatically, we do not expect any backward compatibility issues planned change is: ================= from: http://localhost:8080/api/capabilities ... ... to: http://localhost:8080/api/capabilities/xxx ... (where xxx is a version number) -- Michael Pasternak RedHat, ENG-Virtualization R&D From mkenneth at redhat.com Thu May 24 08:24:52 2012 From: mkenneth at redhat.com (Miki Kenneth) Date: Thu, 24 May 2012 04:24:52 -0400 (EDT) Subject: [Engine-devel] CPU Pinning @engine In-Reply-To: <4FBDE26F.1000007@redhat.com> Message-ID: <17035a5f-16e6-4e47-9b4e-eb1acd26ee80@mkenneth.csb> This is good feedback - unrelated to the vCPU pining discussion tough. Few points: 1. Migration options are relevant only when specific host is selected. 2. "run on selected host" - means pin ONLY to this host, if unavailable, the VM won't run, and no migration will occur. 3. "allow migration" - means admin can manually migrate this VM to any other host. AFAIK, no logic for migration back currently exists. Miki ----- Original Message ----- > From: "Dor Laor" > To: "Ayal Baron" > Cc: engine-devel at ovirt.org > Sent: Thursday, May 24, 2012 10:25:35 AM > Subject: Re: [Engine-devel] CPU Pinning @engine > > On 05/24/2012 10:02 AM, Ayal Baron wrote: > > > > > >> Design updated, so pinning is not blocked, unless user will block > >> it > >> (pin to host, etc). > >> UI will be updated shortly. Please review- > >> http://www.ovirt.org/wiki/Features/Design/cpu-pinning > > > > What happens if VM is not pinned to host but the other checkbox > > with the very long description is checked (i.e. only user > > initiated migrations), upon startup the system would automatically > > choose a host but from that point on not migrate unless user > > chooses to do so? > > > > The different combinations of the following leave me feeling that > > this is over complicated (or presented in a confusing manner): > > 1. Specific host > > 2. Run VM on Selected Host > > 3. Allow VM migration only upon Administrator... > > I'm didn't fully understand the above options - what's the diff > between > 1 and 2? > > You're right it's all pretty complicated. > > The friendliest thing one can do (but takes time) is a graphical > presentation: > > The GUI presents various icons that represents all the host in the > cluster (when there are plenty of hosts, it can bunch them together > and > write the number underneath). When a user selects a pinning string, > the > GUI automatically shows the group of hosts that match this pinning > (removes the ones not relevant). > > Eventually the user can choose whether there are enough matching > hosts > to allow migration+cpu_pinning or only admin manual migration. > > > About the pinning string, it's gets messy defining exclusion (can you > exclude several pcups?). > > Again GUI should come to the rescue and you should have a drag and > drop > graphical tool where you drag vcpus on a group of pcpus. > > I've done a similar thing in a previous company I worked for and it > was > really simple and neat for the user. > > > > > a. Is 1 supposed to be "Preferred host" ? i.e. should run on it if > > possible but not mandate it (and auto migrate is enabled and also > > probably also auto migrate back to it when possible) > > b. if using 1 + 2 - Vm is pinned to host? ("Run VM on Selected > > Host" is the wrong terminology imo) > > c. if using 1 + 3 - VM preferred host is specified (could start on > > different host in case of pressure) and no auto migrate (if > > started on non preferred host then will not auto-migrate to > > preferred host) > > d. ~1 (not specific host) + 3 - start wherever but only user > > initiated migrations are allowed. > > e. I assume 2+3 cannot coexist as well as ~1+2 > > f. ~1 + ~3 - Regular VM (system chooses where to run it and it auto > > migrates). > > > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From dfediuck at redhat.com Thu May 24 09:04:14 2012 From: dfediuck at redhat.com (Doron Fediuck) Date: Thu, 24 May 2012 12:04:14 +0300 Subject: [Engine-devel] CPU Pinning @engine In-Reply-To: <4FBDE26F.1000007@redhat.com> References: <4FBDE26F.1000007@redhat.com> Message-ID: <4FBDF98E.7020508@redhat.com> On 24/05/12 10:25, Dor Laor wrote: > On 05/24/2012 10:02 AM, Ayal Baron wrote: >> >> >>> Design updated, so pinning is not blocked, unless user will block it >>> (pin to host, etc). >>> UI will be updated shortly. Please review- >>> http://www.ovirt.org/wiki/Features/Design/cpu-pinning >> >> What happens if VM is not pinned to host but the other checkbox with the very long description is checked (i.e. only user initiated migrations), upon startup the system would automatically choose a host but from that point on not migrate unless user chooses to do so? >> >> The different combinations of the following leave me feeling that this is over complicated (or presented in a confusing manner): >> 1. Specific host >> 2. Run VM on Selected Host >> 3. Allow VM migration only upon Administrator... > > I'm didn't fully understand the above options - what's the diff between 1 and 2? > > You're right it's all pretty complicated. > > The friendliest thing one can do (but takes time) is a graphical presentation: > > The GUI presents various icons that represents all the host in the cluster (when there are plenty of hosts, it can bunch them together and write the number underneath). When a user selects a pinning string, the GUI automatically shows the group of hosts that match this pinning (removes the ones not relevant). > > Eventually the user can choose whether there are enough matching hosts to allow migration+cpu_pinning or only admin manual migration. > > > About the pinning string, it's gets messy defining exclusion (can you exclude several pcups?). > > Again GUI should come to the rescue and you should have a drag and drop graphical tool where you drag vcpus on a group of pcpus. > > I've done a similar thing in a previous company I worked for and it was really simple and neat for the user. > I agree with Dor. Let's keep it simple; this feature handles CPU pinning only. Anything related to migration should be determined by the various existing _host_ pinning options, which should already be there. >From CPU-pinning point of view, migration is failed by libvirt if destination topology cannot host such pinning policy (we verified it). I also agree UI will do magic here, but that's for next phases. >> >> a. Is 1 supposed to be "Preferred host" ? i.e. should run on it if possible but not mandate it (and auto migrate is enabled and also probably also auto migrate back to it when possible) >> b. if using 1 + 2 - Vm is pinned to host? ("Run VM on Selected Host" is the wrong terminology imo) >> c. if using 1 + 3 - VM preferred host is specified (could start on different host in case of pressure) and no auto migrate (if started on non preferred host then will not auto-migrate to preferred host) >> d. ~1 (not specific host) + 3 - start wherever but only user initiated migrations are allowed. >> e. I assume 2+3 cannot coexist as well as ~1+2 >> f. ~1 + ~3 - Regular VM (system chooses where to run it and it auto migrates). > > > > >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel > -- /d "Air conditioned environment - Do NOT open Windows!" From ItzikB at mellanox.com Thu May 24 15:24:38 2012 From: ItzikB at mellanox.com (Itzik Brown) Date: Thu, 24 May 2012 15:24:38 +0000 Subject: [Engine-devel] Host Network status isn't being updated Message-ID: <4488206DC085244C886DBC9E7038B68925186CD0@mtrdag02.mtl.com> Hi, I add a network using ovirt-engine: Adding a network to a data center then attaching the network to a cluster(Non required network). Then I do the following on the host (running vdsm): #brctl addbr mynetwork #brctl addif mynetwork eth3 The refresh rate as indicated by ovirt-engine GUI is 5 seconds. I don't see that the network is attached to the interface until I manually restart vdsm. Any suggestion? Thanks, Itzik -------------- next part -------------- An HTML attachment was scrubbed... URL: From masayag at redhat.com Thu May 24 15:54:46 2012 From: masayag at redhat.com (Moti Asayag) Date: Thu, 24 May 2012 18:54:46 +0300 Subject: [Engine-devel] Host Network status isn't being updated In-Reply-To: <4488206DC085244C886DBC9E7038B68925186CD0@mtrdag02.mtl.com> References: <4488206DC085244C886DBC9E7038B68925186CD0@mtrdag02.mtl.com> Message-ID: <4FBE59C6.10900@redhat.com> On 05/24/2012 06:24 PM, Itzik Brown wrote: > Hi, > > > > I add a network using ovirt-engine: > > Adding a network to a data center then attaching the network to a > cluster(Non required network). > > > > Then I do the following on the host (running vdsm): > > #brctl addbr mynetwork > > #brctl addif mynetwork eth3 > > > > The refresh rate as indicated by ovirt-engine GUI is 5 seconds. > > I don't see that the network is attached to the interface until I > manually restart vdsm. > > > > Any suggestion? > The network interfaces are being refreshed on ovirt-engine side by the GetCapabilitiesVDSCommand. It is being triggered either by activating a host, or if the host status is other than: Up, PreparingForMaintenance, Error or NonOperational. The easiest way to refresh the new network on ovirt-engine is moving the host to maintenance and activating it. We're missing the functionality of refreshing the Host information on the fly, specifically network entities. It is also mentioned on the thread which deals on network features: http://lists.ovirt.org/pipermail/engine-devel/2012-May/001707.html > > > Thanks, > > Itzik > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From shaohef at linux.vnet.ibm.com Thu May 24 18:13:27 2012 From: shaohef at linux.vnet.ibm.com (ShaoHe Feng) Date: Fri, 25 May 2012 02:13:27 +0800 Subject: [Engine-devel] [ovirt-engine-sdk] Simplify the process of the RSDL code generation Message-ID: <4FBE7A47.6090001@linux.vnet.ibm.com> Hi all, Now I'm using the code generation suites of ovirt-engine-sdk, I find it is very troublesome. IMO, we can simplify the process. And I want to engaged in it. there are two tools parse the api.xsd and generate the params.py code. They are generateds_gui.py and generateDS.py. but there still some code can not be generate by these tools. now we should add these codes manually. the not NOT_GENERATED codes are as follow in the current params.py code: 1. import python module 2. a new attribute of GeneratedsSuper class 3. modify the get_root_tag function. 4. modify the parseString function to shut up the stdout. 5. _rootClassMap 6 . _elementToClassMap 7. findRootClass And I have two ideas about the code generation. For we should not modify the generateDS.py tools. But we can improve it. I think the 1, 2, 3, 7, can be hard-code, and 4, 5 and 6 can be configured. So I want to add an configure file to tell how to add the extra code that are not generated by generateDS.py tools. And new python program, as extension of generateDS.py to read the configure file and generate these codes. Or without the configure file, just make the new python program that supports an interactive commands. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ItzikB at mellanox.com Thu May 24 19:09:41 2012 From: ItzikB at mellanox.com (Itzik Brown) Date: Thu, 24 May 2012 19:09:41 +0000 Subject: [Engine-devel] Host Network status isn't being updated In-Reply-To: <4FBE59C6.10900@redhat.com> References: <4488206DC085244C886DBC9E7038B68925186CD0@mtrdag02.mtl.com>, <4FBE59C6.10900@redhat.com> Message-ID: <4488206DC085244C886DBC9E7038B68925186D16@mtrdag02.mtl.com> So what is the refresh rate for? ________________________________________ From: Moti Asayag [masayag at redhat.com] Sent: Thursday, May 24, 2012 6:54 PM To: Itzik Brown Cc: engine-devel at ovirt.org Subject: Re: [Engine-devel] Host Network status isn't being updated On 05/24/2012 06:24 PM, Itzik Brown wrote: > Hi, > > > > I add a network using ovirt-engine: > > Adding a network to a data center then attaching the network to a > cluster(Non required network). > > > > Then I do the following on the host (running vdsm): > > #brctl addbr mynetwork > > #brctl addif mynetwork eth3 > > > > The refresh rate as indicated by ovirt-engine GUI is 5 seconds. > > I don't see that the network is attached to the interface until I > manually restart vdsm. > > > > Any suggestion? > The network interfaces are being refreshed on ovirt-engine side by the GetCapabilitiesVDSCommand. It is being triggered either by activating a host, or if the host status is other than: Up, PreparingForMaintenance, Error or NonOperational. The easiest way to refresh the new network on ovirt-engine is moving the host to maintenance and activating it. We're missing the functionality of refreshing the Host information on the fly, specifically network entities. It is also mentioned on the thread which deals on network features: http://lists.ovirt.org/pipermail/engine-devel/2012-May/001707.html > > > Thanks, > > Itzik > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From masayag at redhat.com Fri May 25 06:46:39 2012 From: masayag at redhat.com (Moti Asayag) Date: Fri, 25 May 2012 09:46:39 +0300 Subject: [Engine-devel] Host Network status isn't being updated In-Reply-To: <4488206DC085244C886DBC9E7038B68925186D16@mtrdag02.mtl.com> References: <4488206DC085244C886DBC9E7038B68925186CD0@mtrdag02.mtl.com>, <4FBE59C6.10900@redhat.com> <4488206DC085244C886DBC9E7038B68925186D16@mtrdag02.mtl.com> Message-ID: <4FBF2ACF.80704@redhat.com> On 05/24/2012 10:09 PM, Itzik Brown wrote: > So what is the refresh rate for? The VdsRefreshRate configuration value holds the interval between refreshing data from the host (e.g. VM statuses) and verifying the host is responsive. > ________________________________________ > From: Moti Asayag [masayag at redhat.com] > Sent: Thursday, May 24, 2012 6:54 PM > To: Itzik Brown > Cc: engine-devel at ovirt.org > Subject: Re: [Engine-devel] Host Network status isn't being updated > > On 05/24/2012 06:24 PM, Itzik Brown wrote: >> Hi, >> >> >> >> I add a network using ovirt-engine: >> >> Adding a network to a data center then attaching the network to a >> cluster(Non required network). >> >> >> >> Then I do the following on the host (running vdsm): >> >> #brctl addbr mynetwork >> >> #brctl addif mynetwork eth3 >> >> >> >> The refresh rate as indicated by ovirt-engine GUI is 5 seconds. >> >> I don't see that the network is attached to the interface until I >> manually restart vdsm. >> >> >> >> Any suggestion? >> > > The network interfaces are being refreshed on ovirt-engine side by the > GetCapabilitiesVDSCommand. It is being triggered either by activating a > host, or if the host status is other than: Up, PreparingForMaintenance, > Error or NonOperational. > > The easiest way to refresh the new network on ovirt-engine is moving the > host to maintenance and activating it. > > We're missing the functionality of refreshing the Host information on > the fly, specifically network entities. > > It is also mentioned on the thread which deals on network features: > http://lists.ovirt.org/pipermail/engine-devel/2012-May/001707.html > >> >> >> Thanks, >> >> Itzik >> >> >> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From shuming at linux.vnet.ibm.com Fri May 25 05:45:24 2012 From: shuming at linux.vnet.ibm.com (Shu Ming) Date: Fri, 25 May 2012 13:45:24 +0800 Subject: [Engine-devel] oVirt automated test suites Message-ID: <4FBF1C74.2010700@linux.vnet.ibm.com> Hi, I need a reasonable test suites to test VDSM APIs. I know most of tests are done from the engine side manually. But I think we need a reasonable test suites to define the typical workflows of engine usage calling into VDSM APIs and make sure all the functions are doing well. As engine publics REST-APIs, an automated test suites can be created on top of the REST-APs without much difficult. Any other comments about this idea? -- Shu Ming IBM China Systems and Technology Laboratory From danken at redhat.com Fri May 25 08:27:03 2012 From: danken at redhat.com (Dan Kenigsberg) Date: Fri, 25 May 2012 11:27:03 +0300 Subject: [Engine-devel] Host Network status isn't being updated In-Reply-To: <4FBE59C6.10900@redhat.com> References: <4488206DC085244C886DBC9E7038B68925186CD0@mtrdag02.mtl.com> <4FBE59C6.10900@redhat.com> Message-ID: <20120525082702.GE11676@redhat.com> On Thu, May 24, 2012 at 06:54:46PM +0300, Moti Asayag wrote: > On 05/24/2012 06:24 PM, Itzik Brown wrote: > > Hi, > > > > > > > > I add a network using ovirt-engine: > > > > Adding a network to a data center then attaching the network to a > > cluster(Non required network). > > > > > > > > Then I do the following on the host (running vdsm): > > > > #brctl addbr mynetwork > > > > #brctl addif mynetwork eth3 > > > > > > > > The refresh rate as indicated by ovirt-engine GUI is 5 seconds. > > > > I don't see that the network is attached to the interface until I > > manually restart vdsm. > > > > > > > > Any suggestion? > > > > The network interfaces are being refreshed on ovirt-engine side by the > GetCapabilitiesVDSCommand. It is being triggered either by activating a > host, or if the host status is other than: Up, PreparingForMaintenance, > Error or NonOperational. > > The easiest way to refresh the new network on ovirt-engine is moving the > host to maintenance and activating it. > > We're missing the functionality of refreshing the Host information on > the fly, specifically network entities. How difficult would it be to add a call to getVdsCaps when getVdsStats return statistics for a yet-unknown network? > > It is also mentioned on the thread which deals on network features: > http://lists.ovirt.org/pipermail/engine-devel/2012-May/001707.html > > > > > > > Thanks, > > > > Itzik > > > > > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From snmishra at linux.vnet.ibm.com Fri May 25 14:00:40 2012 From: snmishra at linux.vnet.ibm.com (snmishra at linux.vnet.ibm.com) Date: Fri, 25 May 2012 10:00:40 -0400 Subject: [Engine-devel] oVirt automated test suites In-Reply-To: <4FBF1C74.2010700@linux.vnet.ibm.com> References: <4FBF1C74.2010700@linux.vnet.ibm.com> Message-ID: <20120525100040.Horde.LZ4WNJir309Pv5CI1b0WEFA@imap.linux.ibm.com> Quoting Shu Ming : > Hi, > > I need a reasonable test suites to test VDSM APIs. I know most of > tests are done from the engine side manually. But I think we need > a reasonable test suites to define the typical workflows of engine > usage calling into VDSM APIs and make sure all the functions are > doing well. As engine publics REST-APIs, an automated test suites > can be created on top of the REST-APs without much difficult. Any > other comments about this idea? How about extending the current engine jUnit tests ? -Sharad Mishra IBM > > -- > Shu Ming > IBM China Systems and Technology Laboratory > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From mpastern at redhat.com Fri May 25 17:48:50 2012 From: mpastern at redhat.com (Michael Pasternak) Date: Fri, 25 May 2012 20:48:50 +0300 Subject: [Engine-devel] [ovirt-engine-sdk] Simplify the process of the RSDL code generation In-Reply-To: <4FBE7A47.6090001@linux.vnet.ibm.com> References: <4FBE7A47.6090001@linux.vnet.ibm.com> Message-ID: <4FBFC602.90105@redhat.com> Hi, On 05/24/2012 09:13 PM, ShaoHe Fen3g wrote: > Hi all, > > Now I'm using the code generation suites of ovirt-engine-sdk, I find it is very troublesome. I completely agree with you, automating python entities generation is on top of my TODO stack see [1], Along with this, there was always something more important to do, and it was delayed time after time, so your help is most welcome. [1] http://www.ovirt.org/wiki/SDK#codegen > > IMO, we can simplify the process. And I want to engaged in it. > > there are two tools parse the api.xsd and generate the params.py code. They are generateds_gui.py and generateDS.py. > but there still some code can not be generate by these tools. now we should add these codes manually. > > the not NOT_GENERATED codes are as follow in the current params.py code: > 1. import python module > 2. a new attribute of GeneratedsSuper class > 3. modify the get_root_tag function. > 4. modify the parseString function to shut up the stdout. > 5. _rootClassMap > 6 . _elementToClassMap > 7. findRootClass > > And I have two ideas about the code generation. > For we should not modify the generateDS.py tools. > But we can improve it. > > I think the 1, 2, 3, 7, can be hard-code, and 4, 5 and 6 can be configured. > So I want to add an configure file to tell how to add the extra code that are not generated by generateDS.py tools. > And new python program, as extension of generateDS.py to read the configure file and generate these codes. sounds good, btw 5,6 can be constructed programmatically using __all__ generated by generateDS and finding element name in xsd by type (from __all__). > > Or without the configure file, just make the new python program that supports an interactive commands. > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel -- Michael Pasternak RedHat, ENG-Virtualization R&D From shaohef at linux.vnet.ibm.com Sun May 27 17:06:25 2012 From: shaohef at linux.vnet.ibm.com (ShaoHe Feng) Date: Mon, 28 May 2012 01:06:25 +0800 Subject: [Engine-devel] [ovirt-engine-sdk] Simplify the process of the RSDL code generation In-Reply-To: <4FBFC602.90105@redhat.com> References: <4FBE7A47.6090001@linux.vnet.ibm.com> <4FBFC602.90105@redhat.com> Message-ID: <4FC25F11.8090201@linux.vnet.ibm.com> On 05/26/2012 01:48 AM, Michael Pasternak wrote: > Hi, > > On 05/24/2012 09:13 PM, ShaoHe Fen3g wrote: >> Hi all, >> >> Now I'm using the code generation suites of ovirt-engine-sdk, I find it is very troublesome. > I completely agree with you, automating python entities generation is on top > of my TODO stack see [1], > > Along with this, there was always something more important to do, and > it was delayed time after time, so your help is most welcome. > > [1] http://www.ovirt.org/wiki/SDK#codegen > >> IMO, we can simplify the process. And I want to engaged in it. >> >> there are two tools parse the api.xsd and generate the params.py code. They are generateds_gui.py and generateDS.py. >> but there still some code can not be generate by these tools. now we should add these codes manually. >> >> the not NOT_GENERATED codes are as follow in the current params.py code: >> 1. import python module >> 2. a new attribute of GeneratedsSuper class >> 3. modify the get_root_tag function. >> 4. modify the parseString function to shut up the stdout. >> 5. _rootClassMap >> 6 . _elementToClassMap >> 7. findRootClass >> >> And I have two ideas about the code generation. >> For we should not modify the generateDS.py tools. >> But we can improve it. >> >> I think the 1, 2, 3, 7, can be hard-code, and 4, 5 and 6 can be configured. >> So I want to add an configure file to tell how to add the extra code that are not generated by generateDS.py tools. >> And new python program, as extension of generateDS.py to read the configure file and generate these codes. > sounds good, btw 5,6 can be constructed programmatically using __all__ generated by generateDS > and finding element name in xsd by type (from __all__). should all the element name in xsd by type be added to _rootClassMap, and no element can be exception? >> Or without the configure file, just make the new python program that supports an interactive commands. >> >> >> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel > From dfediuck at redhat.com Sun May 27 19:31:22 2012 From: dfediuck at redhat.com (Doron Fediuck) Date: Sun, 27 May 2012 22:31:22 +0300 Subject: [Engine-devel] Enabling guest memory balloon device Message-ID: <4FC2810A.3090307@redhat.com> Hi All, In the following wiki, there's a design for enabling the balloon device, which is currently disabled in engine setups. Other than enabling the device, this is also a step forward in the path to vdsm and MoM sub-project integration. More details can be found here: http://www.ovirt.org/wiki/Features/Design/memory-balloon P.S. UI mockups should be updated soon. -- /d ?Funny,? he intoned funereally, ?how just when you think life can't possibly get any worse it suddenly does.? --Douglas Adams, The Hitchhiker's Guide to the Galaxy From mpastern at redhat.com Mon May 28 06:56:08 2012 From: mpastern at redhat.com (Michael Pasternak) Date: Mon, 28 May 2012 09:56:08 +0300 Subject: [Engine-devel] [ovirt-engine-sdk] Simplify the process of the RSDL code generation In-Reply-To: <4FC25F11.8090201@linux.vnet.ibm.com> References: <4FBE7A47.6090001@linux.vnet.ibm.com> <4FBFC602.90105@redhat.com> <4FC25F11.8090201@linux.vnet.ibm.com> Message-ID: <4FC32188.6080409@redhat.com> On 05/27/2012 08:06 PM, ShaoHe Feng wrote: > On 05/26/2012 01:48 AM, Michael Pasternak wrote: >> Hi, >> >> On 05/24/2012 09:13 PM, ShaoHe Fen3g wrote: >>> Hi all, >>> >>> Now I'm using the code generation suites of ovirt-engine-sdk, I find it is very troublesome. >> I completely agree with you, automating python entities generation is on top >> of my TODO stack see [1], >> >> Along with this, there was always something more important to do, and >> it was delayed time after time, so your help is most welcome. >> >> [1] http://www.ovirt.org/wiki/SDK#codegen >> >>> IMO, we can simplify the process. And I want to engaged in it. >>> >>> there are two tools parse the api.xsd and generate the params.py code. They are generateds_gui.py and generateDS.py. >>> but there still some code can not be generate by these tools. now we should add these codes manually. >>> >>> the not NOT_GENERATED codes are as follow in the current params.py code: >>> 1. import python module >>> 2. a new attribute of GeneratedsSuper class >>> 3. modify the get_root_tag function. >>> 4. modify the parseString function to shut up the stdout. >>> 5. _rootClassMap >>> 6 . _elementToClassMap >>> 7. findRootClass >>> >>> And I have two ideas about the code generation. >>> For we should not modify the generateDS.py tools. >>> But we can improve it. >>> >>> I think the 1, 2, 3, 7, can be hard-code, and 4, 5 and 6 can be configured. >>> So I want to add an configure file to tell how to add the extra code that are not generated by generateDS.py tools. >>> And new python program, as extension of generateDS.py to read the configure file and generate these codes. >> sounds good, btw 5,6 can be constructed programmatically using __all__ generated by generateDS >> and finding element name in xsd by type (from __all__). > should all the element name in xsd by type be added to _rootClassMap, and no element can be exception? basically yes, cause _rootClassMap is holder which used for (by name) type retrieval, only exception is if certain type is not referenced by any other type (then none will look for it during the type construction), but i would not implement this logic. > >>> Or without the configure file, just make the new python program that supports an interactive commands. >>> >>> >>> >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel at ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >> > -- Michael Pasternak RedHat, ENG-Virtualization R&D From shaohef at linux.vnet.ibm.com Mon May 28 07:26:43 2012 From: shaohef at linux.vnet.ibm.com (ShaoHe Feng) Date: Mon, 28 May 2012 15:26:43 +0800 Subject: [Engine-devel] [ovirt-engine-sdk] Simplify the process of the RSDL code generation In-Reply-To: <4FC32188.6080409@redhat.com> References: <4FBE7A47.6090001@linux.vnet.ibm.com> <4FBFC602.90105@redhat.com> <4FC25F11.8090201@linux.vnet.ibm.com> <4FC32188.6080409@redhat.com> Message-ID: <4FC328B3.2050808@linux.vnet.ibm.com> On 05/28/2012 02:56 PM, Michael Pasternak wrote: > On 05/27/2012 08:06 PM, ShaoHe Feng wrote: >> On 05/26/2012 01:48 AM, Michael Pasternak wrote: >>> Hi, >>> >>> On 05/24/2012 09:13 PM, ShaoHe Fen3g wrote: >>>> Hi all, >>>> >>>> Now I'm using the code generation suites of ovirt-engine-sdk, I find it is very troublesome. >>> I completely agree with you, automating python entities generation is on top >>> of my TODO stack see [1], >>> >>> Along with this, there was always something more important to do, and >>> it was delayed time after time, so your help is most welcome. >>> >>> [1] http://www.ovirt.org/wiki/SDK#codegen >>> >>>> IMO, we can simplify the process. And I want to engaged in it. >>>> >>>> there are two tools parse the api.xsd and generate the params.py code. They are generateds_gui.py and generateDS.py. >>>> but there still some code can not be generate by these tools. now we should add these codes manually. >>>> >>>> the not NOT_GENERATED codes are as follow in the current params.py code: >>>> 1. import python module >>>> 2. a new attribute of GeneratedsSuper class >>>> 3. modify the get_root_tag function. >>>> 4. modify the parseString function to shut up the stdout. >>>> 5. _rootClassMap >>>> 6 . _elementToClassMap >>>> 7. findRootClass >>>> >>>> And I have two ideas about the code generation. >>>> For we should not modify the generateDS.py tools. >>>> But we can improve it. >>>> >>>> I think the 1, 2, 3, 7, can be hard-code, and 4, 5 and 6 can be configured. >>>> So I want to add an configure file to tell how to add the extra code that are not generated by generateDS.py tools. >>>> And new python program, as extension of generateDS.py to read the configure file and generate these codes. >>> sounds good, btw 5,6 can be constructed programmatically using __all__ generated by generateDS >>> and finding element name in xsd by type (from __all__). >> should all the element name in xsd by type be added to _rootClassMap, and no element can be exception? > basically yes, cause _rootClassMap is holder which used for (by name) type retrieval, > only exception is if certain type is not referenced by any other type (then none will look for > it during the type construction), but i would not implement this logic. > Hi Michael, what's your account on ovirt IRC channel? >>>> Or without the configure file, just make the new python program that supports an interactive commands. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Engine-devel mailing list >>>> Engine-devel at ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > From shaohef at linux.vnet.ibm.com Mon May 28 07:54:25 2012 From: shaohef at linux.vnet.ibm.com (ShaoHe Feng) Date: Mon, 28 May 2012 15:54:25 +0800 Subject: [Engine-devel] [ovirt-engine-sdk] Simplify the process of the RSDL code generation In-Reply-To: <4FC328B3.2050808@linux.vnet.ibm.com> References: <4FBE7A47.6090001@linux.vnet.ibm.com> <4FBFC602.90105@redhat.com> <4FC25F11.8090201@linux.vnet.ibm.com> <4FC32188.6080409@redhat.com> <4FC328B3.2050808@linux.vnet.ibm.com> Message-ID: <4FC32F31.3050308@linux.vnet.ibm.com> On 05/28/2012 03:26 PM, ShaoHe Feng wrote: > On 05/28/2012 02:56 PM, Michael Pasternak wrote: >> On 05/27/2012 08:06 PM, ShaoHe Feng wrote: >>> On 05/26/2012 01:48 AM, Michael Pasternak wrote: >>>> Hi, >>>> >>>> On 05/24/2012 09:13 PM, ShaoHe Fen3g wrote: >>>>> Hi all, >>>>> >>>>> Now I'm using the code generation suites of ovirt-engine-sdk, I >>>>> find it is very troublesome. >>>> I completely agree with you, automating python entities generation >>>> is on top >>>> of my TODO stack see [1], >>>> >>>> Along with this, there was always something more important to do, and >>>> it was delayed time after time, so your help is most welcome. >>>> >>>> [1] http://www.ovirt.org/wiki/SDK#codegen >>>> >>>>> IMO, we can simplify the process. And I want to engaged in it. >>>>> >>>>> there are two tools parse the api.xsd and generate the params.py >>>>> code. They are generateds_gui.py and generateDS.py. >>>>> but there still some code can not be generate by these tools. now >>>>> we should add these codes manually. >>>>> >>>>> the not NOT_GENERATED codes are as follow in the current >>>>> params.py code: >>>>> 1. import python module >>>>> 2. a new attribute of GeneratedsSuper class >>>>> 3. modify the get_root_tag function. >>>>> 4. modify the parseString function to shut up the stdout. >>>>> 5. _rootClassMap >>>>> 6 . _elementToClassMap >>>>> 7. findRootClass >>>>> >>>>> And I have two ideas about the code generation. >>>>> For we should not modify the generateDS.py tools. >>>>> But we can improve it. >>>>> >>>>> I think the 1, 2, 3, 7, can be hard-code, and 4, 5 and 6 can be >>>>> configured. >>>>> So I want to add an configure file to tell how to add the extra >>>>> code that are not generated by generateDS.py tools. >>>>> And new python program, as extension of generateDS.py to read the >>>>> configure file and generate these codes. >>>> sounds good, btw 5,6 can be constructed programmatically using >>>> __all__ generated by generateDS >>>> and finding element name in xsd by type (from __all__). >>> should all the element name in xsd by type be added to >>> _rootClassMap, and no element can be exception? >> basically yes, cause _rootClassMap is holder which used >> for (by name) type retrieval, >> only exception is if certain type is not referenced by any other type >> (then none will look for >> it during the type construction), but i would not implement this logic. >> > Hi Michael, > what's your account on ovirt IRC channel? seem I can not log on the #ovirt IRC channel. still some questions. can I edit the generateDS.py directly in order to generate the params.py code that we expect. and then rename the generateDS.py, put it into the SDK directory? or an new py program to call the functions of generateDS? >>>>> Or without the configure file, just make the new python program >>>>> that supports an interactive commands. >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Engine-devel mailing list >>>>> Engine-devel at ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >> > From mpastern at redhat.com Mon May 28 08:17:37 2012 From: mpastern at redhat.com (Michael Pasternak) Date: Mon, 28 May 2012 11:17:37 +0300 Subject: [Engine-devel] [ovirt-engine-sdk] Simplify the process of the RSDL code generation In-Reply-To: <4FC32F31.3050308@linux.vnet.ibm.com> References: <4FBE7A47.6090001@linux.vnet.ibm.com> <4FBFC602.90105@redhat.com> <4FC25F11.8090201@linux.vnet.ibm.com> <4FC32188.6080409@redhat.com> <4FC328B3.2050808@linux.vnet.ibm.com> <4FC32F31.3050308@linux.vnet.ibm.com> Message-ID: <4FC334A1.60209@redhat.com> On 05/28/2012 10:54 AM, ShaoHe Feng wrote: > On 05/28/2012 03:26 PM, ShaoHe Feng wrote: >> On 05/28/2012 02:56 PM, Michael Pasternak wrote: >>> On 05/27/2012 08:06 PM, ShaoHe Feng wrote: >>>> On 05/26/2012 01:48 AM, Michael Pasternak wrote: >>>>> Hi, >>>>> >>>>> On 05/24/2012 09:13 PM, ShaoHe Fen3g wrote: >>>>>> Hi all, >>>>>> >>>>>> Now I'm using the code generation suites of ovirt-engine-sdk, I find it is very troublesome. >>>>> I completely agree with you, automating python entities generation is on top >>>>> of my TODO stack see [1], >>>>> >>>>> Along with this, there was always something more important to do, and >>>>> it was delayed time after time, so your help is most welcome. >>>>> >>>>> [1] http://www.ovirt.org/wiki/SDK#codegen >>>>> >>>>>> IMO, we can simplify the process. And I want to engaged in it. >>>>>> >>>>>> there are two tools parse the api.xsd and generate the params.py code. They are generateds_gui.py and generateDS.py. >>>>>> but there still some code can not be generate by these tools. now we should add these codes manually. >>>>>> >>>>>> the not NOT_GENERATED codes are as follow in the current params.py code: >>>>>> 1. import python module >>>>>> 2. a new attribute of GeneratedsSuper class >>>>>> 3. modify the get_root_tag function. >>>>>> 4. modify the parseString function to shut up the stdout. >>>>>> 5. _rootClassMap >>>>>> 6 . _elementToClassMap >>>>>> 7. findRootClass >>>>>> >>>>>> And I have two ideas about the code generation. >>>>>> For we should not modify the generateDS.py tools. >>>>>> But we can improve it. >>>>>> >>>>>> I think the 1, 2, 3, 7, can be hard-code, and 4, 5 and 6 can be configured. >>>>>> So I want to add an configure file to tell how to add the extra code that are not generated by generateDS.py tools. >>>>>> And new python program, as extension of generateDS.py to read the configure file and generate these codes. >>>>> sounds good, btw 5,6 can be constructed programmatically using __all__ generated by generateDS >>>>> and finding element name in xsd by type (from __all__). >>>> should all the element name in xsd by type be added to _rootClassMap, and no element can be exception? >>> basically yes, cause _rootClassMap is holder which used for (by name) type retrieval, >>> only exception is if certain type is not referenced by any other type (then none will look for >>> it during the type construction), but i would not implement this logic. >>> >> Hi Michael, >> what's your account on ovirt IRC channel? > seem I can not log on the #ovirt IRC channel. mpastern > > still some questions. > can I edit the generateDS.py directly in order to generate the params.py code that we expect. and then rename the generateDS.py, put it into the SDK directory? > or an new py program to call the functions of generateDS? rewriting generateDS means that from now on we maintaining it (including bug fixes etc.), i prefer new py module extending generateDS, and leaving maintenance of generateDS to author/community. > >>>>>> Or without the configure file, just make the new python program that supports an interactive commands. >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Engine-devel mailing list >>>>>> Engine-devel at ovirt.org >>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> >> > -- Michael Pasternak RedHat, ENG-Virtualization R&D From mpastern at redhat.com Mon May 28 09:59:12 2012 From: mpastern at redhat.com (Michael Pasternak) Date: Mon, 28 May 2012 12:59:12 +0300 Subject: [Engine-devel] Adding atomic restore snapshot command at backend Message-ID: <4FC34C70.6070101@redhat.com> Currently 'restore snapshot' done in two steps on a client side: 1. TryBackToAllSnapshotsOfVm 2. RestoreAllSnapshots This implementation creates race condition on 1 and therefore unstable & bug prone, i suggested refactoring 2 to include 1 as single atomic operation at backend. -- Michael Pasternak RedHat, ENG-Virtualization R&D From lpeer at redhat.com Mon May 28 11:07:40 2012 From: lpeer at redhat.com (Livnat Peer) Date: Mon, 28 May 2012 14:07:40 +0300 Subject: [Engine-devel] Adding atomic restore snapshot command at backend In-Reply-To: <4FC34C70.6070101@redhat.com> References: <4FC34C70.6070101@redhat.com> Message-ID: <4FC35C7C.4020707@redhat.com> On 28/05/12 12:59, Michael Pasternak wrote: > > Currently 'restore snapshot' done in two steps on a client side: > > 1. TryBackToAllSnapshotsOfVm > 2. RestoreAllSnapshots > > This implementation creates race condition on 1 and therefore unstable & bug prone, > i suggested refactoring 2 to include 1 as single atomic operation at backend. > > Hi Michael, The two commands above are used for functionality that is needed regardless of the functionality you are looking for. We want to present the user the option to preview a snapshot without committing to it and without loosing the current snapshot. I think we need to model the the two options above in the REST, it is functionality that is used in the UI. What you are looking for is a functionality 'restore to snapshot', this functionality does not exist in the engine in a single step, and I think that because we assumed that the user can get it in two steps It wasn't prioritize so far. Implementing the missing functionality with the two functions above is a compromise that was done in the API. To summarize I think the requirement you present is a missing functionality in the engine and solving it is not about refactoring the two existing verbs into one. Thanks, Livnat From mpastern at redhat.com Mon May 28 11:26:10 2012 From: mpastern at redhat.com (Michael Pasternak) Date: Mon, 28 May 2012 14:26:10 +0300 Subject: [Engine-devel] REST-API: Exposing correlation-ID In-Reply-To: <4FB268D6.4030002@redhat.com> References: <750f8c50-2d5e-4524-99dc-52d9180306a2@zmail17.collab.prod.int.phx2.redhat.com> <4FB268D6.4030002@redhat.com> Message-ID: <4FC360D2.7040809@redhat.com> On 05/15/2012 05:31 PM, Moti Asayag wrote: > On 05/14/2012 02:19 PM, Ori Liel wrote: >> > No decision about the name of the parameter yet, and this is blocking me. >> > >> > Names that were suggested so far: >> > >> > * flow-id +1 -- Michael Pasternak RedHat, ENG-Virtualization R&D From mpastern at redhat.com Mon May 28 11:37:10 2012 From: mpastern at redhat.com (Michael Pasternak) Date: Mon, 28 May 2012 14:37:10 +0300 Subject: [Engine-devel] Adding atomic restore snapshot command at backend In-Reply-To: <4FC35C7C.4020707@redhat.com> References: <4FC34C70.6070101@redhat.com> <4FC35C7C.4020707@redhat.com> Message-ID: <4FC36366.7040207@redhat.com> Hi Livnat, On 05/28/2012 02:07 PM, Livnat Peer wrote: > On 28/05/12 12:59, Michael Pasternak wrote: >> >> Currently 'restore snapshot' done in two steps on a client side: >> >> 1. TryBackToAllSnapshotsOfVm >> 2. RestoreAllSnapshots >> >> This implementation creates race condition on 1 and therefore unstable & bug prone, >> i suggested refactoring 2 to include 1 as single atomic operation at backend. >> >> > > Hi Michael, > > The two commands above are used for functionality that is needed > regardless of the functionality you are looking for. > We want to present the user the option to preview a snapshot without > committing to it and without loosing the current snapshot. > I think we need to model the the two options above in the REST, it is > functionality that is used in the UI. this is out of scope of this RFE. > > What you are looking for is a functionality 'restore to snapshot', this > functionality does not exist in the engine in a single step, and I think > that because we assumed that the user can get it in two steps It wasn't > prioritize so far. the cons. of this approach is an async nature of the former command. > > Implementing the missing functionality with the two functions above is > a compromise that was done in the API. > > To summarize I think the requirement you present is a missing > functionality in the engine and solving it is not about refactoring the > two existing verbs into one. what i meant is not deprecating/refactoring old commands, but introducing new one that reusing them and expose as single (atomic) command called 'RestoreAllSnapshots', sorry if i wasn't clear. > > Thanks, Livnat > -- Michael Pasternak RedHat, ENG-Virtualization R&D From oliel at redhat.com Mon May 28 11:35:23 2012 From: oliel at redhat.com (Ori Liel) Date: Mon, 28 May 2012 07:35:23 -0400 (EDT) Subject: [Engine-devel] REST-API: Exposing correlation-ID In-Reply-To: <4FC360D2.7040809@redhat.com> Message-ID: Quite a few people liked flow-id, and no one objected to it explicitly, so I'll just go with that. If someone feels strongly against, please reply. Ori ----- Original Message ----- From: "Michael Pasternak" To: "Moti Asayag" Cc: "Ori Liel" , engine-devel at ovirt.org Sent: Monday, May 28, 2012 2:26:10 PM Subject: Re: [Engine-devel] REST-API: Exposing correlation-ID On 05/15/2012 05:31 PM, Moti Asayag wrote: > On 05/14/2012 02:19 PM, Ori Liel wrote: >> > No decision about the name of the parameter yet, and this is blocking me. >> > >> > Names that were suggested so far: >> > >> > * flow-id +1 -- Michael Pasternak RedHat, ENG-Virtualization R&D From shaohef at linux.vnet.ibm.com Mon May 28 11:49:05 2012 From: shaohef at linux.vnet.ibm.com (ShaoHe Feng) Date: Mon, 28 May 2012 19:49:05 +0800 Subject: [Engine-devel] [ovirt-engine-sdk] Simplify the process of the RSDL code generation In-Reply-To: <4FC32F31.3050308@linux.vnet.ibm.com> References: <4FBE7A47.6090001@linux.vnet.ibm.com> <4FBFC602.90105@redhat.com> <4FC25F11.8090201@linux.vnet.ibm.com> <4FC32188.6080409@redhat.com> <4FC328B3.2050808@linux.vnet.ibm.com> <4FC32F31.3050308@linux.vnet.ibm.com> Message-ID: <4FC36631.80207@linux.vnet.ibm.com> I have write an example. Now it can only add the import module automatically . see the attachment. What about this way to add the NOT_GENERATED codes? if OK, I will go ahead to add the left NOT_GENERATED codes. such as how to add an attribute of an class. On 05/28/2012 03:54 PM, ShaoHe Feng wrote: > On 05/28/2012 03:26 PM, ShaoHe Feng wrote: >> On 05/28/2012 02:56 PM, Michael Pasternak wrote: >>> On 05/27/2012 08:06 PM, ShaoHe Feng wrote: >>>> On 05/26/2012 01:48 AM, Michael Pasternak wrote: >>>>> Hi, >>>>> >>>>> On 05/24/2012 09:13 PM, ShaoHe Fen3g wrote: >>>>>> Hi all, >>>>>> >>>>>> Now I'm using the code generation suites of ovirt-engine-sdk, I >>>>>> find it is very troublesome. >>>>> I completely agree with you, automating python entities generation >>>>> is on top >>>>> of my TODO stack see [1], >>>>> >>>>> Along with this, there was always something more important to do, and >>>>> it was delayed time after time, so your help is most welcome. >>>>> >>>>> [1] http://www.ovirt.org/wiki/SDK#codegen >>>>> >>>>>> IMO, we can simplify the process. And I want to engaged in it. >>>>>> >>>>>> there are two tools parse the api.xsd and generate the params.py >>>>>> code. They are generateds_gui.py and generateDS.py. >>>>>> but there still some code can not be generate by these tools. now >>>>>> we should add these codes manually. >>>>>> >>>>>> the not NOT_GENERATED codes are as follow in the current >>>>>> params.py code: >>>>>> 1. import python module >>>>>> 2. a new attribute of GeneratedsSuper class >>>>>> 3. modify the get_root_tag function. >>>>>> 4. modify the parseString function to shut up the stdout. >>>>>> 5. _rootClassMap >>>>>> 6 . _elementToClassMap >>>>>> 7. findRootClass >>>>>> >>>>>> And I have two ideas about the code generation. >>>>>> For we should not modify the generateDS.py tools. >>>>>> But we can improve it. >>>>>> >>>>>> I think the 1, 2, 3, 7, can be hard-code, and 4, 5 and 6 can be >>>>>> configured. >>>>>> So I want to add an configure file to tell how to add the extra >>>>>> code that are not generated by generateDS.py tools. >>>>>> And new python program, as extension of generateDS.py to read >>>>>> the configure file and generate these codes. >>>>> sounds good, btw 5,6 can be constructed programmatically using >>>>> __all__ generated by generateDS >>>>> and finding element name in xsd by type (from __all__). >>>> should all the element name in xsd by type be added to >>>> _rootClassMap, and no element can be exception? >>> basically yes, cause _rootClassMap is holder which used >>> for (by name) type retrieval, >>> only exception is if certain type is not referenced by any other >>> type (then none will look for >>> it during the type construction), but i would not implement this logic. >>> >> Hi Michael, >> what's your account on ovirt IRC channel? > seem I can not log on the #ovirt IRC channel. > > still some questions. > can I edit the generateDS.py directly in order to generate the > params.py code that we expect. and then rename the generateDS.py, put > it into the SDK directory? > or an new py program to call the functions of generateDS? > >>>>>> Or without the configure file, just make the new python program >>>>>> that supports an interactive commands. >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Engine-devel mailing list >>>>>> Engine-devel at ovirt.org >>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> >> > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: genparams.py Type: text/x-python Size: 1913 bytes Desc: not available URL: From ovirt at qip.ru Mon May 28 13:35:06 2012 From: ovirt at qip.ru (ovirt at qip.ru) Date: Mon, 28 May 2012 17:35:06 +0400 Subject: [Engine-devel] upgrade.sh error after commit e592cb210b6bceba6414e4b89c8456b21532f479 Message-ID: <9228553bfd96d4df290f459aa32311d55b87e183@mail.qip.ru> # ./upgrade.sh -u postgres Running upgrade script upgrade/03_01_1120_vm_device_add_alias_column.sql psql:upgrade/03_01_1120_vm_device_add_alias_column.sql:1: invalid command \''); -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From ovedo at redhat.com Mon May 28 13:39:52 2012 From: ovedo at redhat.com (Oved Ourfalli) Date: Mon, 28 May 2012 09:39:52 -0400 (EDT) Subject: [Engine-devel] upgrade.sh error after commit e592cb210b6bceba6414e4b89c8456b21532f479 In-Reply-To: <9228553bfd96d4df290f459aa32311d55b87e183@mail.qip.ru> Message-ID: <4808e793-d54f-4762-a568-ea9ebc54bc80@zmail02.collab.prod.int.phx2.redhat.com> Fix pushed a minute ago. Fetch, and run the the upgrade again. Sorry for the inconvenience, Oved ----- Original Message ----- > From: ovirt at qip.ru > To: engine-devel at ovirt.org > Sent: Monday, May 28, 2012 4:35:06 PM > Subject: [Engine-devel] upgrade.sh error after commit e592cb210b6bceba6414e4b89c8456b21532f479 > > > > # ./upgrade.sh -u postgres > Running upgrade script > upgrade/03_01_1120_vm_device_add_alias_column.sql > psql:upgrade/03_01_1120_vm_device_add_alias_column.sql:1: invalid > command \''); > > > > > -- > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From oschreib at redhat.com Mon May 28 14:24:05 2012 From: oschreib at redhat.com (Ofer Schreiber) Date: Mon, 28 May 2012 10:24:05 -0400 (EDT) Subject: [Engine-devel] oVirt 3.1 Blocker - BZ#822158 - fail to join host to cluster In-Reply-To: Message-ID: Hey Yair, BZ#822158 (https://bugzilla.redhat.com/show_bug.cgi?id=822158) is currently marked as oVirt 3.1 release blocker. I'd like to get some updates from you, As the assignee for this bug: 1. What is the current status of this bug? 2. Any time estimation for a complete fix? Thanks, -- Ofer Schreiber oVirt Release Manager From iheim at redhat.com Mon May 28 18:31:17 2012 From: iheim at redhat.com (Itamar Heim) Date: Mon, 28 May 2012 21:31:17 +0300 Subject: [Engine-devel] REST-API: Exposing correlation-ID In-Reply-To: References: Message-ID: <4FC3C475.9030804@redhat.com> On 05/28/2012 02:35 PM, Ori Liel wrote: > Quite a few people liked flow-id, and no one objected to it > explicitly, so I'll just go with that. > > If someone feels strongly against, please reply. I still like 'label' better. it doesn't have the context of a unique id, and is much more correct to what this is - allows the user to label a command (or a set of commands). but also doesn't imply it's unique in any way (i.e., it's like a "tag", just a better, non overloaded term for it). > > Ori > > ----- Original Message ----- > From: "Michael Pasternak" > To: "Moti Asayag" > Cc: "Ori Liel", engine-devel at ovirt.org > Sent: Monday, May 28, 2012 2:26:10 PM > Subject: Re: [Engine-devel] REST-API: Exposing correlation-ID > > On 05/15/2012 05:31 PM, Moti Asayag wrote: >> On 05/14/2012 02:19 PM, Ori Liel wrote: >>>> No decision about the name of the parameter yet, and this is blocking me. >>>> >>>> Names that were suggested so far: >>>> >>>> * flow-id > > +1 > From lpeer at redhat.com Tue May 29 05:56:00 2012 From: lpeer at redhat.com (Livnat Peer) Date: Tue, 29 May 2012 08:56:00 +0300 Subject: [Engine-devel] REST-API: Exposing correlation-ID In-Reply-To: <4FC3C475.9030804@redhat.com> References: <4FC3C475.9030804@redhat.com> Message-ID: <4FC464F0.2010904@redhat.com> On 28/05/12 21:31, Itamar Heim wrote: > On 05/28/2012 02:35 PM, Ori Liel wrote: >> Quite a few people liked flow-id, and no one objected to it >> explicitly, so I'll just go with that. >> >> If someone feels strongly against, please reply. > > I still like 'label' better. > it doesn't have the context of a unique id, and is much more correct to > what this is - allows the user to label a command (or a set of commands). > but also doesn't imply it's unique in any way (i.e., it's like a "tag", > just a better, non overloaded term for it). > I think that flow-id is confusing. This id has nothing to do with flow, it can aggregate multiple commands and it is not associated with a specific user flow. Correlation-Id is a common name for such Id, we took it from the terminology used in JMS queues, but Microsoft and Oracle are using CID too. * http://www.microsoft.com/en-us/download/details.aspx?id=23842 * http://sharepoint.microsoft.com/blogs/GetThePoint/Lists/Posts/Post.aspx?ID=353 * http://docs.oracle.com/cd/B14099_19/integrate.1012/b25709/com/oracle/bpel/client/CorrelationId.html >> >> Ori >> >> ----- Original Message ----- >> From: "Michael Pasternak" >> To: "Moti Asayag" >> Cc: "Ori Liel", engine-devel at ovirt.org >> Sent: Monday, May 28, 2012 2:26:10 PM >> Subject: Re: [Engine-devel] REST-API: Exposing correlation-ID >> >> On 05/15/2012 05:31 PM, Moti Asayag wrote: >>> On 05/14/2012 02:19 PM, Ori Liel wrote: >>>>> No decision about the name of the parameter yet, and this is >>>>> blocking me. >>>>> >>>>> Names that were suggested so far: >>>>> >>>>> * flow-id >> >> +1 >> > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From yzaslavs at redhat.com Tue May 29 06:05:23 2012 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Tue, 29 May 2012 09:05:23 +0300 Subject: [Engine-devel] oVirt 3.1 Blocker - BZ#822158 - fail to join host to cluster In-Reply-To: References: Message-ID: <4FC46723.4030305@redhat.com> On 05/28/2012 05:24 PM, Ofer Schreiber wrote: > Hey Yair, > > BZ#822158 (https://bugzilla.redhat.com/show_bug.cgi?id=822158) is currently marked as oVirt 3.1 release blocker. > I'd like to get some updates from you, As the assignee for this bug: > > 1. What is the current status of this bug? > 2. Any time estimation for a complete fix? > > Thanks, As I previous emailed , maybe not including you (sorry for that :( ) - I suggest for next build we report version 4.10 (see comment #2 at the bug). Changing to 3 part version involves touching too many parts of code. In order to obtain this, we should add 4.10 at SupportedVDSMVersions (one of the values at vdc_options) - I already tested that and it works. Comments on this? > -- > Ofer Schreiber > oVirt Release Manager From iheim at redhat.com Tue May 29 06:03:16 2012 From: iheim at redhat.com (Itamar Heim) Date: Tue, 29 May 2012 09:03:16 +0300 Subject: [Engine-devel] REST-API: Exposing correlation-ID In-Reply-To: <4FC464F0.2010904@redhat.com> References: <4FC3C475.9030804@redhat.com> <4FC464F0.2010904@redhat.com> Message-ID: <4FC466A4.5050008@redhat.com> On 05/29/2012 08:56 AM, Livnat Peer wrote: > On 28/05/12 21:31, Itamar Heim wrote: >> On 05/28/2012 02:35 PM, Ori Liel wrote: >>> Quite a few people liked flow-id, and no one objected to it >>> explicitly, so I'll just go with that. >>> >>> If someone feels strongly against, please reply. >> >> I still like 'label' better. >> it doesn't have the context of a unique id, and is much more correct to >> what this is - allows the user to label a command (or a set of commands). >> but also doesn't imply it's unique in any way (i.e., it's like a "tag", >> just a better, non overloaded term for it). >> > > I think that flow-id is confusing. This id has nothing to do with flow, > it can aggregate multiple commands and it is not associated with a > specific user flow. > > Correlation-Id is a common name for such Id, we took it from the > terminology used in JMS queues, but Microsoft and Oracle are using CID too. > > * http://www.microsoft.com/en-us/download/details.aspx?id=23842 > * > http://sharepoint.microsoft.com/blogs/GetThePoint/Lists/Posts/Post.aspx?ID=353 > * > http://docs.oracle.com/cd/B14099_19/integrate.1012/b25709/com/oracle/bpel/client/CorrelationId.html but all of those conform to the concept of an "id" uniquely identifies the correlation. in our case, it is not unique, and just a label the user sets. From lpeer at redhat.com Tue May 29 06:14:14 2012 From: lpeer at redhat.com (Livnat Peer) Date: Tue, 29 May 2012 09:14:14 +0300 Subject: [Engine-devel] REST-API: Exposing correlation-ID In-Reply-To: <4FC466A4.5050008@redhat.com> References: <4FC3C475.9030804@redhat.com> <4FC464F0.2010904@redhat.com> <4FC466A4.5050008@redhat.com> Message-ID: <4FC46936.5050906@redhat.com> On 29/05/12 09:03, Itamar Heim wrote: > On 05/29/2012 08:56 AM, Livnat Peer wrote: >> On 28/05/12 21:31, Itamar Heim wrote: >>> On 05/28/2012 02:35 PM, Ori Liel wrote: >>>> Quite a few people liked flow-id, and no one objected to it >>>> explicitly, so I'll just go with that. >>>> >>>> If someone feels strongly against, please reply. >>> >>> I still like 'label' better. >>> it doesn't have the context of a unique id, and is much more correct to >>> what this is - allows the user to label a command (or a set of >>> commands). >>> but also doesn't imply it's unique in any way (i.e., it's like a "tag", >>> just a better, non overloaded term for it). >>> >> >> I think that flow-id is confusing. This id has nothing to do with flow, >> it can aggregate multiple commands and it is not associated with a >> specific user flow. >> >> Correlation-Id is a common name for such Id, we took it from the >> terminology used in JMS queues, but Microsoft and Oracle are using CID >> too. >> >> * http://www.microsoft.com/en-us/download/details.aspx?id=23842 >> * >> http://sharepoint.microsoft.com/blogs/GetThePoint/Lists/Posts/Post.aspx?ID=353 >> >> * >> http://docs.oracle.com/cd/B14099_19/integrate.1012/b25709/com/oracle/bpel/client/CorrelationId.html >> > > but all of those conform to the concept of an "id" uniquely identifies > the correlation. in our case, it is not unique, and just a label the > user sets. I don't think the uniqueness is an issue, if not abused it will be unique per flow/flow sequence. Usually correlation Id enables the user to correlate between multiple components or between multiple flows, which fits our usage of this ID. From gjansen at redhat.com Tue May 29 07:56:21 2012 From: gjansen at redhat.com (Geert Jansen) Date: Tue, 29 May 2012 09:56:21 +0200 Subject: [Engine-devel] planned changes for api capabilities resource In-Reply-To: <4FBDE8DF.5010100@redhat.com> References: <4FBDE8DF.5010100@redhat.com> Message-ID: <4FC48125.4090907@redhat.com> Hi Michael, two questions: Can you elaborate on why you think there's no backwards compatibility issues? In your proposal, are you leaving /api/capabilites in place as it is now? If not how to you enumerate the different versions? Regards, Geert On 05/24/2012 09:53 AM, Michael Pasternak wrote: > the motivation: > =============== > > 1. current design is not restfull > 2. is not consistent with the rest of api impl. > > impacts: > ======== > > as this resource not used programmatically, we do not expect any > backward compatibility issues > > planned change is: > ================= > > from: > > http://localhost:8080/api/capabilities > > > > ... > > > ... > > > > to: > > http://localhost:8080/api/capabilities/xxx > > > ... > > > (where xxx is a version number) > -- Geert Jansen Sr. Product Marketing Manager, Red Hat Enterprise Virtualization Red Hat S.r.L. O: +39 095 916287 Via G. Fara 26 C: +39 348 1980079 (when in US: 415-623-0542) Milan 20124, Italy E: gjansen at redhat.com From eglynn at redhat.com Tue May 29 09:02:10 2012 From: eglynn at redhat.com (Eoghan Glynn) Date: Tue, 29 May 2012 05:02:10 -0400 (EDT) Subject: [Engine-devel] planned changes for api capabilities resource In-Reply-To: <4FC48125.4090907@redhat.com> Message-ID: <3e08ea67-2baa-4881-a9f4-33f6da5de430@zmail11.collab.prod.int.phx2.redhat.com> > In your proposal, are you leaving /api/capabilites in place as it is > now? If not how to you enumerate the different versions? Yep, the lack of discoverability was my first thought also. Cheers, Eoghan From mpastern at redhat.com Tue May 29 10:12:38 2012 From: mpastern at redhat.com (Michael Pasternak) Date: Tue, 29 May 2012 13:12:38 +0300 Subject: [Engine-devel] planned changes for api capabilities resource In-Reply-To: <4FC48125.4090907@redhat.com> References: <4FBDE8DF.5010100@redhat.com> <4FC48125.4090907@redhat.com> Message-ID: <4FC4A116.2010809@redhat.com> On 05/29/2012 10:56 AM, Geert Jansen wrote: > Hi Michael, > > two questions: > > Can you elaborate on why you think there's no backwards compatibility issues? there is no point in using this resource programmatically, as it only contains enumerations available in the system for given version and some other metadata, i.e it used by developers during the coding and it's not real system resource. > > In your proposal, are you leaving /api/capabilites in place as it is now? no, please see new modelling below. > If not how to you enumerate the different versions? since our resource id is opaque by definition - it doesn't have to be UUID, the id for version_capabilities resource can be the version itself, i.e 3.0 / 3.1 / etc. (worst case if someone likes UUID more we can convert version str. to UUID) > > Regards, > Geert > > On 05/24/2012 09:53 AM, Michael Pasternak wrote: >> the motivation: >> =============== >> >> 1. current design is not restfull >> 2. is not consistent with the rest of api impl. >> >> impacts: >> ======== >> >> as this resource not used programmatically, we do not expect any >> backward compatibility issues >> >> planned change is: >> ================= >> >> from: >> >> http://localhost:8080/api/capabilities >> >> >> >> ... >> >> >> ... >> >> >> >> to: >> >> http://localhost:8080/api/capabilities/x.y >> >> >> >> ... >> >> >> or >> >> >> ... >> >> >> or >> >> http://localhost:8080/api/capabilities/UUID >> >> ... >> >> >> -- Michael Pasternak RedHat, ENG-Virtualization R&D From lpeer at redhat.com Tue May 29 11:39:15 2012 From: lpeer at redhat.com (Livnat Peer) Date: Tue, 29 May 2012 07:39:15 -0400 (EDT) Subject: [Engine-devel] ovirt-quantum integration Message-ID: The following is a new meeting request: Subject: ovirt-quantum integration Organiser: "Livnat Peer" Time: Wednesday, 30 May, 2012, 4:00:00 PM - 5:00:00 PM GMT +02:00 Jerusalem Invitees: engine-devel at ovirt.org *~*~*~*~*~*~*~*~*~* Hi All, We'll have a discussion on oVirt-Quantum integration tomorrow. In the meeting we'll discuss - http://www.ovirt.org/wiki/Quantum_and_oVirt Thanks, Livnat Bridge ID: 972506565679 Dial-in information: Reservationless-Plus Toll Free Dial-In Number (US & Canada): (800) 451-8679 Reservationless-Plus International Dial-In Number: (212) 729-5016 Conference code: 972506565679 Global Access Numbers Local: Australia, Sydney Dial-In #: 0289852326 Austria, Vienna Dial-In #: 012534978196 Belgium, Brussels Dial-In #: 027920405 China Dial-In #: 4006205013 Denmark, Copenhagen Dial-In #: 32729215 Finland, Helsinki Dial-In #: 0923194436 France, Paris Dial-In #: 0170377140 Germany, Berlin Dial-In #: 030300190579 Ireland, Dublin Dial-In #: 014367793 Italy, Milan Dial-In #: 0236269529 Netherlands, Amsterdam Dial-In #: 0207975872 Norway, Oslo Dial-In #: 21033188 Singapore Dial-In #: 64840858 Spain, Barcelona Dial-In #: 935452328 Sweden, Stockholm Dial-In #: 0850513770 Switzerland, Geneva Dial-In #: 0225927881 United Kingdom Dial-In #: 02078970515 United Kingdom Dial-In #: 08445790676 United Kingdom, LocalCall Dial-In #: 08445790678 United States Dial-In #: 2127295016 Global Access Numbers Tollfree: Argentina Dial-In #: 8004441016 Australia Dial-In #: 1800337169 Austria Dial-In #: 0800005898 Bahamas Dial-In #: 18002054776 Bahrain Dial-In #: 80004377 Belgium Dial-In #: 080048325 Brazil Dial-In #: 08008921002 Bulgaria Dial-In #: 008001100236 Chile Dial-In #: 800370228 Colombia Dial-In #: 018009134033 Costa Rica Dial-In #: 08000131048 Cyprus Dial-In #: 80095297 Czech Republic Dial-In #: 800700318 Denmark Dial-In #: 80887114 Dominican Republic Dial-In #: 18887512313 Estonia Dial-In #: 8000100232 Finland Dial-In #: 0800117116 France Dial-In #: 0805632867 Germany Dial-In #: 8006647541 Greece Dial-In #: 00800127562 Hong Kong Dial-In #: 800930349 Hungary Dial-In #: 0680016796 Iceland Dial-In #: 8008967 India Dial-In #: 0008006501533 Indonesia Dial-In #: 0018030179162 Ireland Dial-In #: 1800932401 Israel Dial-In #: 1809462557 Italy Dial-In #: 800985897 Jamaica Dial-In #: 18002050328 Japan Dial-In #: 0120934453 Korea (South) Dial-In #: 007986517393 Latvia Dial-In #: 80003339 Lithuania Dial-In #: 880030479 Luxembourg Dial-In #: 80026595 Malaysia Dial-In #: 1800814451 Mexico Dial-In #: 0018664590915 New Zealand Dial-In #: 0800888167 Norway Dial-In #: 80012994 Panama Dial-In #: 008002269184 Philippines Dial-In #: 180011100991 Poland Dial-In #: 008001210187 Portugal Dial-In #: 800814625 Russian Federation Dial-In #: 81080028341012 Saint Kitts and Nevis Dial-In #: 18002059252 Singapore Dial-In #: 8006162235 Slovak Republic Dial-In #: 0800001441 South Africa Dial-In #: 0800981148 Spain Dial-In #: 800300524 Sweden Dial-In #: 200896860 Switzerland Dial-In #: 800650077 Taiwan Dial-In #: 00801127141 Thailand Dial-In #: 001800656966 Trinidad and Tobago Dial-In #: 18002024615 United Arab Emirates Dial-In #: 8000650591 United Kingdom Dial-In #: 08006948057 United States Dial-In #: 8004518679 Uruguay Dial-In #: 00040190315 Venezuela Dial-In #: 08001627182 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: meeting.ics Type: text/calendar Size: 8675 bytes Desc: not available URL: From gjansen at redhat.com Tue May 29 13:14:23 2012 From: gjansen at redhat.com (Geert Jansen) Date: Tue, 29 May 2012 15:14:23 +0200 Subject: [Engine-devel] planned changes for api capabilities resource In-Reply-To: <4FC4A116.2010809@redhat.com> References: <4FBDE8DF.5010100@redhat.com> <4FC48125.4090907@redhat.com> <4FC4A116.2010809@redhat.com> Message-ID: <4FC4CBAF.5060600@redhat.com> On 05/29/2012 12:12 PM, Michael Pasternak wrote: > there is no point in using this resource programmatically, as it only contains enumerations > available in the system for given version and some other metadata, > > i.e it used by developers during the coding and it's not real system resource. I'm not convinced that that is true. For example, applications can use the "power_managers" and "cpus" elements to prepopulate lists in a user interface for example. >> >> In your proposal, are you leaving /api/capabilites in place as it is now? > > no, please see new modelling below. > >> If not how to you enumerate the different versions? > > since our resource id is opaque by definition - it doesn't have to be UUID, > the id for version_capabilities resource can be the version itself, i.e 3.0 > / 3.1 / etc. > > (worst case if someone likes UUID more we can convert version str. to UUID) How do you get a list of which IDs / versions are available? Regards, Geert From mpastern at redhat.com Tue May 29 13:44:14 2012 From: mpastern at redhat.com (Michael Pasternak) Date: Tue, 29 May 2012 16:44:14 +0300 Subject: [Engine-devel] planned changes for api capabilities resource In-Reply-To: <4FC4CBAF.5060600@redhat.com> References: <4FBDE8DF.5010100@redhat.com> <4FC48125.4090907@redhat.com> <4FC4A116.2010809@redhat.com> <4FC4CBAF.5060600@redhat.com> Message-ID: <4FC4D2AE.4090402@redhat.com> On 05/29/2012 04:14 PM, Geert Jansen wrote: > > > On 05/29/2012 12:12 PM, Michael Pasternak wrote: > >> there is no point in using this resource programmatically, as it only contains enumerations >> available in the system for given version and some other metadata, >> >> i.e it used by developers during the coding and it's not real system resource. > > I'm not convinced that that is true. For example, applications can use the "power_managers" and "cpus" elements to prepopulate lists in a user interface for example. this is good example indeed, then what about leaving /capabilities as is [1] only adding single resource retrieval capability [2] to comply with collection/resource pattern? [1] ... ... ... [2] /api/capabilities/UUID ... > >>> >>> In your proposal, are you leaving /api/capabilites in place as it is now? >> >> no, please see new modelling below. >> >>> If not how to you enumerate the different versions? >> >> since our resource id is opaque by definition - it doesn't have to be UUID, >> the id for version_capabilities resource can be the version itself, i.e 3.0 >> / 3.1 / etc. >> >> (worst case if someone likes UUID more we can convert version str. to UUID) > > How do you get a list of which IDs / versions are available? by listing all s as today only adding id/href to it, /api/capabilities ... ... ... i.e same as for any resource in api. > > Regards, > Geert -- Michael Pasternak RedHat, ENG-Virtualization R&D From yzaslavs at redhat.com Tue May 29 14:20:32 2012 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Tue, 29 May 2012 17:20:32 +0300 Subject: [Engine-devel] api capabilities query and presenting SupportedVdsmVersions Message-ID: <4FC4DB30.3050800@redhat.com> Hi, After seeing an email regarding api/capabilities and looking at the code, and dealing regardless of that with VDSM versions - I have a question - is it interesting for us to display the list of supported VDSM versions under api/capabilities? Kind regards, Yair From gjansen at redhat.com Tue May 29 15:26:48 2012 From: gjansen at redhat.com (Geert Jansen) Date: Tue, 29 May 2012 17:26:48 +0200 Subject: [Engine-devel] planned changes for api capabilities resource In-Reply-To: <4FC4D2AE.4090402@redhat.com> References: <4FBDE8DF.5010100@redhat.com> <4FC48125.4090907@redhat.com> <4FC4A116.2010809@redhat.com> <4FC4CBAF.5060600@redhat.com> <4FC4D2AE.4090402@redhat.com> Message-ID: <4FC4EAB8.4090004@redhat.com> On 05/29/2012 03:44 PM, Michael Pasternak wrote: > On 05/29/2012 04:14 PM, Geert Jansen wrote: >> >> >> On 05/29/2012 12:12 PM, Michael Pasternak wrote: >> >>> there is no point in using this resource programmatically, as it only contains enumerations >>> available in the system for given version and some other metadata, >>> >>> i.e it used by developers during the coding and it's not real system resource. >> >> I'm not convinced that that is true. For example, applications can use the "power_managers" and "cpus" elements to prepopulate lists in a user interface for example. > > this is good example indeed, then what about leaving /capabilities as is [1] > only adding single resource retrieval capability [2] to comply with collection/resource > pattern? > > [1] > > > > ... > > > ... > > ... > > > [2] > > /api/capabilities/UUID > > > ... > It would work from a compatibility point of view. However - to be honest - i would leave it as it is now. You also have non-version specific capabilities there, that do not fit any model. In my view there is no way to get to a clean design here. The way i look at /api/capabilities is that is is a single global singleton resource. It isn't a collection, and neither a resource in a collection. Regards, Geert From iheim at redhat.com Tue May 29 15:49:21 2012 From: iheim at redhat.com (Itamar Heim) Date: Tue, 29 May 2012 18:49:21 +0300 Subject: [Engine-devel] api capabilities query and presenting SupportedVdsmVersions In-Reply-To: <4FC4DB30.3050800@redhat.com> References: <4FC4DB30.3050800@redhat.com> Message-ID: <4FC4F001.4030004@redhat.com> On 05/29/2012 05:20 PM, Yair Zaslavsky wrote: > Hi, > After seeing an email regarding api/capabilities and looking at the > code, and dealing regardless of that with VDSM versions - > I have a question - is it interesting for us to display the list of > supported VDSM versions under api/capabilities? this is currently mostly internal to engine vs. vdsm. what would be the use case to expose this to clients? (in general, I'd wait for someone asking for such info and explain their use case before adding it) From ashok at vemuris.com Tue May 29 18:47:55 2012 From: ashok at vemuris.com (Ashok Vemuri) Date: Tue, 29 May 2012 11:47:55 -0700 Subject: [Engine-devel] Question about host compatibility version Message-ID: <922EC743AB414DB88D058CD425553CAD@vemuris.com> Hello, I have a newbie question regarding host/cluster compatibility versions. I hope someone could clarify this for me. We have an old lab setup in which we were managing KVM hostnodes using RHEV Manager (version 2.2.4.51796) . We are now trying to upgrade to the latest version of oVirt Engine (version 3.1.0_0001-1.8.el6). Now, when I add the old KVM node to oVirt Engine, I am getting following error message: Host's Compatibility Version doesn't match the Cluster's Compatibility Version Can someone tell me if oVirt Engine is backward-compatible with older hostnodes? Or do I need to upgrade one or more components (such as VDSM) on the hostnode to be compatible with new engine? Here is the version information from the hostnode I'm trying to add: OS : RHEV Hypervisor - 5.6 - 9.3.el5_6 Kernel : 2.6.18 - 238.5.1.el5 KVM : 83 - 224.el5 VDSM : 2.2.63.23 SPICE : 0.3.0 - 54.el5_5.2 Thanks, Ashok -------------- next part -------------- An HTML attachment was scrubbed... URL: From acathrow at redhat.com Tue May 29 20:16:29 2012 From: acathrow at redhat.com (Andrew Cathrow) Date: Tue, 29 May 2012 16:16:29 -0400 (EDT) Subject: [Engine-devel] Question about host compatibility version In-Reply-To: <922EC743AB414DB88D058CD425553CAD@vemuris.com> Message-ID: <18997c3a-2d8f-45ad-b4f1-7aa94cabbda8@zmail07.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Ashok Vemuri" > To: engine-devel at ovirt.org > Sent: Tuesday, May 29, 2012 2:47:55 PM > Subject: [Engine-devel] Question about host compatibility version > > > > Hello, > > > I have a newbie question regarding host/cluster compatibility > versions. I hope someone could clarify this for me. > > > We have an old lab setup in which we were managing KVM hostnodes > using RHEV Manager ( version 2.2.4.51796 ) . We are now trying to > upgrade to the latest version of oVirt Engine ( version > 3.1.0_0001-1.8.el6 ). > > > Now, when I add the old KVM node to oVirt Engine, I am getting > following error message: > Host's Compatibility Version doesn't match the Cluster's > Compatibility Version > Can someone tell me if oVirt Engine is backward-compatible with older > hostnodes? Or do I need to upgrade one or more components (such as > VDSM) on the hostnode to be compatible with new engine? > > oVirt 3.1 will support 3.0 and 3.1 cluster levels, but it looks like you're trying to mix RHEV 2.2 RHEV hypervisors with oVirt 3.1, that's not going to work. I've never tried mixing RHEV 2.2 and oVirt 3.0, it might work in theory but for sure RHEV 2.2 and oVirt 3.1 will not work. > Here is the version information from the hostnode I'm trying to add: > > > OS : RHEV Hypervisor - 5.6 - 9.3.el5_6 > Kernel : 2.6.18 - 238.5.1.el5 > KVM : 83 - 224.el5 > VDSM : 2.2.63.23 > SPICE : 0.3.0 - 54.el5_5.2 > > > Thanks, > Ashok > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From mpastern at redhat.com Wed May 30 06:45:48 2012 From: mpastern at redhat.com (Michael Pasternak) Date: Wed, 30 May 2012 09:45:48 +0300 Subject: [Engine-devel] planned changes for api capabilities resource In-Reply-To: <4FC4EAB8.4090004@redhat.com> References: <4FBDE8DF.5010100@redhat.com> <4FC48125.4090907@redhat.com> <4FC4A116.2010809@redhat.com> <4FC4CBAF.5060600@redhat.com> <4FC4D2AE.4090402@redhat.com> <4FC4EAB8.4090004@redhat.com> Message-ID: <4FC5C21C.5020307@redhat.com> On 05/29/2012 06:26 PM, Geert Jansen wrote: > > > On 05/29/2012 03:44 PM, Michael Pasternak wrote: >> On 05/29/2012 04:14 PM, Geert Jansen wrote: >>> >>> >>> On 05/29/2012 12:12 PM, Michael Pasternak wrote: >>> >>>> there is no point in using this resource programmatically, as it only contains enumerations >>>> available in the system for given version and some other metadata, >>>> >>>> i.e it used by developers during the coding and it's not real system resource. >>> >>> I'm not convinced that that is true. For example, applications can use the "power_managers" and "cpus" elements to prepopulate lists in a user interface for example. >> >> this is good example indeed, then what about leaving /capabilities as is [1] >> only adding single resource retrieval capability [2] to comply with collection/resource >> pattern? >> >> [1] >> >> >> >> ... >> >> >> ... >> >> ... >> >> >> [2] >> >> /api/capabilities/UUID >> >> >> ... >> > > It would work from a compatibility point of view. However - to be honest - i would leave it as it is now. You also have non-version specific capabilities there, that do not > fit any model. In my view there is no way to get to a clean design here. > > The way i look at /api/capabilities is that is is a single global singleton resource. It isn't a collection, and neither a resource in a collection. it should have be collection of version_capabilities cause otherwise it not RESTful resource and inconsistent with other resources in api, as about /currently/ non-version specific capabilities: should be version specific as in new version will be added new permits and same for the , can you remind me what was the reasons for making them such. > > Regards, > Geert -- Michael Pasternak RedHat, ENG-Virtualization R&D From deepakcs at linux.vnet.ibm.com Wed May 30 09:38:46 2012 From: deepakcs at linux.vnet.ibm.com (Deepak C Shetty) Date: Wed, 30 May 2012 15:08:46 +0530 Subject: [Engine-devel] RFC: Writeup on VDSM-libstoragemgmt integration Message-ID: <4FC5EAA6.3090605@linux.vnet.ibm.com> Hello All, I have a draft write-up on the VDSM-libstoragemgmt integration. I wanted to run this thru' the mailing list(s) to help tune and crystallize it, before putting it on the ovirt wiki. I have run this once thru Ayal and Tony, so have some of their comments incorporated. I still have few doubts/questions, which I have posted below with lines ending with '?' Comments / Suggestions are welcome & appreciated. thanx, deepak [Ccing engine-devel and libstoragemgmt lists as this stuff is relevant to them too] -------------------------------------------------------------------------------------------------------------- 1) Background: VDSM provides high level API for node virtualization management. It acts in response to the requests sent by oVirt Engine, which uses VDSM to do all node virtualization related tasks, including but not limited to storage management. libstoragemgmt aims to provide vendor agnostic API for managing external storage array. It should help system administrators utilizing open source solutions have a way to programmatically manage their storage hardware in a vendor neutral way. It also aims to facilitate management automation, ease of use and take advantage of storage vendor supported features which improve storage performance and space utilization. Home Page: http://sourceforge.net/apps/trac/libstoragemgmt/ libstoragemgmt (LSM) today supports C and python plugins for talking to external storage array using SMI-S as well as native interfaces (eg: netapp plugin ) Plan is to grow the SMI-S interface as needed over time and add more vendor specific plugins for exploiting features not possible via SMI-S or have better alternatives than using SMI-S. For eg: Many of the copy offload features require to use vendor specific commands, which justifies the need for a vendor specific plugin. 2) Goals: 2a) Ability to plugin external storage array into oVirt/VDSM virtualization stack, in a vendor neutral way. 2b) Ability to list features/capabilities and other statistical info of the array 2c) Ability to utilize the storage array offload capabilities from oVirt/VDSM. 3) Details: LSM will sit as a new repository engine in VDSM. VDSM Repository Engine WIP @ http://gerrit.ovirt.org/#change,192 Current plan is to have LSM co-exist with VDSM on the virtualization nodes. *Note : 'storage' used below is generic. It can be a file/nfs-export for NAS targets and LUN/logical-drive for SAN targets. VDSM can use LSM and do the following... - Provision storage - Consume storage 3.1) Provisioning Storage using LSM Typically this will be done by a Storage administrator. oVirt/VDSM should provide storage admin the - ability to list the different storage arrays along with their types (NAS/SAN), capabilities, free/used space. - ability to provision storage using any of the array capabilities (eg: thin provisioned lun or new NFS export ) - ability to manage the provisioned storage (eg: resize/delete storage) Once the storage is provisioned by the storage admin, VDSM will have to refresh the host(s) for them to be able to see the newly provisioned storage. 3.1.1) Potential flows: Mgmt -> vdsm -> lsm: create LUN + LUN Mapping / Zoning / whatever is needed to make LUN available to list of hosts passed by mgmt Mgmt -> vdsm: getDeviceList (refreshes host and gets list of devices) Repeat above for all relevant hosts (depending on list passed earlier, mostly relevant when extending an existing VG) Mgmt -> use LUN in normal flows. 3.1.2) How oVirt Engine will know which LSM to use ? Normally the way this works today is that user can choose the host to use (default today is SPM), however there are a few flows where mgmt will know which host to use: 1. extend storage domain (add LUN to existing VG) - Use SPM and make sure *all* hosts that need access to this SD can see the new LUN 2. attach new LUN to a VM which is pinned to a specific host - use this host 3. attach new LUN to a VM which is not pinned - use a host from the cluster the VM belongs to and make sure all nodes in cluster can see the new LUN Flows for which there is no clear candidate (Maybe we can use the SPM host itself which is the default ?) 1. create a new disk without attaching it to any VM 2. create a LUN for a new storage domain 3.2) Consuming storage using LSM Typically this will be done by a virtualization administrator oVirt/VDSM should allow virtualization admin to - Create a new storage domain using the storage on the array. - Be able to specify whether VDSM should use the storage offload capability (default) or override it to use its own internal logic. 4) VDSM potential changes: 4.1) How to represent a VM disk, 1 LUN = 1 VMdisk or 1 LV = 1 VMdisk ? which bring another question...1 array == 1 storage domain OR 1 LUN/nfs-export on the array == 1 storage domain ? Pros & Cons of each... 1 array == 1 storage domain - Each new vmdisk (aka volume) will be a new lun/file on the array. - Easier to exploit offload capabilities, as they are available at the LUN/File granularity - Will there be any issues where there will be too many LUNs/Files ... any maxluns limit on linux hosts that we might hit ? -- VDSM has been tested with 1K LUNs and it worked fine - ayal - Storage array limitations on the number of LUNs can be a downside here. - Would it be ok to share the array for hosting another storage domain if need be ? -- Provided the existing domain is not utilising all of the free space -- We can create new LUNs and hand it over to anyone needed ? -- Changes needed in VDSM to work with raw LUNs, today it only has support for consuming LUNs via VG/LV. 1 LUN/nfs-export on the array == 1 storage domain - How to represent a new vmdisk (aka vdsm volume) if its a LUN provisioned using SAN target ? -- Will it be VG/LV as is done today for block domains ? -- If yes, then it will be difficult to exploit offload capabilities, as they are at LUN level, not at LV level. - Each new vmdisk will be a new file on the nfs-export, assuming offload capability is available at the file level, so this should work for NAS targets ? - Can use the storage array for hosting multiple storage domains. -- Provision one more LUN and use it for another storage domain if need be. - VDSM already supports this today, as part of block storage domains for LUNs case. Note that we will allow user to do either one of the two options above, depending on need. 4.2) Storage domain metadata will also include the features/capabilities of the storage array as reported by LSM. - Capabilities (taken via LSM) will be stored in the domain metadata during storage domain create flow. - Need changes in oVirt engine as well ( see 'oVirt Engine potential changes' section below ) 4.3) VDSM to poll LSM for array capabilities on a regular basis ? Per ayal: - If we have a 'storage array' entity in oVirt Engine (see 'oVirt Engine potential changes' section below ) then we can have a 'refresh capabilities' button/verb. - We can periodically query the storage array. - Query LSM before running operations (sounds redundant to me, but if it's cheap enough it could be simplest). Probably need a combination of 1+2 (query at very low frequency - 1/hour or 1/day + refresh button) 5) oVirt Engine potential changes - as described by ayal : - We will either need a new 'storage array' entity in engine to keep credentials, or, in case of storage array as storage domain, just keep this info as part of the domain at engine level. - Have a 'storage array' entity in oVirt Engine to support 'refresh capabilities' as a button/verb. - When user during storage provisioning, selects a LUN exported from a storage array (via LSM), the oVirt Engine would know from then onwards that this LUN is being served via LSM. It would then be able to query the capabilities of the LUN and show it to the virt admin during storage consumption flow. 6) Potential flows: - Create snapshot flow -- VDSM will check the snapshot offload capability in the domain metadata -- If available, and override is not configured, it will use LSM to offload LUN/File snapshot -- If override is configured or capability is not available, it will use its internal logic to create snapshot (qcow2). - Copy/Clone vmdisk flow -- VDSM will check the copy offload capability in the domain metadata -- If available, and override is not configured, it will use LSM to offload LUN/File copy -- If override is configured or capability is not available, it will use its internal logic to create snapshot (eg: dd cmd in case of LUN). 7) LSM potential changes: - list features/capabilities of the array. Eg: copy offload, thin prov. etc. - list containers (aka pools) (present in LSM today) - Ability to list different types of arrays being managed, their capabilities and used/free space - Ability to create/list/delete/resize volumes ( LUN or exports, available in LSM as of today) - Get monitoring info with object (LUN/snapshot/volume) as optional parameter for specific info. eg: container/pool free/used space, raid type etc. Need to make sure above info is listed in a coherent way across arrays (number of LUNs, raid type used? free/total per container/pool, per LUN?. Also need I/O statistics wherever possible. From lpeer at redhat.com Wed May 30 11:43:08 2012 From: lpeer at redhat.com (Livnat Peer) Date: Wed, 30 May 2012 14:43:08 +0300 Subject: [Engine-devel] quantum ovirt integration meeting Message-ID: <4FC607CC.1010503@redhat.com> Hi All, Garry is sick and can not make it for today's meeting. Since he wrote the wiki proposal we'll reschedule this meeting to later this week or early next week. I'll send update soon. thanks, Livnat From lpeer at redhat.com Wed May 30 11:45:20 2012 From: lpeer at redhat.com (Livnat Peer) Date: Wed, 30 May 2012 07:45:20 -0400 (EDT) Subject: [Engine-devel] Cancelled: ovirt-quantum integration Message-ID: The following meeting has been cancelled: Subject: ovirt-quantum integration Organiser: "Livnat Peer" Time: Wednesday, 30 May, 2012, 4:00:00 PM - 5:00:00 PM GMT +02:00 Jerusalem Invitees: engine-devel at ovirt.org; ovedo at redhat.com; mkenneth at redhat.com; irenab at mellanox.com; atal at redhat.com; Ricky.Hopper at netapp.com; simon at redhat.com; gkotton at redhat.com *~*~*~*~*~*~*~*~*~* Garry is sick, he won't be available today, I'll reschedule this meeting soon. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: meeting.ics Type: text/calendar Size: 2905 bytes Desc: not available URL: From gjansen at redhat.com Wed May 30 12:07:21 2012 From: gjansen at redhat.com (Geert Jansen) Date: Wed, 30 May 2012 14:07:21 +0200 Subject: [Engine-devel] planned changes for api capabilities resource In-Reply-To: <4FC5C21C.5020307@redhat.com> References: <4FBDE8DF.5010100@redhat.com> <4FC48125.4090907@redhat.com> <4FC4A116.2010809@redhat.com> <4FC4CBAF.5060600@redhat.com> <4FC4D2AE.4090402@redhat.com> <4FC4EAB8.4090004@redhat.com> <4FC5C21C.5020307@redhat.com> Message-ID: <4FC60D79.2020103@redhat.com> On 05/30/2012 08:45 AM, Michael Pasternak wrote: > as about/currently/ non-version specific capabilities: should be version specific as in new version > will be added new permits and same for the, can you remind me what was the reasons for > making them such. I don't know, you should ask Mark or Eoghan... Regards, Geert From ofrenkel at redhat.com Wed May 30 14:39:12 2012 From: ofrenkel at redhat.com (Omer Frenkel) Date: Wed, 30 May 2012 10:39:12 -0400 (EDT) Subject: [Engine-devel] Adding atomic restore snapshot command at backend In-Reply-To: <4FC36366.7040207@redhat.com> Message-ID: ----- Original Message ----- > From: "Michael Pasternak" > To: "Livnat Peer" > Cc: "engine-devel" > Sent: Monday, May 28, 2012 2:37:10 PM > Subject: Re: [Engine-devel] Adding atomic restore snapshot command at backend > > > Hi Livnat, > > On 05/28/2012 02:07 PM, Livnat Peer wrote: > > On 28/05/12 12:59, Michael Pasternak wrote: > >> > >> Currently 'restore snapshot' done in two steps on a client side: > >> > >> 1. TryBackToAllSnapshotsOfVm > >> 2. RestoreAllSnapshots > >> > >> This implementation creates race condition on 1 and therefore > >> unstable & bug prone, IIRC, there is an easy way to fix this, by polling on engine jobs and not vdsm tasks, no? > >> i suggested refactoring 2 to include 1 as single atomic operation > >> at backend. > >> > >> > > > > Hi Michael, > > > > The two commands above are used for functionality that is needed > > regardless of the functionality you are looking for. > > We want to present the user the option to preview a snapshot > > without > > committing to it and without loosing the current snapshot. > > I think we need to model the the two options above in the REST, it > > is > > functionality that is used in the UI. +1 for that. > > this is out of scope of this RFE. > > > > > What you are looking for is a functionality 'restore to snapshot', > > this > > functionality does not exist in the engine in a single step, and I > > think > > that because we assumed that the user can get it in two steps It > > wasn't > > prioritize so far. > > the cons. of this approach is an async nature of the former command. > > > > > Implementing the missing functionality with the two functions above > > is > > a compromise that was done in the API. > > > > To summarize I think the requirement you present is a missing > > functionality in the engine and solving it is not about refactoring > > the > > two existing verbs into one. > > what i meant is not deprecating/refactoring old commands, but > introducing > new one that reusing them and expose as single (atomic) command > called > 'RestoreAllSnapshots', > > sorry if i wasn't clear. another suggestion is to have a way to send to the engine list of commands that will be performed. > > > > > Thanks, Livnat > > > > > -- > > Michael Pasternak > RedHat, ENG-Virtualization R&D > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From mpastern at redhat.com Wed May 30 14:55:37 2012 From: mpastern at redhat.com (Michael Pasternak) Date: Wed, 30 May 2012 17:55:37 +0300 Subject: [Engine-devel] Adding atomic restore snapshot command at backend In-Reply-To: References: Message-ID: <4FC634E9.5040709@redhat.com> On 05/30/2012 05:39 PM, Omer Frenkel wrote: > > > ----- Original Message ----- >> From: "Michael Pasternak" >> To: "Livnat Peer" >> Cc: "engine-devel" >> Sent: Monday, May 28, 2012 2:37:10 PM >> Subject: Re: [Engine-devel] Adding atomic restore snapshot command at backend >> >> >> Hi Livnat, >> >> On 05/28/2012 02:07 PM, Livnat Peer wrote: >>> On 28/05/12 12:59, Michael Pasternak wrote: >>>> >>>> Currently 'restore snapshot' done in two steps on a client side: >>>> >>>> 1. TryBackToAllSnapshotsOfVm >>>> 2. RestoreAllSnapshots >>>> >>>> This implementation creates race condition on 1 and therefore >>>> unstable & bug prone, > > IIRC, there is an easy way to fix this, > by polling on engine jobs and not vdsm tasks, no? indeed, and we already doing that, but it still fails on race at former command. > >>>> i suggested refactoring 2 to include 1 as single atomic operation >>>> at backend. >>>> >>>> >>> >>> Hi Michael, >>> >>> The two commands above are used for functionality that is needed >>> regardless of the functionality you are looking for. >>> We want to present the user the option to preview a snapshot >>> without >>> committing to it and without loosing the current snapshot. >>> I think we need to model the the two options above in the REST, it >>> is >>> functionality that is used in the UI. > > +1 for that. > >> >> this is out of scope of this RFE. >> >>> >>> What you are looking for is a functionality 'restore to snapshot', >>> this >>> functionality does not exist in the engine in a single step, and I >>> think >>> that because we assumed that the user can get it in two steps It >>> wasn't >>> prioritize so far. >> >> the cons. of this approach is an async nature of the former command. >> >>> >>> Implementing the missing functionality with the two functions above >>> is >>> a compromise that was done in the API. >>> >>> To summarize I think the requirement you present is a missing >>> functionality in the engine and solving it is not about refactoring >>> the >>> two existing verbs into one. >> >> what i meant is not deprecating/refactoring old commands, but >> introducing >> new one that reusing them and expose as single (atomic) command >> called >> 'RestoreAllSnapshots', >> >> sorry if i wasn't clear. > > another suggestion is to have a way to send to the engine list of commands that will be performed. afaik both UI and API perform restore in a same manner, 1. TryBackToAllSnapshotsOfVm 2. polling 3. RestoreAllSnapshots so why not combining 1 & 3 in to single command, if from clients perspective it is such ... > >> >>> >>> Thanks, Livnat >>> >> >> >> -- >> >> Michael Pasternak >> RedHat, ENG-Virtualization R&D >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> -- Michael Pasternak RedHat, ENG-Virtualization R&D From ofrenkel at redhat.com Wed May 30 15:15:55 2012 From: ofrenkel at redhat.com (Omer Frenkel) Date: Wed, 30 May 2012 11:15:55 -0400 (EDT) Subject: [Engine-devel] Enabling guest memory balloon device In-Reply-To: <4FC2810A.3090307@redhat.com> Message-ID: ----- Original Message ----- > From: "Doron Fediuck" > To: engine-devel at ovirt.org, "Adam Litke" > Sent: Sunday, May 27, 2012 10:31:22 PM > Subject: [Engine-devel] Enabling guest memory balloon device > > Hi All, > In the following wiki, there's a design for enabling the balloon > device, > which is currently disabled in engine setups. Other than enabling the > device, > this is also a step forward in the path to vdsm and MoM sub-project > integration. > > More details can be found here: > http://www.ovirt.org/wiki/Features/Design/memory-balloon > > P.S. > UI mockups should be updated soon. > -- > > /d > > ?Funny,? he intoned funereally, ?how just when you think life can't > possibly get any worse it suddenly does.? --Douglas Adams, The > Hitchhiker's Guide to the Galaxy > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > what does it mean template is not supported? (and why is it under ovf section?) this value will not pass to a template created from a vm? (although its mentioned in Backend-vdsm parts section) if this is a vm-device, why do we need it in vm_static? can you explain means the change in VmOldInfoBuilder? shouldn't we just ignore it to keep old behavior? or we want to support ballooning in all clusters? (in Validations section it says only 3.1 is supported) maybe validation is needed on changing vm cluster command, in case changing to 3.0 cluster and balloon enabled. From juan.hernandez at redhat.com Wed May 30 15:49:26 2012 From: juan.hernandez at redhat.com (Juan Hernandez) Date: Wed, 30 May 2012 17:49:26 +0200 Subject: [Engine-devel] Using 3.1.0 instead of 3.1.0-0001 for next release? Message-ID: <4FC64186.7000108@redhat.com> Hello, I think we have the opportunity now to clean the version number and use 3.1.0 instead of 3.1.0-0001 for the next release. I submitted the corresponding change to gerrit for review: http://gerrit.ovirt.org/4914 As far as I can tell there are no issues introduced by this change and it allows a cleaner versioning schema for the RPM packages. Please let me now if you foresee any issue. Regards, Juan Hernandez From dfediuck at redhat.com Wed May 30 16:32:09 2012 From: dfediuck at redhat.com (Doron Fediuck) Date: Wed, 30 May 2012 19:32:09 +0300 Subject: [Engine-devel] Enabling guest memory balloon device In-Reply-To: References: Message-ID: <4FC64B89.30909@redhat.com> On 30/05/12 18:15, Omer Frenkel wrote: > > > ----- Original Message ----- >> From: "Doron Fediuck" >> To: engine-devel at ovirt.org, "Adam Litke" >> Sent: Sunday, May 27, 2012 10:31:22 PM >> Subject: [Engine-devel] Enabling guest memory balloon device >> >> Hi All, >> In the following wiki, there's a design for enabling the balloon >> device, >> which is currently disabled in engine setups. Other than enabling the >> device, >> this is also a step forward in the path to vdsm and MoM sub-project >> integration. >> >> More details can be found here: >> http://www.ovirt.org/wiki/Features/Design/memory-balloon >> >> P.S. >> UI mockups should be updated soon. >> -- >> >> /d >> >> ?Funny,? he intoned funereally, ?how just when you think life can't >> possibly get any worse it suddenly does.? --Douglas Adams, The >> Hitchhiker's Guide to the Galaxy >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> > > what does it mean template is not supported? (and why is it under ovf section?) > this value will not pass to a template created from a vm? (although its mentioned in Backend-vdsm parts section) The unsupported phrase is just for template changes. Template editing will not show it in UI (it actually doesn't have the whole resource allocation part a VM has). But, creating a new template from a vm will enable/disable the device based on the parent VM's value, > > if this is a vm-device, why do we need it in vm_static? We need a way for UI/REST to get the state of an existing VM. IE- does or doesn't it enable a balloon device. This is similar to allow_console_reconnect or anything else we need to know if it's enabled or not. I checked if UI and REST can enumerate existing devices, but it gets to a logic that we better have in the backend and not in the client. > > can you explain means the change in VmOldInfoBuilder? Yep. This a part of the stable device addresses framework. Since this is working on the new api with vdsm for 3.1 cluster, we need an empty implementation of it, the same we have for other devices which are for 3.1 only. Take a look at buildVmUsbDevices and buildUnmanagedDevices. > shouldn't we just ignore it to keep old behavior? or we want to support ballooning in all clusters? > (in Validations section it says only 3.1 is supported) > maybe validation is needed on changing vm cluster command, in case changing to 3.0 cluster and balloon enabled. We already have such cases now as a part of the stable device address API, working in <3.1 cluster uses the old API, which builds the devices in a different way, ignoring 3.0 unsupported devices. -- /d "Forty-two," said Deep Thought, with infinite majesty and calm. --Douglas Adams, The Hitchhiker's Guide to the Galaxy From smizrahi at redhat.com Wed May 30 18:44:01 2012 From: smizrahi at redhat.com (Saggi Mizrahi) Date: Wed, 30 May 2012 14:44:01 -0400 (EDT) Subject: [Engine-devel] Using 3.1.0 instead of 3.1.0-0001 for next release? In-Reply-To: <4FC64186.7000108@redhat.com> Message-ID: <3a354ec9-32e7-4c3a-a67d-a5b5c153c9a7@zmail16.collab.prod.int.phx2.redhat.com> I gave you a +1 as the patch is solid and I agree with the change. Mu question is why have all the versions in all the files instead of using a variable in the configuration and having *.in files? Will make all future changes much easier. ----- Original Message ----- > From: "Juan Hernandez" > To: engine-devel at ovirt.org > Sent: Wednesday, May 30, 2012 11:49:26 AM > Subject: [Engine-devel] Using 3.1.0 instead of 3.1.0-0001 for next release? > > Hello, > > I think we have the opportunity now to clean the version number and > use > 3.1.0 instead of 3.1.0-0001 for the next release. I submitted the > corresponding change to gerrit for review: > > http://gerrit.ovirt.org/4914 > > As far as I can tell there are no issues introduced by this change > and > it allows a cleaner versioning schema for the RPM packages. > > Please let me now if you foresee any issue. > > Regards, > Juan Hernandez > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From juan.hernandez at redhat.com Wed May 30 19:37:06 2012 From: juan.hernandez at redhat.com (Juan Hernandez) Date: Wed, 30 May 2012 21:37:06 +0200 Subject: [Engine-devel] Using 3.1.0 instead of 3.1.0-0001 for next release? In-Reply-To: <3a354ec9-32e7-4c3a-a67d-a5b5c153c9a7@zmail16.collab.prod.int.phx2.redhat.com> References: <3a354ec9-32e7-4c3a-a67d-a5b5c153c9a7@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: <4FC676E2.5070900@redhat.com> On 05/30/2012 08:44 PM, Saggi Mizrahi wrote: > I gave you a +1 as the patch is solid and I agree with the change. > Mu question is why have all the versions in all the files instead of using a variable in the configuration and having *.in files? > Will make all future changes much easier. Using .in files it not a common practice in the java/maven world, and it would complicate working with the pom.xml files, as most developers and tools (eclipse, for example) assume that they can be modified directly. Having a property in the root POM isn't possible either, at it will be a chicken-egg problem and the resulting POM files stored in the maven repositories will be incorrect. Unfortunately the only alternative is modifying each POM file with each release number change. We don't do releases so frequently, so this is not a big issue. > ----- Original Message ----- >> From: "Juan Hernandez" >> To: engine-devel at ovirt.org >> Sent: Wednesday, May 30, 2012 11:49:26 AM >> Subject: [Engine-devel] Using 3.1.0 instead of 3.1.0-0001 for next release? >> >> Hello, >> >> I think we have the opportunity now to clean the version number and >> use >> 3.1.0 instead of 3.1.0-0001 for the next release. I submitted the >> corresponding change to gerrit for review: >> >> http://gerrit.ovirt.org/4914 >> >> As far as I can tell there are no issues introduced by this change >> and >> it allows a cleaner versioning schema for the RPM packages. >> >> Please let me now if you foresee any issue. >> >> Regards, >> Juan Hernandez >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> From apahim at redhat.com Wed May 30 19:39:42 2012 From: apahim at redhat.com (Amador Pahim) Date: Wed, 30 May 2012 16:39:42 -0300 Subject: [Engine-devel] Shared Memory Message-ID: <4FC6777E.8020502@redhat.com> Hello, Not sure if it was already discussed, but I'd like to talk about oVirt "Shared Memory". Webadmin has the Shared Memory percent information in host general tab [1]. Initially, I thought that Shared Memory was the KSM de-duplication results. But comparing with my KSM stats, it does not make sense. My env: 3,5 GB virt-host. 6 identical VMs running with 1GB RAM each. Webadmin host details: Memory Sharing: Active Shared Memory: 0% KSM - How many shared pages are being used: $ cat /sys/kernel/mm/ksm/pages_sharing 109056 KSM - How many more sites are sharing them i.e. how much saved $ cat /sys/kernel/mm/ksm/pages_sharing 560128 Converting to Mbytes: $ echo $(( (109056 * $(getconf PAGE_SIZE)) / (1024 * 1024) )) 426 $ echo $(( ( 560128 * $(getconf PAGE_SIZE)) / (1024 * 1024) )) 2188 With those KSM results, I could expect something but 0 in "Shared Memory". Tracing the origin of "Shared Memory" in oVirt code, I realized it's coming from memShared value (from getVdsStats vdsm command), which is provided in Mbytes: $ vdsClient -s 192.168.10.250 getVdsStats | grep memShared memShared = 9 Finding memShared function in vdsm, we have: $VDSM_ROOT/vdsm/API.py ... stats['memShared'] = self._memShared() / Mbytes ... def _memShared(self): """ Return an approximation of memory shared by VMs thanks to KSM. """ shared = 0 for v in self._cif.vmContainer.values(): if v.conf['pid'] == '0': continue try: statmfile = file('/proc/' + v.conf['pid'] + '/statm') shared += int(statmfile.read().split()[2]) * PAGE_SIZE_BYTES except: pass return shared ... memShared is calculated adding the shared pages value (3rd field) from /proc//statm file from all running VMs, converting to bytes through PAGE_SIZE value and transforming to Mbytes at the end. This field in statm file currently is (it changed along kernel history) the count of pages instantiated in the process address space which are shared with a file, including executable, library or shared memory. Despite vdsm code comment, KSM shared pages are not accounted here. KSM works de-duplicating and sharing memory pages without process awareness. Engine is calculating the percent considering total physical memory - memSize value from getVdsCapabilities vdsm command: $ vdsClient -s 192.168.10.250 getVdsCapabilities | grep memSize memSize = 3574 Calculating the percent: $ echo "scale=2; 9 * 100 / 3574" | bc .25 So, we have arround 0,25%, rounded to 0%. "Shared Memory" is coherent, but not reflecting the real page deduplication benefits. And unnoticed administrators - me included - are led to think that Shared Memory is related with KSM results. IMO, memShared is not providing any representative information. On the other hand, the missing KSM results are really important to oVirt administrators, providing information about how much memory they are over committed by, for capacity management, and how much money oVirt is saving in memory. In order to offer those KSM stats to engine, I sent a patch [2] (waiting approval) adding "ksmShared" and "ksmSharing" values to vdsm getVdsStats command in a standard way, with key names that fits with existing KSM ones (ksmCpu, ksmPages and ksmState). Before patch: $ vdsClient -s 192.168.10.250 getVdsStats | grep ksm ksmCpu = 1 -> the ksmd process cpu load ksmPages = 664 -> pages to scan before ksmd goes to sleep ksmState = True -> is ksm running? With the patch: $ vdsClient -s 192.168.10.250 getVdsStats | grep ksm ksmCpu = 1 ksmPages = 664 ksmShared = 426 -> how many Mbytes of memory are being shared ksmSharing = 2188 -> how many more sites are sharing them i.e. how much Mbytes are being saved ksmState = True Finally my questions: 1 - Is sharedMem value (from /proc/PID/statm) that significant to be kept in host details? If yes, why? 2 - What about - and how (%, Mb, ...) - to add the vdsm new ksmShared and ksmSharing stats in host details? Sorry about my long history. I look forward to hearing your comments. All the best, -- Pahim [1] - http://www.pahim.org/wp-content/uploads/2012/05/Screenshot-oVirt-Enterprise-Virtualization-Engine-Web-Administration-Mozilla-Firefox-4.png [2] - http://gerrit.ovirt.org/4755 From smizrahi at redhat.com Wed May 30 20:34:37 2012 From: smizrahi at redhat.com (Saggi Mizrahi) Date: Wed, 30 May 2012 16:34:37 -0400 (EDT) Subject: [Engine-devel] Using 3.1.0 instead of 3.1.0-0001 for next release? In-Reply-To: <4FC676E2.5070900@redhat.com> Message-ID: <40c98076-ff6e-4c8e-8b75-cef5f44b68d7@zmail16.collab.prod.int.phx2.redhat.com> Comments inline. ----- Original Message ----- > From: "Juan Hernandez" > To: "Saggi Mizrahi" > Cc: engine-devel at ovirt.org > Sent: Wednesday, May 30, 2012 3:37:06 PM > Subject: Re: [Engine-devel] Using 3.1.0 instead of 3.1.0-0001 for next release? > > On 05/30/2012 08:44 PM, Saggi Mizrahi wrote: > > I gave you a +1 as the patch is solid and I agree with the change. > > Mu question is why have all the versions in all the files instead > > of using a variable in the configuration and having *.in files? > > Will make all future changes much easier. > > Using .in files it not a common practice in the java/maven world, and > it > would complicate working with the pom.xml files, as most developers > and > tools (eclipse, for example) assume that they can be modified > directly. This is why I hate IDEs, they think they can just touch everything. My understanding of maven is amateurish at best but I think you can put ${env.ENGINE_VERSION} variables in POM files and have the make file declare it. You could also have the ${setting.EngineVersion} and declare in settings.xml. I personally prefer the environment solution because it allows you to declare the version on the fly to properly mark test RPMs, but maybe Eclipse would prefer the settings.xml solution (which could be a ".in" file ;-) ). > > Having a property in the root POM isn't possible either, at it will > be a > chicken-egg problem and the resulting POM files stored in the maven > repositories will be incorrect. > > Unfortunately the only alternative is modifying each POM file with > each > release number change. We don't do releases so frequently, so this is > not a big issue. > > > ----- Original Message ----- > >> From: "Juan Hernandez" > >> To: engine-devel at ovirt.org > >> Sent: Wednesday, May 30, 2012 11:49:26 AM > >> Subject: [Engine-devel] Using 3.1.0 instead of 3.1.0-0001 for next > >> release? > >> > >> Hello, > >> > >> I think we have the opportunity now to clean the version number > >> and > >> use > >> 3.1.0 instead of 3.1.0-0001 for the next release. I submitted the > >> corresponding change to gerrit for review: > >> > >> http://gerrit.ovirt.org/4914 > >> > >> As far as I can tell there are no issues introduced by this change > >> and > >> it allows a cleaner versioning schema for the RPM packages. > >> > >> Please let me now if you foresee any issue. > >> > >> Regards, > >> Juan Hernandez > >> _______________________________________________ > >> Engine-devel mailing list > >> Engine-devel at ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/engine-devel > >> > > From lpeer at redhat.com Thu May 31 06:04:12 2012 From: lpeer at redhat.com (Livnat Peer) Date: Thu, 31 May 2012 09:04:12 +0300 Subject: [Engine-devel] Adding atomic restore snapshot command at backend In-Reply-To: <4FC634E9.5040709@redhat.com> References: <4FC634E9.5040709@redhat.com> Message-ID: <4FC709DC.7060207@redhat.com> On 30/05/12 17:55, Michael Pasternak wrote: > On 05/30/2012 05:39 PM, Omer Frenkel wrote: >> >> >> ----- Original Message ----- >>> From: "Michael Pasternak" >>> To: "Livnat Peer" >>> Cc: "engine-devel" >>> Sent: Monday, May 28, 2012 2:37:10 PM >>> Subject: Re: [Engine-devel] Adding atomic restore snapshot command at backend >>> >>> >>> Hi Livnat, >>> >>> On 05/28/2012 02:07 PM, Livnat Peer wrote: >>>> On 28/05/12 12:59, Michael Pasternak wrote: >>>>> >>>>> Currently 'restore snapshot' done in two steps on a client side: >>>>> >>>>> 1. TryBackToAllSnapshotsOfVm >>>>> 2. RestoreAllSnapshots >>>>> >>>>> This implementation creates race condition on 1 and therefore >>>>> unstable & bug prone, >> >> IIRC, there is an easy way to fix this, >> by polling on engine jobs and not vdsm tasks, no? > > indeed, and we already doing that, but it still fails on race at > former command. > Can you give more details on that? The Job indicates it is finished but actually it is not? >> >>>>> i suggested refactoring 2 to include 1 as single atomic operation >>>>> at backend. >>>>> >>>>> >>>> >>>> Hi Michael, >>>> >>>> The two commands above are used for functionality that is needed >>>> regardless of the functionality you are looking for. >>>> We want to present the user the option to preview a snapshot >>>> without >>>> committing to it and without loosing the current snapshot. >>>> I think we need to model the the two options above in the REST, it >>>> is >>>> functionality that is used in the UI. >> >> +1 for that. >> >>> >>> this is out of scope of this RFE. >>> >>>> >>>> What you are looking for is a functionality 'restore to snapshot', >>>> this >>>> functionality does not exist in the engine in a single step, and I >>>> think >>>> that because we assumed that the user can get it in two steps It >>>> wasn't >>>> prioritize so far. >>> >>> the cons. of this approach is an async nature of the former command. >>> >>>> >>>> Implementing the missing functionality with the two functions above >>>> is >>>> a compromise that was done in the API. >>>> >>>> To summarize I think the requirement you present is a missing >>>> functionality in the engine and solving it is not about refactoring >>>> the >>>> two existing verbs into one. >>> >>> what i meant is not deprecating/refactoring old commands, but >>> introducing >>> new one that reusing them and expose as single (atomic) command >>> called >>> 'RestoreAllSnapshots', >>> >>> sorry if i wasn't clear. >> >> another suggestion is to have a way to send to the engine list of commands that will be performed. > > afaik both UI and API perform restore in a same manner, > > 1. TryBackToAllSnapshotsOfVm > 2. polling > 3. RestoreAllSnapshots > > so why not combining 1 & 3 in to single command, if from clients perspective > it is such ... > The UI is not polling and does not run the two operations above automatically. It is doing the TryBack and then the user can start the VM and decides if he wants to commit to this snapshot or return to the original one - which is the functionality the API is missing. >> >>> >>>> >>>> Thanks, Livnat >>>> >>> >>> >>> -- >>> >>> Michael Pasternak >>> RedHat, ENG-Virtualization R&D >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel at ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> > > From mpastern at redhat.com Thu May 31 06:19:47 2012 From: mpastern at redhat.com (Michael Pasternak) Date: Thu, 31 May 2012 09:19:47 +0300 Subject: [Engine-devel] Adding atomic restore snapshot command at backend In-Reply-To: <4FC709DC.7060207@redhat.com> References: <4FC634E9.5040709@redhat.com> <4FC709DC.7060207@redhat.com> Message-ID: <4FC70D83.8090101@redhat.com> On 05/31/2012 09:04 AM, Livnat Peer wrote: > On 30/05/12 17:55, Michael Pasternak wrote: >> On 05/30/2012 05:39 PM, Omer Frenkel wrote: >>> >>> >>> ----- Original Message ----- >>>> From: "Michael Pasternak" >>>> To: "Livnat Peer" >>>> Cc: "engine-devel" >>>> Sent: Monday, May 28, 2012 2:37:10 PM >>>> Subject: Re: [Engine-devel] Adding atomic restore snapshot command at backend >>>> >>>> >>>> Hi Livnat, >>>> >>>> On 05/28/2012 02:07 PM, Livnat Peer wrote: >>>>> On 28/05/12 12:59, Michael Pasternak wrote: >>>>>> >>>>>> Currently 'restore snapshot' done in two steps on a client side: >>>>>> >>>>>> 1. TryBackToAllSnapshotsOfVm >>>>>> 2. RestoreAllSnapshots >>>>>> >>>>>> This implementation creates race condition on 1 and therefore >>>>>> unstable & bug prone, >>> >>> IIRC, there is an easy way to fix this, >>> by polling on engine jobs and not vdsm tasks, no? >> >> indeed, and we already doing that, but it still fails on race at >> former command. >> > > Can you give more details on that? > The Job indicates it is finished but actually it is not? Ori? > > >>> >>>>>> i suggested refactoring 2 to include 1 as single atomic operation >>>>>> at backend. >>>>>> >>>>>> >>>>> >>>>> Hi Michael, >>>>> >>>>> The two commands above are used for functionality that is needed >>>>> regardless of the functionality you are looking for. >>>>> We want to present the user the option to preview a snapshot >>>>> without >>>>> committing to it and without loosing the current snapshot. >>>>> I think we need to model the the two options above in the REST, it >>>>> is >>>>> functionality that is used in the UI. >>> >>> +1 for that. >>> >>>> >>>> this is out of scope of this RFE. >>>> >>>>> >>>>> What you are looking for is a functionality 'restore to snapshot', >>>>> this >>>>> functionality does not exist in the engine in a single step, and I >>>>> think >>>>> that because we assumed that the user can get it in two steps It >>>>> wasn't >>>>> prioritize so far. >>>> >>>> the cons. of this approach is an async nature of the former command. >>>> >>>>> >>>>> Implementing the missing functionality with the two functions above >>>>> is >>>>> a compromise that was done in the API. >>>>> >>>>> To summarize I think the requirement you present is a missing >>>>> functionality in the engine and solving it is not about refactoring >>>>> the >>>>> two existing verbs into one. >>>> >>>> what i meant is not deprecating/refactoring old commands, but >>>> introducing >>>> new one that reusing them and expose as single (atomic) command >>>> called >>>> 'RestoreAllSnapshots', >>>> >>>> sorry if i wasn't clear. >>> >>> another suggestion is to have a way to send to the engine list of commands that will be performed. >> >> afaik both UI and API perform restore in a same manner, >> >> 1. TryBackToAllSnapshotsOfVm >> 2. polling >> 3. RestoreAllSnapshots >> >> so why not combining 1 & 3 in to single command, if from clients perspective >> it is such ... >> > > The UI is not polling and does not run the two operations above > automatically. > It is doing the TryBack and then the user can start the VM and decides > if he wants to commit to this snapshot or return to the original one - > which is the functionality the API is missing. > > >>> >>>> >>>>> >>>>> Thanks, Livnat >>>>> >>>> >>>> >>>> -- >>>> >>>> Michael Pasternak >>>> RedHat, ENG-Virtualization R&D >>>> _______________________________________________ >>>> Engine-devel mailing list >>>> Engine-devel at ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>> >> >> > -- Michael Pasternak RedHat, ENG-Virtualization R&D From oliel at redhat.com Thu May 31 08:57:32 2012 From: oliel at redhat.com (Ori Liel) Date: Thu, 31 May 2012 04:57:32 -0400 (EDT) Subject: [Engine-devel] Adding atomic restore snapshot command at backend In-Reply-To: <4FC70D83.8090101@redhat.com> Message-ID: <41b787ae-c36d-4e9b-b5ba-c315e5bbef81@zmail17.collab.prod.int.phx2.redhat.com> >On 05/31/2012 09:04 AM, Livnat Peer wrote: >> On 30/05/12 17:55, Michael Pasternak wrote: >>> On 05/30/2012 05:39 PM, Omer Frenkel wrote: >>>> >>>> >>>> ----- Original Message ----- >>>>> From: "Michael Pasternak" >>>>> To: "Livnat Peer" >>>>> Cc: "engine-devel" >>>>> Sent: Monday, May 28, 2012 2:37:10 PM >>>>> Subject: Re: [Engine-devel] Adding atomic restore snapshot command at backend >>>>> >>>>> >>>>> Hi Livnat, >>>>> >>>>> On 05/28/2012 02:07 PM, Livnat Peer wrote: >>>>>> On 28/05/12 12:59, Michael Pasternak wrote: >>>>>>> >>>>>>> Currently 'restore snapshot' done in two steps on a client side: >>>>>>> >>>>>>> 1. TryBackToAllSnapshotsOfVm >>>>>>> 2. RestoreAllSnapshots >>>>>>> >>>>>>> This implementation creates race condition on 1 and therefore >>>>>>> unstable & bug prone, >>>> >>>> IIRC, there is an easy way to fix this, >>>> by polling on engine jobs and not vdsm tasks, no? >>> >>> indeed, and we already doing that, but it still fails on race at >>> former command. >>> >> >> Can you give more details on that? >> The Job indicates it is finished but actually it is not? > >Ori? Moti and I fixed this and it's in pre-integration, it might work. Regardless, the Backend imposes unnecessarily complex API for a simple operation that a client might want to do: 'Go back to Snapshot xxx for VM yyy' Any client who wants to support this must activate two actions, blocking between the first and the second. Why replicate this complexity in all potential clients? Why does a client care that Backend chooses to implement this command as two steps? That is an implmentation detail. It really doesn't matter that the first client we had was the GUI, and that in GUI previewing the VM and then approving is convenient. > >> >> >>>> >>>>>>> i suggested refactoring 2 to include 1 as single atomic operation >>>>>>> at backend. >>>>>>> >>>>>>> >>>>>> >>>>>> Hi Michael, >>>>>> >>>>>> The two commands above are used for functionality that is needed >>>>>> regardless of the functionality you are looking for. >>>>>> We want to present the user the option to preview a snapshot >>>>>> without >>>>>> committing to it and without loosing the current snapshot. >>>>>> I think we need to model the the two options above in the REST, it >>>>>> is >>>>>> functionality that is used in the UI. >>>> >>>> +1 for that. >>>> >>>>> >>>>> this is out of scope of this RFE. >>>>> >>>>>> >>>>>> What you are looking for is a functionality 'restore to snapshot', >>>>>> this >>>>>> functionality does not exist in the engine in a single step, and I >>>>>> think >>>>>> that because we assumed that the user can get it in two steps It >>>>>> wasn't >>>>>> prioritize so far. >>>>> >>>>> the cons. of this approach is an async nature of the former command. >>>>> >>>>>> >>>>>> Implementing the missing functionality with the two functions above >>>>>> is >>>>>> a compromise that was done in the API. >>>>>> >>>>>> To summarize I think the requirement you present is a missing >>>>>> functionality in the engine and solving it is not about refactoring >>>>>> the >>>>>> two existing verbs into one. >>>>> >>>>> what i meant is not deprecating/refactoring old commands, but >>>>> introducing >>>>> new one that reusing them and expose as single (atomic) command >>>>> called >>>>> 'RestoreAllSnapshots', >>>>> >>>>> sorry if i wasn't clear. >>>> >>>> another suggestion is to have a way to send to the engine list of commands that will be performed. >>> >>> afaik both UI and API perform restore in a same manner, >>> >>> 1. TryBackToAllSnapshotsOfVm >>> 2. polling >>> 3. RestoreAllSnapshots >>> >>> so why not combining 1 & 3 in to single command, if from clients perspective >>> it is such ... >>> >> >> The UI is not polling and does not run the two operations above >> automatically. >> It is doing the TryBack and then the user can start the VM and decides >> if he wants to commit to this snapshot or return to the original one - >> which is the functionality the API is missing. >> >> >>>> >>>>> >>>>>> >>>>>> Thanks, Livnat >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Michael Pasternak >>>>> RedHat, ENG-Virtualization R&D >>>>> _______________________________________________ >>>>> Engine-devel mailing list >>>>> Engine-devel at ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>> >>> >>> >> > > >-- > >Michael Pasternak >RedHat, ENG-Virtualization R&D From danken at redhat.com Thu May 31 09:15:05 2012 From: danken at redhat.com (Dan Kenigsberg) Date: Thu, 31 May 2012 12:15:05 +0300 Subject: [Engine-devel] Shared Memory In-Reply-To: <4FC6777E.8020502@redhat.com> References: <4FC6777E.8020502@redhat.com> Message-ID: <20120531091504.GI28159@redhat.com> On Wed, May 30, 2012 at 04:39:42PM -0300, Amador Pahim wrote: > Hello, > > Not sure if it was already discussed, but I'd like to talk about > oVirt "Shared Memory". > > Webadmin has the Shared Memory percent information in host general > tab [1]. Initially, I thought that Shared Memory was the KSM > de-duplication results. But comparing with my KSM stats, it does not > make sense. My env: > > 3,5 GB virt-host. > 6 identical VMs running with 1GB RAM each. > > Webadmin host details: > Memory Sharing: Active > Shared Memory: 0% > > KSM - How many shared pages are being used: > > $ cat /sys/kernel/mm/ksm/pages_sharing > 109056 > > KSM - How many more sites are sharing them i.e. how much saved > > $ cat /sys/kernel/mm/ksm/pages_sharing > 560128 > > Converting to Mbytes: > > $ echo $(( (109056 * $(getconf PAGE_SIZE)) / (1024 * 1024) )) > 426 > > $ echo $(( ( 560128 * $(getconf PAGE_SIZE)) / (1024 * 1024) )) > 2188 > > With those KSM results, I could expect something but 0 in "Shared Memory". > > Tracing the origin of "Shared Memory" in oVirt code, I realized it's > coming from memShared value (from getVdsStats vdsm command), which > is provided in Mbytes: > > $ vdsClient -s 192.168.10.250 getVdsStats | grep memShared > memShared = 9 > > Finding memShared function in vdsm, we have: > > $VDSM_ROOT/vdsm/API.py > > ... > > stats['memShared'] = self._memShared() / Mbytes > > ... > > def _memShared(self): > """ > Return an approximation of memory shared by VMs thanks to KSM. > """ > shared = 0 > for v in self._cif.vmContainer.values(): > if v.conf['pid'] == '0': > continue > try: > statmfile = file('/proc/' + v.conf['pid'] + '/statm') > shared += int(statmfile.read().split()[2]) * PAGE_SIZE_BYTES > except: > pass > return shared > > ... > > memShared is calculated adding the shared pages value (3rd field) > from /proc//statm file from all running VMs, converting to > bytes through PAGE_SIZE value and transforming to Mbytes at the end. > This field in statm file currently is (it changed along kernel > history) the count of pages instantiated in the process address > space which are shared with a file, including executable, library or > shared memory. Despite vdsm code comment, KSM shared pages are not > accounted here. KSM works de-duplicating and sharing memory pages > without process awareness. > > Engine is calculating the percent considering total physical memory > - memSize value from getVdsCapabilities vdsm command: > > $ vdsClient -s 192.168.10.250 getVdsCapabilities | grep memSize > memSize = 3574 > > Calculating the percent: > > $ echo "scale=2; 9 * 100 / 3574" | bc > .25 > > So, we have arround 0,25%, rounded to 0%. "Shared Memory" is > coherent, but not reflecting the real page deduplication benefits. > And unnoticed administrators - me included - are led to think that > Shared Memory is related with KSM results. > > IMO, memShared is not providing any representative information. On > the other hand, the missing KSM results are really important to > oVirt administrators, providing information about how much memory > they are over committed by, for capacity management, and how much > money oVirt is saving in memory. > > In order to offer those KSM stats to engine, I sent a patch [2] > (waiting approval) adding "ksmShared" and "ksmSharing" values to > vdsm getVdsStats command in a standard way, with key names that fits > with existing KSM ones (ksmCpu, ksmPages and ksmState). > > Before patch: > $ vdsClient -s 192.168.10.250 getVdsStats | grep ksm > ksmCpu = 1 -> the ksmd process cpu load > ksmPages = 664 -> pages to scan before ksmd goes to sleep > ksmState = True -> is ksm running? > > With the patch: > $ vdsClient -s 192.168.10.250 getVdsStats | grep ksm > ksmCpu = 1 > ksmPages = 664 > ksmShared = 426 -> how many Mbytes of memory are being shared > ksmSharing = 2188 -> how many more sites are sharing them > i.e. how much Mbytes are being saved > ksmState = True > > > Finally my questions: > > 1 - Is sharedMem value (from /proc/PID/statm) that significant to be > kept in host details? If yes, why? I belive memShared used to report the Right Thing (i.e., an estimate of memory saved by KSM) in the rhev-2.Y days. Oded, could you confirm? Has it changed when we moved to EL6, and nobody noticed? > 2 - What about - and how (%, Mb, ...) - to add the vdsm new > ksmShared and ksmSharing stats in host details? I'm not sure if ksmShared/ksmSharing have an "added value" to the the admin, but if it does, I see no problem in reporting it from vdsm. But then again, a meaningful memShared seems enough to me. > > Sorry about my long history. I look forward to hearing your comments. Actually the long history is useful to understand the issue, thanks for it. From juan.hernandez at redhat.com Thu May 31 11:15:43 2012 From: juan.hernandez at redhat.com (Juan Hernandez) Date: Thu, 31 May 2012 13:15:43 +0200 Subject: [Engine-devel] Build and run with Fedora 17 jboss-as packages Message-ID: <4FC752DF.2020109@redhat.com> Hello, The changes required to build and run the engine using the jboss-as packages in Fedora 17 have been recently merged: http://gerrit.ovirt.org/4416 This means that from now on in order to install the RPMs you will need a Fedora 17 machine. In addition this also changes how the application server is used. We have been running the engine as an application deployed to the default instance of the application server. Starting now the engine will run a private instance of the application server owned by the user ovirt ovirt and managed by systemd, so please remember that you don't longer need/should start the jboss-as service, but the ovirt-engine systemd service: systemctl start ovirt-engine.service systemctl stop ovirt-engine.service The locations of the files/directories used by this private instance of the application server are also different: 1. You are probably familiar with the standalone.xml file. This is no longer used, we use the /etc/ovirt-engine/engine-service.xml instead. 2. The location of the engine.ear file is still the same (/usr/share/ovirt-engine/engine.ear), but the deployment marker file engine.ear.dodeploy is not created in the same directory. Instead of that a symlink to the engine.ear file is created in /var/lib/ovirt-engine/deployments directory and the engine.ear.dodeploy file is created there by the start/stop script. 3. Locations of log files are also slightly different. The main log file is still /var/log/ovirt-engine/engine.log, but the server.log file is no longer in the jboss-as directory, but in /var/log/ovirt-engine as well. In addition there is a /var/log/ovirt-engine/console.log file that stores the standard and error output of the engine. There are other changes, but probably less relevant to most of you. I made many tests, but I am sure that issues will appear, so please keep an eye on this and let me know of any issues you may encounter. Regards, Juan Hernandez From apahim at redhat.com Thu May 31 12:40:26 2012 From: apahim at redhat.com (Amador Pahim) Date: Thu, 31 May 2012 09:40:26 -0300 Subject: [Engine-devel] Shared Memory In-Reply-To: <20120531091504.GI28159@redhat.com> References: <4FC6777E.8020502@redhat.com> <20120531091504.GI28159@redhat.com> Message-ID: <4FC766BA.9090605@redhat.com> On 05/31/2012 06:15 AM, Dan Kenigsberg wrote: > On Wed, May 30, 2012 at 04:39:42PM -0300, Amador Pahim wrote: >> Hello, >> >> Not sure if it was already discussed, but I'd like to talk about >> oVirt "Shared Memory". >> >> Webadmin has the Shared Memory percent information in host general >> tab [1]. Initially, I thought that Shared Memory was the KSM >> de-duplication results. But comparing with my KSM stats, it does not >> make sense. My env: >> >> 3,5 GB virt-host. >> 6 identical VMs running with 1GB RAM each. >> >> Webadmin host details: >> Memory Sharing: Active >> Shared Memory: 0% >> >> KSM - How many shared pages are being used: >> >> $ cat /sys/kernel/mm/ksm/pages_sharing >> 109056 >> >> KSM - How many more sites are sharing them i.e. how much saved >> >> $ cat /sys/kernel/mm/ksm/pages_sharing >> 560128 >> >> Converting to Mbytes: >> >> $ echo $(( (109056 * $(getconf PAGE_SIZE)) / (1024 * 1024) )) >> 426 >> >> $ echo $(( ( 560128 * $(getconf PAGE_SIZE)) / (1024 * 1024) )) >> 2188 >> >> With those KSM results, I could expect something but 0 in "Shared Memory". >> >> Tracing the origin of "Shared Memory" in oVirt code, I realized it's >> coming from memShared value (from getVdsStats vdsm command), which >> is provided in Mbytes: >> >> $ vdsClient -s 192.168.10.250 getVdsStats | grep memShared >> memShared = 9 >> >> Finding memShared function in vdsm, we have: >> >> $VDSM_ROOT/vdsm/API.py >> >> ... >> >> stats['memShared'] = self._memShared() / Mbytes >> >> ... >> >> def _memShared(self): >> """ >> Return an approximation of memory shared by VMs thanks to KSM. >> """ >> shared = 0 >> for v in self._cif.vmContainer.values(): >> if v.conf['pid'] == '0': >> continue >> try: >> statmfile = file('/proc/' + v.conf['pid'] + '/statm') >> shared += int(statmfile.read().split()[2]) * PAGE_SIZE_BYTES >> except: >> pass >> return shared >> >> ... >> >> memShared is calculated adding the shared pages value (3rd field) >> from /proc//statm file from all running VMs, converting to >> bytes through PAGE_SIZE value and transforming to Mbytes at the end. >> This field in statm file currently is (it changed along kernel >> history) the count of pages instantiated in the process address >> space which are shared with a file, including executable, library or >> shared memory. Despite vdsm code comment, KSM shared pages are not >> accounted here. KSM works de-duplicating and sharing memory pages >> without process awareness. >> >> Engine is calculating the percent considering total physical memory >> - memSize value from getVdsCapabilities vdsm command: >> >> $ vdsClient -s 192.168.10.250 getVdsCapabilities | grep memSize >> memSize = 3574 >> >> Calculating the percent: >> >> $ echo "scale=2; 9 * 100 / 3574" | bc >> .25 >> >> So, we have arround 0,25%, rounded to 0%. "Shared Memory" is >> coherent, but not reflecting the real page deduplication benefits. >> And unnoticed administrators - me included - are led to think that >> Shared Memory is related with KSM results. >> >> IMO, memShared is not providing any representative information. On >> the other hand, the missing KSM results are really important to >> oVirt administrators, providing information about how much memory >> they are over committed by, for capacity management, and how much >> money oVirt is saving in memory. >> >> In order to offer those KSM stats to engine, I sent a patch [2] >> (waiting approval) adding "ksmShared" and "ksmSharing" values to >> vdsm getVdsStats command in a standard way, with key names that fits >> with existing KSM ones (ksmCpu, ksmPages and ksmState). >> >> Before patch: >> $ vdsClient -s 192.168.10.250 getVdsStats | grep ksm >> ksmCpu = 1 -> the ksmd process cpu load >> ksmPages = 664 -> pages to scan before ksmd goes to sleep >> ksmState = True -> is ksm running? >> >> With the patch: >> $ vdsClient -s 192.168.10.250 getVdsStats | grep ksm >> ksmCpu = 1 >> ksmPages = 664 >> ksmShared = 426 -> how many Mbytes of memory are being shared >> ksmSharing = 2188 -> how many more sites are sharing them >> i.e. how much Mbytes are being saved >> ksmState = True >> >> >> Finally my questions: >> >> 1 - Is sharedMem value (from /proc/PID/statm) that significant to be >> kept in host details? If yes, why? > I belive memShared used to report the Right Thing (i.e., an estimate of > memory saved by KSM) in the rhev-2.Y days. Oded, could you confirm? > Has it changed when we moved to EL6, and nobody noticed? > >> 2 - What about - and how (%, Mb, ...) - to add the vdsm new >> ksmShared and ksmSharing stats in host details? > I'm not sure if ksmShared/ksmSharing have an "added value" to the the > admin, but if it does, I see no problem in reporting it from vdsm. > But then again, a meaningful memShared seems enough to me. > >> Sorry about my long history. I look forward to hearing your comments. > Actually the long history is useful to understand the issue, thanks for > it. Two more points here: - "The KSM module shipped in this release is a different version from the KSM module found on the latest upstream kernel versions. Newer features, such as exporting statistics on the /sys filesystem, that are implemented upstream are not in the version shipped in this release." [3] This should explain why /proc//statm was used to get KSM stats. - "[PATCH] statm: shared = rss - anon_rss" [4] This should explain what's changed in statm. So, I agree with you in just change memShared source. -- Pahim [3] - http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/5.4_Technical_Notes/Known_Issues-kvm.html [4] - http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.10 -------------- next part -------------- An HTML attachment was scrubbed... URL: From agl at us.ibm.com Thu May 31 14:01:52 2012 From: agl at us.ibm.com (Adam Litke) Date: Thu, 31 May 2012 09:01:52 -0500 Subject: [Engine-devel] [vdsm] RFC: Writeup on VDSM-libstoragemgmt integration In-Reply-To: <4FC5EAA6.3090605@linux.vnet.ibm.com> References: <4FC5EAA6.3090605@linux.vnet.ibm.com> Message-ID: <20120531140152.GH4096@localhost.localdomain> On Wed, May 30, 2012 at 03:08:46PM +0530, Deepak C Shetty wrote: > Hello All, > > I have a draft write-up on the VDSM-libstoragemgmt integration. > I wanted to run this thru' the mailing list(s) to help tune and > crystallize it, before putting it on the ovirt wiki. > I have run this once thru Ayal and Tony, so have some of their > comments incorporated. > > I still have few doubts/questions, which I have posted below with > lines ending with '?' > > Comments / Suggestions are welcome & appreciated. > > thanx, > deepak > > [Ccing engine-devel and libstoragemgmt lists as this stuff is > relevant to them too] > > -------------------------------------------------------------------------------------------------------------- > > 1) Background: > > VDSM provides high level API for node virtualization management. It > acts in response to the requests sent by oVirt Engine, which uses > VDSM to do all node virtualization related tasks, including but not > limited to storage management. > > libstoragemgmt aims to provide vendor agnostic API for managing > external storage array. It should help system administrators > utilizing open source solutions have a way to programmatically > manage their storage hardware in a vendor neutral way. It also aims > to facilitate management automation, ease of use and take advantage > of storage vendor supported features which improve storage > performance and space utilization. > > Home Page: http://sourceforge.net/apps/trac/libstoragemgmt/ > > libstoragemgmt (LSM) today supports C and python plugins for talking > to external storage array using SMI-S as well as native interfaces > (eg: netapp plugin ) > Plan is to grow the SMI-S interface as needed over time and add more > vendor specific plugins for exploiting features not possible via > SMI-S or have better alternatives than using SMI-S. > For eg: Many of the copy offload features require to use vendor > specific commands, which justifies the need for a vendor specific > plugin. > > > 2) Goals: > > 2a) Ability to plugin external storage array into oVirt/VDSM > virtualization stack, in a vendor neutral way. > > 2b) Ability to list features/capabilities and other statistical > info of the array > > 2c) Ability to utilize the storage array offload capabilities > from oVirt/VDSM. > > > 3) Details: > > LSM will sit as a new repository engine in VDSM. > VDSM Repository Engine WIP @ http://gerrit.ovirt.org/#change,192 > > Current plan is to have LSM co-exist with VDSM on the virtualization nodes. > > *Note : 'storage' used below is generic. It can be a file/nfs-export > for NAS targets and LUN/logical-drive for SAN targets. > > VDSM can use LSM and do the following... > - Provision storage > - Consume storage > > 3.1) Provisioning Storage using LSM > > Typically this will be done by a Storage administrator. > > oVirt/VDSM should provide storage admin the > - ability to list the different storage arrays along with their > types (NAS/SAN), capabilities, free/used space. > - ability to provision storage using any of the array > capabilities (eg: thin provisioned lun or new NFS export ) > - ability to manage the provisioned storage (eg: resize/delete storage) I guess vdsm will need to model a new type of object (perhaps StorageTarget) to be used for performing the above provisioning operations. Then, to consume the provisioned storage, we could create a StorageConnectionRef by passing in a StorageTarget object and some additional parameters. Sound about right? > Once the storage is provisioned by the storage admin, VDSM will have > to refresh the host(s) for them to be able to see the newly > provisioned storage. How would this refresh affect currently connected storage and running VMs? > 3.1.1) Potential flows: > > Mgmt -> vdsm -> lsm: create LUN + LUN Mapping / Zoning / whatever is > needed to make LUN available to list of hosts passed by mgmt > Mgmt -> vdsm: getDeviceList (refreshes host and gets list of devices) > Repeat above for all relevant hosts (depending on list passed > earlier, mostly relevant when extending an existing VG) > Mgmt -> use LUN in normal flows. > > > 3.1.2) How oVirt Engine will know which LSM to use ? > > Normally the way this works today is that user can choose the host > to use (default today is SPM), however there are a few flows where > mgmt will know which host to use: > 1. extend storage domain (add LUN to existing VG) - Use SPM and make > sure *all* hosts that need access to this SD can see the new LUN > 2. attach new LUN to a VM which is pinned to a specific host - use this host > 3. attach new LUN to a VM which is not pinned - use a host from the > cluster the VM belongs to and make sure all nodes in cluster can see > the new LUN You are still going to need to worry about locking the shared storage resource. Will libstoragemgmt have storage clustering support baked in or will we continue to rely on SPM? If the latter is true, most/all of these operations would still need to be done by SPM if I understand correctly. > Flows for which there is no clear candidate (Maybe we can use the > SPM host itself which is the default ?) > 1. create a new disk without attaching it to any VM > 2. create a LUN for a new storage domain Yes, SPM would seem correct to me. > 3.2) Consuming storage using LSM > > Typically this will be done by a virtualization administrator > > oVirt/VDSM should allow virtualization admin to > - Create a new storage domain using the storage on the array. > - Be able to specify whether VDSM should use the storage offload > capability (default) or override it to use its own internal logic. If vdsm can make the right decisions, I would prefer that vdsm decides when to use hardware offload and when to use software algorithms without administrator intervention. It's another case where oVirt can provide value-add by simplifying the configuration and providing optimal performance. > 4) VDSM potential changes: > > 4.1) How to represent a VM disk, 1 LUN = 1 VMdisk or 1 LV = 1 VMdisk > ? which bring another question...1 array == 1 storage domain OR 1 > LUN/nfs-export on the array == 1 storage domain ? Saggi has mentioned some ideas on this topic so I will encourage him to explain his thoughts here. > > Pros & Cons of each... > > 1 array == 1 storage domain > - Each new vmdisk (aka volume) will be a new lun/file on the array. > - Easier to exploit offload capabilities, as they are available > at the LUN/File granularity > - Will there be any issues where there will be too many > LUNs/Files ... any maxluns limit on linux hosts that we might hit ? > -- VDSM has been tested with 1K LUNs and it worked fine - ayal > - Storage array limitations on the number of LUNs can be a > downside here. > - Would it be ok to share the array for hosting another storage > domain if need be ? > -- Provided the existing domain is not utilising all of the > free space > -- We can create new LUNs and hand it over to anyone needed ? > -- Changes needed in VDSM to work with raw LUNs, today it only > has support for consuming LUNs via VG/LV. > > 1 LUN/nfs-export on the array == 1 storage domain > - How to represent a new vmdisk (aka vdsm volume) if its a LUN > provisioned using SAN target ? > -- Will it be VG/LV as is done today for block domains ? > -- If yes, then it will be difficult to exploit offload > capabilities, as they are at LUN level, not at LV level. > - Each new vmdisk will be a new file on the nfs-export, assuming > offload capability is available at the file level, so this should > work for NAS targets ? > - Can use the storage array for hosting multiple storage domains. > -- Provision one more LUN and use it for another storage > domain if need be. > - VDSM already supports this today, as part of block storage > domains for LUNs case. > > Note that we will allow user to do either one of the two options > above, depending on need. > > 4.2) Storage domain metadata will also include the > features/capabilities of the storage array as reported by LSM. > - Capabilities (taken via LSM) will be stored in the domain > metadata during storage domain create flow. > - Need changes in oVirt engine as well ( see 'oVirt Engine > potential changes' section below ) Do we want to store the exact hw capabilities or some set of vdsm chosen feature bits that are set at create time based on the discovered hw capabilities? The difference would be that vdsm could choose which features to enable at create time and update those features later if needed. > 4.3) VDSM to poll LSM for array capabilities on a regular basis ? > Per ayal: > - If we have a 'storage array' entity in oVirt Engine (see > 'oVirt Engine potential changes' section below ) then we can have a > 'refresh capabilities' button/verb. > - We can periodically query the storage array. > - Query LSM before running operations (sounds redundant to me, > but if it's cheap enough it could be simplest). > > Probably need a combination of 1+2 (query at very low frequency > - 1/hour or 1/day + refresh button) This problem can be aleviated by the abstraction I suggested above. Then, LSM can be queried only when we may want to adjust the policy connected with a particular storage target. > 5) oVirt Engine potential changes - as described by ayal : > > - We will either need a new 'storage array' entity in engine to > keep credentials, or, in case of storage array as storage domain, > just keep this info as part of the domain at engine level. > - Have a 'storage array' entity in oVirt Engine to support > 'refresh capabilities' as a button/verb. > - When user during storage provisioning, selects a LUN exported > from a storage array (via LSM), the oVirt Engine would know from > then onwards that this LUN is being served via LSM. > It would then be able to query the capabilities of the LUN > and show it to the virt admin during storage consumption flow. > > 6) Potential flows: > - Create snapshot flow > -- VDSM will check the snapshot offload capability in the > domain metadata > -- If available, and override is not configured, it will use > LSM to offload LUN/File snapshot > -- If override is configured or capability is not available, > it will use its internal logic to create > snapshot (qcow2). > > - Copy/Clone vmdisk flow > -- VDSM will check the copy offload capability in the domain > metadata > -- If available, and override is not configured, it will use > LSM to offload LUN/File copy > -- If override is configured or capability is not available, > it will use its internal logic to create > snapshot (eg: dd cmd in case of LUN). > > 7) LSM potential changes: > > - list features/capabilities of the array. Eg: copy offload, > thin prov. etc. > - list containers (aka pools) (present in LSM today) > - Ability to list different types of arrays being managed, their > capabilities and used/free space > - Ability to create/list/delete/resize volumes ( LUN or exports, > available in LSM as of today) > - Get monitoring info with object (LUN/snapshot/volume) as > optional parameter for specific info. eg: container/pool free/used > space, raid type etc. > > Need to make sure above info is listed in a coherent way across > arrays (number of LUNs, raid type used? free/total per > container/pool, per LUN?. Also need I/O statistics wherever > possible. > > > _______________________________________________ > vdsm-devel mailing list > vdsm-devel at lists.fedorahosted.org > https://fedorahosted.org/mailman/listinfo/vdsm-devel -- Adam Litke IBM Linux Technology Center From jhernand at redhat.com Thu May 31 14:23:21 2012 From: jhernand at redhat.com (Juan Hernandez) Date: Thu, 31 May 2012 16:23:21 +0200 Subject: [Engine-devel] Build and run with Fedora 17 jboss-as packages In-Reply-To: <4FC752DF.2020109@redhat.com> References: <4FC752DF.2020109@redhat.com> Message-ID: <4FC77ED9.8020205@redhat.com> First issue that you will find in your dev environment is that when you run "mvn install -Psetup" it will copy to your ${jbossHome}/modules directory some modules that will not work, as they are only needed with the jboss-as package in Fedora 17. In order to avoid that you need to apply this patch: http://gerrit.ovirt.org/4947 On 05/31/2012 01:15 PM, Juan Hernandez wrote: > Hello, > > The changes required to build and run the engine using the jboss-as > packages in Fedora 17 have been recently merged: > > http://gerrit.ovirt.org/4416 > > This means that from now on in order to install the RPMs you will need a > Fedora 17 machine. > > In addition this also changes how the application server is used. We > have been running the engine as an application deployed to the default > instance of the application server. Starting now the engine will run a > private instance of the application server owned by the user ovirt ovirt > and managed by systemd, so please remember that you don't longer > need/should start the jboss-as service, but the ovirt-engine systemd > service: > > systemctl start ovirt-engine.service > systemctl stop ovirt-engine.service > > The locations of the files/directories used by this private instance of > the application server are also different: > > 1. You are probably familiar with the standalone.xml file. This is no > longer used, we use the /etc/ovirt-engine/engine-service.xml instead. > > 2. The location of the engine.ear file is still the same > (/usr/share/ovirt-engine/engine.ear), but the deployment marker file > engine.ear.dodeploy is not created in the same directory. Instead of > that a symlink to the engine.ear file is created in > /var/lib/ovirt-engine/deployments directory and the engine.ear.dodeploy > file is created there by the start/stop script. > > 3. Locations of log files are also slightly different. The main log file > is still /var/log/ovirt-engine/engine.log, but the server.log file is no > longer in the jboss-as directory, but in /var/log/ovirt-engine as well. > In addition there is a /var/log/ovirt-engine/console.log file that > stores the standard and error output of the engine. > > There are other changes, but probably less relevant to most of you. > > I made many tests, but I am sure that issues will appear, so please keep > an eye on this and let me know of any issues you may encounter. > > Regards, > Juan Hernandez -- Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3?D, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat S.L.