Re: [openstack-dev] [nova][infra] Getting a bleeding edge libvirt gate job running

2015-11-19 Thread Markus Zoeller 
Tony Breeds <t...@bakeyournoodle.com> wrote on 11/18/2015 10:43:30 PM:

> From: Tony Breeds <t...@bakeyournoodle.com>
> To: "Daniel P. Berrange" <berra...@redhat.com>, "OpenStack Development
> Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
> Date: 11/18/2015 10:44 PM
> Subject: Re: [openstack-dev] [nova][infra] Getting a bleeding edge 
> libvirt gate job running
> 
> On Wed, Nov 18, 2015 at 11:46:40AM +, Daniel P. Berrange wrote:
> > On Wed, Nov 18, 2015 at 05:18:28PM +1100, Tony Breeds wrote:
> > > On Tue, Nov 17, 2015 at 03:32:45PM -0800, Jay Pipes wrote:
> > > > On 11/17/2015 11:10 AM, Markus Zoeller wrote:
> > > > >Background
> > > > >==
> > > > >The blueprint [1] wants to utilize the *virtlogd* logging deamon 
from
> > > > >libvirt. Among others to solve bug [2], one of our oldest ones. 
The
> > > > >funny part is, that this libvirt feature is still in development. 
This
> > > > >was a trigger to see if we can create a gate job which utilizes 
the
> > > > >latest, bleeding edge, version of libvirt to test such features. 
We
> > > > >discussed it shortly in IRC [3] (tonyb, bauzas, markus_z) and 
wanted to
> > > > >get some feedback here. The summary of the idea is:
> > > > >* Create a custom repo which contains the latest libvirt version
> > > > >* Enhance Devstack so that it can point to a custom repo to 
install
> > > > >   the built libvirt packages
> > > > >* Have a nodepool image which is compatible with the libvirt 
packages
> > > > >* In case of [1]: check if tempest needs further/changed tests
> > > > >
> > > > >Open questions
> > > > >==
> > > > >* Is already someone working on something like that and I missed 
it?
> > > > 
> > > > Sean (cc'd) might have some information on what he's doing in the 
OVS w/
> > > > DPDK build environment, which AFAIK requires a later build of 
libvirt than
> > > > available in most distros.
> > > > 
> > > > >* If 'no', is there already a repo which contains the very latest
> > > > >   libvirt builds which we can utilize?
> > > > >
> > > > >I haven't done anything with the gates before, which means there 
is a
> > > > >very high chance I'm missing something or missunderstanding a 
concept.
> > > > >Please let me know what you think.
> > > > 
> > > > A generic "build libvirt or OVS from this source repo" dsvm job 
would be
> > > > great I think. That would allow overrides in ENV variables to 
> point the job
> > > > to a URI for grabbing sources of OVS (DPDK OVS, mainline OVS) or 
libvirt
> > > > that would be built into the target nodepool images.
> > > 
> > > I was really hoping to decouple the build from the dsvm jobs.  My 
initial
> > > thoughts were a add a devstack plugin that add $repo and then 
upgrade
> > > $packages.  I wanted to decouple the build from install as I 
> assumed that the
> > > delays in building libvirt (etc) would be problematic *and* provide 
another
> > > failure mode for devstack that we really don't want to deal with.
> > > 
> > > I was only thinking of having libvirt and qemu in there but if the
> plug-in was
> > > abstract enough it could easily provide packages for other help 
> utils (like OVS
> > > and DPDK).
> > > 
> > > When I started looking at this Ubuntu was the likely candidate as 
> Fedora in the gate
> > > wasn't really a stable thing.  I see a little more fedora in 
> nodepool so perhaps a
> > > really quick win would be to just use the lib-virt preview on F22.
> > 
> > Trying to build from bleeding edge is just a can of worms as you'll 
need to
> > have someone baby-sitting the job to fix it up on new releases when 
the
> > list of build deps changes or build options alter. As an example, next
> > QEMU release will require you to pull in 3rd party libcacard library
> > for SPICE build, since it was split out, so there's already a build
> > change pending that would cause a regression in the gate.
> 
> Right, that's why I wanted to decouple the build from the gate. releases 
don't
> happen that often so if virt-preview/UCA isn't appropraite for some 
reason I
> can easly dedicate a day/project/release to build the packages.
> 
> > So, my recommendation would really be to just use Fedora wit

Re: [openstack-dev] [nova][infra] Getting a bleeding edge libvirt gate job running

2015-11-18 Thread Kashyap Chamarthy 
On Wed, Nov 18, 2015 at 06:46:58AM +1100, Ian Wienand wrote:
> On 11/18/2015 06:10 AM, Markus Zoeller wrote:
>  This
> >was a trigger to see if we can create a gate job which utilizes the
> >latest, bleeding edge, version of libvirt to test such features.
> 
> >* Is already someone working on something like that and I missed it?
> 
> I believe the closest we have got is probably [1]; pulling apart some
> of the comments there might be helpful

After months of review, and being almost close to merge, the "Support
for libvirt/QEMU tar releases" patch you refer to below, seems to be
abandoned by the contributor.

It is functionally fine and just ought to put in an external plugin (as
you note below) and add the relevant glue code in DevStack to call it.

> In short, a devstack plugin that installs the latest libvirt is
> probably the way to go.
>
> Ongoing, the only issue I see is that we do things to base devstack
> that conflict/break this plugin, as we are more-or-less assuming the
> distro version (see things like [2], stuff like this comes up every
> now and then).
> 
> >* If 'no', is there already a repo which contains the very latest
> >   libvirt builds which we can utilize?
> 
> For Fedora, there is virt-preview  [3] at least

Yep, it is actively maintained.

> 
> [1] https://review.openstack.org/#/c/108714/
> [2] https://review.openstack.org/246501
> [3] https://fedoraproject.org/wiki/Virtualization_Preview_Repository

-- 
/kashyap

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][infra] Getting a bleeding edge libvirt gate job running

2015-11-18 Thread James Page 
Hi Markus

On Tue, Nov 17, 2015 at 7:10 PM, Markus Zoeller  wrote:

> Background
> ==
> The blueprint [1] wants to utilize the *virtlogd* logging deamon from
> libvirt. Among others to solve bug [2], one of our oldest ones. The
> funny part is, that this libvirt feature is still in development. This
> was a trigger to see if we can create a gate job which utilizes the
> latest, bleeding edge, version of libvirt to test such features. We
> discussed it shortly in IRC [3] (tonyb, bauzas, markus_z) and wanted to
> get some feedback here. The summary of the idea is:
> * Create a custom repo which contains the latest libvirt version
> * Enhance Devstack so that it can point to a custom repo to install
>   the built libvirt packages
> * Have a nodepool image which is compatible with the libvirt packages
> * In case of [1]: check if tempest needs further/changed tests
>
> Open questions
> ==
> * Is already someone working on something like that and I missed it?
> * If 'no', is there already a repo which contains the very latest
>   libvirt builds which we can utilize?
>

What are your requirements for libvirt and qemu?  The Liberty UCA for
Ubuntu has the following versions:

  libvirt: 1.2.16
  qemu: 2.3

if that's useful these can be added to any Ubuntu 14.04 system using:

  sudo add-apt-repository cloud-archive:liberty

versions will be updated during Xenial development to later releases which
will be backported to 14.04 as part of the Mitaka UCA.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][infra] Getting a bleeding edge libvirt gate job running

2015-11-18 Thread Daniel P. Berrange 
On Wed, Nov 18, 2015 at 05:18:28PM +1100, Tony Breeds wrote:
> On Tue, Nov 17, 2015 at 03:32:45PM -0800, Jay Pipes wrote:
> > On 11/17/2015 11:10 AM, Markus Zoeller wrote:
> > >Background
> > >==
> > >The blueprint [1] wants to utilize the *virtlogd* logging deamon from
> > >libvirt. Among others to solve bug [2], one of our oldest ones. The
> > >funny part is, that this libvirt feature is still in development. This
> > >was a trigger to see if we can create a gate job which utilizes the
> > >latest, bleeding edge, version of libvirt to test such features. We
> > >discussed it shortly in IRC [3] (tonyb, bauzas, markus_z) and wanted to
> > >get some feedback here. The summary of the idea is:
> > >* Create a custom repo which contains the latest libvirt version
> > >* Enhance Devstack so that it can point to a custom repo to install
> > >   the built libvirt packages
> > >* Have a nodepool image which is compatible with the libvirt packages
> > >* In case of [1]: check if tempest needs further/changed tests
> > >
> > >Open questions
> > >==
> > >* Is already someone working on something like that and I missed it?
> > 
> > Sean (cc'd) might have some information on what he's doing in the OVS w/
> > DPDK build environment, which AFAIK requires a later build of libvirt than
> > available in most distros.
> > 
> > >* If 'no', is there already a repo which contains the very latest
> > >   libvirt builds which we can utilize?
> > >
> > >I haven't done anything with the gates before, which means there is a
> > >very high chance I'm missing something or missunderstanding a concept.
> > >Please let me know what you think.
> > 
> > A generic "build libvirt or OVS from this source repo" dsvm job would be
> > great I think. That would allow overrides in ENV variables to point the job
> > to a URI for grabbing sources of OVS (DPDK OVS, mainline OVS) or libvirt
> > that would be built into the target nodepool images.
> 
> I was really hoping to decouple the build from the dsvm jobs.  My initial
> thoughts were a add a devstack plugin that add $repo and then upgrade
> $packages.  I wanted to decouple the build from install as I assumed that the
> delays in building libvirt (etc) would be problematic *and* provide another
> failure mode for devstack that we really don't want to deal with.
> 
> I was only thinking of having libvirt and qemu in there but if the plug-in was
> abstract enough it could easily provide packages for other help utils (like 
> OVS
> and DPDK).
> 
> When I started looking at this Ubuntu was the likely candidate as Fedora in 
> the gate
> wasn't really a stable thing.  I see a little more fedora in nodepool so 
> perhaps a
> really quick win would be to just use the lib-virt preview on F22.

Trying to build from bleeding edge is just a can of worms as you'll need to
have someone baby-sitting the job to fix it up on new releases when the
list of build deps changes or build options alter. As an example, next
QEMU release will require you to pull in 3rd party libcacard library
for SPICE build, since it was split out, so there's already a build
change pending that would cause a regression in the gate.

So, my recommendation would really be to just use Fedora with virt-preview
for the bleeding edge and avoid trying to compile stuff in the gate. The
virt-preview repository tracks upstream releases of QEMU+Libvirt+libguestfs
with minimal delay and is built with the same configuration as future Fedora
releases will use. So such testing is good evidence that Nova won't break on
the next Fedora release.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][infra] Getting a bleeding edge libvirt gate job running

2015-11-18 Thread Tony Breeds 
On Wed, Nov 18, 2015 at 11:46:40AM +, Daniel P. Berrange wrote:
> On Wed, Nov 18, 2015 at 05:18:28PM +1100, Tony Breeds wrote:
> > On Tue, Nov 17, 2015 at 03:32:45PM -0800, Jay Pipes wrote:
> > > On 11/17/2015 11:10 AM, Markus Zoeller wrote:
> > > >Background
> > > >==
> > > >The blueprint [1] wants to utilize the *virtlogd* logging deamon from
> > > >libvirt. Among others to solve bug [2], one of our oldest ones. The
> > > >funny part is, that this libvirt feature is still in development. This
> > > >was a trigger to see if we can create a gate job which utilizes the
> > > >latest, bleeding edge, version of libvirt to test such features. We
> > > >discussed it shortly in IRC [3] (tonyb, bauzas, markus_z) and wanted to
> > > >get some feedback here. The summary of the idea is:
> > > >* Create a custom repo which contains the latest libvirt version
> > > >* Enhance Devstack so that it can point to a custom repo to install
> > > >   the built libvirt packages
> > > >* Have a nodepool image which is compatible with the libvirt packages
> > > >* In case of [1]: check if tempest needs further/changed tests
> > > >
> > > >Open questions
> > > >==
> > > >* Is already someone working on something like that and I missed it?
> > > 
> > > Sean (cc'd) might have some information on what he's doing in the OVS w/
> > > DPDK build environment, which AFAIK requires a later build of libvirt than
> > > available in most distros.
> > > 
> > > >* If 'no', is there already a repo which contains the very latest
> > > >   libvirt builds which we can utilize?
> > > >
> > > >I haven't done anything with the gates before, which means there is a
> > > >very high chance I'm missing something or missunderstanding a concept.
> > > >Please let me know what you think.
> > > 
> > > A generic "build libvirt or OVS from this source repo" dsvm job would be
> > > great I think. That would allow overrides in ENV variables to point the 
> > > job
> > > to a URI for grabbing sources of OVS (DPDK OVS, mainline OVS) or libvirt
> > > that would be built into the target nodepool images.
> > 
> > I was really hoping to decouple the build from the dsvm jobs.  My initial
> > thoughts were a add a devstack plugin that add $repo and then upgrade
> > $packages.  I wanted to decouple the build from install as I assumed that 
> > the
> > delays in building libvirt (etc) would be problematic *and* provide another
> > failure mode for devstack that we really don't want to deal with.
> > 
> > I was only thinking of having libvirt and qemu in there but if the plug-in 
> > was
> > abstract enough it could easily provide packages for other help utils (like 
> > OVS
> > and DPDK).
> > 
> > When I started looking at this Ubuntu was the likely candidate as Fedora in 
> > the gate
> > wasn't really a stable thing.  I see a little more fedora in nodepool so 
> > perhaps a
> > really quick win would be to just use the lib-virt preview on F22.
> 
> Trying to build from bleeding edge is just a can of worms as you'll need to
> have someone baby-sitting the job to fix it up on new releases when the
> list of build deps changes or build options alter. As an example, next
> QEMU release will require you to pull in 3rd party libcacard library
> for SPICE build, since it was split out, so there's already a build
> change pending that would cause a regression in the gate.

Right, that's why I wanted to decouple the build from the gate.  releases don't
happen that often so if virt-preview/UCA isn't appropraite for some reason I
can easly dedicate a day/project/release to build the packages.
 
> So, my recommendation would really be to just use Fedora with virt-preview
> for the bleeding edge and avoid trying to compile stuff in the gate. The
> virt-preview repository tracks upstream releases of QEMU+Libvirt+libguestfs
> with minimal delay and is built with the same configuration as future Fedora
> releases will use. So such testing is good evidence that Nova won't break on
> the next Fedora release.

Right that was more or less my motivation.

Yours Tony.


pgpRTXZ7Y2HFP.pgp
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][infra] Getting a bleeding edge libvirt gate job running

2015-11-17 Thread Jay Pipes 

On 11/17/2015 11:10 AM, Markus Zoeller wrote:

Background
==
The blueprint [1] wants to utilize the *virtlogd* logging deamon from
libvirt. Among others to solve bug [2], one of our oldest ones. The
funny part is, that this libvirt feature is still in development. This
was a trigger to see if we can create a gate job which utilizes the
latest, bleeding edge, version of libvirt to test such features. We
discussed it shortly in IRC [3] (tonyb, bauzas, markus_z) and wanted to
get some feedback here. The summary of the idea is:
* Create a custom repo which contains the latest libvirt version
* Enhance Devstack so that it can point to a custom repo to install
   the built libvirt packages
* Have a nodepool image which is compatible with the libvirt packages
* In case of [1]: check if tempest needs further/changed tests

Open questions
==
* Is already someone working on something like that and I missed it?


Sean (cc'd) might have some information on what he's doing in the OVS w/ 
DPDK build environment, which AFAIK requires a later build of libvirt 
than available in most distros.



* If 'no', is there already a repo which contains the very latest
   libvirt builds which we can utilize?

I haven't done anything with the gates before, which means there is a
very high chance I'm missing something or missunderstanding a concept.
Please let me know what you think.


A generic "build libvirt or OVS from this source repo" dsvm job would be 
great I think. That would allow overrides in ENV variables to point the 
job to a URI for grabbing sources of OVS (DPDK OVS, mainline OVS) or 
libvirt that would be built into the target nodepool images.


Thoughts?

Best,
-jay


References
==
[1] Nova spec "Libvirt: Use the virtlogd deamon for logs":
 https://review.openstack.org/#/c/234291/
[2] Nova; bugs; "console.log grows indefinitely"
 https://bugs.launchpad.net/nova/+bug/832507
[3] #openstack-nova; 2015-11-17:

http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2015-11-17.log.html#t2015-11-17T08:44:57

Regards, Markus Zoeller (markus_z)


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][infra] Getting a bleeding edge libvirt gate job running

2015-11-17 Thread Ian Wienand 

On 11/18/2015 06:10 AM, Markus Zoeller wrote:
 This

was a trigger to see if we can create a gate job which utilizes the
latest, bleeding edge, version of libvirt to test such features.



* Is already someone working on something like that and I missed it?


I believe the closest we have got is probably [1]; pulling apart some
of the comments there might be helpful

In short, a devstack plugin that installs the latest libvirt is
probably the way to go.

Ongoing, the only issue I see is that we do things to base devstack
that conflict/break this plugin, as we are more-or-less assuming the
distro version (see things like [2], stuff like this comes up every
now and then).


* If 'no', is there already a repo which contains the very latest
   libvirt builds which we can utilize?


For Fedora, there is virt-preview  [3] at least

-i

[1] https://review.openstack.org/#/c/108714/
[2] https://review.openstack.org/246501
[3] https://fedoraproject.org/wiki/Virtualization_Preview_Repository

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova][infra] Getting a bleeding edge libvirt gate job running

2015-11-17 Thread Markus Zoeller 
Background
==
The blueprint [1] wants to utilize the *virtlogd* logging deamon from
libvirt. Among others to solve bug [2], one of our oldest ones. The
funny part is, that this libvirt feature is still in development. This
was a trigger to see if we can create a gate job which utilizes the
latest, bleeding edge, version of libvirt to test such features. We
discussed it shortly in IRC [3] (tonyb, bauzas, markus_z) and wanted to
get some feedback here. The summary of the idea is:
* Create a custom repo which contains the latest libvirt version
* Enhance Devstack so that it can point to a custom repo to install
  the built libvirt packages
* Have a nodepool image which is compatible with the libvirt packages
* In case of [1]: check if tempest needs further/changed tests

Open questions
==
* Is already someone working on something like that and I missed it?
* If 'no', is there already a repo which contains the very latest
  libvirt builds which we can utilize?

I haven't done anything with the gates before, which means there is a
very high chance I'm missing something or missunderstanding a concept.
Please let me know what you think.

References
==
[1] Nova spec "Libvirt: Use the virtlogd deamon for logs":
https://review.openstack.org/#/c/234291/
[2] Nova; bugs; "console.log grows indefinitely"
https://bugs.launchpad.net/nova/+bug/832507
[3] #openstack-nova; 2015-11-17:

http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2015-11-17.log.html#t2015-11-17T08:44:57

Regards, Markus Zoeller (markus_z)


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][infra] Getting a bleeding edge libvirt gate job running

2015-11-17 Thread Tony Breeds 
On Tue, Nov 17, 2015 at 03:32:45PM -0800, Jay Pipes wrote:
> On 11/17/2015 11:10 AM, Markus Zoeller wrote:
> >Background
> >==
> >The blueprint [1] wants to utilize the *virtlogd* logging deamon from
> >libvirt. Among others to solve bug [2], one of our oldest ones. The
> >funny part is, that this libvirt feature is still in development. This
> >was a trigger to see if we can create a gate job which utilizes the
> >latest, bleeding edge, version of libvirt to test such features. We
> >discussed it shortly in IRC [3] (tonyb, bauzas, markus_z) and wanted to
> >get some feedback here. The summary of the idea is:
> >* Create a custom repo which contains the latest libvirt version
> >* Enhance Devstack so that it can point to a custom repo to install
> >   the built libvirt packages
> >* Have a nodepool image which is compatible with the libvirt packages
> >* In case of [1]: check if tempest needs further/changed tests
> >
> >Open questions
> >==
> >* Is already someone working on something like that and I missed it?
> 
> Sean (cc'd) might have some information on what he's doing in the OVS w/
> DPDK build environment, which AFAIK requires a later build of libvirt than
> available in most distros.
> 
> >* If 'no', is there already a repo which contains the very latest
> >   libvirt builds which we can utilize?
> >
> >I haven't done anything with the gates before, which means there is a
> >very high chance I'm missing something or missunderstanding a concept.
> >Please let me know what you think.
> 
> A generic "build libvirt or OVS from this source repo" dsvm job would be
> great I think. That would allow overrides in ENV variables to point the job
> to a URI for grabbing sources of OVS (DPDK OVS, mainline OVS) or libvirt
> that would be built into the target nodepool images.

I was really hoping to decouple the build from the dsvm jobs.  My initial
thoughts were a add a devstack plugin that add $repo and then upgrade
$packages.  I wanted to decouple the build from install as I assumed that the
delays in building libvirt (etc) would be problematic *and* provide another
failure mode for devstack that we really don't want to deal with.

I was only thinking of having libvirt and qemu in there but if the plug-in was
abstract enough it could easily provide packages for other help utils (like OVS
and DPDK).

When I started looking at this Ubuntu was the likely candidate as Fedora in the 
gate
wasn't really a stable thing.  I see a little more fedora in nodepool so 
perhaps a
really quick win would be to just use the lib-virt preview on F22.

Now some questions for the Infra folk:
 - What if any concerns do you have with a job on the experimental pipeline
   pulling stuff from the Internet?
 - Later if we wanted to add this job to the check pipeline would we need to
   mirror the repo closer to the nodes?

Yours Tony.


pgpSCcQwujDwC.pgp
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev