Re: [ovirt-devel] Dropping rpm build from ovirt-engine check-merged.sh

[Eyal Edri]

On Mon, Sep 19, 2016 at 6:49 PM, Vojtech Szocs  wrote:

>
>
> - Original Message -
> > From: "Sandro Bonazzola" 
> > To: "Eyal Edri" 
> > Cc: "Juan Hernandez" , "infra" ,
> "devel" 
> > Sent: Monday, September 19, 2016 8:41:12 AM
> > Subject: Re: [ovirt-devel] Dropping rpm build from ovirt-engine
>  check-merged.sh
> >
> >
> >
> > On Sun, Sep 18, 2016 at 4:18 PM, Eyal Edri < ee...@redhat.com > wrote:
> >
> >
> >
> > Hi,
> >
> > Following [1] I'd like to propose to remove rpm building from the
> > 'check-merged.sh' script from ovirt-engine (master for now).
> >
> > The job [2] takes on avg 15 min while actually the rpms are built
> already in
> > check-patch
> > (with gwt draft mode if needed) and runs exactly the same build rpm
> command
> > as check-patch [3].
> >
> > So there isn't real value in running exactly the same rpm build post
> merge,
> > and we already build full permutation mode in 'build-artifacts.sh'.
> >
> > Any reason to keep it?
> > We can cut down valuable time in CI if we drop it and vacant more time
> for
> > more meaningful tests.
> >
> >
> > This depends on the flow: if we make check_merge gating to the merge and
> to
> > the build we should keep the rpm build becuase at merge a rebase is done
> > automatically.
> > If there's not gating process performed by check-merge then I agree in
> > dropping rpm build.
>
> First of all, for oVirt Engine snapshot (non-release) builds, we should
> avoid doing a full GWT compilation [all browsers x all locales]. That's
> simply because the full GWT compilation is too costly for CI to run on
> a regular basis.
>

+1, It also makes us find regressions slower because it takes more than 1
hour to build + consume very valuable resource which is BM slave.


>
> Doing [Firefox + Chrome x English = 2 permutations] && [draft GWT build
> option enabled] for snapshot builds should be enough.
>
> The *only* downside of not doing a full GWT build is that problems with
> localization resources [e.g. non-English .properties files] will not be
> reported by the GWT compiler. But we have Java unit tests to cover this,
> so it should be OK. (And if not, we must improve those tests.)
>
> In general, we should do a full GWT compilation only for release builds.
> Eyal mentioned at [1] that his team is working on
>
>   'build official manual' option to standard CI
>

Already merged and working for most projects.who requested it, also part of
standard CI.


>
> so that would be a great place to document & perform the full GWT build.
>
> As for build jobs: if `check-merged` is indeed acting as gate for merge
> [fail of `check-merged` => patch not merged


its not the case today, we'll need to install Zuul for that, which is in
the plan (including system tests).


> , `build-artifacts` does not
> execute], then it actually makes sense to:
>
> - keep `check-merged` doing a (draft) GWT build + Engine RPM build
> - maybe skip GWT build in `check-patch` [right now, there's detection
>   logic => if frontend files were changed, do GWT build]
>
> Otherwise, if `check-merged` doesn't act as gate for merge, we can just
> skip GWT build / Engine RPM build for that script.
>

Yea, doesn't act as gate, it just run post merge.


>
> >
> >
> >
> >
> >
> >
> > [1] https://ovirt-jira.atlassian.net/browse/OVIRT-416
> > [2]
> > http://jenkins.ovirt.org/job/ovirt-engine_master_check-
> merged-el7-x86_64/buildTimeTrend
> > [3]
> > rpmbuild \
> > -D "_rpmdir $PWD/output" \
> > -D "_topmdir $PWD/rpmbuild" \
> > -D "release_suffix ${SUFFIX}" \
> > -D "ovirt_build_ut $BUILD_UT" \
> > -D "ovirt_build_extra_flags $EXTRA_BUILD_FLAGS" \
> > -D "ovirt_build_draft 1" \
> > --rebuild output/*.src.rpm
> >
> >
> > --
> > Eyal Edri
> > Associate Manager
> > RHV DevOps
> > EMEA ENG Virtualization R
> > Red Hat Israel
> >
> > phone: +972-9-7692018
> > irc: eedri (on #tlv #rhev-dev #rhev-integ)
> >
> >
> >
> > --
> > 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
>



-- 
Eyal Edri
Associate Manager
RHV 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

Re: [ovirt-devel] Dropping rpm build from ovirt-engine check-merged.sh

[Vojtech Szocs]

- Original Message -
> From: "Sandro Bonazzola" 
> To: "Eyal Edri" 
> Cc: "Juan Hernandez" , "infra" , 
> "devel" 
> Sent: Monday, September 19, 2016 8:41:12 AM
> Subject: Re: [ovirt-devel] Dropping rpm build from ovirt-engine   
> check-merged.sh
> 
> 
> 
> On Sun, Sep 18, 2016 at 4:18 PM, Eyal Edri < ee...@redhat.com > wrote:
> 
> 
> 
> Hi,
> 
> Following [1] I'd like to propose to remove rpm building from the
> 'check-merged.sh' script from ovirt-engine (master for now).
> 
> The job [2] takes on avg 15 min while actually the rpms are built already in
> check-patch
> (with gwt draft mode if needed) and runs exactly the same build rpm command
> as check-patch [3].
> 
> So there isn't real value in running exactly the same rpm build post merge,
> and we already build full permutation mode in 'build-artifacts.sh'.
> 
> Any reason to keep it?
> We can cut down valuable time in CI if we drop it and vacant more time for
> more meaningful tests.
> 
> 
> This depends on the flow: if we make check_merge gating to the merge and to
> the build we should keep the rpm build becuase at merge a rebase is done
> automatically.
> If there's not gating process performed by check-merge then I agree in
> dropping rpm build.

First of all, for oVirt Engine snapshot (non-release) builds, we should
avoid doing a full GWT compilation [all browsers x all locales]. That's
simply because the full GWT compilation is too costly for CI to run on
a regular basis.

Doing [Firefox + Chrome x English = 2 permutations] && [draft GWT build
option enabled] for snapshot builds should be enough.

The *only* downside of not doing a full GWT build is that problems with
localization resources [e.g. non-English .properties files] will not be
reported by the GWT compiler. But we have Java unit tests to cover this,
so it should be OK. (And if not, we must improve those tests.)

In general, we should do a full GWT compilation only for release builds.
Eyal mentioned at [1] that his team is working on

  'build official manual' option to standard CI

so that would be a great place to document & perform the full GWT build.

As for build jobs: if `check-merged` is indeed acting as gate for merge
[fail of `check-merged` => patch not merged, `build-artifacts` does not
execute], then it actually makes sense to:

- keep `check-merged` doing a (draft) GWT build + Engine RPM build
- maybe skip GWT build in `check-patch` [right now, there's detection
  logic => if frontend files were changed, do GWT build]

Otherwise, if `check-merged` doesn't act as gate for merge, we can just
skip GWT build / Engine RPM build for that script.

> 
> 
> 
> 
> 
> 
> [1] https://ovirt-jira.atlassian.net/browse/OVIRT-416
> [2]
> http://jenkins.ovirt.org/job/ovirt-engine_master_check-merged-el7-x86_64/buildTimeTrend
> [3]
> rpmbuild \
> -D "_rpmdir $PWD/output" \
> -D "_topmdir $PWD/rpmbuild" \
> -D "release_suffix ${SUFFIX}" \
> -D "ovirt_build_ut $BUILD_UT" \
> -D "ovirt_build_extra_flags $EXTRA_BUILD_FLAGS" \
> -D "ovirt_build_draft 1" \
> --rebuild output/*.src.rpm
> 
> 
> --
> Eyal Edri
> Associate Manager
> RHV DevOps
> EMEA ENG Virtualization R
> Red Hat Israel
> 
> phone: +972-9-7692018
> irc: eedri (on #tlv #rhev-dev #rhev-integ)
> 
> 
> 
> --
> 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] Proposing Martin Sivak as a Backend Maintainer for SLA & Scheduling

[Martin Perina]

On Mon, Sep 19, 2016 at 2:12 PM, Doron Fediuck  wrote:

> Hi All,
>
> Martin Sivak has been working on the oVirt engine since June 2013.
> His main focus over the years was around MoM, external scheduler, 
> hosted-engine, and
> related engine code.
>
> In the past year Martin took over many of the oVirt scheduler related work 
> and did a lot of improvements there. In total Martin has around 170 engine 
> patches already merged.
>
> Within these you will find improving the scheduler's notifications and error 
> handling, rewriting the pending resource mechanism which resolved many 
> issues, VM affinity, affinity labels and multiple improvements for our 
> scheduling policies and hosted engine.
>
> I would like to thank Martin for his great contribution and hope for many 
> more patches to come :)
>
> I would also like to propose Martin as an engine maintainer for SLA and 
> Scheduling.
>
>
​+1, well deserved!
​


> Thanks, Doron
>
>
>
> ___
> 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] Proposing Martin Sivak as a Backend Maintainer for SLA & Scheduling

[Martin Sivak]

Thank you all very much for your support.

Martin

On Mon, Sep 19, 2016 at 4:27 PM, Francesco Romani  wrote:
>
>
> 
>
> From: "Doron Fediuck" 
> To: "devel" 
> Sent: Monday, September 19, 2016 2:12:56 PM
> Subject: [ovirt-devel] Proposing Martin Sivak as a Backend Maintainer for
> SLA & Scheduling
>
> Hi All,
>
> Martin Sivak has been working on the oVirt engine since June 2013.
> His main focus over the years was around MoM, external scheduler,
> hosted-engine, and
> related engine code.
>
> In the past year Martin took over many of the oVirt scheduler related work
> and did a lot of improvements there. In total Martin has around 170 engine
> patches already merged.
>
> Within these you will find improving the scheduler's notifications and error
> handling, rewriting the pending resource mechanism which resolved many
> issues, VM affinity, affinity labels and multiple improvements for our
> scheduling policies and hosted engine.
>
> I would like to thank Martin for his great contribution and hope for many
> more patches to come :)
>
> I would also like to propose Martin as an engine maintainer for SLA and
> Scheduling.
>
>
> +1
>
>
> --
> Francesco Romani
> RedHat Engineering Virtualization R & D
> Phone: 8261328
> IRC: fromani
>
> ___
> 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] Proposing Martin Sivak as a Backend Maintainer for SLA & Scheduling

[Francesco Romani]

- Original Message -

> From: "Doron Fediuck" 
> To: "devel" 
> Sent: Monday, September 19, 2016 2:12:56 PM
> Subject: [ovirt-devel] Proposing Martin Sivak as a Backend Maintainer for SLA
> & Scheduling

> Hi All,

> Martin Sivak has been working on the oVirt engine since June 2013.
> His main focus over the years was around MoM, external scheduler,
> hosted-engine, and
> related engine code.
> In the past year Martin took over many of the oVirt scheduler related work
> and did a lot of improvements there. In total Martin has around 170 engine
> patches already merged.
> Within these you will find improving the scheduler's notifications and error
> handling, rewriting the pending resource mechanism which resolved many
> issues, VM affinity, affinity labels and multiple improvements for our
> scheduling policies and hosted engine.
> I would like to thank Martin for his great contribution and hope for many
> more patches to come :)

> I would also like to propose Martin as an engine maintainer for SLA and
> Scheduling.

+1 

-- 
Francesco Romani 
RedHat Engineering Virtualization R & D 
Phone: 8261328 
IRC: fromani 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Proposing Martin Sivak as a Backend Maintainer for SLA & Scheduling

[Doron Fediuck]

Thanks everyone for the vote of confidence.
I believe we have sufficient +1's from engine maintainers.

Congratulations Martin Sivak for becoming an engine maintainer for the SLA
& Scheduling!

Doron

On Mon, Sep 19, 2016 at 5:06 PM, Roman Mohr  wrote:

>
>
> On Mon, Sep 19, 2016 at 4:05 PM, Martin Betak  wrote:
>
>>
>>
>>
>>
>> - Original Message -
>> > From: "Arik Hadas" 
>> > To: "Doron Fediuck" 
>> > Cc: "devel" 
>> > Sent: Monday, September 19, 2016 3:52:53 PM
>> > Subject: Re: [ovirt-devel] Proposing Martin Sivak as a Backend
>> Maintainer for SLA & Scheduling
>> >
>> >
>> >
>> > - Original Message -
>> > >
>> > >
>> > > On Mon, Sep 19, 2016 at 3:07 PM, Roy Golan < rgo...@redhat.com >
>> wrote:
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > On 19 September 2016 at 15:12, Doron Fediuck < dfedi...@redhat.com >
>> wrote:
>> > >
>> > >
>> > >
>> > > Hi All,
>> > >
>> > > Martin Sivak has been working on the oVirt engine since June 2013.
>> > > His main focus over the years was around MoM, external scheduler,
>> > > hosted-engine, and
>> > > related engine code.
>> > > In the past year Martin took over many of the oVirt scheduler related
>> work
>> > > and did a lot of improvements there. In total Martin has around 170
>> engine
>> > > patches already merged.
>> > > Within these you will find improving the scheduler's notifications and
>> > > error
>> > > handling, rewriting the pending resource mechanism which resolved many
>> > > issues, VM affinity, affinity labels and multiple improvements for our
>> > > scheduling policies and hosted engine.
>> > > I would like to thank Martin for his great contribution and hope for
>> many
>> > > more patches to come :)
>> > >
>> > > I would also like to propose Martin as an engine maintainer for SLA
>> and
>> > > Scheduling.
>> > > Thanks, Doron
>> > >
>> > > +1 Actually +2 :)
>> > >
>> > > +1
>> >
>> > +1
>> >
>>
>> +1
>>
>
> +1
>
>
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > ___
>> > > Devel mailing list
>> > > Devel@ovirt.org
>> > > http://lists.ovirt.org/mailman/listinfo/devel
>> > >
>> > >
>> > > ___
>> > > Devel mailing list
>> > > Devel@ovirt.org
>> > > http://lists.ovirt.org/mailman/listinfo/devel
>> > >
>> > >
>> > > ___
>> > > Devel mailing list
>> > > Devel@ovirt.org
>> > > http://lists.ovirt.org/mailman/listinfo/devel
>> > ___
>> > Devel mailing list
>> > Devel@ovirt.org
>> > http://lists.ovirt.org/mailman/listinfo/devel
>> >
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Proposing Martin Sivak as a Backend Maintainer for SLA & Scheduling

[Roman Mohr]

On Mon, Sep 19, 2016 at 4:05 PM, Martin Betak  wrote:

>
>
>
>
> - Original Message -
> > From: "Arik Hadas" 
> > To: "Doron Fediuck" 
> > Cc: "devel" 
> > Sent: Monday, September 19, 2016 3:52:53 PM
> > Subject: Re: [ovirt-devel] Proposing Martin Sivak as a Backend
> Maintainer for SLA & Scheduling
> >
> >
> >
> > - Original Message -
> > >
> > >
> > > On Mon, Sep 19, 2016 at 3:07 PM, Roy Golan < rgo...@redhat.com >
> wrote:
> > >
> > >
> > >
> > >
> > >
> > > On 19 September 2016 at 15:12, Doron Fediuck < dfedi...@redhat.com >
> wrote:
> > >
> > >
> > >
> > > Hi All,
> > >
> > > Martin Sivak has been working on the oVirt engine since June 2013.
> > > His main focus over the years was around MoM, external scheduler,
> > > hosted-engine, and
> > > related engine code.
> > > In the past year Martin took over many of the oVirt scheduler related
> work
> > > and did a lot of improvements there. In total Martin has around 170
> engine
> > > patches already merged.
> > > Within these you will find improving the scheduler's notifications and
> > > error
> > > handling, rewriting the pending resource mechanism which resolved many
> > > issues, VM affinity, affinity labels and multiple improvements for our
> > > scheduling policies and hosted engine.
> > > I would like to thank Martin for his great contribution and hope for
> many
> > > more patches to come :)
> > >
> > > I would also like to propose Martin as an engine maintainer for SLA and
> > > Scheduling.
> > > Thanks, Doron
> > >
> > > +1 Actually +2 :)
> > >
> > > +1
> >
> > +1
> >
>
> +1
>

+1


> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > ___
> > > Devel mailing list
> > > Devel@ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/devel
> > >
> > >
> > > ___
> > > Devel mailing list
> > > Devel@ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/devel
> > >
> > >
> > > ___
> > > 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] Proposing Martin Sivak as a Backend Maintainer for SLA & Scheduling

[Arik Hadas]

- Original Message -
> 
> 
> On Mon, Sep 19, 2016 at 3:07 PM, Roy Golan < rgo...@redhat.com > wrote:
> 
> 
> 
> 
> 
> On 19 September 2016 at 15:12, Doron Fediuck < dfedi...@redhat.com > wrote:
> 
> 
> 
> Hi All,
> 
> Martin Sivak has been working on the oVirt engine since June 2013.
> His main focus over the years was around MoM, external scheduler,
> hosted-engine, and
> related engine code.
> In the past year Martin took over many of the oVirt scheduler related work
> and did a lot of improvements there. In total Martin has around 170 engine
> patches already merged.
> Within these you will find improving the scheduler's notifications and error
> handling, rewriting the pending resource mechanism which resolved many
> issues, VM affinity, affinity labels and multiple improvements for our
> scheduling policies and hosted engine.
> I would like to thank Martin for his great contribution and hope for many
> more patches to come :)
> 
> I would also like to propose Martin as an engine maintainer for SLA and
> Scheduling.
> Thanks, Doron
> 
> +1 Actually +2 :)
> 
> +1

+1

> 
> 
> 
> 
> 
> 
> 
> 
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
> 
> 
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
> 
> 
> ___
> 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] Proposing Martin Sivak as a Backend Maintainer for SLA & Scheduling

[Martin Betak]

- Original Message -
> From: "Arik Hadas" 
> To: "Doron Fediuck" 
> Cc: "devel" 
> Sent: Monday, September 19, 2016 3:52:53 PM
> Subject: Re: [ovirt-devel] Proposing Martin Sivak as a Backend Maintainer for 
> SLA & Scheduling
> 
> 
> 
> - Original Message -
> > 
> > 
> > On Mon, Sep 19, 2016 at 3:07 PM, Roy Golan < rgo...@redhat.com > wrote:
> > 
> > 
> > 
> > 
> > 
> > On 19 September 2016 at 15:12, Doron Fediuck < dfedi...@redhat.com > wrote:
> > 
> > 
> > 
> > Hi All,
> > 
> > Martin Sivak has been working on the oVirt engine since June 2013.
> > His main focus over the years was around MoM, external scheduler,
> > hosted-engine, and
> > related engine code.
> > In the past year Martin took over many of the oVirt scheduler related work
> > and did a lot of improvements there. In total Martin has around 170 engine
> > patches already merged.
> > Within these you will find improving the scheduler's notifications and
> > error
> > handling, rewriting the pending resource mechanism which resolved many
> > issues, VM affinity, affinity labels and multiple improvements for our
> > scheduling policies and hosted engine.
> > I would like to thank Martin for his great contribution and hope for many
> > more patches to come :)
> > 
> > I would also like to propose Martin as an engine maintainer for SLA and
> > Scheduling.
> > Thanks, Doron
> > 
> > +1 Actually +2 :)
> > 
> > +1
> 
> +1
> 

+1
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > ___
> > Devel mailing list
> > Devel@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
> > 
> > 
> > ___
> > Devel mailing list
> > Devel@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
> > 
> > 
> > ___
> > 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] Proposing Martin Sivak as a Backend Maintainer for SLA & Scheduling

[Simone Tiraboschi]

On Mon, Sep 19, 2016 at 3:07 PM, Roy Golan  wrote:

>
>
> On 19 September 2016 at 15:12, Doron Fediuck  wrote:
>
>> Hi All,
>>
>> Martin Sivak has been working on the oVirt engine since June 2013.
>> His main focus over the years was around MoM, external scheduler, 
>> hosted-engine, and
>> related engine code.
>>
>> In the past year Martin took over many of the oVirt scheduler related work 
>> and did a lot of improvements there. In total Martin has around 170 engine 
>> patches already merged.
>>
>> Within these you will find improving the scheduler's notifications and error 
>> handling, rewriting the pending resource mechanism which resolved many 
>> issues, VM affinity, affinity labels and multiple improvements for our 
>> scheduling policies and hosted engine.
>>
>> I would like to thank Martin for his great contribution and hope for many 
>> more patches to come :)
>>
>> I would also like to propose Martin as an engine maintainer for SLA and 
>> Scheduling.
>>
>> Thanks, Doron
>>
>>
> +1 Actually +2 :)
>

+1


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

Re: [ovirt-devel] Proposing Martin Sivak as a Backend Maintainer for SLA & Scheduling

[Roy Golan]

On 19 September 2016 at 15:12, Doron Fediuck  wrote:

> Hi All,
>
> Martin Sivak has been working on the oVirt engine since June 2013.
> His main focus over the years was around MoM, external scheduler, 
> hosted-engine, and
> related engine code.
>
> In the past year Martin took over many of the oVirt scheduler related work 
> and did a lot of improvements there. In total Martin has around 170 engine 
> patches already merged.
>
> Within these you will find improving the scheduler's notifications and error 
> handling, rewriting the pending resource mechanism which resolved many 
> issues, VM affinity, affinity labels and multiple improvements for our 
> scheduling policies and hosted engine.
>
> I would like to thank Martin for his great contribution and hope for many 
> more patches to come :)
>
> I would also like to propose Martin as an engine maintainer for SLA and 
> Scheduling.
>
> Thanks, Doron
>
>
+1 Actually +2 :)


>
> ___
> 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] Proposing Martin Sivak as a Backend Maintainer for SLA & Scheduling

[Doron Fediuck]

On Mon, Sep 19, 2016 at 4:00 PM, Eyal Edri  wrote:

> +1 indeed.
> I guess Martin should get merge rights for master branch on ovirt-engine
> pending approval of the proposal?
>
> Yes, this is true.


> On Sep 19, 2016 3:30 PM, "Doron Fediuck"  wrote:
>
>>
>>
>> On Mon, Sep 19, 2016 at 3:25 PM, Sandro Bonazzola 
>> wrote:
>>
>>>
>>>
>>> On Mon, Sep 19, 2016 at 2:12 PM, Doron Fediuck 
>>> wrote:
>>>
 Hi All,

 Martin Sivak has been working on the oVirt engine since June 2013.
 His main focus over the years was around MoM, external scheduler, 
 hosted-engine, and
 related engine code.

 In the past year Martin took over many of the oVirt scheduler related work 
 and did a lot of improvements there. In total Martin has around 170 engine 
 patches already merged.

 Within these you will find improving the scheduler's notifications and 
 error handling, rewriting the pending resource mechanism which resolved 
 many issues, VM affinity, affinity labels and multiple improvements for 
 our scheduling policies and hosted engine.

 I would like to thank Martin for his great contribution and hope for many 
 more patches to come :)

 I would also like to propose Martin as an engine maintainer for SLA and 
 Scheduling.

 +1 for me; Just a question, who will be main contact for SLA? I see Roy
>>> is also maintainer for SLA in ovirt engine.
>>>
>>> Martin will be the main contact.
>>
>>
>>>
>>>
 Thanks, Doron



 ___
 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] Proposing Martin Sivak as a Backend Maintainer for SLA & Scheduling

[Eyal Edri]

+1 indeed.
I guess Martin should get merge rights for master branch on ovirt-engine
pending approval of the proposal?

On Sep 19, 2016 3:30 PM, "Doron Fediuck"  wrote:

>
>
> On Mon, Sep 19, 2016 at 3:25 PM, Sandro Bonazzola 
> wrote:
>
>>
>>
>> On Mon, Sep 19, 2016 at 2:12 PM, Doron Fediuck 
>> wrote:
>>
>>> Hi All,
>>>
>>> Martin Sivak has been working on the oVirt engine since June 2013.
>>> His main focus over the years was around MoM, external scheduler, 
>>> hosted-engine, and
>>> related engine code.
>>>
>>> In the past year Martin took over many of the oVirt scheduler related work 
>>> and did a lot of improvements there. In total Martin has around 170 engine 
>>> patches already merged.
>>>
>>> Within these you will find improving the scheduler's notifications and 
>>> error handling, rewriting the pending resource mechanism which resolved 
>>> many issues, VM affinity, affinity labels and multiple improvements for our 
>>> scheduling policies and hosted engine.
>>>
>>> I would like to thank Martin for his great contribution and hope for many 
>>> more patches to come :)
>>>
>>> I would also like to propose Martin as an engine maintainer for SLA and 
>>> Scheduling.
>>>
>>> +1 for me; Just a question, who will be main contact for SLA? I see Roy
>> is also maintainer for SLA in ovirt engine.
>>
>> Martin will be the main contact.
>
>
>>
>>
>>> Thanks, Doron
>>>
>>>
>>>
>>> ___
>>> 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

[ovirt-devel] oVirt 4.0.4 RC4 merge / branch / tag / bugzilla reminder

[Sandro Bonazzola]

All stable branch maintainers, please make sure to

   - merge all relevant open bugs until Tuesday morning 11:00 AM TLV time.


For each package that need to be built (i.e oVirt product) please make sure
every bug in MODIFIED has the right Target Release and Target Milestone.
A Target release should state the version of the package you're building
and should include the same version you used for the tag you just used for
this build. (e.g. for ovirt-engine, tag: ovirt-engine-4.0.4.4, tr: 4.0.4.4)
A list of bugs that require attention is here:

   -
   
https://bugzilla.redhat.com/buglist.cgi?quicksearch=target_milestone%3A4.0.4%20target_release%3A---%20status%3Amodified%2Cpost


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

[ovirt-devel] oVirt 4.0.4 RC4 build planned

[Sandro Bonazzola]

Fyi oVirt developers,

An oVirt build is planned for this Tuesday 10:00 AM TLV time (9:00 AM CEST).
Taking into consideration the time it takes for Jenkins to run a full CI
everything need to be backported by Monday 11PM.
Please make sure to mark as verified and CR +2 so it will be ready for
merging Tuesday morning.

A list of pending blockers is available here:
https://bugzilla.redhat.com/buglist.cgi?quicksearch=target_milestone%3A4.0.4%20flag%3Ablocker%20status%3Anew%2Cassigned%2Cpost

-- 
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] Proposing Martin Sivak as a Backend Maintainer for SLA & Scheduling

[Doron Fediuck]

On Mon, Sep 19, 2016 at 3:25 PM, Sandro Bonazzola 
wrote:

>
>
> On Mon, Sep 19, 2016 at 2:12 PM, Doron Fediuck 
> wrote:
>
>> Hi All,
>>
>> Martin Sivak has been working on the oVirt engine since June 2013.
>> His main focus over the years was around MoM, external scheduler, 
>> hosted-engine, and
>> related engine code.
>>
>> In the past year Martin took over many of the oVirt scheduler related work 
>> and did a lot of improvements there. In total Martin has around 170 engine 
>> patches already merged.
>>
>> Within these you will find improving the scheduler's notifications and error 
>> handling, rewriting the pending resource mechanism which resolved many 
>> issues, VM affinity, affinity labels and multiple improvements for our 
>> scheduling policies and hosted engine.
>>
>> I would like to thank Martin for his great contribution and hope for many 
>> more patches to come :)
>>
>> I would also like to propose Martin as an engine maintainer for SLA and 
>> Scheduling.
>>
>> +1 for me; Just a question, who will be main contact for SLA? I see Roy
> is also maintainer for SLA in ovirt engine.
>
> Martin will be the main contact.


>
>
>> Thanks, Doron
>>
>>
>>
>> ___
>> 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] Proposing Martin Sivak as a Backend Maintainer for SLA & Scheduling

[Sandro Bonazzola]

On Mon, Sep 19, 2016 at 2:12 PM, Doron Fediuck  wrote:

> Hi All,
>
> Martin Sivak has been working on the oVirt engine since June 2013.
> His main focus over the years was around MoM, external scheduler, 
> hosted-engine, and
> related engine code.
>
> In the past year Martin took over many of the oVirt scheduler related work 
> and did a lot of improvements there. In total Martin has around 170 engine 
> patches already merged.
>
> Within these you will find improving the scheduler's notifications and error 
> handling, rewriting the pending resource mechanism which resolved many 
> issues, VM affinity, affinity labels and multiple improvements for our 
> scheduling policies and hosted engine.
>
> I would like to thank Martin for his great contribution and hope for many 
> more patches to come :)
>
> I would also like to propose Martin as an engine maintainer for SLA and 
> Scheduling.
>
> +1 for me; Just a question, who will be main contact for SLA? I see Roy is
also maintainer for SLA in ovirt engine.



> Thanks, Doron
>
>
>
> ___
> 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] Best (and up-to-date) practices for developers?

[Martin Betak]

Yeah definitely +1.

Even after being with the project for some time, I often wonder about things
like in what order should fields in class be based on their function (as in
logger, static sonstants, @Injected dependencies, actual instance fields...)
so such document could answer questions like this (that are not encoded in 
existing checkstyle rules) or provide general high-level guidance throughout
the code base - at least for things that don't change that much. For example
I believe that the process to invoke a command (or a query) from the Backend 
via the VdcActionType, CommandFactory .etc hasn't changed that much, 
and probably won't change in the foreseeable future :-)

Martin B.

- Original Message -
> From: "Phillip Bailey" 
> To: "Martin Sivak" 
> Cc: "engine-de...@ovirt.org" 
> Sent: Monday, September 19, 2016 1:54:23 PM
> Subject: Re: [ovirt-devel] Best (and up-to-date) practices for developers?
> 
> +1 for the idea if it doesn't already exist. It would ease development for
> those already working on the project, but it would also make it easier for
> others who would like to contribute to it, but aren't comfortable with
> navigating such a large code base.
> 
> -Phillip Bailey
> 
> On Mon, Sep 19, 2016 at 3:56 AM, Martin Sivak < msi...@redhat.com > wrote:
> 
> 
> Hi,
> 
> I just wanted to find out if we have some documentation for the
> developers that would give hint on different aspects of the engine
> development in terms of coding.
> 
> Like:
> - code style (we have the config in sources)
> - what libraries are (not) allowed (guava..ehm..)
> - how should CDI be used (see https://gerrit.ovirt.org/#/c/63747/ )
> - what files need to be touched to properly support translations
> - ...
> 
> 
> It would be cool to have something brief we can search easily. I know
> it can get outdated fast, but if we use it only for the important
> stuff and review it for each major release (as the major rules do not
> change much) we should be able to keep it usable.
> 
> --
> Martin Sivák
> SLA / oVirt
> ___
> 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] Best (and up-to-date) practices for developers?

[Phillip Bailey]

+1 for the idea if it doesn't already exist. It would ease development for
those already working on the project, but it would also make it easier for
others who would like to contribute to it, but aren't comfortable with
navigating such a large code base.

-Phillip Bailey

On Mon, Sep 19, 2016 at 3:56 AM, Martin Sivak  wrote:

> Hi,
>
> I just wanted to find out if we have some documentation for the
> developers that would give hint on different aspects of the engine
> development in terms of coding.
>
> Like:
> - code style (we have the config in sources)
> - what libraries are (not) allowed (guava..ehm..)
> - how should CDI be used (see https://gerrit.ovirt.org/#/c/63747/)
> - what files need to be touched to properly support translations
> - ...
>
>
> It would be cool to have something brief we can search easily. I know
> it can get outdated fast, but if we use it only for the important
> stuff and review it for each major release (as the major rules do not
> change much) we should be able to keep it usable.
>
> --
> Martin Sivák
> SLA / oVirt
> ___
> 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] Reporting vm disk stats "truesize" and "apparentsize"?

[Michal Skrivanek]

> On 18 Sep 2016, at 18:16, Nir Soffer  wrote:
> 
> On Sat, Sep 17, 2016 at 3:14 AM, Nir Soffer  > wrote:
> On Fri, Sep 16, 2016 at 10:49 AM, Michal Skrivanek 
> > wrote:
> 
> > On 15 Sep 2016, at 18:18, Nir Soffer  > > wrote:
> >
> > Hi all,
> >
> > Vdsm reports apparentsize and truesize disk stats [1] when getting
> > vms stats (every 15 seconds?). These values are update every
> > 60 seconds in vdsm.
> >
> > To collect the values, we run risky storage apis in vdsm virt thread
> > pool, and we want to avoid this [2] since one slow or broken domain
> > can cause the entire virt thread pool to get stuck and cause vms
> > using other (healthy) storage domain to become non responsive.
> >
> > These can also break block storage thin provisioned disks, since they
> > depend also on the virt thread pool. So one bad NFS storage domain
> > can cause vms using only block storage to be paused.
> >
> > If both of these values are not used by anyone, we would like to
> > stop reporting them.
> 
> there are only 2 consumers of the monitoring, engine and mom.
> git grep reveals that “apparentsize" is used only for importing HE.
> “truesize" too, but additionally it is used in engine storage code as an 
> actual size of the disk
> 
> >
> > If the values are used, we need to find a safer way to report them,
> > probably in storage thread pool, or maybe we can get these values
> > from libvirt using bulk sampling.
> 
> you could have been able to drop apparentsize right away, but the HE import 
> code is expecting that field and won’t be happy if it is missing
> The monitoring code would work but fill in 0 for the actual size
> 
> Returning always 0 can be nice prank for the storage team :-)

what about that apparentsize? that seems to be unused except for HE import

> 
> Looking in bulk stats, we already have the required info from libvirt:
> 
>  {'bcfa00d3-78a7-40c9-990e-5ffac8886ce0': {'balloon.current': 1048576L,
>   'balloon.maximum': 1048576L,
>   'block.0.allocation': 0L,
>   'block.0.fl.reqs': 0L,
>   'block.0.fl.times': 0L,
>   'block.0.name 
> ': 'hdc',
>   'block.0.physical': 0L,
>   'block.0.rd.bytes': 152L,
>   'block.0.rd.reqs': 4L,
>   'block.0.rd.times': 539801L,
>   'block.0.wr.bytes': 0L,
>   'block.0.wr.reqs': 0L,
>   'block.0.wr.times': 0L,
>   'block.1.allocation': 131005952L,
>   'block.1.capacity': 8589934592L,
>   'block.1.fl.reqs': 68L,
>   'block.1.fl.times': 1894725112L,
>   'block.1.name 
> ': 'vda',
>   'block.1.path': 
> '/rhev/data-center/f9374c0e-ae24-4bc1-a596-f61d5f05bc5f/5f35b5c0-17d7-4475-9125-e97f1cdb06f9/images/c54e7894-b1dc-4f23-9ff5-1836259adc6d/133db162-6c6a-4e82-baae-9ae0e7e3885d',
>   'block.1.physical': 1073741824L,
>   'block.1.rd.bytes': 123849728L,
>   'block.1.rd.reqs': 7979L,
>   'block.1.rd.times': 10655381303L,
>   'block.1.wr.bytes': 16762880L,
>   'block.1.wr.reqs': 455L,
>   'block.1.wr.times': 6021639149L,
>   'block.2.allocation': 0L,
>   'block.2.capacity': 21474836480L,
>   'block.2.fl.reqs': 0L,
>   'block.2.fl.times': 0L,
>   'block.2.name 
> ': 'vdb',
>   'block.2.path': 
> '/rhev/data-center/f9374c0e-ae24-4bc1-a596-f61d5f05bc5f/bb85ee2f-d674-489f-9377-3eb1f176e8fb/images/b59304f3-d19d-40dd-9f04-8c2df37ef6d3/4df47a96-8a1b-436e-8a3e-3a638f119b48',
>   'block.2.physical': 21474836480L,
>   'block.2.rd.bytes': 1389056L,
>   'block.2.rd.reqs': 331L,
> 

[ovirt-devel] Best (and up-to-date) practices for developers?

[Martin Sivak]

Hi,

I just wanted to find out if we have some documentation for the
developers that would give hint on different aspects of the engine
development in terms of coding.

Like:
- code style (we have the config in sources)
- what libraries are (not) allowed (guava..ehm..)
- how should CDI be used (see https://gerrit.ovirt.org/#/c/63747/)
- what files need to be touched to properly support translations
- ...


It would be cool to have something brief we can search easily. I know
it can get outdated fast, but if we use it only for the important
stuff and review it for each major release (as the major rules do not
change much) we should be able to keep it usable.

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

Re: [ovirt-devel] Dropping rpm build from ovirt-engine check-merged.sh

[Sandro Bonazzola]

On Sun, Sep 18, 2016 at 4:18 PM, Eyal Edri  wrote:

> Hi,
>
> Following [1] I'd like to propose to remove rpm building from the
> 'check-merged.sh' script from ovirt-engine (master for now).
>
> The job [2] takes on avg 15 min while actually the rpms are built already
> in check-patch
> (with gwt draft mode if needed) and runs exactly the same build rpm
> command as check-patch [3].
>
> So there isn't real value in running exactly the same rpm build post
> merge, and we already build full permutation mode in 'build-artifacts.sh'.
>
> Any reason to keep it?
> We can cut down valuable time in CI if we drop it and vacant more time for
> more meaningful tests.
>


This depends on the flow: if we make check_merge gating to the merge and to
the build we should keep the rpm build becuase at merge a rebase is done
automatically.
If there's not gating process performed by check-merge then I agree in
dropping rpm build.



>
>
> [1] https://ovirt-jira.atlassian.net/browse/OVIRT-416
> [2] http://jenkins.ovirt.org/job/ovirt-engine_master_check-
> merged-el7-x86_64/buildTimeTrend
> [3]
> rpmbuild \
> -D "_rpmdir $PWD/output" \
> -D "_topmdir $PWD/rpmbuild" \
> -D "release_suffix ${SUFFIX}" \
> -D "ovirt_build_ut $BUILD_UT" \
> -D "ovirt_build_extra_flags $EXTRA_BUILD_FLAGS" \
> -D "ovirt_build_draft 1" \
> --rebuild output/*.src.rpm
>
>
> --
> Eyal Edri
> Associate Manager
> RHV DevOps
> EMEA ENG Virtualization R
> Red Hat Israel
>
> phone: +972-9-7692018
> irc: eedri (on #tlv #rhev-dev #rhev-integ)
>



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