Re: [ovirt-devel] patch granularity, extracting patches

[Martin Mucha]

Hi,

I think I have found a rule which applies to lot of CRs. If you submit set
of small patches, you will be asked to squash them, and if you submit 'big
bang' patch, you will be asked to split it. Sometimes, and that's the
hardest situation, you are asked to do both :D

I think you should lead with what is most effective for you to work with.
And that ideally should be (for your own good) small commits with one (or
some small number) logical change (rename this, add this) in local feature
branch. That way you can easily remove some change if it's not needed in
the end, you have patches ready for 'fine granularity reviewer', and if you
need to provide big bang patch of 'bulk reviewer', you can create one in
seconds. And potential 're-split' is easy too, you just squash them again
differently.

Squashing is easy, splitting is not.

_warning_mine_opinion_:
About patch size in general. It's like method / class names. If it's called
'perform' and have 100 LOC, it's most probably bad. Thus if your patch
description does not list all the changes and/or its description is
excessively long: "I did X and Y, then Z, while W, unless Q", then your
patch is big, and kinda defies purpose of VCS. Next time you should write
smaller one, and squash it to bulk patch only if reviewer insists. Also
patch "rename methodA->methodB" takes no time to review(eyes are really
good to see same patterns), with small probablility of error, and when we
all use IDE for refactorings, there's no need to review it at all. Five
renames and method extractions in one patch, garnished with added (even
trivial) new functionality is significantly harder to review, and reviewer
really needs to pay attention to every line change.

M.


On Thu, Jun 29, 2017 at 6:16 PM, Greg Sheremeta  wrote:

> Do we have or follow a standard on patch granularity? When I started, I
> picked up on the culture that we do small, logical commits -- as much as
> possible, each commit should be focused on a specific purpose. I've
> perceived some reviewers prefer to have all orthogonal changes (fix a
> random spelling error, remove a duplicate semicolon) extracted to other
> patches for clarity. Others don't seem to mind. I feel like I always want
> to ask, but I feel bad because it's a hassle.
>
> Also, when you are asked to extract something, do you have a trick to make
> it as easy as possible?
>
> Best wishes,
> Greg
>
> --
> Greg Sheremeta, MBA
> Sr. Software Engineer
> Red Hat, Inc.
> 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

Re: [ovirt-devel] Writing SQL queries in DAO code

[Martin Mucha]

On Thu, Mar 30, 2017 at 9:31 AM, Eli Mesika <emes...@redhat.com> wrote:

>
>
> On Wed, Mar 29, 2017 at 4:23 PM, Martin Mucha <mmu...@redhat.com> wrote:
>
>> Hi,
>>
>> I didn't want to step into this, but I was asked by dan to express my
>> opinion about this. I'm not pushing for change (since I believe it will be
>> blocked), I'm just trying to help us focus. We should have some questions
>> answered prior to saying what we want to do...
>>
>> Current state of accessing db is that there's fired lots of unnecessary
>> db calls, just because there isn't easy way to do them correctly, someone
>> is lazy, whatever, that isn't important. The blame was laid on invalid code
>> review. Now let me remember maintainer Kolesnik, who during CR *insisted*
>> on creating N+1 problem[1] when accessing db, to save ±10 lines of code in
>> dal layer. So Eli is right, our code suck because of improper code revision
>> process, but sometimes it is maintainers who wants invalid code to be
>> pushed to simplify db access code. Therefore we cannot rely on review
>> process, this is real issue we have. I'm fine with it, this is how we do
>> things. But we also have (sometimes (a lot)) degraded performance because
>> of it.
>>
>> We should have answered following questions:
>>
>> 1) is performance even important at all? Should we optimize db access?
>> I'm assuming "yes" should be the answer. If it's not the answer, we can
>> skip next questions.
>>
>> 2) can someone responsible for whole project provide timings and count of
>> queries? This should easily bring crosshair on commands requiring attention.
>>   2.1) customer is issuing synchronous command. What is maximum number of
>> queries this command (plus all transitive internal commands) should fire?
>> What's the number for asynchronous command?
>>   2.2) same for time; what is the maximum time for synchronous and
>> asynchronous command?
>>
>> 3) lets say that we found command which requires optimization (and that
>> should not be hard). If we go back to mentioned N+1 problem, it's rather
>> easy to avoid it for one association(yet we did not do it even there), but
>> it's not that easy for multiple joins [1]. But it's superbly easy to
>> achieve it using ORM tool, even with still using only named queries, even
>> native ones defined outside of java. Supposing we want to optimize found
>> command, what would dal maintainers consider as a acceptable optimization?
>> Is there even possibility to not use stored procedures? I believe saying
>> simple "no", if that's the case, is valid response, which can save time. If
>> there is theoretical possibility, what criteria must be met so that we can
>> consider replacing most trivial stored procedures with some tool in our
>> project? There are lots of tools/frameworks, based on your criteria we
>> might find some, which would work best...
>>
>> —
>>
>> My generic opinion would be to stick with sp and allowing to use
>> something less heavy for simplest queries/stuff. It could beJPA using ORM
>> and entities. Or named queries (still using entities) or nativequeries
>> (which does not use entities, but plain sql) and both ends up creating
>> prepared statements on server startup. Or we could use some lighter orm.
>> But I'd definitely avoid writing any new homebrewed approach, this isn't a
>> sane option.
>>
>
> ​In that case , if we will not use SP , we still will have to secure the
> data (for example , hidden columns for some users like in the VDS view)​
>
*Sorry, but I asked 3 questions we should have answers for to decide
further steps. We have to start with what we want, and as I said, until
then, all _generic opinions_ (including mine ones) are irrelevant. Can you
please answer them? IIUC yevgeny is trying to find a way how to improve our
project, but that's hard to accoplish if we do not have defined, what do we
expect from our project. The thing, that developers and maintainers are
avoiding writing new specific queries is real issue to tackle, and one of
reasons they do so is lots of code need to be written. Therefore yevgeny I
believe is trying to find a way how to overcome this. We can focus our
efforts in this area, or at least say boldly „we do not want any changes”,
both is fine I believe.*

*You mentioned need to secure data. Is this sole reason which bounds us to
SP? Can you give me link to specific example, so that I can understand
better why we cannot use simple queries without SP? Is this limitation
really relevant to majority of simple queries yevgeny is interrested
in?** (since
nobody is talking about dropping SP alt

Re: [ovirt-devel] Writing SQL queries in DAO code

[Martin Mucha]

Hi,

I didn't want to step into this, but I was asked by dan to express my
opinion about this. I'm not pushing for change (since I believe it will be
blocked), I'm just trying to help us focus. We should have some questions
answered prior to saying what we want to do...

Current state of accessing db is that there's fired lots of unnecessary db
calls, just because there isn't easy way to do them correctly, someone is
lazy, whatever, that isn't important. The blame was laid on invalid code
review. Now let me remember maintainer Kolesnik, who during CR *insisted*
on creating N+1 problem[1] when accessing db, to save ±10 lines of code in
dal layer. So Eli is right, our code suck because of improper code revision
process, but sometimes it is maintainers who wants invalid code to be
pushed to simplify db access code. Therefore we cannot rely on review
process, this is real issue we have. I'm fine with it, this is how we do
things. But we also have (sometimes (a lot)) degraded performance because
of it.

We should have answered following questions:

1) is performance even important at all? Should we optimize db access? I'm
assuming "yes" should be the answer. If it's not the answer, we can skip
next questions.

2) can someone responsible for whole project provide timings and count of
queries? This should easily bring crosshair on commands requiring attention.
  2.1) customer is issuing synchronous command. What is maximum number of
queries this command (plus all transitive internal commands) should fire?
What's the number for asynchronous command?
  2.2) same for time; what is the maximum time for synchronous and
asynchronous command?

3) lets say that we found command which requires optimization (and that
should not be hard). If we go back to mentioned N+1 problem, it's rather
easy to avoid it for one association(yet we did not do it even there), but
it's not that easy for multiple joins [1]. But it's superbly easy to
achieve it using ORM tool, even with still using only named queries, even
native ones defined outside of java. Supposing we want to optimize found
command, what would dal maintainers consider as a acceptable optimization?
Is there even possibility to not use stored procedures? I believe saying
simple "no", if that's the case, is valid response, which can save time. If
there is theoretical possibility, what criteria must be met so that we can
consider replacing most trivial stored procedures with some tool in our
project? There are lots of tools/frameworks, based on your criteria we
might find some, which would work best...

—

My generic opinion would be to stick with sp and allowing to use something
less heavy for simplest queries/stuff. It could beJPA using ORM and
entities. Or named queries (still using entities) or nativequeries (which
does not use entities, but plain sql) and both ends up creating prepared
statements on server startup. Or we could use some lighter orm. But I'd
definitely avoid writing any new homebrewed approach, this isn't a sane
option.

[1] example: Lets discuss query association A—>B—>C, 5xA, each A has 5B
etc. In our typical dao this will mean 1+5+5*5=31 queries. Same with
properly annotated ORM sums up to 1 or 3 queries.


M.

On Mon, Mar 27, 2017 at 5:38 PM, Yevgeny Zaspitsky 
wrote:

>
>
> On Mon, Mar 27, 2017 at 5:30 PM, Yevgeny Zaspitsky 
> wrote:
>
>>
>>
>> On Mon, Mar 27, 2017 at 12:45 PM, Eli Mesika  wrote:
>>
>>>
>>>
>>> On Mon, Mar 27, 2017 at 12:26 PM, Yevgeny Zaspitsky >> > wrote:
>>>
 > I don't think that looking in SQL in Java code is ​clear than looking
 in a SP code

 Looking in SQL isn't the problem I'm trying to solve, but finding that.

 > 1) You will pass more data on the wire instead of calling a SP with
 parameters

 Passing the SQL string shouldn't be a problem unless that is very long
 one (several K) and then we probably do something wrong.

 > 2) Your data that is passed on the wire is exposed to attacks since
 you will have to implement DB security in the engine level (for example
 hidden columns).

 IIUC currently querying tables/views with hidden columns is implemented
 in a SP that consist of at least 2 SQL's, so those aren't good candidates
 for my proposal and will stay as is.
 BTW how other projects resolve the security problem? AFAIK usually
 hidden columns are hidden by defining a proper view that do not include
 those.

>>>
>>> ​That's a bad solution as long as your data is passed unmasked on the
>>> wire ​
>>>
>>
>> In some cases we do send a sensitive info in the current solution that
>> uses SP's.
>> Should we use (maybe already) a kind of secured connection to DB?
>>
>> Database security should be done in the database level and you will not
>>> be able to do that without using SPs
>>>
>>
>> I'm not a DB security expert, but from my experience from my 

Re: [ovirt-devel] Caching of data from the database done properly

[Martin Mucha]

Hi,

some of information in mail are not exactly true. Namely MacPoolPerCluster 
*does not do caching*, it does not even have DB layer structures it could 
cache. So how it works is: pool has configuration upon which it initialize 
itself. After that, it looks into db for all used MACs, which currently happens 
to be querying all MAC addresses of all VmNics. So this is initialized from 
data in DB, but it does not cache them. Clients [of pool] asks pool for MAC 
address, which is then used somewhere without pool supervision. I don't want to 
question this design, and I'm not saying that it wouldn't be possible to move 
it's logic to db layer, but once, long, long time ago someone decided this to 
be done on bll, and so it is on bll layer.

I understand, that these might come as a problem in arquillian testing, but 
that's to be resolved, since, not all singletons are for caching. And even if 
they are, testing framework should be able to cope with such common beans, we 
shouldn't limit ourselves not to use singletons. Therefore, I wouldn't invest 
into changing these 'caches', but into allowing more complex setups in our 
testing. If it's not possible, then 'reset' method is second best solution — we 
have to use write lock as suggested in cr, and then it should be fine.

About drawbacks:
ad 1) yes, this comes as an extra problem, one has to deal with tx on his own, 
that's true. This wasn't part of original solution, but it should be fixed 
already.
ad 2) No. Caching done correctly is done closest to the consumer. I assume you 
can similarly ruin hibernate l2 cache via accessing data through different 
channel. But that's kinda common to all caches — if you bypass them, you'll 
corrupt them. So do not bypass them, or in this case, use them as they was 
designed. As it have been said, you ask pool for mac, or inform it, that you're 
going to use your own, and then use it. It means, that it's designed to 
actually bypass it on all writes. Therefore if someone writes a code using MAC 
without prior notification to the pool about such action, it would be a 
problem. To avoid this problem there has to be bigger refactor — pool would 
have to persist MAC addresses somehow and not vmNicDao, or if moved entirelly 
to db layer, there would have to be trigger on vmnic table or something like 
that...
ad 3) It was requested, to have at least tens of millions of macs in pool. 
Forget about loop, initializing this structure for given clusterId is not 
acceptable even once per request. Loading that structure is quite cheap (now), 
but not that cheap to allow what you ask for. Moving whole stuff to db layer 
would be probably beneficial (when it was originally implemented), but it's 
worthless doing it now.

About suggestions: neither of them applies to MacPoolPerCluster — point (3) for 
example: since pool is not a simple cache of db structure, and does not have 
corresponding data in db layer, it cannot cache writes and it even does not do 
any writes at all...

——
Surely I can imagine better implementation of this, but it'd require bigger 
changes whose benefits aren't worth of cost of this change. (I hope that) we 
have to deal with it. This was original design, and since testing framework 
(with changed caches or without) should deal with singletons etc. anyways, it's 
not worthy to change it. If there aren't any better options(I don't know), 
reinitializing bean can be used (and I apologize for blocking that). I'd avoid 
bigger rewrites in this area.

M.


- Original Message -
> On Mon, Jul 4, 2016 at 11:58 PM, Roman Mohr  wrote:
> > Hi Everyone,
> >
> > I wanted to discuss a practice which seems to be pretty common in the
> > engine which I find very limiting, dangerous and for some things it
> > can even be a blocker.
> >
> > There are several places in the engine where we are using maps as
> > cache in singletons to avoid reloading data from the database. Two
> > prominent ones are the QuotaManager[1] and the MacPoolPerCluster[2].
> >
> > While it looks tempting to just use a map as cache, add some locks
> > around it and create an injectable singleton, this has some drawbacks:
> >
> > 1) We have an autoritative source for our data and it offers
> > transactions to take care of inconsistencies or parallel updates.
> > Doing all that in a service again duplicates this.
> > 2) Caching on the service layer is definitely not a good idea. It can
> > introduce unwanted side effects when someone invokes the DAOs
> > directly.
> > 3) The point is more about the question if a cache is really needed:
> > Do I just want that cache because I find it convenient to do a
> > #getMacPoolForCluster(Guid clusterId) in a loop instead of just
> > loading it once before the loop, or do my usage requirements really
> > force me to use a cache?
> >
> > If you really need a cache, consider the following:
> >
> > 1) Do the caching on the DAO layer. This guarantees the best
> > consistency across the data.
> > 

Re: [ovirt-devel] Failing MacPoolDaoTests on master

[Martin Mucha]

I do apologize, fix patches are done and should be merged soon ...

M.

- Original Message -
> On Tue, May 31, 2016 at 10:13 AM, Barak Korren  wrote:
> > On 31 May 2016 at 10:45, Roman Mohr  wrote:
> >> Hi,
> >>
> >> DAO tests are failing on master in
> >>
> >> org.ovirt.engine.core.dao.MacPoolDaoTest.
> >>
> >> Build logs are here:
> >> https://travis-ci.org/oVirt/ovirt-engine/builds/134082394
> >>
> > Or here:
> > http://jenkins.ovirt.org/job/ovirt-engine_4.0_dao-unit-tests_created/3/console
> >
> > It seems there is a vdsm-jsonrpc-java-client build missing?
> >
> That seems to be another issue. When building locally and on travis we
> have failing dao tests, not missing libraries.
> 
> Further, on jenkins it seems like we are not running the DAO tests
> since 26th of May.
> Wrote a mail to infra list regarding that about an hour ago.
> 
> > 07:13:31 [ERROR] Failed to execute goal on project
> > common-dependencies: Could not resolve dependencies for project
> > org.ovirt.engine.core.manager:common-dependencies:jar:4.0.0: Could not
> > find artifact
> > org.ovirt.vdsm-jsonrpc-java:vdsm-jsonrpc-java-client:jar:1.2.3
> > in ovirt-maven-repository
> > (http://artifactory.ovirt.org/artifactory/ovirt-mirror) -> [Help 1]
> > 07:13:31 [ERROR]
> >
> >
> > --
> > Barak Korren
> > bkor...@redhat.com
> > RHEV-CI Team
> ___
> 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] Integration tests future (and very nice alternative for the DAO fixture file)

[Martin Mucha]

Having such builders would simplify our lives for sure. But I'd really try to 
avoid any autogeneration. I would cost lots of man hours to make it happen and 
result won't be good. If we agree to use this approach, and everyone write new 
methods as they're needed, 'some basic builders' come to life very easy and 
fast. Also some places already has such similar builders — like 
org.ovirt.engine.core.bll.network.host.HostSetupNetworksValidatorTest.HostSetupNetworksValidatorBuilder.

M.

- Original Message -
> Hi Roman,
> 
> I really like the idea behind domain object builders.
> 
> Maybe a silly question, but how much effort would it take
> to autogenerate some "basic" builders from domain objects?
> (without DAO/Integration test related stuff like prePersist
> override etc.)
> 
> From the "basic" builders we could derive DAO/Integration
> ones as subclasses. This way, the domain object specific
> stuff wouldn't have to be kept in sync by hand, and we can
> subclass only if we need to make a builder DAO/Integration
> test aware.
> 
> Vojtech
> 
> 
> - Original Message -
> > From: "Roman Mohr" 
> > To: "Eyal Edri" 
> > Cc: "Juan Antonio Hernandez Fernandez" , "devel"
> > 
> > Sent: Thursday, April 14, 2016 1:05:25 PM
> > Subject: Re: [ovirt-devel] Integration tests future (and very nice
> > alternative for the DAO fixture file)
> > 
> > 
> > 
> > On Thu, Apr 14, 2016 at 12:32 PM, Eyal Edri < ee...@redhat.com > wrote:
> > 
> > 
> > 
> > Will that replace the current DAO tests running in CI?
> > 
> > 
> > For now no. What you can do with the builders reagarding to the DAO tests
> > is
> > creating test scenarios for the database. So instead of adding entities to
> > the fixture file you can set up clean sceanrios for your tests just with
> > the
> > builders in @Test or @Before methods.
> > 
> > Integration tests are using Arqullian with the spring transaction manager
> > and
> > will probably an extra CI job which passes the right maven flags.
> > Arquillian
> > is nice here because we are much closer to a real JBoss than with Spring.
> > 
> > The reason why we do not use Arquillian and only the builders for the DAO
> > test is that you would need a full JBoss downloaded in the background to
> > give us a transaction manager which does the same thing as springs
> > transaction manager does during the build.
> > 
> > The JBoss people are currently working on modularizing all their JBoss
> > libraries (for JBoss Swarm) and I hope that in the future we can drop the
> > spring transaction manager and do everything with arquillian and the JBoss
> > transaction manager.
> > 
> > 
> > 
> > On Wed, Apr 13, 2016 at 4:22 PM, Roman Mohr < rm...@redhat.com > wrote:
> > 
> > 
> > 
> > Hi all,
> > 
> > In [1] you can find some patches which are meant to improve the test
> > writing
> > experience in ovirt-engine.
> > 
> > They provide the following things:
> > 
> > A) Domain Object builders which can be used for creating and/or persisting
> > domain objects [2]
> > B) DAO testing without writing fixtures because of the builders
> > C) Integration testing for commands in conjunction with a real database
> > Arquillian, injectable commands and the builders [3]
> > 
> > # How to run what?
> > 
> > A) In normal unit tests just create a new instance of a builder and use it.
> > This should help us to get rid of all the small createDefaultVm(),
> > createHostWithX() helper methods in our tests.
> > 
> > B) In dao tests just inject them and go ahead. The advantage of not using
> > the
> > fixture file is that we can now set up clean scenarios for every test in a
> > setup method. See example 2 below on how easy it is to set up a new
> > cluster.
> > 
> > C) Arquillian integration tests need to be marked with
> > "@Category(IntegrationTest.class)" and can inherit from
> > TransactionalTestBase. The @Category annotation makes sure that the
> > integration tests are only run when
> > 
> > mvn clean verify -DskipITs=false
> > 
> > is invoked. Note that these tests are then executed in the integration test
> > phase of maven. For them we use the maven-failsafe-plugin[5] which will
> > also
> > make sure that the testing database is up to date. See [4] for more
> > details.
> > 
> > # Examples
> > 
> > 1) Add a running VM to a host, persist everything to the database and load
> > all VMs which are running on the host:
> > 
> > VDS host = vdsBuilder.cluster(persistedCluster).persist();
> > vmBuilder.host(host).up().persist();
> > List vms = vmDao.getAllRunningForVds(host.getId());
> > 
> > 2) Add 10 hosts with 1 GB of RAM to a cluster, persist the hosts to the
> > database in a DAO test:
> > 
> > public class MyHostDaoTest extends BaseDaoTestCase {
> > 
> > @Inject
> > private VdsBuilder vdsBuilder;
> > 
> > @Test
> > public void createHosts() {
> > VdsBuilder builder =
> > vdsBuilder.cluster(persistedCluster).physicalMemory(1000);
> > for (int x 

Re: [ovirt-devel] Proposing Martin Betak as oVirt UI maintainer

[Martin Mucha]

- Original Message -
> 
> 
> On Mon, Feb 8, 2016 at 10:28 AM, Martin Betak < mbe...@redhat.com > wrote:
> 
> 
> Thanks everyone for their expressed support!
> 
> I hope I'll be able to continue working towards improving our existing
> frontend codebase and whatever may serve as the UI in the future :-)
> 
> Best regards,
> 
> Martin B.
> 
> 
> Congratulations!
> 
> 

Congratulations from me as well.

> 
> - Original Message -
> > From: "Tomas Jelinek" < tjeli...@redhat.com >
> > To: "Martin" < mbe...@redhat.com >
> > Cc: "devel" < devel@ovirt.org >
> > Sent: Monday, February 8, 2016 10:19:34 AM
> > Subject: Re: [ovirt-devel] Proposing Martin Betak as oVirt UI maintainer
> > 
> > congrats! :)
> > 
> > - Original Message -
> > > From: "David Caro" < dc...@redhat.com >
> > > To: "Vojtech Szocs" < vsz...@redhat.com >
> > > Cc: "Michal Skrivanek" < mskri...@redhat.com >, "devel" < devel@ovirt.org
> > > >
> > > Sent: Monday, February 8, 2016 10:11:30 AM
> > > Subject: Re: [ovirt-devel] Proposing Martin Betak as oVirt UI maintainer
> > > 
> > > On 02/03 09:00, Vojtech Szocs wrote:
> > > > Hello, UI folks!
> > > > 
> > > > I'd like to propose Martin Betak as oVirt UI maintainer.
> > > 
> > > 
> > > I've added him to the ovirt-engine-webadmin gerrit group, let me know if
> > > there's anything else needed
> > > 
> > > > 
> > > > Over time, Martin made some significant UI contributions:
> > > > 
> > > > - improving UiCommon by utilizing Java generics [1]
> > > > 
> > > > - adding GinUiBinder [2] to allow @Inject'ing GIN-managed
> > > > objects into GWT widgets created in ui.xml templates
> > > > 
> > > > - upgrade GWT version to 2.6.1 [3] for both oVirt webapps
> > > > 
> > > > - providing excellent feedback and ideas on oVirtJS project
> > > > [4] while demonstrating outstanding JavaScript knowledge
> > > > 
> > > > [1] https://gerrit.ovirt.org/#/c/32907/
> > > > [2] https://gerrit.ovirt.org/#/c/34954/
> > > > [3] https://gerrit.ovirt.org/#/c/32135/
> > > > [4] https://gerrit.ovirt.org/#/c/49466/
> > > > 
> > > > Personal note: Martin is familiar with oVirt GWT UI infra
> > > > as a whole (GWT-P component model, advanced GWT features,
> > > > UiCommon integration etc). His grasp on JS and its current
> > > > eco-system is very solid.
> > > > 
> > > > Regards,
> > > > Vojtech
> > > > ___
> > > > Devel mailing list
> > > > Devel@ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/devel
> > > 
> > > --
> > > David Caro
> > > 
> > > Red Hat S.L.
> > > Continuous Integration Engineer - EMEA ENG Virtualization R
> > > 
> > > Tel.: +420 532 294 605
> > > Email: dc...@redhat.com
> > > IRC: dcaro|dcaroest@{freenode|oftc|redhat}
> > > Web: www.redhat.com
> > > RHT Global #: 82-62605
> > > 
> > > ___
> > > 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] missing "jinja2"??

[Martin Mucha]

- Original Message -
> 
> 
> - Original Message -
> > From: "Sandro Bonazzola" <sbona...@redhat.com>
> > To: "Marek Libra" <mli...@redhat.com>, "Rafael Martins"
> > <rmart...@redhat.com>
> > Cc: "devel" <devel@ovirt.org>, "Martin Mucha" <mmu...@redhat.com>
> > Sent: Thursday, February 4, 2016 6:11:51 PM
> > Subject: Re: [ovirt-devel] missing "jinja2"??
> > 
> > Il 04/Feb/2016 09:58, "Marek Libra" <mli...@redhat.com> ha scritto:
> > >
> > > Hi,
> > >
> > > try
> > > dnf install python-jinja2
> > 
> > Rafael please check deps on fedora
> 
> Sandro, deps are correct, Martin probably installed stuff manually.


that's true. When engine complained, I tried to search for answer on google, 
then I searched zimbra (no results, no idea why), then I installed library 
using pip (no idea why that wasn't sufficient for engine). Then I got hint how 
to install it using dnf (from several guys, sorry for not responding to all of 
you). 'After dnf' I can confirm engine works again. 

Thanks to all involved in helping me.
M.


> 
> Rafael
> 
> > >
> > > M.
> > > - Original Message -
> > > > From: "Martin Mucha" <mmu...@redhat.com>
> > > > To: "devel" <devel@ovirt.org>
> > > > Sent: Thursday, February 4, 2016 8:14:22 AM
> > > > Subject: [ovirt-devel] missing "jinja2"??
> > > >
> > > > Hi,
> > > >
> > > > if I try to run engine now, I'm getting following, even if jinja2 is
> > > > (manually) installed. How to fix that?
> > > >
> > > > File
> > > >
> > "/home/mmucha/build/ovirt-engine/share/ovirt-engine/services/ovirt-engine/ovirt-engine.py",
> > > > line 26, in 
> > > > from jinja2 import Template
> > > > ImportError: cannot import name Template
> > > >
> > > >
> > > > thanks,
> > > > M.
> > > > ___
> > > > 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

[ovirt-devel] missing "jinja2"??

[Martin Mucha]

Hi,

if I try to run engine now, I'm getting following, even if jinja2 is (manually) 
installed. How to fix that?

File 
"/home/mmucha/build/ovirt-engine/share/ovirt-engine/services/ovirt-engine/ovirt-engine.py",
 line 26, in 
from jinja2 import Template
ImportError: cannot import name Template


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

Re: [ovirt-devel] removing parameterized constructors from queries.

[Martin Mucha]

- Original Message -
> Hi Martin,
> 
> I'd like to address this with the same approach as suggested by Idan for
> Commands [1] .
> 

I may not understand your comment right, so I do apologize if i'm saying 
something nonsensical.

Having parameterized constructors is OK, and their benefits are well known. 
However having CDI and parameterized constructors is somewhat contradictory — 
if it does something, then it's problems.
Another side effect of this removal is also removal of some of reflection code, 
which is also good.

>1. It preserves the support for postConstruct() which is implemented
>explicitly in your patch by setup() method.

 postConstruct generally is preserved even without parameterized 
constructors. It's not too common in our code (if I'm not mistaken) to touch 
parameters/context in postconstruct, which is only true reason, why we *need* 
parameterized constructors. Even then, it's only wrong — these manipulations 
should not be done in postconstruct methods, but we can still workaround it, 
since, as we're calling injection manually, we can create bean, setup it, and 
then call injection. It's not good, sure, but it's better to have few bad 
places, that all places bad.

>2. The suggested patch allows to define the classes as mutable - where
>the affect of it is unknown and probably not welcome.

 I did simplest implementation for code review. It's not problematic to 
implement setup method so it can be called only once, thus modification of 
parameters / context are not possible just like with constructors.

>3. It blocks queries from any future treatment of the parameters are
>creation time.

 I don't understand this sentence.
 If you're talking about final fields immutability, then it's valid only 
for queryType. Other 3 fields (parameters, returnValue, engineContext) are 
mutable, so even if pointer remains unchanged, queries may fiddle with its 
content as they wish. If that was your point, there's actually no difference (I 
believe) in these 2 approaches.

> 
> Having a single c'tor which expects both parameters will solve that issue,
> same as done for the commands.

yes, it can be solved by requiring *one* full constructor with all required 
parameters through whole hierarchy tree. That way reflection cannot fail. It'd 
be smaller change, but as I said, getting rid of those constructors, we can 
probably get rid of all reflection (not in my patch) and probably also of 
special CDI treatment.

> 
> [1] https://gerrit.ovirt.org/#/c/52657/
> 
> On Tue, Jan 26, 2016 at 11:01 AM, Martin Mucha <mmu...@redhat.com> wrote:
> 
> > Hi,
> >
> > I got another bug about missing constructor:
> >
> > public …(P parameters, EngineContext engineContext) {
> > super(parameters, engineContext);
> > }
> >
> > so I looked into:
> > org.ovirt.engine.core.bll.QueriesCommandBase
> >
> > and it seems, that sole 'problem' is with initialization of user in
> > @PostConstruct method. It seems, that we can easily set all those fields
> > via setters, and user initialization can be done later, for example before
> > calling executeQueryCommand in:
> > org.ovirt.engine.core.bll.QueriesCommandBase#executeCommand
> >
> > doing this will move us closer to CDI and avoid errors because of
> > forgotten constructor. Is there a obstacle blocking us from doing this?
> >
> > thanks,
> > Mar.
> >
> > Edit: I had some time left so I tried to implement it, and it seems to be
> > working. It's big patch, but mostly there's just constructors removal.
> > Actual changes are in:
> >
> > QueriesCommandBase
> > CommandsFactory
> > RegisterVdsQuery
> > GetAllTemplateBasedEntityQuery
> > GetAllInstanceTypesQuery
> > GetAllVmTemplatesQuery
> > GetAllImageTypesQuery
> >
> > and test files.
> > ___
> > Devel mailing list
> > Devel@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
> 
> 
> 
> 
> --
> Regards,
> Moti
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [UI plugins] replacing RestApiSessionAcquired event

[Martin Mucha]

sorry, I made a mistake this is not a reply to this subject.
M.

- Original Message -
> Hi,
> 
> I got another bug about missing constructor:
> 
> public …(P parameters, EngineContext engineContext) {
> super(parameters, engineContext);
> }
> 
> so I looked into:
> org.ovirt.engine.core.bll.QueriesCommandBase
> 
> and it seems, that sole 'problem' is with initialization of user in
> @PostConstruct method. It seems, that we can easily set all those fields via
> setters, and user initialization can be done later, for example before
> calling executeQueryCommand in:
> org.ovirt.engine.core.bll.QueriesCommandBase#executeCommand
> 
> doing this will move us closer to CDI and avoid errors because of forgotten
> constructor. Is there a obstacle blocking us from doing this?
> 
> thanks,
> Mar.
> ___
> 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] [UI plugins] replacing RestApiSessionAcquired event

[Martin Mucha]

Hi,

I got another bug about missing constructor:

public …(P parameters, EngineContext engineContext) {
super(parameters, engineContext);
}

so I looked into: 
org.ovirt.engine.core.bll.QueriesCommandBase

and it seems, that sole 'problem' is with initialization of user in 
@PostConstruct method. It seems, that we can easily set all those fields via 
setters, and user initialization can be done later, for example before calling 
executeQueryCommand in:
org.ovirt.engine.core.bll.QueriesCommandBase#executeCommand

doing this will move us closer to CDI and avoid errors because of forgotten 
constructor. Is there a obstacle blocking us from doing this?

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

Re: [ovirt-devel] findbugs on network code

[Martin Mucha]

I think that's probable explanation. Another NPE can be (theoretically) here 
org.ovirt.engine.core.utils.customprop.DevicePropertiesUtils#getDeviceProperties
when reading using null version (static analysis can probably find way into 
this method), but cancel is more imminent.

M.

- Original Message -
> 
> > On Jan 15, 2016, at 9:21 AM, Michal Skrivanek 
> > wrote:
> > 
> > somehow findbugs started to fail[1] on network code
> > any idea why?
> 
> To me this looks like that might be because of the VnicProfileModel base
> class which accesses the sourceModel parameter without checking if it is
> null or not in the cancel method.
> 
> But that is just a hunch
> 
> > 
> > Thanks,
> > michal
> > 
> > [1]
> > http://jenkins.ovirt.org/job/ovirt-engine_master_find-bugs_gerrit/43304/findbugsResult/new/
> > ___
> > 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] unable to add host ~ InitVdsOnUpCommand parameters specifies storage domain ID when creating host.

[Martin Mucha]

Hi,

'm unable to add host to engine. I have fresh engine build, cleaned host, 
dropped and recreated DB. I'm adding host using rest¹.

Command InitVdsOnUpCommand is called during operation, having 
getStoragePoolId()
equal to
0001-0001-0001-0001-00c1.

However, there's no storage domain in system — it's empty installation, and I'm 
only creating host yet (so I cannot have any storage domain).
Because of that, following code:

StorageDomain masterDomain = 
getStorageDomainDao().getStorageDomains(storagePoolId, 
StorageDomainType.Master).get(0);

in method: 

org.ovirt.engine.core.bll.InitVdsOnUpCommand#runConnectHostToPoolEvent

produces NPE, which is probably cause of host marked as nonoperational.


———
If I'm doing something wrong, plese advice.
Martin.


[1]
curl -v -u "admin@internal:adminadmin" -H "Content-type: application/xml" -d "

$NAME
10.34.63.167
qum5net

$CLUSTERNAME



" -X POST http://localhost:8080/ovirt-engine/api/hosts
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Slides for the Java 8 presentation yesterday

[Martin Mucha]

Thanks Juan, I've read your slides and learn something new from them.

And I'd like to ask one small thing about how lambdas are represented. It seems 
that from early draft there were 'some changes' — from inner class 
representation, to runtime generated inner class representation, to no classes 
in the end. So if spec says, that [quote]:

The value of a lambda expression is a reference to an instance of a class with 
the following properties:
• The class implements the targeted functional interface type and, if the 
target type is an intersection type, every other interface type mentioned in 
the intersection.
…

and in current implementation class type of lambda is now it's enclosing class 
type, it means, that lambda is represented by instance of class its defined 
in(this instanceof  in lambda returns true). Then it seems 
that enclosing type has to implement functional interface to fulfill spec. 
Which seems wild, provided, that with two 'Runnable-representing' lambdas 
enclosing class has to implement Runnable twice, with two different 
implementations, which is usually impossible.

as you know more about this subject, can I ask you to confirm this statements / 
explain where I'm wrong and how it works internally / or explain what kind of 
sorcery is going on here?

thanks,
Mar.

- Original Message -
> Thanks Juan for the great presentation !!
> 
> On Wed, Dec 2, 2015 at 10:50 AM, Juan Hernández < jhern...@redhat.com >
> wrote:
> 
> 
> Hello all,
> 
> The slides for the Java 8 new features that I delivered yesterday are
> available here:
> 
> https://jhernand.fedorapeople.org/java8/slides.html
> 
> There is no recording, as hangout failed and I forgot to record the
> BlueJeans call, sorry.
> 
> Regards,
> Juan Hernandez
> --
> Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
> 3ºD, 28016 Madrid, Spain
> Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
> ___
> 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] Slides for the Java 8 presentation yesterday

[Martin Mucha]

thank you very much for explanation.
M.

- Original Message -
> On 12/02/2015 10:53 AM, Martin Mucha wrote:
> > Thanks Juan, I've read your slides and learn something new from them.
> > 
> > And I'd like to ask one small thing about how lambdas are represented. It
> > seems that from early draft there were 'some changes' — from inner class
> > representation, to runtime generated inner class representation, to no
> > classes in the end. So if spec says, that [quote]:
> > 
> > The value of a lambda expression is a reference to an instance of a class
> > with the following properties:
> > • The class implements the targeted functional interface type and, if the
> > target type is an intersection type, every other interface type mentioned
> > in the intersection.
> > …
> > 
> > and in current implementation class type of lambda is now it's enclosing
> > class type, it means, that lambda is represented by instance of class its
> > defined in(this instanceof  in lambda returns true). Then
> > it seems that enclosing type has to implement functional interface to
> > fulfill spec. Which seems wild, provided, that with two
> > 'Runnable-representing' lambdas enclosing class has to implement Runnable
> > twice, with two different implementations, which is usually impossible.
> > 
> > as you know more about this subject, can I ask you to confirm this
> > statements / explain where I'm wrong and how it works internally / or
> > explain what kind of sorcery is going on here?
> > 
> > thanks,
> > Mar.
> > 
> 
> I'm not an expert in the subject, but as far as I understand there are
> two mechanisms used to implement the lambda expressions. First is that
> the body of the lambda expression is implemented as a method within the
> class were it is used. For example, if you write a class like this:
> 
>   public class Test {
> public go() {
>   Runnable my = () -> System.out.println("Hello!");
>   my.run();
> }
>   }
> 
> The compiler will ad a new synthetic method to the class, named
> "lambda$main$0", containing the body of the expression:
> 
>   private static void labmda$main$0() {
> System.out.println("Hello!");
>   }
> 
> In this case the method is static, because the expression doesn't need
> to access members of the containing class, and it doesn't receive
> parameters because it doesn't use variables or parameters from its
> environment. If it used members it wouldn't have been static, and would
> have parameters, one for each local variable or parameter used. For
> example, if you change the class to this:
> 
>  public class Test {
>String member;
> 
>public void go(String parameter) {
>  String local = "local";
>  Runnable my = () -> {
>System.out.println(member);
>System.out.println(parameter);
>System.out.println(local);
>  };
>  my.run();
>}
> }
> 
> Then the generated method looks like this:
> 
>   private void labmda$main$0(String parameter, String local) {
> System.out.println(member);
> System.out.println(parameter);
> System.out.println(local);
>   }
> 
> Note that the method isn't now static, that is why it can access
> members, and why "this" doesn't mean the same that it means in anonymous
> inner classes. Note that this doesn't mean that the type of the
> expression is the enclosing class, just that "this" has a different meaning.
> 
> The second mechanism is the "invokedynamic" instruction, introduced in
> Java 7. This is used to instantiate the the object that wraps the
> expression. In the above example, the following line:
> 
>   Runnable my = () -> { ... }
> 
> Is translated by the compiler in a "invokedynamic" instruction like this:
> 
>   invokedynamic #3, 0 // InvokeDynamic
> #0:run:(LTest;Ljava/lang/String;Ljava/lang/String;)Ljava/lang/Runnable;
> 
> I won't go into the details here (and I don't know them very well
> either), but more or less this is telling the Java virtual machine that
> during run time, the first time that this instruction is executed, it
> should use the lambda expressions bootstrap method to find (maybe
> create, "linking" is the term) an object that implements the "Runnable"
> interface such that the "run" method class the "lambda$run$0" method. I
> guess that these classes are generated with a mechanism similar to
> java.lang.reflect.Proxy, but not exactly the same.
> 
> > - Original Message -
> >> Thanks Juan for the great presenta

Re: [ovirt-devel] Requiring Java 8 during runtime

[Martin Mucha]

not strictly related question: are we going to raise language level as well? So 
we can start using JDK8 features like lambdas etc?

M.

- Original Message -
> Hello,
> 
> As you probably know oVirt Engine 4 will use WildFly 10, and that
> requires Java 8. The version of WildFly that we currently use is 8.2.1,
> and it can work with both Java 7 and Java 8. In order to ease the
> transition I'm about to merge the following patch, that will require
> Java 8 during runtime:
> 
>   core: Require Java 8 during runtime
>   https://gerrit.ovirt.org/46872
> 
> The implication of this for you is that you must make sure that you have
> Java 8 installed in the machine where you run your the engine. Fedora 22
> only supports Java 8, so that isn't a problem. EL6 supports both Java 7
> and Java 8, so make sure that you have Java 8 installed:
> 
>   yum -y install java-1.8.0-openjdk-devel
> 
> If you have objections please speak now, otherwise I will merge the
> patch tomorrow.
> 
> Regards,
> Juan Hernandez
> 
> --
> Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
> 3ºD, 28016 Madrid, Spain
> Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
> ___
> 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] disabling maven-checkstyle-plugin

[Martin Mucha]

Hi,

I want to get rid of work style: wait 10 minutes for compilation to finish, 
read about unused import, fix it and start over. 

I'm not that familiar with maven / our setup. Is there a correct way how to do 
that? 

So far what I do is using altered pom.xml so there's new profile disabling 
maven-check-style if enabled, and I had to force git to ignore pom.xml changes. 
This does not seem right.

Also is there a way how to continue with build from point where it failed, or 
do I truly need to restart from scratch?

thanks for advices,
M.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [oVirt 3.6 Localization Question #29] Return VM

[Martin Mucha]

not familiar with this part of system, but from looking quickly into source 
code:

there's should be some 'side tab' in VM view in userportal, in which you can 
'shutdown' it by clicking it. And If you hover your mouse over that button, 
there should be your text in tooltip.

hope I'm right and it'll help,
M.

- Original Message -
 Hello all,
 
 Could you please help us with the following question?
 
 File: ApplicationConstants
 Resource ID: returnVmLabel
 String: Return VM
 Question: Could anyone tell me where in the UI this string is used? Is it for
 returning VM to VM pool or returning to a snapshot or returning from a
 preview (ie restore to a certain point)?
 
 Kind regards,
 
 Yuko
 
 
 
 ___
 Devel mailing list
 Devel@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [oVirt 3.6 Localization Question #30] Load

[Martin Mucha]

from source code:

loadVmsFromExportDomainButton.setLabel(constants.loadLabel());

so it's verb, and it's used on button invoking loading vms from export domain.

M.

- Original Message -
 Hello all,
 
 Another question is raised:
 
 File: CommonApplicationConstants
 Resource ID: loadLabel
 String: Load
 Question: Is it a verb or noun? Where in the UI this is used?
 
 Kind regards,
 
 Yuko
 
 ___
 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] Error: VDSGenericException: VDSNetworkException: Policy reset

[Martin Mucha]

Hi,

I keep seeing in engine.log (no another error anywhere else) this error. Does 
anyone knows what's wrong? Sometimes it takes days before it happens, sometimes 
if fails very frequently.


2015-07-03 09:12:40,056 ERROR 
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default 
task-10) [2428859b] Correlation ID: null, Call Stack: null, Custom Event ID: 
-1, Message: VDSM 'dev07' command failed: Policy reset
2015-07-03 09:12:40,056 ERROR 
[org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand] (default task-10) 
[2428859b] Error: VDSGenericException: VDSNetworkException: Policy reset
2015-07-03 09:12:40,056 ERROR 
[org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand] (default task-10) 
[2428859b] Exception: 
org.ovirt.engine.core.vdsbroker.vdsbroker.VDSNetworkException: 
VDSGenericException: VDSNetworkException: Policy reset
at 
org.ovirt.engine.core.vdsbroker.vdsbroker.BrokerCommandBase.proceedProxyReturnValue(BrokerCommandBase.java:188)
 [vdsbroker.jar:]
at 
org.ovirt.engine.core.vdsbroker.vdsbroker.FutureVDSCommand.get(FutureVDSCommand.java:73)
 [vdsbroker.jar:]
at 
org.ovirt.engine.core.bll.network.host.HostSetupNetworkPoller.poll(HostSetupNetworkPoller.java:30)
 [bll.jar:]
at 
org.ovirt.engine.core.bll.network.host.HostSetupNetworksCommand.invokeSetupNetworksCommand(HostSetupNetworksCommand.java:253)
 [bll.jar:]
at 
org.ovirt.engine.core.bll.network.host.HostSetupNetworksCommand.executeCommand(HostSetupNetworksCommand.java:171)
 [bll.jar:]
at 
org.ovirt.engine.core.bll.CommandBase.executeWithoutTransaction(CommandBase.java:1212)
 [bll.jar:]
at 
org.ovirt.engine.core.bll.CommandBase.executeActionInTransactionScope(CommandBase.java:1356)
 [bll.jar:]
at 
org.ovirt.engine.core.bll.CommandBase.runInTransaction(CommandBase.java:1979) 
[bll.jar:]
at 
org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInSuppressed(TransactionSupport.java:174)
 [utils.jar:]
at 
org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInScope(TransactionSupport.java:116)
 [utils.jar:]
at org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1392) 
[bll.jar:]
at 
org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:375) 
[bll.jar:]
at org.ovirt.engine.core.bll.Backend.runAction(Backend.java:459) 
[bll.jar:]
at org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:441) 
[bll.jar:]
at org.ovirt.engine.core.bll.Backend.runAction(Backend.java:397) 
[bll.jar:]
…
…

2015-07-03 09:12:40,106 ERROR 
[org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand] (default task-10) 
[2428859b] Command 'PollVDSCommand(HostName = dev07, 
VdsIdVDSCommandParametersBase:{runAsync='true', 
hostId='72456bb8-4afb-4104-b86e-ab692b4a6f2e'})' execution failed: 
VDSGenericException: VDSNetworkException: Policy reset



thanks,

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

Re: [ovirt-devel] Error: VDSGenericException: VDSNetworkException: Policy reset

[Martin Mucha]

thanks for explanation,

M.

- Original Message -
 Martin,
 
 This is policy reset when we perform setupNetworks. This is expected
 behavior but the stacktrace is confusing and we have a BZ [1] to
 improve it.
 
 The reason for it is that engine makes sure to keep connection alive
 at all times by using heartbeats. When we are about to configure
 network
 we know that there will be connectivity issue so before performing the
 operation we change heartbeat policy to ignore missing heartbeats.
 This operation enforces to reconnect using different policy and we see
 this nice stacktrace in the log.
 
 Thanks,
 Piotr
 
 
 [1] https://bugzilla.redhat.com/1235683
 
 On Fri, Jul 3, 2015 at 9:17 AM, Martin Mucha mmu...@redhat.com wrote:
  Hi,
 
  I keep seeing in engine.log (no another error anywhere else) this error.
  Does anyone knows what's wrong? Sometimes it takes days before it happens,
  sometimes if fails very frequently.
 
 
  2015-07-03 09:12:40,056 ERROR
  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
  (default task-10) [2428859b] Correlation ID: null, Call Stack: null,
  Custom Event ID: -1, Message: VDSM 'dev07' command failed: Policy reset
  2015-07-03 09:12:40,056 ERROR
  [org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand] (default
  task-10) [2428859b] Error: VDSGenericException: VDSNetworkException:
  Policy reset
  2015-07-03 09:12:40,056 ERROR
  [org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand] (default
  task-10) [2428859b] Exception:
  org.ovirt.engine.core.vdsbroker.vdsbroker.VDSNetworkException:
  VDSGenericException: VDSNetworkException: Policy reset
  at
  
  org.ovirt.engine.core.vdsbroker.vdsbroker.BrokerCommandBase.proceedProxyReturnValue(BrokerCommandBase.java:188)
  [vdsbroker.jar:]
  at
  
  org.ovirt.engine.core.vdsbroker.vdsbroker.FutureVDSCommand.get(FutureVDSCommand.java:73)
  [vdsbroker.jar:]
  at
  
  org.ovirt.engine.core.bll.network.host.HostSetupNetworkPoller.poll(HostSetupNetworkPoller.java:30)
  [bll.jar:]
  at
  
  org.ovirt.engine.core.bll.network.host.HostSetupNetworksCommand.invokeSetupNetworksCommand(HostSetupNetworksCommand.java:253)
  [bll.jar:]
  at
  
  org.ovirt.engine.core.bll.network.host.HostSetupNetworksCommand.executeCommand(HostSetupNetworksCommand.java:171)
  [bll.jar:]
  at
  
  org.ovirt.engine.core.bll.CommandBase.executeWithoutTransaction(CommandBase.java:1212)
  [bll.jar:]
  at
  
  org.ovirt.engine.core.bll.CommandBase.executeActionInTransactionScope(CommandBase.java:1356)
  [bll.jar:]
  at
  
  org.ovirt.engine.core.bll.CommandBase.runInTransaction(CommandBase.java:1979)
  [bll.jar:]
  at
  
  org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInSuppressed(TransactionSupport.java:174)
  [utils.jar:]
  at
  
  org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInScope(TransactionSupport.java:116)
  [utils.jar:]
  at
  org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1392)
  [bll.jar:]
  at
  
  org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:375)
  [bll.jar:]
  at org.ovirt.engine.core.bll.Backend.runAction(Backend.java:459)
  [bll.jar:]
  at
  org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:441)
  [bll.jar:]
  at org.ovirt.engine.core.bll.Backend.runAction(Backend.java:397)
  [bll.jar:]
  …
  …
 
  2015-07-03 09:12:40,106 ERROR
  [org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand] (default
  task-10) [2428859b] Command 'PollVDSCommand(HostName = dev07,
  VdsIdVDSCommandParametersBase:{runAsync='true',
  hostId='72456bb8-4afb-4104-b86e-ab692b4a6f2e'})' execution failed:
  VDSGenericException: VDSNetworkException: Policy reset
 
 
 
  thanks,
 
  mar.
  ___
  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] Upgrade to wildfly problem

[Martin Mucha]

Thanks very much, for review. 

I mistakenly used BootProtocol enum instead of NetworkBootProtocol enum, and 
relied on ordinal values of former instead on 'intValue's of latter.

updated.

M.

- Original Message -
 On 06/30/2015 08:25 AM, Martin Mucha wrote:
  Hi,
 
  this is caused by new HostNetworkingAPI resp one its db upgrade script, not
  by wildfly. I wrote 'fix' script yesterday, which should fix this. However
  this patch did not get CR yet, and cannot be merged. But you can use it to
  cure your environment manually. If you do, please let me know if
  everything went ok.
 
  https://gerrit.ovirt.org/#/c/42977/
 I reviewed the patch, it needs an update
  M.
 
  - Original Message -
  Hi,
 
  I followed the upgrade to wildfly steps here [1]. And everything worked as
  expected. I was able to compile/run/update database without issues.
  However
  now when I start the engine, everything appears to work but I am getting
  the
  following stack trace over and over and over again in my engine log.
 
  2015-06-29 11:47:44,240 WARN  [org.ovirt.engine.core.vdsbroker.VdsManager]
  (DefaultQuartzScheduler_Worker-39) [] Failed to refresh VDS , vds =
  'host1' :
  '932f05b4-e3b0-4e9a-ab99-77ff749138b3', error = 'No enum constant
  org.ovirt.engine.core.common.businessentities.network.NetworkBootProtocol.1',
  continuing.
  2015-06-29 11:47:44,241 ERROR [org.ovirt.engine.core.vdsbroker.VdsManager]
  (DefaultQuartzScheduler_Worker-39) [] Exception:
  java.lang.IllegalArgumentException: No enum constant
  org.ovirt.engine.core.common.businessentities.network.NetworkBootProtocol.1
   at java.lang.Enum.valueOf(Enum.java:236) [rt.jar:1.7.0_79]
   at
  org.ovirt.engine.core.common.businessentities.network.NetworkBootProtocol.valueOf(NetworkBootProtocol.java:6)
  [common.jar:]
   at
  org.ovirt.engine.core.dao.network.NetworkAttachmentDaoDbFacadeImpl$NetworkAttachmentRowMapper.mapRow(NetworkAttachmentDaoDbFacadeImpl.java:96)
  [dal.jar:]
   at
  org.ovirt.engine.core.dao.network.NetworkAttachmentDaoDbFacadeImpl$NetworkAttachmentRowMapper.mapRow(NetworkAttachmentDaoDbFacadeImpl.java:79)
  [dal.jar:]
   at
  org.springframework.jdbc.core.RowMapperResultSetExtractor.extractData(RowMapperResultSetExtractor.java:92)
  [spring-jdbc.jar:3.1.1.RELEASE]
   at
  org.springframework.jdbc.core.RowMapperResultSetExtractor.extractData(RowMapperResultSetExtractor.java:1)
  [spring-jdbc.jar:3.1.1.RELEASE]
   at
  org.springframework.jdbc.core.JdbcTemplate$1.doInPreparedStatement(JdbcTemplate.java:649)
  [spring-jdbc.jar:3.1.1.RELEASE]
   at
  org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:587)
  [spring-jdbc.jar:3.1.1.RELEASE]
   at
  org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:637)
  [spring-jdbc.jar:3.1.1.RELEASE]
   at
  org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:666)
  [spring-jdbc.jar:3.1.1.RELEASE]
   at
  org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:706)
  [spring-jdbc.jar:3.1.1.RELEASE]
   at
  org.ovirt.engine.core.dal.dbbroker.PostgresDbEngineDialect$PostgresSimpleJdbcCall.executeCallInternal(PostgresDbEngineDialect.java:154)
  [dal.jar:]
   at
  org.ovirt.engine.core.dal.dbbroker.PostgresDbEngineDialect$PostgresSimpleJdbcCall.doExecute(PostgresDbEngineDialect.java:120)
  [dal.jar:]
   at
  org.springframework.jdbc.core.simple.SimpleJdbcCall.execute(SimpleJdbcCall.java:181)
  [spring-jdbc.jar:3.1.1.RELEASE]
   at
  org.ovirt.engine.core.dal.dbbroker.SimpleJdbcCallsHandler.executeImpl(SimpleJdbcCallsHandler.java:147)
  [dal.jar:]
   at
  org.ovirt.engine.core.dal.dbbroker.SimpleJdbcCallsHandler.executeReadList(SimpleJdbcCallsHandler.java:109)
  [dal.jar:]
   at
  org.ovirt.engine.core.dao.network.NetworkAttachmentDaoDbFacadeImpl.getAllForHost(NetworkAttachmentDaoDbFacadeImpl.java:40)
  [dal.jar:]
   at
  org.ovirt.engine.core.vdsbroker.vdsbroker.HostNetworkAttachmentsPersister.persistNetworkAttachments(HostNetworkAttachmentsPersister.java:69)
  [vdsbroker.jar:]
   at
  org.ovirt.engine.core.vdsbroker.vdsbroker.HostNetworkTopologyPersisterImpl.persistTopology(HostNetworkTopologyPersisterImpl.java:280)
  [vdsbroker.jar:]
   at
  org.ovirt.engine.core.vdsbroker.vdsbroker.HostNetworkTopologyPersisterImpl.persistAndEnforceNetworkCompliance(HostNetworkTopologyPersisterImpl.java:85)
  [vdsbroker.jar:]
   at
  org.ovirt.engine.core.vdsbroker.vdsbroker.HostNetworkTopologyPersisterImpl.persistAndEnforceNetworkCompliance(HostNetworkTopologyPersisterImpl.java:141)
  [vdsbroker.jar:]
   at
  org.ovirt.engine.core.vdsbroker.VdsManager.refreshCapabilities(VdsManager.java:666)
  [vdsbroker.jar:]
   at
  org.ovirt.engine.core.vdsbroker.HostMonitoring.beforeFirstRefreshTreatment(HostMonitoring.java:706)
  [vdsbroker.jar

Re: [ovirt-devel] Upgrade to wildfly problem

[Martin Mucha]

Hi,

this is caused by new HostNetworkingAPI resp one its db upgrade script, not by 
wildfly. I wrote 'fix' script yesterday, which should fix this. However this 
patch did not get CR yet, and cannot be merged. But you can use it to cure your 
environment manually. If you do, please let me know if everything went ok.

https://gerrit.ovirt.org/#/c/42977/

M.

- Original Message -
 Hi,
 
 I followed the upgrade to wildfly steps here [1]. And everything worked as
 expected. I was able to compile/run/update database without issues. However
 now when I start the engine, everything appears to work but I am getting the
 following stack trace over and over and over again in my engine log.
 
 2015-06-29 11:47:44,240 WARN  [org.ovirt.engine.core.vdsbroker.VdsManager]
 (DefaultQuartzScheduler_Worker-39) [] Failed to refresh VDS , vds = 'host1' :
 '932f05b4-e3b0-4e9a-ab99-77ff749138b3', error = 'No enum constant
 org.ovirt.engine.core.common.businessentities.network.NetworkBootProtocol.1',
 continuing.
 2015-06-29 11:47:44,241 ERROR [org.ovirt.engine.core.vdsbroker.VdsManager]
 (DefaultQuartzScheduler_Worker-39) [] Exception:
 java.lang.IllegalArgumentException: No enum constant
 org.ovirt.engine.core.common.businessentities.network.NetworkBootProtocol.1
 at java.lang.Enum.valueOf(Enum.java:236) [rt.jar:1.7.0_79]
 at
 org.ovirt.engine.core.common.businessentities.network.NetworkBootProtocol.valueOf(NetworkBootProtocol.java:6)
 [common.jar:]
 at
 org.ovirt.engine.core.dao.network.NetworkAttachmentDaoDbFacadeImpl$NetworkAttachmentRowMapper.mapRow(NetworkAttachmentDaoDbFacadeImpl.java:96)
 [dal.jar:]
 at
 org.ovirt.engine.core.dao.network.NetworkAttachmentDaoDbFacadeImpl$NetworkAttachmentRowMapper.mapRow(NetworkAttachmentDaoDbFacadeImpl.java:79)
 [dal.jar:]
 at
 org.springframework.jdbc.core.RowMapperResultSetExtractor.extractData(RowMapperResultSetExtractor.java:92)
 [spring-jdbc.jar:3.1.1.RELEASE]
 at
 org.springframework.jdbc.core.RowMapperResultSetExtractor.extractData(RowMapperResultSetExtractor.java:1)
 [spring-jdbc.jar:3.1.1.RELEASE]
 at
 org.springframework.jdbc.core.JdbcTemplate$1.doInPreparedStatement(JdbcTemplate.java:649)
 [spring-jdbc.jar:3.1.1.RELEASE]
 at
 org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:587)
 [spring-jdbc.jar:3.1.1.RELEASE]
 at
 org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:637)
 [spring-jdbc.jar:3.1.1.RELEASE]
 at
 org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:666)
 [spring-jdbc.jar:3.1.1.RELEASE]
 at
 org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:706)
 [spring-jdbc.jar:3.1.1.RELEASE]
 at
 org.ovirt.engine.core.dal.dbbroker.PostgresDbEngineDialect$PostgresSimpleJdbcCall.executeCallInternal(PostgresDbEngineDialect.java:154)
 [dal.jar:]
 at
 org.ovirt.engine.core.dal.dbbroker.PostgresDbEngineDialect$PostgresSimpleJdbcCall.doExecute(PostgresDbEngineDialect.java:120)
 [dal.jar:]
 at
 org.springframework.jdbc.core.simple.SimpleJdbcCall.execute(SimpleJdbcCall.java:181)
 [spring-jdbc.jar:3.1.1.RELEASE]
 at
 org.ovirt.engine.core.dal.dbbroker.SimpleJdbcCallsHandler.executeImpl(SimpleJdbcCallsHandler.java:147)
 [dal.jar:]
 at
 org.ovirt.engine.core.dal.dbbroker.SimpleJdbcCallsHandler.executeReadList(SimpleJdbcCallsHandler.java:109)
 [dal.jar:]
 at
 org.ovirt.engine.core.dao.network.NetworkAttachmentDaoDbFacadeImpl.getAllForHost(NetworkAttachmentDaoDbFacadeImpl.java:40)
 [dal.jar:]
 at
 org.ovirt.engine.core.vdsbroker.vdsbroker.HostNetworkAttachmentsPersister.persistNetworkAttachments(HostNetworkAttachmentsPersister.java:69)
 [vdsbroker.jar:]
 at
 org.ovirt.engine.core.vdsbroker.vdsbroker.HostNetworkTopologyPersisterImpl.persistTopology(HostNetworkTopologyPersisterImpl.java:280)
 [vdsbroker.jar:]
 at
 org.ovirt.engine.core.vdsbroker.vdsbroker.HostNetworkTopologyPersisterImpl.persistAndEnforceNetworkCompliance(HostNetworkTopologyPersisterImpl.java:85)
 [vdsbroker.jar:]
 at
 org.ovirt.engine.core.vdsbroker.vdsbroker.HostNetworkTopologyPersisterImpl.persistAndEnforceNetworkCompliance(HostNetworkTopologyPersisterImpl.java:141)
 [vdsbroker.jar:]
 at
 org.ovirt.engine.core.vdsbroker.VdsManager.refreshCapabilities(VdsManager.java:666)
 [vdsbroker.jar:]
 at
 org.ovirt.engine.core.vdsbroker.HostMonitoring.beforeFirstRefreshTreatment(HostMonitoring.java:706)
 [vdsbroker.jar:]
 at
 org.ovirt.engine.core.vdsbroker.HostMonitoring.refreshVdsRunTimeInfo(HostMonitoring.java:128)
 [vdsbroker.jar:]
 at
 org.ovirt.engine.core.vdsbroker.HostMonitoring.refresh(HostMonitoring.java:84)
 [vdsbroker.jar:]
 at
 org.ovirt.engine.core.vdsbroker.VdsManager.onTimer(VdsManager.java:215)
 [vdsbroker.jar:]
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 [rt.jar:1.7.0_79]
 at
 

[ovirt-devel] cannot install host: VdsDeployBase, Error during deploy dialog: java.lang.NullPointerException

[Martin Mucha]

Hi,

I have difficulties to install host. I do believe it fails due to this:

2015-06-24 08:29:26,729 ERROR 
[org.ovirt.engine.core.bll.hostdeploy.VdsDeployBase] (VdsDeploy) [612066b7] 
Error during deploy dialog: java.lang.NullPointerException
at 
org.ovirt.otopi.dialog.MachineDialogParser.cliEnvironmentGet(MachineDialogParser.java:236)
 [otopi.jar:]
at 
org.ovirt.engine.core.bll.hostdeploy.VdsDeploy$43.call(VdsDeploy.java:579) 
[bll.jar:]
at 
org.ovirt.engine.core.bll.hostdeploy.VdsDeploy$43.call(VdsDeploy.java:577) 
[bll.jar:]
at 
org.ovirt.engine.core.bll.hostdeploy.VdsDeployBase._nextCustomizationEntry(VdsDeployBase.java:202)
 [bll.jar:]
at 
org.ovirt.engine.core.bll.hostdeploy.VdsDeployBase._threadMain(VdsDeployBase.java:301)
 [bll.jar:]
at 
org.ovirt.engine.core.bll.hostdeploy.VdsDeployBase.access$200(VdsDeployBase.java:45)
 [bll.jar:]
at 
org.ovirt.engine.core.bll.hostdeploy.VdsDeployBase$7.run(VdsDeployBase.java:392)
 [bll.jar:]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_79]

anyone met this? Know how to overcome this? Any hints welcomed.
(alredy tried to remove library from m2 repo to force re-download)

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

Re: [ovirt-devel] cannot install host: VdsDeployBase, Error during deploy dialog: java.lang.NullPointerException

[Martin Mucha]

update: 
library updated, engine rebuild from sources, engine-setup called, engine 
started again.  Still not able to install host.

any hint appreciated.

M.

- Original Message -
 A similar issue was already reported in this mailing list.
 You should just upgrade the ovirt-host-deploy to ovirt-host-deploy-1.4.0-0.0.
 
 Oved
 
 - Original Message -
  From: Martin Mucha mmu...@redhat.com
  To: devel@ovirt.org
  Sent: Wednesday, June 24, 2015 9:34:50 AM
  Subject: [ovirt-devel] cannot install host: VdsDeployBase, Error during
  deploy dialog: java.lang.NullPointerException
  
  Hi,
  
  I have difficulties to install host. I do believe it fails due to this:
  
  2015-06-24 08:29:26,729 ERROR
  [org.ovirt.engine.core.bll.hostdeploy.VdsDeployBase] (VdsDeploy) [612066b7]
  Error during deploy dialog: java.lang.NullPointerException
  at
  
  org.ovirt.otopi.dialog.MachineDialogParser.cliEnvironmentGet(MachineDialogParser.java:236)
  [otopi.jar:]
  at
  
  org.ovirt.engine.core.bll.hostdeploy.VdsDeploy$43.call(VdsDeploy.java:579)
  [bll.jar:]
  at
  
  org.ovirt.engine.core.bll.hostdeploy.VdsDeploy$43.call(VdsDeploy.java:577)
  [bll.jar:]
  at
  
  org.ovirt.engine.core.bll.hostdeploy.VdsDeployBase._nextCustomizationEntry(VdsDeployBase.java:202)
  [bll.jar:]
  at
  
  org.ovirt.engine.core.bll.hostdeploy.VdsDeployBase._threadMain(VdsDeployBase.java:301)
  [bll.jar:]
  at
  
  org.ovirt.engine.core.bll.hostdeploy.VdsDeployBase.access$200(VdsDeployBase.java:45)
  [bll.jar:]
  at
  
  org.ovirt.engine.core.bll.hostdeploy.VdsDeployBase$7.run(VdsDeployBase.java:392)
  [bll.jar:]
  at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_79]
  
  anyone met this? Know how to overcome this? Any hints welcomed.
  (alredy tried to remove library from m2 repo to force re-download)
  
  M.
  ___
  Devel mailing list
  Devel@ovirt.org
  http://lists.ovirt.org/mailman/listinfo/devel
  
 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [oVirt 3.6 Localization Question #20] Add new Label to

[Martin Mucha]

Hi,

Following in UIConstants.java:
@DefaultStringValue(Add new Label to)
String newLabel();

and

@DefaultMessage(Add Label {0} to)
String label(String label);

are both related to SetupHostNetworks dialog, where there's improved 
interface to label NICs. In upper right right corner click combobox labels, and 
you'll be able to drag existing/new label onto selected nic. Given message 
should be presented in top left corner of dialog. One message is for new label 
(not having name yet) and another one is for attaching already existing label.

Martin.



- Original Message -
 I also found a similar string Add Label {0} to in UIMessages file.
 Could anyone explain how/where this appears in the GUI as well?
 
 Kind regards,
 
 Yuko
 
 On 06/23/2015 09:05 AM, Yuko Katabami wrote:
 
 
 Hi,
 
 I would like to ask you another question.
 
 File: UIConstants
 Resource ID: newLabel
 String: Add new Label to
 Question: Could anyone tell me how / where this string appears in the GUI? In
 Japanese translation, order of the words is different from English, and I
 would like to make sure it works when it is shown on the screen.
 
 Kind regards,
 
 Yuko
 
 
 ___
 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] Java 1.8 (was: ovirt-engine replies with 503 Service Temporarily Unavailable on fresh install)

[Martin Mucha]

if I'm not wrong, this is not strictly java 8 issue. There are also java 7 
versions behaving like this (jboss did not start on fresh install, peaking cpu 
usage)

m.

- Original Message -
 - Original Message -
  From: knarra kna...@redhat.com
  To: devel@ovirt.org
  Cc: Stanislav Graf sg...@redhat.com
  Sent: Tuesday, May 5, 2015 8:50:38 AM
  Subject: [ovirt-devel] ovirt-engine replies with 503 Service Temporarily
  Unavailable on fresh install
  
  
  Hi,
  
  From last Tuesday (Apr-28), I'm experiencing
  ovirt-engine replies with 503 Service Temporarily Unavailable on fresh
  install https://bugzilla.redhat.com/show_bug.cgi?id=1217023 I tried to
  completely reinstall before filing BZ and the issue was reproducible. I
  also
  updated today my install with latest, still the same.
  
  Am I alone who is hit by this BZ? Anything I could try? Should I reinstall
  again tomorrow?
 
 The mentioned bug does not seem very relevant.
 
 After checking with Kasturi, it seems that he is trying to run it with
 java-1.8.0-openjdk on RHEL6.6.
 
 For now, unless you care about this, just remove and install 1.7.
 
 Until the situation with 1.8 stabilizes, we might want to do something, not
 sure exactly what - perhaps change the script java-home to not accept 1.8
 for now (and people that want to test that will have to override by having
 there
 a trivial java-home.local pointing at their 1.8 home), or make engine-setup
 notice and prompt, whatever.
 --
 Didi
 ___
 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] WARNING: trying to localize null, probable error. Exception is not thrown, returning 'N/A'

[Martin Mucha]

No, that warning was created by me, when altering EnumTranslator to remove few 
problems of it.

we 'can' just remove the warning, but I do think that trying to localize null 
key is just wrong since we're not able to differentiate misuse, lets say when 
providing key from variable, and proper localization of null value. Thus, can 
somebody explain, why it's valid to trying localize null valued enum type? If 
there's need to localize null key, I'd rather opt for having special method for 
that to explicitly show programmers intention. But for me it seems as a call 
for new properly named enum value.

sorry about any complications with this.

M.

- Original Message -
 That's correct.
 
 I think we can just remove the warning. Returning N/A seems like a
 fine behavior to me.
 
 Greg
 
 - Original Message -
  From: Frantisek Kobzik fkob...@redhat.com
  To: Greg Sheremeta gsher...@redhat.com
  Cc: devel@ovirt.org
  Sent: Friday, February 20, 2015 10:33:43 AM
  Subject: Re: [ovirt-devel] WARNING: trying to localize null, probable
  error. Exception is not thrown, returning 'N/A'
  
  Yeah,
  
  I think I was the last who touched that code. IIRC null is passed when a VM
  doesn't have active graphics (e.g. Down state). I'll take a closer look.
  
  Cheers,
  F.
  
  - Original Message -
  From: Greg Sheremeta gsher...@redhat.com
  To: devel@ovirt.org
  Sent: Friday, February 20, 2015 2:31:43 AM
  Subject: [ovirt-devel] WARNING: trying to localize null, probable error.
  Exception is not thrown, returning 'N/A'
  
  This warning message of $subject is spamming Firebug / Dev tools consoles
  on
  latest master.
  
  VM tab  Display column is at least one source of it.
  
  EnumTranslator is getting nulls passed to translate(). I'm not sure why
  it's
  logging about it
  all of a sudden.
  
  Anyone recognize this?
  
  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
 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] reporting and removing unmanaged networks after deprecating org.ovirt.engine.core.common.action.VdcActionType#SetupNetworks

[Martin Mucha]

Hi,

I'd like to discuss how to properly report unmanaged networks and how to ask 
for their removal after 
org.ovirt.engine.core.common.action.VdcActionType#SetupNetworks
is removed.

We thought about several possibilities and so far the best one is following 
one. 

Reporting unmanaged networks on specific nic: 
———

We'd like to return new collection under:
GET http://localhost:8080/api/hosts/{id}/nics/{id}/unmanagednetworks

returning (reporting) unmanaged networks like this:

unmanaged_networks
unmanaged_network
nic_name.../nic_name
unmanaged_network_name.../unmanaged_network_name
vland_id.../vland_id
/unmanaged_network

unmanaged_network
 ...
/unmanaged_network
/unmanaged_networks


Removing unmanagedNetworks:
—

DELETE 
http://localhost:8080/api/hosts/{id}/nics/{id}/unmanagednetworks/{unmanaged_network_name}


===

any ideas, hints, complaints, recommendations, confirmations are welcomed.
Martin.

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

[ovirt-devel] missing 'translations' in 'bundles/AuditLogMessages'

[Martin Mucha]

Hi, 

I've did some changes in AuditLogDirector.java, triggered by wrong behavior, 
when some key (AuditLogType) is not present in ResourceBundle 
'bundles/AuditLogMessages', and wrote test to alert about missing translations. 
To be able to merge these changes, I need to supply already missing 
translations. For all following AuditLogType enums, silently nothing was saved 
to db when 
org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector#log(org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogableBase)
 was called.

Can somebody provide me missing translations for those keys?

Also test considers only default locale, should it test 'all existing' 
ResourceBundles or is testing default one just sufficient? (technically there's 
no difference at this time, since there's only default translation, but if 
someone will provide new ResourceBundle currently it will be used but not 
tested)

---

Key 'UNASSIGNED' is not translated in 'bundles/AuditLogMessages'
Key 'VDS_AUTO_FENCE_STATUS' is not translated in 'bundles/AuditLogMessages'
Key 'VDS_AUTO_FENCE_STATUS_FAILED' is not translated in 
'bundles/AuditLogMessages'
Key 'VDS_AUTO_FENCE_FAILED_CALL_FENCE_SPM' is not translated in 
'bundles/AuditLogMessages'
Key 'VDS_HIGH_NETWORK_USE' is not translated in 'bundles/AuditLogMessages'
Key 'USER_FAILED_REMOVE_VM' is not translated in 'bundles/AuditLogMessages'
Key 'USER_RUN_UNLOCK_ENTITY_SCRIPT' is not translated in 
'bundles/AuditLogMessages'
Key 'VDS_NETWORK_MTU_DIFFER_FROM_LOGICAL_NETWORK' is not translated in 
'bundles/AuditLogMessages'
Key 'VDS_HOST_IN_CONNECTING_STATE' is not translated in 
'bundles/AuditLogMessages'
Key 'STORAGE_ACTIVATE_ASYNC' is not translated in 'bundles/AuditLogMessages'
Key 'DWH_STOPPED' is not translated in 'bundles/AuditLogMessages'
Key 'DWH_STARTED' is not translated in 'bundles/AuditLogMessages'
Key 'DWH_ERROR' is not translated in 'bundles/AuditLogMessages'
Key 'USER_REMOVE_AUDIT_LOG' is not translated in 'bundles/AuditLogMessages'
Key 'USER_REMOVE_AUDIT_LOG_FAILED' is not translated in 
'bundles/AuditLogMessages'
Key 'USER_CLEAR_ALL_DISMISSED_AUDIT_LOG' is not translated in 
'bundles/AuditLogMessages'
Key 'USER_CLEAR_ALL_DISMISSED_AUDIT_LOG_FAILED' is not translated in 
'bundles/AuditLogMessages'

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

Re: [ovirt-devel] Failed to execute stage 'Setup validation': Trying to upgrade from unsupported versions: 3.5

[Martin Mucha]

thanks Didi, I'll rebase mine work on top of that. I wasn't aware that this was 
already fixed.

Mar.

- Original Message -
From: Yedidyah Bar David d...@redhat.com
To: Yair Zaslavsky yzasl...@redhat.com
Cc: Martin Mucha mmu...@redhat.com, de...@linode01.ovirt.org
Sent: Sunday, June 8, 2014 8:25:05 AM
Subject: Re: [ovirt-devel] Failed to execute stage 'Setup validation': Trying 
to upgrade from unsupported versions: 3.5

Should have been solved by http://gerrit.ovirt.org/28157 (since ~10 days ago).
Is your git repo up-to-date?
-- 
Didi

- Original Message -
 From: Yair Zaslavsky yzasl...@redhat.com
 To: Martin Mucha mmu...@redhat.com
 Cc: de...@linode01.ovirt.org
 Sent: Friday, June 6, 2014 5:53:08 PM
 Subject: Re: [ovirt-devel] Failed to execute stage 'Setup validation': Trying 
 to upgrade from unsupported versions:
 3.5
 
 Hi Martin,
 I have encountered the issue in the past as well.
 From what I remember, looks like your db scripts and the setup are not in
 sync.
 Can you please elaborate on how you performed the build with devenv, and if
 you built on master or any other local branch you derived from master?
 
 
 - Original Message -
  From: Martin Mucha mmu...@redhat.com
  To: de...@linode01.ovirt.org
  Sent: Friday, June 6, 2014 11:00:25 AM
  Subject: [ovirt-devel] Failed to execute stage 'Setup validation': Trying
  to upgrade from unsupported versions: 3.5
  
  Hi,
  
  can somebody point me to what I'm doing wrong?
  
  create database engine owner engine template template0 encoding 'UTF8'
  lc_collate 'en_US.UTF-8' lc_ctype 'en_US.UTF-8';
  $OVIRT_OUT/bin/engine-setup --jboss-home=${JBOSS_HOME}
  $OVIRT_OUT/bin/engine-setup --jboss-home=${JBOSS_HOME}
  
  gives me error:
  Failed to execute stage 'Setup validation': Trying to upgrade from
  unsupported versions: 3.5
  
  thanks,
  Martin.
  ___
  Devel mailing list
  Devel@ovirt.org
  http://lists.ovirt.org/mailman/listinfo/devel
  
 ___
 Devel mailing list
 Devel@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/devel
 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] Failed to execute stage 'Setup validation': Trying to upgrade from unsupported versions: 3.5

[Martin Mucha]

Hi,

can somebody point me to what I'm doing wrong?

create database engine owner engine template template0 encoding 'UTF8' 
lc_collate 'en_US.UTF-8' lc_ctype 'en_US.UTF-8';
$OVIRT_OUT/bin/engine-setup --jboss-home=${JBOSS_HOME}
$OVIRT_OUT/bin/engine-setup --jboss-home=${JBOSS_HOME}

gives me error:
Failed to execute stage 'Setup validation': Trying to upgrade from unsupported 
versions: 3.5

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

Re: [ovirt-devel] [ovirt-users] Feature Page: Mac Pool per DC

[Martin Mucha]

Hi,

thanks for your input, I'll try to satisfy your request to be able to set range 
'width' either by 'end boundary' or 'mac count' in gui design.

Prior to that there are more fundamental decisions to be made -- like whether 
the pool definition is mandatory or optional, and how this influence the app 
for upgrading users. I'm pushing the idea of optional definition with one 
global pool as a fallback. And like I said in previous emails, from this point 
of view is gui design marginal, since we do not know what exact things should 
be displayed there(gui will be little bit different for optional pool 
definition). This is to be decided this week, after that we can discuss final 
design of gui.

m.

- Original Message -
From: Genadi Chereshnya gcher...@redhat.com
To: Moti Asayag masa...@redhat.com
Cc: devel@ovirt.org, us...@ovirt.org, Martin Mucha mmu...@redhat.com, 
Martin Pavlik mpav...@redhat.com
Sent: Monday, April 28, 2014 8:47:11 AM
Subject: Re: [ovirt-users] [ovirt-devel] Feature Page: Mac Pool per DC

Hi, 
We would like to propose a little bit better solution from user experience side.

We should have 3 fields for each range:
1) Start range
2) End range
3) Number of MACs
When you have to fill in End range or Number of MACs (when start range is 
mandatory).
And the 3rd field will be filled in automatically according to others.
For example:
1) If Start range is 00:00:00:00:00:01 and Number of MACs is 5 then End 
range should be filled in with 00:00:00:00:00:05.
2) If Start range is 00:00:00:00:00:01 and End range is 00:00:00:00:00:05, 
then Number of MACs should be filled in with 5. 

For update: End range and Number of MACs should be updated automatically as 
well, so if you update End range the Number of MACs should be updated and 
vice versa.

For adding several MAC pool ranges for DC we can use the + or - sign as we 
do for adding VNIC profile or Labels field.

Regards,
   Genadi








- Original Message -
From: Moti Asayag masa...@redhat.com
To: Martin Mucha mmu...@redhat.com
Cc: devel@ovirt.org, us...@ovirt.org
Sent: Monday, April 28, 2014 9:21:50 AM
Subject: Re: [ovirt-users] [ovirt-devel] Feature Page: Mac Pool per DC



- Original Message -
 From: Martin Mucha mmu...@redhat.com
 To: Yevgeny Zaspitsky yzasp...@redhat.com
 Cc: us...@ovirt.org, devel@ovirt.org
 Sent: Monday, April 28, 2014 9:14:38 AM
 Subject: Re: [ovirt-devel] Feature Page: Mac Pool per DC
 
 Hi,
 you're right, I do know about these problems. THIS IS DEFINITELY NOT A FINAL
 CODE.
 
 Why I did it this way: I come from agile environment.
 This supposed to be FIRST increment. Not last. I hate waterfall style of work
 -- almighty solution in one swing. I'd like to make sure, that main part,
 that core principle is valid and approved. Making gui look nice is marginal.
 So it is data structure for first increment. We can definitely think of
 thousands of improvements, BUT this RFC already include more than 10 patch
 sets and NO core reviews. How can I know, that others will approve this and
 I'm not completely wrong?
 
 about UX: it's wrong, but just fine for first increment. It can be used
 somehow and that just sufficient. Note: even with table to enter each
 from-to range there can be validation problem needed to be handled. Gui can
 changed to better one, when we know, that this feature works. But meantime
 others can test this feature functionality via this ugly, but very fast to
 write, gui!
 
 about DB: I'm aware of DB normalization, and about all implications my
 design has. Yes, storing it in one varchar column is DB (very heavily
 used) antipattern, just fine for first increment and very easy to fix.
 

There is another motivation for using a normalized data, specifically for
mac addresses - using the MAC addresses type [1] will enforce validity of
the input and will allow functionality such as comparison (is required).

[1] http://www.postgresql.org/docs/8.4/static/datatype-net-types.html

 If it's up to me, I'd like to wait for approval of 'core' part of this change
 (lets call it spike), and finish remaining 'marginalities' after it. (just
 to make myself clear proper db design ISN'T marginal measuring it using
 absolute scale, but it IS very marginal related to situation where most of
 code wasn't approved/reviewed yet).
 
 m.
 
 - Original Message -
 From: Yevgeny Zaspitsky yzasp...@redhat.com
 To: Martin Mucha mmu...@redhat.com
 Cc: devel@ovirt.org, us...@ovirt.org
 Sent: Sunday, April 27, 2014 2:22:04 PM
 Subject: Re: [ovirt-devel] Feature Page: Mac Pool per DC
 
 Now for us...@ovirt.org indeed.
 
 - Original Message -
 From: Yevgeny Zaspitsky yzasp...@redhat.com
 To: Martin Mucha mmu...@redhat.com
 Cc: us...@ovrit.org, devel@ovirt.org
 Sent: Sunday, April 27, 2014 2:29:46 PM
 Subject: Re: [ovirt-devel] Feature Page: Mac Pool per DC
 
 Martin,
 
 I'd like to propose a different approach on how the ranges to be defined and
 stored.
 
 Discussing this feature with Moti