from:"Gilad Chaplik"

Re: [ovirt-devel] [ENGINE][SLA] from time to time I'm getting the folowwing exception when running on master

2015-01-14 Thread Gilad Chaplik

- Original Message -
 From: Yair Zaslavsky yzasl...@redhat.com
 To: Doron Fediuck dfedi...@redhat.com
 Cc: Doron Fediuck do...@redhat.com, Gilad Chaplik 
 gchap...@redhat.com, devel@ovirt.org
 Sent: Wednesday, January 14, 2015 9:28:29 AM
 Subject: Re: [ENGINE][SLA] from time to time I'm getting the folowwing 
 exception when running on master
 
 
 
 - Original Message -
  From: Doron Fediuck dfedi...@redhat.com
  To: Yair Zaslavsky yzasl...@redhat.com
  Cc: Doron Fediuck do...@redhat.com, Gilad Chaplik
  gchap...@redhat.com, devel@ovirt.org
  Sent: Wednesday, January 14, 2015 9:22:55 AM
  Subject: Re: [ENGINE][SLA] from time to time I'm getting the folowwing
  exception when running on master
  
  IS this on master or 3.5 branch?
 
 master

probably you missed running 03_06_0640_add_migration_policy_unit.sql,
because you're working on devel env. 

try to run it manually.

 
  
  On 01/14/2015 03:30 AM, Yair Zaslavsky wrote:
   2015-01-14 03:30:27,407 INFO
   [org.ovirt.engine.core.bll.scheduling.SchedulingManager] (MSC service
   thread 1-6) [] Initializing Scheduling manager
   2015-01-14 03:30:27,438 ERROR
   [org.ovirt.engine.core.bll.InitBackendServicesOnStartupBean] (MSC service
   thread 1-6) [] Failed to initialize backend:
   org.apache.commons.lang.NotImplementedException: policyUnit: Migration
   at
   
   org.ovirt.engine.core.bll.scheduling.PolicyUnitImpl.getPolicyUnitImpl(PolicyUnitImpl.java:116)
   [bll.jar:]
   at
   
   org.ovirt.engine.core.bll.scheduling.SchedulingManager.loadPolicyUnits(SchedulingManager.java:178)
   [bll.jar:]
   at
   
   org.ovirt.engine.core.bll.scheduling.SchedulingManager.init(SchedulingManager.java:101)
   [bll.jar:]
   at
   
   org.ovirt.engine.core.bll.InitBackendServicesOnStartupBean.create(InitBackendServicesOnStartupBean.java:104)
   [bll.jar:]
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   [rt.jar:1.7.0_45]
   at
   
   sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   [rt.jar:1.7.0_45]
   at
   
   sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   [rt.jar:1.7.0_45]
   at java.lang.reflect.Method.invoke(Method.java:606)
   [rt.jar:1.7.0_45]
   at
   
   org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptorFactory$ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptorFactory.java:130)
   [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
   at
   
   org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
   [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
   at
   
   org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
   [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
   at
   
   org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
   [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
   at
   
   org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:73)
   [jboss-as-weld-7.1.1.Final.jar:7.1.1.Final]
   at
   
   org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
   [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
   at
   
   org.jboss.as.ee.component.ManagedReferenceInterceptorFactory$ManagedReferenceInterceptor.processInvocation(ManagedReferenceInterceptorFactory.java:95)
   [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
   at
   
   org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
   [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
   at
   
   org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
   [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
   at
   
   org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
   [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
   at
   
   org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
   [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
   at
   
   org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
   [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
   at
   
   org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:228)
   [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
   at
   
   org.jboss.as.ejb3.tx.CMTTxInterceptor.requiresNew(CMTTxInterceptor.java:333)
   [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final

Re: [ovirt-devel] [ovirt-users] oVirt 3.5 test day 2 results - NUMA

2014-07-30 Thread Gilad Chaplik

- Original Message -
 From: Martin Perina mper...@redhat.com
 To: devel@ovirt.org, us...@ovirt.org List us...@ovirt.org
 Sent: Wednesday, July 30, 2014 1:26:49 PM
 Subject: [ovirt-users] oVirt 3.5 test day 2 results - NUMA
 
 Hi,
 
 I tried to test NUMA feature. Unfortunately the feature has no UI yet,
 so I tested just db content and REST API calls:
 
 
 1) Two NUMA hosts added to 3.5 cluster with shared NFS storage using webadmin
 
 2) Database:
  a) Both hosts have is_numa_supported=true, auto_numa_balancing=1 in
  vds_dynamic table
  b) Both hosts have 2 records in numa_nodes tables (consistent with
  numactl info)
  c) Both hosts have 24 records in numa_node_cpu_map, 12 per numa node
  (consistent with numactl info)
 
 3) REST API:
 a) URL /ovirt-engine/api/hosts/{HOST_ID} contains numa related data:
  auto_numa_statusenable/auto_numa_status
  numa_supportedtrue/numa_supported
 
 b) URL /ovirt-engine/api/hosts/{HOST_ID}/numanodes works (consistent with
 numactl info)
 
 c) URL /ovirt-engine/api/hosts/{HOST_ID}/numanodes/{NODE_ID}/statistics
 works
 
 4) Installed two VMs (one RHEL 6, one RHEL 7), both requires 16GB of RAM,
 with balloon enabled
and 8GB guarantied.
 
 5) Database:
 a) Both vms have numatune_mode=preferred in vm_static
 
 6) REST API for VM related data:
a) URL /ovirt-engine/api/vms/{VM_ID} contains numa related data:
 numa_tune_modepreferred/numa_tune_mode
 
b) URL /ovirt-engine/api/vms/{VM_ID}/numanodes works, but returns only:
 vm_numa_nodes/

thanks for the elaborate report, few question: 

What was reported in the element?
Did you pin the nodes? 

 
 6) VMs migration between hosts worked fine

VM migration with/out numa pinning?

 
 
 
 Martin Perina
 ___
 Users mailing list
 us...@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/users
 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Test day 1 results

2014-07-02 Thread Gilad Chaplik

- Original Message -
 From: Martin Betak mbe...@redhat.com
 To: devel@ovirt.org
 Sent: Wednesday, July 2, 2014 3:20:00 PM
 Subject: [ovirt-devel] Test day 1 results

 Hi all,

 During the first test day I tested BZ 1108602 Implement REST API for oVirt
 scheduler.
 Most basic CRUD operations via rest worked well, but there was a problem with
 accessing
 the subcollections 'filters', 'weights' and 'balances' of the
 /api/schedulingpolicies
 resource by id.

 For this a bug was filed under
 https://bugzilla.redhat.com/show_bug.cgi?id=1115071

great work Martin! and thanks!

http://gerrit.ovirt.org/#/c/29513/
http://gerrit.ovirt.org/#/c/29514/

gilad :-)

 Martin
 ___
 Devel mailing list
 Devel@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/devel

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] fixing whitespace in ui.xml files

2014-05-29 Thread Gilad Chaplik

- Original Message -
 From: Lior Vernia lver...@redhat.com
 To: Greg Sheremeta gsher...@redhat.com
 Cc: devel@ovirt.org, Alexander Wels aw...@redhat.com, Vojtech Szocs 
 vsz...@redhat.com, Einav Cohen
 eco...@redhat.com, Alona Kaplan alkap...@redhat.com, Gilad Chaplik 
 gchap...@redhat.com, Tomas Jelinek
 tjeli...@redhat.com
 Sent: Thursday, May 29, 2014 2:56:29 PM
 Subject: Re: fixing whitespace in ui.xml files

 Sounds good to me, I think the only reason they're not formatted is that
 the Java formatter by default ignores them.

 On 29/05/14 14:51, Greg Sheremeta wrote:
  Hi,

  Can we agree to use the same .java file space standards in our gwt ui.xml
  files? Specifically: spaces only, no tabs, 4 spaces indent, no trailing
  whitespace.

[adding Juan]
I agree on same formatting as api.xsd.

  I have my Eclipse set to fix these things (with the anyedit plugin), and
  the ui.xml files always have tabs and trailing space in them.

  If we agree, I volunteer to fix them all and post a patch. I think we can
  also set gerrit to point these out.

  Thanks,
  Greg

  Greg Sheremeta
  Red Hat, Inc.
  Sr. Software Engineer, RHEV
  Cell: 919-807-1086
  gsher...@redhat.com

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Discussion VM CPU pinning and NUMA CPU pinning

2014-05-28 Thread Gilad Chaplik

Great! sorry, I wasn't aware of it.
fyi, this patch depends on oVirt scheduling patch for NUMA (it's a must since 
we now expose an API to the user).
I will upload it today, try to get them reviewed, and merge both. 

Thanks, 
Gilad.


- Original Message -
 From: Chuan Liao (Jason Liao, HPservers-Core-OE-PSC) chuan.l...@hp.com
 To: Gilad Chaplik gchap...@redhat.com
 Cc: Sven Kieske s.kie...@mittwald.de, devel@ovirt.org
 Sent: Wednesday, May 28, 2014 5:14:39 AM
 Subject: RE: [ovirt-devel] Discussion VM CPU pinning and NUMA CPU pinning
 
 The patch is already upload yesterday, and verified with latest rebase.
 http://gerrit.ovirt.org/#/c/26943/
 
 Best Regards,
 Jason Liao
 
  -Original Message-
  From: Gilad Chaplik [mailto:gchap...@redhat.com]
  Sent: 2014年5月27日 21:52
  To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC)
  Cc: Sven Kieske; devel@ovirt.org
  Subject: Re: [ovirt-devel] Discussion VM CPU pinning and NUMA CPU pinning
  
  Hi Jason,
  
  I guess that the time you've waited for feedback is sufficient.
  
  please upload a patch as described (I hope I will get it merged tomorrow).
  
  Thanks,
  Gilad.
  
  - Original Message -
   From: Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)
   chuan.l...@hp.com
   To: Sven Kieske s.kie...@mittwald.de, devel@ovirt.org
   Sent: Tuesday, May 27, 2014 5:08:55 AM
   Subject: Re: [ovirt-devel] Discussion VM CPU pinning and NUMA CPU
   pinning
  
   Yes, you are right.
  
   And this design is almost like the libvirt capabilities format
  
   cpu id='0' socket_id='0' core_id='0' siblings='0'/ with attribute
   socket.
  
   Best Regards,
   Jason Liao
  
-Original Message-
From: devel-boun...@ovirt.org [mailto:devel-boun...@ovirt.org] On
Behalf Of Sven Kieske
Sent: 2014年5月26日 23:51
To: devel@ovirt.org
Subject: Re: [ovirt-devel] Discussion VM CPU pinning and NUMA CPU
pinning
   
well I'm no expert in reading xml like model declarations so please
correct me where I'm wrong:
   
any cpu contains at least 1 core, bound to 1 socket (1 cpu == 1
socket) a core does not contain any element socket.
   
Am 26.05.2014 05:11, schrieb Liao, Chuan (Jason Liao,
HPservers-Core-OE-PSC):
   xs:complexType name=CPU
 xs:sequence
   ...
   xs:element name=cores type=Cores minOccurs=0/
   ...
   /xs:complexType

   xs:complexType name=Cores
 xs:sequence
   xs:element ref=core maxOccurs=unbounded/
 /xs:sequence
   /xs:complexType

   xs:complexType name=Core
 xs:attribute name=index type=xs:int use=required/
 xs:attribute name=socket type=xs:int use=optional/
   /xs:complexType
   
--
Mit freundlichen Grüßen / Regards
   
Sven Kieske
   
Systemadministrator
Mittwald CM Service GmbH  Co. KG
Königsberger Straße 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
https://www.mittwald.de
Geschäftsführer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad
Oeynhausen
Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad
Oeynhausen ___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
   ___
   Devel mailing list
   Devel@ovirt.org
   http://lists.ovirt.org/mailman/listinfo/devel
 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [QE][ACTION NEEDED] oVirt 3.5.0 Second Alpha status

2014-05-28 Thread Gilad Chaplik

- Original Message -
 From: Sandro Bonazzola sbona...@redhat.com
 To: users us...@ovirt.org, devel@ovirt.org
 Sent: Wednesday, May 28, 2014 10:13:06 AM
 Subject: [ovirt-devel] [QE][ACTION NEEDED] oVirt 3.5.0 Second Alpha status

 Hi,
 We're preparing for feature freeze scheduled for 2014-05-30.
 We're going to compose a Second Alpha on Firday *2014-05-30 08:00 UTC*.
 Maintainers:
 - Please be sure that master snapshot allow to create VMs before *2014-05-29
 15:00 UTC*

Hi Sandro,

oVirt RESTful API project's main maintainer is not available, and will be back 
(I think) on Monday (6/2).
I personally have 2 pending long going major issues that awaits for him (ack  
merge) for coming feature freeze.

I want my features to slip in 3.5 without breaking any rules, ideas?

Thanks, 
Gilad.

 The bug tracker [1] shows the following proposed blockers to be reviewed:

 Bug IDWhiteboard  Status  Summary
 1001100   integration NEW Add log gathering for a new 
 ovirt module (External
 scheduler)
 1073944   integration ASSIGNEDAdd log gathering for a new 
 ovirt module
 (External scheduler)
 1060198   integration NEW [RFE] add support for Fedora 20
 1100236   integration NEW all-in-one setup should 
 configure cluster
 compatibility as max common between vdsm and engine

 Feature freeze has been postponed to 2014-05-30 and the following features
 should be testable in 3.5.0 Alpha according to Features Status Table [2]

 Group oVirt BZTitle
 gluster   1096713 Monitoring (UI plugin) Dashboard 
 (Integrated with Nagios
 monitoring)
 infra 1090530 [RFE] Please add host count and guest count 
 columns to
 Clusters tab in webadmin
 infra 1078738 [RFE] make ovirt easy configurable to allow 
 redirection of
 all logs to syslog
 infra 1054778 [RFE] Allow to perform fence operations from a 
 host in
 another DC
 infra 1090803 [RFE] Change the Slot field to Service 
 Profile when
 cisco_ucs is selected as the fencing type
 infra 1090511 [RFE] Improve fencing robustness by retrying 
 failed attempts
 infra 1090800 [RFE] Add periodic power management health 
 check to
 detect/warn about link-down detection of power management LAN
 infra 1090794 [RFE] Search VMs based on MAC address from 
 web-admin portal
 infra 1090793 consider the event type while printing events 
 to engine.log
 infra 1090796 [RFE] Re-work engine ovirt-node host-deploy 
 sequence
 infra 1090798 [RFE] Admin GUI - Add host uptime information 
 to the
 General tab
 infra 1090808 [RFE] Ability to dismiss alerts and events from 
 web-admin
 portal
 infra 1058737 [RFE] Restart HA VMs ASAP
 infra-api 1090797 [RFE] RESTAPI: Add /tags sub-collection for 
 Template
 resource
 infra-dwh 1091686 prevent OutOfMemoryError after starting the dwh 
 service.
 infra-dwh 1091687 History DB should sync user's first and last 
 name for user
 usage tables
 network   1078836 Add a warning when adding display 
 network
 network   1079719 Display of NIC Slave/Bond fault on 
 Event Log
 network   1080984 Support bridging_opts functionality 
 within oVirt
 network   1080987 Support ethtool_opts functionality 
 within oVirt
 network   1078862 Providing Neutron Applience
 storage   Store OVF on any domains
 storage   1083312 Disk alias recycling in web-admin portal
 storage   1086181 [RFE] Snapshot overview in webadmin 
 portal
 ux1064543 oVirt new look and feel [PatternFly adoption] - 
 phase #1
 virt  1058832 Allow to clone a (down) VM without 
 snapshot/template
 virt  1031040 can't set different keymap for vnc via runonce 
 option
 virt  1043471 oVirt guest agent for SLES
 virt  1073453 Debian 7 support (incl. 1043474 oVirt guest 
 agent for Debian)
 virt  1072313 Edit Running Vm
 virt  1083049 add progress bar for vm migration
 virt  1083065 EL 7 guest compatibility
 virt  Allow guest serial number to be configurable
 virt  1047624 [RFE] support BIOS boot device menu
 virt  1083129 allows setting netbios name, locale, language 
 and keyboard
 settings for windows vm's
 virt  1038632 spice-html5 button to show debug console/output 
 window
 virt  1080002 [RFE] Enable user defined Windows Sysprep file

 Some more features may be included since they were near to be completed on
 last sync meeting.
 The table will be updated on next

Re: [ovirt-devel] Entity names in DB scripts

2014-05-27 Thread Gilad Chaplik

- Original Message -
 From: Omer Frenkel ofren...@redhat.com
 To: Oved Ourfalli ov...@redhat.com
 Cc: Gilad Chaplik gchap...@redhat.com, devel@ovirt.org
 Sent: Tuesday, May 27, 2014 2:01:02 PM
 Subject: Re: [ovirt-devel] Entity names in DB scripts
 
 
 
 - Original Message -
  From: Oved Ourfalli ov...@redhat.com
  To: Gilad Chaplik gchap...@redhat.com
  Cc: devel@ovirt.org
  Sent: Tuesday, May 27, 2014 1:51:44 PM
  Subject: Re: [ovirt-devel] Entity names in DB scripts
  
  
  
  - Original Message -
   From: Gilad Chaplik gchap...@redhat.com
   To: Moti Asayag masa...@redhat.com
   Cc: Oved Ourfalli ov...@redhat.com, devel@ovirt.org
   Sent: Tuesday, May 27, 2014 1:46:48 PM
   Subject: Re: [ovirt-devel] Entity names in DB scripts
   
   - Original Message -
From: Moti Asayag masa...@redhat.com
To: Oved Ourfalli ov...@redhat.com
Cc: Gilad Chaplik gchap...@redhat.com, devel@ovirt.org
Sent: Tuesday, May 27, 2014 1:44:07 PM
Subject: Re: [ovirt-devel] Entity names in DB scripts



- Original Message -
 From: Oved Ourfalli ov...@redhat.com
 To: Gilad Chaplik gchap...@redhat.com
 Cc: Moti Asayag masa...@redhat.com, devel@ovirt.org
 Sent: Tuesday, May 27, 2014 1:30:43 PM
 Subject: Re: [ovirt-devel] Entity names in DB scripts
 
 
 
 - Original Message -
  From: Gilad Chaplik gchap...@redhat.com
  To: Moti Asayag masa...@redhat.com
  Cc: devel@ovirt.org
  Sent: Tuesday, May 27, 2014 1:27:10 PM
  Subject: Re: [ovirt-devel] Entity names in DB scripts
  
  - Original Message -
   From: Moti Asayag masa...@redhat.com
   To: Martin Perina mper...@redhat.com
   Cc: devel@ovirt.org
   Sent: Monday, May 26, 2014 12:39:17 PM
   Subject: Re: [ovirt-devel] Entity names in DB scripts
   
   
   
   - Original Message -
From: Martin Perina mper...@redhat.com
To: Eli Mesika emes...@redhat.com
Cc: devel@ovirt.org
Sent: Monday, May 19, 2014 12:43:32 PM
Subject: Re: [ovirt-devel] Entity names in DB scripts



- Original Message -
 From: Eli Mesika emes...@redhat.com
 To: Barak Azulay bazu...@redhat.com
 Cc: devel@ovirt.org
 Sent: Monday, May 19, 2014 11:37:23 AM
 Subject: Re: [ovirt-devel] Entity names in DB scripts
 
 
 
 - Original Message -
  From: Barak Azulay bazu...@redhat.com
  To: Eli Mesika emes...@redhat.com
  Cc: Moti Asayag masa...@redhat.com, devel@ovirt.org
  Sent: Sunday, May 18, 2014 8:42:47 PM
  Subject: Re: [ovirt-devel] Entity names in DB scripts
  
  
  
  - Original Message -
   From: Eli Mesika emes...@redhat.com
   To: Moti Asayag masa...@redhat.com
   Cc: devel@ovirt.org
   Sent: Sunday, May 18, 2014 4:08:45 PM
   Subject: Re: [ovirt-devel] Entity names in DB scripts
   
   
   
   - Original Message -
From: Moti Asayag masa...@redhat.com
To: Eli Mesika emes...@redhat.com
Cc: Yair Zaslavsky yzasl...@redhat.com,
devel@ovirt.org
Sent: Thursday, May 15, 2014 7:33:06 PM
Subject: Re: [ovirt-devel] Entity names in DB scripts



- Original Message -
 From: Eli Mesika emes...@redhat.com
 To: Yair Zaslavsky yzasl...@redhat.com
 Cc: devel@ovirt.org
 Sent: Thursday, May 15, 2014 4:56:50 PM
 Subject: Re: [ovirt-devel] Entity names in DB scripts
 
 
 
 - Original Message -
  From: Yair Zaslavsky yzasl...@redhat.com
  To: devel@ovirt.org
  Sent: Thursday, May 15, 2014 3:20:18 PM
  Subject: [ovirt-devel] Entity names in DB scripts
  
  Hi all,
  I have a feeling there is some inconsistency in
  using
  entity
  names
  in
  the
  DB
  scripts.
  For example, should we use Host or VDS?
  I am not talking about existing tables or columns
  but
  about
  new
  ones
  (and
  new
  stored procedures).
  
  I am quite sure I saw patches containing both
  approaches.

I guess that includes any recent patches around the
network
area.

 
 You are right
 I think old should be kept until we have the time to
 do
 a
 global
 find/replace

Re: [ovirt-devel] Entity names in DB scripts

2014-05-27 Thread Gilad Chaplik

- Original Message -
 From: Sven Kieske s.kie...@mittwald.de
 To: devel@ovirt.org
 Sent: Tuesday, May 27, 2014 3:11:18 PM
 Subject: Re: [ovirt-devel] Entity names in DB scripts

 further more, given the terminology of today
 it's not sure if cluster means gluster cluster
 or migration domain.

 also look at my example for host
 a host can be everything:
 a) the machine engine runs on
 b) a machine in a cluster, running vms
 c) a machine in a cluster, as storage backend
 d) some network equipment (may be virtualized)

 in short: don't use any term which has to broad usage
 (like host or cluster):

 use: compute node for machines running vms

I think Host (=server) is the right term.
compute node can be a rack as well, it's all a matter of POV :-)

 use: migration domain (or similar narrowed down specifc term)
 for a bunch of hosts between which a vm can be migrated.

 Just my opinion of course.

 PS: It's no argument at all to say:
 but we did this always this way, we can't change it

 I know this can introduce a lot of work, but nameing
 schemes can be converted over time or via scripts/automatism.

 Am 27.05.2014 13:15, schrieb Gilad Chaplik:
  Think of the time spent on that, let's take a conversation as an example:

  oVirt guy: 'create a cluster'
  oVirt newcomer: 'what is a cluster?'
  oVirt guy: 'cluster is a migration domain'

  Takes 5 seconds right?
  Now multiply that by every guy that had ever used/worked/heard/already
  forgot/ (newcomer) about oVirt.

  let the scoring begin: I'm -1 on Cluster.

 --
 Mit freundlichen Grüßen / Regards

 Sven Kieske

 Systemadministrator
 Mittwald CM Service GmbH  Co. KG
 Königsberger Straße 6
 32339 Espelkamp
 T: +49-5772-293-100
 F: +49-5772-293-333
 https://www.mittwald.de
 Geschäftsführer: Robert Meyer
 St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
 Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
 ___
 Devel mailing list
 Devel@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Discussion VM CPU pinning and NUMA CPU pinning

2014-05-27 Thread Gilad Chaplik

Hi Jason,

I guess that the time you've waited for feedback is sufficient.

please upload a patch as described (I hope I will get it merged tomorrow).

Thanks, 
Gilad.

- Original Message -
 From: Chuan Liao (Jason Liao, HPservers-Core-OE-PSC) chuan.l...@hp.com
 To: Sven Kieske s.kie...@mittwald.de, devel@ovirt.org
 Sent: Tuesday, May 27, 2014 5:08:55 AM
 Subject: Re: [ovirt-devel] Discussion VM CPU pinning and NUMA CPU pinning
 
 Yes, you are right.
  
 And this design is almost like the libvirt capabilities format
 
 cpu id='0' socket_id='0' core_id='0' siblings='0'/ with attribute socket.
 
 Best Regards,
 Jason Liao
 
  -Original Message-
  From: devel-boun...@ovirt.org [mailto:devel-boun...@ovirt.org] On Behalf Of
  Sven
  Kieske
  Sent: 2014年5月26日 23:51
  To: devel@ovirt.org
  Subject: Re: [ovirt-devel] Discussion VM CPU pinning and NUMA CPU pinning
  
  well I'm no expert in reading xml like model declarations so please correct
  me where
  I'm wrong:
  
  any cpu contains at least 1 core, bound to 1 socket (1 cpu == 1 socket) a
  core does not
  contain any element socket.
  
  Am 26.05.2014 05:11, schrieb Liao, Chuan (Jason Liao,
  HPservers-Core-OE-PSC):
 xs:complexType name=CPU
   xs:sequence
 ...
 xs:element name=cores type=Cores minOccurs=0/
 ...
 /xs:complexType
  
 xs:complexType name=Cores
   xs:sequence
 xs:element ref=core maxOccurs=unbounded/
   /xs:sequence
 /xs:complexType
  
 xs:complexType name=Core
   xs:attribute name=index type=xs:int use=required/
   xs:attribute name=socket type=xs:int use=optional/
 /xs:complexType
  
  --
  Mit freundlichen Grüßen / Regards
  
  Sven Kieske
  
  Systemadministrator
  Mittwald CM Service GmbH  Co. KG
  Königsberger Straße 6
  32339 Espelkamp
  T: +49-5772-293-100
  F: +49-5772-293-333
  https://www.mittwald.de
  Geschäftsführer: Robert Meyer
  St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
  Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
  ___
  Devel mailing list
  Devel@ovirt.org
  http://lists.ovirt.org/mailman/listinfo/devel
 ___
 Devel mailing list
 Devel@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ovirt-users] oVirt 3.5.0 Alpha postponed due to blocker

2014-05-20 Thread Gilad Chaplik

- Original Message -
 From: Sandro Bonazzola sbona...@redhat.com
 To: us...@ovirt.org, devel@ovirt.org, Gilad Chaplik gchap...@redhat.com
 Sent: Tuesday, May 20, 2014 9:48:30 AM
 Subject: Re: [ovirt-users] oVirt 3.5.0 Alpha postponed due to blocker
 
 Il 16/05/2014 16:36, Sandro Bonazzola ha scritto:
  Hi,
  We're postponing oVirt 3.5.0 Alpha release due to the following blocker bug
  discovered while running basic sanity tests:
  
  Bug 1098539 - failed to create VM if no NUMA set is specified
 
 Hi, above bug is still in status NEW, any chance to have it fixed today?
 If not, ETA on this?

merged yesterday's eve thanks to doron.
moved status to modified.

Thanks for the reminder :-)

 
 
  
  On a clean install no VM can be created.
  New tentative release date for 3.5.0 Alpha is 2014-05-20.
  Thanks,
  
 
 
 --
 Sandro Bonazzola
 Better technology. Faster innovation. Powered by community collaboration.
 See how it works at redhat.com
 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Discussion VM CPU pinning and NUMA CPU pinning

2014-05-18 Thread Gilad Chaplik

- Original Message -
 From: Chuan Liao (Jason Liao, HPservers-Core-OE-PSC) chuan.l...@hp.com
 To: Gilad Chaplik gchap...@redhat.com
 Cc: devel@ovirt.org, Doron Fediuck dfedi...@redhat.com, Martin Sivák 
 msi...@redhat.com, Juan Hernandez
 juan.hernan...@redhat.com, Malini Rao m...@redhat.com, Chegu Vinod 
 chegu_vi...@hp.com, Shang-Chun Liang
 (David Liang, HPservers-Core-OE-PSC) shangchun.li...@hp.com, Xiao-Lei Shi 
 (Bruce, HP Servers-PSC-CQ)
 xiao-lei@hp.com
 Sent: Friday, May 16, 2014 5:30:34 AM
 Subject: RE: Discussion VM CPU pinning and NUMA CPU pinning

 Hi Gilad,

 The restful API model of NUMA CPU and CPU-pinning is named NUMACPU ( Under
 NumaNode, VirutalNumaNode )
 Which is contain some attributes;
 index (xs:int): Numa CPU index or vNuma CPU index.
 pin_set (xs:string): Virtual NUMA CPU pin to host NUMA CPU set. ( only
 enabled on VirtualNumaNode )

I think that CPU-pinning new modeling should be coupled with NUMA.
also CPU is a Host sub-entity, so there shouldn't be NUMACPU.

 BTW, Could you give us some update about UI layer solution of NUMA
 CPU-pinning configuration ?

[adding David's response as well, and answering to both questions]

 Hi Gilad,
 Thanks for your reply. Did you submit the UI code. We need to know your UI
 model to consolidate your feedback. Meanwhile, we need to know the current
 cpu pining solution that include the UI code you are in charging. Then, we
 will see if we can specific to RESTful.

 Best Regards,
 David Liang

As discussed, the CPU pinning modeling in GUI won't be handled in first phase 
(maybe as a 3.5 bug later on).
The reason RESTful modeling is important now is obvious, GUI can wait, so 
there's shouldn't be any coupling between GUI and RESTful impl.

Thanks, 
Gilad.

 Best Regards,
 Jason Liao

  -Original Message-
  From: Gilad Chaplik [mailto:gchap...@redhat.com]
  Sent: 2014年5月15日 20:07
  To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC)
  Cc: devel@ovirt.org; Doron Fediuck; Martin Sivák; Juan Hernandez; Malini
  Rao; Vinod,
  Chegu; Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC); Shi,
  Xiao-Lei (Bruce,
  HP Servers-PSC-CQ)
  Subject: Re: Discussion VM CPU pinning and NUMA CPU pinning

  Can you please be more specific on how to model RESTful API, with regards
  to CPU and
  CPU-pinning.

  Thanks,
  Gilad.

  - Original Message -
   From: Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)
   chuan.l...@hp.com
   To: devel@ovirt.org
   Cc: Doron Fediuck dfedi...@redhat.com, Gilad Chaplik
  gchap...@redhat.com, Martin Sivák msi...@redhat.com,
   Juan Hernandez juan.hernan...@redhat.com, Malini Rao
  m...@redhat.com, Chegu Vinod chegu_vi...@hp.com,
   Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)
  shangchun.li...@hp.com, Xiao-Lei Shi (Bruce, HP
   Servers-PSC-CQ) xiao-lei@hp.com
   Sent: Thursday, May 15, 2014 2:50:23 PM
   Subject: Discussion VM CPU pinning and NUMA CPU pinning

   Hi All,

   Now we are working on the NUMA tune feature development for oVirt 3.5.
   This
   feature allow user to configure the vCPU pining according to host
   CPU/NUMA
   topology to get the best performance for created VM. But this will impact
   the current function of vCPU pining. Now, we are looking for a solution
   to
   consolidate the conflict. We want to start an open discussion about VM
   CPU
   pinning (the current design) and NUMA CPU pining (new feature we are
   working
   on) in developer list:

   Background:
   Concept:

   1.  VM CPU pinning: the exist feature in current oVirt, which allow
   user
   to configure the VM vCPU pinning over ovirt, user can configure vCPU
   pining
   independently without NUMA tune.

   2.  NUMA CPU pinning: allow user to configure the vCPU pining
   according
   to host NUMA topology to get the best performance for created VM

   3.  vNode: Virtual NUMA node ( User configured )

   4.  pNode: host physical NUMA node ( Get capability from host )
   Notice:

   1.  NUMA tuning feature and CPU pinning feature are individually in
   libvirt ( ovirt backend ).

   2.  User could configure VM CPU pining individually without NUMA tune
   setup.

   3.  When configuring NUMA tuning feature, user need to configure VM
   NUMA
   tuning ( vNode pinto pNode  tuning mode ) and VM CPU pinning ( NUMA
   included ) to get optimized VM performance, otherwise VM will have low
   performance.

   We have two proposal now for this issue. Please give us some comments and
   your feedback, thanks.

   Solution 1:
GUI:
   Transform between the CPU pinning text and a structure which will be used
   in
   NUMA CPU pinning configure page.
   And then save the CPU pinning text to the current VM CPU pinning
   field of
   VM.
Restful:
   Transform between the CPU pinning text and a structure which will be used
   in
   restful NUMA CPU pinning.
   And then save the CPU pinning text to the current

Re: [ovirt-devel] Discussion VM CPU pinning and NUMA CPU pinning

2014-05-15 Thread Gilad Chaplik

Can you please be more specific on how to model RESTful API, with regards to 
CPU and CPU-pinning.

Thanks, 
Gilad.

- Original Message -
 From: Chuan Liao (Jason Liao, HPservers-Core-OE-PSC) chuan.l...@hp.com
 To: devel@ovirt.org
 Cc: Doron Fediuck dfedi...@redhat.com, Gilad Chaplik 
 gchap...@redhat.com, Martin Sivák msi...@redhat.com,
 Juan Hernandez juan.hernan...@redhat.com, Malini Rao m...@redhat.com, 
 Chegu Vinod chegu_vi...@hp.com,
 Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC) 
 shangchun.li...@hp.com, Xiao-Lei Shi (Bruce, HP
 Servers-PSC-CQ) xiao-lei@hp.com
 Sent: Thursday, May 15, 2014 2:50:23 PM
 Subject: Discussion VM CPU pinning and NUMA CPU pinning

 Hi All,

 Now we are working on the NUMA tune feature development for oVirt 3.5. This
 feature allow user to configure the vCPU pining according to host CPU/NUMA
 topology to get the best performance for created VM. But this will impact
 the current function of vCPU pining. Now, we are looking for a solution to
 consolidate the conflict. We want to start an open discussion about VM CPU
 pinning (the current design) and NUMA CPU pining (new feature we are working
 on) in developer list:

 Background:
 Concept:

 1.  VM CPU pinning: the exist feature in current oVirt, which allow user
 to configure the VM vCPU pinning over ovirt, user can configure vCPU pining
 independently without NUMA tune.

 2.  NUMA CPU pinning: allow user to configure the vCPU pining according
 to host NUMA topology to get the best performance for created VM

 3.  vNode: Virtual NUMA node ( User configured )

 4.  pNode: host physical NUMA node ( Get capability from host )
 Notice:

 1.  NUMA tuning feature and CPU pinning feature are individually in
 libvirt ( ovirt backend ).

 2.  User could configure VM CPU pining individually without NUMA tune
 setup.

 3.  When configuring NUMA tuning feature, user need to configure VM NUMA
 tuning ( vNode pinto pNode  tuning mode ) and VM CPU pinning ( NUMA
 included ) to get optimized VM performance, otherwise VM will have low
 performance.

 We have two proposal now for this issue. Please give us some comments and
 your feedback, thanks.

 Solution 1:
  GUI:
 Transform between the CPU pinning text and a structure which will be used in
 NUMA CPU pinning configure page.
 And then save the CPU pinning text to the current VM CPU pinning field of
 VM.
  Restful:
 Transform between the CPU pinning text and a structure which will be used in
 restful NUMA CPU pinning.
 And then save the CPU pinning text to the current VM CPU pinning field of VM.
  Broker:
 Remove temporary solution(See the current implementation as below) and follow
 previous cpupin configuration procedure.

 Solution 2:
  GUI:
 If current VM CPU pinning is configured, when user open NUMA CPU pinning
 configure page, he will get a warning message. If he continues to configure
 NUMA CPU pinning and save the data, the current VM CPU pinning
 configuration will be cleared.
 NUMA CPU pinning configured data will be saved as new structure individually
 without changing current VM CPU pinning configuration.
  Restful:
 Configure NUMA CPU pinning and then save the data with the new NUMA CPU
 pinning structure.
  Entity and Database:
 Individually NUMA CPU pinning entities and data structure.
  Broker:
  NUMA CPU pinning configuration will be first considered to use. If
  it's not configured, it will use the current VM CPU pinning.

 Solution 1 The CPU pining data is consistent but the code logic is very
 complex.
 Solution 2 have better adaptive and better data structure. This is the way we
 preferred.

 We are appreciated that anybody could give us your comments or the better
 solution you have.

 The below is the current implementation for your reference:
 VM CPU pinning feature
  GUI:
 User input vCPU pining configure data with formatted text.
  Restful:
 User configure CpuTune and VCpuPin model with mapper to CPU pinning text.
  Entity and Database:
 CPU pinning is String property.
  Broker:
 Generate structure of cputune ( libvirt format ) from CPU pining string
 property.
 NUMA tuning feature
  GUI:
 User can drag  drop virtual NUMA node to host NUMA node ( pin to or remove
 pin to ).
  Restful:
 Add/update/remove virtual NUMA node with property of pin to host NUMA node
 index.
  Design NUMACPU model under NUMA node for extend.
  Entity and Database:
 Individually NUMA node entities ( vNode extend pNode ) and store procedure.
  Broker:
 Generate structure of numatune, cpu/numa ( libvirt format ) from NUMA node
 entities.
 Temporary solution prevent Notice 3
  Broker:
 Generate right structure of cputune ( libivirt format ) from NUMA node
 entities ( vNode pinto pNode )
  Limitation:
 This structure of cputune will not get the best

Re: [ovirt-devel] Entity names in DB scripts

2014-05-15 Thread Gilad Chaplik

- Original Message -
 From: Eli Mesika emes...@redhat.com
 To: Yair Zaslavsky yzasl...@redhat.com
 Cc: devel@ovirt.org
 Sent: Thursday, May 15, 2014 4:56:50 PM
 Subject: Re: [ovirt-devel] Entity names in DB scripts

 - Original Message -
  From: Yair Zaslavsky yzasl...@redhat.com
  To: devel@ovirt.org
  Sent: Thursday, May 15, 2014 3:20:18 PM
  Subject: [ovirt-devel] Entity names in DB scripts

  Hi all,
  I have a feeling there is some inconsistency in using entity names in the
  DB
  scripts.
  For example, should we use Host or VDS?
  I am not talking about existing tables or columns but about new ones (and
  new
  stored procedures).

  I am quite sure I saw patches containing both approaches.

 You are right
 I think old should be kept until we have the time to do a global find/replace
 of all old names.
 The only place in which I encourage new names are application log/audit
 messages

+1

Note that in the UI we're using new names since I can remember, so less 
re-factoring ;-)

  Yair
  ___
  Devel mailing list
  Devel@ovirt.org
  http://lists.ovirt.org/mailman/listinfo/devel

 ___
 Devel mailing list
 Devel@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/devel

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Custom Properties code duplication

2014-05-08 Thread Gilad Chaplik

- Original Message -
From: Lior Vernia lver...@redhat.com
To: Gilad Chaplik gchap...@redhat.com
Cc: Vojtech Szocs vsz...@redhat.com, devel@ovirt.org
Sent: Wednesday, May 7, 2014 7:29:23 PM
Subject: Re: [ovirt-devel] Custom Properties code duplication

On 07/05/14 18:57, Gilad Chaplik wrote:
- Original Message -
From: Lior Vernia lver...@redhat.com
To: Gilad Chaplik gchap...@redhat.com
Cc: Vojtech Szocs vsz...@redhat.com, devel@ovirt.org
Sent: Wednesday, May 7, 2014 5:32:38 PM
Subject: Re: [ovirt-devel] Custom Properties code duplication

On 07/05/14 16:02, Gilad Chaplik wrote:
- Original Message -
From: Lior Vernia lver...@redhat.com
To: Vojtech Szocs vsz...@redhat.com
Cc: devel@ovirt.org
Sent: Monday, May 5, 2014 7:08:23 PM
Subject: Re: [ovirt-devel] Custom Properties code duplication

Hey guys (and gals),

A few patches are up for review starting at:
http://gerrit.ovirt.org/#/c/27383

In total, about 250 lines of code removed, hopefully not at the cost of
regression. I put down some reviewers as I saw fit, but everyone can
feel free to add themselves. Summary of what was done compared to the
original plan:

1. Removed said dependencies, except for DeviceCustomPropertiesUtils
that was using the capture groups features of Pattern, and thus remained
in the utils project.

2. Done.

3. Done.

4. Almost didn't touch this, it seems to involve a lot of moving parts.

Yours, Lior.

On 30/04/14 18:01, Vojtech Szocs wrote:
Hi Lior, please find my comments inline.

- Original Message -
From: Yair Zaslavsky yzasl...@redhat.com
To: Lior Vernia lver...@redhat.com
Cc: devel@ovirt.org
Sent: Wednesday, April 30, 2014 3:28:06 PM
Subject: Re: [ovirt-devel] Custom Properties code duplication

- Original Message -
From: Lior Vernia lver...@redhat.com
To: devel@ovirt.org
Sent: Wednesday, April 30, 2014 3:52:16 PM
Subject: [ovirt-devel] Custom Properties code duplication

Hello,

While adding network custom properties towards oVirt 3.5, I got to
take
a good look at the custom properties code in the backend and
frontend.
It seems to me like there's a lot of code duplication, and I would
like
to suggest the following refactoring:

1. Remove dependencies on Pattern/Matcher and ApacheCommons methods
from
*CustomPropertiesUtils.java, to make them compilable with GWT, and
move
these utilities to the common package. The usage of the said methods
is
minimal and could easily be replaced with String methods, etc.

In general I am in favor, but how are you going to perform the regex
validation of values?
for example , with vm custom properties, you have - sap_agent that can
be
either true or false.
So you need to validate both at the client and the engine, right?

Lior mentioned above the possibility of using String methods, I assume
by this he means java.lang.String.matches(String) and similar methods.

During GWT compilation, JRE standard String implementation is replaced
by emulated (GWT-friendly) String implementation, which implements
methods like matches(String) using JavaScript RegExp object. You can
find this emulated implementation here:

gwt-user-{version}-sources.jar/com/google/gwt/emul/java/lang/String.java

Another alternative is to use GWT's built-in regex support through
com.google.gwt.regexp.shared.RegExp class. GWT's RegExp class has two
implementations, default one using JRE Pattern/Matcher, emulated one
using JavaScript RegExp object. The advantage is (mostly) consistent
regex support on both client and server, the disadvantage is server's
dependency on GWT JAR. (I don't think we want this.)

For simple regex matches, I'd suggest to simply go with String
approach.

For complex regex matches, we can use JRE Pattern/Matcher on server,
and emulate given implementation using GWT RegExp on client.

Note that there are (slight) differences between JRE's Pattern/Matcher
and JavaScript's RegExp object syntax/behavior. Check GWT RegExp class
Javadoc to see details (for simple cases, it's not a big deal, though).

2. Modify KeyValueModel to delegate to the common utilities instead
of
duplicating code, e.g. for validation.

I see that KeyValueModel uses RegexValidation class that delegates to
compat's Regex class. Just like above, default Regex class utilizes
JRE Pattern/Matcher but client uses emuluated implementation:

gwt-extension/src/main/java/org/ovirt/engine/ui/uioverrides/org/ovirt/engine/core/compat/Regex.java

and this emulated implementation uses GWT RegExp class.

3. Move some validation, which is relevant to all custom properties
(e.g. duplicate keys), from specific utils (e.g. VmPropertiesUtils)
up
to the shared CustomPropertiesUtils.

4. Optionally change the implementation of custom properties

Re: [ovirt-devel] Custom Properties code duplication

2014-05-08 Thread Gilad Chaplik

- Original Message -
 From: Gilad Chaplik gchap...@redhat.com
 To: Lior Vernia lver...@redhat.com
 Cc: devel@ovirt.org
 Sent: Thursday, May 8, 2014 9:50:19 AM
 Subject: Re: [ovirt-devel] Custom Properties code duplication

 - Original Message -
  From: Lior Vernia lver...@redhat.com
  To: Gilad Chaplik gchap...@redhat.com
  Cc: Vojtech Szocs vsz...@redhat.com, devel@ovirt.org
  Sent: Wednesday, May 7, 2014 7:29:23 PM
  Subject: Re: [ovirt-devel] Custom Properties code duplication

  On 07/05/14 18:57, Gilad Chaplik wrote:
   - Original Message -
   From: Lior Vernia lver...@redhat.com
   To: Gilad Chaplik gchap...@redhat.com
   Cc: Vojtech Szocs vsz...@redhat.com, devel@ovirt.org
   Sent: Wednesday, May 7, 2014 5:32:38 PM
   Subject: Re: [ovirt-devel] Custom Properties code duplication

   On 07/05/14 16:02, Gilad Chaplik wrote:
   - Original Message -
   From: Lior Vernia lver...@redhat.com
   To: Vojtech Szocs vsz...@redhat.com
   Cc: devel@ovirt.org
   Sent: Monday, May 5, 2014 7:08:23 PM
   Subject: Re: [ovirt-devel] Custom Properties code duplication

   Hey guys (and gals),

   A few patches are up for review starting at:
   http://gerrit.ovirt.org/#/c/27383

   In total, about 250 lines of code removed, hopefully not at the cost
   of
   regression. I put down some reviewers as I saw fit, but everyone can
   feel free to add themselves. Summary of what was done compared to the
   original plan:

   1. Removed said dependencies, except for DeviceCustomPropertiesUtils
   that was using the capture groups features of Pattern, and thus
   remained
   in the utils project.

   2. Done.

   3. Done.

   4. Almost didn't touch this, it seems to involve a lot of moving
   parts.

   Yours, Lior.

   On 30/04/14 18:01, Vojtech Szocs wrote:
   Hi Lior, please find my comments inline.

   - Original Message -
   From: Yair Zaslavsky yzasl...@redhat.com
   To: Lior Vernia lver...@redhat.com
   Cc: devel@ovirt.org
   Sent: Wednesday, April 30, 2014 3:28:06 PM
   Subject: Re: [ovirt-devel] Custom Properties code duplication

   - Original Message -
   From: Lior Vernia lver...@redhat.com
   To: devel@ovirt.org
   Sent: Wednesday, April 30, 2014 3:52:16 PM
   Subject: [ovirt-devel] Custom Properties code duplication

   Hello,

   While adding network custom properties towards oVirt 3.5, I got to
   take
   a good look at the custom properties code in the backend and
   frontend.
   It seems to me like there's a lot of code duplication, and I would
   like
   to suggest the following refactoring:

   1. Remove dependencies on Pattern/Matcher and ApacheCommons methods
   from
   *CustomPropertiesUtils.java, to make them compilable with GWT, and
   move
   these utilities to the common package. The usage of the said
   methods
   is
   minimal and could easily be replaced with String methods, etc.

   +1

   In general I am in favor, but how are you going to perform the regex
   validation of values?
   for example , with vm custom properties, you have - sap_agent that
   can
   be
   either true or false.
   So you need to validate both at the client and the engine, right?

   Lior mentioned above the possibility of using String methods, I
   assume
   by this he means java.lang.String.matches(String) and similar
   methods.

   During GWT compilation, JRE standard String implementation is
   replaced
   by emulated (GWT-friendly) String implementation, which implements
   methods like matches(String) using JavaScript RegExp object. You can
   find this emulated implementation here:

   gwt-user-{version}-sources.jar/com/google/gwt/emul/java/lang/String.java

   Another alternative is to use GWT's built-in regex support through
   com.google.gwt.regexp.shared.RegExp class. GWT's RegExp class has two
   implementations, default one using JRE Pattern/Matcher, emulated one
   using JavaScript RegExp object. The advantage is (mostly) consistent
   regex support on both client and server, the disadvantage is server's
   dependency on GWT JAR. (I don't think we want this.)

   For simple regex matches, I'd suggest to simply go with String
   approach.

   For complex regex matches, we can use JRE Pattern/Matcher on server,
   and emulate given implementation using GWT RegExp on client.

   Note that there are (slight) differences between JRE's
   Pattern/Matcher
   and JavaScript's RegExp object syntax/behavior. Check GWT RegExp
   class
   Javadoc to see details (for simple cases, it's not a big deal,
   though).

   2. Modify KeyValueModel to delegate to the common utilities instead
   of
   duplicating code, e.g. for validation.

   +1

   I see that KeyValueModel uses RegexValidation class that delegates to
   compat's Regex class. Just like above, default Regex class utilizes
   JRE Pattern/Matcher but client uses emuluated implementation:

   gwt-extension/src/main

Re: [ovirt-devel] Custom Properties code duplication

2014-05-07 Thread Gilad Chaplik

- Original Message -
From: Lior Vernia lver...@redhat.com
To: Gilad Chaplik gchap...@redhat.com
Cc: Vojtech Szocs vsz...@redhat.com, devel@ovirt.org
Sent: Wednesday, May 7, 2014 5:32:38 PM
Subject: Re: [ovirt-devel] Custom Properties code duplication

Hey guys (and gals),

A few patches are up for review starting at:
http://gerrit.ovirt.org/#/c/27383

1. Removed said dependencies, except for DeviceCustomPropertiesUtils
that was using the capture groups features of Pattern, and thus remained
in the utils project.

2. Done.

3. Done.

4. Almost didn't touch this, it seems to involve a lot of moving parts.

Yours, Lior.

On 30/04/14 18:01, Vojtech Szocs wrote:
Hi Lior, please find my comments inline.

- Original Message -
From: Lior Vernia lver...@redhat.com
To: devel@ovirt.org
Sent: Wednesday, April 30, 2014 3:52:16 PM
Subject: [ovirt-devel] Custom Properties code duplication

Hello,

While adding network custom properties towards oVirt 3.5, I got to take
a good look at the custom properties code in the backend and frontend.
It seems to me like there's a lot of code duplication, and I would like
to suggest the following refactoring:

1. Remove dependencies on Pattern/Matcher and ApacheCommons methods
from
*CustomPropertiesUtils.java, to make them compilable with GWT, and move
these utilities to the common package. The usage of the said methods is
minimal and could easily be replaced with String methods, etc.

Lior mentioned above the possibility of using String methods, I assume
by this he means java.lang.String.matches(String) and similar methods.

gwt-user-{version}-sources.jar/com/google/gwt/emul/java/lang/String.java

For simple regex matches, I'd suggest to simply go with String approach.

For complex regex matches, we can use JRE Pattern/Matcher on server,
and emulate given implementation using GWT RegExp on client.

2. Modify KeyValueModel to delegate to the common utilities instead of
duplicating code, e.g. for validation.

I see that KeyValueModel uses RegexValidation class that delegates to
compat's Regex class. Just like above, default Regex class utilizes
JRE Pattern/Matcher but client uses emuluated implementation:

gwt-extension/src/main/java/org/ovirt/engine/ui/uioverrides/org/ovirt/engine/core/compat/Regex.java

and this emulated implementation uses GWT RegExp class.

3. Move some validation, which is relevant to all custom properties
(e.g. duplicate keys), from specific utils (e.g. VmPropertiesUtils) up
to the shared CustomPropertiesUtils.

4. Optionally change the implementation of custom properties members in
entities (e.g. VM) from String to MapString, String, which would
obviate the need for different conversion methods between String/Map -
(de)serialization would only be required in DB interaction.

3,4 Agreed - good points.

The main argument against this would be that the frontend is to be
moved
over

Re: [ovirt-devel] Small reminder about 0000_config.sql

2014-04-18 Thread Gilad Chaplik

- Original Message -
 From: Michal Skrivanek michal.skriva...@redhat.com
 To: Alon Bar-Lev alo...@redhat.com, Yair Zaslavsky yzasl...@redhat.com
 Cc: devel@ovirt.org
 Sent: Friday, April 18, 2014 11:05:48 AM
 Subject: Re: [ovirt-devel] Small reminder about _config.sql

 On Apr 18, 2014, at 09:10 , Alon Bar-Lev alo...@redhat.com wrote:

  - Original Message -
  From: Yair Zaslavsky yzasl...@redhat.com
  To: Alon Bar-Lev alo...@redhat.com
  Cc: Eli Mesika emes...@redhat.com, devel@ovirt.org
  Sent: Friday, April 18, 2014 4:57:54 AM
  Subject: Re: [ovirt-devel] Small reminder about _config.sql

  - Original Message -
  From: Alon Bar-Lev alo...@redhat.com
  To: Eli Mesika emes...@redhat.com
  Cc: devel@ovirt.org
  Sent: Friday, April 18, 2014 1:19:41 AM
  Subject: Re: [ovirt-devel] Small reminder about _config.sql

  - Original Message -
  From: Eli Mesika emes...@redhat.com
  To: Alon Bar-Lev alo...@redhat.com
  Cc: devel@ovirt.org, Barak Azulay bazu...@redhat.com, Oved
  Ourfalli
  oourf...@redhat.com
  Sent: Friday, April 18, 2014 12:06:38 AM
  Subject: Re: [ovirt-devel] Small reminder about _config.sql

  - Original Message -
  From: Alon Bar-Lev alo...@redhat.com
  To: Yair Zaslavsky yzasl...@redhat.com
  Cc: devel@ovirt.org
  Sent: Thursday, April 17, 2014 10:45:40 PM
  Subject: Re: [ovirt-devel] Small reminder about _config.sql

  - Original Message -
  From: Yair Zaslavsky yzasl...@redhat.com
  To: devel@ovirt.org
  Sent: Thursday, April 17, 2014 12:43:37 PM
  Subject: [ovirt-devel] Small reminder about _config.sql

  Hi all, and happy holidays.
  I would like to give a small reminder about the contents of
  _config.sql
  -
  We are trying to keep an alphabetical order when it comes to the
  option
  names
  (the keys).

I think we should order/maintain the options by topic (network, storage, 
console, etc.), we can order alphabetically within topics but IMO pointless.
Does someone really lookup alphabetically?

  We really need to remove this mechanism of config and hold within
  database
  only non default values.
  Default values should go into properties file or even into code.
  We need someone to take ownership of this ask, I will be happy to
  instruct.

  Alon, I will be glad to own that (CCing Barak  Oved) , can you please
  open
  a
  oVirt RFE on that ?

  Thanks!

  Done[1]

  [1] https://bugzilla.redhat.com/show_bug.cgi?id=1089093

  Bare in mind default values already exist in code (maybe need to be
  revisited, but that's something else) at ConfigValues.

 I'd be more than happy to see all those going away. Many of them are outdated
 and plain wrong.

  engine-config cannot set a value to a default that exists only in
  ConfigValues.
  So in principal you are right, but the entire solution does not support
  this.

  Thanks,

  Yair
  ___
  Devel mailing list
  Devel@ovirt.org
  http://lists.ovirt.org/mailman/listinfo/devel

  ___
  Devel mailing list
  Devel@ovirt.org
  http://lists.ovirt.org/mailman/listinfo/devel

  ___
  Devel mailing list
  Devel@ovirt.org
  http://lists.ovirt.org/mailman/listinfo/devel

  ___
  Devel mailing list
  Devel@ovirt.org
  http://lists.ovirt.org/mailman/listinfo/devel

 ___
 Devel mailing list
 Devel@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/devel

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [Devel] QoS Aggregate

2014-04-13 Thread Gilad Chaplik

- Original Message -
 From: Moti Asayag masa...@redhat.com
 To: Gilad Chaplik gchap...@redhat.com
 Cc: devel@ovirt.org
 Sent: Sunday, April 13, 2014 3:59:39 PM
 Subject: Re: [Devel] QoS Aggregate

 - Original Message -
  From: Gilad Chaplik gchap...@redhat.com
  To: devel@ovirt.org
  Sent: Monday, April 7, 2014 6:59:07 PM
  Subject: [Devel] QoS Aggregate

  Hi list,

  While oVirt is rapidly continues to grow and gather features, it’s
  important
  to wrap already existing features with new ones, for better UX reasons.
  In oVirt 3.5, there are going to be 2 new QoS objects, CPU limits and blkio
  limits, added to the existing one network QoS (since 3.3).

  You are more than welcome to review my proposal to aggregate all features
  under the same umbrella:

  http://www.ovirt.org/Features/aggregate_QoS

 Generally, I'm okay with the proposed design, however since we're using any
 ORM framework to mitigate the data retrieval, could you provide the required
 DB changes in details ? Meaning, how would you implement the DB inheritance ?

Both net_QoS and net_profiles tables will be renamed and a type field will be 
added; current db network flows will be renamed as well, for all 'ByType' ref 
will be added. i.e. you can't query (fetching or CRUD) a QoS/profile without 
specifying type in parameters.

 In addition, could you add the expected can-do-actions for example, prevent
 using a
 specific QoS type when is not in the right scope, or block updating the QoS
 type.

All QoS and Profile objects will inherit IQoS and IProfile interfaces 
respectively; both ifaces will contain a 'validate()' and a 'toString()' 
methods.
validate will be used both in client and server sides, toString will be used in 
aggregating QoS objects in UI (getQoSWithoutType is the only place type won't 
be used in the process, REST is kinda unique since there is no type notion at 
least in QoS (DC level); profiles type will be derived from context).

 Currently there is a top level collection named vnicprofiles, a specific
 collection
 for vm network interfaces profiles. Any thoughts about this as well ?

Should remain intact till we're allow to break it, I guess.

 How will the search mechanism act with the suggested proposal ?

No search mechanism for vnicprofiles, is there a bug? anyway, that's good :) in 
new design network profiles will be removed as a main tab (no search is needed 
+ no regression= I'm happy); for top level rest collection, I'm not sure search 
is required...

I know sparse matrix isn't the best approach, at least for profiles, but I 
believe we can reuse already existing flows (which were tested), with minor 
alterations and risk. also I believe that one day profiles (aka SLA policy) 
will be a main entity in the system and all profiles' parameters will be 
aggregated to a single policy object, to help administrators with simple use 
cases; GOLD policy = GOLD QoS = all params have max values.

Hope I've provided satisfying answers to your questions, I will update the wiki 
page accordingly.

Thanks Moti!

Thanks, 
Gilad.

  Thanks,
  Gilad.
  ___
  Devel mailing list
  Devel@ovirt.org
  http://lists.ovirt.org/mailman/listinfo/devel

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[Devel] QoS Aggregate

2014-04-07 Thread Gilad Chaplik

Hi list,

While oVirt is rapidly continues to grow and gather features, it’s important to 
wrap already existing features with new ones, for better UX reasons.
In oVirt 3.5, there are going to be 2 new QoS objects, CPU limits and blkio 
limits, added to the existing one network QoS (since 3.3).

You are more than welcome to review my proposal to aggregate all features under 
the same umbrella:

http://www.ovirt.org/Features/aggregate_QoS

Thanks, 
Gilad.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [Engine-devel] NUMA support action items

2014-04-06 Thread Gilad Chaplik

- Original Message -
 From: Chegu Vinod chegu_vi...@hp.com
 To: Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ) xiao-lei@hp.com
 Cc: Einav Cohen eco...@redhat.com, Shang-Chun Liang (David Liang, 
 HPservers-Core-OE-PSC)
 shangchun.li...@hp.com, Chuan Liao (Jason Liao, HPservers-Core-OE-PSC) 
 chuan.l...@hp.com, msi...@redhat.com,
 Da-huai Tang (Gary, MCXS-CQ) da-huai.t...@hp.com, Malini Rao 
 m...@redhat.com, Eldan Hildesheim
 ehild...@redhat.com, Doron Fediuck dfedi...@redhat.com, 
 sher...@redhat.com, Alexander Wels
 aw...@redhat.com, Gilad Chaplik gchap...@redhat.com
 Sent: Thursday, April 3, 2014 3:28:03 PM
 Subject: RE: NUMA support action items

 Hi Bruce,

 The virtual NUMA layout in the guest is a very simple one (not multi-level
 etc). It is generated by qemu+seabios... and there is no relationship with
 the host NUMA node distances etc.  Let us not worry about gathering Virtual
 NUMA node distances for now.

 Vinod

CC'ing devel list as well.

Having said that, I don't see a reason why not to prepare an infrastructure for 
that (if it's free) for future versions (guest agent will collect vNuma data in 
some point in time).

Thanks, 
Gilad.

 -Original Message-
 From: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
 Sent: Thursday, April 03, 2014 12:41 AM
 To: Vinod, Chegu
 Cc: Einav Cohen; Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC);
 Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); msi...@redhat.com; Tang,
 Da-huai (Gary, MCXS-CQ); Malini Rao; Eldan Hildesheim; Doron Fediuck;
 sher...@redhat.com; Alexander Wels; Gilad Chaplik
 Subject: RE: NUMA support action items

 Hi Vinod,

 Is it meaningful for us to collect the distance information of vm numa node
 (maybe in future, not now)?
 In my understanding, vm numa topology is a simulation of numa topology, since
 the vcpus are just threads, I don't know how the vm numa node distances are
 calculated in vm. Is there any relationship between the vNode distances and
 host node distances?

 Thanks  Best Regards
 Shi, Xiao-Lei (Bruce)

 Hewlett-Packard Co., Ltd.
 HP Servers Core Platform Software China Telephone +86 23 65683093 Mobile +86
 18696583447 Email xiao-lei@hp.com

 -Original Message-
 From: Vinod, Chegu
 Sent: Thursday, April 03, 2014 7:18 AM
 To: Gilad Chaplik
 Cc: Einav Cohen; Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC);
 Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); msi...@redhat.com; Shi,
 Xiao-Lei (Bruce, HP Servers-PSC-CQ); Tang, Da-huai (Gary, MCXS-CQ); Malini
 Rao; Eldan Hildesheim; Doron Fediuck; sher...@redhat.com; Alexander Wels
 Subject: RE: NUMA support action items

 Not sure what the correct way to do this isbut here is a suggestion.

 Let a given host server diagram shown be very generic...i.e. show the N
 sockets/nodes numbered from 0 thru N-1.  Show the amount of memory and the
 list of CPUs in each of those sockets/nodes.
 Draw a generic Interconnect fabric [box] in between which all the sockets
 connect to

 Ideally ... Under that host diagram we could show the NUMA node distances in
 text format (as you know this is derived from the numactl -H and then
 conveyed from VDSM- oVIrt engine etc).
 That distance info. will tell the user what the distance between a pair of
 sockets/nodes are (and they can then do what they wish after that :)).

 Vinod

 -Original Message-
 From: Gilad Chaplik [mailto:gchap...@redhat.com]
 Sent: Wednesday, April 02, 2014 4:09 PM
 To: Vinod, Chegu
 Cc: Einav Cohen; Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC);
 Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); msi...@redhat.com; Shi,
 Xiao-Lei (Bruce, HP Servers-PSC-CQ); Tang, Da-huai (Gary, MCXS-CQ); Malini
 Rao; Eldan Hildesheim; Doron Fediuck; sher...@redhat.com; Alexander Wels
 Subject: Re: NUMA support action items

 Thank you Vinod for the much elaborate explanation.
 GUI-wise, do you want to show those numbers? maybe for first phase, enough to
 show them via API?

 A thought, According to your example there could be up to 2 distances, so
 maybe the 'closer' nodes can be on the same column or sth; I mean to try an
 illustrate it graphically rather than with numbers (we have enough of those
 :)).

 Thanks,
 Gilad.

 - Original Message -
  From: Chegu Vinod chegu_vi...@hp.com
  To: Einav Cohen eco...@redhat.com
  Cc: Gilad Chaplik gchap...@redhat.com, Shang-Chun Liang (David Liang,
  HPservers-Core-OE-PSC)
  shangchun.li...@hp.com, Chuan Liao (Jason Liao,
  HPservers-Core-OE-PSC) chuan.l...@hp.com, msi...@redhat.com, Xiao-Lei
  Shi (Bruce, HP Servers-PSC-CQ) xiao-lei@hp.com, Da-huai Tang
  (Gary, MCXS-CQ)
  da-huai.t...@hp.com, Malini Rao m...@redhat.com, Eldan Hildesheim
  ehild...@redhat.com, Doron Fediuck
  dfedi...@redhat.com, sher...@redhat.com, Alexander Wels
  aw...@redhat.com
  Sent: Saturday, March 29, 2014 8:15:56 AM
  Subject: Re: NUMA support action items

  On 3/27/2014 10:42 AM, Einav Cohen wrote:
   Hi Vinod, thank you very

Re: [Engine-devel] Please help us to review our database schema design with NUMA feature on ovirt

2014-04-06 Thread Gilad Chaplik

- Original Message -
 From: Eli Mesika emes...@redhat.com
 To: Omer Frenkel ofren...@redhat.com
 Cc: Gilad Chaplik gchap...@redhat.com, Xiao-Lei Shi (Bruce, HP 
 Servers-PSC-CQ) xiao-lei@hp.com, Roy
 Golan rgo...@redhat.com, Chuan Liao (Jason Liao, HPservers-Core-OE-PSC) 
 chuan.l...@hp.com, Doron Fediuck
 dfedi...@redhat.com, Chegu Vinod chegu_vi...@hp.com, Shang-Chun Liang 
 (David Liang, HPservers-Core-OE-PSC)
 shangchun.li...@hp.com, Yaniv Dary yd...@redhat.com, 
 engine-devel@ovirt.org
 Sent: Thursday, April 3, 2014 4:51:38 PM
 Subject: Re: Please help us to review our database schema design with NUMA 
 feature on ovirt
 
 
 
 - Original Message -
  From: Omer Frenkel ofren...@redhat.com
  To: Gilad Chaplik gchap...@redhat.com
  Cc: Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ) xiao-lei@hp.com, Roy
  Golan rgo...@redhat.com, Eli Mesika
  emes...@redhat.com, Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)
  chuan.l...@hp.com, Doron Fediuck
  dfedi...@redhat.com, Chegu Vinod chegu_vi...@hp.com, Shang-Chun
  Liang (David Liang, HPservers-Core-OE-PSC)
  shangchun.li...@hp.com, Yaniv Dary yd...@redhat.com,
  engine-devel@ovirt.org
  Sent: Thursday, April 3, 2014 4:45:49 PM
  Subject: Re: Please help us to review our database schema design with NUMA
  feature on ovirt
  
  
  
  - Original Message -
   From: Gilad Chaplik gchap...@redhat.com
   To: Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ) xiao-lei@hp.com, Roy
   Golan rgo...@redhat.com, Omer Frenkel
   ofren...@redhat.com
   Cc: Eli Mesika emes...@redhat.com, Roy Golan rgo...@redhat.com,
   Chuan Liao (Jason Liao,
   HPservers-Core-OE-PSC) chuan.l...@hp.com, Doron Fediuck
   dfedi...@redhat.com, Chegu Vinod
   chegu_vi...@hp.com, Shang-Chun Liang (David Liang,
   HPservers-Core-OE-PSC) shangchun.li...@hp.com, Yaniv Dary
   yd...@redhat.com, engine-devel@ovirt.org
   Sent: Monday, March 31, 2014 4:31:17 PM
   Subject: Re: Please help us to review our database schema design with
   NUMA
   feature on ovirt
   
   adding Roy  Omer.
   
   why CPU topology is in dynamic?
   
  
  the guideline we (try to) follow today is (i know you can find exceptions
  to
  this, but this is how it suppose to be):
  vm/vds static - user configurable information (whatever you have in
  add/edit)
  vm dynamic - information related to a running instance, the is changed in a
  somewhat small frequency
  vds dynamic - host capabilities, information from the host that doesn't
  change while the host is up.
  statistics - all the rest, mostly statistics, and other fast changing
  information.
 
 IMO it is a little more complicated and the terms static/dynamic does not
 reflect today the meaning of those terms rather, if engine knows the values
 by itself , this is considered static and if it has to ask the VDSM for
 the value then this is considered dynamic.
 For example cpu_cores is a static information but it is stored in
 vds_dynamic since we get the value from VDSM.
 I found those terms very confusing and a good candidate for a serious
 refactoring in future
 

+1, I've opened another thread about it in devel list, and cc'ed Omer.

 
  
   Thanks,
   Gilad.
   
   - Original Message -
From: Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ) xiao-lei@hp.com
To: Eli Mesika emes...@redhat.com
Cc: Gilad Chaplik gchap...@redhat.com, Roy Golan
rgo...@redhat.com,
Chuan Liao (Jason Liao,
HPservers-Core-OE-PSC) chuan.l...@hp.com, Doron Fediuck
dfedi...@redhat.com, Chegu Vinod
chegu_vi...@hp.com, Shang-Chun Liang (David Liang,
HPservers-Core-OE-PSC) shangchun.li...@hp.com, Yaniv Dary
yd...@redhat.com, engine-devel@ovirt.org
Sent: Monday, March 31, 2014 3:20:33 PM
Subject: RE: Please help us to review our database schema design with
NUMA
feature on ovirt

Thanks Eli.
I will move the vm level NUMA fields to vm_dynamic, and the related
database
schema will be updated accordingly.

Thanks  Best Regards
Shi, Xiao-Lei (Bruce)

Hewlett-Packard Co., Ltd.
HP Servers Core Platform Software China
Telephone +86 23 65683093
Mobile +86 18696583447
Email xiao-lei@hp.com

-Original Message-
From: Eli Mesika [mailto:emes...@redhat.com]
Sent: Monday, March 31, 2014 5:49 PM
To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
Cc: Gilad Chaplik; Roy Golan; Liao, Chuan (Jason Liao,
HPservers-Core-OE-PSC); Doron Fediuck; Vinod, Chegu; Liang, Shang-Chun
(David Liang, HPservers-Core-OE-PSC); Yaniv Dary;
engine-devel@ovirt.org
Subject: Re: Please help us to review our database schema design with
NUMA
feature on ovirt



- Original Message -
 From: Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ) xiao-lei@hp.com
 To: Gilad Chaplik gchap...@redhat.com, Eli Mesika
 emes...@redhat.com, Roy Golan rgo...@redhat.com
 Cc: Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)
 chuan.l...@hp.com

Re: [Engine-devel] vds_dynamic refactor

2014-04-06 Thread Gilad Chaplik

- Original Message -
 From: Liran Zelkha liran.zel...@gmail.com
 To: Eli Mesika emes...@redhat.com
 Cc: Gilad Chaplik gchap...@redhat.com, engine-devel 
 engine-devel@ovirt.org
 Sent: Thursday, April 3, 2014 4:36:07 PM
 Subject: Re: [Engine-devel] vds_dynamic refactor

 I would be happy if we can lose vds_dynamic all together, and just keep
 vds_static and vds_statistics. Our performance will be happy too ;-)

@Liran, status and pending fields are very fragile ones, IMO need separate 
table.
@Eli, iirc, you don't have a problem with adding more tables :-)

 On Thu, Apr 3, 2014 at 4:33 PM, Eli Mesika emes...@redhat.com wrote:

  - Original Message -
   From: Gilad Chaplik gchap...@redhat.com
   To: Yair Zaslavsky yzasl...@redhat.com
   Cc: engine-devel engine-devel@ovirt.org
   Sent: Thursday, April 3, 2014 4:00:25 PM
   Subject: Re: [Engine-devel] vds_dynamic refactor

   - Original Message -
From: Yair Zaslavsky yzasl...@redhat.com
To: Liran Zelkha liran.zel...@gmail.com
Cc: Gilad Chaplik gchap...@redhat.com, engine-devel
engine-devel@ovirt.org
Sent: Thursday, April 3, 2014 2:12:59 PM
Subject: Re: [Engine-devel] vds_dynamic refactor

- Original Message -
 From: Liran Zelkha liran.zel...@gmail.com
 To: Gilad Chaplik gchap...@redhat.com
 Cc: engine-devel engine-devel@ovirt.org
 Sent: Thursday, April 3, 2014 2:04:29 PM
 Subject: Re: [Engine-devel] vds_dynamic refactor

 Why not move it to vds_static?

+1 on Liran's comment.

  +1 as well , vds_static is the place for that

I would prefer not to add more complexity to the  vds tables family.
Such complexity may effect performs of queries/views.
If you wish, you can create a view on top of vds_static named
  vds_on_boot
for
querying of vds on boot info.

Yair

   That means moving almost all of vds_dynamic into vds_static except of
  memory,
   pending resources and status (maybe more but not much);
   and there will not be any db separation between user input and on_boot
  data.

  Why we should have such separation ?

   Thanks,
   Gilad.

 On Thu, Apr 3, 2014 at 2:00 PM, Gilad Chaplik gchap...@redhat.com
 wrote:

  Hi list,

  I propose to split vds_dynamic table into 2 tables:
  - vds_dynamic
  - vds_on_boot
  We need a place to put all non-dynamic data that gets updated once
  the
  host is booted, and I think dynamic isn't the place for it.
  In first phase we will put there NUMA host topoplogy, but later on
  migrate
  all non-dynamic host data (cpu, os, etc.).

  thoughts?

  Thanks,
  Gilad.
  ___
  Engine-devel mailing list
  Engine-devel@ovirt.org
  http://lists.ovirt.org/mailman/listinfo/engine-devel

 ___
 Engine-devel mailing list
 Engine-devel@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/engine-devel

   ___
   Engine-devel mailing list
   Engine-devel@ovirt.org
   http://lists.ovirt.org/mailman/listinfo/engine-devel

  ___
  Engine-devel mailing list
  Engine-devel@ovirt.org
  http://lists.ovirt.org/mailman/listinfo/engine-devel

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] vds_dynamic refactor

2014-04-06 Thread Gilad Chaplik

- Original Message -
 From: Liran Zelkha liran.zel...@gmail.com
 To: Gilad Chaplik gchap...@redhat.com
 Cc: Eli Mesika emes...@redhat.com, engine-devel engine-devel@ovirt.org
 Sent: Thursday, April 3, 2014 5:16:51 PM
 Subject: Re: [Engine-devel] vds_dynamic refactor

 Don't go down that road.  Status shouldn't be saved in the db.
 But anyway statistics is rapidly changing. So it fits...

First let's have a notion of caching, then notion of shared caching, then I can 
start thinking of not going down that road...

 On Apr 3, 2014 5:14 PM, Gilad Chaplik gchap...@redhat.com wrote:

  - Original Message -
   From: Liran Zelkha liran.zel...@gmail.com
   To: Eli Mesika emes...@redhat.com
   Cc: Gilad Chaplik gchap...@redhat.com, engine-devel 
  engine-devel@ovirt.org
   Sent: Thursday, April 3, 2014 4:36:07 PM
   Subject: Re: [Engine-devel] vds_dynamic refactor

   I would be happy if we can lose vds_dynamic all together, and just keep
   vds_static and vds_statistics. Our performance will be happy too ;-)

  @Liran, status and pending fields are very fragile ones, IMO need separate
  table.
  @Eli, iirc, you don't have a problem with adding more tables :-)

   On Thu, Apr 3, 2014 at 4:33 PM, Eli Mesika emes...@redhat.com wrote:

- Original Message -
 From: Gilad Chaplik gchap...@redhat.com
 To: Yair Zaslavsky yzasl...@redhat.com
 Cc: engine-devel engine-devel@ovirt.org
 Sent: Thursday, April 3, 2014 4:00:25 PM
 Subject: Re: [Engine-devel] vds_dynamic refactor

 - Original Message -
  From: Yair Zaslavsky yzasl...@redhat.com
  To: Liran Zelkha liran.zel...@gmail.com
  Cc: Gilad Chaplik gchap...@redhat.com, engine-devel
  engine-devel@ovirt.org
  Sent: Thursday, April 3, 2014 2:12:59 PM
  Subject: Re: [Engine-devel] vds_dynamic refactor

  - Original Message -
   From: Liran Zelkha liran.zel...@gmail.com
   To: Gilad Chaplik gchap...@redhat.com
   Cc: engine-devel engine-devel@ovirt.org
   Sent: Thursday, April 3, 2014 2:04:29 PM
   Subject: Re: [Engine-devel] vds_dynamic refactor

   Why not move it to vds_static?

  +1 on Liran's comment.

+1 as well , vds_static is the place for that

  I would prefer not to add more complexity to the  vds tables
  family.
  Such complexity may effect performs of queries/views.
  If you wish, you can create a view on top of vds_static named
vds_on_boot
  for
  querying of vds on boot info.

  Yair

 That means moving almost all of vds_dynamic into vds_static except of
memory,
 pending resources and status (maybe more but not much);
 and there will not be any db separation between user input and
  on_boot
data.

Why we should have such separation ?

 Thanks,
 Gilad.

   On Thu, Apr 3, 2014 at 2:00 PM, Gilad Chaplik 
  gchap...@redhat.com
   wrote:

Hi list,

I propose to split vds_dynamic table into 2 tables:
- vds_dynamic
- vds_on_boot
We need a place to put all non-dynamic data that gets updated
  once
the
host is booted, and I think dynamic isn't the place for it.
In first phase we will put there NUMA host topoplogy, but
  later on
migrate
all non-dynamic host data (cpu, os, etc.).

thoughts?

Thanks,
Gilad.
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

   ___
   Engine-devel mailing list
   Engine-devel@ovirt.org
   http://lists.ovirt.org/mailman/listinfo/engine-devel

 ___
 Engine-devel mailing list
 Engine-devel@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/engine-devel

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] NUMA support action items

2014-04-06 Thread Gilad Chaplik

- Original Message -
 From: Chegu Vinod chegu_vi...@hp.com
 To: Gilad Chaplik gchap...@redhat.com
 Cc: Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ) xiao-lei@hp.com, Einav 
 Cohen eco...@redhat.com, Shang-Chun
 Liang (David Liang, HPservers-Core-OE-PSC) shangchun.li...@hp.com, Chuan 
 Liao (Jason Liao,
 HPservers-Core-OE-PSC) chuan.l...@hp.com, msi...@redhat.com, Da-huai Tang 
 (Gary, MCXS-CQ)
 da-huai.t...@hp.com, Malini Rao m...@redhat.com, Eldan Hildesheim 
 ehild...@redhat.com, Doron Fediuck
 dfedi...@redhat.com, sher...@redhat.com, Alexander Wels 
 aw...@redhat.com, engine-devel
 engine-devel@ovirt.org
 Sent: Thursday, April 3, 2014 5:21:49 PM
 Subject: Re: NUMA support action items

 On 4/3/2014 7:11 AM, Gilad Chaplik wrote:
  - Original Message -
  From: Chegu Vinod chegu_vi...@hp.com
  To: Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ) xiao-lei@hp.com
  Cc: Einav Cohen eco...@redhat.com, Shang-Chun Liang (David Liang,
  HPservers-Core-OE-PSC)
  shangchun.li...@hp.com, Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)
  chuan.l...@hp.com, msi...@redhat.com,
  Da-huai Tang (Gary, MCXS-CQ) da-huai.t...@hp.com, Malini Rao
  m...@redhat.com, Eldan Hildesheim
  ehild...@redhat.com, Doron Fediuck dfedi...@redhat.com,
  sher...@redhat.com, Alexander Wels
  aw...@redhat.com, Gilad Chaplik gchap...@redhat.com
  Sent: Thursday, April 3, 2014 3:28:03 PM
  Subject: RE: NUMA support action items

  Hi Bruce,

  The virtual NUMA layout in the guest is a very simple one (not multi-level
  etc). It is generated by qemu+seabios... and there is no relationship with
  the host NUMA node distances etc.  Let us not worry about gathering
  Virtual
  NUMA node distances for now.

  Vinod

  CC'ing devel list as well.

  Having said that, I don't see a reason why not to prepare an infrastructure
  for that (if it's free) for future versions (guest agent will collect
  vNuma data in some point in time).

 If you think having this Virtual NUMA topology (along with the virtual
 numa node *distance* info.) really helps some future use cases then pl.
 go ahead...

 Vinod

I really don't know. but IMO, me as a user that gets some machine (transparent 
to the fact it's VM or bare metal), it would be very nice to see the NUMA stats 
outside of the machine.

Thanks, 
Gilad.

  Thanks,
  Gilad.

  -Original Message-
  From: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
  Sent: Thursday, April 03, 2014 12:41 AM
  To: Vinod, Chegu
  Cc: Einav Cohen; Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC);
  Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); msi...@redhat.com; Tang,
  Da-huai (Gary, MCXS-CQ); Malini Rao; Eldan Hildesheim; Doron Fediuck;
  sher...@redhat.com; Alexander Wels; Gilad Chaplik
  Subject: RE: NUMA support action items

  Hi Vinod,

  Is it meaningful for us to collect the distance information of vm numa
  node
  (maybe in future, not now)?
  In my understanding, vm numa topology is a simulation of numa topology,
  since
  the vcpus are just threads, I don't know how the vm numa node distances
  are
  calculated in vm. Is there any relationship between the vNode distances
  and
  host node distances?

  Thanks  Best Regards
  Shi, Xiao-Lei (Bruce)

  Hewlett-Packard Co., Ltd.
  HP Servers Core Platform Software China Telephone +86 23 65683093 Mobile
  +86
  18696583447 Email xiao-lei@hp.com

  -Original Message-
  From: Vinod, Chegu
  Sent: Thursday, April 03, 2014 7:18 AM
  To: Gilad Chaplik
  Cc: Einav Cohen; Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC);
  Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); msi...@redhat.com; Shi,
  Xiao-Lei (Bruce, HP Servers-PSC-CQ); Tang, Da-huai (Gary, MCXS-CQ); Malini
  Rao; Eldan Hildesheim; Doron Fediuck; sher...@redhat.com; Alexander Wels
  Subject: RE: NUMA support action items

  Not sure what the correct way to do this isbut here is a suggestion.

  Let a given host server diagram shown be very generic...i.e. show the N
  sockets/nodes numbered from 0 thru N-1.  Show the amount of memory and the
  list of CPUs in each of those sockets/nodes.
  Draw a generic Interconnect fabric [box] in between which all the sockets
  connect to

  Ideally ... Under that host diagram we could show the NUMA node distances
  in
  text format (as you know this is derived from the numactl -H and then
  conveyed from VDSM- oVIrt engine etc).
  That distance info. will tell the user what the distance between a pair of
  sockets/nodes are (and they can then do what they wish after that :)).

  Vinod

  -Original Message-
  From: Gilad Chaplik [mailto:gchap...@redhat.com]
  Sent: Wednesday, April 02, 2014 4:09 PM
  To: Vinod, Chegu
  Cc: Einav Cohen; Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC);
  Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); msi...@redhat.com; Shi,
  Xiao-Lei (Bruce, HP Servers-PSC-CQ); Tang, Da-huai (Gary, MCXS-CQ); Malini
  Rao; Eldan Hildesheim; Doron Fediuck; sher...@redhat.com

Re: [Engine-devel] vds_dynamic refactor

2014-04-06 Thread Gilad Chaplik

 From: Liran Zelkha liran.zel...@gmail.com
 To: Gilad Chaplik gchap...@redhat.com
 Cc: Omer Frenkel ofren...@redhat.com, Eli Mesika emes...@redhat.com,
 engine-devel engine-devel@ovirt.org
 Sent: Thursday, April 3, 2014 5:27:56 PM
 Subject: Re: [Engine-devel] vds_dynamic refactor

 True but that's no reason to have a bad schema
I'm open to new ideas and truly want to understand what is bad? 

 On Apr 3, 2014 5:18 PM, Gilad Chaplik  gchap...@redhat.com  wrote:

  - Original Message -
 
   From: Liran Zelkha  liran.zel...@gmail.com 
 
   To: Gilad Chaplik  gchap...@redhat.com 
 
   Cc: Eli Mesika  emes...@redhat.com , engine-devel 
   engine-devel@ovirt.org 
 
   Sent: Thursday, April 3, 2014 5:16:51 PM
 
   Subject: Re: [Engine-devel] vds_dynamic refactor
 
  
 
   Don't go down that road. Status shouldn't be saved in the db.
 
   But anyway statistics is rapidly changing. So it fits...
 

  First let's have a notion of caching, then notion of shared caching, then I
  can start thinking of not going down that road...
 

   On Apr 3, 2014 5:14 PM, Gilad Chaplik  gchap...@redhat.com  wrote:
 
  
 
- Original Message -
 
 From: Liran Zelkha  liran.zel...@gmail.com 
 
 To: Eli Mesika  emes...@redhat.com 
 
 Cc: Gilad Chaplik  gchap...@redhat.com , engine-devel 
 
engine-devel@ovirt.org 
 
 Sent: Thursday, April 3, 2014 4:36:07 PM
 
 Subject: Re: [Engine-devel] vds_dynamic refactor
 

 
 I would be happy if we can lose vds_dynamic all together, and just
 keep
 
 vds_static and vds_statistics. Our performance will be happy too ;-)
 

 
   
 
@Liran, status and pending fields are very fragile ones, IMO need
separate
 
table.
 
@Eli, iirc, you don't have a problem with adding more tables :-)
 
   
 

 
 On Thu, Apr 3, 2014 at 4:33 PM, Eli Mesika  emes...@redhat.com 
 wrote:
 

 
 
 
 
 
  - Original Message -
 
   From: Gilad Chaplik  gchap...@redhat.com 
 
   To: Yair Zaslavsky  yzasl...@redhat.com 
 
   Cc: engine-devel  engine-devel@ovirt.org 
 
   Sent: Thursday, April 3, 2014 4:00:25 PM
 
   Subject: Re: [Engine-devel] vds_dynamic refactor
 
  
 
   - Original Message -
 
From: Yair Zaslavsky  yzasl...@redhat.com 
 
To: Liran Zelkha  liran.zel...@gmail.com 
 
Cc: Gilad Chaplik  gchap...@redhat.com , engine-devel
 
 engine-devel@ovirt.org 
 
Sent: Thursday, April 3, 2014 2:12:59 PM
 
Subject: Re: [Engine-devel] vds_dynamic refactor
 
   
 
   
 
   
 
- Original Message -
 
 From: Liran Zelkha  liran.zel...@gmail.com 
 
 To: Gilad Chaplik  gchap...@redhat.com 
 
 Cc: engine-devel  engine-devel@ovirt.org 
 
 Sent: Thursday, April 3, 2014 2:04:29 PM
 
 Subject: Re: [Engine-devel] vds_dynamic refactor
 

 
 Why not move it to vds_static?
 
   
 
+1 on Liran's comment.
 
 
 
  +1 as well , vds_static is the place for that
 
 
 
I would prefer not to add more complexity to the vds tables
 
family.
 
Such complexity may effect performs of queries/views.
 
If you wish, you can create a view on top of vds_static named
 
  vds_on_boot
 
for
 
querying of vds on boot info.
 
   
 
Yair
 
  
 
   That means moving almost all of vds_dynamic into vds_static
   except
   of
 
  memory,
 
   pending resources and status (maybe more but not much);
 
   and there will not be any db separation between user input and
 
on_boot
 
  data.
 
 
 
  Why we should have such separation ?
 
 
 
  
 
   Thanks,
 
   Gilad.
 
  
 
   
 

 

 
 On Thu, Apr 3, 2014 at 2:00 PM, Gilad Chaplik 
 
gchap...@redhat.com 
 
 wrote:
 

 
  Hi list,
 
 
 
  I propose to split vds_dynamic table into 2 tables:
 
  - vds_dynamic
 
  - vds_on_boot
 
  We need a place to put all non-dynamic data that gets
  updated
 
once
 
  the
 
  host is booted, and I think dynamic isn't the place for it.
 
  In first phase we will put there NUMA host topoplogy, but
 
later on
 
  migrate
 
  all non-dynamic host data (cpu, os, etc.).
 
 
 
  thoughts?
 
 
 
  Thanks,
 
  Gilad.
 
  ___
 
  Engine-devel mailing list
 
  Engine-devel@ovirt.org
 
  http://lists.ovirt.org/mailman/listinfo/engine-devel
 
 
 

 
 ___
 
 Engine-devel mailing list
 
 Engine-devel@ovirt.org
 
 http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Devel] NUMA Support - GUI Technical Session

2014-04-06 Thread Gilad Chaplik

[top posting]

Thanks you Vojtech for the elaborate expatiation, I will follow on that and
keep you all posted.

Thanks,
Gilad.

- Original Message -
From: Vojtech Szocs vsz...@redhat.com
To: Gilad Chaplik gchap...@redhat.com
Cc: devel@ovirt.org, chegu vinod chegu_vi...@hp.com, aw...@redhat.com
Sent: Saturday, April 5, 2014 12:08:09 AM
Subject: Re: [Devel] NUMA Support - GUI Technical Session

Forgot to send some references on the matter:

https://groups.google.com/forum/#!topic/google-web-toolkit/q0JUtbiUR8g

http://stackoverflow.com/questions/13681541/best-way-to-implement-a-drag-and-drop-list-in-gwt

Regards,
Vojtech

- Original Message -
From: Vojtech Szocs vsz...@redhat.com
To: aw...@redhat.com
Cc: devel@ovirt.org, chegu vinod chegu_vi...@hp.com
Sent: Friday, April 4, 2014 11:06:16 PM
Subject: Re: [Devel] NUMA Support - GUI Technical Session

Hi Gilad,

to my understanding, we already use _HTML5_ Drag'n'Drop support
(exposed by GWT API since 2.4) in Setup Host Networks dialog.

To utilize HTML5 Drag'n'Drop support in GWT widget, just extend
FocusPanel and mark your widget's DOM element as draggable.

For example, in UnassignedNetworksPanel constructor:

getElement().setDraggable( ... );
addBitlessDomHandler(new DragEnterHandler() { ... });
addBitlessDomHandler(new DragOverHandler() { ... });
addBitlessDomHandler(new DragLeaveHandler() { ... });
addBitlessDomHandler(new DropHandler() { ... });

In other words, GWT already exposes API for working with HTML5
Drag'n'Drop spec, so you don't need any 3rd party libraries.
The downside is that HTML5 Drag'n'Drop spec is supported only
in recent browsers (but this isn't an issue for us, AFAIK):

http://caniuse.com/#feat=dragndrop

So in general we have two alternatives:

1, use standard HTML5 Drag'n'Drop spec

pros:
+ no need for 3rd party library
+ compliant with existing code, i.e. Setup Host Networks

cons (not too relevant IMHO):
- requires browser support of HTML5 Drag'n'Drop spec
- HTML5 Drag'n'Drop spec deals with dragging data, not widgets
themselves (no HTML DOM re-parenting after drag finish)

2, use 3rd party gwt-dnd library

pros (which I don't think we really need):
+ emulate Drag'n'Drop support in older browsers
+ more advanced functionality, i.e. allows dragging widgets
so that HTML DOM is dynamically updated

cons:
- dependency on 3rd party library
- this would mean we need to revisit existing code
(we should do Drag'n'Drop in one consistent way)

It's possible that I might be missing something, but I'd
suggest to try using HTML5 Drag'n'Drop via GWT API as the
first approach.

If we find out that HTML5 Drag'n'Drop doesn't work for us
in given browser(s) or if we need extra functionality, we
can always add gwt-dnd dependency.

Few more comments inline, let me know what you think.

Regards,
Vojtech

- Original Message -
From: Alexander Wels aw...@redhat.com
To: Gilad Chaplik gchap...@redhat.com
Cc: eco...@redhat.com, Vojtech Szocs vsz...@redhat.com,
dfedi...@redhat.com, engine-de...@ovirt.org, chegu
vinod chegu_vi...@hp.com, lver...@redhat.com
Sent: Tuesday, April 1, 2014 7:24:12 PM
Subject: Re: NUMA Support - GUI Technical Session

On Tuesday, April 01, 2014 11:34:43 AM Gilad Chaplik wrote:
Hi all,

Here are the resolutions from the meeting:

* option 1
1) Use gwt-dnd lib for oVirt's dnd (drag and drop) infrastructure.
2) Come up with a very simple POC that covers all of NUMA-support UX
requirements. 3) Either do a POC, or get UX maintainers approval, that
moving already existing dnd features to new infrastructure
(setup-networks
and scheduling policy dialogs) is feasible and possible.

+1 for option 1. None of the drag and drop in the application now looks
terribly hard. The gwt-dnd library simply makes things easier to control
and
maintain.

Yeah, but the downside is adding 3rd party dependency which predates GWT's
support for (API exposure of) HTML5 Drag'n'Drop spec.

* option 2
Extract setup network dnd capabilities to a common general
infrastructure
and use that as an infrastructure. NOTE that setup-networks will not
use
it
in oVirt-3.5.

GWT's HTML5 Drag'n'Drop API works directly on DOM element level, it's just
a thin API overlay on top of HTML5Drag'n'Drop spec.

Do we really need custom DnD infra on top of that? Can't we just use GWT
APIs like Element.setDraggable, Drag*Handler, Drop*Handler?

I will start with option 1, just need UX team approval that [1] will be
added to ovirt-3.5, and be used for dnd for now on. In case I fail to
deliver option 1 (with the help and guidance of the UX team

Re: [Devel] [Engine-devel] vds_dynamic refactor

2014-04-06 Thread Gilad Chaplik

- Original Message -
 From: Itamar Heim ih...@redhat.com
 To: Liran Zelkha liran.zel...@gmail.com
 Cc: Gilad Chaplik gchap...@redhat.com, de...@linode01.ovirt.org, 
 engine-devel engine-de...@ovirt.org
 Sent: Sunday, April 6, 2014 11:33:12 AM
 Subject: Re: [Engine-devel] vds_dynamic refactor

 On 04/06/2014 11:32 AM, Liran Zelkha wrote:

  On Sun, Apr 6, 2014 at 11:22 AM, Itamar Heim ih...@redhat.com
  mailto:ih...@redhat.com wrote:

  On 04/03/2014 07:51 PM, Liran Zelkha wrote:

  The problem is with both updates and selects.
  For selects - to get all the information for the VDS we have
  multiple
  joins. Adding another one will hurt performance even more.
  For updates - we have vds_static thats hardly changed.
  vds_statistics
  that changes all the time. vds_dynamic is not changed allot - but
  is
  updated all the time because of the status. I think it's best to
  split
  it to the two existing tables (BTW - relevant for VM as well)

  but we don't update it unless the status has changed, which is a
  rare occurance?

  Actually - no. We can definitely see times we are updating vds_dynamic
  with no reason at all. I tried to create patches for that - but it
  happens from many different places in the code.

 what would be updated vds_dyanmic for status not originating in update
 run time info?

We have separate DB flows for that (updateStatus and 
updatePartialVdsDynamicCalc and more in VdsDynamicDAODbFacadeImpl).
A question: do you know if we update status in updateVdsDynamic? :-) not sure 
but I found a possible race for pending resources (cpu, mem), LOL :-)

Still holds my original thought for having vds_on_boot.

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [Devel] [Engine-devel] vds_dynamic refactor

2014-04-06 Thread Gilad Chaplik

- Original Message -
 From: Liran Zelkha liran.zel...@gmail.com
 To: Gilad Chaplik gchap...@redhat.com
 Cc: Itamar Heim ih...@redhat.com, de...@linode01.ovirt.org, 
 engine-devel engine-de...@ovirt.org
 Sent: Sunday, April 6, 2014 3:26:24 PM
 Subject: Re: [Engine-devel] vds_dynamic refactor

 On Sun, Apr 6, 2014 at 3:18 PM, Gilad Chaplik gchap...@redhat.com wrote:

  - Original Message -
   From: Itamar Heim ih...@redhat.com
   To: Liran Zelkha liran.zel...@gmail.com
   Cc: Gilad Chaplik gchap...@redhat.com, de...@linode01.ovirt.org,
  engine-devel engine-de...@ovirt.org
   Sent: Sunday, April 6, 2014 11:33:12 AM
   Subject: Re: [Engine-devel] vds_dynamic refactor

   On 04/06/2014 11:32 AM, Liran Zelkha wrote:

On Sun, Apr 6, 2014 at 11:22 AM, Itamar Heim ih...@redhat.com
mailto:ih...@redhat.com wrote:

On 04/03/2014 07:51 PM, Liran Zelkha wrote:

The problem is with both updates and selects.
For selects - to get all the information for the VDS we have
multiple
joins. Adding another one will hurt performance even more.
For updates - we have vds_static thats hardly changed.
vds_statistics
that changes all the time. vds_dynamic is not changed allot -
  but
is
updated all the time because of the status. I think it's best
  to
split
it to the two existing tables (BTW - relevant for VM as well)

but we don't update it unless the status has changed, which is a
rare occurance?

Actually - no. We can definitely see times we are updating vds_dynamic
with no reason at all. I tried to create patches for that - but it
happens from many different places in the code.

   what would be updated vds_dyanmic for status not originating in update
   run time info?

  We have separate DB flows for that (updateStatus and
  updatePartialVdsDynamicCalc and more in VdsDynamicDAODbFacadeImpl).
  A question: do you know if we update status in updateVdsDynamic? :-) not
  sure but I found a possible race for pending resources (cpu, mem), LOL :-)

  I think we do but not sure. Will check.

Of course it is, that was a rhetorical question :-) (a lot of emoticons and 
LOLs ;-))

  Still holds my original thought for having vds_on_boot.

 Let's talk f2f on Tuesday?

I'd prefer to reach conclusions here, I'd like everyone to be involved in a 
root issue like this one.

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [Devel] [Engine-devel] vds_dynamic refactor

2014-04-06 Thread Gilad Chaplik

- Original Message -
 From: Liran Zelkha liran.zel...@gmail.com
 To: Gilad Chaplik gchap...@redhat.com
 Cc: Kobi Ianko k...@redhat.com, de...@linode01.ovirt.org, engine-devel 
 engine-de...@ovirt.org
 Sent: Sunday, April 6, 2014 8:51:02 PM
 Subject: Re: [Devel] [Engine-devel] vds_dynamic refactor

 On Sun, Apr 6, 2014 at 6:32 PM, Gilad Chaplik gchap...@redhat.com wrote:

  - Original Message -
   From: Liran Zelkha liran.zel...@gmail.com
   To: Kobi Ianko k...@redhat.com
   Cc: Gilad Chaplik gchap...@redhat.com, de...@linode01.ovirt.org,
  engine-devel engine-de...@ovirt.org
   Sent: Sunday, April 6, 2014 3:40:13 PM
   Subject: Re: [Devel] [Engine-devel] vds_dynamic refactor

   On Sun, Apr 6, 2014 at 3:37 PM, Kobi Ianko k...@redhat.com wrote:

Joining in...
From my point of view, in real life a user should have that many VDSs
  on
one Engine (from a DB point of view).
Modern DB system handles tables with millions of records and many
relations, Do we really have a performance issue here?
We could prefer a more easy to maintain implantation in this case over
  DB
performance

Yes we do. We make many queries on the VDS view, which is a VERY
  complex
   view.

  Actually I quite agree with Kobi, what is the plan for VMs? why do we
  start with VDS...
  what is the biggest deploy do you know of?

 We start with VDS because in an idle system, with 200 hosts and several
 thousands VMs, this is what you get as the top queries against the
 database. Look at how many times getvds is called.
 [image: Inline image 1]
 BTW - the second query is an example of abusing the dynamic query
 mechanism. The 4th query (an update command) is a set of useless
 update_vds_dynamic commands.

 For reference, the explain plan of get VDS is something like this:

 QUERY PLAN

 ---
  Nested Loop  (cost=9.30..46.75 rows=6 width=9060) (actual
 time=0.063..0.068 rows=1 loops=1)
Join Filter: (vds_static.vds_id = vds_statistics.vds_id)
-  Seq Scan on vds_statistics  (cost=0.00..1.01 rows=1 width=109)
 (actual time=0.008..0.008 rows=1 loops=1)
-  Nested Loop  (cost=9.30..45.64 rows=6 width=8983) (actual
 time=0.048..0.052 rows=1 loops=1)
  Join Filter: (vds_groups.vds_group_id = vds_static.vds_group_id)
  -  Nested Loop Left Join  (cost=0.00..9.29 rows=1 width=1389)
 (actual time=0.013..0.013 rows=1 loops=1)
-  Seq Scan on vds_groups  (cost=0.00..1.01 rows=1
 width=1271) (actual time=0.003..0.003 rows=1 loops=1)
-  Index Scan using pk_storage_pool on storage_pool
  (cost=0.00..8.27 rows=1 width=134) (actual time=0.008..0.008 rows=1
 loops=1)
  Index Cond: (vds_groups.storage_pool_id = id)
  -  Hash Right Join  (cost=9.30..36.28 rows=6 width=7610) (actual
 time=0.033..0.037 rows=1 loops=1)
Hash Cond: (vds_spm_id_map.vds_id = vds_static.vds_id)
-  Seq Scan on vds_spm_id_map  (cost=0.00..22.30 rows=1230
 width=20) (actual time=0.003..0.003 rows=1 loops=1)
-  Hash  (cost=9.29..9.29 rows=1 width=7606) (actual
 time=0.019..0.019 rows=1 loops=1)
  Buckets: 1024  Batches: 1  Memory Usage: 2kB
  -  Nested Loop  (cost=0.00..9.29 rows=1 width=7606)
 (actual time=0.012..0.013 rows=1 loops=1)
-  Seq Scan on vds_dynamic  (cost=0.00..1.01
 rows=1 width=1895) (actual time=0.006..0.006 rows=1 loops=1)
-  Index Scan using pk_vds_static on vds_static
  (cost=0.00..8.27 rows=1 width=5711) (actual time=0.005..0.006 rows=1
 loops=1)
  Index Cond: (vds_id = vds_dynamic.vds_id)
  Total runtime: 0.299 ms
 (19 rows)

 It's terrible. Adding any additional join will make this worse. Please
 don't add any more tables...

Thank you for the detailed explanation, my comments:

* a very long time isn't an argument for not adding another table (should be 
neglectable);
currently we have an unrelated problem, we need to solve it.

*  We start with VDS because in an idle system, with 200 hosts and several
 thousands VMs, this is what you get as the top queries against the
 database.

so, if fetching VMs takes 10 minutes? and its get called a single time?

* you didn't reply on my of my suggestion of constructing the VDS records in 
the DB without using joins.

- Original Message -
 From: Gilad Chaplik gchap...@redhat.com
 To: Liran Zelkha liran.zel...@gmail.com
 Cc: de...@linode01.ovirt.org, engine-devel engine-de...@ovirt.org

 Sent: Sunday, April 6, 2014 3:32:26 PM
 Subject: Re: [Devel] [Engine-devel] vds_dynamic refactor

 - Original Message -
  From: Liran Zelkha liran.zel...@gmail.com
  To: Gilad Chaplik gchap...@redhat.com

Re: [Engine-devel] Please help us to review our database schema design with NUMA feature on ovirt

2014-04-03 Thread Gilad Chaplik

- Original Message -
 From: Eli Mesika emes...@redhat.com
 To: Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ) xiao-lei@hp.com
 Cc: Gilad Chaplik gchap...@redhat.com, Roy Golan rgo...@redhat.com, 
 Omer Frenkel ofren...@redhat.com,
 Chegu Vinod chegu_vi...@hp.com, Chuan Liao (Jason Liao, 
 HPservers-Core-OE-PSC) chuan.l...@hp.com, Doron
 Fediuck dfedi...@redhat.com, Shang-Chun Liang (David Liang, 
 HPservers-Core-OE-PSC) shangchun.li...@hp.com,
 Yaniv Dary yd...@redhat.com, engine-devel@ovirt.org
 Sent: Thursday, April 3, 2014 10:54:54 AM
 Subject: Re: Please help us to review our database schema design with NUMA 
 feature on ovirt

 - Original Message -
  From: Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ) xiao-lei@hp.com
  To: Gilad Chaplik gchap...@redhat.com, Eli Mesika
  emes...@redhat.com
  Cc: Roy Golan rgo...@redhat.com, Omer Frenkel ofren...@redhat.com,
  Chegu Vinod chegu_vi...@hp.com, Chuan
  Liao (Jason Liao, HPservers-Core-OE-PSC) chuan.l...@hp.com, Doron
  Fediuck dfedi...@redhat.com, Shang-Chun
  Liang (David Liang, HPservers-Core-OE-PSC) shangchun.li...@hp.com,
  Yaniv Dary yd...@redhat.com,
  engine-devel@ovirt.org
  Sent: Thursday, April 3, 2014 7:25:11 AM
  Subject: RE: Please help us to review our database schema design with NUMA
  feature on ovirt

  Hi all,
  Please see my comments in line.

  Thanks  Best Regards
  Shi, Xiao-Lei (Bruce)

  Hewlett-Packard Co., Ltd.
  HP Servers Core Platform Software China
  Telephone +86 23 65683093
  Mobile +86 18696583447
  Email xiao-lei@hp.com

  -Original Message-
  From: Gilad Chaplik [mailto:gchap...@redhat.com]
  Sent: Thursday, April 03, 2014 9:05 AM
  To: Eli Mesika
  Cc: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ); Roy Golan; Omer Frenkel;
  Vinod,
  Chegu; Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron Fediuck;
  Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC); Yaniv Dary;
  engine-devel@ovirt.org
  Subject: Re: Please help us to review our database schema design with NUMA
  feature on ovirt

  Hi all,
  Sorry for joining-in late.

  My comments (according to the db diagram section in
  https://docs.google.com/document/d/1-wdDkm6EDbwyoCIRPPcmbGWAcyQo_ISTY8ykDr0I6VY):
  1) Join vm_numa_node and vds_numa_node to a single table (almost
  identical),
  one of the FKs can be null.
  [Bruce] I prefer two tables. Actually host level NUMA node and vm level
  NUMA
  node are different objects. In my understanding, vm level NUMA node is just
  a simulation of host level NUMA node, and host level NUMA node has more
  features that not in vm NUMA (like several levels of host NUMA topology
  mentioned by Vinod). We need to consider the extensions of host NUMA in the
  future.

Let's open the discussion and consider them right now. vNode and Node are the 
same.
Vinod?

 I agree with Bruce, we have no problem with more tables and constrains should
 work as expected and remove entries when a Host or VM is removed.
 I do not like tables that have 2 UUIDs when one of them is null , this is
 against simple DB normalization

We are going to maintain and develop this feature. there is a huge overhead in 
6 table design in compare to 4.

  2) No templates reference in the design, need to check it out (it might be
  inherently designed already :-) ); vNode can be linked to a template.
  [Bruce] IMO, we can consider template as a special vm, our current design
  supports to create vNodes in a template just like what it does in a vm.

 We also store today templates in the VM* tables as special entities defined
 by the entity_type column

+1, just need to see that this is taken care of.

  3) The reason I want host's NUMA data to be in static is because it updates
  only once (on boot). engineerically speaking, dynamic table has a lot of
  traffic and that's not the case for NUMA info. Its feels to me like 'a
  hybrid' of static and dynamic, 3 suggestions comes to mind:
   - leave it in dynamic (maybe in a separate process).
   - have a separate flow that updates static.
   - come up with a third 'vds_on_boot' table (my favorite ;-P ).
  I will get back to you on that.
  [Bruce] From the onTimer codes in vdsManager (IMO it's the scheduled vds
  refresh action), when vds is in normal running status (up status), only
  statistics data will be refreshed, so I think maybe dynamic table doesn't
  have so much traffic, and the varied data (I mean the data varied through a
  power reload, like cpu topology, numa topology, ...etc) can be refreshed
  meanwhile.

I beg to differ, dynamic table contains a lot of dynamic data:
host status, used memory and pending resources (maybe more).
still need to think about it, and get back to you.

  4) vm_vds_numa_node_map is connected to vds_numa_node_statistics, why to
  split the tables (vds_numa_node  vds_numa_node_statistics), going back to
  comment #1, don't we want vNode stats as well, it can be nice to show it
  :-)
  (have a vNUMA overview of the VM using

[Engine-devel] vds_dynamic refactor

2014-04-03 Thread Gilad Chaplik

Hi list,

I propose to split vds_dynamic table into 2 tables:
- vds_dynamic
- vds_on_boot
We need a place to put all non-dynamic data that gets updated once the host is 
booted, and I think dynamic isn't the place for it.
In first phase we will put there NUMA host topoplogy, but later on migrate all 
non-dynamic host data (cpu, os, etc.).

thoughts?

Thanks, 
Gilad.
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] vds_dynamic refactor

2014-04-03 Thread Gilad Chaplik

- Original Message -
 From: Yair Zaslavsky yzasl...@redhat.com
 To: Liran Zelkha liran.zel...@gmail.com
 Cc: Gilad Chaplik gchap...@redhat.com, engine-devel 
 engine-devel@ovirt.org
 Sent: Thursday, April 3, 2014 2:12:59 PM
 Subject: Re: [Engine-devel] vds_dynamic refactor
 
 
 
 - Original Message -
  From: Liran Zelkha liran.zel...@gmail.com
  To: Gilad Chaplik gchap...@redhat.com
  Cc: engine-devel engine-devel@ovirt.org
  Sent: Thursday, April 3, 2014 2:04:29 PM
  Subject: Re: [Engine-devel] vds_dynamic refactor
  
  Why not move it to vds_static?
 
 +1 on Liran's comment.
 I would prefer not to add more complexity to the  vds tables family.
 Such complexity may effect performs of queries/views.
 If you wish, you can create a view on top of vds_static named vds_on_boot for
 querying of vds on boot info.
 
 Yair

That means moving almost all of vds_dynamic into vds_static except of memory, 
pending resources and status (maybe more but not much);
and there will not be any db separation between user input and on_boot data.

Thanks, 
Gilad.

 
  
  
  On Thu, Apr 3, 2014 at 2:00 PM, Gilad Chaplik gchap...@redhat.com wrote:
  
   Hi list,
  
   I propose to split vds_dynamic table into 2 tables:
   - vds_dynamic
   - vds_on_boot
   We need a place to put all non-dynamic data that gets updated once the
   host is booted, and I think dynamic isn't the place for it.
   In first phase we will put there NUMA host topoplogy, but later on
   migrate
   all non-dynamic host data (cpu, os, etc.).
  
   thoughts?
  
   Thanks,
   Gilad.
   ___
   Engine-devel mailing list
   Engine-devel@ovirt.org
   http://lists.ovirt.org/mailman/listinfo/engine-devel
  
  
  ___
  Engine-devel mailing list
  Engine-devel@ovirt.org
  http://lists.ovirt.org/mailman/listinfo/engine-devel
  
 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

[Engine-devel] 3.5 SLA features overview

2014-04-02 Thread Gilad Chaplik

BEGIN:VCALENDAR
PRODID:Zimbra-Calendar-Provider
VERSION:2.0
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:Asia/Jerusalem
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETTO:+0200
TZOFFSETFROM:+0300
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=10;BYDAY=-1SU
TZNAME:IST
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02
TZOFFSETTO:+0300
TZOFFSETFROM:+0200
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=-1FR
TZNAME:IDT
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:e470bc9a-7ef5-4d8e-ae8d-3ad6345764cf
SUMMARY:3.5 SLA features overview
ATTENDEE;CN=Martin Sivak;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRU
 E:mailto:msi...@redhat.com
ATTENDEE;CN=Jiri Moskovcak;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=T
 RUE:mailto:jmosk...@redhat.com
ATTENDEE;CN=Kobi Ianku;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:
 mailto:kia...@redhat.com
ATTENDEE;CN=Doron Fediuck;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TR
 UE:mailto:dfedi...@redhat.com
ATTENDEE;CN=Scott Herold;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRU
 E:mailto:sher...@redhat.com
ATTENDEE;CN=engine-devel;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRU
 E:mailto:engine-devel@ovirt.org
ORGANIZER;CN=Gilad Chaplik:mailto:gchap...@redhat.com
DTSTART;TZID=Asia/Jerusalem:20140408T17
DTEND;TZID=Asia/Jerusalem:20140408T18
STATUS:CONFIRMED
CLASS:PUBLIC
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
TRANSP:OPAQUE
LAST-MODIFIED:20140402T170030Z
DTSTAMP:20140402T170030Z
SEQUENCE:1
DESCRIPTION:The following is a new meeting request:\n\nSubject: 3.5 SLA feat
 ures overview \nOrganizer: Gilad Chaplik gchap...@redhat.com \n\nTime: T
 uesday\, April 8\, 2014\, 5:00:00 PM - 6:00:00 PM GMT +02:00 Jerusalem\n \nR
 equired: msi...@redhat.com\; jmosk...@redhat.com\; kia...@redhat.com \nOptio
 nal: dfedi...@redhat.com\; sher...@redhat.com\; engine-devel@ovirt.org \n\n*
 ~*~*~*~*~*~*~*~*~*\n\nHi all\, \n\nWe will present SLA features for version 
 3.5:\n\nTimeline:\n* Opta planner integration\, Martin\, 10min\n* Hosted Eng
 ine on SAN support\, Jirka\, 10min\n* CPU limits\, Kobi\, 10min\n* NUMA inte
 gration\, 10min\n* blkio limits\, Gilad\, 10min\n* QA\, rest of time\n\nDia
 l in:\nhttps://www.intercallonline.com/listNumbersByCode.action?confCode=712
 8867405 \nconf id: 972 545 636 785# \n\nSee you there\, \nGilad.\n
BEGIN:VALARM
ACTION:DISPLAY
TRIGGER;RELATED=START:-PT5M
DESCRIPTION:Reminder
END:VALARM
END:VEVENT
END:VCALENDAR___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Numa feature entities patch

2014-04-01 Thread Gilad Chaplik

Great to hear :-)

VdcQueryType and VdcActionType with parameters are not part of the initial BE 
patch; should part of the server's queries and commands patch.



Thanks, 
Gilad.


- Original Message -
 From: Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC) 
 shangchun.li...@hp.com
 To: Gilad Chaplik gchap...@redhat.com, Chuan Liao (Jason Liao, 
 HPservers-Core-OE-PSC) chuan.l...@hp.com
 Cc: Doron Fediuck dfedi...@redhat.com, Chegu Vinod 
 chegu_vi...@hp.com, Martin Sivak msi...@redhat.com,
 Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ) xiao-lei@hp.com, 
 engine-devel@ovirt.org, Roy Golan
 rgo...@redhat.com
 Sent: Tuesday, April 1, 2014 3:38:20 AM
 Subject: RE: Numa feature entities patch
 
 Hi Gilad,
 The below are our understanding. Please correct me if anything wrong. :)
 For VdcQueryType and VdcActionType with parameters, we think it's need to
 update in doc asap because the code of this part has not started yet.
 For other parts that started the coding, We will reach an agreement in
 gerrit/review and then update in the docs accordingly.
 
 Best Regards,
 David Liang
 
 -Original Message-
 From: Gilad Chaplik [mailto:gchap...@redhat.com]
 Sent: Tuesday, April 01, 2014 1:05 AM
 To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC)
 Cc: Doron Fediuck; Vinod, Chegu; Martin Sivak; Shi, Xiao-Lei (Bruce, HP
 Servers-PSC-CQ); Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC);
 engine-devel@ovirt.org; Roy Golan
 Subject: Re: Numa feature entities patch
 
 Hi Jason,
 
 Please reply on the comments in the patch.
 Once the code is written I think it's better not to context switch back to
 the design.
 we will reach an agreement in gerrit/review and then update the design
 respectively.
 
 
 Thanks,
 Gilad.
 
 - Original Message -
  From: Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)
  chuan.l...@hp.com
  To: Gilad Chaplik gchap...@redhat.com
  Cc: Doron Fediuck dfedi...@redhat.com, Chegu Vinod
  chegu_vi...@hp.com, Martin Sivak msi...@redhat.com, Xiao-Lei
  Shi (Bruce, HP Servers-PSC-CQ) xiao-lei@hp.com, Shang-Chun
  Liang (David Liang, HPservers-Core-OE-PSC) shangchun.li...@hp.com,
  engine-devel@ovirt.org
  Sent: Monday, March 31, 2014 7:48:28 PM
  Subject: RE: Numa feature entities patch
  
  Hi Gilad,
  
  I have update the wiki page design of BE patch 1. add VdcQueryType and
  VdcActionType with parameters.
  2. merge some of your comments and Eli's feedback.
  
  Please take a look at the section
  http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA#Interface
  _and_data_structure_in_engine_core
  
  We appreciate any of the comments from community, and sorry for the nag.
  
  Best Regards,
  Jason Liao
  
  -Original Message-
  From: Gilad Chaplik [mailto:gchap...@redhat.com]
  Sent: 2014年3月30日 22:43
  To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Shi, Xiao-Lei
  (Bruce, HP Servers-PSC-CQ); Liang, Shang-Chun (David Liang,
  HPservers-Core-OE-PSC)
  Cc: Doron Fediuck; Vinod, Chegu; Martin Sivak
  Subject: Numa feature entities patch
  
  Hi all,
  
  I had some comments :-) IMO this patch [1] has maximum priority.
  let's try to merge it ASAP, I will be very responsive to every new upload.
  
  Thanks,
  Gilad.
  
  [1] http://gerrit.ovirt.org/#/c/23702/
 
 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Numa feature entities patch

2014-04-01 Thread Gilad Chaplik

not yet it's on my TODO list :) we are still at the first patch...

Thanks, 
Gilad.


- Original Message -
 From: Chuan Liao (Jason Liao, HPservers-Core-OE-PSC) chuan.l...@hp.com
 To: Gilad Chaplik gchap...@redhat.com, Shang-Chun Liang (David Liang, 
 HPservers-Core-OE-PSC)
 shangchun.li...@hp.com
 Cc: Doron Fediuck dfedi...@redhat.com, Chegu Vinod 
 chegu_vi...@hp.com, Martin Sivak msi...@redhat.com,
 Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ) xiao-lei@hp.com, 
 engine-devel@ovirt.org, Roy Golan
 rgo...@redhat.com
 Sent: Tuesday, April 1, 2014 11:30:46 AM
 Subject: RE: Numa feature entities patch
 
 Hi Gilad,
 
 Did you see updated wiki page design with VdcQueryType, VdcActionType ?
 
 Feel free to let us know if you have any comment.
 
 Best Regards,
 Jason Liao
 
 -Original Message-
 From: Gilad Chaplik [mailto:gchap...@redhat.com]
 Sent: 2014年4月1日 15:51
 To: Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC)
 Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron Fediuck; Vinod,
 Chegu; Martin Sivak; Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ);
 engine-devel@ovirt.org; Roy Golan
 Subject: Re: Numa feature entities patch
 
 Great to hear :-)
 
 VdcQueryType and VdcActionType with parameters are not part of the initial BE
 patch; should part of the server's queries and commands patch.
 
 
 
 Thanks,
 Gilad.
 
 
 - Original Message -
  From: Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)
  shangchun.li...@hp.com
  To: Gilad Chaplik gchap...@redhat.com, Chuan Liao (Jason Liao,
  HPservers-Core-OE-PSC) chuan.l...@hp.com
  Cc: Doron Fediuck dfedi...@redhat.com, Chegu Vinod
  chegu_vi...@hp.com, Martin Sivak msi...@redhat.com,
  Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ) xiao-lei@hp.com,
  engine-devel@ovirt.org, Roy Golan
  rgo...@redhat.com
  Sent: Tuesday, April 1, 2014 3:38:20 AM
  Subject: RE: Numa feature entities patch
  
  Hi Gilad,
  The below are our understanding. Please correct me if anything wrong. :)
  For VdcQueryType and VdcActionType with parameters, we think it's need to
  update in doc asap because the code of this part has not started yet.
  For other parts that started the coding, We will reach an agreement in
  gerrit/review and then update in the docs accordingly.
  
  Best Regards,
  David Liang
  
  -Original Message-
  From: Gilad Chaplik [mailto:gchap...@redhat.com]
  Sent: Tuesday, April 01, 2014 1:05 AM
  To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC)
  Cc: Doron Fediuck; Vinod, Chegu; Martin Sivak; Shi, Xiao-Lei (Bruce, HP
  Servers-PSC-CQ); Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC);
  engine-devel@ovirt.org; Roy Golan
  Subject: Re: Numa feature entities patch
  
  Hi Jason,
  
  Please reply on the comments in the patch.
  Once the code is written I think it's better not to context switch back to
  the design.
  we will reach an agreement in gerrit/review and then update the design
  respectively.
  
  
  Thanks,
  Gilad.
  
  - Original Message -
   From: Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)
   chuan.l...@hp.com
   To: Gilad Chaplik gchap...@redhat.com
   Cc: Doron Fediuck dfedi...@redhat.com, Chegu Vinod
   chegu_vi...@hp.com, Martin Sivak msi...@redhat.com, Xiao-Lei
   Shi (Bruce, HP Servers-PSC-CQ) xiao-lei@hp.com, Shang-Chun
   Liang (David Liang, HPservers-Core-OE-PSC) shangchun.li...@hp.com,
   engine-devel@ovirt.org
   Sent: Monday, March 31, 2014 7:48:28 PM
   Subject: RE: Numa feature entities patch
   
   Hi Gilad,
   
   I have update the wiki page design of BE patch 1. add VdcQueryType and
   VdcActionType with parameters.
   2. merge some of your comments and Eli's feedback.
   
   Please take a look at the section
   http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA#Interface
   _and_data_structure_in_engine_core
   
   We appreciate any of the comments from community, and sorry for the nag.
   
   Best Regards,
   Jason Liao
   
   -Original Message-
   From: Gilad Chaplik [mailto:gchap...@redhat.com]
   Sent: 2014年3月30日 22:43
   To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Shi, Xiao-Lei
   (Bruce, HP Servers-PSC-CQ); Liang, Shang-Chun (David Liang,
   HPservers-Core-OE-PSC)
   Cc: Doron Fediuck; Vinod, Chegu; Martin Sivak
   Subject: Numa feature entities patch
   
   Hi all,
   
   I had some comments :-) IMO this patch [1] has maximum priority.
   let's try to merge it ASAP, I will be very responsive to every new
   upload.
   
   Thanks,
   Gilad.
   
   [1] http://gerrit.ovirt.org/#/c/23702/
  
  
 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Numa feature entities patch

2014-04-01 Thread Gilad Chaplik

just saw you've uploaded a new patch, but still no replies to comments in the 
body of the patch. please handle that ASAP before we do a second review.

Thanks, 
Gilad.

- Original Message -
 From: Gilad Chaplik gchap...@redhat.com
 To: Chuan Liao (Jason Liao, HPservers-Core-OE-PSC) chuan.l...@hp.com
 Cc: engine-devel@ovirt.org, Shang-Chun Liang (David Liang, 
 HPservers-Core-OE-PSC) shangchun.li...@hp.com, Chegu
 Vinod chegu_vi...@hp.com
 Sent: Tuesday, April 1, 2014 11:44:05 AM
 Subject: Re: [Engine-devel] Numa feature entities patch
 
 not yet it's on my TODO list :) we are still at the first patch...
 
 Thanks,
 Gilad.
 
 
 - Original Message -
  From: Chuan Liao (Jason Liao, HPservers-Core-OE-PSC) chuan.l...@hp.com
  To: Gilad Chaplik gchap...@redhat.com, Shang-Chun Liang (David Liang,
  HPservers-Core-OE-PSC)
  shangchun.li...@hp.com
  Cc: Doron Fediuck dfedi...@redhat.com, Chegu Vinod
  chegu_vi...@hp.com, Martin Sivak msi...@redhat.com,
  Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ) xiao-lei@hp.com,
  engine-devel@ovirt.org, Roy Golan
  rgo...@redhat.com
  Sent: Tuesday, April 1, 2014 11:30:46 AM
  Subject: RE: Numa feature entities patch
  
  Hi Gilad,
  
  Did you see updated wiki page design with VdcQueryType, VdcActionType ?
  
  Feel free to let us know if you have any comment.
  
  Best Regards,
  Jason Liao
  
  -Original Message-
  From: Gilad Chaplik [mailto:gchap...@redhat.com]
  Sent: 2014年4月1日 15:51
  To: Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC)
  Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron Fediuck; Vinod,
  Chegu; Martin Sivak; Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ);
  engine-devel@ovirt.org; Roy Golan
  Subject: Re: Numa feature entities patch
  
  Great to hear :-)
  
  VdcQueryType and VdcActionType with parameters are not part of the initial
  BE
  patch; should part of the server's queries and commands patch.
  
  
  
  Thanks,
  Gilad.
  
  
  - Original Message -
   From: Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)
   shangchun.li...@hp.com
   To: Gilad Chaplik gchap...@redhat.com, Chuan Liao (Jason Liao,
   HPservers-Core-OE-PSC) chuan.l...@hp.com
   Cc: Doron Fediuck dfedi...@redhat.com, Chegu Vinod
   chegu_vi...@hp.com, Martin Sivak msi...@redhat.com,
   Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ) xiao-lei@hp.com,
   engine-devel@ovirt.org, Roy Golan
   rgo...@redhat.com
   Sent: Tuesday, April 1, 2014 3:38:20 AM
   Subject: RE: Numa feature entities patch
   
   Hi Gilad,
   The below are our understanding. Please correct me if anything wrong. :)
   For VdcQueryType and VdcActionType with parameters, we think it's need to
   update in doc asap because the code of this part has not started yet.
   For other parts that started the coding, We will reach an agreement in
   gerrit/review and then update in the docs accordingly.
   
   Best Regards,
   David Liang
   
   -Original Message-
   From: Gilad Chaplik [mailto:gchap...@redhat.com]
   Sent: Tuesday, April 01, 2014 1:05 AM
   To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC)
   Cc: Doron Fediuck; Vinod, Chegu; Martin Sivak; Shi, Xiao-Lei (Bruce, HP
   Servers-PSC-CQ); Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC);
   engine-devel@ovirt.org; Roy Golan
   Subject: Re: Numa feature entities patch
   
   Hi Jason,
   
   Please reply on the comments in the patch.
   Once the code is written I think it's better not to context switch back
   to
   the design.
   we will reach an agreement in gerrit/review and then update the design
   respectively.
   
   
   Thanks,
   Gilad.
   
   - Original Message -
From: Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)
chuan.l...@hp.com
To: Gilad Chaplik gchap...@redhat.com
Cc: Doron Fediuck dfedi...@redhat.com, Chegu Vinod
chegu_vi...@hp.com, Martin Sivak msi...@redhat.com, Xiao-Lei
Shi (Bruce, HP Servers-PSC-CQ) xiao-lei@hp.com, Shang-Chun
Liang (David Liang, HPservers-Core-OE-PSC) shangchun.li...@hp.com,
engine-devel@ovirt.org
Sent: Monday, March 31, 2014 7:48:28 PM
Subject: RE: Numa feature entities patch

Hi Gilad,

I have update the wiki page design of BE patch 1. add VdcQueryType and
VdcActionType with parameters.
2. merge some of your comments and Eli's feedback.

Please take a look at the section
http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA#Interface
_and_data_structure_in_engine_core

We appreciate any of the comments from community, and sorry for the
nag.

Best Regards,
Jason Liao

-Original Message-
From: Gilad Chaplik [mailto:gchap...@redhat.com]
Sent: 2014年3月30日 22:43
To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Shi, Xiao-Lei
(Bruce, HP Servers-PSC-CQ); Liang, Shang-Chun (David Liang,
HPservers-Core-OE-PSC)
Cc: Doron Fediuck; Vinod, Chegu; Martin Sivak
Subject: Numa feature entities patch

Hi all

Re: [Engine-devel] NUMA Support - GUI Technical Session

2014-04-01 Thread Gilad Chaplik

Hi all, 

Here are the resolutions from the meeting:

* option 1
1) Use gwt-dnd lib for oVirt's dnd (drag and drop) infrastructure.
2) Come up with a very simple POC that covers all of NUMA-support UX 
requirements.
3) Either do a POC, or get UX maintainers approval, that moving already 
existing dnd features to new infrastructure (setup-networks and scheduling 
policy dialogs) is feasible and possible.

* option 2
Extract setup network dnd capabilities to a common general infrastructure and 
use that as an infrastructure. NOTE that setup-networks will not use it in 
oVirt-3.5.

I will start with option 1, just need UX team approval that [1] will be added 
to ovirt-3.5, and be used for dnd for now on.
In case I fail to deliver option 1 (with the help and guidance of the UX team) 
in a quick cycle (a week or so), I will peruse option 2, which is trivial.

Moving forward, all new dnd enabled features will use the new infrastructure, 
and the motivation is to migrate existing ones as well.

Thanks, 
Gilad.

[1] http://code.google.com/p/gwt-dnd/

- Original Message -
 From: Gilad Chaplik gchap...@redhat.com
 To: Einav Cohen eco...@redhat.com, Alexander Wels aw...@redhat.com, 
 Eyal Edri ee...@redhat.com, Steve
 Gordon sgor...@redhat.com, Eli Mesika emes...@redhat.com, Otavio Luiz 
 Ferranti
 otavio.ferra...@eldorado.org.br, Sandro Bonazzola sbona...@redhat.com, 
 Greg Sheremeta gsher...@redhat.com,
 Doron Fediuck dfedi...@redhat.com, Lior Vernia lver...@redhat.com, 
 engine-devel engine-devel@ovirt.org,
 Martin Sivak msi...@redhat.com, chuan liao chuan.l...@hp.com, 
 xiao-lei shi xiao-lei@hp.com, chegu
 vinod chegu_vi...@hp.com, da-huai tang da-huai.t...@hp.com
 Sent: Sunday, March 30, 2014 2:06:59 AM
 Subject: NUMA Support - GUI Technical Session
 
 The following meeting has been modified:
 
 Subject: NUMA Support - GUI Technical Session [MODIFIED]
 Organizer: Gilad Chaplik gchap...@redhat.com
 
 Time: Tuesday, April 1, 2014, 5:00:00 PM - 6:00:00 PM GMT +02:00 Jerusalem
 [MODIFIED]
  
 Required: eco...@redhat.com; aw...@redhat.com; ee...@redhat.com;
 sgor...@redhat.com; emes...@redhat.com; otavio.ferra...@eldorado.org.br;
 sbona...@redhat.com; gsher...@redhat.com
 Optional: dfedi...@redhat.com; lver...@redhat.com; engine-devel@ovirt.org;
 msi...@redhat.com; chuan.l...@hp.com; xiao-lei@hp.com;
 chegu_vi...@hp.com; da-huai.t...@hp.com
 
 *~*~*~*~*~*~*~*~*~*
 
 We will discuss on how to implement NUMA support GUI in oVirt for version 3.5
 (see attached sketches).
 
 Agenda:
 1) Brainstorming
 2) Resolution
 3) Split work/tasks among volunteers :)
 
 GUI maintainers please join-in.
 
 Bluejeans (video conference) session to follow [maybe], currently dial in:
 
 https://www.intercallonline.com/listNumbersByCode.action?confCode=7128867405
 
 conf id: 712 886 7405#
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Please help us to review our database schema design with NUMA feature on ovirt

2014-03-31 Thread Gilad Chaplik

+1

IMO: vds data should reside in static
VM need to think about it.

Roy?

Thanks, 
Gilad.


- Original Message -
 From: Eli Mesika emes...@redhat.com
 To: Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ) xiao-lei@hp.com
 Cc: Chuan Liao (Jason Liao, HPservers-Core-OE-PSC) chuan.l...@hp.com, 
 Doron Fediuck dfedi...@redhat.com,
 Gilad Chaplik gchap...@redhat.com, Chegu Vinod chegu_vi...@hp.com, 
 Shang-Chun Liang (David Liang,
 HPservers-Core-OE-PSC) shangchun.li...@hp.com, Yaniv Dary 
 yd...@redhat.com, engine-devel@ovirt.org
 Sent: Monday, March 31, 2014 12:12:50 PM
 Subject: Re: Please help us to review our database schema design with NUMA 
 feature on ovirt
 
 
 
 - Original Message -
  From: Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ) xiao-lei@hp.com
  To: Eli Mesika emes...@redhat.com
  Cc: Chuan Liao (Jason Liao, HPservers-Core-OE-PSC) chuan.l...@hp.com,
  Doron Fediuck dfedi...@redhat.com,
  Gilad Chaplik gchap...@redhat.com, Chegu Vinod chegu_vi...@hp.com,
  Shang-Chun Liang (David Liang,
  HPservers-Core-OE-PSC) shangchun.li...@hp.com, Yaniv Dary
  yd...@redhat.com, engine-devel@ovirt.org
  Sent: Monday, March 31, 2014 8:56:20 AM
  Subject: RE: Please help us to review our database schema design with NUMA
  feature on ovirt
  
  Include the devel group.
  Thanks Eli for the quick responses for our first design and sorry for the
  nag.
  We appreciate any of the comments for our database design and will follow
  the
  design to do the implementation if no more comments.
   http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA
 
 Seems OK for me except an unanswered question I had asked in my first review
 :
 
 Why in the Host level NUMA fields are added to vds_dynamic while in the VM
 level it is added to vm_static ???
 I would expect it to be in both on static or dynamic , can you please explain
 ? Thanks
 
  
  Thanks  Best Regards
  Shi, Xiao-Lei (Bruce)
  
  Hewlett-Packard Co., Ltd.
  HP Servers Core Platform Software China
  Telephone +86 23 65683093
  Mobile +86 18696583447
  Email xiao-lei@hp.com
  
  -Original Message-
  From: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
  Sent: Friday, March 28, 2014 1:30 PM
  To: 'Eli Mesika'
  Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron Fediuck; Gilad
  Chaplik; Vinod, Chegu; Liang, Shang-Chun (David Liang,
  HPservers-Core-OE-PSC); Yaniv Dary
  Subject: RE: Please help us to review our database schema design with NUMA
  feature on ovirt
  
  Hi Eli,
  
  After the UX design meeting, we did some modification for the database
  schema, and merged some update according to your last review comments.
  Now the document has been posted on ovirt wikipage, could you help to
  review
  the database design again:
  http://www.ovirt.org/Features/Detailed_NUMA_and_Virtual_NUMA
  
  
  Thanks  Best Regards
  Shi, Xiao-Lei (Bruce)
  
  Hewlett-Packard Co., Ltd.
  HP Servers Core Platform Software China Telephone +86 23 65683093 Mobile
  +86
  18696583447 Email xiao-lei@hp.com
  
  
  -Original Message-
  From: Eli Mesika [mailto:emes...@redhat.com]
  Sent: Monday, March 24, 2014 6:24 PM
  To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
  Cc: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Doron Fediuck; Gilad
  Chaplik; Vinod, Chegu; Liang, Shang-Chun (David Liang,
  HPservers-Core-OE-PSC); Yaniv Dary
  Subject: Re: Please help us to review our database schema design with NUMA
  feature on ovirt
  
  
  
  - Original Message -
   From: Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ) xiao-lei@hp.com
   To: Eli Mesika emes...@redhat.com, Chuan Liao (Jason Liao,
   HPservers-Core-OE-PSC) chuan.l...@hp.com
   Cc: Doron Fediuck dfedi...@redhat.com, Gilad Chaplik
   gchap...@redhat.com, Chegu Vinod chegu_vi...@hp.com, Shang-Chun
   Liang (David Liang, HPservers-Core-OE-PSC) shangchun.li...@hp.com
   Sent: Monday, March 24, 2014 11:23:39 AM
   Subject: RE: Please help us to review our database schema design with
   NUMA feature on ovirt
   
   Hi Eli,
   
   Thanks for your comments.
   I have updated the document according to your comments except the below
   one:
   Missing from here are 2 issues:
   
   1) Impact on the search engine, which new columns are search-able and
   which changes are planned in the search engine code to enable that
   
   2) Impact on engine-reports, are those changed planned to be exposed
   to the engine data warehouse and required new/modified reports?
   
   Could you tell us more detailed information about the modules you
   mentioned above? I mean search engine and engine-reports. I think
   we missed these two parts in our previous investigation.
   I just find org.ovirt.engine.core.bll.SearchQuery, is that the right
   object for search engine?
  
  Yes, actually when you are opening the admin UI, there are TABs for each
  entity , i.e. Data Center, Cluster, Host etc.
  In each, you can see a text-box in which you can search for by writing a
  search expression My question

Re: [Engine-devel] Please help us to review our database schema design with NUMA feature on ovirt

2014-03-31 Thread Gilad Chaplik

adding Roy  Omer.

why CPU topology is in dynamic?

Thanks, 
Gilad.

- Original Message -
 From: Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ) xiao-lei@hp.com
 To: Eli Mesika emes...@redhat.com
 Cc: Gilad Chaplik gchap...@redhat.com, Roy Golan rgo...@redhat.com, 
 Chuan Liao (Jason Liao,
 HPservers-Core-OE-PSC) chuan.l...@hp.com, Doron Fediuck 
 dfedi...@redhat.com, Chegu Vinod
 chegu_vi...@hp.com, Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC) 
 shangchun.li...@hp.com, Yaniv Dary
 yd...@redhat.com, engine-devel@ovirt.org
 Sent: Monday, March 31, 2014 3:20:33 PM
 Subject: RE: Please help us to review our database schema design with NUMA 
 feature on ovirt
 
 Thanks Eli.
 I will move the vm level NUMA fields to vm_dynamic, and the related database
 schema will be updated accordingly.
 
 Thanks  Best Regards
 Shi, Xiao-Lei (Bruce)
 
 Hewlett-Packard Co., Ltd.
 HP Servers Core Platform Software China
 Telephone +86 23 65683093
 Mobile +86 18696583447
 Email xiao-lei@hp.com
 
 -Original Message-
 From: Eli Mesika [mailto:emes...@redhat.com]
 Sent: Monday, March 31, 2014 5:49 PM
 To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
 Cc: Gilad Chaplik; Roy Golan; Liao, Chuan (Jason Liao,
 HPservers-Core-OE-PSC); Doron Fediuck; Vinod, Chegu; Liang, Shang-Chun
 (David Liang, HPservers-Core-OE-PSC); Yaniv Dary; engine-devel@ovirt.org
 Subject: Re: Please help us to review our database schema design with NUMA
 feature on ovirt
 
 
 
 - Original Message -
  From: Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ) xiao-lei@hp.com
  To: Gilad Chaplik gchap...@redhat.com, Eli Mesika
  emes...@redhat.com, Roy Golan rgo...@redhat.com
  Cc: Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)
  chuan.l...@hp.com, Doron Fediuck dfedi...@redhat.com, Chegu Vinod
  chegu_vi...@hp.com, Shang-Chun Liang (David Liang,
  HPservers-Core-OE-PSC)
  shangchun.li...@hp.com, Yaniv Dary yd...@redhat.com,
  engine-devel@ovirt.org
  Sent: Monday, March 31, 2014 12:38:04 PM
  Subject: RE: Please help us to review our database schema design with
  NUMA feature on ovirt
  
  We put host level NUMA fields in vds_dynamic because these information
  are from host itself, and NUMA topology may be changed if the host's
  hardware make a change. NUMA information are similar to the host's cpu
  topology information like cpu_cores and cpu_sockets which are in
  vds_dynamic, we refer to this.
  VM level NUMA fields are configured by user, and actually we
  originally think they should be in vm_dynamic. But we found that the
  field of another feature cpuPin which is similar as NUMA feature is in
  vm_static, so we put vm NUMA fields in vm_static.
  Do you think we need to put VM level NUMA fields in vm_dynamic?
 
 I think that in this case we should fix cpuPin to be in vm_dynamic and put
 after that the other NUMA fields in vm_dynamic as well
 
  
  Thanks  Best Regards
  Shi, Xiao-Lei (Bruce)
  
  Hewlett-Packard Co., Ltd.
  HP Servers Core Platform Software China Telephone +86 23 65683093
  Mobile +86 18696583447 Email xiao-lei@hp.com
  
  
  -Original Message-
  From: Gilad Chaplik [mailto:gchap...@redhat.com]
  Sent: Monday, March 31, 2014 5:22 PM
  To: Eli Mesika; Roy Golan
  Cc: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ); Liao, Chuan (Jason Liao,
  HPservers-Core-OE-PSC); Doron Fediuck; Vinod, Chegu; Liang, Shang-Chun
  (David Liang, HPservers-Core-OE-PSC); Yaniv Dary; engine-devel@ovirt.org
  Subject: Re: Please help us to review our database schema design with NUMA
  feature on ovirt
  
  +1
  
  IMO: vds data should reside in static
  VM need to think about it.
  
  Roy?
  
  Thanks,
  Gilad.
  
  
  - Original Message -
   From: Eli Mesika emes...@redhat.com
   To: Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ) xiao-lei@hp.com
   Cc: Chuan Liao (Jason Liao, HPservers-Core-OE-PSC) chuan.l...@hp.com,
   Doron Fediuck dfedi...@redhat.com,
   Gilad Chaplik gchap...@redhat.com, Chegu Vinod
   chegu_vi...@hp.com,
   Shang-Chun Liang (David Liang,
   HPservers-Core-OE-PSC) shangchun.li...@hp.com, Yaniv Dary
   yd...@redhat.com, engine-devel@ovirt.org
   Sent: Monday, March 31, 2014 12:12:50 PM
   Subject: Re: Please help us to review our database schema design with
   NUMA
   feature on ovirt
   
   
   
   - Original Message -
From: Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ) xiao-lei@hp.com
To: Eli Mesika emes...@redhat.com
Cc: Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)
chuan.l...@hp.com,
Doron Fediuck dfedi...@redhat.com,
Gilad Chaplik gchap...@redhat.com, Chegu Vinod
chegu_vi...@hp.com,
Shang-Chun Liang (David Liang,
HPservers-Core-OE-PSC) shangchun.li...@hp.com, Yaniv Dary
yd...@redhat.com, engine-devel@ovirt.org
Sent: Monday, March 31, 2014 8:56:20 AM
Subject: RE: Please help us to review our database schema design with
NUMA
feature on ovirt

Include the devel group.
Thanks Eli for the quick responses for our first design and sorry

Re: [Engine-devel] REST API - where did bookmarks go?

2014-03-27 Thread Gilad Chaplik

Thanks, 
Gilad.

- Original Message -
 From: David Jaša dj...@redhat.com
 To: Gilad Chaplik gchap...@redhat.com
 Cc: engine-devel engine-devel@ovirt.org
 Sent: Thursday, March 27, 2014 1:55:36 PM
 Subject: Re: [Engine-devel] REST API - where did bookmarks go?

 On St, 2014-03-26 at 09:27 -0400, Gilad Chaplik wrote:
  - Original Message -
   From: David Jaša dj...@redhat.com
   To: Gilad Chaplik gchap...@redhat.com
   Cc: Vojtech Szocs vsz...@redhat.com, Einav Cohen
   eco...@redhat.com, engine-devel engine-devel@ovirt.org
   Sent: Wednesday, March 26, 2014 1:59:46 PM
   Subject: Re: [Engine-devel] REST API - where did bookmarks go?

   I don't use bookmarks in RHEV-M but if I did, I wouldn't be pleased if I
   had to use another computer when things go wrong and in addition, engine
   wouldn't give me my bookmarks... IMO if bookmarks are to stay, they
   should be server-side.

  I think that browser's bookmarks are much more advanced, sophisticated and
  native;
  i.e. I'd rather have in my browser a bookmark to down HA VMs search,
  instead of:
  - opening the application
  - open the bookmarks tab
  - searching the bookmark
  * and that's after I know how to use it (I've read the manual[??]/wasted
  time in playing with it), and remember how to use it from time to time.

 OK, that's an argument for no bookmarks in webadmin. My point was for
 client-side vs. server-side webadmin bookmarks.

 Actually, my point is also valid for webadmin bookmarks vs. browser
 bookmarks - imagine you have to do something urgent and the only thing
 is say private browser tab of your colleaugues machine. With webadmin
 bookmarks, you have everything at hand. With browser-based bookmarks,
 you essentially lose them till you come to some sync'd browser.

 David

Again I think it's a really rare use-case, we shouldn't base our UI on that.

   David

   On Po, 2014-03-24 at 11:28 -0400, Gilad Chaplik wrote:
Hi Guys,

Why we need bookmarks in API? a single liner that points out to another
single liner?
I know that we need it for 'UI over REST' migration, but...
IMHO bookmarks should be saved in client side, maybe inject the search
string in the url, and get 'real' bookmarks/favorites... I don't know
:-)

Thanks,
Gilad.

- Original Message -
 From: Vojtech Szocs vsz...@redhat.com
 To: Juan Hernandez jhern...@redhat.com
 Cc: engine-devel engine-devel@ovirt.org
 Sent: Wednesday, March 12, 2014 1:27:19 PM
 Subject: Re: [Engine-devel] REST API - where did bookmarks go?

 - Original Message -
  From: Juan Hernandez jhern...@redhat.com
  To: Vojtech Szocs vsz...@redhat.com, engine-devel
  engine-devel@ovirt.org
  Cc: Einav Cohen eco...@redhat.com
  Sent: Tuesday, March 11, 2014 7:22:35 PM
  Subject: Re: REST API - where did bookmarks go?

  On 03/11/2014 07:15 PM, Vojtech Szocs wrote:
   Hi guys,

   as part of prototyping new JavaScript binding for oVirt REST API,
   we chose a couple of business entities (resources) to experiment
   with.

   I just realized that requesting /ovirt-engine/api doesn't return
   any information about bookmarks. Where did bookmarks go? Is it
   possible to manage bookmarks through REST API?

   Note: WebAdmin currently gets bookmarks through GWT RPC by
   calling
   GetAllBookmarksQuery. Bookmark seems like proper backend business
   entity (with DAO and everything) so it should be exposed also via
   REST API.. or am I missing something?

   Thanks,
   Vojtech

  The didn't go anywhere, just never existed in the API. Please open
  a
  RFE
  to add them.

 Thanks, Juan. The RFE is here:

   https://bugzilla.redhat.com/1075556

  --
  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.

 ___
 Engine-devel mailing list
 Engine-devel@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/engine-devel

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

  ___
  Engine-devel mailing list
  Engine-devel@ovirt.org
  http://lists.ovirt.org/mailman/listinfo/engine-devel

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] debug ovirt-engine

2014-03-26 Thread Gilad Chaplik

btw, at least with eclipse you can debug both client and server together (two 
debug instances, port 8787 and 8000)
note that debugging the client takes time!! don't be intimidated 8-) 

Thanks, 
Gilad.

- Original Message -
 From: Chuan Liao (Jason Liao, HPservers-Core-OE-PSC) chuan.l...@hp.com
 To: 彭春洪 pengchunh...@gmail.com, engine-devel@ovirt.org
 Sent: Wednesday, March 26, 2014 10:43:13 AM
 Subject: Re: [Engine-devel] debug ovirt-engine

 Hi,

 Do you go through the wiki page OVirt Engine Development Environment

 http://www.ovirt.org/OVirt_Engine_Development_Environment

 you can debug with

 Debug port is available via port 8787, to be used by Eclipse or any other
 debugger.

 Best Regards,
 Jason Liao

 From: engine-devel-boun...@ovirt.org [mailto:engine-devel-boun...@ovirt.org]
 On Behalf Of 彭春洪
 Sent: 2014 年 3 月 26 日 16:13
 To: engine-devel@ovirt.org
 Subject: [Engine-devel] debug ovirt-engine

 Hello,everybody.when I develop with ovirt-engine,I have meet some obstacles
 because of without the debug environment. So I really want to know how to
 debug the frontend and backend of ovirt-engine by break points or by step .
 Thank you for help!

 ___
 Engine-devel mailing list
 Engine-devel@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/engine-devel

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] REST API - where did bookmarks go?

2014-03-26 Thread Gilad Chaplik

- Original Message -
 From: David Jaša dj...@redhat.com
 To: Gilad Chaplik gchap...@redhat.com
 Cc: Vojtech Szocs vsz...@redhat.com, Einav Cohen eco...@redhat.com, 
 engine-devel engine-devel@ovirt.org
 Sent: Wednesday, March 26, 2014 1:59:46 PM
 Subject: Re: [Engine-devel] REST API - where did bookmarks go?

 I don't use bookmarks in RHEV-M but if I did, I wouldn't be pleased if I
 had to use another computer when things go wrong and in addition, engine
 wouldn't give me my bookmarks... IMO if bookmarks are to stay, they
 should be server-side.

I think that browser's bookmarks are much more advanced, sophisticated and 
native;
i.e. I'd rather have in my browser a bookmark to down HA VMs search, instead of:
- opening the application
- open the bookmarks tab
- searching the bookmark
* and that's after I know how to use it (I've read the manual[??]/wasted time 
in playing with it), and remember how to use it from time to time. 

 David

 On Po, 2014-03-24 at 11:28 -0400, Gilad Chaplik wrote:
  Hi Guys,

  Why we need bookmarks in API? a single liner that points out to another
  single liner?
  I know that we need it for 'UI over REST' migration, but...
  IMHO bookmarks should be saved in client side, maybe inject the search
  string in the url, and get 'real' bookmarks/favorites... I don't know :-)

  Thanks,
  Gilad.

  - Original Message -
   From: Vojtech Szocs vsz...@redhat.com
   To: Juan Hernandez jhern...@redhat.com
   Cc: engine-devel engine-devel@ovirt.org
   Sent: Wednesday, March 12, 2014 1:27:19 PM
   Subject: Re: [Engine-devel] REST API - where did bookmarks go?

   - Original Message -
From: Juan Hernandez jhern...@redhat.com
To: Vojtech Szocs vsz...@redhat.com, engine-devel
engine-devel@ovirt.org
Cc: Einav Cohen eco...@redhat.com
Sent: Tuesday, March 11, 2014 7:22:35 PM
Subject: Re: REST API - where did bookmarks go?

On 03/11/2014 07:15 PM, Vojtech Szocs wrote:
 Hi guys,

 as part of prototyping new JavaScript binding for oVirt REST API,
 we chose a couple of business entities (resources) to experiment
 with.

 I just realized that requesting /ovirt-engine/api doesn't return
 any information about bookmarks. Where did bookmarks go? Is it
 possible to manage bookmarks through REST API?

 Note: WebAdmin currently gets bookmarks through GWT RPC by calling
 GetAllBookmarksQuery. Bookmark seems like proper backend business
 entity (with DAO and everything) so it should be exposed also via
 REST API.. or am I missing something?

 Thanks,
 Vojtech

The didn't go anywhere, just never existed in the API. Please open a
RFE
to add them.

   Thanks, Juan. The RFE is here:

 https://bugzilla.redhat.com/1075556

--
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.

   ___
   Engine-devel mailing list
   Engine-devel@ovirt.org
   http://lists.ovirt.org/mailman/listinfo/engine-devel

  ___
  Engine-devel mailing list
  Engine-devel@ovirt.org
  http://lists.ovirt.org/mailman/listinfo/engine-devel

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] REST API - where did bookmarks go?

2014-03-26 Thread Gilad Chaplik

thank you Vojtech!

fyi, if we hadn't have the 3.X compatibility issues, I'm for removing current 
bookmarks.

Thanks, 
Gilad.


- Original Message -
 From: Vojtech Szocs vsz...@redhat.com
 To: Gilad Chaplik gchap...@redhat.com
 Cc: dj...@redhat.com, Einav Cohen eco...@redhat.com, engine-devel 
 engine-devel@ovirt.org
 Sent: Wednesday, March 26, 2014 3:36:35 PM
 Subject: Re: [Engine-devel] REST API - where did bookmarks go?
 
 
 
 - Original Message -
  From: Gilad Chaplik gchap...@redhat.com
  To: dj...@redhat.com
  Cc: Vojtech Szocs vsz...@redhat.com, Einav Cohen eco...@redhat.com,
  engine-devel engine-devel@ovirt.org
  Sent: Wednesday, March 26, 2014 2:27:41 PM
  Subject: Re: [Engine-devel] REST API - where did bookmarks go?
  
  - Original Message -
   From: David Jaša dj...@redhat.com
   To: Gilad Chaplik gchap...@redhat.com
   Cc: Vojtech Szocs vsz...@redhat.com, Einav Cohen
   eco...@redhat.com,
   engine-devel engine-devel@ovirt.org
   Sent: Wednesday, March 26, 2014 1:59:46 PM
   Subject: Re: [Engine-devel] REST API - where did bookmarks go?
   
   I don't use bookmarks in RHEV-M but if I did, I wouldn't be pleased if I
   had to use another computer when things go wrong and in addition, engine
   wouldn't give me my bookmarks... IMO if bookmarks are to stay, they
   should be server-side.
  
  I think that browser's bookmarks are much more advanced, sophisticated and
  native;
  i.e. I'd rather have in my browser a bookmark to down HA VMs search,
  instead
  of:
  - opening the application
  - open the bookmarks tab
  - searching the bookmark
  * and that's after I know how to use it (I've read the manual[??]/wasted
  time
  in playing with it), and remember how to use it from time to time.
 
 If this means embedding search string in WebAdmin's URL like [1], I'm for it.
 
 [1] WebAdmin.html#search;q={uri-encoded-search-string}
 
 This could be done as RFE on top of (existing) bookmark functionality, giving
 people more choice.
 
  
   
   David
   
   On Po, 2014-03-24 at 11:28 -0400, Gilad Chaplik wrote:
Hi Guys,

Why we need bookmarks in API? a single liner that points out to another
single liner?
I know that we need it for 'UI over REST' migration, but...
IMHO bookmarks should be saved in client side, maybe inject the search
string in the url, and get 'real' bookmarks/favorites... I don't know
:-)

Thanks,
Gilad.

- Original Message -
 From: Vojtech Szocs vsz...@redhat.com
 To: Juan Hernandez jhern...@redhat.com
 Cc: engine-devel engine-devel@ovirt.org
 Sent: Wednesday, March 12, 2014 1:27:19 PM
 Subject: Re: [Engine-devel] REST API - where did bookmarks go?
 
 
 
 - Original Message -
  From: Juan Hernandez jhern...@redhat.com
  To: Vojtech Szocs vsz...@redhat.com, engine-devel
  engine-devel@ovirt.org
  Cc: Einav Cohen eco...@redhat.com
  Sent: Tuesday, March 11, 2014 7:22:35 PM
  Subject: Re: REST API - where did bookmarks go?
  
  On 03/11/2014 07:15 PM, Vojtech Szocs wrote:
   Hi guys,
   
   as part of prototyping new JavaScript binding for oVirt REST API,
   we chose a couple of business entities (resources) to experiment
   with.
   
   I just realized that requesting /ovirt-engine/api doesn't return
   any information about bookmarks. Where did bookmarks go? Is it
   possible to manage bookmarks through REST API?
   
   Note: WebAdmin currently gets bookmarks through GWT RPC by
   calling
   GetAllBookmarksQuery. Bookmark seems like proper backend business
   entity (with DAO and everything) so it should be exposed also via
   REST API.. or am I missing something?
   
   Thanks,
   Vojtech
   
  
  The didn't go anywhere, just never existed in the API. Please open
  a
  RFE
  to add them.
 
 Thanks, Juan. The RFE is here:
 
   https://bugzilla.redhat.com/1075556
 
  
  --
  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.
  
 ___
 Engine-devel mailing list
 Engine-devel@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/engine-devel

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
   
   
   
  
 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] REST API - where did bookmarks go?

2014-03-25 Thread Gilad Chaplik

- Original Message -
 From: Itamar Heim ih...@redhat.com
 To: Gilad Chaplik gchap...@redhat.com
 Cc: Vojtech Szocs vsz...@redhat.com, Juan Hernandez 
 jhern...@redhat.com, engine-devel
 engine-devel@ovirt.org, Einav Cohen eco...@redhat.com
 Sent: Tuesday, March 25, 2014 4:55:29 PM
 Subject: Re: [Engine-devel] REST API - where did bookmarks go?

 On 03/25/2014 10:52 AM, Gilad Chaplik wrote:
  - Original Message -
  From: Itamar Heim ih...@redhat.com
  To: Vojtech Szocs vsz...@redhat.com, Gilad Chaplik
  gchap...@redhat.com
  Cc: Juan Hernandez jhern...@redhat.com, engine-devel
  engine-devel@ovirt.org
  Sent: Tuesday, March 25, 2014 12:17:48 AM
  Subject: Re: [Engine-devel] REST API - where did bookmarks go?

  On 03/24/2014 12:40 PM, Vojtech Szocs wrote:

  - Original Message -
  From: Gilad Chaplik gchap...@redhat.com
  To: Einav Cohen eco...@redhat.com
  Cc: Vojtech Szocs vsz...@redhat.com, Juan Hernandez
  jhern...@redhat.com, engine-devel
  engine-devel@ovirt.org
  Sent: Monday, March 24, 2014 4:46:04 PM
  Subject: Re: [Engine-devel] REST API - where did bookmarks go?

  Hi Einav,

  I agree with every word. also thought about it, that's why I wrote a
  possible
  solution.
  Not sure we need to design the RESTful API according to UI's needs (add
  features in this case).

  I think that API should accomodate general/common needs of its clients.
  After all, the usefulness of API can be measured by its usability from
  client's perspective.

  At one extreme, API adapts to each specific client, which in turn bloats
  the API. At another extreme, API lives in isolated bubble and doesn't
  care
  for its clients. Each of these extremes is dangerous :)

  I find shared bookmarks useful.
  i do actually think they should have had permissions:
  - who can see my bookmarks
  - who can share their bookmarks with others

  I think that nowadays bookmarks are a client side feature only.
  You can add bookmarks in your browser, and it will exist everywhere
  (mobile/smartphone/etc) - I use it on a daily basis on 4 different
  devices.
  so you are getting these features for free.

 that's multiple devices, not multiple users.

* Have you heard of a user who wants it? I think it's a rare use case, but 
maybe(/usually) I'm wrong.
* Google search: share browser bookmarks, About 12,700,000 results

  In 'UI over REST' migration process I suggest to leave bookmarks to last,
  and reassess then.

  Thanks,
  Gilad.

  - Original Message -
  From: Einav Cohen eco...@redhat.com
  To: Gilad Chaplik gchap...@redhat.com
  Cc: Vojtech Szocs vsz...@redhat.com, Juan Hernandez
  jhern...@redhat.com, engine-devel
  engine-devel@ovirt.org
  Sent: Monday, March 24, 2014 5:38:33 PM
  Subject: Re: [Engine-devel] REST API - where did bookmarks go?

  Hi Gilad, client-side Bookmarks is a great suggestion, however it
  is a (non-related) RFE, which may be implemented instead of, or in
  addition to, the already-existing server-side Bookmarks.

  [keep in mind that server-side bookmarks allow you to add bookmarks
  that may be used by other users; it is also a feature that exists
  for a long time in oVirt, so need to think a little bit before
  removing it]

  As long as we have server-side Bookmarks (i.e. as long as Bookmark
  is an engine-managed business entity), they need to be exposed via
  the REST API.

  Thanks,
  Einav

  - Original Message -
  From: Gilad Chaplik gchap...@redhat.com
  To: Vojtech Szocs vsz...@redhat.com
  Cc: Juan Hernandez jhern...@redhat.com, engine-devel
  engine-devel@ovirt.org
  Sent: Monday, March 24, 2014 11:28:02 AM
  Subject: Re: [Engine-devel] REST API - where did bookmarks go?

  Hi Guys,

  Why we need bookmarks in API? a single liner that points out to
  another
  single liner?
  I know that we need it for 'UI over REST' migration, but...
  IMHO bookmarks should be saved in client side, maybe inject the search
  string
  in the url, and get 'real' bookmarks/favorites... I don't know :-)

  Thanks,
  Gilad.

  - Original Message -
  From: Vojtech Szocs vsz...@redhat.com
  To: Juan Hernandez jhern...@redhat.com
  Cc: engine-devel engine-devel@ovirt.org
  Sent: Wednesday, March 12, 2014 1:27:19 PM
  Subject: Re: [Engine-devel] REST API - where did bookmarks go?

  - Original Message -
  From: Juan Hernandez jhern...@redhat.com
  To: Vojtech Szocs vsz...@redhat.com, engine-devel
  engine-devel@ovirt.org
  Cc: Einav Cohen eco...@redhat.com
  Sent: Tuesday, March 11, 2014 7:22:35 PM
  Subject: Re: REST API - where did bookmarks go?

  On 03/11/2014 07:15 PM, Vojtech Szocs wrote:
  Hi guys,

  as part of prototyping new JavaScript binding for oVirt REST API,
  we chose a couple of business entities (resources) to experiment
  with.

  I just realized that requesting /ovirt-engine/api doesn't return
  any information about bookmarks. Where did bookmarks go? Is it
  possible to manage bookmarks

Re: [Engine-devel] Share Your Thoughts

2014-03-24 Thread Gilad Chaplik

- Original Message -
 From: Adam Litke ali...@redhat.com
 To: Gilad Chaplik gchap...@redhat.com
 Cc: engine-devel engine-devel@ovirt.org
 Sent: Monday, March 24, 2014 3:00:20 PM
 Subject: Re: [Engine-devel] Share Your Thoughts

 On 24/03/14 08:43 -0400, Adam Litke wrote:
 On 23/03/14 10:36 -0400, Gilad Chaplik wrote:
 AuditLog gets recycled after 30 days. the reason i stopped my VM may
 still be relevant.
 I would not make fields complex/composite. they need to be easily
 useable via the CLI for example.

 I think we need multiple comments, so we need to think about the RESTful
 api anyhow.
 I guess that next feature will be a reason for 'wipe after stop'/any other
 BE that needs reasoning.

 What about a new DB table (maybe called Annotations) that takes a
 business entity type, UUID, action type, timestamp, and reason string.
 Then the shutdown reason could be entered as a new row in the DB.  It
 can be kept as long as we want it and views can be adjusted to make
 these fields searchable.

 I forgot to mention that this idea would make it simple to annotate
 the reason for moving a host into maintenance mode as well (or any
 other state change annotations we would want to make in the future).

Hi Adam,

Sorry for not being clear enough, the change of the comment free-text field 
should be an infra one, 
and can be applied for all other comment fields, we will start with VM because 
it's required for now, and reuse the same code for other entities when needed.
I've discusses with Eli off-line and he came up with the same idea as yours 
(great minds think alike ;) - it's not just in advertising).
Personally, I think it's an overhead for now, there no problem adding it later, 
and it's quite simple actually.

3 comments:
* I think Eli's solution is nice to have but not complete. gave +1 because I 
thought it's a bigger feature that what he wants (a simple write to log), 
because in order to meet the RFE/bug 's requirements with logging, we need to 
pin the audit log into the entity itself (flag the entity according to audit 
log), IMHO logging isn't good enough UX-wise.
* Regarding Itamar's comment:
   1) Is this field is a tech preview? if not, we can still support strings in 
that field as well.
   2) Saving XML will allow us to get the RESTful API out of the box (just need 
to format it according to requested user's presentation).
   3) We can add the types as part of the API.
   4) Did someone say custom properties sheet in REST? :-)
* Regarding the cluster level config (requested in the bug, and implemented in 
the patch), if we are going on it, we need a separate thread on it (and I'm -1 
on it, btw), a simple checkbox 'do not show this textbox/message again' in 
browser's local-data will do the trick.

Thanks, 
Gilad.

 --
 Adam Litke

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] REST API - where did bookmarks go?

2014-03-24 Thread Gilad Chaplik

Hi Guys,

Why we need bookmarks in API? a single liner that points out to another single 
liner?
I know that we need it for 'UI over REST' migration, but...
IMHO bookmarks should be saved in client side, maybe inject the search string 
in the url, and get 'real' bookmarks/favorites... I don't know :-)

Thanks, 
Gilad.

- Original Message -
 From: Vojtech Szocs vsz...@redhat.com
 To: Juan Hernandez jhern...@redhat.com
 Cc: engine-devel engine-devel@ovirt.org
 Sent: Wednesday, March 12, 2014 1:27:19 PM
 Subject: Re: [Engine-devel] REST API - where did bookmarks go?
 
 
 
 - Original Message -
  From: Juan Hernandez jhern...@redhat.com
  To: Vojtech Szocs vsz...@redhat.com, engine-devel
  engine-devel@ovirt.org
  Cc: Einav Cohen eco...@redhat.com
  Sent: Tuesday, March 11, 2014 7:22:35 PM
  Subject: Re: REST API - where did bookmarks go?
  
  On 03/11/2014 07:15 PM, Vojtech Szocs wrote:
   Hi guys,
   
   as part of prototyping new JavaScript binding for oVirt REST API,
   we chose a couple of business entities (resources) to experiment
   with.
   
   I just realized that requesting /ovirt-engine/api doesn't return
   any information about bookmarks. Where did bookmarks go? Is it
   possible to manage bookmarks through REST API?
   
   Note: WebAdmin currently gets bookmarks through GWT RPC by calling
   GetAllBookmarksQuery. Bookmark seems like proper backend business
   entity (with DAO and everything) so it should be exposed also via
   REST API.. or am I missing something?
   
   Thanks,
   Vojtech
   
  
  The didn't go anywhere, just never existed in the API. Please open a RFE
  to add them.
 
 Thanks, Juan. The RFE is here:
 
   https://bugzilla.redhat.com/1075556
 
  
  --
  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.
  
 ___
 Engine-devel mailing list
 Engine-devel@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/engine-devel

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] REST API - where did bookmarks go?

2014-03-24 Thread Gilad Chaplik

Hi Einav,

I agree with every word. also thought about it, that's why I wrote a possible 
solution.
Not sure we need to design the RESTful API according to UI's needs (add 
features in this case).



Thanks, 
Gilad.


- Original Message -
 From: Einav Cohen eco...@redhat.com
 To: Gilad Chaplik gchap...@redhat.com
 Cc: Vojtech Szocs vsz...@redhat.com, Juan Hernandez 
 jhern...@redhat.com, engine-devel
 engine-devel@ovirt.org
 Sent: Monday, March 24, 2014 5:38:33 PM
 Subject: Re: [Engine-devel] REST API - where did bookmarks go?
 
 Hi Gilad, client-side Bookmarks is a great suggestion, however it
 is a (non-related) RFE, which may be implemented instead of, or in
 addition to, the already-existing server-side Bookmarks.
 
 [keep in mind that server-side bookmarks allow you to add bookmarks
 that may be used by other users; it is also a feature that exists
 for a long time in oVirt, so need to think a little bit before
 removing it]
 
 As long as we have server-side Bookmarks (i.e. as long as Bookmark
 is an engine-managed business entity), they need to be exposed via
 the REST API.
 
 
 Thanks,
 Einav
 
 - Original Message -
  From: Gilad Chaplik gchap...@redhat.com
  To: Vojtech Szocs vsz...@redhat.com
  Cc: Juan Hernandez jhern...@redhat.com, engine-devel
  engine-devel@ovirt.org
  Sent: Monday, March 24, 2014 11:28:02 AM
  Subject: Re: [Engine-devel] REST API - where did bookmarks go?
  
  Hi Guys,
  
  Why we need bookmarks in API? a single liner that points out to another
  single liner?
  I know that we need it for 'UI over REST' migration, but...
  IMHO bookmarks should be saved in client side, maybe inject the search
  string
  in the url, and get 'real' bookmarks/favorites... I don't know :-)
  
  Thanks,
  Gilad.
  
  - Original Message -
   From: Vojtech Szocs vsz...@redhat.com
   To: Juan Hernandez jhern...@redhat.com
   Cc: engine-devel engine-devel@ovirt.org
   Sent: Wednesday, March 12, 2014 1:27:19 PM
   Subject: Re: [Engine-devel] REST API - where did bookmarks go?
   
   
   
   - Original Message -
From: Juan Hernandez jhern...@redhat.com
To: Vojtech Szocs vsz...@redhat.com, engine-devel
engine-devel@ovirt.org
Cc: Einav Cohen eco...@redhat.com
Sent: Tuesday, March 11, 2014 7:22:35 PM
Subject: Re: REST API - where did bookmarks go?

On 03/11/2014 07:15 PM, Vojtech Szocs wrote:
 Hi guys,
 
 as part of prototyping new JavaScript binding for oVirt REST API,
 we chose a couple of business entities (resources) to experiment
 with.
 
 I just realized that requesting /ovirt-engine/api doesn't return
 any information about bookmarks. Where did bookmarks go? Is it
 possible to manage bookmarks through REST API?
 
 Note: WebAdmin currently gets bookmarks through GWT RPC by calling
 GetAllBookmarksQuery. Bookmark seems like proper backend business
 entity (with DAO and everything) so it should be exposed also via
 REST API.. or am I missing something?
 
 Thanks,
 Vojtech
 

The didn't go anywhere, just never existed in the API. Please open a
RFE
to add them.
   
   Thanks, Juan. The RFE is here:
   
 https://bugzilla.redhat.com/1075556
   

--
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.

   ___
   Engine-devel mailing list
   Engine-devel@ovirt.org
   http://lists.ovirt.org/mailman/listinfo/engine-devel
  
  ___
  Engine-devel mailing list
  Engine-devel@ovirt.org
  http://lists.ovirt.org/mailman/listinfo/engine-devel
 
 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] REST API - where did bookmarks go?

2014-03-24 Thread Gilad Chaplik

So iiuc, we are going to develop a known obsolete feature :-) ?
Can we break it in 4.0?

Thanks, 
Gilad.

- Original Message -
 From: Einav Cohen eco...@redhat.com
 To: Gilad Chaplik gchap...@redhat.com
 Cc: Juan Hernandez jhern...@redhat.com, engine-devel 
 engine-devel@ovirt.org
 Sent: Monday, March 24, 2014 5:55:20 PM
 Subject: Re: [Engine-devel] REST API - where did bookmarks go?

  - Original Message -
  From: Gilad Chaplik gchap...@redhat.com
  Sent: Monday, March 24, 2014 11:46:04 AM

  Hi Einav,

  I agree with every word. also thought about it, that's why I wrote a
  possible
  solution.
  Not sure we need to design the RESTful API according to UI's needs (add
  features in this case).

 the REST API should not be designed according to UI's needs - but the REST
 API
 should allow to retrieve all engine-managed business entities. Bookmarks is
 one
 of them.
 There is a chance that creating Bookmarks as an engine-managed
 business-entity
 in the first place was a bad design decision, but they are there now, as
 managed
 business-entities, and as such - should be exposed via the REST API.

  Thanks,
  Gilad.

  - Original Message -
   From: Einav Cohen eco...@redhat.com
   To: Gilad Chaplik gchap...@redhat.com
   Cc: Vojtech Szocs vsz...@redhat.com, Juan Hernandez
   jhern...@redhat.com, engine-devel
   engine-devel@ovirt.org
   Sent: Monday, March 24, 2014 5:38:33 PM
   Subject: Re: [Engine-devel] REST API - where did bookmarks go?

   Hi Gilad, client-side Bookmarks is a great suggestion, however it
   is a (non-related) RFE, which may be implemented instead of, or in
   addition to, the already-existing server-side Bookmarks.

   [keep in mind that server-side bookmarks allow you to add bookmarks
   that may be used by other users; it is also a feature that exists
   for a long time in oVirt, so need to think a little bit before
   removing it]

   As long as we have server-side Bookmarks (i.e. as long as Bookmark
   is an engine-managed business entity), they need to be exposed via
   the REST API.

   Thanks,
   Einav

   - Original Message -
From: Gilad Chaplik gchap...@redhat.com
To: Vojtech Szocs vsz...@redhat.com
Cc: Juan Hernandez jhern...@redhat.com, engine-devel
engine-devel@ovirt.org
Sent: Monday, March 24, 2014 11:28:02 AM
Subject: Re: [Engine-devel] REST API - where did bookmarks go?

Hi Guys,

Why we need bookmarks in API? a single liner that points out to another
single liner?
I know that we need it for 'UI over REST' migration, but...
IMHO bookmarks should be saved in client side, maybe inject the search
string
in the url, and get 'real' bookmarks/favorites... I don't know :-)

Thanks,
Gilad.

- Original Message -
 From: Vojtech Szocs vsz...@redhat.com
 To: Juan Hernandez jhern...@redhat.com
 Cc: engine-devel engine-devel@ovirt.org
 Sent: Wednesday, March 12, 2014 1:27:19 PM
 Subject: Re: [Engine-devel] REST API - where did bookmarks go?

 - Original Message -
  From: Juan Hernandez jhern...@redhat.com
  To: Vojtech Szocs vsz...@redhat.com, engine-devel
  engine-devel@ovirt.org
  Cc: Einav Cohen eco...@redhat.com
  Sent: Tuesday, March 11, 2014 7:22:35 PM
  Subject: Re: REST API - where did bookmarks go?

  On 03/11/2014 07:15 PM, Vojtech Szocs wrote:
   Hi guys,

   as part of prototyping new JavaScript binding for oVirt REST API,
   we chose a couple of business entities (resources) to experiment
   with.

   I just realized that requesting /ovirt-engine/api doesn't return
   any information about bookmarks. Where did bookmarks go? Is it
   possible to manage bookmarks through REST API?

   Note: WebAdmin currently gets bookmarks through GWT RPC by
   calling
   GetAllBookmarksQuery. Bookmark seems like proper backend business
   entity (with DAO and everything) so it should be exposed also via
   REST API.. or am I missing something?

   Thanks,
   Vojtech

  The didn't go anywhere, just never existed in the API. Please open
  a
  RFE
  to add them.

 Thanks, Juan. The RFE is here:

   https://bugzilla.redhat.com/1075556

  --
  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.

 ___
 Engine-devel mailing list
 Engine-devel@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/engine-devel

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

[Engine-devel] Share Your Thoughts

2014-03-23 Thread Gilad Chaplik

Dear Devel Community Members,

We are having a small discussion on patch: http://gerrit.ovirt.org/#/c/25633/,
bug 1065753 - Maintenance operations on a VM would ask for an optional reason 
(adding a note to stop/shutdown VM, that will be cleared when the VM go up).

The proposed solution is to add a free text field in the VM entity, and to 
update it in command's parameters (StopVmParmas.. etc.).

I think slightly different, my alternative is to enhance the current free text 
(comment field) into XML, and allow to add multiple comments that include types.
You are welcome to read more about it in the patch's comments.

Thoughts?

Thanks, 
Gilad.
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Share Your Thoughts

2014-03-23 Thread Gilad Chaplik

Thanks, 
Gilad.

- Original Message -
 From: Omer Frenkel ofren...@redhat.com
 To: Eli Mesika emes...@redhat.com
 Cc: Gilad Chaplik gchap...@redhat.com, engine-devel 
 engine-devel@ovirt.org
 Sent: Sunday, March 23, 2014 3:35:28 PM
 Subject: Re: [Engine-devel] Share Your Thoughts

 - Original Message -
  From: Eli Mesika emes...@redhat.com
  To: Gilad Chaplik gchap...@redhat.com
  Cc: engine-devel engine-devel@ovirt.org
  Sent: Sunday, March 23, 2014 2:41:15 PM
  Subject: Re: [Engine-devel] Share Your Thoughts

  - Original Message -
   From: Eli Mesika emes...@redhat.com
   To: Gilad Chaplik gchap...@redhat.com
   Cc: engine-devel engine-devel@ovirt.org
   Sent: Sunday, March 23, 2014 2:36:17 PM
   Subject: Re: [Engine-devel] Share Your Thoughts

   - Original Message -
From: Gilad Chaplik gchap...@redhat.com
To: engine-devel engine-devel@ovirt.org
Sent: Sunday, March 23, 2014 2:06:01 PM
Subject: [Engine-devel] Share Your Thoughts

Dear Devel Community Members,

We are having a small discussion on patch:
http://gerrit.ovirt.org/#/c/25633/,
bug 1065753 - Maintenance operations on a VM would ask for an optional
reason (adding a note to stop/shutdown VM, that will be cleared when
the
VM
go up).

The proposed solution is to add a free text field in the VM entity, and
to
update it in command's parameters (StopVmParmas.. etc.).

I think slightly different, my alternative is to enhance the current
free
text (comment field) into XML, and allow to add multiple comments that
include types.
You are welcome to read more about it in the patch's comments.

Thoughts?

   I suggest a third approach
   We are logging here a reason for a user/admin operation
   The natural place for such information is the audit log and not the VM
   tables.
   I think that the audit log messages related for the stop/shutdown
   commands
   should be enhanced to include a {REASON} field then the command itself
   will
   replace this value in the message with the one given by the user and we
   are
   done.
   Again, the required information is a pure logging issue, therefor I
   suggest
   to put this information in the correct place for it, there is no point in
   saving any logging messages in any entity table.

   Technically:
   1) The option for giving a reason should be configurable (per Cluster if
   I
   look at Arthur comment in the BZ)
   2) If the option is on than any stop/shutdown will ask for reason and
   sent
   it
   in the command parameters
  than=then
   3) If the command succeed and got a non-empty reason , it will set the
   reason
   in the command audit log message

  4) We gain here additional advantage since we can :
 a) search for the reason using the search engine
 b) get the reason in the message text sent to us if we are subscribed
 for
 the VM stop/shotdown event ans using engine-notifier

   Eli

 +1
 sounds like a good and simple idea

+1, BUT this is completely a different feature, and more difficult (MUCH more, 
if I may add).
IMHO we need both, lets start with the no-brainer.

Thanks,
Gilad.
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

  ___
  Engine-devel mailing list
  Engine-devel@ovirt.org
  http://lists.ovirt.org/mailman/listinfo/engine-devel

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Share Your Thoughts

2014-03-23 Thread Gilad Chaplik

Thanks, 
Gilad.

- Original Message -
 From: Itamar Heim ih...@redhat.com
 To: Gilad Chaplik gchap...@redhat.com, Eli Mesika emes...@redhat.com
 Cc: engine-devel engine-devel@ovirt.org
 Sent: Sunday, March 23, 2014 4:13:41 PM
 Subject: Re: [Engine-devel] Share Your Thoughts

 On 03/23/2014 04:01 PM, Gilad Chaplik wrote:

  Thanks,
  Gilad.

  - Original Message -
  From: Omer Frenkel ofren...@redhat.com
  To: Eli Mesika emes...@redhat.com
  Cc: Gilad Chaplik gchap...@redhat.com, engine-devel
  engine-devel@ovirt.org
  Sent: Sunday, March 23, 2014 3:35:28 PM
  Subject: Re: [Engine-devel] Share Your Thoughts

  - Original Message -
  From: Eli Mesika emes...@redhat.com
  To: Gilad Chaplik gchap...@redhat.com
  Cc: engine-devel engine-devel@ovirt.org
  Sent: Sunday, March 23, 2014 2:41:15 PM
  Subject: Re: [Engine-devel] Share Your Thoughts

  - Original Message -
  From: Eli Mesika emes...@redhat.com
  To: Gilad Chaplik gchap...@redhat.com
  Cc: engine-devel engine-devel@ovirt.org
  Sent: Sunday, March 23, 2014 2:36:17 PM
  Subject: Re: [Engine-devel] Share Your Thoughts

  - Original Message -
  From: Gilad Chaplik gchap...@redhat.com
  To: engine-devel engine-devel@ovirt.org
  Sent: Sunday, March 23, 2014 2:06:01 PM
  Subject: [Engine-devel] Share Your Thoughts

  Dear Devel Community Members,

  We are having a small discussion on patch:
  http://gerrit.ovirt.org/#/c/25633/,
  bug 1065753 - Maintenance operations on a VM would ask for an optional
  reason (adding a note to stop/shutdown VM, that will be cleared when
  the
  VM
  go up).

  The proposed solution is to add a free text field in the VM entity, and
  to
  update it in command's parameters (StopVmParmas.. etc.).

  I think slightly different, my alternative is to enhance the current
  free
  text (comment field) into XML, and allow to add multiple comments that
  include types.
  You are welcome to read more about it in the patch's comments.

  Thoughts?

  I suggest a third approach
  We are logging here a reason for a user/admin operation
  The natural place for such information is the audit log and not the VM
  tables.
  I think that the audit log messages related for the stop/shutdown
  commands
  should be enhanced to include a {REASON} field then the command itself
  will
  replace this value in the message with the one given by the user and we
  are
  done.
  Again, the required information is a pure logging issue, therefor I
  suggest
  to put this information in the correct place for it, there is no point
  in
  saving any logging messages in any entity table.

  Technically:
  1) The option for giving a reason should be configurable (per Cluster if
  I
  look at Arthur comment in the BZ)
  2) If the option is on than any stop/shutdown will ask for reason and
  sent
  it
  in the command parameters
  than=then
  3) If the command succeed and got a non-empty reason , it will set the
  reason
  in the command audit log message

  4) We gain here additional advantage since we can :
  a) search for the reason using the search engine
  b) get the reason in the message text sent to us if we are subscribed
  for
  the VM stop/shotdown event ans using engine-notifier

  Eli

  +1
  sounds like a good and simple idea

  +1, BUT this is completely a different feature, and more difficult (MUCH
  more, if I may add).
  IMHO we need both, lets start with the no-brainer.

 AuditLog gets recycled after 30 days. the reason i stopped my VM may
 still be relevant.
 I would not make fields complex/composite. they need to be easily
 useable via the CLI for example.

I think we need multiple comments, so we need to think about the RESTful api 
anyhow.
I guess that next feature will be a reason for 'wipe after stop'/any other BE 
that needs reasoning.

  Thanks,
  Gilad.
  ___
  Engine-devel mailing list
  Engine-devel@ovirt.org
  http://lists.ovirt.org/mailman/listinfo/engine-devel

  ___
  Engine-devel mailing list
  Engine-devel@ovirt.org
  http://lists.ovirt.org/mailman/listinfo/engine-devel

  ___
  Engine-devel mailing list
  Engine-devel@ovirt.org
  http://lists.ovirt.org/mailman/listinfo/engine-devel

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Supposed to add per CPU usage related infomation into engine core and vdsm

2014-03-10 Thread Gilad Chaplik

- Original Message -
 From: Chuan Liao (Jason Liao, HPservers-Core-OE-PSC) chuan.l...@hp.com
 To: arch a...@ovirt.org, vdsm-devel 
 vdsm-de...@lists.fedorahosted.org, engine-devel@ovirt.org
 Cc: Gilad Chaplik gchap...@redhat.com, dfedi...@redhat.com, 
 msi...@redhat.com
 Sent: Monday, March 10, 2014 11:17:13 AM
 Subject: Supposed to add per CPU usage related infomation into engine core 
 and vdsm

 Hi All,

 In order to support NUMA and guest NUMA feature in ovirt.
 We need per NUMA node CPU usage or per CPU usage related information on
 engine core.

 This information will be used for VM who have NUMA aware information and find
 the best Host to run it on with best performance.

 Approach 1:

 1.  Sample data in vdsm for each CPU stats. (sys, usr, iowait, idle)

 2.  Calculate the each CPU usage information. (%sys, %usr, %iowait,
 %idle)

 3.  Transport the usage data to engine core.

 4.  Engine core merge per NUMA node CPU usage. (%sys, %usr, %iowait,
 %idle)

+1, since this data can be used for hardware other than NUMA

 Approach 2:

 1.  Sample data in vdsm for each CPU stats. (sys, usr, iowait, idle)

 2.  Calculate the each CPU usage information. (%sys, %usr, %iowait,
 %idle)

 3.  VDSM merge per NUMA node CPU usage. (%sys, %usr, %iowait, %idle)

 4.  Transport the usage data to engine core.

 Which one do you prefer, and why, or other solution.

 Best Regards,
 Jason Liao

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] proposing Alexander Wels as an ovirt-engine UI maintainer

2014-01-21 Thread Gilad Chaplik

+1

Thanks, 
Gilad.

- Original Message -
 From: Vojtech Szocs vsz...@redhat.com
 To: Einav Cohen eco...@redhat.com
 Cc: Tal Nisan tni...@redhat.com, Gilad Chaplik gchap...@redhat.com, 
 Kanagaraj kmayi...@redhat.com,
 Daniel Erez de...@redhat.com, Tomas Jelinek tjeli...@redhat.com, 
 Lior Vernia lver...@redhat.com,
 in...@ovirt.org, engine-devel engine-devel@ovirt.org, Alexander Wels 
 aw...@redhat.com
 Sent: Tuesday, January 21, 2014 5:43:17 PM
 Subject: Re: proposing Alexander Wels as an ovirt-engine UI maintainer
 
 
 
 - Original Message -
  From: Einav Cohen eco...@redhat.com
  To: Tal Nisan tni...@redhat.com, Gilad Chaplik gchap...@redhat.com,
  Vojtech Szocs vsz...@redhat.com,
  Kanagaraj kmayi...@redhat.com, Daniel Erez de...@redhat.com, Tomas
  Jelinek tjeli...@redhat.com, Lior
  Vernia lver...@redhat.com
  Cc: in...@ovirt.org, engine-devel engine-devel@ovirt.org, Alexander
  Wels aw...@redhat.com
  Sent: Tuesday, January 21, 2014 4:39:09 PM
  Subject: proposing Alexander Wels as an ovirt-engine UI maintainer
  
  Hello UI Maintainers,
  
  I would like to propose Alexander Wels as an ovirt-engine UI maintainer.
 
 +1
 
  
  Alexander started his ovirt involvement more than a year ago,
  contributing over 100 patches (to 'master' alone), including the
  branding mechanism, Frontend refactoring (cleanup, unit-tests, requests
  retry mechanism, requests-aggregation mechanism), cross-GUI refresh
  synchronization and low-resolutions support.
  
  Your response would be appreciated.
  
  Thanks in advance.
  
  
  Regards,
  Einav
  
 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] [jenkins] dao tests broken

2013-12-15 Thread Gilad Chaplik


- Original Message -
 From: Eyal Edri ee...@redhat.com
 To: engine-devel engine-devel@ovirt.org
 Cc: infra in...@ovirt.org, Gilad Chaplik gchap...@redhat.com
 Sent: Sunday, December 15, 2013 12:10:11 PM
 Subject: [jenkins] dao tests broken
 
 fyi,
 
 dao tests are broken for some time now, who can look into it?
 current failing tests are:

Hi Eyal, 

what fails is unit tests and not dao tests (fails on dao job), 
it looks like you're trying to rebase ovirt-engine-3.3 on top of master (you 
can see it even it the log, comparing the last success and first fail jobs).

can you check it out?

Thanks, 
Gilad.

 
 Tests in error:
   testAdUserConstrcutor(org.ovirt.engine.core.common.users.VdcUserTest):
   
 org.ovirt.engine.core.common.businessentities.LdapUser.setPassword(Ljava/lang/String;)V
   
 testAdUserAndFalseBooleanConstrcutor(org.ovirt.engine.core.common.users.VdcUserTest):
   
 org.ovirt.engine.core.common.businessentities.LdapUser.setPassword(Ljava/lang/String;)V
   
 testAdUserAndTrueBooleanConstrcutor(org.ovirt.engine.core.common.users.VdcUserTest):
   
 org.ovirt.engine.core.common.businessentities.LdapUser.setPassword(Ljava/lang/String;)V
   getUserFQN(org.ovirt.engine.core.common.users.VdcUserTest):
   
 org.ovirt.engine.core.common.businessentities.LdapUser.setPassword(Ljava/lang/String;)V
 
 http://jenkins.ovirt.org/job/ovirt_engine_dao_unit_tests/5446/console
 
 looks like it started after commit :
 http://jenkins.ovirt.org/job/ovirt_engine_dao_unit_tests/5438/
 core: scheduling: handle cpu load duration (detail / gitweb)
 
 Eyal.
 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Adding users and assigning roles in Ovirt

2013-12-02 Thread Gilad Chaplik

Hi Ramesh,

You're right, I also think that the 'add users' is a bit pointless, but adding 
a system permission in that dialog can be dangerous (if admin doesn't fully 
understand what he's doing, and MLA is complicated enough ;-) ).

Currently when adding a permission we can specify a AD-user (regardless to the 
fact he's added or not), So eventually power users can add users to the system.
I can think of a case, that admins will want to manage the users by themselves, 
i.e- power users can add permissions for the added users only.
this way this dialog can be useful.

Thanks, 
Gilad.

- Original Message -
 From: Oved Ourfalli ov...@redhat.com
 To: Ramesh rnach...@redhat.com
 Cc: engine-devel@ovirt.org
 Sent: Monday, December 2, 2013 9:01:52 AM
 Subject: Re: [Engine-devel] Adding users and assigning roles in Ovirt
 
 Your E-mail made me look a bit and check the different flows.
 
 I think the only use-case for adding users without giving any permissions is
 when you add a user for notification reasons.
 You can add a user, and then in the Event Notifier sub-tab define what events
 he will get via E-mail.
 afaik (and I'm not an event notifier expert), this user doesn't have to be
 able to login, or to have permissions of any kind. He just gets events.
 
 Other than that you're right. A user which is added to the system can't do
 much without assigning him roles.
 I think adding roles assignment to this dialog may be a bit cumbersome.
 Perhaps some wizard is required in that case. Or at least some checkbox
 saying allow user to login. That way the new user will be able to login,
 and he will have some default permissions as well (permissions granted to
 Everyone).
 
 Let's see what others think.
 
 Regards,
 Oved
 
 
 - Original Message -
  From: Ramesh rnach...@redhat.com
  To: engine-devel@ovirt.org
  Sent: Monday, December 2, 2013 7:22:53 AM
  Subject: [Engine-devel] Adding users and assigning roles in Ovirt
  
  Hi All,
  
 We have 'Add' action under 'Users' main tab to add users in Ovirt .
  It looks slightly different from the Add user option of the Configure
  option. Actually, this one is missing the Role to Assign option. I
  think without assigning any role, adding a user is not meaningful and it
  didn't complete the flow.
  
 Currently to assign any role to the user, either we have to use
  'Configure' option ( to add system permission) or we have to go to the
  specific entity and add permission for that entity. It will be nice if
  we can assign roles( system level permissions) while adding users in
  'Users' tab itself. It will be a clear user flow where one can add user
  and assign role in the same place.
  
  I have attached both the screen shots.
  
  please share your thoughts.
  
  Regards,
  Ramesh
  
  
  ___
  Engine-devel mailing list
  Engine-devel@ovirt.org
  http://lists.ovirt.org/mailman/listinfo/engine-devel
  
 ___
 Engine-devel mailing list
 Engine-devel@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/engine-devel
 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Usage of 'Comment' field in Cluster

2013-10-29 Thread Gilad Chaplik

- Original Message -
 From: Mike Kolesnik mkole...@redhat.com
 To: engine-devel engine-devel@ovirt.org
 Sent: Tuesday, October 29, 2013 1:52:16 PM
 Subject: Re: [Engine-devel] Usage of 'Comment' field in Cluster

 - Original Message -
  Hi All,

I see a new field in Cluster called 'Comment'. It is available in
  'New/Edit Cluster' dialog as well as in the 'Clusters Tab'. The Comment
  column in the clusters table shows a 'note' icon when some comment is
  set for a cluster. I just want to understand the right usage of this field.

  Can someone please clarify this?

 +1

 Also please explain the difference between comment and description fields
 since they both appear there, seemingly with same meaning..?

The comment field is a free text area where you can put a temporary notion for 
an entity.
The description is less likely to change (explains what this entity is for), 
whereas in comment field you can add something like: 
Please don't power off the VM without talking to XYZ or The DC is under 
maintenance till XYZ.

Thanks, 
Gilad.

  Thanks,
  Kanagaraj

 ___
 Engine-devel mailing list
 Engine-devel@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/engine-devel

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] disk quota broken in latest master

2013-09-22 Thread Gilad Chaplik

Hi,

looks like the quota drop-down isn't getting refreshed according to selected 
storage domain.
can you please open a bug?

Thanks, 
Gilad.

- Original Message -
 From: Dead Horse deadhorseconsult...@gmail.com
 To: engine-devel engine-devel@ovirt.org
 Sent: Friday, September 20, 2013 9:44:20 PM
 Subject: Re: [Engine-devel] disk quota broken in latest master
 
 In further testing I note that assign quota under the disks tab of the
 associated vm in the admin portal does work.
 - DHC
 
 
 On Fri, Sep 20, 2013 at 2:24 PM, Dead Horse  deadhorseconsult...@gmail.com 
 wrote:
 
 
 
 
 really attach the logs
 
 I also notice that disks tab is no longer showing a disk inventory as well.
 
 - DHC
 
 
 On Fri, Sep 20, 2013 at 2:15 PM, Dead Horse  deadhorseconsult...@gmail.com 
 wrote:
 
 
 
 When attempting to add a disk from either the admin or power user portals the
 according disk quota associated with the requested storage domain cannot be
 assigned to the disk. The disk quota pull-down only will only display
 whatever quota is first in the list alphabetically.
 - DHC
 
 engine and vdsm logs attached.
 
 2013-09-20 13:56:36,810 INFO [org.ovirt.engine.core.bll.
 LoginUserCommand] (ajp--127.0.0.1-8702-4) Running command: LoginUserCommand
 internal: false.
 2013-09-20 13:56:36,833 INFO
 [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
 (ajp--127.0.0.1-8702-4) Correlation ID: null, Call Stack: null, Custom Event
 ID: -1, Message: User admin@internal logged in.
 2013-09-20 13:56:45,775 ERROR
 [org.ovirt.engine.core.utils.servlet.ServletUtils] (ajp--127.0.0.1-8702-6)
 Can't read file /usr/share/doc/ovirt-engine/manual/DocumentationPath.csv
 for request /docs/DocumentationPath.csv, will send a 404 error response.
 2013-09-20 13:57:00,456 INFO [org.ovirt.engine.core.bll.quota.QuotaManager]
 (DefaultQuartzScheduler_Worker-72) Quota Cache updated. (26 msec)
 2013-09-20 13:57:01,810 INFO [org.ovirt.engine.core.bll.AddDiskCommand]
 (ajp--127.0.0.1-8702-10) Lock Acquired to object EngineLock [exclusiveLocks=
 key: ca3cecf1-090e-469a-aaad-e26ce47f89d8 value: VM_DISK_BOOT
 , sharedLocks= key: ca3cecf1-090e-469a-aaad-e26ce47f89d8 value: VM
 ]
 2013-09-20 13:57:01,863 ERROR [org.ovirt.engine.core.bll.quota.QuotaManager]
 (ajp--127.0.0.1-8702-10) Quota storage parameters from command:
 org.ovirt.engine.core.bll.AddDiskCommand. Storage domain does not match
 quota
 2013-09-20 13:57:01,901 INFO
 [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
 (ajp--127.0.0.1-8702-10) Correlation ID: 5790e811, Job ID:
 7abd0b95-4cd4-4cb5-864c-d51c4446a42d, Call Stack: null, Custom Event ID: -1,
 Message: Missing Quota for Disk, proceeding since in Permissive (Audit)
 mode.
 2013-09-20 13:57:01,937 INFO [org.ovirt.engine.core.bll.AddDiskCommand]
 (ajp--127.0.0.1-8702-10) Running command: AddDiskCommand internal: false.
 Entities affected : ID: ca3cecf1-090e-469a-aaad-e26ce47f89d8 Type: VM, ID:
 26be0640-01a3-415d-82c9-0a92f2f84c3f Type: Storage
 2013-09-20 13:57:02,325 INFO
 [org.ovirt.engine.core.bll.AddImageFromScratchCommand]
 (ajp--127.0.0.1-8702-10) Running command: AddImageFromScratchCommand
 internal: true. Entities affected : ID: 26be0640-01a3-415d-82c9-0a92f2f84c3f
 Type: Storage
 2013-09-20 13:57:02,446 INFO
 [org.ovirt.engine.core.bll.AddImageFromScratchCommand]
 (ajp--127.0.0.1-8702-10) Lock freed to object EngineLock [exclusiveLocks=
 key: ca3cecf1-090e-469a-aaad-e26ce47f89d8 value: VM_DISK_BOOT
 , sharedLocks= key: ca3cecf1-090e-469a-aaad-e26ce47f89d8 value: VM
 ]
 2013-09-20 13:57:02,451 INFO
 [org.ovirt.engine.core.vdsbroker.irsbroker.CreateImageVDSCommand]
 (ajp--127.0.0.1-8702-10) START, CreateImageVDSCommand( storagePoolId =
 5849b030-626e-47cb-ad90-3ce782d831b3, ignoreFailoverLimit = false,
 storageDomainId = 26be0640-01a3-415d-82c9-0a92f2f84c3f, imageGroupId =
 bf6458bc-627a-4399-822d-f72751edf303, imageSizeInBytes = 1073741824,
 volumeFormat = RAW, newImageId = 165089b7-4737-4900-9a7f-d2d888ec3514,
 newImageDescription = ), log id: 1ef8212d
 2013-09-20 13:57:02,454 INFO
 [org.ovirt.engine.core.vdsbroker.irsbroker.CreateImageVDSCommand]
 (ajp--127.0.0.1-8702-10) -- executeIrsBrokerCommand: calling 'createVolume'
 with two new parameters: description and UUID
 2013-09-20 13:57:02,456 INFO
 [org.ovirt.engine.core.vdsbroker.irsbroker.CreateImageVDSCommand]
 (ajp--127.0.0.1-8702-10) -- createVolume parameters:
 
 sdUUID=26be0640-01a3-415d-82c9-0a92f2f84c3f
 
 spUUID=5849b030-626e-47cb-ad90-3ce782d831b3
 
 imgGUID=bf6458bc-627a-4399-822d-f72751edf303
 
 size=1,073,741,824 bytes
 
 volFormat=RAW
 
 volType=Sparse
 
 volUUID=165089b7-4737-4900-9a7f-d2d888ec3514
 
 descr=
 
 srcImgGUID=----
 
 srcVolUUID=----
 
 
 2013-09-20 13:57:02,489 INFO
 [org.ovirt.engine.core.vdsbroker.irsbroker.CreateImageVDSCommand]
 (ajp--127.0.0.1-8702-10) FINISH, CreateImageVDSCommand, return:
 165089b7-4737-4900-9a7f-d2d888ec3514, log id:

Re: [Engine-devel] [oVirt/RHEV 3.3 Localization Question #14] No Position

2013-08-12 Thread Gilad Chaplik

- Original Message -
 From: Yuko Katabami ykata...@redhat.com
 To: engine-devel@ovirt.org
 Sent: Monday, August 12, 2013 5:07:59 AM
 Subject: [Engine-devel] [oVirt/RHEV 3.3 Localization Question #14] No
 Position
 
 Hello again.
 
 I would like to ask one more question with the following details:
 
 File: ApplicationConstants
 Resource ID: noPositionFilter
 Strings: No Position
 Question: Could anyone please explain the usage of this string and where in
 the Admin Portal it appears?

Hi Yuko,

Configure - Cluster Policies.
when adding a filter you may specify it will be invoked first/last in line. 
to remove it from being first/last to no position, use context menu on the 
selected filter.

Thanks, 
Gilad.

 
 Thank you,
 
 Yuko
 
 
 --
 Regards,
 
 Yuko Katabami (方波見裕子)
 Technical Translator II
 NAATI Accredited Professional Translator (English into Japanese) #28138
 RHCSA #111-119-244
 Mobile: +61 415 847 352
 Email: ykata...@redhat.com
 
 
 
 Red Hat, Asia-Pacific Pty Ltd
 Level 1, 193 North Quay
 Brisbane 4000
 Office: +61 7 3514 8100
 Fax: +61 7 3514 8199
 Website: www.redhat.com
 
 Facebook: Red Hat APAC | Red Hat Japan | Red Hat Korea | JBoss APAC
 Twitter: Red Hat APAC | Red Hat ANZ
 LinkedIn: Red Hat APAC | JBoss APAC
 
 ___
 Engine-devel mailing list
 Engine-devel@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/engine-devel
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] [oVirt 3.3 Localization Question #8] Cluster Policy Function Label Weights Modules

2013-08-05 Thread Gilad Chaplik

- Original Message -
 From: Yuko Katabami ykata...@redhat.com
 To: engine-devel@ovirt.org
 Sent: Monday, August 5, 2013 9:52:18 AM
 Subject: [Engine-devel] [oVirt 3.3 Localization Question #8] Cluster Policy 
 Function Label Weights Modules

 Hello all,

 I would like to ask another question:

 File: ApplicationConstants
 Resource ID: clusterPolicyFunctionLabel
 String: Weights Modules
 Question: Could anyone please describe what this is referring to and where on
 the portal it appears?

Hi Yuko,

it appears at: Configure (system level entity) - cluster policies.

I'm going to add descriptions (=blue info icons) next to each section with the 
following text:

Filter:
Filters represents hard constraints for running a VM.
Each filter implements logic which validates a minimum requirements in order to 
run a VM.
For example, minimum RAM, CPU, designated host, etc. Hosts who fail this 
validation
are filtered out from the current request.

Weight:
Weights represent soft constraints for running a VM.
Note: in a weighting system, lower score is considered better. So a host with 
the
lowest score (weight) is the one the scheduler will choose.
Each weight module scores any given host based on an optimization logic the 
module
implements. For example, if we want to optimize for CPU load, the module will 
score
each host based on its known CPU load.
Weight modules scores are being summed, so it is possible to have more than one
weight module. The way to prioritize modules is by increasing / decreasing a 
factor.

Balance:
Load balancing is a logic that determines which hosts are over-utilized and 
which
are under-utilized. Then, the balancing mechanism calls the scheduler trying to
migrate a VM from an over-utilized to an under-utilized host. 
Note that it is important to choose a balancing module that does not conflict 
with
the weight module. Such a policy may destabilize this cluster.
Only a single load-balancing module is supported.

Custom properties:
These properties are needed for one of the above modules, so they will appear 
when
needed. Setting it when creating a policy generates the default values, which 
may
be overridden in each specific cluster using this policy.

(high level feature description: http://wiki.ovirt.org/Features/oVirtScheduler).

Thanks, 
Gilad.

 Thank you,

 Yuko

 --
 Regards,

 Yuko Katabami (方波見裕子)
 Technical Translator II
 NAATI Accredited Professional Translator (English into Japanese) #28138
 RHCSA #111-119-244
 Mobile: +61 415 847 352
 Email: ykata...@redhat.com

 Red Hat, Asia-Pacific Pty Ltd
 Level 1, 193 North Quay
 Brisbane 4000
 Office: +61 7 3514 8100
 Fax: +61 7 3514 8199
 Website: www.redhat.com

 Facebook: Red Hat APAC | Red Hat Japan | Red Hat Korea | JBoss APAC
 Twitter: Red Hat APAC | Red Hat ANZ
 LinkedIn: Red Hat APAC | JBoss APAC

 ___
 Engine-devel mailing list
 Engine-devel@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/engine-devel

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] oVirt Scheduler API Design

2013-05-29 Thread Gilad Chaplik

inline.

- Original Message -
 From: Ofri Masad oma...@redhat.com
 To: Laszlo Hornyak lhorn...@redhat.com
 Cc: Gilad Chaplik gchap...@redhat.com, engine-devel 
 engine-devel@ovirt.org
 Sent: Wednesday, May 29, 2013 9:46:40 AM
 Subject: Re: [Engine-devel] oVirt Scheduler API Design

 Hi Gilad,

 two questions about the 'balance' api.
 1. do we filter out all VMs which cannot be migrated before passing the list
 to the 'balance' method? otherwise, the user-implemented code may select a
 VM which cannot be migrated for some reason.
 2. do we make sure that the user-implemented 'balance' method do not select
 the same VM over and over again? if the 'balance' selects a non-migrateable
 VM (like described in 1 above) the VM will not migrate and the exact same
 input will be passed again. (infinite loop)

hi Ofri, 
the answer is no for both questions.
balance is a periodic task that oVirt (we) use for VM balancing, the user can 
use it for all other actions exposed by the REST and not even use our mechanism 
(return VM=null), having said that I don't think we should make the api more 
complicated only because we want the user to work like us.
so yes the user is responsible to prevent loops and not selecting 
non-migratable vms.

 thanks
 Ofri

 - Original Message -
  From: Laszlo Hornyak lhorn...@redhat.com
  To: Gilad Chaplik gchap...@redhat.com
  Cc: engine-devel engine-devel@ovirt.org
  Sent: Wednesday, May 29, 2013 3:23:12 AM
  Subject: Re: [Engine-devel] oVirt Scheduler API Design

  Hi Gilad,

  Some questions to start the discussion :)
  External scheduler API:
   - Why are you mixing xml into json?

JSON is preferable. I use xml because the ovirt-python-sdk supports xml-python 
conversion, and when it'll support JSON we'll use that.

   - I am missing from the documentation how the external scheduler can
   communicate to the engine

XML-RPC
I think it's written there (somewhere :))

  Thx,
  Laszlo

  - Original Message -
   From: Gilad Chaplik gchap...@redhat.com
   To: engine-devel engine-devel@ovirt.org
   Sent: Tuesday, May 28, 2013 4:34:11 PM
   Subject: [Engine-devel] oVirt Scheduler API Design

   Hi all,

   Attached links for oVirt Scheduler API design wiki page.

   High level overview: http://www.ovirt.org/Features/oVirtScheduler
   Detailed design: http://www.ovirt.org/Features/oVirtSchedulerAPI

   You are more than welcome to share you thoughts.

   Thanks,
   Gilad.
   ___
   Engine-devel mailing list
   Engine-devel@ovirt.org
   http://lists.ovirt.org/mailman/listinfo/engine-devel

  ___
  Engine-devel mailing list
  Engine-devel@ovirt.org
  http://lists.ovirt.org/mailman/listinfo/engine-devel

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

[Engine-devel] oVirt Scheduler API Design

2013-05-28 Thread Gilad Chaplik

Hi all, 

Attached links for oVirt Scheduler API design wiki page.

High level overview: http://www.ovirt.org/Features/oVirtScheduler
Detailed design: http://www.ovirt.org/Features/oVirtSchedulerAPI

You are more than welcome to share you thoughts.

Thanks, 
Gilad.
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] enable column resizing on all sub-tabs?

2013-04-25 Thread Gilad Chaplik

imo the preliminary patches (separated or not) should be only adding the 
missing columns widths.
once done, a single patch should activate column re-sizing in a single shot 
-i.e removing the method (enableColumn...) and enabling the feature.
btw, what is the time in Boston?

Thanks, 
Gilad.

- Original Message -
 From: Einav Cohen eco...@redhat.com
 To: Vojtech Szocs vsz...@redhat.com
 Cc: Daniel Erez de...@redhat.com, Alona Kaplan alkap...@redhat.com, 
 Tal Nisan tni...@redhat.com,
 gchap...@redhat.com, engine-devel engine-devel@ovirt.org
 Sent: Thursday, April 25, 2013 10:30:48 AM
 Subject: enable column resizing on all sub-tabs?
 
 Vojtech[/others] - what do you think about Gilad's comment below?
 would it be possible / more correct to activate column resizing within the
 base grid class itself by default (or something similar), rather than enable
 it separately for each grid?
 
 [@Gilad - keep in mind that IIUC - each column in each grid still needs to
 have
 its width explicitly set]
 
 
 Thanks,
 Einav
 
 - Original Message -
  From: gchap...@redhat.com
  To: Daniel Erez de...@redhat.com
  Cc: Einav Cohen eco...@redhat.com, Vojtech Szocs vsz...@redhat.com,
  Alona Kaplan alkap...@redhat.com,
  Tal Nisan tni...@redhat.com
  Sent: Thursday, April 25, 2013 3:23:56 AM
  Subject: Change in ovirt-engine[master]: webadmin: DataCenters main-tab:
  sub-tabs resizable columns
  
  Gilad Chaplik has posted comments on this change.
  
  Change subject: webadmin: DataCenters main-tab: sub-tabs resizable columns
  ..
  
  
  Patch Set 4:
  
  why we need to invoke getTable().enableColumnResizing() on each sub-tab?
  don't we want all grid subtabs to have column resizing?
  
  --
  To view, visit http://gerrit.ovirt.org/14105
  To unsubscribe, visit http://gerrit.ovirt.org/settings
  
  Gerrit-MessageType: comment
  Gerrit-Change-Id: I71465d36e5c18ecb8eb6dbca436feaeea1c902a9
  Gerrit-PatchSet: 4
  Gerrit-Project: ovirt-engine
  Gerrit-Branch: master
  Gerrit-Owner: Daniel Erez de...@redhat.com
  Gerrit-Reviewer: Alona Kaplan alkap...@redhat.com
  Gerrit-Reviewer: Daniel Erez de...@redhat.com
  Gerrit-Reviewer: Einav Cohen eco...@redhat.com
  Gerrit-Reviewer: Gilad Chaplik gchap...@redhat.com
  Gerrit-Reviewer: Tal Nisan tni...@redhat.com
  Gerrit-Reviewer: Vojtech Szocs vsz...@redhat.com
  
 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] oVirt Engine GUI: builders infrastructure - meeting minutes

2013-03-06 Thread Gilad Chaplik

- Original Message -
 From: Einav Cohen eco...@redhat.com
 To: Tomas Jelinek tjeli...@redhat.com, engine-devel 
 engine-devel@ovirt.org
 Cc: Alona Kaplan alkap...@redhat.com, Daniel Erez de...@redhat.com, 
 Gilad Chaplik gchap...@redhat.com,
 Vojtech Szocs vsz...@redhat.com
 Sent: Tuesday, March 5, 2013 7:17:59 PM
 Subject: oVirt Engine GUI: builders infrastructure - meeting minutes

 - Problem and proposed solution in a nutshell:

* we have a lot of duplication in the GUI code that can be
eliminated
 using the builders infrastructure, which attempts to solve the
 problem by breaking
 down the logic to atomic particles, which can be (re)used as
 necessary.

* Tomas came up with the solution when planning the implementation
of the GUI code
 for the new Instance Types and Images [1] business entities (which
 are VM-related
 business entities, and the VM-related GUI code already have a lot of
 code
 duplication), when he realized that additional code duplication would
 have
 to be introduced unless some kind of new infrastructure/refactoring
 will be done.

 - Inheritance?

* Code duplication exists across the entire GUI code, not only in
the VM-related
 parts of it. It seems that an inheritance solution in the Networking
 code has already
 been introduced by Alona, and is possibly applicable to VM-related
 code as well.

* Tomas has already tried the inheritance approach, however the
result hasn't
 introduced a significant improvement to the current state of the
 code.

* Derez/Alona will help Tomas with trying to figure out the most
 correct way to solve the code-duplication problem by inheritance.

* If it will be concluded that an inheritance solution is not
feasible, we will
 think of an alternative (builders, something else, stay with code
 duplication(???)),
 but we would really like to try and utilize the code inheritance, as
 it is already
 successfully used in other parts of the GUI code that had similar
 problems.

 - Need to keep in mind potential future plans for the GUI code:

* moving to REST API business entities and REST API in general
[Java(script?) SDK]

* eliminating some entity models, and binding the view directly to
the REST API
 business entities (possibly using decorators?). Need to keep in mind
 that a lot
 of the models will still need to be retained, e.g. since they are
 stateful (e.g. list model
 holds selected item(s)).

small note: I think that stateless won't be a big deal (there are places in the 
code that we
consider list model as stateless).

* grouping several queries together, allowing to load data into a
dialog, for
 example, in a single bulk, rather than calling 20 different queries
 (New VM dialog
 and alike are the most painful - can take a lot of time to load,
 especially on WAN).

I think that all other issues are insignificant comparing to this one.
If we invest the resources to refactor this area, this should be our primary 
goal.
different approaches may lead us to have the same talk/cycle in the near future.

I think that each of the items you've mentioned here is more than enough to 
postpone/delay/rethink
the solution for this issue; maybe propose a quick POC instead of investing 
time in sth that could/may
change soon.

[FYI: I think that inheritance is the way to go, but on the servlet side... 
we should call a single query to fill out the entire dialog]

Great discussion! and thanks you Tomas :-)

Gilad.

 - I would like to thank:

* Tomas for his excellent presentation of the problem and the
 builders infrastructure solution (slides attached).

* All other participants in the meeting for taking the time
 to listen, express their opinion and helping Tomas in this issue.

 [Participants: feel free to add to/amend the above as necessary]

 Best Regards,
 Einav

 [1] http://www.ovirt.org/Features/Instance_Types

 - Original Message -
  From: Tomas Jelinek tjeli...@redhat.com
  To: eco...@redhat.com, engine-devel@ovirt.org
  Sent: Tuesday, March 5, 2013 9:21:27 AM
  Subject: [Engine-devel] oVirt Engine GUI: builders infrastructure
  feedback (conf: 712 886 7405#)

  attaching the slides

  - Original Message -
   The following is a new meeting request:

   Subject: oVirt Engine GUI: builders infrastructure feedback
   (conf:
   712 886 7405#)
   Organizer: Einav Cohen eco...@redhat.com

   Location: Intercall conf code: 712 886 7405#
   Time: Tuesday, March 5, 2013, 9:30:00 AM - 11:00:00 AM GMT -05:00
   US/Canada Eastern

   Invitees: tjeli...@redhat.com; engine-devel@ovirt.org

   *~*~*~*~*~*~*~*~*~*

   Following the correspondence in the builders infrastructure patch
   [1]
   and engine-devel thread [2]:
   In the first part of the meeting, Tomas Jelinek
   tjeli...@redhat.com
   will present his builders infrastructure solution.
   In the second part of the meeting, we will hear feedback about

Re: [Engine-devel] [engine-devel] frontend builders proposal

2013-01-28 Thread Gilad Chaplik

- Original Message -
 From: Eli Mesika emes...@redhat.com
 To: Tomas Jelinek tjeli...@redhat.com
 Cc: engine-devel@ovirt.org
 Sent: Saturday, January 26, 2013 10:58:57 PM
 Subject: Re: [Engine-devel] [engine-devel] frontend builders proposal

 - Original Message -
  From: Tomas Jelinek tjeli...@redhat.com
  To: engine-devel@ovirt.org
  Sent: Friday, January 25, 2013 11:55:43 AM
  Subject: [Engine-devel] [engine-devel] frontend builders proposal

  Hi All,

  as many of you may know, the way how the frontend and backend
  models
  are built on frontend (uicommonweb project) is not really ideal.
  Currently this logic is copy pasted over and over again to
  different
  places where it is needed with minor changes to fulfill the
  specific
  requirements. It is not only aesthetically problematic, but I
  recall
  tons of bugs caused by introducing a new field and forgetting to
  add
  it to every place it is used in GUI.

  Now, as there will be big changes in the VM/Template models
  (http://www.ovirt.org/Features/Instance_Types), so the way how the
  VM, Template, Pool and also the newly created Instance Types models
  are being built has to be touched anyhow, it is a great opportunity
  to rethink the way how we do it.

  I have created a simple infrastructure
  (http://gerrit.ovirt.org/#/c/10874/) which could be used for it,
  and
  a PoC patch which uses this infrastructure
  (http://gerrit.ovirt.org/#/c/11354/). Please note that the PoC is
  not really impressive in means of removing duplications, I wanted
  to
  start with the simplest possibility.

  The principles behind the infrastructure:
  - have small, well named, easy to understand and reuse builders
  - this builders can be chained together or embedded to each other
  to
  build the full resulting object (composite pattern)
  - this builders can be asynchronous, and the next builder in the
  chain has to be executed only when the current is completely done

  The structure:
  - the base is an interface called Builder which has a method
  build(source, destination, rest)
  - the builder implementing this interface
+ will get the source and destination objects
+ copies whatever he wants from source to destination
+ when done, executes build on the first element of the rest
  + this may sound awkward, but this is the way how the async
  calls
  can be linearized in a general way, not embedding anonymous
  class into anonymous
class into anonymous class... as we do it today.
  + for synchronous builders, there is a BaseSyncBuilder which
  takes care of this boilerplate calling of next and exposes a
  simple method
build(S source, D destination)
+ to simplify the creating and running the chain of builders,
there
is a BuilderExecutor class (can be created as sync or async)

  So, a simple example - even more simple than the PoC patch :)

  //create the first builder
  class FirstLetterBuilder extends BaseSyncBuilderString,
  StringBuilder {
   @Override
   protected void build(String source, StringBuilder destination) {
   // copy the first letter to the destination
   destination.append(source.charAt(0));
   }
  }

  //create the second builder
  class SecondLetterBuilder extends BaseSyncBuilderString,
  StringBuilder {
   @Override
   protected void build(String source, StringBuilder destination) {
   // copy the second letter to the destination
   destination.append(source.charAt(1));
   }
  }

  // usage
  ...
  // create the destination object
  StringBuilder res = new StringBuilder();

  // configure the executor with the two builders
  BuilderExecutorString, StringBuilder executor = new
  BuilderExecutorString, StringBuilder(
  new FirstLetterBuilder(),
  new SecondLetterBuilder()
  );

  // execute the builder chain (ab is the source, res the
  destination)
  executor.build(ab, res);

  // use the result
  ...

  That's it. And the nice part is, that this FirstLetterBuilder and
  SecondLetterBuilder can be reused anywhere or combined with any
  other builders.

  Any comments on this will be more than welcome!

 great and really simplifies work and eliminate bugs resulted from
 copy/past code
 gave +1
 Thanks
 Eli

Hi guys,

I agree that this refactoring can significantly help us reduce code complexity,
there is another issue that your suggestion doesn't address, 
but we may want take the opportunity to address it if we are already 
considering refactoring for this code:
this dialog demonstrates the greatest difference (IMHO) between server side 
pages to applets,
the back and forth filling the form by retrieving all elements one by one.
I would think of a concept similar to server side pages, i.e. retrieving all
data, visibility and even validations (compat?), in a single request, and let 
the
server have the logic.

Thanks, 
Gilad.

  Thank you,
  Tomas

Re: [Engine-devel] Revisiting Java7

2012-12-18 Thread Gilad Chaplik

- Original Message -
 From: Roy Golan rgo...@redhat.com
 To: engine-devel@ovirt.org
 Sent: Tuesday, December 18, 2012 10:31:37 AM
 Subject: Re: [Engine-devel] Revisiting Java7

 another motive End of Public Updates for Java SE 6 
 https://blogs.oracle.com/java/entry/end_of_public_updates_for

I think we can wait with the change, there are no complains yet..

 On 12/04/2012 08:25 PM, Asaf Shakarchi wrote:
  - Original Message -
  On 12/04/2012 03:53 PM, Alon Bar-Lev wrote:

  - Original Message -
  From: Itamar Heim ih...@redhat.com
  To: Allon Mureinik amure...@redhat.com
  Cc: engine-devel engine-devel@ovirt.org
  Sent: Tuesday, December 4, 2012 1:13:49 PM
  Subject: Re: [Engine-devel] Revisiting Java7

  On 12/04/2012 11:20 AM, Allon Mureinik wrote:

  - Original Message -
  From: Itamar Heim ih...@redhat.com
  To: Allon Mureinik amure...@redhat.com
  Cc: engine-devel engine-devel@ovirt.org
  Sent: Tuesday, December 4, 2012 1:40:10 AM
  Subject: Re: [Engine-devel] Revisiting Java7

  On 12/03/2012 04:03 PM, Allon Mureinik wrote:
  Hi guys,

  Earlier today, Java6 compatibility was broken
  (http://gerrit.ovirt.org/#/c/9430/).
  This was picked up on pretty quickly, and easily fixed
  (http://gerrit.ovirt.org/#/c/9666/).

  However, I think this is a good opportunity to revisit our
  policy
  towards Java 7.
  Currently, we have an odd setup, where we recommend running
  a
  compiling /with/ Java 7 [1] but comply to Java 6 language
  level
  [2] and JDK [3].
  Inevitably, mistakes like the that happened today will
  happen.

  I know we're holding back due to GWT issues, but looking
  forward
  to
  oVirt 4.0, is Java 7 on our roadmap?
  what was the GWT issue?
  GWT 2.3 that we use doesn't support java 7 syntax.
  The latest version, 2.5, doesn't either.
  I'm not sure, however, this is a good reason to enforce the
  java
  6
  limitation on the entire project (including backed, rest, etc.)
  i agree. you can limit it to the parts used by GWT for now.
  The major advantage to move to java7 is the try-with-resources
  statement.

  If we can do this for 3.2 it will be great. From what I
  understand
  from Allon, the only noisy change is to move the common and
  compat
  out of the backend directory into its own top-level directory, so
  we can apply a different maven policy on these two easily.

  This way the common/compat and frontend will be built using 1.6
  and
  backend will be built using 1.7.
  and searchbackend.
  asaf, is there no easier way to enable java 7
  compilation/enforcement
  except for these 3?
  In the long run consider having a project layer such as :
  Frontend / Backend / Shared [common/compat/searchbackend] , this
  will allow us to use plugins inheritance cleanly [regarding
  versions],

  Of course inheritance is nicer but it requires a lot of movements
  (maybe in v4?)

  For now its easy - we can just use the maven-compiler to define
  source/target of [v1.7] for the root project, while defining
  explicitly different versions per frontend/shared module [v1.6]
  Checkstyles should be upgraded as well.
  ___
  Engine-devel mailing list
  Engine-devel@ovirt.org
  http://lists.ovirt.org/mailman/listinfo/engine-devel

 ___
 Engine-devel mailing list
 Engine-devel@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/engine-devel

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

[Engine-devel] default config value (vdc_options; general)

2012-12-03 Thread Gilad Chaplik

hi all,

In engine config table (vdc_options), when an option has a general as its 
version, and we fetch by version,
we aren't getting the general value, rather the default one (hard coded in the 
config value enum)

Is this the wanted behavior and why?
According to it general is some-kind of a version number instead of a 
configurable fallback to a missing version.

NOTE: currently there isn't any configurable default; in case the hard coded 
default != your configurable default, 
you need to specify it for each version.

I will be glad to fix it.

Thanks, 
Gilad.

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Managing permissions on network

2012-11-14 Thread Gilad Chaplik

- Original Message -
 From: Itamar Heim ih...@redhat.com
 To: Livnat Peer lp...@redhat.com
 Cc: engine-devel@ovirt.org, Michal Skrivanek mskri...@redhat.com, Andrew 
 Cathrow acath...@redhat.com, Gilad
 Chaplik gchap...@redhat.com, Doron Fediuck dfedi...@redhat.com
 Sent: Tuesday, November 13, 2012 8:19:01 PM
 Subject: Re: [Engine-devel] Managing permissions on network

 On 11/13/2012 07:18 PM, Livnat Peer wrote:
  On 13/11/12 15:39, Itamar Heim wrote:
  On 11/13/2012 03:37 PM, Livnat Peer wrote:
  On 13/11/12 15:19, Itamar Heim wrote:
  On 11/13/2012 12:45 PM, Livnat Peer wrote:
  Interesting point, I think that if a user has permission to
  create a VM
  from a specific template we should give him permission to use
  the
  template networks on this VM implicitly upon the VM creation.

  having a permission to a template does not mean a permission to
  the
  default network of that VM, especially as we'll use templates
  more as
  instance types.

  Another alternative is to require permission on the network as
  well as
  the template.
  I must say I don't really like it, although I agree with your
  comment,
  we require too many operations for enabling a user to create a VM
  from
  template (permission on the template, quota on the storage,
  permissions
  on the network, next we'll require a PHD ;)).

  Anyone has a better idea?

  I assume most networks would be given either to 'everyone' or
  groups of
  users, not per user (and if the network is per user/tenant, then
  it must
  be done per user.

  Which reminds that I wanted to propose adding a property on a
  network
  which is called public.
  It's just a UI feature to give a NetworkUser on this network to
  'everyone'. It makes making a network public easier for the user.

  In addition during upgrade we should make all existing networks
  public
  networks and not allocate specific permissions for users on
  networks.

  In addition it also means a user is given permission on a network
  and
  then he can use it for any VM he owns. Isn't that problematic? We
  can't
  limit a user to use a network on a specific VM.

 I think that's fine.
 don't let user edit that vm if you don't trust them.

  i may not remember correctly, but i thought when giving quota to
  user we
  also give some permissions with it (on cluster and storage)?

  I am not sure what is the current implementation as it changed a
  lot,
  but last I tracked we checked for either quota or permissions we
  did not
  give implicit permissions when creating a quota.

 gilad/doron?

No implicit permissions. IIRC it was never implemented

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Do we need genericApi project?

2012-06-10 Thread Gilad Chaplik

we don't use GetUserActionGroups (it's an unreachable code - can be deleted), 
IMHO we can remove the project.

Thanks, 
Gilad.

- Original Message -
 From: Itamar Heim ih...@redhat.com
 To: Michael Kublin mkub...@redhat.com
 Cc: engine-devel engine-devel@ovirt.org
 Sent: Sunday, June 10, 2012 11:48:53 AM
 Subject: Re: [Engine-devel] Do we need genericApi project?

 On 06/10/2012 11:23 AM, Michael Kublin wrote:
  Hi,

  I found that we have a ovirt-engine/frontend/api/genericapi
  project, which is for my opinion is not at use any more.
  If there are any reason that we want to keep it , maybe someone
  using it and I missed these?

  Thanks Michael
  ___
  Engine-devel mailing list
  Engine-devel@ovirt.org
  http://lists.ovirt.org/mailman/listinfo/engine-devel

 iirc, it's intended to allow to add queries needed for the UI without
 adding them into the core.
 and looking at GetUserActionGroups, I see it is used for example by
 uicommon.

 (GWT still uses the generic api)
 ___
 Engine-devel mailing list
 Engine-devel@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/engine-devel

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] LOCALFS path validation

2012-05-21 Thread Gilad Chaplik

Hi Pahim,

Thanks for the input!
Comments inline.

Thanks, 
Gilad.

- Original Message -
 From: Amador pahim apa...@redhat.com
 To: engine-devel@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@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/engine-devel
 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] custom properties sheet feature page

2012-05-20 Thread Gilad Chaplik


- Original Message -
 From: Gilad Chaplik gchap...@redhat.com
 To: Einav Cohen eco...@redhat.com
 Cc: David Jaša dj...@redhat.com, Eldan Hildesheim i...@eldanet.com, 
 engine-devel@ovirt.org, Eldan
 Hildesheim ehild...@redhat.com, Simon Grinberg sgrin...@redhat.com
 Sent: Friday, May 18, 2012 1:15:16 PM
 Subject: Re: [Engine-devel] custom properties sheet feature page
 
 
 - Original Message -
  From: Einav Cohen eco...@redhat.com
  To: Gilad Chaplik gchap...@redhat.com
  Cc: Eldan Hildesheim i...@eldanet.com, engine-devel@ovirt.org,
  Simon Grinberg sgrin...@redhat.com, Eldan
  Hildesheim ehild...@redhat.com, David Jaša dj...@redhat.com
  Sent: Friday, May 18, 2012 1:02:03 PM
  Subject: Re: [Engine-devel] custom properties sheet feature page
  
   - Original Message -
   From: Gilad Chaplik gchap...@redhat.com
   Sent: Friday, May 18, 2012 12:56:00 PM
  
   - Original Message -
From: David Jaša dj...@redhat.com
To: Gilad Chaplik gchap...@redhat.com
Cc: Einav Cohen eco...@redhat.com, engine-devel@ovirt.org,
Miki Kenneth mkenn...@redhat.com, Andrew Cathrow
acath...@redhat.com, Simon Grinberg sgrin...@redhat.com,
Eldan Hildesheim ehild...@redhat.com, Eldan
Hildesheim i...@eldanet.com
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 eco...@redhat.com
  To: Gilad Chaplik gchap...@redhat.com
  Cc: engine-devel@ovirt.org, David Jaša
  dj...@redhat.com,
  Miki Kenneth mkenn...@redhat.com, Andrew Cathrow
  acath...@redhat.com, Simon Grinberg
  sgrin...@redhat.com,
  Eldan Hildesheim ehild...@redhat.com, Eldan
  Hildesheim i...@eldanet.com
  Sent: Friday, May 18, 2012 12:35:34 PM
  Subject: Re: [Engine-devel] custom properties sheet feature
  page
 
   - Original Message -
   From: Gilad Chaplik gchap...@redhat.com
   Sent: Friday, May 18, 2012 12:25:45 PM
  
   inline
  
   Thanks,
   Gilad.
  
   - Original Message -
From: Einav Cohen eco...@redhat.com
To: David Jaša dj...@redhat.com, Miki Kenneth
mkenn...@redhat.com, Andrew Cathrow
acath...@redhat.com,
Simon Grinberg sgrin...@redhat.com, Eldan
Hildesheim
ehild...@redhat.com, Eldan Hildesheim
i...@eldanet.com, Gilad Chaplik
gchap...@redhat.com
Cc: engine-devel@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 dj...@redhat.com
 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 dj...@redhat.com
   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 dj...@redhat.com
 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

Re: [Engine-devel] restapi: New params for import VM/Template

2012-05-17 Thread Gilad Chaplik

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 lp...@redhat.com
 To: Gilad Chaplik gchap...@redhat.com
 Cc: Michael Pasternak mpast...@redhat.com, engine-devel 
 engine-devel@ovirt.org, Itamar Heim
 ih...@redhat.com
 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
 
 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] git-review error.

2012-05-14 Thread 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: snmis...@linux.vnet.ibm.com
 To: engine-devel@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://snmis...@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://snmis...@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@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/engine-devel
 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] REST-API: Exposing correlation-ID

2012-05-06 Thread Gilad Chaplik

- Original Message -
 From: Ayal Baron aba...@redhat.com
 To: Ori Liel ol...@redhat.com
 Cc: engine-devel@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@ovirt.org
   http://lists.ovirt.org/mailman/listinfo/engine-devel

  ___
  Engine-devel mailing list
  Engine-devel@ovirt.org
  http://lists.ovirt.org/mailman/listinfo/engine-devel

 ___
 Engine-devel mailing list
 Engine-devel@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/engine-devel

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

73 matches

Mail list logo