Re: [ovirt-devel] oVirt-specific aspect languages

[Arik Hadas]

Hi,

Thanks for the feedback!
I commented below.

- Original Message -
> Hi all,
> 
> I agree that it was an interesting article.
> 
> > However, since AspectJ is an extension to Java, most of oVirt
> > developers would need to know additional programming language
> > which puts the cost-effectiveness of this approach into question.
> 
> Actually you only need to learn some very basic stuff about pointcut
> definition. The rest was pure Java for anything I ever needed (before,
> after and around cases).
> 

Well, it depends on both the base code and the crosscutting-concerns you 
develop the aspects for I guess.
>From my experience with AspectJ, the very basic stuff there typically fits 
>only for very simple crosscutting concerns.
For example, in the generated aspects for the languages I developed for the 
crosscutting concerns in oVirt I had to use more than the basic stuff (e.g. 
inter-type declarations).
I'm curios, where did you use AspectJ? For how many and what kind of 
crosscutting concerns did you use it?

> DSLs are a nice thing to have, and we can start by utilizing object
> builders more :) Those are a kind of DSL too if nicely written. See
> the latest email on this list from Roman Mohr that talks about Domain
> Object Builders (or Spring Security Java configuration [2] to see a
> more complicated example of how it is used elsewhere).
> 
> Martin
> 
> [1] http://lists.ovirt.org/pipermail/devel/2016-April/012790.html
> [2]
> http://docs.spring.io/spring-security/site/docs/current/reference/html/jc.html
> 
> On Mon, Apr 11, 2016 at 4:13 PM, Vojtech Szocs  wrote:
> > Hi Arik,
> >
> > thanks for sharing this, the article is very interesting!
> >
> > "
> > However, since AspectJ is an extension to Java, most of oVirt
> > developers would need to know additional programming language
> > which puts the cost-effectiveness of this approach into question.
> > "
> >
> > I always thought that good Java developers should be familiar
> > with AOP concepts anyway.

I think that many are familiar with the general AOP concepts but nevertheless 
decide not to adopt them.
Many think that AOP is useful only for simple logging and tracing or as a 
simplified API for byte-code manipulation (I guess that's why AspectJ is used 
by GWT in our build process, right?) or in its simplified form as spring-aop, 
because of the known drawbacks of AspectJ.
Hopefully the proposed approach would change that :)

> >
> > That said, I really like the combo of AOP with DSL (or ASL)
> > and I agree that it can simplify handling concerns in a way
> > that is much closer to app's domain, rather than being closer
> > to its implementation (as with AOP).
> >
> > Regards,
> > Vojtech
> >
> >
> > - Original Message -
> >> From: "Arik Hadas" 
> >> To: "devel" 
> >> Sent: Monday, April 11, 2016 9:02:39 AM
> >> Subject: [ovirt-devel] oVirt-specific aspect languages
> >>
> >> Hi All,
> >>
> >> Last month I participated in Modularity'16, an academic conference that
> >> focuses on advanced software modularization techniques, where I presented
> >> my
> >> work in the area of domain specific aspect languages that was evaluated on
> >> oVirt.
> >>
> >> Many have asked me to elaborate on this work, so I wrote a post that
> >> explains
> >> the idea and provides references to relevant materials that were presented
> >> in the conference, which I would like to share with you:
> >> http://ahadas.github.io/oVirt-Specifc-Aspect-Languages/
> >>
> >> Regards,
> >> Arik
> >> ___
> >> 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] UI plugins - access to engine styles and libraries

[Martin Sivak]

Hi everybody,

there is one piece I always missed when developing my optimizer plugin
and that is the access to the engine css styles.

I feel it might be pretty easy and good for both bandwidth and
branding to expose them using some "well known" url from the engine.
All plugins would be then able to (re-)use the same styling
information and basic javascript libraries (jQuery, angular, whatever
you decide the core engine will use).

So far, each UI plugin has to link to its own version of libraries and
define (and maintain) custom color theme.

Do you think this would be doable for 4.0?

Best regards

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

Re: [ovirt-devel] oVirt-specific aspect languages

[Martin Sivak]

Hi all,

I agree that it was an interesting article.

> However, since AspectJ is an extension to Java, most of oVirt
> developers would need to know additional programming language
> which puts the cost-effectiveness of this approach into question.

Actually you only need to learn some very basic stuff about pointcut
definition. The rest was pure Java for anything I ever needed (before,
after and around cases).

DSLs are a nice thing to have, and we can start by utilizing object
builders more :) Those are a kind of DSL too if nicely written. See
the latest email on this list from Roman Mohr that talks about Domain
Object Builders (or Spring Security Java configuration [2] to see a
more complicated example of how it is used elsewhere).

Martin

[1] http://lists.ovirt.org/pipermail/devel/2016-April/012790.html
[2] 
http://docs.spring.io/spring-security/site/docs/current/reference/html/jc.html

On Mon, Apr 11, 2016 at 4:13 PM, Vojtech Szocs  wrote:
> Hi Arik,
>
> thanks for sharing this, the article is very interesting!
>
> "
> However, since AspectJ is an extension to Java, most of oVirt
> developers would need to know additional programming language
> which puts the cost-effectiveness of this approach into question.
> "
>
> I always thought that good Java developers should be familiar
> with AOP concepts anyway.
>
> That said, I really like the combo of AOP with DSL (or ASL)
> and I agree that it can simplify handling concerns in a way
> that is much closer to app's domain, rather than being closer
> to its implementation (as with AOP).
>
> Regards,
> Vojtech
>
>
> - Original Message -
>> From: "Arik Hadas" 
>> To: "devel" 
>> Sent: Monday, April 11, 2016 9:02:39 AM
>> Subject: [ovirt-devel] oVirt-specific aspect languages
>>
>> Hi All,
>>
>> Last month I participated in Modularity'16, an academic conference that
>> focuses on advanced software modularization techniques, where I presented my
>> work in the area of domain specific aspect languages that was evaluated on
>> oVirt.
>>
>> Many have asked me to elaborate on this work, so I wrote a post that explains
>> the idea and provides references to relevant materials that were presented
>> in the conference, which I would like to share with you:
>> http://ahadas.github.io/oVirt-Specifc-Aspect-Languages/
>>
>> Regards,
>> Arik
>> ___
>> 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] Integration tests future (and very nice alternative for the DAO fixture file)

[Roman Mohr]

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 =0; x < 10; x++){
builder.id(Guid.newGuid()).persist();
}
}
}

3) Full integration test with arquillian and the database

@Category(IntegrationTest.class)
public class VmDaoIntegrationTest extends TransactionalTestBase {

@Inject
VmDao vmDao;

private final Guid VM1_GUID =
Guid.createGuidFromString("0fe4bc81-5999-4ab6-80f8-7a4a2d4bfacd");

@Deployment
public static JavaArchive deploy(){
return createDeployment();
}

@Test
public void shouldFailOnExistingEntity() {

vmBuilder.id(VM1_GUID).cluster(clusterBuilder.reset().persist()).persist();
// This uses assertThat from assertj:
assertThat(vmDao.get(VM1_GUID)).isNotNull();
}
}

4) Using the builders in a normal unit test without a database:

VM vm = new VmBuilder().id(Guid.newGuid()).up().build();


# How to add your own Domain objects?

There are just a few simple rules:

1) Your builder should extend org.ovirt.engine.core.builder.AbstractBuilder

2) Make sure that you only access DAOs injected into the builder during
#prePersist() and #persist(). This allows to use the #build() method also
without injections

3) #prePersist() should set all fields which are necessary to suffice
database constraints. The fields should only be set if they are not already
set before by the builder. When following this rule we can always persist
new objects to the database by simply calling myBuilder.reset().persist().

4) Mark your builder with @Repository to make them useable for our Spring
DAO tests and our Arquillian integration tests.

So have a look at the patches at [1] and let me know what you think about
them.

Best Regards and happy testing,

Roman

[1] https://gerrit.ovirt.org/#/q/topic:integration
[2] https://gerrit.ovirt.org/#/c/47008/17
[3] https://gerrit.ovirt.org/#/c/47007/10
[4] https://gerrit.ovirt.org/#/c/47008/17
[5] https://maven.apache.org/surefire/maven-failsafe-plugin/
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [lago-devel] Lago + ovirt-system-tests run fail on collecting logs

[David Caro]

On 04/13 15:01, Yaniv Kaul wrote:
> On Wed, Apr 13, 2016 at 2:02 PM, David Caro  wrote:
> 
> > Though you will not have any caching and zram execution (just as the
> > jenkins
> > slaves don't have it).
> >
> 
> That should change. The sooner the better.

So as I said, there's an usync between what you do and everyone else, it should
be synced, either one side or the other, in any case, please open a task and
prioritize properly, if it only affects the test scripts (like running on ram)
then to bugzilla, if it affects lago, then github.

> 
> If they have enough ram, they can actually run in /dev/shm/something.
> That's what I'm doing with the VDSM functional tests.
> Y.

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


signature.asc
Description: PGP signature
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [lago-devel] Lago + ovirt-system-tests run fail on collecting logs

[Yaniv Kaul]

On Wed, Apr 13, 2016 at 2:02 PM, David Caro  wrote:

> Though you will not have any caching and zram execution (just as the
> jenkins
> slaves don't have it).
>

That should change. The sooner the better.

If they have enough ram, they can actually run in /dev/shm/something.
That's what I'm doing with the VDSM functional tests.
Y.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Reducing the amount of builds to keep in ovirt-engine upstream jobs

[Eyal Edri]

I missed the part of reducing to 10 artifacts.
I think we should keep it at 20, I agree lower than that will be harder to
see errors.

We'll keep monitoring it closely until the migration (planned for the
24-25/04).

On Wed, Apr 13, 2016 at 1:56 PM, Sandro Bonazzola 
wrote:

>
>
> On Wed, Apr 13, 2016 at 12:42 PM, Eyal Edri  wrote:
>
>> +1 from me.
>>
>> We are in the process of migration to the new jenkins [2], Actually some
>> of the jobs already migrated (node/lago),
>> So we will be able to increase history back to higher levels once we
>> finish the migration.
>>
>> I think on some projects we reduced it to 20 already, which projects
>> still use 40?
>>
>
> Note that the request here is to reduce from 20 to 10 the archived builds.
> This means that you probably won't be able anymore to inspect logs for a
> failing job unless it's a job triggered just once every 2 hours.
> I think that 20 is already a low number enough at least for most of the
> jobs.
> I'm ok with reducing the archiving for jobs running once a day.
>
>
>
>>
>> e.
>>
>> On Mon, Apr 11, 2016 at 5:01 PM, Gil Shinar  wrote:
>>
>>> Hi,
>>>
>>> Upstream Jenkins disk always get filled up and I want to reduce the
>>> amount of builds to keep from 40 to 30 or even 20 and the amount of
>>> archived artifacts to keep from 20 to 15 or even 10.
>>>
>>> Is that OK by you?
>>>
>>> Thanks
>>> Gil
>>>
>>> ___
>>> Devel mailing list
>>> Devel@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>
>>
>>
>> --
>> Eyal Edri
>> Associate Manager
>> RHEV DevOps
>> EMEA ENG Virtualization R
>> Red Hat Israel
>>
>> phone: +972-9-7692018
>> irc: eedri (on #tlv #rhev-dev #rhev-integ)
>>
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>
>
>
> --
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
>



-- 
Eyal Edri
Associate Manager
RHEV DevOps
EMEA ENG Virtualization R
Red Hat Israel

phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] gerrit.ovirt.org restart

[Gil Shinar]

Hi all,

Due to very slow performance we are restarting the gerrit service.
It'll be back up in one minute

Sorry for the inconvenient
Gil
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Upstream Jenkins maintenance

[Gil Shinar]

Hi,

Jenkins is back online. Some jobs were still in the queue. Please make sure
that your patches have passes check patch or check merge and if not,
re-trigger them.

Thanks
Gil

On Tue, Apr 12, 2016 at 11:36 AM, Gil Shinar  wrote:

> Hi,
>
> We need to install two security patches and for that we need to restart
> the Jenkins.
> In order to do that we will need you to stop sending patches for two hours
> so the Jenkins queue will clear itself.
> I'm scheduling the restart for today at 18:00 IST. Patches that'll be sent
> after 16:00 IST might not be checked.
>
> Thanks
> Gil
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] Upstream Jenkins maintenance

[Gil Shinar]

Hi,

We need to install two security patches and for that we need to restart the
Jenkins.
In order to do that we will need you to stop sending patches for two hours
so the Jenkins queue will clear itself.
I'm scheduling the restart for today at 18:00 IST. Patches that'll be sent
after 16:00 IST might not be checked.

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

[ovirt-devel] Reducing the amount of builds to keep in ovirt-engine upstream jobs

[Gil Shinar]

Hi,

Upstream Jenkins disk always get filled up and I want to reduce the amount
of builds to keep from 40 to 30 or even 20 and the amount of archived
artifacts to keep from 20 to 15 or even 10.

Is that OK by you?

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

Re: [ovirt-devel] VDSM fails 'autogen.sh' when shallow cloning - is that expected?

[Yaniv Kaul]

On Wed, Apr 13, 2016 at 11:49 AM, Nir Soffer  wrote:

> On Wed, Apr 13, 2016 at 11:27 AM, Sandro Bonazzola 
> wrote:
> >
> >
> > On Tue, Apr 12, 2016 at 8:37 PM, Yaniv Kaul  wrote:
> >>
> >> Probably fails because of:
> >> git describe
> >> fatal: No names found, cannot describe anything.
> >
> >
> > Yes. I think autogen.sh and configure.ac shouldn't rely on git for
> package
> > versioning.
> > The automation/build-artifacs.sh script can take care of adding suffixes
> to
> > rpm release if needed at build time.
> > Version should be statically defined within configure.ac.
>
> Yaniv is using a git clone, so depending on git is fine in this case.
>
> The tarball should not have any dependencies on git.
>
> I think the issue is missing tags - this works:
>
> git clone -b master --depth 1 git://gerrit.ovirt.org/vdsm
> git tag v4.17.999
>

How do I know which tag to use?
Y.


> ./autogen.sh --system
>
> Nir
>
> >
> >
> >>
> >>
> >>
> >>
> >> On Tue, Apr 12, 2016 at 9:32 PM, Yaniv Kaul  wrote:
> >>>
> >>> Cloning VDSM with the following command:
> >>> git clone -b master --depth 1 git://gerrit.ovirt.org/vdsm
> >>>
> >>> Which works, but then I can't run ./autogen.sh succesfully:
> >>> mini@ykaul-mini:/tmp/github/vdsmshallow$ ./autogen.sh  |less
> >>> fatal: No names found, cannot describe anything.
> >>> fatal: No names found, cannot describe anything.
> >>> fatal: No names found, cannot describe anything.
> >>> fatal: No names found, cannot describe anything.
> >>> fatal: No names found, cannot describe anything.
> >>> fatal: No names found, cannot describe anything.
> >>> fatal: No names found, cannot describe anything.
> >>> fatal: No names found, cannot describe anything.
> >>> fatal: No names found, cannot describe anything.
> >>> fatal: No names found, cannot describe anything.
> >>> fatal: No names found, cannot describe anything.
> >>> fatal: No names found, cannot describe anything.
> >>> fatal: No names found, cannot describe anything.
> >>> fatal: No names found, cannot describe anything.
> >>> fatal: No names found, cannot describe anything.
> >>> fatal: No names found, cannot describe anything.
> >>> fatal: No names found, cannot describe anything.
> >>> fatal: No names found, cannot describe anything.
> >>> fatal: No names found, cannot describe anything.
> >>> fatal: No names found, cannot describe anything.
> >>> fatal: No names found, cannot describe anything.
> >>> fatal: No names found, cannot describe anything.
> >>> fatal: No names found, cannot describe anything.
> >>> fatal: No names found, cannot describe anything.
> >>> fatal: No names found, cannot describe anything.
> >>> fatal: No names found, cannot describe anything.
> >>> fatal: No names found, cannot describe anything.
> >>> fatal: No names found, cannot describe anything.
> >>> fatal: No names found, cannot describe anything.
> >>> fatal: No names found, cannot describe anything.
> >>> fatal: No names found, cannot describe anything.
> >>> fatal: No names found, cannot describe anything.
> >>> fatal: No names found, cannot describe anything.
> >>> fatal: No names found, cannot describe anything.
> >>> fatal: No names found, cannot describe anything.
> >>> fatal: No names found, cannot describe anything.
> >>> fatal: No names found, cannot describe anything.
> >>> fatal: No names found, cannot describe anything.
> >>> fatal: No names found, cannot describe anything.
> >>> fatal: No names found, cannot describe anything.
> >>> fatal: No names found, cannot describe anything.
> >>> fatal: No names found, cannot describe anything.
> >>> I am going to run ./configure with no arguments - if you wish
> >>> to pass any to it, please specify them on the ./autogen.sh command
> line.
> >>> configure: error: package version not defined
> >>>
> >>> As the difference is 1:10 in data size and I only wish to work on the
> >>> tip, this could be very useful to me.
> >>> Any ideas?
> >>
> >>
> >>
> >> ___
> >> Devel mailing list
> >> Devel@ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/devel
> >
> >
> >
> >
> > --
> > Sandro Bonazzola
> > Better technology. Faster innovation. Powered by community collaboration.
> > See how it works at redhat.com
> >
> > ___
> > Devel mailing list
> > Devel@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] No RPMs under http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/ ?

[Gil Shinar]

Hi Juan,

Sent you an email in the morning. Can you please check?

Thanks
Gil

On Mon, Apr 11, 2016 at 3:49 PM, Juan Hernández  wrote:

> On 04/11/2016 02:07 PM, Gil Shinar wrote:
> > Hi,
> >
> > Now it should be OK till Juan will permanently fix that.
> >
> > Gil
> >
>
> What do I need to fix?
>
> > On Mon, Apr 11, 2016 at 3:02 PM, Sandro Bonazzola  > > wrote:
> >
> >
> >
> > On Mon, Apr 11, 2016 at 11:34 AM, Yaniv Kaul  > > wrote:
> >
> > I can't find EL7 RPMs under the above path.
> > They used to be there...
> >
> >
> >
> > There have been an issue in nighlty publisher, Gil was on it this
> > morning, didn't have time yet to check the current status
> >
> >
> >
> > TIA,
> > Y.
> >
> > ___
> > Devel mailing list
> > Devel@ovirt.org 
> > http://lists.ovirt.org/mailman/listinfo/devel
> >
> >
> >
> >
> > --
> > Sandro Bonazzola
> > Better technology. Faster innovation. Powered by community
> > collaboration.
> > See how it works at redhat.com 
> >
> >
> >
> >
> > ___
> > Devel mailing list
> > Devel@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
> >
>
>
> --
> 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] [lago-devel] Lago + ovirt-system-tests run fail on collecting logs

[Yaniv Kaul]

On Wed, Apr 13, 2016 at 1:05 PM, David Caro  wrote:

> On 04/10 20:52, Yaniv Kaul wrote:
> > On Sun, Apr 10, 2016 at 6:06 PM, Eyal Edri  wrote:
> >
> > > test_logs/
> >
> >
> > This is an annoying change of behavior. In the past, I believe the logs
> > were under the deployment dir. Now, they are here. It requires cleaning
> > them manually every time.
>
> Before it also required manual cleanup every time, it just turned out, that
> while doing the manual cleanup of the prefix (with ./run_suite -c) the logs
> were removed too (that was also an issue on jenkins, as you had to extract
> the
> logs before the cleanup)
>

1. Makes sense to me that you'll extract the logs before cleanup.
2. It did not cause a re-run to fail, which now, unless you cleanup AND rm
the files, it will.

>
> > It's part of issues we'll have to fix if we want (and I believe we do)
> > support multiple execution.
>

Yep.


>
> It supports multiple execution as long as you are not running the same
> suite,
> same as before, the issue here is that you are using a very specific flow
> that
> is not used anywhere else, and thus, facing issues and user cases that
> noone
> else has.
> I really recommend:
>   * Moving to the same flow jenkins uses
>   * Moving jenkins to the same flow you use
>

I'm running ./run_suite.sh -o /home/zram/3.6 basic_suite_3.6
and cleanup:
lagocli --prefix-path /home/zram/3.6/current cleanup

over and over and over and over...

What should I be running?
Y.


> > I consider it as a regression in a way, since it's a changed behavior -
> and
> > I'm not sure for the better.
>
> It changed behavior yes, and it improved the log collection and cleanup
> procedures on jenkins.
> To alleviate that issue, I sent a patch for that in the beginning of the
> lago
> project that was never merged, feel free to open a task for that too,
> should be
> relatively easy to implement some kind of log rotation if the destination
> directory already exists.
>
> > Y.
>
> > ___
> > lago-devel mailing list
> > lago-de...@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/lago-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

Re: [ovirt-devel] [lago-devel] Lago + ovirt-system-tests run fail on collecting logs

[David Caro]

On 04/10 20:52, Yaniv Kaul wrote:
> On Sun, Apr 10, 2016 at 6:06 PM, Eyal Edri  wrote:
> 
> > test_logs/
> 
> 
> This is an annoying change of behavior. In the past, I believe the logs
> were under the deployment dir. Now, they are here. It requires cleaning
> them manually every time.

Before it also required manual cleanup every time, it just turned out, that
while doing the manual cleanup of the prefix (with ./run_suite -c) the logs
were removed too (that was also an issue on jenkins, as you had to extract the
logs before the cleanup)

> It's part of issues we'll have to fix if we want (and I believe we do)
> support multiple execution.

It supports multiple execution as long as you are not running the same suite,
same as before, the issue here is that you are using a very specific flow that
is not used anywhere else, and thus, facing issues and user cases that noone
else has.
I really recommend:
  * Moving to the same flow jenkins uses
  * Moving jenkins to the same flow you use

> I consider it as a regression in a way, since it's a changed behavior - and
> I'm not sure for the better.

It changed behavior yes, and it improved the log collection and cleanup
procedures on jenkins.
To alleviate that issue, I sent a patch for that in the beginning of the lago
project that was never merged, feel free to open a task for that too, should be
relatively easy to implement some kind of log rotation if the destination
directory already exists.

> Y.

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


signature.asc
Description: PGP signature
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] VDSM fails 'autogen.sh' when shallow cloning - is that expected?

[Nir Soffer]

On Wed, Apr 13, 2016 at 11:27 AM, Sandro Bonazzola  wrote:
>
>
> On Tue, Apr 12, 2016 at 8:37 PM, Yaniv Kaul  wrote:
>>
>> Probably fails because of:
>> git describe
>> fatal: No names found, cannot describe anything.
>
>
> Yes. I think autogen.sh and configure.ac shouldn't rely on git for package
> versioning.
> The automation/build-artifacs.sh script can take care of adding suffixes to
> rpm release if needed at build time.
> Version should be statically defined within configure.ac.

Yaniv is using a git clone, so depending on git is fine in this case.

The tarball should not have any dependencies on git.

I think the issue is missing tags - this works:

git clone -b master --depth 1 git://gerrit.ovirt.org/vdsm
git tag v4.17.999
./autogen.sh --system

Nir

>
>
>>
>>
>>
>>
>> On Tue, Apr 12, 2016 at 9:32 PM, Yaniv Kaul  wrote:
>>>
>>> Cloning VDSM with the following command:
>>> git clone -b master --depth 1 git://gerrit.ovirt.org/vdsm
>>>
>>> Which works, but then I can't run ./autogen.sh succesfully:
>>> mini@ykaul-mini:/tmp/github/vdsmshallow$ ./autogen.sh  |less
>>> fatal: No names found, cannot describe anything.
>>> fatal: No names found, cannot describe anything.
>>> fatal: No names found, cannot describe anything.
>>> fatal: No names found, cannot describe anything.
>>> fatal: No names found, cannot describe anything.
>>> fatal: No names found, cannot describe anything.
>>> fatal: No names found, cannot describe anything.
>>> fatal: No names found, cannot describe anything.
>>> fatal: No names found, cannot describe anything.
>>> fatal: No names found, cannot describe anything.
>>> fatal: No names found, cannot describe anything.
>>> fatal: No names found, cannot describe anything.
>>> fatal: No names found, cannot describe anything.
>>> fatal: No names found, cannot describe anything.
>>> fatal: No names found, cannot describe anything.
>>> fatal: No names found, cannot describe anything.
>>> fatal: No names found, cannot describe anything.
>>> fatal: No names found, cannot describe anything.
>>> fatal: No names found, cannot describe anything.
>>> fatal: No names found, cannot describe anything.
>>> fatal: No names found, cannot describe anything.
>>> fatal: No names found, cannot describe anything.
>>> fatal: No names found, cannot describe anything.
>>> fatal: No names found, cannot describe anything.
>>> fatal: No names found, cannot describe anything.
>>> fatal: No names found, cannot describe anything.
>>> fatal: No names found, cannot describe anything.
>>> fatal: No names found, cannot describe anything.
>>> fatal: No names found, cannot describe anything.
>>> fatal: No names found, cannot describe anything.
>>> fatal: No names found, cannot describe anything.
>>> fatal: No names found, cannot describe anything.
>>> fatal: No names found, cannot describe anything.
>>> fatal: No names found, cannot describe anything.
>>> fatal: No names found, cannot describe anything.
>>> fatal: No names found, cannot describe anything.
>>> fatal: No names found, cannot describe anything.
>>> fatal: No names found, cannot describe anything.
>>> fatal: No names found, cannot describe anything.
>>> fatal: No names found, cannot describe anything.
>>> fatal: No names found, cannot describe anything.
>>> fatal: No names found, cannot describe anything.
>>> I am going to run ./configure with no arguments - if you wish
>>> to pass any to it, please specify them on the ./autogen.sh command line.
>>> configure: error: package version not defined
>>>
>>> As the difference is 1:10 in data size and I only wish to work on the
>>> tip, this could be very useful to me.
>>> Any ideas?
>>
>>
>>
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>
>
>
>
> --
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ACTION REQUIRED] Project vdsm_master_check-merged-el7-x86_64 failing consistently

[Sandro Bonazzola]

On Wed, Apr 13, 2016 at 10:19 AM, Eyal Edri  wrote:

> We should also have more el7 hypervisors now so if needed we can use them
> instead.
>
> We can reinstall the fc23 as el7 if we don't need specifically fedora hosts
>

I'm not aware of jobs requiring fc23 slaves.




> On Apr 13, 2016 11:09 AM, "David Caro"  wrote:
>
>> On 04/12 18:16, Sandro Bonazzola wrote:
>> > Hi,
>> >  Project vdsm_master_check-merged-el7-x86_64 failing consistently at
>> least
>> > since April 7.
>> >
>> > *00:15:04.646* * Starting VM vdsm_functional_tests_host-fc23:
>> > *00:15:04.649* libvirt: QEMU Driver error : Cannot check QEMU binary
>> > /usr/libexec/qemu-kvm: No such file or directory
>> >
>> >
>> > Please fix functional test ASAP.
>> >
>> > CC infra so they're aware of the issue as well.
>>
>> That's caused by the tests when they run el* chroot on top of fedora*
>> host, it
>> can be easily fixed with this snippet running on the automation/* scripts
>> (extracted from the lago ones):
>>
>> # Ugly fix to be able to run el* on fc*
>> if ! [[ -e /usr/bin/qemu-kvm ]]; then
>> ln -s /usr/libexec/qemu-kvm /usr/bin/qemu-kvm
>> fi
>>
>>
>> >
>> > --
>> > Sandro Bonazzola
>> > Better technology. Faster innovation. Powered by community
>> collaboration.
>> > See how it works at redhat.com
>>
>> > ___
>> > Infra mailing list
>> > in...@ovirt.org
>> > http://lists.ovirt.org/mailman/listinfo/infra
>>
>>
>> --
>> 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
>>
>


-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] VDSM fails 'autogen.sh' when shallow cloning - is that expected?

[Sandro Bonazzola]

On Tue, Apr 12, 2016 at 8:37 PM, Yaniv Kaul  wrote:

> Probably fails because of:
> git describe
> fatal: No names found, cannot describe anything.
>

Yes. I think autogen.sh and configure.ac shouldn't rely on git for package
versioning.
The automation/build-artifacs.sh script can take care of adding suffixes to
rpm release if needed at build time.
Version should be statically defined within configure.ac.



>
>
>
> On Tue, Apr 12, 2016 at 9:32 PM, Yaniv Kaul  wrote:
>
>> Cloning VDSM with the following command:
>> git clone -b master --depth 1 git://gerrit.ovirt.org/vdsm
>>
>> Which works, but then I can't run ./autogen.sh succesfully:
>> mini@ykaul-mini:/tmp/github/vdsmshallow$ ./autogen.sh  |less
>> fatal: No names found, cannot describe anything.
>> fatal: No names found, cannot describe anything.
>> fatal: No names found, cannot describe anything.
>> fatal: No names found, cannot describe anything.
>> fatal: No names found, cannot describe anything.
>> fatal: No names found, cannot describe anything.
>> fatal: No names found, cannot describe anything.
>> fatal: No names found, cannot describe anything.
>> fatal: No names found, cannot describe anything.
>> fatal: No names found, cannot describe anything.
>> fatal: No names found, cannot describe anything.
>> fatal: No names found, cannot describe anything.
>> fatal: No names found, cannot describe anything.
>> fatal: No names found, cannot describe anything.
>> fatal: No names found, cannot describe anything.
>> fatal: No names found, cannot describe anything.
>> fatal: No names found, cannot describe anything.
>> fatal: No names found, cannot describe anything.
>> fatal: No names found, cannot describe anything.
>> fatal: No names found, cannot describe anything.
>> fatal: No names found, cannot describe anything.
>> fatal: No names found, cannot describe anything.
>> fatal: No names found, cannot describe anything.
>> fatal: No names found, cannot describe anything.
>> fatal: No names found, cannot describe anything.
>> fatal: No names found, cannot describe anything.
>> fatal: No names found, cannot describe anything.
>> fatal: No names found, cannot describe anything.
>> fatal: No names found, cannot describe anything.
>> fatal: No names found, cannot describe anything.
>> fatal: No names found, cannot describe anything.
>> fatal: No names found, cannot describe anything.
>> fatal: No names found, cannot describe anything.
>> fatal: No names found, cannot describe anything.
>> fatal: No names found, cannot describe anything.
>> fatal: No names found, cannot describe anything.
>> fatal: No names found, cannot describe anything.
>> fatal: No names found, cannot describe anything.
>> fatal: No names found, cannot describe anything.
>> fatal: No names found, cannot describe anything.
>> fatal: No names found, cannot describe anything.
>> fatal: No names found, cannot describe anything.
>> I am going to run ./configure with no arguments - if you wish
>> to pass any to it, please specify them on the ./autogen.sh command line.
>> configure: error: package version not defined
>>
>> As the difference is 1:10 in data size and I only wish to work on the
>> tip, this could be very useful to me.
>> Any ideas?
>>
>
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>



-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ACTION REQUIRED] Project vdsm_master_check-merged-el7-x86_64 failing consistently

[Eyal Edri]

We should also have more el7 hypervisors now so if needed we can use them
instead.

We can reinstall the fc23 as el7 if we don't need specifically fedora hosts
On Apr 13, 2016 11:09 AM, "David Caro"  wrote:

> On 04/12 18:16, Sandro Bonazzola wrote:
> > Hi,
> >  Project vdsm_master_check-merged-el7-x86_64 failing consistently at
> least
> > since April 7.
> >
> > *00:15:04.646* * Starting VM vdsm_functional_tests_host-fc23:
> > *00:15:04.649* libvirt: QEMU Driver error : Cannot check QEMU binary
> > /usr/libexec/qemu-kvm: No such file or directory
> >
> >
> > Please fix functional test ASAP.
> >
> > CC infra so they're aware of the issue as well.
>
> That's caused by the tests when they run el* chroot on top of fedora*
> host, it
> can be easily fixed with this snippet running on the automation/* scripts
> (extracted from the lago ones):
>
> # Ugly fix to be able to run el* on fc*
> if ! [[ -e /usr/bin/qemu-kvm ]]; then
> ln -s /usr/libexec/qemu-kvm /usr/bin/qemu-kvm
> fi
>
>
> >
> > --
> > Sandro Bonazzola
> > Better technology. Faster innovation. Powered by community collaboration.
> > See how it works at redhat.com
>
> > ___
> > Infra mailing list
> > in...@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
>
>
> --
> 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

Re: [ovirt-devel] [ACTION REQUIRED] Project vdsm_master_check-merged-el7-x86_64 failing consistently

[David Caro]

On 04/12 18:16, Sandro Bonazzola wrote:
> Hi,
>  Project vdsm_master_check-merged-el7-x86_64 failing consistently at least
> since April 7.
> 
> *00:15:04.646* * Starting VM vdsm_functional_tests_host-fc23:
> *00:15:04.649* libvirt: QEMU Driver error : Cannot check QEMU binary
> /usr/libexec/qemu-kvm: No such file or directory
> 
> 
> Please fix functional test ASAP.
> 
> CC infra so they're aware of the issue as well.

That's caused by the tests when they run el* chroot on top of fedora* host, it
can be easily fixed with this snippet running on the automation/* scripts 
(extracted from the lago ones):

# Ugly fix to be able to run el* on fc*
if ! [[ -e /usr/bin/qemu-kvm ]]; then
ln -s /usr/libexec/qemu-kvm /usr/bin/qemu-kvm
fi


> 
> -- 
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com

> ___
> Infra mailing list
> in...@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra


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


signature.asc
Description: PGP signature
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel