[oVirt Jenkins] ovirt-engine_master_upgrade-from-4.0_el7_merged - Build # 102 - Failure!

[jenkins]

Project: 
http://jenkins.ovirt.org/job/ovirt-engine_master_upgrade-from-4.0_el7_merged/ 
Build: 
http://jenkins.ovirt.org/job/ovirt-engine_master_upgrade-from-4.0_el7_merged/102/
Build Number: 102
Build Status:  Failure
Triggered By: Triggered by Gerrit: https://gerrit.ovirt.org/58228

-
Changes Since Last Success:
-
Changes for Build #102
[Yevgeny Zaspitsky] engine: Skip configuring IPv6 on mgmt network upon host 
install




-
Failed Tests:
-
No tests ran. 

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

Jenkins build is back to stable : ovirt_4.0_publish-rpms_nightly #22

[jenkins]

See 

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

Jenkins build is back to stable : ovirt_master_publish-rpms_nightly #76

[jenkins]

See 

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

Re: PHX updates - hypervisors in Jenkins datacenter

[Evgheni Dereveanchin]

Status update:
ovirt-srv05 rebuilt and back in production.

Network bonding fixed on ovirt-srv17 and ovirt-srv18.
ovirt-srv11 updated to CentOS 7.2.

Currently bonding is being fixed on ovirt-srv01, 
ovirt-srv11 and ovirt-srv14. After that is complete, 
will proceed with rebuilding ovirt-srv06 and ovirt-srv07
which are the last F20 hosts in the Jenkins cluster.

Regards, 
Evgheni Dereveanchin 

- Original Message -
From: "Evgheni Dereveanchin" 
To: "infra" 
Sent: Friday, 3 June, 2016 4:42:41 PM
Subject: Re: PHX updates - hypervisors in Jenkins datacenter

Status update: ovirt-srv12 and ovirt-srv13 updated
to CentOS 7.2, will now rebuild ovirt-srv05 which
is currently in Maintenance and has no VMs running.
Please ignore monitoring alerts for this host if any.

Regards, 
Evgheni Dereveanchin 

- Original Message -
From: "Evgheni Dereveanchin" 
To: "Barak Korren" 
Cc: "infra" 
Sent: Friday, 3 June, 2016 11:32:25 AM
Subject: Re: PHX updates - hypervisors in Jenkins datacenter

Right, sorry for the typo :)
It's up and running now with EL7.2 and vdsm 4.16.30.
I will now update ovirt-srv12 and ovirt-srv13 from
7.1 to 7.2 and then proceed to reprovisioning the
remaining F20 hosts in the old cluster.


Regards, 
Evgheni Dereveanchin 

- Original Message -
From: "Barak Korren" 
To: "Evgheni Dereveanchin" 
Cc: "infra" 
Sent: Friday, 3 June, 2016 11:29:02 AM
Subject: Re: PHX updates - hypervisors in Jenkins datacenter

el7 (i hate phone keyboards)
בתאריך 3 ביוני 2016 12:28,‏ "Barak Korren"  כתב:

>
> בתאריך 2 ביוני 2016 20:00,‏ "Evgheni Dereveanchin" 
> כתב:
> >
> > Status update: ovirt-srv04 was rebuilt with EL6.
>
> You meant elu right?
>
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: 4.0 branch rights

[David Caro Estevez]

Already sent and merged, you should now have all the jobs running for 4.0 
branch too

- Original Message -
> From: "David Caro Estevez" 
> To: "Eyal Edri" 
> Cc: "Francesco Romani" , "infra" 
> Sent: Tuesday, June 7, 2016 3:08:30 PM
> Subject: Re: 4.0 branch rights
> 
> Sure, all you have to do is edit the file
> jobs/confs/projects/vdsm/vdsm_standard.yaml in the jenkins repo, and add
> there a version '4.0' with the branch ovirt-4.0 on each of the three
> projects defined there, for example for the first one:
> 
> 
> - project:
> <<: *vdsm_standard_common
> name: vdsm_build-artifacts
> version:
>   - master:
>   branch: master
>   - 3.6:
>   branch: ovirt-3.6
>   - 4.0:
>   branch: ovirt-4.0
> stage: build-artifacts
> distro:
>   - el7
>   - fc23
>   - fc22
> exclude:
>   - version: master
> distro: fc22
> 
> 
> - Original Message -
> > From: "Eyal Edri" 
> > To: "Francesco Romani" 
> > Cc: "David Caro Estevez" , "infra" 
> > Sent: Tuesday, June 7, 2016 3:03:33 PM
> > Subject: Re: 4.0 branch rights
> > 
> > David, can you help with sending a patch to add 4.0 jobs for vdsm?
> > 
> > On Tue, Jun 7, 2016 at 3:54 PM, Francesco Romani 
> > wrote:
> > 
> > > - Original Message -
> > > > From: "David Caro Estevez" 
> > > > To: "Francesco Romani" 
> > > > Cc: "Yaniv Bronheim" , "infra" 
> > > > Sent: Tuesday, June 7, 2016 11:10:32 AM
> > > > Subject: Re: 4.0 branch rights
> > > >
> > > > The automated ci is added on jenkins, not related to gerrit permissions
> > > or
> > > > hooks
> > >
> > > Right! Who should I ask for help about that?
> > >
> > > Thanks,
> > >
> > >
> > > --
> > > Francesco Romani
> > > RedHat Engineering Virtualization R & D
> > > Phone: 8261328
> > > IRC: fromani
> > > ___
> > > Infra mailing list
> > > Infra@ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/infra
> > >
> > >
> > >
> > 
> > 
> > --
> > Eyal Edri
> > Associate Manager
> > RHEV DevOps
> > EMEA ENG Virtualization R&D
> > Red Hat Israel
> > 
> > phone: +972-9-7692018
> > irc: eedri (on #tlv #rhev-dev #rhev-integ)
> > 
> 
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: 4.0 branch rights

[Francesco Romani]

Thank you both for your help and quick response, this is much appreciated.

Bests,

- Original Message -
> From: "David Caro Estevez" 
> To: "Eyal Edri" 
> Cc: "Francesco Romani" , "infra" 
> Sent: Tuesday, June 7, 2016 3:28:59 PM
> Subject: Re: 4.0 branch rights
> 
> Already sent and merged, you should now have all the jobs running for 4.0
> branch too
> 
> - Original Message -
> > From: "David Caro Estevez" 
> > To: "Eyal Edri" 
> > Cc: "Francesco Romani" , "infra" 
> > Sent: Tuesday, June 7, 2016 3:08:30 PM
> > Subject: Re: 4.0 branch rights
> > 
> > Sure, all you have to do is edit the file
> > jobs/confs/projects/vdsm/vdsm_standard.yaml in the jenkins repo, and add
> > there a version '4.0' with the branch ovirt-4.0 on each of the three
> > projects defined there, for example for the first one:
> > 
> > 
> > - project:
> > <<: *vdsm_standard_common
> > name: vdsm_build-artifacts
> > version:
> >   - master:
> >   branch: master
> >   - 3.6:
> >   branch: ovirt-3.6
> >   - 4.0:
> >   branch: ovirt-4.0
> > stage: build-artifacts
> > distro:
> >   - el7
> >   - fc23
> >   - fc22
> > exclude:
> >   - version: master
> > distro: fc22
> > 
> > 
> > - Original Message -
> > > From: "Eyal Edri" 
> > > To: "Francesco Romani" 
> > > Cc: "David Caro Estevez" , "infra" 
> > > Sent: Tuesday, June 7, 2016 3:03:33 PM
> > > Subject: Re: 4.0 branch rights
> > > 
> > > David, can you help with sending a patch to add 4.0 jobs for vdsm?
> > > 
> > > On Tue, Jun 7, 2016 at 3:54 PM, Francesco Romani 
> > > wrote:
> > > 
> > > > - Original Message -
> > > > > From: "David Caro Estevez" 
> > > > > To: "Francesco Romani" 
> > > > > Cc: "Yaniv Bronheim" , "infra" 
> > > > > Sent: Tuesday, June 7, 2016 11:10:32 AM
> > > > > Subject: Re: 4.0 branch rights
> > > > >
> > > > > The automated ci is added on jenkins, not related to gerrit
> > > > > permissions
> > > > or
> > > > > hooks
> > > >
> > > > Right! Who should I ask for help about that?
> > > >
> > > > Thanks,
> > > >
> > > >
> > > > --
> > > > Francesco Romani
> > > > RedHat Engineering Virtualization R & D
> > > > Phone: 8261328
> > > > IRC: fromani
> > > > ___
> > > > Infra mailing list
> > > > Infra@ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/infra
> > > >
> > > >
> > > >
> > > 
> > > 
> > > --
> > > Eyal Edri
> > > Associate Manager
> > > RHEV DevOps
> > > EMEA ENG Virtualization R&D
> > > Red Hat Israel
> > > 
> > > phone: +972-9-7692018
> > > irc: eedri (on #tlv #rhev-dev #rhev-integ)
> > > 
> > 
> 

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

Re: 4.0 branch rights

[David Caro Estevez]

Sure, all you have to do is edit the file 
jobs/confs/projects/vdsm/vdsm_standard.yaml in the jenkins repo, and add there 
a version '4.0' with the branch ovirt-4.0 on each of the three projects defined 
there, for example for the first one:


- project:
<<: *vdsm_standard_common
name: vdsm_build-artifacts
version:
  - master:
  branch: master
  - 3.6:
  branch: ovirt-3.6
  - 4.0:
  branch: ovirt-4.0
stage: build-artifacts
distro:
  - el7
  - fc23
  - fc22
exclude:
  - version: master
distro: fc22


- Original Message -
> From: "Eyal Edri" 
> To: "Francesco Romani" 
> Cc: "David Caro Estevez" , "infra" 
> Sent: Tuesday, June 7, 2016 3:03:33 PM
> Subject: Re: 4.0 branch rights
> 
> David, can you help with sending a patch to add 4.0 jobs for vdsm?
> 
> On Tue, Jun 7, 2016 at 3:54 PM, Francesco Romani  wrote:
> 
> > - Original Message -
> > > From: "David Caro Estevez" 
> > > To: "Francesco Romani" 
> > > Cc: "Yaniv Bronheim" , "infra" 
> > > Sent: Tuesday, June 7, 2016 11:10:32 AM
> > > Subject: Re: 4.0 branch rights
> > >
> > > The automated ci is added on jenkins, not related to gerrit permissions
> > or
> > > hooks
> >
> > Right! Who should I ask for help about that?
> >
> > Thanks,
> >
> >
> > --
> > Francesco Romani
> > RedHat Engineering Virtualization R & D
> > Phone: 8261328
> > IRC: fromani
> > ___
> > Infra mailing list
> > Infra@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
> >
> >
> >
> 
> 
> --
> Eyal Edri
> Associate Manager
> RHEV DevOps
> EMEA ENG Virtualization R&D
> Red Hat Israel
> 
> phone: +972-9-7692018
> irc: eedri (on #tlv #rhev-dev #rhev-integ)
> 
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: 4.0 branch rights

[Eyal Edri]

David, can you help with sending a patch to add 4.0 jobs for vdsm?

On Tue, Jun 7, 2016 at 3:54 PM, Francesco Romani  wrote:

> - Original Message -
> > From: "David Caro Estevez" 
> > To: "Francesco Romani" 
> > Cc: "Yaniv Bronheim" , "infra" 
> > Sent: Tuesday, June 7, 2016 11:10:32 AM
> > Subject: Re: 4.0 branch rights
> >
> > The automated ci is added on jenkins, not related to gerrit permissions
> or
> > hooks
>
> Right! Who should I ask for help about that?
>
> Thanks,
>
>
> --
> Francesco Romani
> RedHat Engineering Virtualization R & D
> Phone: 8261328
> IRC: fromani
> ___
> Infra mailing list
> Infra@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
>
>
>


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

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

Re: 4.0 branch rights

[Francesco Romani]

- Original Message -
> From: "David Caro Estevez" 
> To: "Francesco Romani" 
> Cc: "Yaniv Bronheim" , "infra" 
> Sent: Tuesday, June 7, 2016 11:10:32 AM
> Subject: Re: 4.0 branch rights
> 
> The automated ci is added on jenkins, not related to gerrit permissions or
> hooks

Right! Who should I ask for help about that?

Thanks,
 

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

[oVirt Jenkins] ovirt-engine_master_upgrade-from-4.0_el7_merged - Build # 96 - Failure!

[jenkins]

Project: 
http://jenkins.ovirt.org/job/ovirt-engine_master_upgrade-from-4.0_el7_merged/ 
Build: 
http://jenkins.ovirt.org/job/ovirt-engine_master_upgrade-from-4.0_el7_merged/96/
Build Number: 96
Build Status:  Failure
Triggered By: Triggered by Gerrit: https://gerrit.ovirt.org/58718

-
Changes Since Last Success:
-
Changes for Build #96
[Alona Kaplan] engine: Remove filter from pasthrough vnics




-
Failed Tests:
-
No tests ran. 

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

Re: Duplicate upgrade scripts issue

[David Caro Estevez]

- Original Message -

> From: "Martin Perina" 
> To: "Eli Mesika" 
> Cc: "Eyal Edri" , "infra" 
> Sent: Tuesday, June 7, 2016 11:45:28 AM
> Subject: Re: Duplicate upgrade scripts issue

> On Tue, Jun 7, 2016 at 11:42 AM, Eli Mesika < emes...@redhat.com > wrote:

> > Ha , one more thing :
> 

> > We would like to force the existence of such hooks if possible ...
> 

> ​+1

> The hook should be included by default after git clone​ if possible. And if
> it's then I'd also force inclusion of commit message hook which generates
> change-id

Git does not allow 'autodownloading' hooks, you can't distribute them by git 
clone, the client must explicitly install them herself 

> > On Tue, Jun 7, 2016 at 12:41 PM, Eli Mesika < emes...@redhat.com > wrote:
> 

> > > Hi guys
> > 
> 

> > > I have talked with Eyal about the $Subject and he asked me to write and
> > > send
> > > this email
> > 
> 

> > > As you probably know, we have from time to time an issue with duplicate
> > > upgrade scripts that are merged by mistake, each such issue forces us to
> > > publish a fixing patch that renames the duplicated file.
> > 
> 
> > > I was discussed this issue today with Marin P on out weekly meeting
> > 
> 

> > > We would like to write some kind of a hook that will check on each patch
> > > set
> > > if it has DB upgrade files and rename them (if necessary) such that it
> > > will
> > > have the correct numbering according to the last existing upgrade patch
> > > on
> > > the related branch.
> > 
> 

> > > The hook should be done upon 'git push' request so it will also prevent
> > > CI
> > > tests to fail on this issue
> > 
> 

> > > I will be happy to get your ideas/comments on that
> > 
> 

> > > Thanks
> > 
> 

> > > Eli Mesika
> > 
> 

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

Re: Duplicate upgrade scripts issue

[Yedidyah Bar David]

On Tue, Jun 7, 2016 at 12:45 PM, Martin Perina  wrote:
>
>
> On Tue, Jun 7, 2016 at 11:42 AM, Eli Mesika  wrote:
>>
>> Ha , one more thing :
>>
>> We would like to force the existence of such hooks if possible ...
>
>
> +1
>
> The hook should be included by default after git clone if possible. And if
> it's then I'd also force inclusion of commit message hook which generates
> change-id
>

IMO having it as a git hook is a useful optimization, but more important
is to make it run on the server, to prevent push/merge.

To do this we can simply patch the engine's automation/check-patch.sh and/or
check-merged.sh .

>>
>> On Tue, Jun 7, 2016 at 12:41 PM, Eli Mesika  wrote:
>>>
>>> Hi guys
>>>
>>> I have talked with Eyal about the $Subject and he asked me to write and
>>> send this email
>>>
>>> As you probably know, we have from time to time an issue with duplicate
>>> upgrade scripts that are merged by mistake, each such issue forces us to
>>> publish a fixing patch that renames the duplicated file.
>>> I was discussed this issue today with Marin P on out weekly meeting
>>>
>>> We would like to write some kind of a hook that will check on each patch
>>> set if it has DB upgrade files and rename them (if necessary) such that it
>>> will have the correct numbering according to the last existing upgrade patch
>>> on the related branch.
>>>
>>> The hook should be done upon 'git push' request so it will also prevent
>>> CI tests to fail on this issue
>>>
>>> I will be happy to get your ideas/comments on that
>>>
>>> Thanks
>>>
>>> Eli Mesika
>>
>>
>
>
> ___
> Infra mailing list
> Infra@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
>



-- 
Didi
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: Enhancing std-ci for deployment (std-cd)

[David Caro Estevez]

- Original Message -
> From: "Barak Korren" 
> To: "David Caro Estevez" 
> Cc: "infra" 
> Sent: Tuesday, June 7, 2016 11:31:17 AM
> Subject: Re: Enhancing std-ci for deployment (std-cd)
> 
> >
> > I'd go a 4th way:
> >
> > * For the non-merged patches, use lago or similar instead of deploying into
> > prod foreman, though it might be a bit cumbersome to generate the env, for
> > most cases, it's way more flexible, and a lot less risky
> 
> This would probably mean all tests would need to be automated, while a
> worthy goal, this is not practical in the short term IMO.
> 

I don't think we should invest time in automating any other solution, that 
would mean not just not working on that one, but actually burying it under 
extra effort to adapt whatever 'temporary short term' solution was used instead.

> > * For the merged patches, I'd use a 'passive' deployment, where the scripts
> > with the deploy logic reside on foreman and are activated by jenkins (for
> > example, by ssh to the slave, similar to how we deploy there today). That
> > puts the deploy logic on the server where it should be deployed. Most
> > probably using the same or very similar script on the non-merged checks to
> > deploy to the virtual environment. This leaves a clean yaml, keeps a
> > strict security (only a specific ssh user with the correct private key can
> > do it, and it can only run that script and nothing else), and maintain the
> > infra config details out of the source code.
> >
> 
> While I agree that infra details should be kept outside the source
> repo. This seems to create the situation where all deployment logic
> will also permanently reside outside of it. I want the deployment
> logic to be self-contained and movable. I'm actually looking at this
> right now because I want to deploy the Puppet code on the DS Sat6 and
> not the US foreman.

I don't think you should use the same deploy procedure on upstream foreman and 
ds satellite, each env has it's own particularities, and unless you want to 
deploy the whole env (like deploying full vms, or containers) it's no worth imo 
try to keep such a generic deploy script, given into account all the 
limitations and maintenance that genericness requires.

> I can see the security benefits of the keyed ssh commands, but I'm not
> sure those are required in all cases and outweigh the lack of
> transparency in the logic and the probable need for manual
> maintenance.
> 

I don't think the manual maintenance will be that high, the deploy scripts can 
be easily puppetized themselves. And imo, upstream the ssh command are more 
than required, they should be a bare minimum.

> 
> --
> Barak Korren
> bkor...@redhat.com
> RHEV-CI Team
> 
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: Duplicate upgrade scripts issue

[Martin Perina]

On Tue, Jun 7, 2016 at 11:42 AM, Eli Mesika  wrote:

> Ha , one more thing :
>
> We would like to force the existence of such hooks if possible ...
>

​+1

The hook should be included by default after git clone​ if possible. And if
it's then I'd also force inclusion of commit message hook which generates
change-id


> On Tue, Jun 7, 2016 at 12:41 PM, Eli Mesika  wrote:
>
>> Hi guys
>>
>> I have talked with Eyal about the $Subject and he asked me to write and
>> send this email
>>
>> As you probably know, we have from time to time an issue with duplicate
>> upgrade scripts that are merged by mistake, each such issue forces us to
>> publish a fixing patch that renames the duplicated file.
>> I was discussed this issue today with Marin P on out weekly meeting
>>
>> We would like to write some kind of a hook that will check on each patch
>> set if it has DB upgrade files and rename them (if necessary) such that it
>> will have the correct numbering according to the last existing upgrade
>> patch on the related branch.
>>
>> The hook should be done upon 'git push' request so it will also prevent
>> CI tests to fail on this issue
>>
>> I will be happy to get your ideas/comments on that
>>
>> Thanks
>>
>> Eli Mesika
>>
>
>
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: Duplicate upgrade scripts issue

[Eli Mesika]

Ha , one more thing :

We would like to force the existence of such hooks if possible ...

On Tue, Jun 7, 2016 at 12:41 PM, Eli Mesika  wrote:

> Hi guys
>
> I have talked with Eyal about the $Subject and he asked me to write and
> send this email
>
> As you probably know, we have from time to time an issue with duplicate
> upgrade scripts that are merged by mistake, each such issue forces us to
> publish a fixing patch that renames the duplicated file.
> I was discussed this issue today with Marin P on out weekly meeting
>
> We would like to write some kind of a hook that will check on each patch
> set if it has DB upgrade files and rename them (if necessary) such that it
> will have the correct numbering according to the last existing upgrade
> patch on the related branch.
>
> The hook should be done upon 'git push' request so it will also prevent CI
> tests to fail on this issue
>
> I will be happy to get your ideas/comments on that
>
> Thanks
>
> Eli Mesika
>
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Duplicate upgrade scripts issue

[Eli Mesika]

Hi guys

I have talked with Eyal about the $Subject and he asked me to write and
send this email

As you probably know, we have from time to time an issue with duplicate
upgrade scripts that are merged by mistake, each such issue forces us to
publish a fixing patch that renames the duplicated file.
I was discussed this issue today with Marin P on out weekly meeting

We would like to write some kind of a hook that will check on each patch
set if it has DB upgrade files and rename them (if necessary) such that it
will have the correct numbering according to the last existing upgrade
patch on the related branch.

The hook should be done upon 'git push' request so it will also prevent CI
tests to fail on this issue

I will be happy to get your ideas/comments on that

Thanks

Eli Mesika
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: Enhancing std-ci for deployment (std-cd)

[Barak Korren]

>
> I'd go a 4th way:
>
> * For the non-merged patches, use lago or similar instead of deploying into 
> prod foreman, though it might be a bit cumbersome to generate the env, for 
> most cases, it's way more flexible, and a lot less risky

This would probably mean all tests would need to be automated, while a
worthy goal, this is not practical in the short term IMO.

> * For the merged patches, I'd use a 'passive' deployment, where the scripts 
> with the deploy logic reside on foreman and are activated by jenkins (for 
> example, by ssh to the slave, similar to how we deploy there today). That 
> puts the deploy logic on the server where it should be deployed. Most 
> probably using the same or very similar script on the non-merged checks to 
> deploy to the virtual environment. This leaves a clean yaml, keeps a strict 
> security (only a specific ssh user with the correct private key can do it, 
> and it can only run that script and nothing else), and maintain the infra 
> config details out of the source code.
>

While I agree that infra details should be kept outside the source
repo. This seems to create the situation where all deployment logic
will also permanently reside outside of it. I want the deployment
logic to be self-contained and movable. I'm actually looking at this
right now because I want to deploy the Puppet code on the DS Sat6 and
not the US foreman.
I can see the security benefits of the keyed ssh commands, but I'm not
sure those are required in all cases and outweigh the lack of
transparency in the logic and the probable need for manual
maintenance.


-- 
Barak Korren
bkor...@redhat.com
RHEV-CI Team
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: 4.0 branch rights

[David Caro Estevez]

The automated ci is added on jenkins, not related to gerrit permissions or hooks

- Original Message -
> From: "Francesco Romani" 
> To: "David Caro Estevez" 
> Cc: "Yaniv Bronheim" , "infra" 
> Sent: Tuesday, June 7, 2016 11:06:31 AM
> Subject: Re: 4.0 branch rights
> 
> Thanks David,
> 
> I have now CI+1, +2 and merge rights!
> 
> No automated CI runs still, it seems.
> 
> Bests,
> 
> - Original Message -
> > From: "David Caro Estevez" 
> > To: "Yaniv Bronheim" 
> > Cc: "infra" 
> > Sent: Tuesday, June 7, 2016 10:47:51 AM
> > Subject: Re: 4.0 branch rights
> > 
> > You should have those rights now, let me know if you have issues
> > 
> > - Original Message -
> > > From: "Yaniv Bronheim" 
> > > To: "infra" 
> > > Sent: Tuesday, June 7, 2016 10:02:10 AM
> > > Subject: 4.0 branch rights
> > > 
> > > Hi,
> > > I need rights to merge and create tags in vdsm ovirt-4.0 branch.
> > > 
> > > Thanks in advance
> > > 
> > > --
> > > Yaniv Bronhaim.
> > > 
> > > ___
> > > Infra mailing list
> > > Infra@ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/infra
> > > 
> > ___
> > Infra mailing list
> > Infra@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
> > 
> 
> --
> Francesco Romani
> RedHat Engineering Virtualization R & D
> Phone: 8261328
> IRC: fromani
> 
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: 4.0 branch rights

[Francesco Romani]

Thanks David,

I have now CI+1, +2 and merge rights!

No automated CI runs still, it seems.

Bests,

- Original Message -
> From: "David Caro Estevez" 
> To: "Yaniv Bronheim" 
> Cc: "infra" 
> Sent: Tuesday, June 7, 2016 10:47:51 AM
> Subject: Re: 4.0 branch rights
> 
> You should have those rights now, let me know if you have issues
> 
> - Original Message -
> > From: "Yaniv Bronheim" 
> > To: "infra" 
> > Sent: Tuesday, June 7, 2016 10:02:10 AM
> > Subject: 4.0 branch rights
> > 
> > Hi,
> > I need rights to merge and create tags in vdsm ovirt-4.0 branch.
> > 
> > Thanks in advance
> > 
> > --
> > Yaniv Bronhaim.
> > 
> > ___
> > Infra mailing list
> > Infra@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
> > 
> ___
> Infra mailing list
> Infra@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
> 

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

Re: Enhancing std-ci for deployment (std-cd)

[David Caro Estevez]

- Original Message -
> From: "Barak Korren" 
> To: "infra" 
> Sent: Tuesday, June 7, 2016 10:45:06 AM
> Subject: Enhancing std-ci for deployment (std-cd)
> 
> Hi all,
> 
> I'm contemplating the best way to enable including deployment logic in
> standard-CI scripts.
> 

I'm working on a first POC of something similar to that right now, deploying 
engine rpms to an 'experimental' repo on build-artifacts success

> Case to the point - embedding the deployment logic of our infra-puppet
> repo. One thing to note about this, is that deployment in this
> scenario can happen either post-merge (Like it does today) or
> pre-merge (Create a per-patch puppet env to enable easy testing)
> 
> I can think of a few ways to go about this:
> 
> 1. Copy the full generated puppet configuration into
> 'exported-artifacts' and add logic to the YAML to copy it to the
> foreman server.
> 
> The main shortcoming of this is that we will have to maintain quite a
> bit of custom logic in the YAML. This beats the purpose of embedding
> the logic in the source repo in the 1st place.
> 
> 2. Mount the '/etc/puppet' directory into the chrrot
> 
> This will require having the foreman be a Jenkins slave and some
> custom YAML to ensure the jobs run on it (not a big deal IMO)
> 
> The shortcoming is that running tests locally with mock_runner would
> be cumbersome (It will touch your local /etc/puppet directory and
> probably fail). Another issue is that we will have to find a way to
> figure out Gerrit patch information from inside mock. Possibly we
> could use the commit message or git hash for that.
> 
> 3. Invent some kind of a new deploy_*.sh script
> 
> This makes it possible to run the checking code locally without the
> deployment code. The YAML changes for this could be quite generic and
> shared with other projects. We could possibly also invent a
> 'deploy_*.target' to specify where to run the deploy script (E.g. a
> Jenkins label).
> 
> We could even consider not running the script inside mock, though I
> think mock's benefits outweigh the limits it imposes on accessing the
> outside system (which can be mostly bypassed anyway with bind mounts).
> 
> So,
> WDYT?
> 

I'd go a 4th way:

* For the non-merged patches, use lago or similar instead of deploying into 
prod foreman, though it might be a bit cumbersome to generate the env, for most 
cases, it's way more flexible, and a lot less risky
* For the merged patches, I'd use a 'passive' deployment, where the scripts 
with the deploy logic reside on foreman and are activated by jenkins (for 
example, by ssh to the slave, similar to how we deploy there today). That puts 
the deploy logic on the server where it should be deployed. Most probably using 
the same or very similar script on the non-merged checks to deploy to the 
virtual environment. This leaves a clean yaml, keeps a strict security (only a 
specific ssh user with the correct private key can do it, and it can only run 
that script and nothing else), and maintain the infra config details out of the 
source code.

> --
> Barak Korren
> bkor...@redhat.com
> RHEV-CI Team
> ___
> Infra mailing list
> Infra@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
> 
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: [Vdsm] infra support for the new stable branch ovirt-4.0

[Eyal Edri]

David, we might need to add more 4.0 jobs to VDSM like we did for engine,
no?

On Tue, Jun 7, 2016 at 11:46 AM, David Caro Estevez 
wrote:

> Shlomi is sick today, so I've changed it.
>
> The hooks were already enabled (maybe Shlomi had time to do that :) ),
> just had to add the privileges to the branch. It has now the same treatment
> than the 3.6 one. Let me know if you miss anything or want something to
> work differently.
>
> Cheers!
>
> - Original Message -
> > From: "Eyal Edri" 
> > To: "Dan Kenigsberg" , "Shlomo Ben David" <
> sbend...@redhat.com>, infra-supp...@ovirt.org
> > Cc: "infra" 
> > Sent: Monday, June 6, 2016 8:24:36 AM
> > Subject: Re: [Vdsm] infra support for the new stable branch ovirt-4.0
> >
> > Shlomi,
> > Can you handle the permissions adding on the VDSM project for the new
> branch?
> > We'll also need to enable hooks for the ovirt-4.0 branch.
> >
> > e.
> >
> > On Sun, Jun 5, 2016 at 10:51 AM, Dan Kenigsberg < dan...@redhat.com >
> wrote:
> >
> >
> > On Sat, Jun 04, 2016 at 04:16:18PM +0300, Nir Soffer wrote:
> > > On Fri, Jun 3, 2016 at 10:58 AM, Francesco Romani < from...@redhat.com
> >
> > > wrote:
> > > > Hi Infra,
> > > >
> > > > (Dan, please ACK/NACK the following)
> > > >
> > > > I'm not sure this is already been worked on, or if it was already
> > > > configured automatically,
> > > > sending just in case to be sure.
> > > >
> > > > Me and Yaniv (CC'd) agreed to continue our maintainer duties and take
> > > > care of the ovirt-4.0
> > > > Vdsm stable branch which was recently created.
> > > >
> > > > I'd like to ask if we have the gerrit permissions and CI jobs ready
> for
> > > > the new
> > > > branch.
> > >
> > > +1
> > +1
> > ___
> > Infra mailing list
> > Infra@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
> >
> >
> >
> >
> >
> > --
> > Eyal Edri
> > Associate Manager
> > RHEV DevOps
> > EMEA ENG Virtualization R&D
> > Red Hat Israel
> >
> > phone: +972-9-7692018
> > irc: eedri (on #tlv #rhev-dev #rhev-integ)
> >
> > ___
> > Infra mailing list
> > Infra@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
> >
>



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

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

Re: 4.0 branch rights

[David Caro Estevez]

You should have those rights now, let me know if you have issues

- Original Message -
> From: "Yaniv Bronheim" 
> To: "infra" 
> Sent: Tuesday, June 7, 2016 10:02:10 AM
> Subject: 4.0 branch rights
> 
> Hi,
> I need rights to merge and create tags in vdsm ovirt-4.0 branch.
> 
> Thanks in advance
> 
> --
> Yaniv Bronhaim.
> 
> ___
> Infra mailing list
> Infra@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
> 
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: 4.0 branch rights

[Eyal Edri]

Sorry for the late response, I think the original request was lost in the
thread and not sure it came into a conclusion.
David is adding them now.

e.

On Tue, Jun 7, 2016 at 11:46 AM, Francesco Romani 
wrote:

> Same.
>
> Plus, AFAIK CI jobs are still not running on ovirt-4.0 branch
>
> Sorry for nagging infra, but the backport queue is rapidly growing :\
>
> Thanks,
>
> - Original Message -
> > From: "Yaniv Bronheim" 
> > To: "infra" 
> > Sent: Tuesday, June 7, 2016 10:02:10 AM
> > Subject: 4.0 branch rights
> >
> > Hi,
> > I need rights to merge and create tags in vdsm ovirt-4.0 branch.
> >
> > Thanks in advance
> >
> > --
> > Yaniv Bronhaim.
> >
> > ___
> > Infra mailing list
> > Infra@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
> >
>
> --
> Francesco Romani
> RedHat Engineering Virtualization R & D
> Phone: 8261328
> IRC: fromani
> ___
> Infra mailing list
> Infra@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
>
>
>


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

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

Re: 4.0 branch rights

[Francesco Romani]

Same.

Plus, AFAIK CI jobs are still not running on ovirt-4.0 branch

Sorry for nagging infra, but the backport queue is rapidly growing :\

Thanks,

- Original Message -
> From: "Yaniv Bronheim" 
> To: "infra" 
> Sent: Tuesday, June 7, 2016 10:02:10 AM
> Subject: 4.0 branch rights
> 
> Hi,
> I need rights to merge and create tags in vdsm ovirt-4.0 branch.
> 
> Thanks in advance
> 
> --
> Yaniv Bronhaim.
> 
> ___
> Infra mailing list
> Infra@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
> 

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

Re: [Vdsm] infra support for the new stable branch ovirt-4.0

[David Caro Estevez]

Shlomi is sick today, so I've changed it.

The hooks were already enabled (maybe Shlomi had time to do that :) ), just had 
to add the privileges to the branch. It has now the same treatment than the 3.6 
one. Let me know if you miss anything or want something to work differently.

Cheers!

- Original Message -
> From: "Eyal Edri" 
> To: "Dan Kenigsberg" , "Shlomo Ben David" 
> , infra-supp...@ovirt.org
> Cc: "infra" 
> Sent: Monday, June 6, 2016 8:24:36 AM
> Subject: Re: [Vdsm] infra support for the new stable branch ovirt-4.0
> 
> Shlomi,
> Can you handle the permissions adding on the VDSM project for the new branch?
> We'll also need to enable hooks for the ovirt-4.0 branch.
> 
> e.
> 
> On Sun, Jun 5, 2016 at 10:51 AM, Dan Kenigsberg < dan...@redhat.com > wrote:
> 
> 
> On Sat, Jun 04, 2016 at 04:16:18PM +0300, Nir Soffer wrote:
> > On Fri, Jun 3, 2016 at 10:58 AM, Francesco Romani < from...@redhat.com >
> > wrote:
> > > Hi Infra,
> > > 
> > > (Dan, please ACK/NACK the following)
> > > 
> > > I'm not sure this is already been worked on, or if it was already
> > > configured automatically,
> > > sending just in case to be sure.
> > > 
> > > Me and Yaniv (CC'd) agreed to continue our maintainer duties and take
> > > care of the ovirt-4.0
> > > Vdsm stable branch which was recently created.
> > > 
> > > I'd like to ask if we have the gerrit permissions and CI jobs ready for
> > > the new
> > > branch.
> > 
> > +1
> +1
> ___
> Infra mailing list
> Infra@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
> 
> 
> 
> 
> 
> --
> Eyal Edri
> Associate Manager
> RHEV DevOps
> EMEA ENG Virtualization R&D
> Red Hat Israel
> 
> phone: +972-9-7692018
> irc: eedri (on #tlv #rhev-dev #rhev-integ)
> 
> ___
> Infra mailing list
> Infra@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
> 
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Enhancing std-ci for deployment (std-cd)

[Barak Korren]

Hi all,

I'm contemplating the best way to enable including deployment logic in
standard-CI scripts.

Case to the point - embedding the deployment logic of our infra-puppet
repo. One thing to note about this, is that deployment in this
scenario can happen either post-merge (Like it does today) or
pre-merge (Create a per-patch puppet env to enable easy testing)

I can think of a few ways to go about this:

1. Copy the full generated puppet configuration into
'exported-artifacts' and add logic to the YAML to copy it to the
foreman server.

The main shortcoming of this is that we will have to maintain quite a
bit of custom logic in the YAML. This beats the purpose of embedding
the logic in the source repo in the 1st place.

2. Mount the '/etc/puppet' directory into the chrrot

This will require having the foreman be a Jenkins slave and some
custom YAML to ensure the jobs run on it (not a big deal IMO)

The shortcoming is that running tests locally with mock_runner would
be cumbersome (It will touch your local /etc/puppet directory and
probably fail). Another issue is that we will have to find a way to
figure out Gerrit patch information from inside mock. Possibly we
could use the commit message or git hash for that.

3. Invent some kind of a new deploy_*.sh script

This makes it possible to run the checking code locally without the
deployment code. The YAML changes for this could be quite generic and
shared with other projects. We could possibly also invent a
'deploy_*.target' to specify where to run the deploy script (E.g. a
Jenkins label).

We could even consider not running the script inside mock, though I
think mock's benefits outweigh the limits it imposes on accessing the
outside system (which can be mostly bypassed anyway with bind mounts).

So,
WDYT?

-- 
Barak Korren
bkor...@redhat.com
RHEV-CI Team
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

4.0 branch rights

[Yaniv Bronheim]

Hi,
I need rights to merge and create tags in vdsm ovirt-4.0 branch.

Thanks in advance

-- 
*Yaniv Bronhaim.*
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: One patch - two failures

[Martin Perina]

Well, this is the only explanation I was able to think of as I haven't been
able to reproduce it locally and definitely there was not any change in 3.5
upgrade scripts for several months (the
03_05_0580_add_default_instance_types.sql script was changed last time on
Jun 2nd 2014).

Anyway it happen again, we can investigate it more.

Thanks

Martin


On Tue, Jun 7, 2016 at 8:37 AM, Barak Korren  wrote:

> On 6 June 2016 at 11:46, Martin Perina  wrote:
> > No it's not, this is some strange failure in 3.5 upgrade script which
> seems
> > to me impossible. The patch [1] didn't contain any db related stuff, so
> > upgrade from master before this patch to master with this patch shouldn't
> > fail (and I just verified locally that this upgrade works fine). So I
> assume
> > this was some kind of mess in db content prior the upgrade job.
> >
>
> This is close to impossible, the upgrade job removes the postgresql
> package and deletes "/var/lib/pgsql/data" as can be seen here:
>
>
> https://gerrit.ovirt.org/gitweb?p=jenkins.git;a=blob;f=jobs/ovirt-engine_upgrade_to_master/upgrade.sh;h=d02ee0e994afd33939a0299920b4de4ca4e4e74e;hb=refs/heads/master#l116
>
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: [Vdsm] infra support for the new stable branch ovirt-4.0

[Francesco Romani]

Hi all

- Original Message -
> From: "Eyal Edri" 
> To: "Dan Kenigsberg" , "Shlomo Ben David" 
> , infra-supp...@ovirt.org
> Cc: "infra" 
> Sent: Monday, June 6, 2016 8:24:36 AM
> Subject: Re: [Vdsm] infra support for the new stable branch ovirt-4.0
> 
> Shlomi,
> Can you handle the permissions adding on the VDSM project for the new branch?
> We'll also need to enable hooks for the ovirt-4.0 branch.
> 
> e.
> 
> On Sun, Jun 5, 2016 at 10:51 AM, Dan Kenigsberg < dan...@redhat.com > wrote:
> 
> 
> On Sat, Jun 04, 2016 at 04:16:18PM +0300, Nir Soffer wrote:
> > On Fri, Jun 3, 2016 at 10:58 AM, Francesco Romani < from...@redhat.com >
> > wrote:
> > > Hi Infra,
> > > 
> > > (Dan, please ACK/NACK the following)
> > > 
> > > I'm not sure this is already been worked on, or if it was already
> > > configured automatically,
> > > sending just in case to be sure.
> > > 
> > > Me and Yaniv (CC'd) agreed to continue our maintainer duties and take
> > > care of the ovirt-4.0
> > > Vdsm stable branch which was recently created.
> > > 
> > > I'd like to ask if we have the gerrit permissions and CI jobs ready for
> > > the new
> > > branch.

Any progress on that?
Considering https://gerrit.ovirt.org/#/c/58698/

- no CI run
- I don't have the "merge" button, nor I can add CI score manually (Nir helped 
with that)

Perhaps the 'ovirt-4.0' branch was not added to the existing set of the stable 
branches?

Thanks,

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