Re: [ovirt-devel] Custom Properties code duplication

[Gilad Chaplik]

- Original Message -
> From: "Lior Vernia" 
> To: "Gilad Chaplik" 
> Cc: "Vojtech Szocs" , 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" 
> >> To: "Gilad Chaplik" 
> >> Cc: "Vojtech Szocs" , 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" 
>  To: "Vojtech Szocs" 
>  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" 
> >> To: "Lior Vernia" 
> >> 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" 
> >>> 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 tha

Re: [ovirt-devel] commons-collections v4.0

[Alon Bar-Lev]

- Original Message -
> From: "Mike Kolesnik" 
> To: "Alon Bar-Lev" 
> Cc: "yzaspits" , devel@ovirt.org
> Sent: Thursday, May 8, 2014 7:18:51 AM
> Subject: Re: [ovirt-devel] commons-collections v4.0
> 
> - Original Message -
> > 
> > 
> > - Original Message -
> > > From: "Yevgeny Zaspitsky" 
> > > To: "Alon Bar-Lev" , "Mike Kolesnik"
> > > 
> > > Cc: devel@ovirt.org
> > > Sent: Thursday, May 8, 2014 1:11:41 AM
> > > Subject: Re: [ovirt-devel] commons-collections v4.0
> > > 
> > > On the other hand, changing a jar in the runtime environment without
> > > compiling and running test with the new jar could lead an application to
> > > stop functioning in a customer environment.
> > > Also not every bug found in a dependency jar would cause a problem in the
> > > application. (An application might not use the problematic part of the
> > > dependency.)
> > > I'd better trust the test suite (automatic and manual) that we run on the
> > > compiled application with all the dependencies that the developers choose
> > > at
> > > the development time and then deliver that (with its dependencies as a
> > > single package) to the customers.
> > > Every bug in a dependency should be evaluated within the given
> > > application
> > > scope and only if proven as the given application problem only then the
> > > application should be released.
> > 
> > So what you basically claim is that java developers and technology is not
> > mature enough to keep backward compatibility, so each java developer should
> > freeze a snapshot in time for his application to work.
> > 
> > I truly hope this is not the case.
> 
> There can always be regressions as you're well aware, and I don't know but
> usually people who develop the libraries are not Einstein so yes, they do
> break
> backwards compatibility on occasions, sometimes even on purpose
> (deprecation).
> 
> > 
> > And for addressing your claim explicitly, what you can test at single point
> > in time, does not mean that it is definite as well, at customer site bugs
> > may be found also in the packages that you do test.
> 
> Well, when you test on site by dev & qa you make sure you send something to
> the
> customer - X. When the dependencies are updated out of band, the customer
> actually is using X'.
> I can see at least 2 things wrong here:
> 1. You're putting the customer in a position of a tester for the X'
> application.
> 2. If customer finds a bug he actually found it on X', whereas the developer
> who
> would be assigned to the bug could be using X'' by now.
> 
> If you're so keen on packaging a jar outside WAR file, we need to specify
> explicit version and not >=.

Explicit version is at if you pack it within your application, there is no 
point in that.

Think of how RHEL is provided, think of Fedora, in all cases there are 
components working together and each can be updated independently, and 
amazingly - it works. You can think of Windows with all of its libraries and 
interfaces (Microsoft or 3rd party), that application use, and it does work 
without every [sane] application pulls the entire dependencies.

For some reason only people with Java background (including the J2EE designers) 
assume that Java developers cannot be trusted for not breaking backward 
compatibility in minor versions. This is not technical assumption but human 
assumption, as there is no technical reason for Java library to break backward 
compatibility within minor releases, so what does it tells us about what Java 
developers thinks of them-selves?

Java will be ready for enterprise only when this is resolved. I hope all the 
dependencies we are using are at the quality level that enables us to to trust 
their developers.

> 
> > 
> > > 
> > > 
> > > Sent from Samsung Mobile
> > > 
> > >  Original message 
> > > From: Alon Bar-Lev 
> > > Date: 07/05/2014  21:41  (GMT+02:00)
> > > To: Mike Kolesnik 
> > > Cc: Yevgeny Zaspitsky ,devel@ovirt.org
> > > Subject: Re: [ovirt-devel] commons-collections v4.0
> > >  
> > > 
> > > 
> > > - Original Message -
> > > > From: "Mike Kolesnik" 
> > > > To: "Alon Bar-Lev" 
> > > > Cc: "Yevgeny Zaspitsky" , devel@ovirt.org
> > > > Sent: Wednesday, May 7, 2014 9:34:03 PM
> > > > Subject: Re: [ovirt-devel] commons-collections v4.0
> > > > 
> > > > - Original Message -
> > > > > 
> > > > > 
> > > > > - Original Message -
> > > > > > From: "Yevgeny Zaspitsky" 
> > > > > > To: "Alon Bar-Lev" 
> > > > > > Cc: devel@ovirt.org
> > > > > > Sent: Tuesday, April 22, 2014 11:39:11 AM
> > > > > > Subject: Re: [ovirt-devel] commons-collections v4.0
> > > > > > 
> > > > > > That means that we manage 2 separate environments:
> > > > > > 1. Development - relies on pom files. E.g. unit tests run with
> > > > > > commons-collections v3.1 (and when I add v4.0) and succeed.
> > > > > 
> > > > > devenv will use runtime option.
> > > > > you are right about the unit tests, these relays on the poms.
> > > > 
> > > > 

Re: [ovirt-devel] [VDSM] [PATCH] Add the missing locked() interface

[ybronhei]

On 05/07/2014 07:48 PM, Nir Soffer wrote:


threading.Lock has a little known locked() method, documented in
https://docs.python.org/2.6/library/thread.html#thread.lock.locked

This method is not very useful, but since pthreading.Lock must be
drop-in replacment for threading.Lock, we must implement it.

This patch adds the missing method, implementing it in the same way
Python implemnts it.  Since RLock does not have this method, RLock does
not extend Lock now.

Signed-off-by: Nir Soffer 
---
  pthreading.py | 18 ++
  tests.py  |  7 +++
  2 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/pthreading.py b/pthreading.py
index 2e9e2d6..f1ea056 100644
--- a/pthreading.py
+++ b/pthreading.py
@@ -51,9 +51,9 @@ import os
  import pthread


-class Lock(pthread.Mutex):
+class _Lock(pthread.Mutex):
  """
-Lock class mimics Python native threading.Lock() API on top of
+_Lock class mimics Python native threading.Lock() API on top of
  the POSIX thread mutex synchronization primitive.
  """
  def __enter__(self):
@@ -78,9 +78,19 @@ class Lock(pthread.Mutex):
  self.unlock()


-class RLock(Lock):
+class Lock(_Lock):
+def locked(self):
+# Yes, this is horrible hack, and the same one used by Python
+# threadmodule.c. But this is part of Python lock interface.
+if self.acquire(blocking=False):
+self.release()
+return False
+return True
+
+
+class RLock(_Lock):
  def __init__(self):
-pthread.Mutex.__init__(self, recursive=True)
+_Lock.__init__(self, recursive=True)


  class Condition(object):
diff --git a/tests.py b/tests.py
index d651288..f4c9746 100644
--- a/tests.py
+++ b/tests.py
@@ -60,6 +60,13 @@ class LockTests(TestCaseBase):
  self.assertTrue(lock.acquire())
  self.assertTrue(lock.acquire(False))

+def testLocked(self):
+lock = pthreading.Lock()
+self.assertFalse(lock.locked())
+with lock:
+self.assertTrue(lock.locked())
+self.assertFalse(lock.locked())
+

  class Flag(object):
  def __init__(self):


+1
thanks

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

Re: [ovirt-devel] commons-collections v4.0

[Mike Kolesnik]

- Original Message -
> 
> 
> - Original Message -
> > From: "Yevgeny Zaspitsky" 
> > To: "Alon Bar-Lev" , "Mike Kolesnik"
> > 
> > Cc: devel@ovirt.org
> > Sent: Thursday, May 8, 2014 1:11:41 AM
> > Subject: Re: [ovirt-devel] commons-collections v4.0
> > 
> > On the other hand, changing a jar in the runtime environment without
> > compiling and running test with the new jar could lead an application to
> > stop functioning in a customer environment.
> > Also not every bug found in a dependency jar would cause a problem in the
> > application. (An application might not use the problematic part of the
> > dependency.)
> > I'd better trust the test suite (automatic and manual) that we run on the
> > compiled application with all the dependencies that the developers choose
> > at
> > the development time and then deliver that (with its dependencies as a
> > single package) to the customers.
> > Every bug in a dependency should be evaluated within the given application
> > scope and only if proven as the given application problem only then the
> > application should be released.
> 
> So what you basically claim is that java developers and technology is not
> mature enough to keep backward compatibility, so each java developer should
> freeze a snapshot in time for his application to work.
> 
> I truly hope this is not the case.

There can always be regressions as you're well aware, and I don't know but
usually people who develop the libraries are not Einstein so yes, they do break
backwards compatibility on occasions, sometimes even on purpose (deprecation).

> 
> And for addressing your claim explicitly, what you can test at single point
> in time, does not mean that it is definite as well, at customer site bugs
> may be found also in the packages that you do test.

Well, when you test on site by dev & qa you make sure you send something to the
customer - X. When the dependencies are updated out of band, the customer
actually is using X'.
I can see at least 2 things wrong here:
1. You're putting the customer in a position of a tester for the X' application.
2. If customer finds a bug he actually found it on X', whereas the developer who
would be assigned to the bug could be using X'' by now.

If you're so keen on packaging a jar outside WAR file, we need to specify
explicit version and not >=.

> 
> > 
> > 
> > Sent from Samsung Mobile
> > 
> >  Original message 
> > From: Alon Bar-Lev 
> > Date: 07/05/2014  21:41  (GMT+02:00)
> > To: Mike Kolesnik 
> > Cc: Yevgeny Zaspitsky ,devel@ovirt.org
> > Subject: Re: [ovirt-devel] commons-collections v4.0
> >  
> > 
> > 
> > - Original Message -
> > > From: "Mike Kolesnik" 
> > > To: "Alon Bar-Lev" 
> > > Cc: "Yevgeny Zaspitsky" , devel@ovirt.org
> > > Sent: Wednesday, May 7, 2014 9:34:03 PM
> > > Subject: Re: [ovirt-devel] commons-collections v4.0
> > > 
> > > - Original Message -
> > > > 
> > > > 
> > > > - Original Message -
> > > > > From: "Yevgeny Zaspitsky" 
> > > > > To: "Alon Bar-Lev" 
> > > > > Cc: devel@ovirt.org
> > > > > Sent: Tuesday, April 22, 2014 11:39:11 AM
> > > > > Subject: Re: [ovirt-devel] commons-collections v4.0
> > > > > 
> > > > > That means that we manage 2 separate environments:
> > > > > 1. Development - relies on pom files. E.g. unit tests run with
> > > > > commons-collections v3.1 (and when I add v4.0) and succeed.
> > > > 
> > > > devenv will use runtime option.
> > > > you are right about the unit tests, these relays on the poms.
> > > 
> > > I use devenv and it always uses the dev option not the runtime.
> > > So basically developers are using the pom specified versions and not what
> > > used in runtime.
> > > 
> > > Even more so, in runtime it highly depends on what OS you're using, so
> > > someone
> > > developing on F19 might not be using same versions as a developer on F20
> > > and
> > > both are probably very different versions than on RHEL/CentOS.
> > > I won't even mention other OS`s.
> > > 
> > > > 
> > > > > 2. Run-time - relies on JBoss own dependencies that bring
> > > > > commons-collection
> > > > > v3.2.1-redhat-2.
> > > > 
> > > > in rhel case, yes.
> > > > 
> > > > > This kind of discrepancies might be found in other libraries as we do
> > > > > not
> > > > > synchronize our pom files with the JBoss current version
> > > > > dependencies.
> > > > > IMHO that could lead to some very difficult bugs that we won't be
> > > > > able
> > > > > to
> > > > > simulate in our unit tests.
> > > > 
> > > > correct, but the java way to pull dependencies at will without being
> > > > able
> > > > to
> > > > fix z-stream using central package management tools is more severe than
> > > > unit
> > > > tests not working/not working.
> > > > 
> > > > for example, your application uses x.jar and actually delivers x.jar...
> > > > so
> > > > from release to eternity it is your responsibility to track x.jar for
> > > > severe
> > > > stability bugs and security bugs, and release your 

Re: [ovirt-devel] Vdsm patches need review and merge

[Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC)]

Hi Dan,
I heard that Martin is in TPO now, would you please take a look on these 
patches and merge it, thanks.

Best regards,
David Liang

From: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)
Sent: Thursday, May 08, 2014 10:31 AM
To: Martin Sivak (msi...@redhat.com); Dan Kenigsberg (dan...@redhat.com)
Cc: Gilad Chaplik  (gchap...@redhat.com); Doron Fediuck 
(dfedi...@redhat.com); Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC); 
Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); devel@ovirt.org
Subject: Vdsm patches need review and merge

Hi Martin,
Could you help to review these numa vdsm patches:
http://gerrit.ovirt.org/#/c/27399/
http://gerrit.ovirt.org/#/c/27090/
http://gerrit.ovirt.org/#/c/27403/
http://gerrit.ovirt.org/#/c/26876/
You had already reviewed some of the patches, but after that I modified the 
transferred data format because of the xmlrpc limitations. So could you please 
review them again?

Hi Dan,
I have modified your comments for some of the above patches. Could you please 
take a look and merge those if no more comments?

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

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

[ovirt-devel] Vdsm patches need review and merge

[Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)]

Hi Martin,
Could you help to review these numa vdsm patches:
http://gerrit.ovirt.org/#/c/27399/
http://gerrit.ovirt.org/#/c/27090/
http://gerrit.ovirt.org/#/c/27403/
http://gerrit.ovirt.org/#/c/26876/
You had already reviewed some of the patches, but after that I modified the 
transferred data format because of the xmlrpc limitations. So could you please 
review them again?

Hi Dan,
I have modified your comments for some of the above patches. Could you please 
take a look and merge those if no more comments?

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

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

Re: [ovirt-devel] commons-collections v4.0

[Alon Bar-Lev]

- Original Message -
> From: "Yevgeny Zaspitsky" 
> To: "Alon Bar-Lev" , "Mike Kolesnik" 
> Cc: devel@ovirt.org
> Sent: Thursday, May 8, 2014 1:11:41 AM
> Subject: Re: [ovirt-devel] commons-collections v4.0
> 
> On the other hand, changing a jar in the runtime environment without
> compiling and running test with the new jar could lead an application to
> stop functioning in a customer environment.
> Also not every bug found in a dependency jar would cause a problem in the
> application. (An application might not use the problematic part of the
> dependency.)
> I'd better trust the test suite (automatic and manual) that we run on the
> compiled application with all the dependencies that the developers choose at
> the development time and then deliver that (with its dependencies as a
> single package) to the customers.
> Every bug in a dependency should be evaluated within the given application
> scope and only if proven as the given application problem only then the
> application should be released.

So what you basically claim is that java developers and technology is not 
mature enough to keep backward compatibility, so each java developer should 
freeze a snapshot in time for his application to work.

I truly hope this is not the case.

And for addressing your claim explicitly, what you can test at single point in 
time, does not mean that it is definite as well, at customer site bugs may be 
found also in the packages that you do test.

> 
> 
> Sent from Samsung Mobile
> 
>  Original message 
> From: Alon Bar-Lev 
> Date: 07/05/2014  21:41  (GMT+02:00)
> To: Mike Kolesnik 
> Cc: Yevgeny Zaspitsky ,devel@ovirt.org
> Subject: Re: [ovirt-devel] commons-collections v4.0
>  
> 
> 
> - Original Message -
> > From: "Mike Kolesnik" 
> > To: "Alon Bar-Lev" 
> > Cc: "Yevgeny Zaspitsky" , devel@ovirt.org
> > Sent: Wednesday, May 7, 2014 9:34:03 PM
> > Subject: Re: [ovirt-devel] commons-collections v4.0
> > 
> > - Original Message -
> > > 
> > > 
> > > - Original Message -
> > > > From: "Yevgeny Zaspitsky" 
> > > > To: "Alon Bar-Lev" 
> > > > Cc: devel@ovirt.org
> > > > Sent: Tuesday, April 22, 2014 11:39:11 AM
> > > > Subject: Re: [ovirt-devel] commons-collections v4.0
> > > > 
> > > > That means that we manage 2 separate environments:
> > > > 1. Development - relies on pom files. E.g. unit tests run with
> > > > commons-collections v3.1 (and when I add v4.0) and succeed.
> > > 
> > > devenv will use runtime option.
> > > you are right about the unit tests, these relays on the poms.
> > 
> > I use devenv and it always uses the dev option not the runtime.
> > So basically developers are using the pom specified versions and not what
> > used in runtime.
> > 
> > Even more so, in runtime it highly depends on what OS you're using, so
> > someone
> > developing on F19 might not be using same versions as a developer on F20
> > and
> > both are probably very different versions than on RHEL/CentOS.
> > I won't even mention other OS`s.
> > 
> > > 
> > > > 2. Run-time - relies on JBoss own dependencies that bring
> > > > commons-collection
> > > > v3.2.1-redhat-2.
> > > 
> > > in rhel case, yes.
> > > 
> > > > This kind of discrepancies might be found in other libraries as we do
> > > > not
> > > > synchronize our pom files with the JBoss current version dependencies.
> > > > IMHO that could lead to some very difficult bugs that we won't be able
> > > > to
> > > > simulate in our unit tests.
> > > 
> > > correct, but the java way to pull dependencies at will without being able
> > > to
> > > fix z-stream using central package management tools is more severe than
> > > unit
> > > tests not working/not working.
> > > 
> > > for example, your application uses x.jar and actually delivers x.jar...
> > > so
> > > from release to eternity it is your responsibility to track x.jar for
> > > severe
> > > stability bugs and security bugs, and release your entire application
> > > each
> > > time found, now multiple it with the # of components application is using
> > > and see how much effort you have just to maintain stability and security
> > > if
> > > you embed 3rd party components without your application.
> > 
> > Yes, if you use package X then you're using that specific version with it's
> > behaviour and API, this is why dependencies aren't updated light headedly
> > but
> > with testing to see that nothing broke (since stuff does break, even in
> > minor
> > version, as we leave in a not so perfect world).
> > 
> > > 
> > > > Why do we avoid "to maintain our own packaging"? IMHO Ovirt own
> > > > dependencies
> > > > could be packed in the war, can't they?
> > > 
> > > yes they could, but this is not suitable for enterprise grade
> > > implementations, mainly per what I described above.
> > 
> > Sorry but AFAIK enterprise grade software release fixes for their software
> > on a timely basis and have processes in place to manage upgrades of
> > functionality.
> > 
> > What cur

Re: [ovirt-devel] commons-collections v4.0

[Yevgeny Zaspitsky]

On the other hand, changing a jar in the runtime environment without compiling 
and running test with the new jar could lead an application to stop functioning 
in a customer environment.
Also not every bug found in a dependency jar would cause a problem in the 
application. (An application might not use the problematic part of the 
dependency.)
I'd better trust the test suite (automatic and manual) that we run on the 
compiled application with all the dependencies that the developers choose at 
the development time and then deliver that (with its dependencies as a single 
package) to the customers.
Every bug in a dependency should be evaluated within the given application 
scope and only if proven as the given application problem only then the 
application should be released.


Sent from Samsung Mobile

 Original message 
From: Alon Bar-Lev  
Date: 07/05/2014  21:41  (GMT+02:00) 
To: Mike Kolesnik  
Cc: Yevgeny Zaspitsky ,devel@ovirt.org 
Subject: Re: [ovirt-devel] commons-collections v4.0 
 


- Original Message -
> From: "Mike Kolesnik" 
> To: "Alon Bar-Lev" 
> Cc: "Yevgeny Zaspitsky" , devel@ovirt.org
> Sent: Wednesday, May 7, 2014 9:34:03 PM
> Subject: Re: [ovirt-devel] commons-collections v4.0
> 
> - Original Message -
> > 
> > 
> > - Original Message -
> > > From: "Yevgeny Zaspitsky" 
> > > To: "Alon Bar-Lev" 
> > > Cc: devel@ovirt.org
> > > Sent: Tuesday, April 22, 2014 11:39:11 AM
> > > Subject: Re: [ovirt-devel] commons-collections v4.0
> > > 
> > > That means that we manage 2 separate environments:
> > > 1. Development - relies on pom files. E.g. unit tests run with
> > > commons-collections v3.1 (and when I add v4.0) and succeed.
> > 
> > devenv will use runtime option.
> > you are right about the unit tests, these relays on the poms.
> 
> I use devenv and it always uses the dev option not the runtime.
> So basically developers are using the pom specified versions and not what
> used in runtime.
> 
> Even more so, in runtime it highly depends on what OS you're using, so
> someone
> developing on F19 might not be using same versions as a developer on F20 and
> both are probably very different versions than on RHEL/CentOS.
> I won't even mention other OS`s.
> 
> > 
> > > 2. Run-time - relies on JBoss own dependencies that bring
> > > commons-collection
> > > v3.2.1-redhat-2.
> > 
> > in rhel case, yes.
> > 
> > > This kind of discrepancies might be found in other libraries as we do not
> > > synchronize our pom files with the JBoss current version dependencies.
> > > IMHO that could lead to some very difficult bugs that we won't be able to
> > > simulate in our unit tests.
> > 
> > correct, but the java way to pull dependencies at will without being able
> > to
> > fix z-stream using central package management tools is more severe than
> > unit
> > tests not working/not working.
> > 
> > for example, your application uses x.jar and actually delivers x.jar... so
> > from release to eternity it is your responsibility to track x.jar for
> > severe
> > stability bugs and security bugs, and release your entire application each
> > time found, now multiple it with the # of components application is using
> > and see how much effort you have just to maintain stability and security if
> > you embed 3rd party components without your application.
> 
> Yes, if you use package X then you're using that specific version with it's
> behaviour and API, this is why dependencies aren't updated light headedly but
> with testing to see that nothing broke (since stuff does break, even in minor
> version, as we leave in a not so perfect world).
> 
> > 
> > > Why do we avoid "to maintain our own packaging"? IMHO Ovirt own
> > > dependencies
> > > could be packed in the war, can't they?
> > 
> > yes they could, but this is not suitable for enterprise grade
> > implementations, mainly per what I described above.
> 
> Sorry but AFAIK enterprise grade software release fixes for their software
> on a timely basis and have processes in place to manage upgrades of
> functionality.
> 
> What currently is done is relying on courtesy of other people to release a
> "fix" that already exists a long time.
> And of course, as I mentioned, the application needs to be tested with the
> updated library.
> IMO neglecting this and leaving this out of band for "enterprise grade"
> software is much worse than actually testing to see that it is working and
> just leaving it all to chance.

‎Well, take the recent example of openssl issue that was found.
Now, imagine that all products that use openssl should have been re-released.
I think this is enough to understand how wrong this is.

> 
> > 
> > Regards,
> > Alon
> > 
> > > Best regards,
> > > 
> > > Yevgeny Zaspitsky
> > > Senior Software Engineer
> > > Red Hat Israel
> > > 
> > > 
> > > - Original Message -
> > > From: "Alon Bar-Lev" 
> > > To: "Yevgeny Zaspitsky" 
> > > Cc: devel@ovirt.org
> > > Sent: Sunday, April 13, 

Re: [ovirt-devel] [VDSM] [PATCH] Add the missing locked() interface

[Federico Simoncelli]

+1

-- 
Federico

- Original Message -
> From: "Nir Soffer" 
> To: devel@ovirt.org, "Saggi Mizrahi" , "ybronhei" 
> , "Dan Kenigsberg"
> , "Barak Azulay" , "Allon Mureinik" 
> 
> Sent: Wednesday, May 7, 2014 6:48:39 PM
> Subject: [ovirt-devel] [VDSM] [PATCH] Add the missing locked() interface
> 
> 
> threading.Lock has a little known locked() method, documented in
> https://docs.python.org/2.6/library/thread.html#thread.lock.locked
> 
> This method is not very useful, but since pthreading.Lock must be
> drop-in replacment for threading.Lock, we must implement it.
> 
> This patch adds the missing method, implementing it in the same way
> Python implemnts it.  Since RLock does not have this method, RLock does
> not extend Lock now.
> 
> Signed-off-by: Nir Soffer 
> ---
>  pthreading.py | 18 ++
>  tests.py  |  7 +++
>  2 files changed, 21 insertions(+), 4 deletions(-)
> 
> diff --git a/pthreading.py b/pthreading.py
> index 2e9e2d6..f1ea056 100644
> --- a/pthreading.py
> +++ b/pthreading.py
> @@ -51,9 +51,9 @@ import os
>  import pthread
>  
>  
> -class Lock(pthread.Mutex):
> +class _Lock(pthread.Mutex):
>  """
> -Lock class mimics Python native threading.Lock() API on top of
> +_Lock class mimics Python native threading.Lock() API on top of
>  the POSIX thread mutex synchronization primitive.
>  """
>  def __enter__(self):
> @@ -78,9 +78,19 @@ class Lock(pthread.Mutex):
>  self.unlock()
>  
>  
> -class RLock(Lock):
> +class Lock(_Lock):
> +def locked(self):
> +# Yes, this is horrible hack, and the same one used by Python
> +# threadmodule.c. But this is part of Python lock interface.
> +if self.acquire(blocking=False):
> +self.release()
> +return False
> +return True
> +
> +
> +class RLock(_Lock):
>  def __init__(self):
> -pthread.Mutex.__init__(self, recursive=True)
> +_Lock.__init__(self, recursive=True)
>  
>  
>  class Condition(object):
> diff --git a/tests.py b/tests.py
> index d651288..f4c9746 100644
> --- a/tests.py
> +++ b/tests.py
> @@ -60,6 +60,13 @@ class LockTests(TestCaseBase):
>  self.assertTrue(lock.acquire())
>  self.assertTrue(lock.acquire(False))
>  
> +def testLocked(self):
> +lock = pthreading.Lock()
> +self.assertFalse(lock.locked())
> +with lock:
> +self.assertTrue(lock.locked())
> +self.assertFalse(lock.locked())
> +
>  
>  class Flag(object):
>  def __init__(self):
> --
> 1.8.3.1
> ___
> 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] commons-collections v4.0

[Alon Bar-Lev]

- Original Message -
> From: "Mike Kolesnik" 
> To: "Alon Bar-Lev" 
> Cc: "Yevgeny Zaspitsky" , devel@ovirt.org
> Sent: Wednesday, May 7, 2014 9:34:03 PM
> Subject: Re: [ovirt-devel] commons-collections v4.0
> 
> - Original Message -
> > 
> > 
> > - Original Message -
> > > From: "Yevgeny Zaspitsky" 
> > > To: "Alon Bar-Lev" 
> > > Cc: devel@ovirt.org
> > > Sent: Tuesday, April 22, 2014 11:39:11 AM
> > > Subject: Re: [ovirt-devel] commons-collections v4.0
> > > 
> > > That means that we manage 2 separate environments:
> > > 1. Development - relies on pom files. E.g. unit tests run with
> > > commons-collections v3.1 (and when I add v4.0) and succeed.
> > 
> > devenv will use runtime option.
> > you are right about the unit tests, these relays on the poms.
> 
> I use devenv and it always uses the dev option not the runtime.
> So basically developers are using the pom specified versions and not what
> used in runtime.
> 
> Even more so, in runtime it highly depends on what OS you're using, so
> someone
> developing on F19 might not be using same versions as a developer on F20 and
> both are probably very different versions than on RHEL/CentOS.
> I won't even mention other OS`s.
> 
> > 
> > > 2. Run-time - relies on JBoss own dependencies that bring
> > > commons-collection
> > > v3.2.1-redhat-2.
> > 
> > in rhel case, yes.
> > 
> > > This kind of discrepancies might be found in other libraries as we do not
> > > synchronize our pom files with the JBoss current version dependencies.
> > > IMHO that could lead to some very difficult bugs that we won't be able to
> > > simulate in our unit tests.
> > 
> > correct, but the java way to pull dependencies at will without being able
> > to
> > fix z-stream using central package management tools is more severe than
> > unit
> > tests not working/not working.
> > 
> > for example, your application uses x.jar and actually delivers x.jar... so
> > from release to eternity it is your responsibility to track x.jar for
> > severe
> > stability bugs and security bugs, and release your entire application each
> > time found, now multiple it with the # of components application is using
> > and see how much effort you have just to maintain stability and security if
> > you embed 3rd party components without your application.
> 
> Yes, if you use package X then you're using that specific version with it's
> behaviour and API, this is why dependencies aren't updated light headedly but
> with testing to see that nothing broke (since stuff does break, even in minor
> version, as we leave in a not so perfect world).
> 
> > 
> > > Why do we avoid "to maintain our own packaging"? IMHO Ovirt own
> > > dependencies
> > > could be packed in the war, can't they?
> > 
> > yes they could, but this is not suitable for enterprise grade
> > implementations, mainly per what I described above.
> 
> Sorry but AFAIK enterprise grade software release fixes for their software
> on a timely basis and have processes in place to manage upgrades of
> functionality.
> 
> What currently is done is relying on courtesy of other people to release a
> "fix" that already exists a long time.
> And of course, as I mentioned, the application needs to be tested with the
> updated library.
> IMO neglecting this and leaving this out of band for "enterprise grade"
> software is much worse than actually testing to see that it is working and
> just leaving it all to chance.

‎Well, take the recent example of openssl issue that was found.
Now, imagine that all products that use openssl should have been re-released.
I think this is enough to understand how wrong this is.

> 
> > 
> > Regards,
> > Alon
> > 
> > > Best regards,
> > > 
> > > Yevgeny Zaspitsky
> > > Senior Software Engineer
> > > Red Hat Israel
> > > 
> > > 
> > > - Original Message -
> > > From: "Alon Bar-Lev" 
> > > To: "Yevgeny Zaspitsky" 
> > > Cc: devel@ovirt.org
> > > Sent: Sunday, April 13, 2014 7:22:18 PM
> > > Subject: Re: [ovirt-devel] commons-collections v4.0
> > > 
> > > 
> > > 
> > > - Original Message -
> > > > From: "Yevgeny Zaspitsky" 
> > > > To: devel@ovirt.org
> > > > Sent: Sunday, April 13, 2014 7:13:10 PM
> > > > Subject: [ovirt-devel] commons-collections v4.0
> > > > 
> > > > Hi All,
> > > > 
> > > > I'd like to add the new version (4.0) of Apache commons-collections
> > > > library
> > > > to the dependencies of the project (we use 3.1 currently).
> > > > The new version uses the generics features of Java 5 so that make the
> > > > code
> > > > more type safe. You can find the full list of changes on
> > > > https://commons.apache.org/proper/commons-collections/release_4_0.html.
> > > > The new API is based on the original but it isn't fully compatible with
> > > > it.
> > > > So in order to make the migration to the new API easier, the package
> > > > has
> > > > been changed to org.apache.commons.collections4. That allows having
> > > > both
> > > > version of the librar

Re: [ovirt-devel] commons-collections v4.0

[Mike Kolesnik]

- Original Message -
> 
> 
> - Original Message -
> > From: "Yevgeny Zaspitsky" 
> > To: "Alon Bar-Lev" 
> > Cc: devel@ovirt.org
> > Sent: Tuesday, April 22, 2014 11:39:11 AM
> > Subject: Re: [ovirt-devel] commons-collections v4.0
> > 
> > That means that we manage 2 separate environments:
> > 1. Development - relies on pom files. E.g. unit tests run with
> > commons-collections v3.1 (and when I add v4.0) and succeed.
> 
> devenv will use runtime option.
> you are right about the unit tests, these relays on the poms.

I use devenv and it always uses the dev option not the runtime.
So basically developers are using the pom specified versions and not what
used in runtime.

Even more so, in runtime it highly depends on what OS you're using, so someone
developing on F19 might not be using same versions as a developer on F20 and
both are probably very different versions than on RHEL/CentOS.
I won't even mention other OS`s.

> 
> > 2. Run-time - relies on JBoss own dependencies that bring
> > commons-collection
> > v3.2.1-redhat-2.
> 
> in rhel case, yes.
> 
> > This kind of discrepancies might be found in other libraries as we do not
> > synchronize our pom files with the JBoss current version dependencies.
> > IMHO that could lead to some very difficult bugs that we won't be able to
> > simulate in our unit tests.
> 
> correct, but the java way to pull dependencies at will without being able to
> fix z-stream using central package management tools is more severe than unit
> tests not working/not working.
> 
> for example, your application uses x.jar and actually delivers x.jar... so
> from release to eternity it is your responsibility to track x.jar for severe
> stability bugs and security bugs, and release your entire application each
> time found, now multiple it with the # of components application is using
> and see how much effort you have just to maintain stability and security if
> you embed 3rd party components without your application.

Yes, if you use package X then you're using that specific version with it's
behaviour and API, this is why dependencies aren't updated light headedly but
with testing to see that nothing broke (since stuff does break, even in minor
version, as we leave in a not so perfect world).

> 
> > Why do we avoid "to maintain our own packaging"? IMHO Ovirt own
> > dependencies
> > could be packed in the war, can't they?
> 
> yes they could, but this is not suitable for enterprise grade
> implementations, mainly per what I described above.

Sorry but AFAIK enterprise grade software release fixes for their software
on a timely basis and have processes in place to manage upgrades of
functionality.

What currently is done is relying on courtesy of other people to release a
"fix" that already exists a long time.
And of course, as I mentioned, the application needs to be tested with the
updated library.
IMO neglecting this and leaving this out of band for "enterprise grade"
software is much worse than actually testing to see that it is working and
just leaving it all to chance.

> 
> Regards,
> Alon
> 
> > Best regards,
> > 
> > Yevgeny Zaspitsky
> > Senior Software Engineer
> > Red Hat Israel
> > 
> > 
> > - Original Message -
> > From: "Alon Bar-Lev" 
> > To: "Yevgeny Zaspitsky" 
> > Cc: devel@ovirt.org
> > Sent: Sunday, April 13, 2014 7:22:18 PM
> > Subject: Re: [ovirt-devel] commons-collections v4.0
> > 
> > 
> > 
> > - Original Message -
> > > From: "Yevgeny Zaspitsky" 
> > > To: devel@ovirt.org
> > > Sent: Sunday, April 13, 2014 7:13:10 PM
> > > Subject: [ovirt-devel] commons-collections v4.0
> > > 
> > > Hi All,
> > > 
> > > I'd like to add the new version (4.0) of Apache commons-collections
> > > library
> > > to the dependencies of the project (we use 3.1 currently).
> > > The new version uses the generics features of Java 5 so that make the
> > > code
> > > more type safe. You can find the full list of changes on
> > > https://commons.apache.org/proper/commons-collections/release_4_0.html.
> > > The new API is based on the original but it isn't fully compatible with
> > > it.
> > > So in order to make the migration to the new API easier, the package has
> > > been changed to org.apache.commons.collections4. That allows having both
> > > version of the library in the classpath at the starting point and move
> > > (refactor) towards the new version gradually.
> > > 
> > > I have couple of questions regarding the new dependency:
> > > 1. Is there anything that could prevent adding the new dependency?
> > 
> > We try to avoid introducing our own dependencies, in this case we use
> > whatever jboss provides which is very comfortable as we do not need to
> > maintain our own packaging.
> > 
> > Currently the jbeap does not provide 4.0, it does support 3.2.1-redhat-2,
> > so
> > better to avoid this until we switch to more recent version of jboss.
> > 
> > Alternatively we could enjoy standalone rpm within rhel/centos if
> > avail

Re: [ovirt-devel] [VDSM] [PATCH] Add the missing locked() interface

[Dan Kenigsberg]

On Wed, May 07, 2014 at 12:48:39PM -0400, Nir Soffer wrote:
> 
> threading.Lock has a little known locked() method, documented in
> https://docs.python.org/2.6/library/thread.html#thread.lock.locked
> 
> This method is not very useful, but since pthreading.Lock must be
> drop-in replacment for threading.Lock, we must implement it.
> 
> This patch adds the missing method, implementing it in the same way
> Python implemnts it.  Since RLock does not have this method, RLock does
> not extend Lock now.
> 
> Signed-off-by: Nir Soffer 
> ---
>  pthreading.py | 18 ++
>  tests.py  |  7 +++
>  2 files changed, 21 insertions(+), 4 deletions(-)
> 
> diff --git a/pthreading.py b/pthreading.py
> index 2e9e2d6..f1ea056 100644
> --- a/pthreading.py
> +++ b/pthreading.py
> @@ -51,9 +51,9 @@ import os
>  import pthread
>  
>  
> -class Lock(pthread.Mutex):
> +class _Lock(pthread.Mutex):
>  """
> -Lock class mimics Python native threading.Lock() API on top of
> +_Lock class mimics Python native threading.Lock() API on top of
>  the POSIX thread mutex synchronization primitive.
>  """
>  def __enter__(self):
> @@ -78,9 +78,19 @@ class Lock(pthread.Mutex):
>  self.unlock()
>  
>  
> -class RLock(Lock):
> +class Lock(_Lock):
> +def locked(self):
> +# Yes, this is horrible hack, and the same one used by Python
> +# threadmodule.c. But this is part of Python lock interface.
> +if self.acquire(blocking=False):
> +self.release()
> +return False
> +return True
> +
> +
> +class RLock(_Lock):
>  def __init__(self):
> -pthread.Mutex.__init__(self, recursive=True)
> +_Lock.__init__(self, recursive=True)
>  
>  
>  class Condition(object):
> diff --git a/tests.py b/tests.py
> index d651288..f4c9746 100644
> --- a/tests.py
> +++ b/tests.py
> @@ -60,6 +60,13 @@ class LockTests(TestCaseBase):
>  self.assertTrue(lock.acquire())
>  self.assertTrue(lock.acquire(False))
>  
> +def testLocked(self):
> +lock = pthreading.Lock()
> +self.assertFalse(lock.locked())
> +with lock:
> +self.assertTrue(lock.locked())
> +self.assertFalse(lock.locked())
> +
>  
>  class Flag(object):
>  def __init__(self):
> -- 
> 1.8.3.1

ACK, thanks for the quick fix
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] just merged the look-and-feel patch -- rebase!

[Greg Sheremeta]

We've received a couple of BZ's so far (thanks derez!)

Please make sure to clear your browser cache after rebasing to this UI change.

Thanks,
Greg


- Original Message -
> From: "Greg Sheremeta" 
> To: devel@ovirt.org
> Sent: Tuesday, May 6, 2014 8:44:03 AM
> Subject: [ovirt-devel] just merged the look-and-feel patch -- rebase!
> 
> Hi,
> 
> We just merged the look-and-feel patch [1]. The patch is gigantic and touches
> most parts of the UI, so please do a rebase immediately if you're doing any
> kind of UI work.
> 
> If you see any UI look/feel bugs (like things out of place, bad alignment,
> etc.), open a BZ and assign to me.
> 
> Thanks!
> Greg
> 
> [1] http://gerrit.ovirt.org/#/c/24594/
> 
> 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
> 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] [VDSM] [PATCH] Add the missing locked() interface

[Nir Soffer]

threading.Lock has a little known locked() method, documented in
https://docs.python.org/2.6/library/thread.html#thread.lock.locked

This method is not very useful, but since pthreading.Lock must be
drop-in replacment for threading.Lock, we must implement it.

This patch adds the missing method, implementing it in the same way
Python implemnts it.  Since RLock does not have this method, RLock does
not extend Lock now.

Signed-off-by: Nir Soffer 
---
 pthreading.py | 18 ++
 tests.py  |  7 +++
 2 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/pthreading.py b/pthreading.py
index 2e9e2d6..f1ea056 100644
--- a/pthreading.py
+++ b/pthreading.py
@@ -51,9 +51,9 @@ import os
 import pthread
 
 
-class Lock(pthread.Mutex):
+class _Lock(pthread.Mutex):
 """
-Lock class mimics Python native threading.Lock() API on top of
+_Lock class mimics Python native threading.Lock() API on top of
 the POSIX thread mutex synchronization primitive.
 """
 def __enter__(self):
@@ -78,9 +78,19 @@ class Lock(pthread.Mutex):
 self.unlock()
 
 
-class RLock(Lock):
+class Lock(_Lock):
+def locked(self):
+# Yes, this is horrible hack, and the same one used by Python
+# threadmodule.c. But this is part of Python lock interface.
+if self.acquire(blocking=False):
+self.release()
+return False
+return True
+
+
+class RLock(_Lock):
 def __init__(self):
-pthread.Mutex.__init__(self, recursive=True)
+_Lock.__init__(self, recursive=True)
 
 
 class Condition(object):
diff --git a/tests.py b/tests.py
index d651288..f4c9746 100644
--- a/tests.py
+++ b/tests.py
@@ -60,6 +60,13 @@ class LockTests(TestCaseBase):
 self.assertTrue(lock.acquire())
 self.assertTrue(lock.acquire(False))
 
+def testLocked(self):
+lock = pthreading.Lock()
+self.assertFalse(lock.locked())
+with lock:
+self.assertTrue(lock.locked())
+self.assertFalse(lock.locked())
+
 
 class Flag(object):
 def __init__(self):
-- 
1.8.3.1
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Custom Properties code duplication

[Lior Vernia]

On 07/05/14 18:57, Gilad Chaplik wrote:
> - Original Message -
>> From: "Lior Vernia" 
>> To: "Gilad Chaplik" 
>> Cc: "Vojtech Szocs" , 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" 
 To: "Vojtech Szocs" 
 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" 
>> To: "Lior Vernia" 
>> 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" 
>>> 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/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 Cu

Re: [ovirt-devel] Custom Properties code duplication

[Gilad Chaplik]

- Original Message -
> From: "Lior Vernia" 
> To: "Gilad Chaplik" 
> Cc: "Vojtech Szocs" , 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" 
> >> To: "Vojtech Szocs" 
> >> 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" 
>  To: "Lior Vernia" 
>  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" 
> > 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/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.
> >>>
> >>> +1
> >>>
> >

Re: [ovirt-devel] Custom Properties code duplication

[Lior Vernia]

On 07/05/14 16:02, Gilad Chaplik wrote:
> - Original Message -
>> From: "Lior Vernia" 
>> To: "Vojtech Szocs" 
>> 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" 
 To: "Lior Vernia" 
 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" 
> 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/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.
>>>
>>> +1
>>>
>
> 4. Optionally change the implementation of custom properties members in
> entities (e.g. VM) from String to Map, which would
> obviate the need for different conversion methods between String/Map -
> (de)serialization would only be required in DB interaction.
>>>
>>> +1
>>>

 3,4 Agreed - good points.

>
> The main argument against this would be that the frontend is to be moved
> over the REST, and might not be written in Java much longer 

Re: [ovirt-devel] oVirt vdsm-jsonrpc-java release

[Alon Bar-Lev]

- Original Message -
> From: "Piotr Kliczewski" 
> To: devel@ovirt.org
> Sent: Wednesday, May 7, 2014 5:25:20 PM
> Subject: [ovirt-devel]  oVirt vdsm-jsonrpc-java release
> 
> I would like to get a key to sign vdsm-jsonrpc-java artifacts before
> releasing them to maven central.

You can generate this your-self... just put this address... :)))

> 
> Thanks,
> Piotr
> ___
> 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

[ovirt-devel] oVirt vdsm-jsonrpc-java release

[Piotr Kliczewski]

I would like to get a key to sign vdsm-jsonrpc-java artifacts before
releasing them to maven central.

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

Re: [ovirt-devel] Custom Properties code duplication

[Gilad Chaplik]

- Original Message -
> From: "Lior Vernia" 
> To: "Vojtech Szocs" 
> 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" 
> >> To: "Lior Vernia" 
> >> 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" 
> >>> 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/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.
> > 
> > +1
> > 
> >>>
> >>> 4. Optionally change the implementation of custom properties members in
> >>> entities (e.g. VM) from String to Map, which would
> >>> obviate the need for different conversion methods between String/Map -
> >>> (de)serialization would only be required in DB interaction.
> > 
> > +1
> > 
> >>
> >> 3,4 Agreed - good points.
> >>
> >>>
> >>> The main argument against this would be that the frontend is to be moved
> >>> over the REST, and might not be written in Java much longer anyway.
> > 
> > :) I think there's a misun

Re: [ovirt-devel] vdsm disabling logical volumes

[Jiri Moskovcak]

On 05/07/2014 11:37 AM, Dan Kenigsberg wrote:

On Wed, May 07, 2014 at 09:56:03AM +0200, Jiri Moskovcak wrote:

On 05/07/2014 09:28 AM, Nir Soffer wrote:

- Original Message -

From: "Jiri Moskovcak" 
To: "Nir Soffer" 
Cc: devel@ovirt.org, "Federico Simoncelli" , "Allon Mureinik" 
, "Greg
Padgett" , "Doron Fediuck" 
Sent: Wednesday, May 7, 2014 10:21:28 AM
Subject: Re: [ovirt-devel] vdsm disabling logical volumes

On 05/05/2014 03:19 PM, Nir Soffer wrote:

- Original Message -

From: "Jiri Moskovcak" 
To: "Nir Soffer" 
Cc: devel@ovirt.org, "Federico Simoncelli" , "Allon
Mureinik" , "Greg
Padgett" 
Sent: Monday, May 5, 2014 3:44:21 PM
Subject: Re: [ovirt-devel] vdsm disabling logical volumes

On 05/05/2014 02:37 PM, Nir Soffer wrote:

- Original Message -

From: "Jiri Moskovcak" 
To: "Nir Soffer" 
Cc: devel@ovirt.org, "Federico Simoncelli" , "Allon
Mureinik" , "Greg
Padgett" 
Sent: Monday, May 5, 2014 3:16:37 PM
Subject: Re: [ovirt-devel] vdsm disabling logical volumes

On 05/05/2014 12:01 AM, Nir Soffer wrote:

- Original Message -

From: "Jiri Moskovcak" 
To: "Nir Soffer" 
Cc: devel@ovirt.org
Sent: Sunday, May 4, 2014 9:23:49 PM
Subject: Re: [ovirt-devel] vdsm disabling logical volumes

On 05/04/2014 07:57 PM, Nir Soffer wrote:

- Original Message -

From: "Jiri Moskovcak" 
To: devel@ovirt.org
Sent: Sunday, May 4, 2014 8:08:33 PM
Subject: [ovirt-devel] vdsm disabling logical volumes

Greetings vdsm developers!

While working on adding ISCSI support to the hosted engine tools, I
ran
into a problem with vdms. It seems that when stopped vdsm
deactivates
ALL logical volumes in it's volume group and when it starts it
reactivates only specific logical volumes. This is a problem for
hosted
engine tools as they create logical volumes in the same volume group
and
when vdsm deactivates the LVs the hosted engine tools don't have a
way
to reactivate it, because the services drop the root permissions and
are
running as vdsm and apparently only root can activate LVs.


Can you describe what volumes are you creating, and why?


We create hosted-engine.lockspace (for sanlock) and
hosted-engine.metadata (keeps data about hosted engine hosts)


Do you create these lvs in every vdsm vg?


- only in the first vg created by vdsm while deploying hosted-engine


It seems that the hosted engine has single point of failure - the random
vg that contains hosted engine data.




Is this part of the domain structure
used by hosted engine, or it has nothing to do with the storage domain?


- sorry, I don't understand this question. How can I tell if it has
something to do with the storage domain? It's for storing data about
hosts set up to run the hosted-engine and data about state of engine and
the state of VM running the engine.


Can you tell us exactly what lvs you are creating, and on which vg?

And how are you creating those lvs - I guess through vdsm?



- no hosted-engine tools do that by calling:

lvc = popen(stdin=subprocess.PIPE, stdout=subprocess.PIPE,
   stderr=subprocess.PIPE,
   args=["lvm", "lvcreate", "-L", str(size_bytes)+"B",
 "-n", lv_name, vg_uuid])
..


How do you ensure that another host is not modifying the same vg in the
same time?

If you are not ensuring this, you will corrupt this vg sooner or later.

When a storage domain is detached from a host, for example when the host
is in maintenance mode, lvs on the shared storage may be deleted,
invalidating
the devices mapper maps for these devices. If you write to an lv with wrong
maps, you may be writing to an extent belonging to another lv, corrupting
that
lv data, or even worse corrupting the engine vg data.

How do you ensure that the lvs are not deleted while you are using them?




The output of lvs command on a host with hosted engine installed will
help us to understand what you are doing, and then we can think more
clearly
what would be the best way to support this in vdsm.


The output of lvs: http://fpaste.org/99196/93619139/

HE created these two LVs:
ha_agent-hosted-engine.lockspace
ha_agent-hosted-engine.metadata


Why do you create these lvs on a vg owned by vdsm?

If you want total control of these lvs, I suggest that you create your own
vg and put what ever lvs you like there.



I would rather not go this way (at least not for 3.5) as it's too much
code changes in hosted-engine. On the other hand the logic in vdsm seems
wrong because it's not complementary (disabling all LVs and then
enabling just some of them) and should be fixed anyway. This problem is
blocking one of our 3.5 features so I've created rhbz#1094657 to track it.


Can you elaborate on this? How should vdsm behave better, and why?


Sure. So far I didn't hear any reason why it behaves like this and
it seems not logical to disable *all* and then enable just *some*.

How: Disabling and enabling operations should be complementary.
Why: To be less surprising.


There is an asym

Re: [ovirt-devel] Login is failing at master due to cookie hell

[Alon Bar-Lev]

- Original Message -
> From: "Juan Hernandez" 
> To: "Alon Bar-Lev" , "Vojtech Szocs" , 
> "Alexander Wels" 
> Cc: de...@linode01.ovirt.org
> Sent: Wednesday, May 7, 2014 1:28:51 PM
> Subject: Re: [ovirt-devel] Login is failing at master due to cookie hell
> 
> On 05/07/2014 11:37 AM, Alon Bar-Lev wrote:
> > Hi,
> > 
> > Thanks Omer for the hint!
> > 
> > Following merge of several patches HttpOnly cookie patch[1], and the new
> > theme[2] (I guess), the login stopped working.
> > 
> > The frontend is doing basic authentication against the restapi and attempt
> > to
> > move the cookie(?)? But it sending the cookie without http only marker.
> >  
> > I do not fully understand the logic, but it may parse the cookie manually
> > in
> > order to do so?
> > 
> > Our cookies must have HttpOnly markers so this probably need to be solved
> > at
> > the component which sends the cookie without the HttpOnly.
> > 
> > For now, people that experiencing this, please revert[1] until we can sort
> > it
> > out.
> > 
> > Thanks,
> > Alon
> > 
> 
> From ReportModel:
> 
> public ReportModel(String baseUrl) {
> String sessionID = Cookies.getCookie("JSESSIONID"); //$NON-NLS-1$
> 
> reportUrl = baseUrl + "/flow.html" +
> "?viewAsDashboardFrame=false"; //$NON-NLS-1$ //$NON-NLS-2$
> paramsMap.setParameter("sessionID", sessionID); //$NON-NLS-1$
> paramsMap.setParameter("_flowId", "viewReportFlow");
> //$NON-NLS-1$ //$NON-NLS-2$
> paramsMap.setParameter("active_hosts_select", //$NON-NLS-1$
>"AND+delete_date+IS+NULL"); //$NON-NLS-1$
> 
> String currentLocale =
> LocaleInfo.getCurrentLocale().getLocaleName();
> paramsMap.setParameter("userLocale",
> (currentLocale.equals("default") ? "en_US" : currentLocale));
> //$NON-NLS-1$ //$NON-NLS-2$ //$NON-NLS-3$
> }
> 
> This code gets the value of the JSESSIONID cookie, which is now
> forbidden, the net result is NPE that blocks the rest of the process.
> 

Thank you for this info.

> Why wasn't this detected during the verification of the change that made
> the cookies HTTP only?

I am unsure, but it did login when verified by me at least when it was written 
before the long delay of merging. so something must created side effect, which 
is good.

Oved, we should get the session id from using a servlet to echo it back.

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

Re: [ovirt-devel] Login is failing at master due to cookie hell

[Juan Hernandez]

On 05/07/2014 11:37 AM, Alon Bar-Lev wrote:
> Hi,
> 
> Thanks Omer for the hint!
> 
> Following merge of several patches HttpOnly cookie patch[1], and the new
> theme[2] (I guess), the login stopped working.
> 
> The frontend is doing basic authentication against the restapi and attempt to
> move the cookie(?)? But it sending the cookie without http only marker.
>  
> I do not fully understand the logic, but it may parse the cookie manually in
> order to do so?
> 
> Our cookies must have HttpOnly markers so this probably need to be solved at
> the component which sends the cookie without the HttpOnly.
> 
> For now, people that experiencing this, please revert[1] until we can sort it
> out.
> 
> Thanks,
> Alon
> 

>From ReportModel:

public ReportModel(String baseUrl) {
String sessionID = Cookies.getCookie("JSESSIONID"); //$NON-NLS-1$

reportUrl = baseUrl + "/flow.html" +
"?viewAsDashboardFrame=false"; //$NON-NLS-1$ //$NON-NLS-2$
paramsMap.setParameter("sessionID", sessionID); //$NON-NLS-1$
paramsMap.setParameter("_flowId", "viewReportFlow");
//$NON-NLS-1$ //$NON-NLS-2$
paramsMap.setParameter("active_hosts_select", //$NON-NLS-1$
   "AND+delete_date+IS+NULL"); //$NON-NLS-1$

String currentLocale =
LocaleInfo.getCurrentLocale().getLocaleName();
paramsMap.setParameter("userLocale",
(currentLocale.equals("default") ? "en_US" : currentLocale));
//$NON-NLS-1$ //$NON-NLS-2$ //$NON-NLS-3$
}

This code gets the value of the JSESSIONID cookie, which is now
forbidden, the net result is NPE that blocks the rest of the process.

Why wasn't this detected during the verification of the change that made
the cookies HTTP only?

-- 
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.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Login is failing at master due to cookie hell

[Alon Bar-Lev]

- Original Message -
> From: "Roy Golan" 
> To: devel@ovirt.org
> Sent: Wednesday, May 7, 2014 12:42:34 PM
> Subject: Re: [ovirt-devel] Login is failing at master due to cookie hell
> 
> On 05/07/2014 12:41 PM, Roy Golan wrote:
> > On 05/07/2014 12:37 PM, Alon Bar-Lev wrote:
> >> Hi,
> >>
> >> Thanks Omer for the hint!
> >>
> >> Following merge of several patches HttpOnly cookie patch[1], and the new
> >> theme[2] (I guess), the login stopped working.
> >>
> >> The frontend is doing basic authentication against the restapi and
> >> attempt to
> >> move the cookie(?)? But it sending the cookie without http only marker.
> >>   I do not fully understand the logic, but it may parse the cookie
> >> manually in
> >> order to do so?
> >>
> >> Our cookies must have HttpOnly markers so this probably need to be
> >> solved at
> >> the component which sends the cookie without the HttpOnly.
> >>
> >> For now, people that experiencing this, please revert[1] until we can
> >> sort it
> >> out.
> >
> > I think its better to revert [1] till this has a fix
> 
> I mean to revert it in gerrit. and not locally by each developer

please do... you have permissions, right?

> 
> >>
> >> Thanks,
> >> Alon
> >>
> >> [1] http://gerrit.ovirt.org/#/c/25915/
> >> [2] http://gerrit.ovirt.org/#/c/24594/
> >> ___
> >> 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] Login is failing at master due to cookie hell

[Roy Golan]

On 05/07/2014 12:41 PM, Roy Golan wrote:

On 05/07/2014 12:37 PM, Alon Bar-Lev wrote:

Hi,

Thanks Omer for the hint!

Following merge of several patches HttpOnly cookie patch[1], and the new
theme[2] (I guess), the login stopped working.

The frontend is doing basic authentication against the restapi and 
attempt to

move the cookie(?)? But it sending the cookie without http only marker.
  I do not fully understand the logic, but it may parse the cookie 
manually in

order to do so?

Our cookies must have HttpOnly markers so this probably need to be 
solved at

the component which sends the cookie without the HttpOnly.

For now, people that experiencing this, please revert[1] until we can 
sort it

out.


I think its better to revert [1] till this has a fix


I mean to revert it in gerrit. and not locally by each developer



Thanks,
Alon

[1] http://gerrit.ovirt.org/#/c/25915/
[2] http://gerrit.ovirt.org/#/c/24594/
___
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] Login is failing at master due to cookie hell

[Roy Golan]

On 05/07/2014 12:37 PM, Alon Bar-Lev wrote:

Hi,

Thanks Omer for the hint!

Following merge of several patches HttpOnly cookie patch[1], and the new
theme[2] (I guess), the login stopped working.

The frontend is doing basic authentication against the restapi and attempt to
move the cookie(?)? But it sending the cookie without http only marker.
  
I do not fully understand the logic, but it may parse the cookie manually in

order to do so?

Our cookies must have HttpOnly markers so this probably need to be solved at
the component which sends the cookie without the HttpOnly.

For now, people that experiencing this, please revert[1] until we can sort it
out.


I think its better to revert [1] till this has a fix


Thanks,
Alon

[1] http://gerrit.ovirt.org/#/c/25915/
[2] http://gerrit.ovirt.org/#/c/24594/
___
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] vdsm disabling logical volumes

[Dan Kenigsberg]

On Wed, May 07, 2014 at 09:56:03AM +0200, Jiri Moskovcak wrote:
> On 05/07/2014 09:28 AM, Nir Soffer wrote:
> >- Original Message -
> >>From: "Jiri Moskovcak" 
> >>To: "Nir Soffer" 
> >>Cc: devel@ovirt.org, "Federico Simoncelli" , "Allon 
> >>Mureinik" , "Greg
> >>Padgett" , "Doron Fediuck" 
> >>Sent: Wednesday, May 7, 2014 10:21:28 AM
> >>Subject: Re: [ovirt-devel] vdsm disabling logical volumes
> >>
> >>On 05/05/2014 03:19 PM, Nir Soffer wrote:
> >>>- Original Message -
> From: "Jiri Moskovcak" 
> To: "Nir Soffer" 
> Cc: devel@ovirt.org, "Federico Simoncelli" , "Allon
> Mureinik" , "Greg
> Padgett" 
> Sent: Monday, May 5, 2014 3:44:21 PM
> Subject: Re: [ovirt-devel] vdsm disabling logical volumes
> 
> On 05/05/2014 02:37 PM, Nir Soffer wrote:
> >- Original Message -
> >>From: "Jiri Moskovcak" 
> >>To: "Nir Soffer" 
> >>Cc: devel@ovirt.org, "Federico Simoncelli" , "Allon
> >>Mureinik" , "Greg
> >>Padgett" 
> >>Sent: Monday, May 5, 2014 3:16:37 PM
> >>Subject: Re: [ovirt-devel] vdsm disabling logical volumes
> >>
> >>On 05/05/2014 12:01 AM, Nir Soffer wrote:
> >>>- Original Message -
> From: "Jiri Moskovcak" 
> To: "Nir Soffer" 
> Cc: devel@ovirt.org
> Sent: Sunday, May 4, 2014 9:23:49 PM
> Subject: Re: [ovirt-devel] vdsm disabling logical volumes
> 
> On 05/04/2014 07:57 PM, Nir Soffer wrote:
> >- Original Message -
> >>From: "Jiri Moskovcak" 
> >>To: devel@ovirt.org
> >>Sent: Sunday, May 4, 2014 8:08:33 PM
> >>Subject: [ovirt-devel] vdsm disabling logical volumes
> >>
> >>Greetings vdsm developers!
> >>
> >>While working on adding ISCSI support to the hosted engine tools, I
> >>ran
> >>into a problem with vdms. It seems that when stopped vdsm
> >>deactivates
> >>ALL logical volumes in it's volume group and when it starts it
> >>reactivates only specific logical volumes. This is a problem for
> >>hosted
> >>engine tools as they create logical volumes in the same volume group
> >>and
> >>when vdsm deactivates the LVs the hosted engine tools don't have a
> >>way
> >>to reactivate it, because the services drop the root permissions and
> >>are
> >>running as vdsm and apparently only root can activate LVs.
> >
> >Can you describe what volumes are you creating, and why?
> 
> We create hosted-engine.lockspace (for sanlock) and
> hosted-engine.metadata (keeps data about hosted engine hosts)
> >>>
> >>>Do you create these lvs in every vdsm vg?
> >>
> >>- only in the first vg created by vdsm while deploying hosted-engine
> >>>
> >>>It seems that the hosted engine has single point of failure - the random
> >>>vg that contains hosted engine data.
> >>>
> >>
> >>>Is this part of the domain structure
> >>>used by hosted engine, or it has nothing to do with the storage domain?
> >>
> >>- sorry, I don't understand this question. How can I tell if it has
> >>something to do with the storage domain? It's for storing data about
> >>hosts set up to run the hosted-engine and data about state of engine and
> >>the state of VM running the engine.
> >
> >Can you tell us exactly what lvs you are creating, and on which vg?
> >
> >And how are you creating those lvs - I guess through vdsm?
> >
> 
> - no hosted-engine tools do that by calling:
> 
> lvc = popen(stdin=subprocess.PIPE, stdout=subprocess.PIPE,
>    stderr=subprocess.PIPE,
>    args=["lvm", "lvcreate", "-L", str(size_bytes)+"B",
>  "-n", lv_name, vg_uuid])
> ..
> >>>
> >>>How do you ensure that another host is not modifying the same vg in the
> >>>same time?
> >>>
> >>>If you are not ensuring this, you will corrupt this vg sooner or later.
> >>>
> >>>When a storage domain is detached from a host, for example when the host
> >>>is in maintenance mode, lvs on the shared storage may be deleted,
> >>>invalidating
> >>>the devices mapper maps for these devices. If you write to an lv with wrong
> >>>maps, you may be writing to an extent belonging to another lv, corrupting
> >>>that
> >>>lv data, or even worse corrupting the engine vg data.
> >>>
> >>>How do you ensure that the lvs are not deleted while you are using them?
> >>>
> 
> >The output of lvs command on a host with hosted engine installed will
> >help us to understand what you are doing, and then we can think more
> >clearly
> >what would be the best way to support this in vdsm.
> 
> The output of lvs: http://fpaste.org/99196/93619139/
> 
> HE created these two LVs:
> ha_agent-hosted-engine.lockspace
> ha_agent-hosted-engine.m

Re: [ovirt-devel] Login is failing at master due to cookie hell

[Alon Bar-Lev]

Hi,

Thanks Omer for the hint!

Following merge of several patches HttpOnly cookie patch[1], and the new
theme[2] (I guess), the login stopped working.

The frontend is doing basic authentication against the restapi and attempt to
move the cookie(?)? But it sending the cookie without http only marker.
 
I do not fully understand the logic, but it may parse the cookie manually in
order to do so?

Our cookies must have HttpOnly markers so this probably need to be solved at
the component which sends the cookie without the HttpOnly.

For now, people that experiencing this, please revert[1] until we can sort it
out.

Thanks,
Alon

[1] http://gerrit.ovirt.org/#/c/25915/
[2] http://gerrit.ovirt.org/#/c/24594/
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Problem In Ovirt-Node

[Dan Kenigsberg]

On Wed, May 07, 2014 at 11:44:02AM +0800, yao xu wrote:
> Ah..
> 
> I replace a new netcard .But the old netcard's mac address is remembered by
> ovirt-node .(I can find the old netcard configure file in
> /var/lib/statelss/writable/etc/sysconfig/network-scripts/ )
> 
> Thus when I reboot the machine , the new netcard can't be up. If I remove
> the MAC address in configure file , everything will be OK.
> 
> Do you think it is a problem ? Have you ever fix this in new version .
> 
> Thanks for your reply.

That's a known issue, to which we do not have a clean-cut solution.
However, since ovirt-3.4 [1], you can configure Vdsm to avoid writing
HWADDR in its ifcfg files, by setting

hwaddr_in_ifcfg = never

in /etc/vdsm/vdsm.conf.

This can be safely done only if NetworkManager is turned off, or with
new versions of NetworkManager (/me thinks 0.9.9.1) that supports
"interface-name: unmanaged-spec".

[1] http://gerrit.ovirt.org/#/c/22288/6/lib/vdsm/config.py.in

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

Re: [ovirt-devel] vdsm disabling logical volumes

[Jiri Moskovcak]

On 05/07/2014 09:28 AM, Nir Soffer wrote:

- Original Message -

From: "Jiri Moskovcak" 
To: "Nir Soffer" 
Cc: devel@ovirt.org, "Federico Simoncelli" , "Allon Mureinik" 
, "Greg
Padgett" , "Doron Fediuck" 
Sent: Wednesday, May 7, 2014 10:21:28 AM
Subject: Re: [ovirt-devel] vdsm disabling logical volumes

On 05/05/2014 03:19 PM, Nir Soffer wrote:

- Original Message -

From: "Jiri Moskovcak" 
To: "Nir Soffer" 
Cc: devel@ovirt.org, "Federico Simoncelli" , "Allon
Mureinik" , "Greg
Padgett" 
Sent: Monday, May 5, 2014 3:44:21 PM
Subject: Re: [ovirt-devel] vdsm disabling logical volumes

On 05/05/2014 02:37 PM, Nir Soffer wrote:

- Original Message -

From: "Jiri Moskovcak" 
To: "Nir Soffer" 
Cc: devel@ovirt.org, "Federico Simoncelli" , "Allon
Mureinik" , "Greg
Padgett" 
Sent: Monday, May 5, 2014 3:16:37 PM
Subject: Re: [ovirt-devel] vdsm disabling logical volumes

On 05/05/2014 12:01 AM, Nir Soffer wrote:

- Original Message -

From: "Jiri Moskovcak" 
To: "Nir Soffer" 
Cc: devel@ovirt.org
Sent: Sunday, May 4, 2014 9:23:49 PM
Subject: Re: [ovirt-devel] vdsm disabling logical volumes

On 05/04/2014 07:57 PM, Nir Soffer wrote:

- Original Message -

From: "Jiri Moskovcak" 
To: devel@ovirt.org
Sent: Sunday, May 4, 2014 8:08:33 PM
Subject: [ovirt-devel] vdsm disabling logical volumes

Greetings vdsm developers!

While working on adding ISCSI support to the hosted engine tools, I
ran
into a problem with vdms. It seems that when stopped vdsm
deactivates
ALL logical volumes in it's volume group and when it starts it
reactivates only specific logical volumes. This is a problem for
hosted
engine tools as they create logical volumes in the same volume group
and
when vdsm deactivates the LVs the hosted engine tools don't have a
way
to reactivate it, because the services drop the root permissions and
are
running as vdsm and apparently only root can activate LVs.


Can you describe what volumes are you creating, and why?


We create hosted-engine.lockspace (for sanlock) and
hosted-engine.metadata (keeps data about hosted engine hosts)


Do you create these lvs in every vdsm vg?


- only in the first vg created by vdsm while deploying hosted-engine


It seems that the hosted engine has single point of failure - the random
vg that contains hosted engine data.




Is this part of the domain structure
used by hosted engine, or it has nothing to do with the storage domain?


- sorry, I don't understand this question. How can I tell if it has
something to do with the storage domain? It's for storing data about
hosts set up to run the hosted-engine and data about state of engine and
the state of VM running the engine.


Can you tell us exactly what lvs you are creating, and on which vg?

And how are you creating those lvs - I guess through vdsm?



- no hosted-engine tools do that by calling:

lvc = popen(stdin=subprocess.PIPE, stdout=subprocess.PIPE,
   stderr=subprocess.PIPE,
   args=["lvm", "lvcreate", "-L", str(size_bytes)+"B",
 "-n", lv_name, vg_uuid])
..


How do you ensure that another host is not modifying the same vg in the
same time?

If you are not ensuring this, you will corrupt this vg sooner or later.

When a storage domain is detached from a host, for example when the host
is in maintenance mode, lvs on the shared storage may be deleted,
invalidating
the devices mapper maps for these devices. If you write to an lv with wrong
maps, you may be writing to an extent belonging to another lv, corrupting
that
lv data, or even worse corrupting the engine vg data.

How do you ensure that the lvs are not deleted while you are using them?




The output of lvs command on a host with hosted engine installed will
help us to understand what you are doing, and then we can think more
clearly
what would be the best way to support this in vdsm.


The output of lvs: http://fpaste.org/99196/93619139/

HE created these two LVs:
ha_agent-hosted-engine.lockspace
ha_agent-hosted-engine.metadata


Why do you create these lvs on a vg owned by vdsm?

If you want total control of these lvs, I suggest that you create your own
vg and put what ever lvs you like there.



I would rather not go this way (at least not for 3.5) as it's too much
code changes in hosted-engine. On the other hand the logic in vdsm seems
wrong because it's not complementary (disabling all LVs and then
enabling just some of them) and should be fixed anyway. This problem is
blocking one of our 3.5 features so I've created rhbz#1094657 to track it.


Can you elaborate on this? How should vdsm behave better, and why?


Sure. So far I didn't hear any reason why it behaves like this and it 
seems not logical to disable *all* and then enable just *some*.


How: Disabling and enabling operations should be complementary.
Why: To be less surprising.

--Jirka





--Jirka



--Jirka











So far the
only suitable solution seems to be to change vdsm to only
deactivate/acti

Re: [ovirt-devel] vdsm disabling logical volumes

[Nir Soffer]

- Original Message -
> From: "Jiri Moskovcak" 
> To: "Nir Soffer" 
> Cc: devel@ovirt.org, "Federico Simoncelli" , "Allon 
> Mureinik" , "Greg
> Padgett" , "Doron Fediuck" 
> Sent: Wednesday, May 7, 2014 10:21:28 AM
> Subject: Re: [ovirt-devel] vdsm disabling logical volumes
> 
> On 05/05/2014 03:19 PM, Nir Soffer wrote:
> > - Original Message -
> >> From: "Jiri Moskovcak" 
> >> To: "Nir Soffer" 
> >> Cc: devel@ovirt.org, "Federico Simoncelli" , "Allon
> >> Mureinik" , "Greg
> >> Padgett" 
> >> Sent: Monday, May 5, 2014 3:44:21 PM
> >> Subject: Re: [ovirt-devel] vdsm disabling logical volumes
> >>
> >> On 05/05/2014 02:37 PM, Nir Soffer wrote:
> >>> - Original Message -
>  From: "Jiri Moskovcak" 
>  To: "Nir Soffer" 
>  Cc: devel@ovirt.org, "Federico Simoncelli" , "Allon
>  Mureinik" , "Greg
>  Padgett" 
>  Sent: Monday, May 5, 2014 3:16:37 PM
>  Subject: Re: [ovirt-devel] vdsm disabling logical volumes
> 
>  On 05/05/2014 12:01 AM, Nir Soffer wrote:
> > - Original Message -
> >> From: "Jiri Moskovcak" 
> >> To: "Nir Soffer" 
> >> Cc: devel@ovirt.org
> >> Sent: Sunday, May 4, 2014 9:23:49 PM
> >> Subject: Re: [ovirt-devel] vdsm disabling logical volumes
> >>
> >> On 05/04/2014 07:57 PM, Nir Soffer wrote:
> >>> - Original Message -
>  From: "Jiri Moskovcak" 
>  To: devel@ovirt.org
>  Sent: Sunday, May 4, 2014 8:08:33 PM
>  Subject: [ovirt-devel] vdsm disabling logical volumes
> 
>  Greetings vdsm developers!
> 
>  While working on adding ISCSI support to the hosted engine tools, I
>  ran
>  into a problem with vdms. It seems that when stopped vdsm
>  deactivates
>  ALL logical volumes in it's volume group and when it starts it
>  reactivates only specific logical volumes. This is a problem for
>  hosted
>  engine tools as they create logical volumes in the same volume group
>  and
>  when vdsm deactivates the LVs the hosted engine tools don't have a
>  way
>  to reactivate it, because the services drop the root permissions and
>  are
>  running as vdsm and apparently only root can activate LVs.
> >>>
> >>> Can you describe what volumes are you creating, and why?
> >>
> >> We create hosted-engine.lockspace (for sanlock) and
> >> hosted-engine.metadata (keeps data about hosted engine hosts)
> >
> > Do you create these lvs in every vdsm vg?
> 
>  - only in the first vg created by vdsm while deploying hosted-engine
> >
> > It seems that the hosted engine has single point of failure - the random
> > vg that contains hosted engine data.
> >
> 
> > Is this part of the domain structure
> > used by hosted engine, or it has nothing to do with the storage domain?
> 
>  - sorry, I don't understand this question. How can I tell if it has
>  something to do with the storage domain? It's for storing data about
>  hosts set up to run the hosted-engine and data about state of engine and
>  the state of VM running the engine.
> >>>
> >>> Can you tell us exactly what lvs you are creating, and on which vg?
> >>>
> >>> And how are you creating those lvs - I guess through vdsm?
> >>>
> >>
> >> - no hosted-engine tools do that by calling:
> >>
> >> lvc = popen(stdin=subprocess.PIPE, stdout=subprocess.PIPE,
> >>   stderr=subprocess.PIPE,
> >>   args=["lvm", "lvcreate", "-L", str(size_bytes)+"B",
> >> "-n", lv_name, vg_uuid])
> >> ..
> >
> > How do you ensure that another host is not modifying the same vg in the
> > same time?
> >
> > If you are not ensuring this, you will corrupt this vg sooner or later.
> >
> > When a storage domain is detached from a host, for example when the host
> > is in maintenance mode, lvs on the shared storage may be deleted,
> > invalidating
> > the devices mapper maps for these devices. If you write to an lv with wrong
> > maps, you may be writing to an extent belonging to another lv, corrupting
> > that
> > lv data, or even worse corrupting the engine vg data.
> >
> > How do you ensure that the lvs are not deleted while you are using them?
> >
> >>
> >>> The output of lvs command on a host with hosted engine installed will
> >>> help us to understand what you are doing, and then we can think more
> >>> clearly
> >>> what would be the best way to support this in vdsm.
> >>
> >> The output of lvs: http://fpaste.org/99196/93619139/
> >>
> >> HE created these two LVs:
> >> ha_agent-hosted-engine.lockspace
> >> ha_agent-hosted-engine.metadata
> >
> > Why do you create these lvs on a vg owned by vdsm?
> >
> > If you want total control of these lvs, I suggest that you create your own
> > vg and put what ever lvs you like there.
> >
> 
> I would rather not go this way (at least not for 3.5) as it's too

Re: [ovirt-devel] vdsm disabling logical volumes

[Jiri Moskovcak]

On 05/05/2014 03:19 PM, Nir Soffer wrote:

- Original Message -

From: "Jiri Moskovcak" 
To: "Nir Soffer" 
Cc: devel@ovirt.org, "Federico Simoncelli" , "Allon Mureinik" 
, "Greg
Padgett" 
Sent: Monday, May 5, 2014 3:44:21 PM
Subject: Re: [ovirt-devel] vdsm disabling logical volumes

On 05/05/2014 02:37 PM, Nir Soffer wrote:

- Original Message -

From: "Jiri Moskovcak" 
To: "Nir Soffer" 
Cc: devel@ovirt.org, "Federico Simoncelli" , "Allon
Mureinik" , "Greg
Padgett" 
Sent: Monday, May 5, 2014 3:16:37 PM
Subject: Re: [ovirt-devel] vdsm disabling logical volumes

On 05/05/2014 12:01 AM, Nir Soffer wrote:

- Original Message -

From: "Jiri Moskovcak" 
To: "Nir Soffer" 
Cc: devel@ovirt.org
Sent: Sunday, May 4, 2014 9:23:49 PM
Subject: Re: [ovirt-devel] vdsm disabling logical volumes

On 05/04/2014 07:57 PM, Nir Soffer wrote:

- Original Message -

From: "Jiri Moskovcak" 
To: devel@ovirt.org
Sent: Sunday, May 4, 2014 8:08:33 PM
Subject: [ovirt-devel] vdsm disabling logical volumes

Greetings vdsm developers!

While working on adding ISCSI support to the hosted engine tools, I
ran
into a problem with vdms. It seems that when stopped vdsm deactivates
ALL logical volumes in it's volume group and when it starts it
reactivates only specific logical volumes. This is a problem for
hosted
engine tools as they create logical volumes in the same volume group
and
when vdsm deactivates the LVs the hosted engine tools don't have a way
to reactivate it, because the services drop the root permissions and
are
running as vdsm and apparently only root can activate LVs.


Can you describe what volumes are you creating, and why?


We create hosted-engine.lockspace (for sanlock) and
hosted-engine.metadata (keeps data about hosted engine hosts)


Do you create these lvs in every vdsm vg?


- only in the first vg created by vdsm while deploying hosted-engine


It seems that the hosted engine has single point of failure - the random
vg that contains hosted engine data.




Is this part of the domain structure
used by hosted engine, or it has nothing to do with the storage domain?


- sorry, I don't understand this question. How can I tell if it has
something to do with the storage domain? It's for storing data about
hosts set up to run the hosted-engine and data about state of engine and
the state of VM running the engine.


Can you tell us exactly what lvs you are creating, and on which vg?

And how are you creating those lvs - I guess through vdsm?



- no hosted-engine tools do that by calling:

lvc = popen(stdin=subprocess.PIPE, stdout=subprocess.PIPE,
  stderr=subprocess.PIPE,
  args=["lvm", "lvcreate", "-L", str(size_bytes)+"B",
"-n", lv_name, vg_uuid])
..


How do you ensure that another host is not modifying the same vg in the
same time?

If you are not ensuring this, you will corrupt this vg sooner or later.

When a storage domain is detached from a host, for example when the host
is in maintenance mode, lvs on the shared storage may be deleted, invalidating
the devices mapper maps for these devices. If you write to an lv with wrong
maps, you may be writing to an extent belonging to another lv, corrupting that
lv data, or even worse corrupting the engine vg data.

How do you ensure that the lvs are not deleted while you are using them?




The output of lvs command on a host with hosted engine installed will
help us to understand what you are doing, and then we can think more
clearly
what would be the best way to support this in vdsm.


The output of lvs: http://fpaste.org/99196/93619139/

HE created these two LVs:
ha_agent-hosted-engine.lockspace
ha_agent-hosted-engine.metadata


Why do you create these lvs on a vg owned by vdsm?

If you want total control of these lvs, I suggest that you create your own
vg and put what ever lvs you like there.



I would rather not go this way (at least not for 3.5) as it's too much 
code changes in hosted-engine. On the other hand the logic in vdsm seems 
wrong because it's not complementary (disabling all LVs and then 
enabling just some of them) and should be fixed anyway. This problem is 
blocking one of our 3.5 features so I've created rhbz#1094657 to track it.


--Jirka



--Jirka











So far the
only suitable solution seems to be to change vdsm to only
deactivate/activate it's own LVs.


This sounds reasonable. You can add a list of hosted engine lv names
and skip these volumes when deactivating vdsm volumes.


- this sounds a bit suboptimal, vdsm already has list of it's LVs, so it
can just disable only LVs known to it, otherwise we would have to change
the list everytime we add some LV to the group


vdsm has a list of special lvs, that needs special treatment. Otherwise,
it
consider any other lv as owned by vdsm, and will deactivate them when
they
are
not used.

I agree that this will create a dependency, but this can also be solved.
For example, vdsm can load the list from a