Re: [Engine-devel] jpa annotations

2012-12-18 Thread Itamar Heim 

On 12/18/2012 03:55 PM, Laszlo Hornyak wrote:

Hi,

We have JPA annotations on the backend entity beans, but they have never been 
actually used as far as I know and now that I looked into VmTemplate for 
example we do not even have a vm_template table anymore, while VmTemplate still 
refers to it.
Any plans with the JPA?



I'm assuming they are from the work on moving to hibernate started a 
long time ago, and question is are we going to finish it anytime soon.



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

Re: [Engine-devel] LDAP: Add support for simple authentication over SSL

2012-12-18 Thread Alon Bar-Lev 


- Original Message -
> From: snmis...@linux.vnet.ibm.com
> To: "Alon Bar-Lev" 
> Cc: snmis...@us.ibm.com, engine-devel@ovirt.org
> Sent: Tuesday, December 18, 2012 11:21:45 PM
> Subject: Re: [Engine-devel] LDAP: Add support for simple authentication over 
> SSL
> 
> 
> Quoting Alon Bar-Lev :
> 
> > - Original Message -
> >> From: snmis...@linux.vnet.ibm.com
> >> To: engine-devel@ovirt.org
> >> Cc: snmis...@us.ibm.com
> >> Sent: Monday, December 17, 2012 6:09:17 PM
> >> Subject: [Engine-devel] LDAP: Add support for simple
> >> authentication over SSL
> >>
> >>
> >> Hi,
> >>
> >> IBM Tivoli Directory Server (ITDS) supports simple
> >> authentication
> >> over SSL. What will it take to add this support? I can help with
> >> this
> >> work item but will need some guidance.
> >>
> >> Regards
> >> Sharad Mishra
> >>
> >
> > Hello,
> >
> > There was a discussion recently regarding this.
> >
> > I paste what I wrote then...
> 
> Alon,
> 
>  Thanks for the prompt reply. Does it mean that we will now be
> passing LDAP protocol as an argument. Here is the patch that does it
> (not a working patch) -
> 

No... it is more than than, please see the attachment I sent.
We need to copy with all combinations of transport and authentication.
We should also add the selected transport and authentication to the 
manage-domains utility and database.
It is not something we can solve in few lines of code if we want to do that 
properly.

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

Re: [Engine-devel] LDAP: Add support for simple authentication over SSL

2012-12-18 Thread snmishra 


Quoting Alon Bar-Lev :


- Original Message -

From: snmis...@linux.vnet.ibm.com
To: engine-devel@ovirt.org
Cc: snmis...@us.ibm.com
Sent: Monday, December 17, 2012 6:09:17 PM
Subject: [Engine-devel] LDAP: Add support for simple authentication over SSL


Hi,

IBM Tivoli Directory Server (ITDS) supports simple authentication
over SSL. What will it take to add this support? I can help with this
work item but will need some guidance.

Regards
Sharad Mishra



Hello,

There was a discussion recently regarding this.

I paste what I wrote then...


Alon,

Thanks for the prompt reply. Does it mean that we will now be  
passing LDAP protocol as an argument. Here is the patch that does it  
(not a working patch) -


@

---  
a/backend/manager/modules/utils/src/main/java/org/ovirt/engine/core/utils/kerberos/JndiAction.java
+++  
b/backend/manager/modules/utils/src/main/java/org/ovirt/engine/core/utils/kerberos/JndiAction.java

@@ -33,14 +33,16 @@ public class JndiAction implements PrivilegedAction {
 private final LdapProviderType ldapProviderType;
 private final StringBuffer userGuid;
 private DnsSRVResult ldapDnsResult;
+private final String ldapProtocol;
 private final static Logger log = Logger.getLogger(JndiAction.class);

-public JndiAction(String userName, String domainName,  
StringBuffer userGuid, LdapProviderType ldapProviderType, DnsSRVResult  
ldapDnsResult) {
+public JndiAction(String userName, String domainName,  
StringBuffer userGuid, LdapProviderType ldapProviderType, DnsSRVResult  
ldapDnsResult, String ldapProtocol) {

 this.userName = userName;
 this.domainName = domainName;
 this.ldapProviderType = ldapProviderType;
 this.userGuid = userGuid;
 this.ldapDnsResult = ldapDnsResult;
+this.ldapProtocol = ldapProtocol;
 }

 @Override
@@ -48,7 +50,7 @@ public class JndiAction implements PrivilegedAction {
 Hashtable env = new Hashtable(11);
 env.put(Context.INITIAL_CONTEXT_FACTORY,  
"com.sun.jndi.ldap.LdapCtxFactory");

 env.put("java.naming.ldap.attributes.binary", "objectGUID");
-env.put(Context.SECURITY_AUTHENTICATION, "GSSAPI");
+env.put(Context.SECURITY_AUTHENTICATION, ldapProtocol);
 env.put("javax.security.sasl.qop", "auth-conf");

 // Send an SRV record DNS query to retrieve all the LDAP  
servers in the domain


@

Thanks
Sharad Mishra



Alon

---

Hello Thierry,

If I understand correctly you wish to help in modifying the engine  
to support non GSSAPI authentication methods.


Following is a quick design goals for this implementation.

I will be glad to improve this.
Alon

---

Implementation should support the following transports:

1. LDAP (plain).
2. LDAP over TLS.
3. LDAP with StartTLS.

Implementation should support the following authentication methods:

1. Simple.
2. Digest-MD5 (plain and strong).

I believe the GSSAPI can be dropped, I see no advantage of using it.

A sample of low level implementation for transport and  
authentication is attached.


When adding a domain the following facts should be provided:

 1. Search user name.
 2. Search user password.
 3. Transport type (ldap, ldaps, ldap+startTLS)
 4. Authentication (simple, Digest-MD5)
 5. Sever selection policy (failover, round-robin, random).
 6. Server address type (explicit, DNS record)
 7. Server address set.
 8. Optional base DN.
 9. Optional root certificate.
10. Optional certificate chain.
11. Search page size.
10. Query timeout.
etc...

Within product there are two separate components that perform LDAP  
authentication:


1. User password validation.
2. User permission fetch.

These two components needs to work in share-nothing mode, meaning  
that each should communicate with directory independently with the  
other.


USER PASSWORD VALIDATION

Input: user
Input: domain
Input: password
Output: DN of user
Output: success/failure
Credentials used: user/password provided.
Notes: LDAP session should not be cached.
Logic: Perform LDAP bind.

USER PERMISSION FETCH

Input: DN of user (passed by user password validation)
Input: domain (passed by user password validation)
Output: A set of permissions
Credentials used: search user and password configured within system.
Notes: LDAP context can be cached.
Logic: Perform LDAP searches, this is most of current logic.




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

Re: [Engine-devel] CPU Overcommit Feature

2012-12-18 Thread Doron Fediuck 


- Original Message -
> From: "Dennis Jacobfeuerborn" 
> To: "Andrew Cathrow" 
> Cc: engine-devel@ovirt.org
> Sent: Tuesday, December 18, 2012 7:59:26 PM
> Subject: Re: [Engine-devel] CPU Overcommit Feature
> 
> On 12/18/2012 06:33 PM, Andrew Cathrow wrote:
> > 
> > 
> > - Original Message -
> >> From: "Dennis Jacobfeuerborn" 
> >> To: engine-devel@ovirt.org
> >> Sent: Tuesday, December 18, 2012 12:30:34 PM
> >> Subject: Re: [Engine-devel] CPU Overcommit Feature
> >>
> >> On 12/17/2012 07:13 PM, Simon Grinberg wrote:
> >>>
> >>>
> >>> - Original Message -
>  From: "Greg Padgett" 
>  To: "engine-devel" 
>  Sent: Monday, December 17, 2012 4:37:57 PM
>  Subject: [Engine-devel] CPU Overcommit Feature
> 
>  Hi,
> 
>  I've been working on a feature to allow CPU Overcommitment of
>  hosts
>  in a
>  cluster.  This first stage allows the engine to consider host
>  cpu
>  threads
>  as cores for the purposes of VM resource allocation.
> 
>  This wiki page has further details, your comments are welcome!
>  http://www.ovirt.org/Features/cpu_overcommit
> >>>
> >>> Basically looking good.
> >>> Hyperthread though is vendor specific.
> >>>
> >>> For AMD it's Clustered Multi-Thread while for Intel it's
> >>> Hyper-Thread
> >>> Official name is  simultaneous multithreading (SMT) but no one
> >>> outside of the academy will recognize that.
> >>>
> >>> in libvirt if I read it right it's  >>> name='thread_siblings'>
> >>>
> >>> So why not just call it threads.
> >>> We'll have cpuSockets, cpiCores, and cpuThreads, should be clear
> >>> when in CPU context.
> >>>
> >>> In the GUI just change hyperthreads to CPU threads. While in the
> >>> tool tip explain that it's either AMD Clustered Multi-Thread or
> >>> Intel Hyperthread
> >>
> >> Does this affect only the number of potential vCpus for the guests
> >> or
> >> does
> >> this also have an impact on the actual scheduling?
> >> So far I always disabled HT out of fear that a 2 vCpu guest might
> >> actually
> >> be scheduled to run in 2 threads of the same core but now I'm not
> >> so
> >> sure
> >> anymore. In the HT case does KVM know that two threads belong to
> >> the
> >> same
> >> core and will it only schedule its vCpus on distinct cores? Is
> >> there
> >> some
> >> documentation about this somewhere?
> > 
> > This is about the maximum number of vCPUs we can give to a VM.
> > If the machine has 32 Physical cores that are hyperthreaded then do
> > we say the max number of vCPUs for a single VM is 32 or 64.
> 
> If the actual scheduling of vCPUs cannot distinguish between threads
> and
> cores then why would you even want to limit yourself to 32 in you
> example?
> In that case the scheduling might end up being inefficient no matter
> how
> many vCPUs you assign to a guest so why restrict the user? (You might
> of
> course want to limit the user for policy reasons but that has nothing
> to to
> with the thread/core topic.)
> 
> On the other hand if KVM does only schedule the vCPUs on distinct
> cores and
> extending the count from 32 to 64 implies that this distinction is to
> be
> disabled then this will have a performance impact for the guest.
> In that case I might want to limit the guests to just the 32 physical
> cores
> so two vCPUs of a single guest don't get scheduled on two threads of
> the
> same core.
> 
> I've never really looked that closely into the scheduling issue but
> it
> might play a role here so I asked if someone had any pointers to
> infos
> about how exactly KVM makes its scheduling decisions.
> 
> Regards,
>   Dennis
> 

Dennis,
first of all every virtual cpu is basically a qemu-thread which can
run on any cpu-thread. The scheduling is done by the kernel scheduler,
while we may control it using cpu pinning. ie- you may ask for
specific vcpu to run on a specific thread which is from the OS
point of view another core.
Indeed there are cases where this is not recommended, but other
cases where this will actually give you a performance boost,
as L1 cache is being shared by the sibling threads.
So it's really up to you to test your workload and decide id you
wish to utilize it or not. We're giving you powerful tools, and
you can decide if and how to use it.

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

Re: [Engine-devel] CPU Overcommit Feature

2012-12-18 Thread Dennis Jacobfeuerborn 
On 12/18/2012 06:33 PM, Andrew Cathrow wrote:
> 
> 
> - Original Message -
>> From: "Dennis Jacobfeuerborn" 
>> To: engine-devel@ovirt.org
>> Sent: Tuesday, December 18, 2012 12:30:34 PM
>> Subject: Re: [Engine-devel] CPU Overcommit Feature
>>
>> On 12/17/2012 07:13 PM, Simon Grinberg wrote:
>>>
>>>
>>> - Original Message -
 From: "Greg Padgett" 
 To: "engine-devel" 
 Sent: Monday, December 17, 2012 4:37:57 PM
 Subject: [Engine-devel] CPU Overcommit Feature

 Hi,

 I've been working on a feature to allow CPU Overcommitment of
 hosts
 in a
 cluster.  This first stage allows the engine to consider host cpu
 threads
 as cores for the purposes of VM resource allocation.

 This wiki page has further details, your comments are welcome!
 http://www.ovirt.org/Features/cpu_overcommit
>>>
>>> Basically looking good.
>>> Hyperthread though is vendor specific.
>>>
>>> For AMD it's Clustered Multi-Thread while for Intel it's
>>> Hyper-Thread
>>> Official name is  simultaneous multithreading (SMT) but no one
>>> outside of the academy will recognize that.
>>>
>>> in libvirt if I read it right it's >> name='thread_siblings'>
>>>
>>> So why not just call it threads.
>>> We'll have cpuSockets, cpiCores, and cpuThreads, should be clear
>>> when in CPU context.
>>>
>>> In the GUI just change hyperthreads to CPU threads. While in the
>>> tool tip explain that it's either AMD Clustered Multi-Thread or
>>> Intel Hyperthread
>>
>> Does this affect only the number of potential vCpus for the guests or
>> does
>> this also have an impact on the actual scheduling?
>> So far I always disabled HT out of fear that a 2 vCpu guest might
>> actually
>> be scheduled to run in 2 threads of the same core but now I'm not so
>> sure
>> anymore. In the HT case does KVM know that two threads belong to the
>> same
>> core and will it only schedule its vCpus on distinct cores? Is there
>> some
>> documentation about this somewhere?
> 
> This is about the maximum number of vCPUs we can give to a VM.
> If the machine has 32 Physical cores that are hyperthreaded then do we say 
> the max number of vCPUs for a single VM is 32 or 64.

If the actual scheduling of vCPUs cannot distinguish between threads and
cores then why would you even want to limit yourself to 32 in you example?
In that case the scheduling might end up being inefficient no matter how
many vCPUs you assign to a guest so why restrict the user? (You might of
course want to limit the user for policy reasons but that has nothing to to
with the thread/core topic.)

On the other hand if KVM does only schedule the vCPUs on distinct cores and
extending the count from 32 to 64 implies that this distinction is to be
disabled then this will have a performance impact for the guest.
In that case I might want to limit the guests to just the 32 physical cores
so two vCPUs of a single guest don't get scheduled on two threads of the
same core.

I've never really looked that closely into the scheduling issue but it
might play a role here so I asked if someone had any pointers to infos
about how exactly KVM makes its scheduling decisions.

Regards,
  Dennis

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

Re: [Engine-devel] CPU Overcommit Feature

2012-12-18 Thread Andrew Cathrow 


- Original Message -
> From: "Dennis Jacobfeuerborn" 
> To: engine-devel@ovirt.org
> Sent: Tuesday, December 18, 2012 12:30:34 PM
> Subject: Re: [Engine-devel] CPU Overcommit Feature
> 
> On 12/17/2012 07:13 PM, Simon Grinberg wrote:
> > 
> > 
> > - Original Message -
> >> From: "Greg Padgett" 
> >> To: "engine-devel" 
> >> Sent: Monday, December 17, 2012 4:37:57 PM
> >> Subject: [Engine-devel] CPU Overcommit Feature
> >>
> >> Hi,
> >>
> >> I've been working on a feature to allow CPU Overcommitment of
> >> hosts
> >> in a
> >> cluster.  This first stage allows the engine to consider host cpu
> >> threads
> >> as cores for the purposes of VM resource allocation.
> >>
> >> This wiki page has further details, your comments are welcome!
> >> http://www.ovirt.org/Features/cpu_overcommit
> > 
> > Basically looking good.
> > Hyperthread though is vendor specific.
> > 
> > For AMD it's Clustered Multi-Thread while for Intel it's
> > Hyper-Thread
> > Official name is  simultaneous multithreading (SMT) but no one
> > outside of the academy will recognize that.
> > 
> > in libvirt if I read it right it's  > name='thread_siblings'>
> > 
> > So why not just call it threads.
> > We'll have cpuSockets, cpiCores, and cpuThreads, should be clear
> > when in CPU context.
> > 
> > In the GUI just change hyperthreads to CPU threads. While in the
> > tool tip explain that it's either AMD Clustered Multi-Thread or
> > Intel Hyperthread
> 
> Does this affect only the number of potential vCpus for the guests or
> does
> this also have an impact on the actual scheduling?
> So far I always disabled HT out of fear that a 2 vCpu guest might
> actually
> be scheduled to run in 2 threads of the same core but now I'm not so
> sure
> anymore. In the HT case does KVM know that two threads belong to the
> same
> core and will it only schedule its vCpus on distinct cores? Is there
> some
> documentation about this somewhere?

This is about the maximum number of vCPUs we can give to a VM.
If the machine has 32 Physical cores that are hyperthreaded then do we say the 
max number of vCPUs for a single VM is 32 or 64.


> 
> Regards,
>   Dennis
> 
> ___
> 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] CPU Overcommit Feature

2012-12-18 Thread Dennis Jacobfeuerborn 
On 12/17/2012 07:13 PM, Simon Grinberg wrote:
> 
> 
> - Original Message -
>> From: "Greg Padgett" 
>> To: "engine-devel" 
>> Sent: Monday, December 17, 2012 4:37:57 PM
>> Subject: [Engine-devel] CPU Overcommit Feature
>>
>> Hi,
>>
>> I've been working on a feature to allow CPU Overcommitment of hosts
>> in a
>> cluster.  This first stage allows the engine to consider host cpu
>> threads
>> as cores for the purposes of VM resource allocation.
>>
>> This wiki page has further details, your comments are welcome!
>> http://www.ovirt.org/Features/cpu_overcommit
> 
> Basically looking good.
> Hyperthread though is vendor specific. 
> 
> For AMD it's Clustered Multi-Thread while for Intel it's Hyper-Thread 
> Official name is  simultaneous multithreading (SMT) but no one outside of the 
> academy will recognize that.
> 
> in libvirt if I read it right it's 
> 
> So why not just call it threads.
> We'll have cpuSockets, cpiCores, and cpuThreads, should be clear when in CPU 
> context.
> 
> In the GUI just change hyperthreads to CPU threads. While in the tool tip 
> explain that it's either AMD Clustered Multi-Thread or Intel Hyperthread 

Does this affect only the number of potential vCpus for the guests or does
this also have an impact on the actual scheduling?
So far I always disabled HT out of fear that a 2 vCpu guest might actually
be scheduled to run in 2 threads of the same core but now I'm not so sure
anymore. In the HT case does KVM know that two threads belong to the same
core and will it only schedule its vCpus on distinct cores? Is there some
documentation about this somewhere?

Regards,
  Dennis

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

Re: [Engine-devel] CPU Overcommit Feature

2012-12-18 Thread Greg Padgett 

On 12/17/2012 05:52 PM, Andrew Cathrow wrote:

... and let's not call this CPU overcommit feature. It's nothing like that - it's 
"Hyperthread handling"

- Original Message -

From: "Simon Grinberg" 
To: "Greg Padgett" 
Cc: "engine-devel" 
Sent: Monday, December 17, 2012 1:13:03 PM
Subject: Re: [Engine-devel] CPU Overcommit Feature



- Original Message -

From: "Greg Padgett" 
To: "engine-devel" 
Sent: Monday, December 17, 2012 4:37:57 PM
Subject: [Engine-devel] CPU Overcommit Feature

Hi,

I've been working on a feature to allow CPU Overcommitment of hosts
in a
cluster.  This first stage allows the engine to consider host cpu
threads
as cores for the purposes of VM resource allocation.

This wiki page has further details, your comments are welcome!
http://www.ovirt.org/Features/cpu_overcommit


Basically looking good.
Hyperthread though is vendor specific.

For AMD it's Clustered Multi-Thread while for Intel it's Hyper-Thread
Official name is  simultaneous multithreading (SMT) but no one
outside of the academy will recognize that.

in libvirt if I read it right it's 

So why not just call it threads.
We'll have cpuSockets, cpiCores, and cpuThreads, should be clear when
in CPU context.

In the GUI just change hyperthreads to CPU threads. While in the tool
tip explain that it's either AMD Clustered Multi-Thread or Intel
Hyperthread





Thanks in advance,
Greg
___
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



Thanks Simon and Andrew.  I've moved the wiki page [1] (with a redirect at 
the old name), updated the terms within to not be vendor-specific, and 
will do the same with the implementation.


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

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

Re: [Engine-devel] Revisiting Java7

2012-12-18 Thread Gilad Chaplik 
- Original Message -
> From: "Roy Golan" 
> 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" 
>  To: "Allon Mureinik" 
>  Cc: "engine-devel" 
>  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" 
> >> To: "Allon Mureinik" 
> >> Cc: "engine-devel" 
> >> 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] jpa annotations

2012-12-18 Thread Laszlo Hornyak 
Hi,

We have JPA annotations on the backend entity beans, but they have never been 
actually used as far as I know and now that I looked into VmTemplate for 
example we do not even have a vm_template table anymore, while VmTemplate still 
refers to it.
Any plans with the JPA?

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

Re: [Engine-devel] Revisiting Java7

2012-12-18 Thread Roy Golan 
another motive "End of Public Updates for Java SE 6 " 
https://blogs.oracle.com/java/entry/end_of_public_updates_for


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" 
To: "Allon Mureinik" 
Cc: "engine-devel" 
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" 
To: "Allon Mureinik" 
Cc: "engine-devel" 
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