From r.koch at ovido.at  Wed Jan  1 16:45:47 2014
From: r.koch at ovido.at (=?utf-8?Q?Ren=C3=A9_Koch?=)
Date: Wed, 1 Jan 2014 17:45:47 +0100
Subject: [Users] Fwd: Your stand proposal for oVirt has been accepted
In-Reply-To: <52B012AF.1070608@redhat.com>
References: <20131216212820.74EE23F4C3@toad.stack.nl>
Message-ID: <zarafa.52c4463b.3b84.68c93e0f50563dbb@tyr.dmz.ovido.at>

-----Original message-----
> From:Dave Neary <dneary at redhat.com>
> Sent: Tuesday 17th December 2013 10:01
> To: users <users at ovirt.org>; arch <arch at ovirt.org>
> Subject: [Users] Fwd: Your stand proposal for oVirt has been accepted
> 
> Hi everyone,
> 
> Great news! We will have an oVirt stand at FOSDEM in Brussels this year!
> 
> Brian and I will be looking for volunteers to man the stand and spread
> the love about oVirt over the next few weeks - please let us know if you
> plan to attend FOSDEM, we would love to see you there!


I'll attend and can also help at the stand.


> 
> Also, I would love to have an oVirt community meet-up for beers on
> Saturday evening - if we did, would you be interested in attending? Let
> us know!


This would be really great! Of course I would be interested in meeting (and beer ;) )...


> 
> Thanks,
> Dave.
> 
> 
> -------- Original Message --------
> Subject: Your stand proposal for oVirt has been accepted
> Date: Mon, 16 Dec 2013 22:28:20 +0100 (CET)
> From: FOSDEM Stands Team <stands at fosdem.org>
> To: Dave Neary <dneary at redhat.com>
> 
> Hi Dave,
> 
> The FOSDEM stands team is glad to be able to inform you that your request
> for a stand for oVirt has been accepted.
> There will be one table reserved for you.
> 
> You will receive further information about what's expected of you closer
> to the event date.
> 
> Looking forward to seeing you at FOSDEM 2014!
> 
> 
> Kind regards,
> 
> Wynke Stulemeijer
> FOSDEM stands team
> 
> 
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
> 


From mrao at redhat.com  Thu Jan  2 15:12:54 2014
From: mrao at redhat.com (Malini Rao)
Date: Thu, 2 Jan 2014 10:12:54 -0500 (EST)
Subject: Gluster volume capacity feature
In-Reply-To: <52B42F92.9080809@redhat.com>
References: <52B42F92.9080809@redhat.com>
Message-ID: <937660382.47938331.1388675574390.JavaMail.root@redhat.com>

Top posting -

Is there a reason, these stats cannot be incorporated into the main grid view as we do for CPU memory etc on VMs? I am not seeing too much detail or any special comparative stats in the dialog view to make a separate dialog necessary. I am also thinking if the user selects just one volume, the dialog will be really sparse.

Thanks
Malini


----- Original Message -----
From: "Shubhendu Tripathi" <shtripat at redhat.com>
To: "engine-devel" <engine-devel at ovirt.org>, "Michael Pasternak" <mpastern at redhat.com>, "Ori Liel" <oliel at redhat.com>
Cc: arch at ovirt.org
Sent: Friday, December 20, 2013 6:52:50 AM
Subject: Gluster volume capacity feature

Hi All,

A new wiki has been published for feature "Gluster Volume Capacity"
http://www.ovirt.org/Features/Gluster_Volume_Capacity

Please review the same and provide your comments.

Added Michael and Ori specifically for review of REST apis.

Thanks,
Shubhendu Tripathi

_______________________________________________
Arch mailing list
Arch at ovirt.org
http://lists.ovirt.org/mailman/listinfo/arch


From shtripat at redhat.com  Fri Jan  3 03:51:59 2014
From: shtripat at redhat.com (Shubhendu Tripathi)
Date: Fri, 03 Jan 2014 09:21:59 +0530
Subject: Gluster volume capacity feature
In-Reply-To: <937660382.47938331.1388675574390.JavaMail.root@redhat.com>
References: <52B42F92.9080809@redhat.com>
	<937660382.47938331.1388675574390.JavaMail.root@redhat.com>
Message-ID: <52C633DF.1070602@redhat.com>

Hi Malini,

We had an internal discussion on the same, and we also thought that 
having a separated dialog for this purpose not actually required.
Now as per discussion, we would be displaying the volume capacity 
details in the volumes list table as an additional column with name 
"Capacity". This column would be displayed just before the Activities 
column in volumes list table.

REST APIs remain as is to be shown as statistics under specific volume.

Thanks and Regards,
Shubhendu

On 01/02/2014 08:42 PM, Malini Rao wrote:
> Top posting -
>
> Is there a reason, these stats cannot be incorporated into the main grid view as we do for CPU memory etc on VMs? I am not seeing too much detail or any special comparative stats in the dialog view to make a separate dialog necessary. I am also thinking if the user selects just one volume, the dialog will be really sparse.
>
> Thanks
> Malini
>
>
> ----- Original Message -----
> From: "Shubhendu Tripathi" <shtripat at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>, "Michael Pasternak" <mpastern at redhat.com>, "Ori Liel" <oliel at redhat.com>
> Cc: arch at ovirt.org
> Sent: Friday, December 20, 2013 6:52:50 AM
> Subject: Gluster volume capacity feature
>
> Hi All,
>
> A new wiki has been published for feature "Gluster Volume Capacity"
> http://www.ovirt.org/Features/Gluster_Volume_Capacity
>
> Please review the same and provide your comments.
>
> Added Michael and Ori specifically for review of REST apis.
>
> Thanks,
> Shubhendu Tripathi
>
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch



From amedeo at oscert.net  Fri Jan  3 10:59:55 2014
From: amedeo at oscert.net (Amedeo Salvati)
Date: Fri,  3 Jan 2014 11:59:55 +0100
Subject: RFE for qemu-kvm-rhev on EL repository
Message-ID: <MYTNVV$D4E32324471DDE0ABD96B7EC6DABC362@oscert.net>

Hi all,it's possible to include on google docs oVirt 3.4 Planning & Tracking the release of qemu-kvm-rhev [1] rpm (or qemu-kvm-ovirt) on ovirt EL repository?Because at this moment it's esclusion blocks live snapshot on centos 6.5 / ovirt 3.3.x installations.[1] https://bugzilla.redhat.com/show_bug.cgi?id=1009100Best regardsa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20140103/978d9dd6/attachment.html>

From danken at redhat.com  Fri Jan  3 12:20:50 2014
From: danken at redhat.com (Dan Kenigsberg)
Date: Fri, 3 Jan 2014 12:20:50 +0000
Subject: Smarter network_setup hooks
Message-ID: <20140103122050.GE21494@redhat.com>

Recently, Miguel Angel Ajo (CCed) has added a nice functionality to the
implementation of setupNetworks in Vdsm: two hook points where added:
before and after the setupNetworks verb takes place.

This is useful because sometimes, Vdsm's configuration is not good
enough for the user. For example, someone may need to set various
ETHTOOL_OPTS on a nic. Now, they can put a script under
/usr/libexec/vdsm/after_network_setup/ that tweak their ifcfg-eth*
files after they have been written by Vdsm.

However, the hook script only knows that *a* change of network
configuration took place. It does not know which change took place, and
has to figure this out on its own.

Enters http://gerrit.ovirt.org/20330 "allow hooks to pass down
dictionaries in json format".

I'd like to discuss it here, as it introduces a new Vdsm/Hook API that
is quite different than what we have for other hooks. Unlike with Vm
and VmDevice creation, where Vdsm uses libvirt's xml definition
internally as well as to communicate with the hooks,
before/after_network_setup have to define their own means of
communication.

I would like to suggest to use the same information passed on the
Engine/Vdsm API, and extend its reach into the hook script. The three
arguments to setupNetworks(networks, bondings, options) would be dumped
as json strings, to be read by the hook script.

This option is very simple to use and implement, it gives the hook all
the information that Vdsm-proper has, and allows for greatest
flexibility for hook writers. This is also the down side of this idea:
hook script may do all kinds of things with this information, some of
them unsupportable, and they should be notified when Engine/Vdsm API
changes.

In my opinion, it is a small price to pay: hooks have always had the
China Store Rule - if you break something, you own it. Hook users must
know what they're doing, and take care not to use deprecated bits of the
API.

What is your opinion? Comments and suggestions are most welcome!

Dan.


From alitke at redhat.com  Fri Jan  3 16:34:40 2014
From: alitke at redhat.com (Adam Litke)
Date: Fri, 3 Jan 2014 11:34:40 -0500
Subject: Smarter network_setup hooks
In-Reply-To: <20140103122050.GE21494@redhat.com>
References: <20140103122050.GE21494@redhat.com>
Message-ID: <20140103163440.GA4790@redhat.com>

On 03/01/14 12:20 +0000, Dan Kenigsberg wrote:
>Recently, Miguel Angel Ajo (CCed) has added a nice functionality to the
>implementation of setupNetworks in Vdsm: two hook points where added:
>before and after the setupNetworks verb takes place.
>
>This is useful because sometimes, Vdsm's configuration is not good
>enough for the user. For example, someone may need to set various
>ETHTOOL_OPTS on a nic. Now, they can put a script under
>/usr/libexec/vdsm/after_network_setup/ that tweak their ifcfg-eth*
>files after they have been written by Vdsm.
>
>However, the hook script only knows that *a* change of network
>configuration took place. It does not know which change took place, and
>has to figure this out on its own.
>
>Enters http://gerrit.ovirt.org/20330 "allow hooks to pass down
>dictionaries in json format".
>
>I'd like to discuss it here, as it introduces a new Vdsm/Hook API that
>is quite different than what we have for other hooks. Unlike with Vm
>and VmDevice creation, where Vdsm uses libvirt's xml definition
>internally as well as to communicate with the hooks,
>before/after_network_setup have to define their own means of
>communication.
>
>I would like to suggest to use the same information passed on the
>Engine/Vdsm API, and extend its reach into the hook script. The three
>arguments to setupNetworks(networks, bondings, options) would be dumped
>as json strings, to be read by the hook script.
>
>This option is very simple to use and implement, it gives the hook all
>the information that Vdsm-proper has, and allows for greatest
>flexibility for hook writers. This is also the down side of this idea:
>hook script may do all kinds of things with this information, some of
>them unsupportable, and they should be notified when Engine/Vdsm API
>changes.
>
>In my opinion, it is a small price to pay: hooks have always had the
>China Store Rule - if you break something, you own it. Hook users must
>know what they're doing, and take care not to use deprecated bits of the
>API.
>
>What is your opinion? Comments and suggestions are most welcome!

Seems like a logical thing to do.  What specific mechanism do you
suggest for passing the JSON strings to the hook script?  If passed as
arguments to the hook script we would need to consider shell escaping
and argv length restrictions.

What about writing these out to a special file and adding a new
getContext() call to the hooking module.  A script that is unconcerned
with the context would not require any changes.  But a script that
wants access would simply do:

    ctx = hooking.getContext()

and ctx would be the contents of the special file already decoded into
a native Python object for easy consumption.  This could easily be
extended to any hook which may want to provide some context to
implementors.

One more question comes to mind:  Are there any pieces of information
that we would need to redact from the context (passwords or other
sensitive information)?




From amuller at redhat.com  Sun Jan  5 10:05:59 2014
From: amuller at redhat.com (Assaf Muller)
Date: Sun, 5 Jan 2014 05:05:59 -0500 (EST)
Subject: [vdsm] Smarter network_setup hooks
In-Reply-To: <CADSDy2hyaz+xrXaJzPthwpNf7ydwmk7fuyMaF_=oBDDSn+fTnA@mail.gmail.com>
References: <20140103122050.GE21494@redhat.com>
	<20140103163440.GA4790@redhat.com>
	<CADSDy2hyaz+xrXaJzPthwpNf7ydwmk7fuyMaF_=oBDDSn+fTnA@mail.gmail.com>
Message-ID: <1285621619.3259554.1388916359128.JavaMail.root@redhat.com>

Whichever way we decide to do this, I think the important bit is documentation - We have
to make sure to update the oVirt wiki hooks pages. If users aren't aware of how to retrieve
the networking config then we might as well not implement it.

That being said, I'd expose three dictionaries: What's currently configure,
the current request, as well as the proposed end result. It's easy to add
and I see how it would be useful to hook writers. And just to state the obvious,
just like how traditional hooks can change the VM or device XML,
the hook should be able to rewrite the current request contents.
For example, if a user would like to take over host networking configuration,
he could just write a before_setup_networks hook that would configure
networking however he wants, then writes the empty dictionary to the current request,
meaning that VDSM wouldn't do anything further with the current setup networks request.


Assaf Muller, Cloud Networking Engineer 
Red Hat 

----- Original Message -----
From: "Miguel Angel" <miguelangel at ajo.es>
To: "Adam Litke" <alitke at redhat.com>
Cc: dsulliva at redhat.com, arch at ovirt.org, vdsm-devel at fedorahosted.org
Sent: Saturday, January 4, 2014 9:08:17 PM
Subject: Re: [vdsm] Smarter network_setup hooks

Hi Adam 

Thanks for the feedback 

2014/1/3 Adam Litke < alitke at redhat.com > 



On 03/01/14 12:20 +0000, Dan Kenigsberg wrote: 


Recently, Miguel Angel Ajo (CCed) has added a nice functionality to the 
implementation of setupNetworks in Vdsm: two hook points where added: 
before and after the setupNetworks verb takes place. 
[....] 
Seems like a logical thing to do. What specific mechanism do you 
suggest for passing the JSON strings to the hook script? If passed as 
arguments to the hook script we would need to consider shell escaping 
and argv length restrictions. 

As for the libvirt domain xml we pass to other hooks, we write a temporary file 
and we set an environment variable pointing to it before calling the script 


What about writing these out to a special file and adding a new 
getContext() call to the hooking module. A script that is unconcerned 
with the context would not require any changes. But a script that 
wants access would simply do: 

ctx = hooking.getContext() 

and ctx would be the contents of the special file already decoded into 
a native Python object for easy consumption. This could easily be 
extended to any hook which may want to provide some context to 
implementors. 

That would be nice, so scripts written in python wouldn't need to look for, and parse 
the file. 

This is an example of a simple hook: 

http://gerrit.ovirt.org/#/c/20330/7/tests/functional/networkTests.py (look inside the ValidatesHook decorator) 

It'd be quite simplified. We would also need a "setContext()..." to update context with changes. 



One more question comes to mind: Are there any pieces of information 
that we would need to redact from the context (passwords or other 
sensitive information)? 


I think there is no sensitive information as far as I know. 

Greetings, 
Miguel ?ngel. 

_______________________________________________
vdsm-devel mailing list
vdsm-devel at lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel


From lpeer at redhat.com  Sun Jan  5 10:51:46 2014
From: lpeer at redhat.com (Livnat Peer)
Date: Sun, 05 Jan 2014 12:51:46 +0200
Subject: [vdsm] Smarter network_setup hooks
In-Reply-To: <1285621619.3259554.1388916359128.JavaMail.root@redhat.com>
References: <20140103122050.GE21494@redhat.com>	<20140103163440.GA4790@redhat.com>	<CADSDy2hyaz+xrXaJzPthwpNf7ydwmk7fuyMaF_=oBDDSn+fTnA@mail.gmail.com>
	<1285621619.3259554.1388916359128.JavaMail.root@redhat.com>
Message-ID: <52C93942.1030501@redhat.com>

On 01/05/2014 12:05 PM, Assaf Muller wrote:
> Whichever way we decide to do this, I think the important bit is documentation - We have
> to make sure to update the oVirt wiki hooks pages. If users aren't aware of how to retrieve
> the networking config then we might as well not implement it.
> 
> That being said, I'd expose three dictionaries: What's currently configure,
> the current request, as well as the proposed end result. It's easy to add
> and I see how it would be useful to hook writers. And just to state the obvious,
> just like how traditional hooks can change the VM or device XML,
> the hook should be able to rewrite the current request contents.
> For example, if a user would like to take over host networking configuration,
> he could just write a before_setup_networks hook that would configure
> networking however he wants, then writes the empty dictionary to the current request,
> meaning that VDSM wouldn't do anything further with the current setup networks request.
> 

+1,
I think the API above would be easy to consume.

Livnat


> 
> Assaf Muller, Cloud Networking Engineer 
> Red Hat 
> 
> ----- Original Message -----
> From: "Miguel Angel" <miguelangel at ajo.es>
> To: "Adam Litke" <alitke at redhat.com>
> Cc: dsulliva at redhat.com, arch at ovirt.org, vdsm-devel at fedorahosted.org
> Sent: Saturday, January 4, 2014 9:08:17 PM
> Subject: Re: [vdsm] Smarter network_setup hooks
> 
> Hi Adam 
> 
> Thanks for the feedback 
> 
> 2014/1/3 Adam Litke < alitke at redhat.com > 
> 
> 
> 
> On 03/01/14 12:20 +0000, Dan Kenigsberg wrote: 
> 
> 
> Recently, Miguel Angel Ajo (CCed) has added a nice functionality to the 
> implementation of setupNetworks in Vdsm: two hook points where added: 
> before and after the setupNetworks verb takes place. 
> [....] 
> Seems like a logical thing to do. What specific mechanism do you 
> suggest for passing the JSON strings to the hook script? If passed as 
> arguments to the hook script we would need to consider shell escaping 
> and argv length restrictions. 
> 
> As for the libvirt domain xml we pass to other hooks, we write a temporary file 
> and we set an environment variable pointing to it before calling the script 
> 
> 
> What about writing these out to a special file and adding a new 
> getContext() call to the hooking module. A script that is unconcerned 
> with the context would not require any changes. But a script that 
> wants access would simply do: 
> 
> ctx = hooking.getContext() 
> 
> and ctx would be the contents of the special file already decoded into 
> a native Python object for easy consumption. This could easily be 
> extended to any hook which may want to provide some context to 
> implementors. 
> 
> That would be nice, so scripts written in python wouldn't need to look for, and parse 
> the file. 
> 
> This is an example of a simple hook: 
> 
> http://gerrit.ovirt.org/#/c/20330/7/tests/functional/networkTests.py (look inside the ValidatesHook decorator) 
> 
> It'd be quite simplified. We would also need a "setContext()..." to update context with changes. 
> 
> 
> 
> One more question comes to mind: Are there any pieces of information 
> that we would need to redact from the context (passwords or other 
> sensitive information)? 
> 
> 
> I think there is no sensitive information as far as I know. 
> 
> Greetings, 
> Miguel ?ngel. 
> 
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 



From iheim at redhat.com  Wed Jan  1 00:30:11 2014
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 01 Jan 2014 02:30:11 +0200
Subject: oVirt December 2013 Updates
Message-ID: <52C36193.2030908@redhat.com>

Happy Holidays and Happy New Year!

It has been quite a year for oVirt, and I'd like to take the opportunity 
and thank everyone in out community for making it a great year for the 
project.

- oVirt 3.3.2 was released
   http://www.ovirt.org/OVirt_3.3.2_release_notes

- oVirt 3.4 is in the works

- Many oVirt sessions planned for Fosdem + oVirt booth - see you there!
   https://fosdem.org/2014/

- oVirt Contributor shirts
   Doron and Dave shipped some T-Shirts to prominently active community
   members to recognize their contribution (and thanks to Eldan for the
   graphics)
   https://twitter.com/hleclerc/status/414357959188430848
   https://twitter.com/ste_vincent/status/415502831702265856

- a new book: "Getting started with oVirt 3.3", written by community
   member Alexey Lesovsky:
   http://www.packtpub.com/getting-started-with-ovirt-3-3/book
   or via safaribooksonline: http://alturl.com/fm7ug

- An Austrian company called IT Novum migrated a 1100 machine data
   center to 100% open source, including oVirt for management (from
   VMware)
   They chronicled the migration with the Twitter tag
   #OpenSourceDataCenter
   https://twitter.com/search?q=%23OpenSourceDataCenter&src=typd

- James is trying to build a docker image for oVirt engine
   http://allthingsopen.com/2013/12/19/building-docker-images-on-fedora/

- Alon announced Experimental Gentoo support for ovirt-engine-3.3.1 is
   available:
   http://lists.ovirt.org/pipermail/users/2013-November/018156.html
   http://wiki.gentoo.org/wiki/OVirt

- iiordanov announced Android Spice Client available for beta testing
   http://lists.ovirt.org/pipermail/users/2013-December/018434.html

- Some nice "how to" added to oVirt wiki by Nkesick (cybertimber2000)
 
http://www.ovirt.org/index.php?title=How_to_create_a_Windows_8_Virtual_Machine
 
http://www.ovirt.org/index.php?title=How_to_create_a_Windows_XP_Virtual_Machine
 
http://www.ovirt.org/index.php?title=How_to_create_a_Windows_7_Virtual_Machine
 
http://www.ovirt.org/index.php?title=How_to_create_a_Ubuntu_Virtual_Machine
 
http://www.ovirt.org/index.php?title=How_to_create_a_Fedora_Virtual_Machine

- just one of those nice emails...
   "Just wanted to express my deepest admiration for the progress of this
    project. ... my quest for upgrading from 3.1 to 3.2 ... This time
    around, ... the whole process _just worked_!
    All I can say is THANK YOU! Both to you developers of oVirt and a
    special thank you to dreyou for posting such a well-written manual.
    Thank you. Thank you. Thank you:)"
    http://lists.ovirt.org/pipermail/users/2013-December/018341.html

Blogs:
- Up and Running with oVirt 3.3
   http://chenglimin.blog.51cto.com/8236854/1344083

- "oVirt 3.3.2 hackery on Fedora 19" blog post by bderzhavets
   http://alturl.com/68muq

- a new (dedicated?) ovirt blog
   http://izen.ghostpeppersrus.com/

- detailed steps for deploying/using oVirt (Japanese)
   http://alturl.com/ww25m

- Oved blogged about various ways to integrate with oVirt/RHEV
   (API, SDK, CLI, UI plugins, Scheduling API, VDSM Hooks)
   part 1 - http://alturl.com/4sytx
   part 2 - http://alturl.com/qye5f

- Use oVirt LiveCD in dual LAN network environment (Chinese)
   http://www.cnblogs.com/sztsian/p/3439873.html


From miguelangel at ajo.es  Fri Jan  3 15:09:01 2014
From: miguelangel at ajo.es (Miguel Angel)
Date: Fri, 3 Jan 2014 16:09:01 +0100
Subject: Smarter network_setup hooks
In-Reply-To: <20140103122050.GE21494@redhat.com>
References: <20140103122050.GE21494@redhat.com>
Message-ID: <CADSDy2jBgPA8TdwMGYyAa6=ytjpvBuw473x7f==bnKrfZNxWDw@mail.gmail.com>

Hello everybody,
2014/1/3 Dan Kenigsberg <danken at redhat.com>

> Recently, Miguel Angel Ajo (CCed) has added a nice functionality to the
> implementation of setupNetworks in Vdsm: two hook points where added:
> before and after the setupNetworks verb takes place.
>


Dan, thank you for starting this thread,



>
> [...]
>


>
> I'd like to discuss it here, as it introduces a new Vdsm/Hook API that
> is quite different than what we have for other hooks. Unlike with Vm
> and VmDevice creation, where Vdsm uses libvirt's xml definition
> internally as well as to communicate with the hooks,
> before/after_network_setup have to define their own means of
> communication.
>

Yes, going the xml way was the first approach, but then we realized
that the cost of maintaining a new xml schema probably wasn't worth.


> I would like to suggest to use the same information passed on the
> Engine/Vdsm API, and extend its reach into the hook script. The three
> arguments to setupNetworks(networks, bondings, options) would be dumped
> as json strings, to be read by the hook script.
>


In the last patch set I've extended it a little bit with suggestions in
gerrit,
we pass down the actual request, plus the current network configuration,
whenever the unified_persistence is enabled.

      {"request":
           {
           "networks": {"virtnet": {"bonding" : "bond0", "bridged": true,
"vlan":27}},
           "bondings": {"bond0": {"nics":["eth1","eth2"]}},
           "options":  {"conectivityCheck":false}
           },
        "current":
           {
            "networks": {"ovirtmgmt": {"nic" : "eth0", "vlan":27 }}
            "bondings": {"bond1": {"nics":["eth3","eth4"]}}
           }
        }



> This option is very simple to use and implement, it gives the hook all
> the information that Vdsm-proper has, and allows for greatest
> flexibility for hook writers. This is also the down side of this idea:
> hook script may do all kinds of things with this information, some of
> them unsupportable, and they should be notified when Engine/Vdsm API
> changes.
>
> In my opinion, it is a small price to pay: hooks have always had the
> China Store Rule - if you break something, you own it. Hook users must
> know what they're doing, and take care not to use deprecated bits of the
> API.
>
> What is your opinion? Comments and suggestions are most welcome!
>
>
My opinion the same as yours, but I'm new to this project,

If the chances for this API parameters to change are low:
In the event of that significant changes happening, we could mitigate the
problem introducing an intermediate layer to dump/load the information
from the API parameters.

I'd really like to know what do others think about this.


> Dan.
>


Cheers,
Miguel ?ngel Ajo.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20140103/c0ad0fd8/attachment.html>

From miguelangel at ajo.es  Sat Jan  4 19:08:17 2014
From: miguelangel at ajo.es (Miguel Angel)
Date: Sat, 4 Jan 2014 20:08:17 +0100
Subject: Smarter network_setup hooks
In-Reply-To: <20140103163440.GA4790@redhat.com>
References: <20140103122050.GE21494@redhat.com>
	<20140103163440.GA4790@redhat.com>
Message-ID: <CADSDy2hyaz+xrXaJzPthwpNf7ydwmk7fuyMaF_=oBDDSn+fTnA@mail.gmail.com>

Hi Adam

Thanks for the feedback

2014/1/3 Adam Litke <alitke at redhat.com>

> On 03/01/14 12:20 +0000, Dan Kenigsberg wrote:
>
>> Recently, Miguel Angel Ajo (CCed) has added a nice functionality to the
>> implementation of setupNetworks in Vdsm: two hook points where added:
>> before and after the setupNetworks verb takes place.
>> [....]
>
> Seems like a logical thing to do.  What specific mechanism do you
> suggest for passing the JSON strings to the hook script?  If passed as
> arguments to the hook script we would need to consider shell escaping
> and argv length restrictions.
>
> As for the libvirt domain xml we pass to other hooks, we write a temporary
file
and we set an environment variable pointing to it before calling the script


> What about writing these out to a special file and adding a new
> getContext() call to the hooking module.  A script that is unconcerned
> with the context would not require any changes.  But a script that
> wants access would simply do:
>
>    ctx = hooking.getContext()
>
> and ctx would be the contents of the special file already decoded into
> a native Python object for easy consumption.  This could easily be
> extended to any hook which may want to provide some context to
> implementors.
>

That would be nice, so scripts written in python wouldn't need to look for,
and parse
the file.

This is an example of a simple hook:

http://gerrit.ovirt.org/#/c/20330/7/tests/functional/networkTests.py  (look
inside the ValidatesHook decorator)


It'd be quite simplified. We would also need a "setContext()..." to update
context with changes.


>
> One more question comes to mind:  Are there any pieces of information
> that we would need to redact from the context (passwords or other
> sensitive information)?
>
>
I think there is no sensitive information as far as I know.

Greetings,
Miguel ?ngel.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20140104/61d9baf2/attachment.html>

From mail at johankooijman.com  Sat Jan  4 19:28:00 2014
From: mail at johankooijman.com (Johan Kooijman)
Date: Sat, 4 Jan 2014 20:28:00 +0100
Subject: [Users] Fwd: Your stand proposal for oVirt has been accepted
In-Reply-To: <52B012AF.1070608@redhat.com>
References: <20131216212820.74EE23F4C3@toad.stack.nl>
	<52B012AF.1070608@redhat.com>
Message-ID: <CAHvs-HUaJmnPg8qBwMhO_dqdCYoHhuoF=cFz8Agny6FWVo1UkQ@mail.gmail.com>

Will be there at the meetup!


On Tue, Dec 17, 2013 at 10:00 AM, Dave Neary <dneary at redhat.com> wrote:

> Hi everyone,
>
> Great news! We will have an oVirt stand at FOSDEM in Brussels this year!
>
> Brian and I will be looking for volunteers to man the stand and spread
> the love about oVirt over the next few weeks - please let us know if you
> plan to attend FOSDEM, we would love to see you there!
>
> Also, I would love to have an oVirt community meet-up for beers on
> Saturday evening - if we did, would you be interested in attending? Let
> us know!
>
> Thanks,
> Dave.
>
>
> -------- Original Message --------
> Subject: Your stand proposal for oVirt has been accepted
> Date: Mon, 16 Dec 2013 22:28:20 +0100 (CET)
> From: FOSDEM Stands Team <stands at fosdem.org>
> To: Dave Neary <dneary at redhat.com>
>
> Hi Dave,
>
> The FOSDEM stands team is glad to be able to inform you that your request
> for a stand for oVirt has been accepted.
> There will be one table reserved for you.
>
> You will receive further information about what's expected of you closer
> to the event date.
>
> Looking forward to seeing you at FOSDEM 2014!
>
>
> Kind regards,
>
> Wynke Stulemeijer
> FOSDEM stands team
>
>
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>



-- 
Met vriendelijke groeten / With kind regards,
Johan Kooijman

T +31(0) 6 43 44 45 27
F +31(0) 162 82 00 01
E mail at johankooijman.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20140104/1cc9149c/attachment.html>

From amedeo at oscert.net  Sun Jan  5 18:02:12 2014
From: amedeo at oscert.net (Amedeo Salvati)
Date: Sun, 05 Jan 2014 19:02:12 +0100
Subject: RFE for qemu-kvm-rhev on EL repository
In-Reply-To: <MYTNVV$D4E32324471DDE0ABD96B7EC6DABC362@oscert.net>
References: <MYTNVV$D4E32324471DDE0ABD96B7EC6DABC362@oscert.net>
Message-ID: <52C99E24.20702@oscert.net>

Il 03/01/2014 11:59, Amedeo Salvati ha scritto:
> Hi all,
>
> it's possible to include on google docs oVirt 3.4 Planning & Tracking 
> the release of qemu-kvm-rhev [1] rpm (or qemu-kvm-ovirt) on ovirt EL 
> repository?
>
> Because at this moment it's esclusion blocks live snapshot on centos 
> 6.5 / ovirt 3.3.x installations.
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1009100
>
> Best regards
> a
>
>
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch

no response from all?

let me know if you need any further information
a

-- 
Amedeo Salvati
RHC{DS,E,VA} - LPIC-3 - UCP - NCLA 11
m. +39 333 1264484
email: amedeo at oscert.net
email: amedeo at linux.com
http://plugcomputing.it/redhatcert.php
http://plugcomputing.it/lpicert.php

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20140105/fe02fade/attachment.html>

From iheim at redhat.com  Sun Jan  5 18:50:37 2014
From: iheim at redhat.com (Itamar Heim)
Date: Sun, 05 Jan 2014 20:50:37 +0200
Subject: RFE for qemu-kvm-rhev on EL repository
In-Reply-To: <52C99E24.20702@oscert.net>
References: <MYTNVV$D4E32324471DDE0ABD96B7EC6DABC362@oscert.net>
	<52C99E24.20702@oscert.net>
Message-ID: <52C9A97D.1060000@redhat.com>

On 01/05/2014 08:02 PM, Amedeo Salvati wrote:
> Il 03/01/2014 11:59, Amedeo Salvati ha scritto:
>> Hi all,
>>
>> it's possible to include on google docs oVirt 3.4 Planning & Tracking
>> the release of qemu-kvm-rhev [1] rpm (or qemu-kvm-ovirt) on ovirt EL
>> repository?
>>
>> Because at this moment it's esclusion blocks live snapshot on centos
>> 6.5 / ovirt 3.3.x installations.
>>
>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1009100
>>
>> Best regards
>> a
>>
>>
>> _______________________________________________
>> Arch mailing list
>> Arch at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/arch
>
> no response from all?
>
> let me know if you need any further information
> a
>
> --
> Amedeo Salvati
> RHC{DS,E,VA} - LPIC-3 - UCP - NCLA 11
> m. +39 333 1264484
> email:amedeo at oscert.net
> email:amedeo at linux.com
> http://plugcomputing.it/redhatcert.php
> http://plugcomputing.it/lpicert.php
>
>
>
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
>

please see:
http://lists.ovirt.org/pipermail/users/2013-December/019023.html

we're trying for CentOS to just build with these enabled, rather than 
maintain another package.


From herrold at owlriver.com  Sun Jan  5 19:13:20 2014
From: herrold at owlriver.com (R P Herrold)
Date: Sun, 5 Jan 2014 14:13:20 -0500 (EST)
Subject: RFE for qemu-kvm-rhev on EL repository
In-Reply-To: <52C9A97D.1060000@redhat.com>
References: <MYTNVV$D4E32324471DDE0ABD96B7EC6DABC362@oscert.net>
	<52C99E24.20702@oscert.net> <52C9A97D.1060000@redhat.com>
Message-ID: <alpine.LRH.2.03.1401051412230.14729@bjyevire.pbz>

On Sun, 5 Jan 2014, Itamar Heim wrote:

> please see:
> http://lists.ovirt.org/pipermail/users/2013-December/019023.html
> 
> we're trying for CentOS to just build with these enabled, rather than maintain
> another package.

I do not recall seeing a bug cross the CentOS tracker with a 
request for this yet.  Please remind me of it

-- Russ herrold


From alonbl at redhat.com  Sun Jan  5 22:05:30 2014
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Sun, 5 Jan 2014 17:05:30 -0500 (EST)
Subject: Caused by: java.io.IOException: No space left on device
In-Reply-To: <402392994.29188865.1388959480804.JavaMail.root@redhat.com>
Message-ID: <1313894863.29188887.1388959530370.JavaMail.root@redhat.com>

centos6-vm01

http://jenkins.ovirt.org/job/ovirt-engine_master_create_rpms_quick_gerrit/35/


From alonbl at redhat.com  Sun Jan  5 22:07:11 2014
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Sun, 5 Jan 2014 17:07:11 -0500 (EST)
Subject: java.lang.OutOfMemoryError
In-Reply-To: <783287586.29188940.1388959622706.JavaMail.root@redhat.com>
Message-ID: <480476816.29188942.1388959631380.JavaMail.root@redhat.com>

jenkins-slave-host03.ovirt.org

http://jenkins.ovirt.org/job/ovirt-engine_master_create_rpms_quick_gerrit/35/


From miguelangel at ajo.es  Sun Jan  5 22:41:44 2014
From: miguelangel at ajo.es (Miguel Angel)
Date: Sun, 5 Jan 2014 23:41:44 +0100
Subject: [vdsm] Smarter network_setup hooks
In-Reply-To: <52C93942.1030501@redhat.com>
References: <20140103122050.GE21494@redhat.com>
	<20140103163440.GA4790@redhat.com>
	<CADSDy2hyaz+xrXaJzPthwpNf7ydwmk7fuyMaF_=oBDDSn+fTnA@mail.gmail.com>
	<1285621619.3259554.1388916359128.JavaMail.root@redhat.com>
	<52C93942.1030501@redhat.com>
Message-ID: <CADSDy2jZW4zsi=FVjJ+78YefH7zMcgu689q+gqj4nLwJ5JwWdQ@mail.gmail.com>

2014/1/5 Livnat Peer <lpeer at redhat.com>

> On 01/05/2014 12:05 PM, Assaf Muller wrote:
> > Whichever way we decide to do this, I think the important bit is
> documentation - We have
> > to make sure to update the oVirt wiki hooks pages. If users aren't aware
> of how to retrieve
> > the networking config then we might as well not implement it.
> >
> > That being said, I'd expose three dictionaries: What's currently
> configure,
> > the current request, as well as the proposed end result. It's easy to add
> > and I see how it would be useful to hook writers. And just to state the
> obvious,
> > just like how traditional hooks can change the VM or device XML,
> > the hook should be able to rewrite the current request contents.
> > For example, if a user would like to take over host networking
> configuration,
> > he could just write a before_setup_networks hook that would configure
> > networking however he wants, then writes the empty dictionary to the
> current request,
> > meaning that VDSM wouldn't do anything further with the current setup
> networks request.
> >
>
>
I'm not sure if it's easy to get the final state without actually applying
it, it's easy
to get an approximate final state (just aggregating dictionaries to
networks and bondings,
and erasing the removed ones), but I suppose that'd be good enough :-)


May be it's good if you can provide a use case for this third "expected"
final state,
I can't come up with one. :-)




> +1,
> I think the API above would be easy to consume.
>
> Livnat
>
>
> >
> > Assaf Muller, Cloud Networking Engineer
> > Red Hat
> >
> > ----- Original Message -----
> > From: "Miguel Angel" <miguelangel at ajo.es>
> > To: "Adam Litke" <alitke at redhat.com>
> > Cc: dsulliva at redhat.com, arch at ovirt.org, vdsm-devel at fedorahosted.org
> > Sent: Saturday, January 4, 2014 9:08:17 PM
> > Subject: Re: [vdsm] Smarter network_setup hooks
> >
> > Hi Adam
> >
> > Thanks for the feedback
> >
> > 2014/1/3 Adam Litke < alitke at redhat.com >
> >
> >
> >
> > On 03/01/14 12:20 +0000, Dan Kenigsberg wrote:
> >
> >
> > Recently, Miguel Angel Ajo (CCed) has added a nice functionality to the
> > implementation of setupNetworks in Vdsm: two hook points where added:
> > before and after the setupNetworks verb takes place.
> > [....]
> > Seems like a logical thing to do. What specific mechanism do you
> > suggest for passing the JSON strings to the hook script? If passed as
> > arguments to the hook script we would need to consider shell escaping
> > and argv length restrictions.
> >
> > As for the libvirt domain xml we pass to other hooks, we write a
> temporary file
> > and we set an environment variable pointing to it before calling the
> script
> >
> >
> > What about writing these out to a special file and adding a new
> > getContext() call to the hooking module. A script that is unconcerned
> > with the context would not require any changes. But a script that
> > wants access would simply do:
> >
> > ctx = hooking.getContext()
> >
> > and ctx would be the contents of the special file already decoded into
> > a native Python object for easy consumption. This could easily be
> > extended to any hook which may want to provide some context to
> > implementors.
> >
> > That would be nice, so scripts written in python wouldn't need to look
> for, and parse
> > the file.
> >
> > This is an example of a simple hook:
> >
> > http://gerrit.ovirt.org/#/c/20330/7/tests/functional/networkTests.py(look inside the ValidatesHook decorator)
> >
> > It'd be quite simplified. We would also need a "setContext()..." to
> update context with changes.
> >
> >
> >
> > One more question comes to mind: Are there any pieces of information
> > that we would need to redact from the context (passwords or other
> > sensitive information)?
> >
> >
> > I think there is no sensitive information as far as I know.
> >
> > Greetings,
> > Miguel ?ngel.
> >
> > _______________________________________________
> > vdsm-devel mailing list
> > vdsm-devel at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> > _______________________________________________
> > Arch mailing list
> > Arch at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/arch
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20140105/6c8e531f/attachment.html>

From asegurap at redhat.com  Mon Jan  6 01:58:07 2014
From: asegurap at redhat.com (Antoni Segura Puimedon)
Date: Sun, 5 Jan 2014 20:58:07 -0500 (EST)
Subject: [vdsm] Smarter network_setup hooks
In-Reply-To: <CADSDy2jZW4zsi=FVjJ+78YefH7zMcgu689q+gqj4nLwJ5JwWdQ@mail.gmail.com>
References: <20140103122050.GE21494@redhat.com>
	<20140103163440.GA4790@redhat.com>
	<CADSDy2hyaz+xrXaJzPthwpNf7ydwmk7fuyMaF_=oBDDSn+fTnA@mail.gmail.com>
	<1285621619.3259554.1388916359128.JavaMail.root@redhat.com>
	<52C93942.1030501@redhat.com>
	<CADSDy2jZW4zsi=FVjJ+78YefH7zMcgu689q+gqj4nLwJ5JwWdQ@mail.gmail.com>
Message-ID: <458184000.29203894.1388973487200.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Miguel Angel" <miguelangel at ajo.es>
> To: "Livnat Peer" <lpeer at redhat.com>
> Cc: dsulliva at redhat.com, vdsm-devel at fedorahosted.org, arch at ovirt.org
> Sent: Sunday, January 5, 2014 11:41:44 PM
> Subject: Re: [vdsm] Smarter network_setup hooks
> 
> 
> 2014/1/5 Livnat Peer < lpeer at redhat.com >
> 
> 
> 
> On 01/05/2014 12:05 PM, Assaf Muller wrote:
> > Whichever way we decide to do this, I think the important bit is
> > documentation - We have
> > to make sure to update the oVirt wiki hooks pages. If users aren't aware of
> > how to retrieve
> > the networking config then we might as well not implement it.
> > 
> > That being said, I'd expose three dictionaries: What's currently configure,
> > the current request, as well as the proposed end result. It's easy to add
> > and I see how it would be useful to hook writers. And just to state the
> > obvious,
> > just like how traditional hooks can change the VM or device XML,
> > the hook should be able to rewrite the current request contents.
> > For example, if a user would like to take over host networking
> > configuration,
> > he could just write a before_setup_networks hook that would configure
> > networking however he wants, then writes the empty dictionary to the
> > current request,
> > meaning that VDSM wouldn't do anything further with the current setup
> > networks request.

My original thought on this was that the hook would be able to mark a device
as configured by it adding a key value like 'hooked': X. This was in order
that if, for example a bond is to be configured by the hook, it would still
stay in the config passed to objectivize but the configurator configure method
for it would be short circuited and X would have the data that is to be put
in the running config by vdsm for that device.

I didn't mature this thought much though... (holidays have kept me a bit busy)

> > 
> 
> 
> I'm not sure if it's easy to get the final state without actually applying
> it, it's easy
> to get an approximate final state (just aggregating dictionaries to networks
> and bondings,
> and erasing the removed ones), but I suppose that'd be good enough :-)
> 
> 
> May be it's good if you can provide a use case for this third "expected"
> final state,
> I can't come up with one. :-)

For this reason I thought of the 'hooked' value, to make the hook writer own
the task of filling in the missing piece of state.


One final consideration that I didn't see arise is the need for having caps
hooks. As soon as we allow setupNetworks hooks it is very necessary that we
enable vdsm caps. One very easy example.

Let us say that I write a hook that makes setupNetworks specified bondings
be configured in the system by libteam/teamd. In order for the changes to
be made visible to the engine we need to fake that team link aggregation
as a bond so that the engine can, in the future, change/delete/use it.
> 
> 
> 
> 
> 
> +1,
> I think the API above would be easy to consume.
> 
> Livnat
> 
> 
> > 
> > Assaf Muller, Cloud Networking Engineer
> > Red Hat
> > 
> > ----- Original Message -----
> > From: "Miguel Angel" < miguelangel at ajo.es >
> > To: "Adam Litke" < alitke at redhat.com >
> > Cc: dsulliva at redhat.com , arch at ovirt.org , vdsm-devel at fedorahosted.org
> > Sent: Saturday, January 4, 2014 9:08:17 PM
> > Subject: Re: [vdsm] Smarter network_setup hooks
> > 
> > Hi Adam
> > 
> > Thanks for the feedback
> > 
> > 2014/1/3 Adam Litke < alitke at redhat.com >
> > 
> > 
> > 
> > On 03/01/14 12:20 +0000, Dan Kenigsberg wrote:
> > 
> > 
> > Recently, Miguel Angel Ajo (CCed) has added a nice functionality to the
> > implementation of setupNetworks in Vdsm: two hook points where added:
> > before and after the setupNetworks verb takes place.
> > [....]
> > Seems like a logical thing to do. What specific mechanism do you
> > suggest for passing the JSON strings to the hook script? If passed as
> > arguments to the hook script we would need to consider shell escaping
> > and argv length restrictions.
> > 
> > As for the libvirt domain xml we pass to other hooks, we write a temporary
> > file
> > and we set an environment variable pointing to it before calling the script
> > 
> > 
> > What about writing these out to a special file and adding a new
> > getContext() call to the hooking module. A script that is unconcerned
> > with the context would not require any changes. But a script that
> > wants access would simply do:
> > 
> > ctx = hooking.getContext()
> > 
> > and ctx would be the contents of the special file already decoded into
> > a native Python object for easy consumption. This could easily be
> > extended to any hook which may want to provide some context to
> > implementors.
> > 
> > That would be nice, so scripts written in python wouldn't need to look for,
> > and parse
> > the file.
> > 
> > This is an example of a simple hook:
> > 
> > http://gerrit.ovirt.org/#/c/20330/7/tests/functional/networkTests.py (look
> > inside the ValidatesHook decorator)
> > 
> > It'd be quite simplified. We would also need a "setContext()..." to update
> > context with changes.
> > 
> > 
> > 
> > One more question comes to mind: Are there any pieces of information
> > that we would need to redact from the context (passwords or other
> > sensitive information)?
> > 
> > 
> > I think there is no sensitive information as far as I know.
> > 
> > Greetings,
> > Miguel ?ngel.
> > 
> > _______________________________________________
> > vdsm-devel mailing list
> > vdsm-devel at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> > _______________________________________________
> > Arch mailing list
> > Arch at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/arch
> > 
> 
> 
> 
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> 


From dneary at redhat.com  Mon Jan  6 09:11:23 2014
From: dneary at redhat.com (Dave Neary)
Date: Mon, 06 Jan 2014 10:11:23 +0100
Subject: [Users] Fwd: Your stand proposal for oVirt has been accepted
In-Reply-To: <CAHvs-HUaJmnPg8qBwMhO_dqdCYoHhuoF=cFz8Agny6FWVo1UkQ@mail.gmail.com>
References: <20131216212820.74EE23F4C3@toad.stack.nl>	<52B012AF.1070608@redhat.com>
	<CAHvs-HUaJmnPg8qBwMhO_dqdCYoHhuoF=cFz8Agny6FWVo1UkQ@mail.gmail.com>
Message-ID: <52CA733B.3000706@redhat.com>

Awesome! See you there.

Dave.

On 01/04/2014 08:28 PM, Johan Kooijman wrote:
> Will be there at the meetup!
> 
> 
> On Tue, Dec 17, 2013 at 10:00 AM, Dave Neary <dneary at redhat.com
> <mailto:dneary at redhat.com>> wrote:
> 
>     Hi everyone,
> 
>     Great news! We will have an oVirt stand at FOSDEM in Brussels this year!
> 
>     Brian and I will be looking for volunteers to man the stand and spread
>     the love about oVirt over the next few weeks - please let us know if you
>     plan to attend FOSDEM, we would love to see you there!
> 
>     Also, I would love to have an oVirt community meet-up for beers on
>     Saturday evening - if we did, would you be interested in attending? Let
>     us know!
> 
>     Thanks,
>     Dave.
> 
> 
>     -------- Original Message --------
>     Subject: Your stand proposal for oVirt has been accepted
>     Date: Mon, 16 Dec 2013 22:28:20 +0100 (CET)
>     From: FOSDEM Stands Team <stands at fosdem.org <mailto:stands at fosdem.org>>
>     To: Dave Neary <dneary at redhat.com <mailto:dneary at redhat.com>>
> 
>     Hi Dave,
> 
>     The FOSDEM stands team is glad to be able to inform you that your
>     request
>     for a stand for oVirt has been accepted.
>     There will be one table reserved for you.
> 
>     You will receive further information about what's expected of you closer
>     to the event date.
> 
>     Looking forward to seeing you at FOSDEM 2014!
> 
> 
>     Kind regards,
> 
>     Wynke Stulemeijer
>     FOSDEM stands team
> 
> 
>     _______________________________________________
>     Users mailing list
>     Users at ovirt.org <mailto:Users at ovirt.org>
>     http://lists.ovirt.org/mailman/listinfo/users
> 
> 
> 
> 
> -- 
> Met vriendelijke groeten / With kind regards,
> Johan Kooijman
> 
> T +31(0) 6 43 44 45 27
> F +31(0) 162 82 00 01
> E mail at johankooijman.com <mailto:mail at johankooijman.com>

-- 
Dave Neary - Community Action and Impact
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13


From danken at redhat.com  Mon Jan  6 11:45:47 2014
From: danken at redhat.com (Dan Kenigsberg)
Date: Mon, 6 Jan 2014 11:45:47 +0000
Subject: [vdsm] Smarter network_setup hooks
In-Reply-To: <1285621619.3259554.1388916359128.JavaMail.root@redhat.com>
References: <20140103122050.GE21494@redhat.com>
	<20140103163440.GA4790@redhat.com>
	<CADSDy2hyaz+xrXaJzPthwpNf7ydwmk7fuyMaF_=oBDDSn+fTnA@mail.gmail.com>
	<1285621619.3259554.1388916359128.JavaMail.root@redhat.com>
Message-ID: <20140106114547.GJ15185@redhat.com>

On Sun, Jan 05, 2014 at 05:05:59AM -0500, Assaf Muller wrote:
> Whichever way we decide to do this, I think the important bit is documentation - We have
> to make sure to update the oVirt wiki hooks pages. If users aren't aware of how to retrieve
> the networking config then we might as well not implement it.
> 
> That being said, I'd expose three dictionaries: What's currently configure,
> the current request, as well as the proposed end result.

I do not see why "current" is a good idea to pass from Vdsm to the hook
- if the hook needs it, it could compute the current state on its own.

What do you mean by the "proposed end result"? setupNetwork API works in
allows "diffs" relative to the current state. The end result, however,
may even be unexpressable within the scope of our API (that's exactly
what hooks are for!). And again, if Vdsm is able to calculate the end
result based on the current state + diff, so can the hook itself.

> It's easy to add
> and I see how it would be useful to hook writers. And just to state the obvious,
> just like how traditional hooks can change the VM or device XML,
> the hook should be able to rewrite the current request contents.
> For example, if a user would like to take over host networking configuration,
> he could just write a before_setup_networks hook that would configure
> networking however he wants, then writes the empty dictionary to the current request,
> meaning that VDSM wouldn't do anything further with the current setup networks request.

This would be a very good additions. Cascaded scripts would then be able
to drop parts of the command, which they have implemented themselves.

Regards,
Dan.


From danken at redhat.com  Mon Jan  6 11:54:19 2014
From: danken at redhat.com (Dan Kenigsberg)
Date: Mon, 6 Jan 2014 11:54:19 +0000
Subject: [vdsm] Smarter network_setup hooks
In-Reply-To: <458184000.29203894.1388973487200.JavaMail.root@redhat.com>
References: <20140103122050.GE21494@redhat.com>
	<20140103163440.GA4790@redhat.com>
	<CADSDy2hyaz+xrXaJzPthwpNf7ydwmk7fuyMaF_=oBDDSn+fTnA@mail.gmail.com>
	<1285621619.3259554.1388916359128.JavaMail.root@redhat.com>
	<52C93942.1030501@redhat.com>
	<CADSDy2jZW4zsi=FVjJ+78YefH7zMcgu689q+gqj4nLwJ5JwWdQ@mail.gmail.com>
	<458184000.29203894.1388973487200.JavaMail.root@redhat.com>
Message-ID: <20140106115419.GK15185@redhat.com>

On Sun, Jan 05, 2014 at 08:58:07PM -0500, Antoni Segura Puimedon wrote:
> 
> 
> ----- Original Message -----
> > From: "Miguel Angel" <miguelangel at ajo.es>
> > To: "Livnat Peer" <lpeer at redhat.com>
> > Cc: dsulliva at redhat.com, vdsm-devel at fedorahosted.org, arch at ovirt.org
> > Sent: Sunday, January 5, 2014 11:41:44 PM
> > Subject: Re: [vdsm] Smarter network_setup hooks
> > 
> > 
> > 2014/1/5 Livnat Peer < lpeer at redhat.com >
> > 
> > 
> > 
> > On 01/05/2014 12:05 PM, Assaf Muller wrote:
> > > Whichever way we decide to do this, I think the important bit is
> > > documentation - We have
> > > to make sure to update the oVirt wiki hooks pages. If users aren't aware of
> > > how to retrieve
> > > the networking config then we might as well not implement it.
> > > 
> > > That being said, I'd expose three dictionaries: What's currently configure,
> > > the current request, as well as the proposed end result. It's easy to add
> > > and I see how it would be useful to hook writers. And just to state the
> > > obvious,
> > > just like how traditional hooks can change the VM or device XML,
> > > the hook should be able to rewrite the current request contents.
> > > For example, if a user would like to take over host networking
> > > configuration,
> > > he could just write a before_setup_networks hook that would configure
> > > networking however he wants, then writes the empty dictionary to the
> > > current request,
> > > meaning that VDSM wouldn't do anything further with the current setup
> > > networks request.
> 
> My original thought on this was that the hook would be able to mark a device
> as configured by it adding a key value like 'hooked': X. This was in order
> that if, for example a bond is to be configured by the hook, it would still
> stay in the config passed to objectivize but the configurator configure method
> for it would be short circuited and X would have the data that is to be put
> in the running config by vdsm for that device.
> 
> I didn't mature this thought much though... (holidays have kept me a bit busy)

Oh, few seconds ago I noted about the idea that hooks scripts would be
able to remove parts of the configuration which they have already
implemented, so that Vdsm proper is left unaware of them.

It's not as flexible as your "hooked=True" suggestion, as it does not
alow to implement only part of a network, but I think that it is
as-powerful and with clearer atomicity.

> 
> > > 
> > 
> > 
> > I'm not sure if it's easy to get the final state without actually applying
> > it, it's easy
> > to get an approximate final state (just aggregating dictionaries to networks
> > and bondings,
> > and erasing the removed ones), but I suppose that'd be good enough :-)
> > 
> > 
> > May be it's good if you can provide a use case for this third "expected"
> > final state,
> > I can't come up with one. :-)
> 
> For this reason I thought of the 'hooked' value, to make the hook writer own
> the task of filling in the missing piece of state.

Sorry, Toni, I do not understaed how hooked=True is related to the
"expected" dictionary suggested by Assaf.

> One final consideration that I didn't see arise is the need for having caps
> hooks. As soon as we allow setupNetworks hooks it is very necessary that we
> enable vdsm caps. One very easy example.
> 
> Let us say that I write a hook that makes setupNetworks specified bondings
> be configured in the system by libteam/teamd. In order for the changes to
> be made visible to the engine we need to fake that team link aggregation
> as a bond so that the engine can, in the future, change/delete/use it.

Correct. The same json-based framework devised by Miguel (as well as
Adam's getContext) would come up hand when implementing it.

Dan.


From alitke at redhat.com  Mon Jan  6 13:32:07 2014
From: alitke at redhat.com (Adam Litke)
Date: Mon, 6 Jan 2014 08:32:07 -0500
Subject: Smarter network_setup hooks
In-Reply-To: <CADSDy2hyaz+xrXaJzPthwpNf7ydwmk7fuyMaF_=oBDDSn+fTnA@mail.gmail.com>
References: <20140103122050.GE21494@redhat.com>
	<20140103163440.GA4790@redhat.com>
	<CADSDy2hyaz+xrXaJzPthwpNf7ydwmk7fuyMaF_=oBDDSn+fTnA@mail.gmail.com>
Message-ID: <20140106133207.GA31032@redhat.com>

On 04/01/14 20:08 +0100, Miguel Angel wrote:
>Hi Adam
>
>Thanks for the feedback
>
>2014/1/3 Adam Litke <alitke at redhat.com>
>
>> On 03/01/14 12:20 +0000, Dan Kenigsberg wrote:
>>
>>> Recently, Miguel Angel Ajo (CCed) has added a nice functionality to the
>>> implementation of setupNetworks in Vdsm: two hook points where added:
>>> before and after the setupNetworks verb takes place.
>>> [....]
>>
>> Seems like a logical thing to do.  What specific mechanism do you
>> suggest for passing the JSON strings to the hook script?  If passed as
>> arguments to the hook script we would need to consider shell escaping
>> and argv length restrictions.
>>
>> As for the libvirt domain xml we pass to other hooks, we write a temporary
>file
>and we set an environment variable pointing to it before calling the script
>
>
>> What about writing these out to a special file and adding a new
>> getContext() call to the hooking module.  A script that is unconcerned
>> with the context would not require any changes.  But a script that
>> wants access would simply do:
>>
>>    ctx = hooking.getContext()
>>
>> and ctx would be the contents of the special file already decoded into
>> a native Python object for easy consumption.  This could easily be
>> extended to any hook which may want to provide some context to
>> implementors.
>>
>
>That would be nice, so scripts written in python wouldn't need to look for,
>and parse
>the file.
>
>This is an example of a simple hook:
>
>http://gerrit.ovirt.org/#/c/20330/7/tests/functional/networkTests.py  (look
>inside the ValidatesHook decorator)
>
>
>It'd be quite simplified. We would also need a "setContext()..." to update
>context with changes.

Yeah seems reasonable.  Then hook scripts can become much simpler and
easier to read and write:

ctx = hooking.getContext()
ctx['foo'] = 'bar'
hooking.setContext(ctx)

>
>
>>
>> One more question comes to mind:  Are there any pieces of information
>> that we would need to redact from the context (passwords or other
>> sensitive information)?
>>
>>
>I think there is no sensitive information as far as I know.
>
>Greetings,
>Miguel ?ngel.


From mrao at redhat.com  Mon Jan  6 19:09:44 2014
From: mrao at redhat.com (Malini Rao)
Date: Mon, 6 Jan 2014 14:09:44 -0500 (EST)
Subject: Single Disk Snapshot Feature
In-Reply-To: <1289649020.52035943.1387129206895.JavaMail.root@redhat.com>
References: <1289649020.52035943.1387129206895.JavaMail.root@redhat.com>
Message-ID: <883112546.49300895.1389035384862.JavaMail.root@redhat.com>

Daniel, 

I went through the feature page and I have some questions ( mainly from the user experience perspective) that may be about the feature or about snapshots itself..not sure -

1. Will the ability to choose disks be available only when I click on 'Create Snapshot' button on the tool bar or even when I right click an existing snapshot and trigger the create snapshot flow?

2. I am a little concerned about the Custom preview option in terms of how intuitive that might be. Would it be more intuitive if there was a way for the user to select multiple snapshots in the list and then click preview to get all those selected snapshots as rows with disk selection possible? My concern is that even though 'Preview' and 'Custom preview' are presented together, they behave differently - preview will send them to the preview flow for that single snapshot while, the custom preview dialog is really independent of any row selection of the snapshot list. If the multiple selection option I described will not work for any reason, then I think having a separate button with a more descriptive name such as 'Hybrid Snapshot' might help.

3. In the custom preview dialog, what is the column with the radio button and is that somehow related with row selection? Right now, it is creating confusion for me because it seems like I pick a snapshot with this radio button in addition to the row highlighting and then that expectation falls apart since I am able to select across rows on the disks columns. Maybe what is needed here is to remove the row highlighting for starters and also pull out the display(?) column out of the list and have a single select drop down at the bottom of the dialog so that in the grid, all you are doing is disk selection. Or maybe at least move the radio button column to the right, so it doesn't confuse with selection.

4. Also, I wanted to know how many disks can we expect per row on an avg? I ask to see if the matrix format is the most suitable or if we need to think of other layouts...

Thanks
Malini 

----- Original Message -----
From: "Daniel Erez" <derez at redhat.com>
To: arch at ovirt.org
Sent: Sunday, December 15, 2013 12:40:06 PM
Subject: Single Disk Snapshot Feature

Hi,

"Single Disk Snapshot" feature is targeted to 3.4.
Please review the wiki page [1] and feel free to
share your thoughts.

[1] http://www.ovirt.org/Features/Single_Disk_Snapshot

Regards,
Daniel
_______________________________________________
Arch mailing list
Arch at ovirt.org
http://lists.ovirt.org/mailman/listinfo/arch


From derez at redhat.com  Mon Jan  6 21:52:35 2014
From: derez at redhat.com (Daniel Erez)
Date: Mon, 6 Jan 2014 16:52:35 -0500 (EST)
Subject: Single Disk Snapshot Feature
In-Reply-To: <883112546.49300895.1389035384862.JavaMail.root@redhat.com>
References: <1289649020.52035943.1387129206895.JavaMail.root@redhat.com>
	<883112546.49300895.1389035384862.JavaMail.root@redhat.com>
Message-ID: <220340629.3966988.1389045155503.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Malini Rao" <mrao at redhat.com>
> To: "Daniel Erez" <derez at redhat.com>
> Cc: arch at ovirt.org
> Sent: Monday, January 6, 2014 9:09:44 PM
> Subject: Re: Single Disk Snapshot Feature
> 
> Daniel,
> 
> I went through the feature page and I have some questions ( mainly from the
> user experience perspective) that may be about the feature or about
> snapshots itself..not sure -
> 
> 1. Will the ability to choose disks be available only when I click on 'Create
> Snapshot' button on the tool bar or even when I right click an existing
> snapshot and trigger the create snapshot flow?

Disks selection will be available only when creating a new snapshot.
Currently, editing an existing snapshot is not applicable.

> 
> 2. I am a little concerned about the Custom preview option in terms of how
> intuitive that might be. Would it be more intuitive if there was a way for
> the user to select multiple snapshots in the list and then click preview to
> get all those selected snapshots as rows with disk selection possible? My
> concern is that even though 'Preview' and 'Custom preview' are presented
> together, they behave differently - preview will send them to the preview
> flow for that single snapshot while, the custom preview dialog is really
> independent of any row selection of the snapshot list. If the multiple
> selection option I described will not work for any reason, then I think
> having a separate button with a more descriptive name such as 'Hybrid
> Snapshot' might help.

You're right, I was concerned as well regarding the non-reliance of
the custom button and row selection. However, currently, multiple
selection is not relevant for any other action (i.e. multiple selection
will enforce graying out all the others buttons). In addition, I'm not
sure it would be more intuitive for the user to select more than one snapshot
just for doing a custom preview (as for now, multiple selection is prohibited
in this sub-tab). Do you think that separating to a different (regular)
action button could work better here? (btw, not sure about 'Hybrid Snapshot'
as the dialog is actually invoking only a preview of a snapshot rather
than creating one. 'Hybrid Preview' sounds good? :)

> 
> 3. In the custom preview dialog, what is the column with the radio button and
> is that somehow related with row selection? Right now, it is creating
> confusion for me because it seems like I pick a snapshot with this radio
> button in addition to the row highlighting and then that expectation falls
> apart since I am able to select across rows on the disks columns. Maybe what
> is needed here is to remove the row highlighting for starters and also pull
> out the display(?) column out of the list and have a single select drop down
> at the bottom of the dialog so that in the grid, all you are doing is disk
> selection. Or maybe at least move the radio button column to the right, so
> it doesn't confuse with selection.

The radio button column is for the snapshot's 'VM configuration' which 
consists of the other attributes of a VM. E.g. name/description/cpu/nics/apps/etc.
I.e. this dialog allows mix-n-match only for the disks, other components
of the snapshot aren't configurable.
So a single drop down won't work here as every snapshot might contain
a different VM configuration, from which the user can choose.
Regarding the row selection - you're right, I've been already told it's
quite confusing. I removed it from my implementation drafts but just
hadn't have a chance to update the video yet...

> 
> 4. Also, I wanted to know how many disks can we expect per row on an avg? I
> ask to see if the matrix format is the most suitable or if we need to think
> of other layouts...

We've tried a few variations scrolling for the dialog, e.g. keeping the
left hand columns (Date/Name/VM configuration) static and allow 
horizontal scrolling only for the disks. But it seems that for
most use-cases, we'll have many snapshots and only a few disks.
Hence, it'll probably better ux-wise to keep the dialog cleaner
and simpler for the common use-cases while supporting rare
scenarios with (regular) scrollbars for the entire table.

Let me know what you think, thanks a lot for the feedback!

> 
> Thanks
> Malini
> 
> ----- Original Message -----
> From: "Daniel Erez" <derez at redhat.com>
> To: arch at ovirt.org
> Sent: Sunday, December 15, 2013 12:40:06 PM
> Subject: Single Disk Snapshot Feature
> 
> Hi,
> 
> "Single Disk Snapshot" feature is targeted to 3.4.
> Please review the wiki page [1] and feel free to
> share your thoughts.
> 
> [1] http://www.ovirt.org/Features/Single_Disk_Snapshot
> 
> Regards,
> Daniel
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From mrao at redhat.com  Tue Jan  7 22:08:29 2014
From: mrao at redhat.com (Malini Rao)
Date: Tue, 7 Jan 2014 17:08:29 -0500 (EST)
Subject: Single Disk Snapshot Feature
In-Reply-To: <220340629.3966988.1389045155503.JavaMail.root@redhat.com>
References: <1289649020.52035943.1387129206895.JavaMail.root@redhat.com>
	<883112546.49300895.1389035384862.JavaMail.root@redhat.com>
	<220340629.3966988.1389045155503.JavaMail.root@redhat.com>
Message-ID: <194176282.50547554.1389132509934.JavaMail.root@redhat.com>


----- Original Message -----
> From: "Daniel Erez" <derez at redhat.com>
> To: "Malini Rao" <mrao at redhat.com>
> Cc: arch at ovirt.org
> Sent: Monday, January 6, 2014 4:52:35 PM
> Subject: Re: Single Disk Snapshot Feature
> 
> 
> 
> ----- Original Message -----
> > From: "Malini Rao" <mrao at redhat.com>
> > To: "Daniel Erez" <derez at redhat.com>
> > Cc: arch at ovirt.org
> > Sent: Monday, January 6, 2014 9:09:44 PM
> > Subject: Re: Single Disk Snapshot Feature
> > 
> > Daniel,
> > 
> > I went through the feature page and I have some questions ( mainly from the
> > user experience perspective) that may be about the feature or about
> > snapshots itself..not sure -
> > 
> > 1. Will the ability to choose disks be available only when I click on
> > 'Create
> > Snapshot' button on the tool bar or even when I right click an existing
> > snapshot and trigger the create snapshot flow?
> 
> Disks selection will be available only when creating a new snapshot.
> Currently, editing an existing snapshot is not applicable.

MR: I didn't mean editing a snapshot.. I am thinking when I right click an existing snapshot and access the create snapshot, it is basing the configurations of the new snapshot on the selected existing snapshot... right? So, if the existing snapshot has multiple disks, will the new one also have the multiple disks and can the user in this flow tweak that selection?

> 
> > 
> > 2. I am a little concerned about the Custom preview option in terms of how
> > intuitive that might be. Would it be more intuitive if there was a way for
> > the user to select multiple snapshots in the list and then click preview to
> > get all those selected snapshots as rows with disk selection possible? My
> > concern is that even though 'Preview' and 'Custom preview' are presented
> > together, they behave differently - preview will send them to the preview
> > flow for that single snapshot while, the custom preview dialog is really
> > independent of any row selection of the snapshot list. If the multiple
> > selection option I described will not work for any reason, then I think
> > having a separate button with a more descriptive name such as 'Hybrid
> > Snapshot' might help.
> 
> You're right, I was concerned as well regarding the non-reliance of
> the custom button and row selection. However, currently, multiple
> selection is not relevant for any other action (i.e. multiple selection
> will enforce graying out all the others buttons). In addition, I'm not
> sure it would be more intuitive for the user to select more than one snapshot
> just for doing a custom preview (as for now, multiple selection is prohibited
> in this sub-tab). Do you think that separating to a different (regular)
> action button could work better here? (btw, not sure about 'Hybrid Snapshot'
> as the dialog is actually invoking only a preview of a snapshot rather
> than creating one. 'Hybrid Preview' sounds good? :)

MR: I think a separate button will help. Even though it is a bit long,  how about 'Define Custom Snapshot Preview'?

> 
> > 
> > 3. In the custom preview dialog, what is the column with the radio button
> > and
> > is that somehow related with row selection? Right now, it is creating
> > confusion for me because it seems like I pick a snapshot with this radio
> > button in addition to the row highlighting and then that expectation falls
> > apart since I am able to select across rows on the disks columns. Maybe
> > what
> > is needed here is to remove the row highlighting for starters and also pull
> > out the display(?) column out of the list and have a single select drop
> > down
> > at the bottom of the dialog so that in the grid, all you are doing is disk
> > selection. Or maybe at least move the radio button column to the right, so
> > it doesn't confuse with selection.
> 
> The radio button column is for the snapshot's 'VM configuration' which
> consists of the other attributes of a VM. E.g.
> name/description/cpu/nics/apps/etc.
> I.e. this dialog allows mix-n-match only for the disks, other components
> of the snapshot aren't configurable.
> So a single drop down won't work here as every snapshot might contain
> a different VM configuration, from which the user can choose.
> Regarding the row selection - you're right, I've been already told it's
> quite confusing. I removed it from my implementation drafts but just
> hadn't have a chance to update the video yet...

MR: Daniel, just so it is clear, the drop down will list the snapshots. See attachment of a mockup I tweaked from yours. Would this not work?


> 
> > 
> > 4. Also, I wanted to know how many disks can we expect per row on an avg? I
> > ask to see if the matrix format is the most suitable or if we need to think
> > of other layouts...
> 
> We've tried a few variations scrolling for the dialog, e.g. keeping the
> left hand columns (Date/Name/VM configuration) static and allow
> horizontal scrolling only for the disks. But it seems that for
> most use-cases, we'll have many snapshots and only a few disks.
> Hence, it'll probably better ux-wise to keep the dialog cleaner
> and simpler for the common use-cases while supporting rare
> scenarios with (regular) scrollbars for the entire table.

MR: I think the static columns on the left are a great idea but that should appear only when the scroll becomes necessary. When the number of disks are small, which is possibly mostly, then the dialog is simple. But even though it is an edge case, I think if the snapshots column did not stay static, the scroll would be meaningless since you don;t know what you are picking anymore.


> 
> Let me know what you think, thanks a lot for the feedback!
> 
> > 
> > Thanks
> > Malini
> > 
> > ----- Original Message -----
> > From: "Daniel Erez" <derez at redhat.com>
> > To: arch at ovirt.org
> > Sent: Sunday, December 15, 2013 12:40:06 PM
> > Subject: Single Disk Snapshot Feature
> > 
> > Hi,
> > 
> > "Single Disk Snapshot" feature is targeted to 3.4.
> > Please review the wiki page [1] and feel free to
> > share your thoughts.
> > 
> > [1] http://www.ovirt.org/Features/Single_Disk_Snapshot
> > 
> > Regards,
> > Daniel
> > _______________________________________________
> > Arch mailing list
> > Arch at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/arch
> > 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Multi disk selection.png
Type: image/png
Size: 227086 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20140107/a7c683d6/attachment.png>

From derez at redhat.com  Wed Jan  8 06:31:11 2014
From: derez at redhat.com (Daniel Erez)
Date: Wed, 8 Jan 2014 01:31:11 -0500 (EST)
Subject: Single Disk Snapshot Feature
In-Reply-To: <194176282.50547554.1389132509934.JavaMail.root@redhat.com>
References: <1289649020.52035943.1387129206895.JavaMail.root@redhat.com>
	<883112546.49300895.1389035384862.JavaMail.root@redhat.com>
	<220340629.3966988.1389045155503.JavaMail.root@redhat.com>
	<194176282.50547554.1389132509934.JavaMail.root@redhat.com>
Message-ID: <591832064.5215928.1389162671198.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Malini Rao" <mrao at redhat.com>
> To: "Daniel Erez" <derez at redhat.com>
> Cc: arch at ovirt.org
> Sent: Wednesday, January 8, 2014 12:08:29 AM
> Subject: Re: Single Disk Snapshot Feature
> 
> 
> ----- Original Message -----
> > From: "Daniel Erez" <derez at redhat.com>
> > To: "Malini Rao" <mrao at redhat.com>
> > Cc: arch at ovirt.org
> > Sent: Monday, January 6, 2014 4:52:35 PM
> > Subject: Re: Single Disk Snapshot Feature
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Malini Rao" <mrao at redhat.com>
> > > To: "Daniel Erez" <derez at redhat.com>
> > > Cc: arch at ovirt.org
> > > Sent: Monday, January 6, 2014 9:09:44 PM
> > > Subject: Re: Single Disk Snapshot Feature
> > > 
> > > Daniel,
> > > 
> > > I went through the feature page and I have some questions ( mainly from
> > > the
> > > user experience perspective) that may be about the feature or about
> > > snapshots itself..not sure -
> > > 
> > > 1. Will the ability to choose disks be available only when I click on
> > > 'Create
> > > Snapshot' button on the tool bar or even when I right click an existing
> > > snapshot and trigger the create snapshot flow?
> > 
> > Disks selection will be available only when creating a new snapshot.
> > Currently, editing an existing snapshot is not applicable.
> 
> MR: I didn't mean editing a snapshot.. I am thinking when I right click an
> existing snapshot and access the create snapshot, it is basing the
> configurations of the new snapshot on the selected existing snapshot...
> right? So, if the existing snapshot has multiple disks, will the new one
> also have the multiple disks and can the user in this flow tweak that
> selection?

Actually, the create button isn't affected by snapshot selection at all.
When creating a new snapshot, we always take the active VM (which is the current
state of the VM) and make a snapshot from it. There's also a clone action
which create a VM from a selected snapshot, in which, the new VM will
consists the selected snapshot disks (but currently, no tweak of selection 
is allowed in this flow).

> 
> > 
> > > 
> > > 2. I am a little concerned about the Custom preview option in terms of
> > > how
> > > intuitive that might be. Would it be more intuitive if there was a way
> > > for
> > > the user to select multiple snapshots in the list and then click preview
> > > to
> > > get all those selected snapshots as rows with disk selection possible? My
> > > concern is that even though 'Preview' and 'Custom preview' are presented
> > > together, they behave differently - preview will send them to the preview
> > > flow for that single snapshot while, the custom preview dialog is really
> > > independent of any row selection of the snapshot list. If the multiple
> > > selection option I described will not work for any reason, then I think
> > > having a separate button with a more descriptive name such as 'Hybrid
> > > Snapshot' might help.
> > 
> > You're right, I was concerned as well regarding the non-reliance of
> > the custom button and row selection. However, currently, multiple
> > selection is not relevant for any other action (i.e. multiple selection
> > will enforce graying out all the others buttons). In addition, I'm not
> > sure it would be more intuitive for the user to select more than one
> > snapshot
> > just for doing a custom preview (as for now, multiple selection is
> > prohibited
> > in this sub-tab). Do you think that separating to a different (regular)
> > action button could work better here? (btw, not sure about 'Hybrid
> > Snapshot'
> > as the dialog is actually invoking only a preview of a snapshot rather
> > than creating one. 'Hybrid Preview' sounds good? :)
> 
> MR: I think a separate button will help. Even though it is a bit long,  how
> about 'Define Custom Snapshot Preview'?

Might be a bit too long indeed :) Maybe the revisit of action buttons separators
(as we had while back) could do the trick?

> 
> > 
> > > 
> > > 3. In the custom preview dialog, what is the column with the radio button
> > > and
> > > is that somehow related with row selection? Right now, it is creating
> > > confusion for me because it seems like I pick a snapshot with this radio
> > > button in addition to the row highlighting and then that expectation
> > > falls
> > > apart since I am able to select across rows on the disks columns. Maybe
> > > what
> > > is needed here is to remove the row highlighting for starters and also
> > > pull
> > > out the display(?) column out of the list and have a single select drop
> > > down
> > > at the bottom of the dialog so that in the grid, all you are doing is
> > > disk
> > > selection. Or maybe at least move the radio button column to the right,
> > > so
> > > it doesn't confuse with selection.
> > 
> > The radio button column is for the snapshot's 'VM configuration' which
> > consists of the other attributes of a VM. E.g.
> > name/description/cpu/nics/apps/etc.
> > I.e. this dialog allows mix-n-match only for the disks, other components
> > of the snapshot aren't configurable.
> > So a single drop down won't work here as every snapshot might contain
> > a different VM configuration, from which the user can choose.
> > Regarding the row selection - you're right, I've been already told it's
> > quite confusing. I removed it from my implementation drafts but just
> > hadn't have a chance to update the video yet...
> 
> MR: Daniel, just so it is clear, the drop down will list the snapshots. See
> attachment of a mockup I tweaked from yours. Would this not work?

Oh, now I understand. But there's another limitation (I'm not sure I've
emphasized it the wiki page) - the memory is coupled to the VM configuration,
i.e. if the users select some configuration, they could only check the
memory check-box correlated that selected configuration. So wouldn't it
be confusing / less intuitive to extract the VM configurtion, as the user
must keep in mind the selected configuration from top and make the
correlation to the list in table?

> 
> 
> > 
> > > 
> > > 4. Also, I wanted to know how many disks can we expect per row on an avg?
> > > I
> > > ask to see if the matrix format is the most suitable or if we need to
> > > think
> > > of other layouts...
> > 
> > We've tried a few variations scrolling for the dialog, e.g. keeping the
> > left hand columns (Date/Name/VM configuration) static and allow
> > horizontal scrolling only for the disks. But it seems that for
> > most use-cases, we'll have many snapshots and only a few disks.
> > Hence, it'll probably better ux-wise to keep the dialog cleaner
> > and simpler for the common use-cases while supporting rare
> > scenarios with (regular) scrollbars for the entire table.
> 
> MR: I think the static columns on the left are a great idea but that should
> appear only when the scroll becomes necessary. When the number of disks are
> small, which is possibly mostly, then the dialog is simple. But even though
> it is an edge case, I think if the snapshots column did not stay static, the
> scroll would be meaningless since you don;t know what you are picking
> anymore.
> 
> 
> > 
> > Let me know what you think, thanks a lot for the feedback!
> > 
> > > 
> > > Thanks
> > > Malini
> > > 
> > > ----- Original Message -----
> > > From: "Daniel Erez" <derez at redhat.com>
> > > To: arch at ovirt.org
> > > Sent: Sunday, December 15, 2013 12:40:06 PM
> > > Subject: Single Disk Snapshot Feature
> > > 
> > > Hi,
> > > 
> > > "Single Disk Snapshot" feature is targeted to 3.4.
> > > Please review the wiki page [1] and feel free to
> > > share your thoughts.
> > > 
> > > [1] http://www.ovirt.org/Features/Single_Disk_Snapshot
> > > 
> > > Regards,
> > > Daniel
> > > _______________________________________________
> > > Arch mailing list
> > > Arch at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/arch
> > > 
> > 
> 


From derez at redhat.com  Wed Jan  8 06:35:20 2014
From: derez at redhat.com (Daniel Erez)
Date: Wed, 8 Jan 2014 01:35:20 -0500 (EST)
Subject: Single Disk Snapshot Feature
In-Reply-To: <591832064.5215928.1389162671198.JavaMail.root@redhat.com>
References: <1289649020.52035943.1387129206895.JavaMail.root@redhat.com>
	<883112546.49300895.1389035384862.JavaMail.root@redhat.com>
	<220340629.3966988.1389045155503.JavaMail.root@redhat.com>
	<194176282.50547554.1389132509934.JavaMail.root@redhat.com>
	<591832064.5215928.1389162671198.JavaMail.root@redhat.com>
Message-ID: <792608855.5216469.1389162920426.JavaMail.root@redhat.com>

CC'ing Eldan for review.

----- Original Message -----
> From: "Daniel Erez" <derez at redhat.com>
> To: "Malini Rao" <mrao at redhat.com>
> Cc: arch at ovirt.org
> Sent: Wednesday, January 8, 2014 8:31:11 AM
> Subject: Re: Single Disk Snapshot Feature
> 
> 
> 
> ----- Original Message -----
> > From: "Malini Rao" <mrao at redhat.com>
> > To: "Daniel Erez" <derez at redhat.com>
> > Cc: arch at ovirt.org
> > Sent: Wednesday, January 8, 2014 12:08:29 AM
> > Subject: Re: Single Disk Snapshot Feature
> > 
> > 
> > ----- Original Message -----
> > > From: "Daniel Erez" <derez at redhat.com>
> > > To: "Malini Rao" <mrao at redhat.com>
> > > Cc: arch at ovirt.org
> > > Sent: Monday, January 6, 2014 4:52:35 PM
> > > Subject: Re: Single Disk Snapshot Feature
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Malini Rao" <mrao at redhat.com>
> > > > To: "Daniel Erez" <derez at redhat.com>
> > > > Cc: arch at ovirt.org
> > > > Sent: Monday, January 6, 2014 9:09:44 PM
> > > > Subject: Re: Single Disk Snapshot Feature
> > > > 
> > > > Daniel,
> > > > 
> > > > I went through the feature page and I have some questions ( mainly from
> > > > the
> > > > user experience perspective) that may be about the feature or about
> > > > snapshots itself..not sure -
> > > > 
> > > > 1. Will the ability to choose disks be available only when I click on
> > > > 'Create
> > > > Snapshot' button on the tool bar or even when I right click an existing
> > > > snapshot and trigger the create snapshot flow?
> > > 
> > > Disks selection will be available only when creating a new snapshot.
> > > Currently, editing an existing snapshot is not applicable.
> > 
> > MR: I didn't mean editing a snapshot.. I am thinking when I right click an
> > existing snapshot and access the create snapshot, it is basing the
> > configurations of the new snapshot on the selected existing snapshot...
> > right? So, if the existing snapshot has multiple disks, will the new one
> > also have the multiple disks and can the user in this flow tweak that
> > selection?
> 
> Actually, the create button isn't affected by snapshot selection at all.
> When creating a new snapshot, we always take the active VM (which is the
> current
> state of the VM) and make a snapshot from it. There's also a clone action
> which create a VM from a selected snapshot, in which, the new VM will
> consists the selected snapshot disks (but currently, no tweak of selection
> is allowed in this flow).
> 
> > 
> > > 
> > > > 
> > > > 2. I am a little concerned about the Custom preview option in terms of
> > > > how
> > > > intuitive that might be. Would it be more intuitive if there was a way
> > > > for
> > > > the user to select multiple snapshots in the list and then click
> > > > preview
> > > > to
> > > > get all those selected snapshots as rows with disk selection possible?
> > > > My
> > > > concern is that even though 'Preview' and 'Custom preview' are
> > > > presented
> > > > together, they behave differently - preview will send them to the
> > > > preview
> > > > flow for that single snapshot while, the custom preview dialog is
> > > > really
> > > > independent of any row selection of the snapshot list. If the multiple
> > > > selection option I described will not work for any reason, then I think
> > > > having a separate button with a more descriptive name such as 'Hybrid
> > > > Snapshot' might help.
> > > 
> > > You're right, I was concerned as well regarding the non-reliance of
> > > the custom button and row selection. However, currently, multiple
> > > selection is not relevant for any other action (i.e. multiple selection
> > > will enforce graying out all the others buttons). In addition, I'm not
> > > sure it would be more intuitive for the user to select more than one
> > > snapshot
> > > just for doing a custom preview (as for now, multiple selection is
> > > prohibited
> > > in this sub-tab). Do you think that separating to a different (regular)
> > > action button could work better here? (btw, not sure about 'Hybrid
> > > Snapshot'
> > > as the dialog is actually invoking only a preview of a snapshot rather
> > > than creating one. 'Hybrid Preview' sounds good? :)
> > 
> > MR: I think a separate button will help. Even though it is a bit long,  how
> > about 'Define Custom Snapshot Preview'?
> 
> Might be a bit too long indeed :) Maybe the revisit of action buttons
> separators
> (as we had while back) could do the trick?
> 
> > 
> > > 
> > > > 
> > > > 3. In the custom preview dialog, what is the column with the radio
> > > > button
> > > > and
> > > > is that somehow related with row selection? Right now, it is creating
> > > > confusion for me because it seems like I pick a snapshot with this
> > > > radio
> > > > button in addition to the row highlighting and then that expectation
> > > > falls
> > > > apart since I am able to select across rows on the disks columns. Maybe
> > > > what
> > > > is needed here is to remove the row highlighting for starters and also
> > > > pull
> > > > out the display(?) column out of the list and have a single select drop
> > > > down
> > > > at the bottom of the dialog so that in the grid, all you are doing is
> > > > disk
> > > > selection. Or maybe at least move the radio button column to the right,
> > > > so
> > > > it doesn't confuse with selection.
> > > 
> > > The radio button column is for the snapshot's 'VM configuration' which
> > > consists of the other attributes of a VM. E.g.
> > > name/description/cpu/nics/apps/etc.
> > > I.e. this dialog allows mix-n-match only for the disks, other components
> > > of the snapshot aren't configurable.
> > > So a single drop down won't work here as every snapshot might contain
> > > a different VM configuration, from which the user can choose.
> > > Regarding the row selection - you're right, I've been already told it's
> > > quite confusing. I removed it from my implementation drafts but just
> > > hadn't have a chance to update the video yet...
> > 
> > MR: Daniel, just so it is clear, the drop down will list the snapshots. See
> > attachment of a mockup I tweaked from yours. Would this not work?
> 
> Oh, now I understand. But there's another limitation (I'm not sure I've
> emphasized it the wiki page) - the memory is coupled to the VM configuration,
> i.e. if the users select some configuration, they could only check the
> memory check-box correlated that selected configuration. So wouldn't it
> be confusing / less intuitive to extract the VM configurtion, as the user
> must keep in mind the selected configuration from top and make the
> correlation to the list in table?
> 
> > 
> > 
> > > 
> > > > 
> > > > 4. Also, I wanted to know how many disks can we expect per row on an
> > > > avg?
> > > > I
> > > > ask to see if the matrix format is the most suitable or if we need to
> > > > think
> > > > of other layouts...
> > > 
> > > We've tried a few variations scrolling for the dialog, e.g. keeping the
> > > left hand columns (Date/Name/VM configuration) static and allow
> > > horizontal scrolling only for the disks. But it seems that for
> > > most use-cases, we'll have many snapshots and only a few disks.
> > > Hence, it'll probably better ux-wise to keep the dialog cleaner
> > > and simpler for the common use-cases while supporting rare
> > > scenarios with (regular) scrollbars for the entire table.
> > 
> > MR: I think the static columns on the left are a great idea but that should
> > appear only when the scroll becomes necessary. When the number of disks are
> > small, which is possibly mostly, then the dialog is simple. But even though
> > it is an edge case, I think if the snapshots column did not stay static,
> > the
> > scroll would be meaningless since you don;t know what you are picking
> > anymore.
> > 
> > 
> > > 
> > > Let me know what you think, thanks a lot for the feedback!
> > > 
> > > > 
> > > > Thanks
> > > > Malini
> > > > 
> > > > ----- Original Message -----
> > > > From: "Daniel Erez" <derez at redhat.com>
> > > > To: arch at ovirt.org
> > > > Sent: Sunday, December 15, 2013 12:40:06 PM
> > > > Subject: Single Disk Snapshot Feature
> > > > 
> > > > Hi,
> > > > 
> > > > "Single Disk Snapshot" feature is targeted to 3.4.
> > > > Please review the wiki page [1] and feel free to
> > > > share your thoughts.
> > > > 
> > > > [1] http://www.ovirt.org/Features/Single_Disk_Snapshot
> > > > 
> > > > Regards,
> > > > Daniel
> > > > _______________________________________________
> > > > Arch mailing list
> > > > Arch at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/arch
> > > > 
> > > 
> >
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Multi disk selection.png
Type: image/png
Size: 227086 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20140108/03e1d175/attachment.png>

From abaron at redhat.com  Wed Jan  8 06:56:04 2014
From: abaron at redhat.com (Ayal Baron)
Date: Wed, 8 Jan 2014 01:56:04 -0500 (EST)
Subject: Single Disk Snapshot Feature
In-Reply-To: <194176282.50547554.1389132509934.JavaMail.root@redhat.com>
References: <1289649020.52035943.1387129206895.JavaMail.root@redhat.com>
	<883112546.49300895.1389035384862.JavaMail.root@redhat.com>
	<220340629.3966988.1389045155503.JavaMail.root@redhat.com>
	<194176282.50547554.1389132509934.JavaMail.root@redhat.com>
Message-ID: <1661271996.46350413.1389164164291.JavaMail.root@redhat.com>



----- Original Message -----
> 
> ----- Original Message -----
> > From: "Daniel Erez" <derez at redhat.com>
> > To: "Malini Rao" <mrao at redhat.com>
> > Cc: arch at ovirt.org
> > Sent: Monday, January 6, 2014 4:52:35 PM
> > Subject: Re: Single Disk Snapshot Feature
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Malini Rao" <mrao at redhat.com>
> > > To: "Daniel Erez" <derez at redhat.com>
> > > Cc: arch at ovirt.org
> > > Sent: Monday, January 6, 2014 9:09:44 PM
> > > Subject: Re: Single Disk Snapshot Feature
> > > 
> > > Daniel,
> > > 
> > > I went through the feature page and I have some questions ( mainly from
> > > the
> > > user experience perspective) that may be about the feature or about
> > > snapshots itself..not sure -
> > > 
> > > 1. Will the ability to choose disks be available only when I click on
> > > 'Create
> > > Snapshot' button on the tool bar or even when I right click an existing
> > > snapshot and trigger the create snapshot flow?
> > 
> > Disks selection will be available only when creating a new snapshot.
> > Currently, editing an existing snapshot is not applicable.
> 
> MR: I didn't mean editing a snapshot.. I am thinking when I right click an
> existing snapshot and access the create snapshot, it is basing the

There is no "create snapshot from snapshot" operation in the system.

> configurations of the new snapshot on the selected existing snapshot...
> right? So, if the existing snapshot has multiple disks, will the new one
> also have the multiple disks and can the user in this flow tweak that
> selection?
> 
> > 
> > > 
> > > 2. I am a little concerned about the Custom preview option in terms of
> > > how
> > > intuitive that might be. Would it be more intuitive if there was a way
> > > for
> > > the user to select multiple snapshots in the list and then click preview
> > > to
> > > get all those selected snapshots as rows with disk selection possible? My
> > > concern is that even though 'Preview' and 'Custom preview' are presented
> > > together, they behave differently - preview will send them to the preview
> > > flow for that single snapshot while, the custom preview dialog is really
> > > independent of any row selection of the snapshot list. If the multiple
> > > selection option I described will not work for any reason, then I think
> > > having a separate button with a more descriptive name such as 'Hybrid
> > > Snapshot' might help.
> > 
> > You're right, I was concerned as well regarding the non-reliance of
> > the custom button and row selection. However, currently, multiple
> > selection is not relevant for any other action (i.e. multiple selection
> > will enforce graying out all the others buttons). In addition, I'm not
> > sure it would be more intuitive for the user to select more than one
> > snapshot
> > just for doing a custom preview (as for now, multiple selection is
> > prohibited
> > in this sub-tab). Do you think that separating to a different (regular)
> > action button could work better here? (btw, not sure about 'Hybrid
> > Snapshot'
> > as the dialog is actually invoking only a preview of a snapshot rather
> > than creating one. 'Hybrid Preview' sounds good? :)
> 
> MR: I think a separate button will help. Even though it is a bit long,  how
> about 'Define Custom Snapshot Preview'?
> 
> > 
> > > 
> > > 3. In the custom preview dialog, what is the column with the radio button
> > > and
> > > is that somehow related with row selection? Right now, it is creating
> > > confusion for me because it seems like I pick a snapshot with this radio
> > > button in addition to the row highlighting and then that expectation
> > > falls
> > > apart since I am able to select across rows on the disks columns. Maybe
> > > what
> > > is needed here is to remove the row highlighting for starters and also
> > > pull
> > > out the display(?) column out of the list and have a single select drop
> > > down
> > > at the bottom of the dialog so that in the grid, all you are doing is
> > > disk
> > > selection. Or maybe at least move the radio button column to the right,
> > > so
> > > it doesn't confuse with selection.
> > 
> > The radio button column is for the snapshot's 'VM configuration' which
> > consists of the other attributes of a VM. E.g.
> > name/description/cpu/nics/apps/etc.
> > I.e. this dialog allows mix-n-match only for the disks, other components
> > of the snapshot aren't configurable.
> > So a single drop down won't work here as every snapshot might contain
> > a different VM configuration, from which the user can choose.
> > Regarding the row selection - you're right, I've been already told it's
> > quite confusing. I removed it from my implementation drafts but just
> > hadn't have a chance to update the video yet...
> 
> MR: Daniel, just so it is clear, the drop down will list the snapshots. See
> attachment of a mockup I tweaked from yours. Would this not work?
> 
> 
> > 
> > > 
> > > 4. Also, I wanted to know how many disks can we expect per row on an avg?
> > > I
> > > ask to see if the matrix format is the most suitable or if we need to
> > > think
> > > of other layouts...
> > 
> > We've tried a few variations scrolling for the dialog, e.g. keeping the
> > left hand columns (Date/Name/VM configuration) static and allow
> > horizontal scrolling only for the disks. But it seems that for
> > most use-cases, we'll have many snapshots and only a few disks.
> > Hence, it'll probably better ux-wise to keep the dialog cleaner
> > and simpler for the common use-cases while supporting rare
> > scenarios with (regular) scrollbars for the entire table.
> 
> MR: I think the static columns on the left are a great idea but that should
> appear only when the scroll becomes necessary. When the number of disks are
> small, which is possibly mostly, then the dialog is simple. But even though
> it is an edge case, I think if the snapshots column did not stay static, the
> scroll would be meaningless since you don;t know what you are picking
> anymore.
> 
> 
> > 
> > Let me know what you think, thanks a lot for the feedback!
> > 
> > > 
> > > Thanks
> > > Malini
> > > 
> > > ----- Original Message -----
> > > From: "Daniel Erez" <derez at redhat.com>
> > > To: arch at ovirt.org
> > > Sent: Sunday, December 15, 2013 12:40:06 PM
> > > Subject: Single Disk Snapshot Feature
> > > 
> > > Hi,
> > > 
> > > "Single Disk Snapshot" feature is targeted to 3.4.
> > > Please review the wiki page [1] and feel free to
> > > share your thoughts.
> > > 
> > > [1] http://www.ovirt.org/Features/Single_Disk_Snapshot
> > > 
> > > Regards,
> > > Daniel
> > > _______________________________________________
> > > Arch mailing list
> > > Arch at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/arch
> > > 
> > 
> 
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From sbonazzo at redhat.com  Wed Jan  8 08:46:22 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Wed, 08 Jan 2014 09:46:22 +0100
Subject: [QE] 3.4.0 Release tracker
Message-ID: <52CD105E.2040409@redhat.com>

Hi,

as you may know, we're planning to build oVirt 3.4.0 beta really soon and release 3.4.0 by end of January.
A tracker bug (https://bugzilla.redhat.com/show_bug.cgi?id=1024889) has been created for this release.

The following is a list of the current blocker bugs with target 3.4.0:
Whiteboard	Bug ID	Summary
storage	1032686	[RFE] API to save OVF on any location
storage	1032679	[RFE] Single Disk Snapshots
network	987813	[RFE] report BOOTPROTO and BONDING_OPTS independent of netdevice.cfg


The following is a list of the bugs with target 3.4.0 not yet fixed:

Whiteboard	Bug ID	Summary
gluster		1008980	[oVirt] Option 'Select as SPM' available for a host in gluster-only mode of oVirt
gluster		1038988	Gluster brick sync does not work when host has multiple interfaces
i18n		1033730	[es-ES] need to revise the "create snapshot" translation
infra		870330	Cache records in memory
infra		904029	[engine-manage-domains] should use POSIX parameter form and aliases as values
infra		979231	oVirt Node Upgrade: Support N configuration
infra		986882	tar which is used by host-deploy is missing from fedora minimal installation
infra		995362	[RFE] Support firewalld
infra		1016634	Performance hit as a result of duplicate updates to VdsDynamic in VdsUpdateRuntimeInfo
infra		1023751	[RFE] Create Bin Overrider for application context files changes we do in JRS
infra		1023754	[RFE] add trigger to stop etl connection via engine db value.
infra		1023759	[RFE] re-implement SSO solution based on JRS new SSO interface
infra		1023761	[RFE] Build nightly JRS builds based on latest JRS version
infra		1028793	systemctl start vdsmd blocks if dns server unreachable
infra		1032682	Refactor authentication framework in engine
infra		1035844	[oVirt][infra] Add host/Reinstall radio button text not actionable
infra		1045350	REST error during VM creation via API
infra		1046611	[oVirt][infra] Device custom properties syntax check is wrong
integration	789040	[RFE] Log Collector should be able to run without asking questions
integration	967350	[RFE] port dwh installer to otopi
integration	967351	[RFE] port reports installer to otopi
integration	1023752	[RFE] add upstream support for Centos el6 arch.
integration	1024028	[RFE] add trigger to stop etl connection via engine db value.
integration	1028489	[RFE] pre-populate ISO DOMAIN  with rhev-tools-setup.iso (or equiv)
integration	1028913	'service network start' sometimes fails during setup
integration	1037663	F20 - ovirt-log-collector: conflicts with file from package sos-3.0-3.fc20.noarch
integration	1039616	Setting shmmax on F19 is not enough for starting postgres
network		987832	failed to add ovirtmgmt bridge when the host has static ip
network		1001186	With AIO installer and NetworkManager enabled, the ovirtmgmt bridge is not properly configured
network		1010663	override mtu field allows only values up to 9000
network		1018947	Yum update to oVirt 3.3 from 3.1.0 fails on CentOS 6.4 with EPEL dependency on python-inotify
network		1037612	[oVirt][network][RFE] Add "sync" column to hosts sub tab under networks main tab
network		1040580	[RFE] Apply networks changes to multiple hosts
network		1040586	[RFE] Ability to configure network on multiple hosts at once
network		1043220	[oVirt][network][RFE] Add Security-Group support for Neutron based networks
network		1043230	Allow configuring Network QoS on host interfaces
network		1044479	Make an iproute2 network configurator for vdsm
network		1048738	[oVirt][network][RFE] Add subnet support for neutron  based networks
network		1048740	[oVirt][network][RFE] Allow deleting Neutron based network (in Neutron)
network		1048880	[vdsm][openstacknet] Migration fails for vNIC using OVS + security groups
sla		994712	Remove underscores for pre-defined policy names
sla		1038616	[RFE] Support for hosted engine
storage		888711	PosixFS issues
storage		961532	[RFE] Handle iSCSI lun resize
storage		1009610	[RFE] Provide clear warning when SPM become inaccessible and needs fencing
storage		1034081	Misleading error message when adding an existing Storage Domain
storage		1038053	[RFE] Allow domain of multiple types in a single Data Center
storage		1045842	After deleting image failed ui display message: Disk gluster-test was successfully removed from...
ux		784779	[webadmin][RFE] Login page. Add a link to welcome page
ux		1014859	[RFE] improve context-sensitive help csv mapping files
ux		1035566	[RFE] [oVirt][webadmin] Change comment column title to icon, and move to right of name
ux		1048916	sub-tab events in different main-tabs are being duplicated
virt		953340	console from rhevm-shell/ovirt-shell using spicec does not work (linux client)
virt		975730	[RFE] pass session id to spice via mime type to allow spice Menu Using REST
virt		987957	[RFE] edit VM dialog - nics appear in random order (not sorted by name)
virt		1031040	[RFE] RunOnce dialog can not set a vnc keymap itself
virt		1033547	[RFE] Configure both SPICE and VNC display console
virt		1035279	Allow to disable SSO per VM
virt		1038587	Show name of the template in General tab for a vm if the vm is deployed from template via clone allocation.
virt		1040088	[RFE] Add FreeBSD to the list of VM operating systems
virt		1043469	ovirt-guest-agent for openSUSE
virt		1043471	ovirt-guest-agent for SLES
virt		1043473	ovirt-guest-agent for Ubuntu
virt		1043474	ovirt-guest-agent for Debian
		753296	[RFE] Enable FIPS mode
		753306	SR-IOV support
		753309	[RFE] Workaround for enable/disable services via persist cmd
		806317	[RFE] ovirt-node regenerates kdump ramdisk image on every boot
		832000	Reduce number of kargs to enable a better automated installation with PXE
		846963	[oVirt-node] Upgrade ovirt-node with "ovirt_upgrade" parameter failed
		850386	Introduce new systemd-rpm macros in ovirt-node spec file
		893950	Make ovirt-node more FHS
		908902	Add specififc log handlers (log files) for transactions and ui
		909369	Use blivet during installation
		918270	Refactor and isolate block device discovery
		918957	[TUI] Confirmation for reboot
		947406	Add notice field
		947407	Status of caps-lock should be shown near password fields
		953870	Migrate to livemedia-creator
		966320	ovirt node will also enable ipv4 with dhcp protocol when only setting ipv6 with dhcp
		966498	Change sensitivity of widgets recursively
		969340	Migrate ovirt-node-installer backend and ovirt-auto-install backend to new code base
		974609	Add correct suffixes to scripts
		979067	[RFE] Add generic container handling
		979078	[RFE] <RETURN> can be used to Save a page
		979389	[RFE] use asciidoc for man pages
		980064	[RFE] Add mouse support to the console
		987824	[RFE] Need to add roll up and down ability to mouse control in multipage
		988337	Shown incorrect info for the item "VLAN ID" after configured nic with "vlan".
		988341	Should not create bond when report an error in configuration process
		995994	Could not add Fedora host when its version becomes "oVirt Node Hypervisor"
		997049	Allow nested transactions
		1001947	KeyboardInterrupt Exception when click mouse on UI
		1001950	RFE: same action on all ovirt-node-install page for press enter
		1002176	Not enough debugging informations in log files
		1002620	[RFE] Create central augeas object
		1003234	password.py: Using "set_admin_password" to change admin password failed in single mode
		1005148	[RFE] Add documentation on how to deploy Node with Puppet/Foreman
		1007191	RFE:  Support "BOOTIF=bondname" in auto-install parameters
		1008891	Installer goes to next page after returning from shell
		1011901	Report traceback infos about errors when starting ntpdate, rpcidmapd and rpcgssd services ...
		1013520	Miss some console info to show status by using "ovirt-node-upgrade" to upgrade ovirt-node
		1020227	/var/log/lastlog is missing
		1021647	Shared configuration keys to pass management informations
		1026646	Better to disable "enter" button works for the fan status table of ipmi page
		1027110	Better to disable cim transaction run and prompt ConfirmationDialog when configuring cim without providing password
		1027130	edit-node: Better to rename iso_name more simpler when install multiple packages
		1027161	plugin info shown incorrectly in plugins page when install multiple packages
		1029033	Link status shows disconnected although the cable is plugged.
		1032373	[RFE] enhance edit-node man page for uid/gid options help info a bit more
		1032374	[RFE] edit-node:Support specify multiple user, uid/group, gid elements changed
		1035441	[RFE] Sync versions between ovirt-node and overall ovirt


Please set the target to 3.4.0 and add the bug to the tracker if you think that 3.4.0 should not be released without it fixed.

Please also update the target to 3.4.1 or any next release for bugs that won't be in 3.4.0: it will ease gathering the blocking bugs for next releases.

For those who want to help testing the bugs, I suggest to add yourself as QA contact for the bug.


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


From sander at grendelman.com  Wed Jan  8 09:23:58 2014
From: sander at grendelman.com (Sander Grendelman)
Date: Wed, 8 Jan 2014 10:23:58 +0100
Subject: [Users] [QE] 3.4.0 Release tracker
In-Reply-To: <52CD105E.2040409@redhat.com>
References: <52CD105E.2040409@redhat.com>
Message-ID: <CAHa6cRT4V6A4=UDu7G5coN_91m2jERWhNX=vtqj6eLJn=sWHcA@mail.gmail.com>

Now that BZ#1038525 (live snapshot merge for backup api) is closed as a
duplicate of BZ#647386 ( You are not authorized to access bug #647386.... )

Shouldn't BZ#647386 targeted for 3.4? Or for a future version?


From sbonazzo at redhat.com  Wed Jan  8 09:29:04 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Wed, 08 Jan 2014 10:29:04 +0100
Subject: [Users] [QE] 3.4.0 Release tracker
In-Reply-To: <CAHa6cRT4V6A4=UDu7G5coN_91m2jERWhNX=vtqj6eLJn=sWHcA@mail.gmail.com>
References: <52CD105E.2040409@redhat.com>
	<CAHa6cRT4V6A4=UDu7G5coN_91m2jERWhNX=vtqj6eLJn=sWHcA@mail.gmail.com>
Message-ID: <52CD1A60.3080002@redhat.com>

Il 08/01/2014 10:23, Sander Grendelman ha scritto:
> Now that BZ#1038525 (live snapshot merge for backup api) is closed as a
> duplicate of BZ#647386 ( You are not authorized to access bug #647386.... )
> 
> Shouldn't BZ#647386 targeted for 3.4? Or for a future version?
> 

BZ#1038525 is open and targeted to 3.5.0


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


From sander at grendelman.com  Wed Jan  8 09:45:44 2014
From: sander at grendelman.com (Sander Grendelman)
Date: Wed, 8 Jan 2014 10:45:44 +0100
Subject: [Users] [QE] 3.4.0 Release tracker
In-Reply-To: <52CD1A60.3080002@redhat.com>
References: <52CD105E.2040409@redhat.com>
	<CAHa6cRT4V6A4=UDu7G5coN_91m2jERWhNX=vtqj6eLJn=sWHcA@mail.gmail.com>
	<52CD1A60.3080002@redhat.com>
Message-ID: <CAHa6cRTZdM=qiCX11szJ0a9PCstT-sVy9hTVYTwU=79TqPuxqw@mail.gmail.com>

On Wed, Jan 8, 2014 at 10:29 AM, Sandro Bonazzola <sbonazzo at redhat.com> wrote:
> Il 08/01/2014 10:23, Sander Grendelman ha scritto:
>> Now that BZ#1038525 (live snapshot merge for backup api) is closed as a
>> duplicate of BZ#647386 ( You are not authorized to access bug #647386.... )
>>
>> Shouldn't BZ#647386 targeted for 3.4? Or for a future version?
>>
>
> BZ#1038525 is open and targeted to 3.5.0
That is correct, I didn't scroll down far enough, my apologies.
Any idea on why BZ#647386 is not visible for "regular" rhbz users?


From amuller at redhat.com  Wed Jan  8 14:12:02 2014
From: amuller at redhat.com (Assaf Muller)
Date: Wed, 8 Jan 2014 09:12:02 -0500 (EST)
Subject: [vdsm] Smarter network_setup hooks
In-Reply-To: <20140106133207.GA31032@redhat.com>
References: <20140103122050.GE21494@redhat.com>
	<20140103163440.GA4790@redhat.com>
	<CADSDy2hyaz+xrXaJzPthwpNf7ydwmk7fuyMaF_=oBDDSn+fTnA@mail.gmail.com>
	<20140106133207.GA31032@redhat.com>
Message-ID: <466343892.4789225.1389190322792.JavaMail.root@redhat.com>

Mid-thread summary:

First some terminology so we're all on the same page:
'request' - The setupNetworks that just arrived
'running config' - If unified persistence is being used - All networking on the host as VDSM sees it
'expected' - If unified persistence is being used - The running config after the effects of the request, but before the hook is ran

I think we all agree that we have to expose the 'request' to the hook.
However, there's two different approaches:
1) Allow the hook to rewrite parts of the request (For example, if two networks were sent, and the hook handled one of them, it could
   then delete that network from the request, so VDSM will only continue to configure the 2nd network).
2) Toni's idea with marking devices as hook-configured. So if a network is over a bridge over a VLAN over a bond over three NICs, hooks
   could configure only the NICs (For example) and VDSM would configure the rest, whereas the first idea means that the hook would
   have to configure the entire network (Bridge, VLANs, bonds, and all 3 NICs) and then remove that network from the request.
   The disadvantage of this method is that it would be harder to implement, and have references to the hooks flag throughout all of VDSM.

Then there's the matter of IF to expose the 'running config' and 'expected'.

My main argument is that it's very easy to expose to the hooks (But then why not expose other 'random' data that is easy for VDSM to calculate?),
and that we don't understand all usages for the setupNetworks hooks. I'd rather we expose too much information than not enough and screw
over hook writers.

Either way, let's get some votes in a timely manner so we could manage to implement this for 3.4.


Assaf Muller, Cloud Networking Engineer 
Red Hat 

----- Original Message -----
From: "Adam Litke" <alitke at redhat.com>
To: "Miguel Angel" <miguelangel at ajo.es>
Cc: dsulliva at redhat.com, arch at ovirt.org, vdsm-devel at fedorahosted.org
Sent: Monday, January 6, 2014 3:32:07 PM
Subject: Re: [vdsm] Smarter network_setup hooks

On 04/01/14 20:08 +0100, Miguel Angel wrote:
>Hi Adam
>
>Thanks for the feedback
>
>2014/1/3 Adam Litke <alitke at redhat.com>
>
>> On 03/01/14 12:20 +0000, Dan Kenigsberg wrote:
>>
>>> Recently, Miguel Angel Ajo (CCed) has added a nice functionality to the
>>> implementation of setupNetworks in Vdsm: two hook points where added:
>>> before and after the setupNetworks verb takes place.
>>> [....]
>>
>> Seems like a logical thing to do.  What specific mechanism do you
>> suggest for passing the JSON strings to the hook script?  If passed as
>> arguments to the hook script we would need to consider shell escaping
>> and argv length restrictions.
>>
>> As for the libvirt domain xml we pass to other hooks, we write a temporary
>file
>and we set an environment variable pointing to it before calling the script
>
>
>> What about writing these out to a special file and adding a new
>> getContext() call to the hooking module.  A script that is unconcerned
>> with the context would not require any changes.  But a script that
>> wants access would simply do:
>>
>>    ctx = hooking.getContext()
>>
>> and ctx would be the contents of the special file already decoded into
>> a native Python object for easy consumption.  This could easily be
>> extended to any hook which may want to provide some context to
>> implementors.
>>
>
>That would be nice, so scripts written in python wouldn't need to look for,
>and parse
>the file.
>
>This is an example of a simple hook:
>
>http://gerrit.ovirt.org/#/c/20330/7/tests/functional/networkTests.py  (look
>inside the ValidatesHook decorator)
>
>
>It'd be quite simplified. We would also need a "setContext()..." to update
>context with changes.

Yeah seems reasonable.  Then hook scripts can become much simpler and
easier to read and write:

ctx = hooking.getContext()
ctx['foo'] = 'bar'
hooking.setContext(ctx)

>
>
>>
>> One more question comes to mind:  Are there any pieces of information
>> that we would need to redact from the context (passwords or other
>> sensitive information)?
>>
>>
>I think there is no sensitive information as far as I know.
>
>Greetings,
>Miguel ?ngel.
_______________________________________________
vdsm-devel mailing list
vdsm-devel at lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel


From miguelangel at ajo.es  Wed Jan  8 14:34:24 2014
From: miguelangel at ajo.es (Miguel Angel)
Date: Wed, 8 Jan 2014 15:34:24 +0100
Subject: [vdsm] Smarter network_setup hooks
In-Reply-To: <466343892.4789225.1389190322792.JavaMail.root@redhat.com>
References: <20140103122050.GE21494@redhat.com>
	<20140103163440.GA4790@redhat.com>
	<CADSDy2hyaz+xrXaJzPthwpNf7ydwmk7fuyMaF_=oBDDSn+fTnA@mail.gmail.com>
	<20140106133207.GA31032@redhat.com>
	<466343892.4789225.1389190322792.JavaMail.root@redhat.com>
Message-ID: <CADSDy2gmczTEsYuY0ap5o17-yz-hNWOWWSUDraD22josGqhzwg@mail.gmail.com>

Hi Assaf, Thank you very much for the summary,

Just a few questions, there are things I don't understand yet:

2014/1/8 Assaf Muller <amuller at redhat.com>

> Mid-thread summary:
>
> First some terminology so we're all on the same page:
> 'request' - The setupNetworks that just arrived
> 'running config' - If unified persistence is being used - All networking
> on the host as VDSM sees it
> 'expected' - If unified persistence is being used - The running config
> after the effects of the request, but before the hook is ran
>
>
correct


> I think we all agree that we have to expose the 'request' to the hook.
> However, there's two different approaches:
> 1) Allow the hook to rewrite parts of the request (For example, if two
> networks were sent, and the hook handled one of them, it could
>    then delete that network from the request, so VDSM will only continue
> to configure the 2nd network).
>

In this case ,if the hook deleted the "2nd network", VDSM couldn't handle
the network config persistence anymore, right?,

I didn't expect this use case, I only expected tweaks, etc (before or after
network setup), for example, setting special hardware
capabilities using ethtool or those kind of things.



> 2) Toni's idea with marking devices as hook-configured. So if a network is
> over a bridge over a VLAN over a bond over three NICs, hooks
>    could configure only the NICs (For example) and VDSM would configure
> the rest, whereas the first idea means that the hook would
>    have to configure the entire network (Bridge, VLANs, bonds, and all 3
> NICs) and then remove that network from the request.
>    The disadvantage of this method is that it would be harder to
> implement, and have references to the hooks flag throughout all of VDSM.
>
>
You mean that if the hook marked a certain device as "hook handled" then,
VDSM would just keep this information along with
the network config, etc... and won't do any setup, just config-keeping,
right?


> Then there's the matter of IF to expose the 'running config' and
> 'expected'.
>
> My main argument is that it's very easy to expose to the hooks (But then
> why not expose other 'random' data that is easy for VDSM to calculate?),
> and that we don't understand all usages for the setupNetworks hooks. I'd
> rather we expose too much information than not enough and screw
> over hook writers.
>
>
We have something important here, the hooks don't need to be
python-written, they could be bash scripts, or any other thing...
that means that they wouldn't have access to get "running config", but they
could calculate "expected".

So, my vote here goes for "request" + "running config".


> Either way, let's get some votes in a timely manner so we could manage to
> implement this for 3.4.
>
>
Thanks Assaf! ;)


>
> Assaf Muller, Cloud Networking Engineer
> Red Hat
>
> ----- Original Message -----
> From: "Adam Litke" <alitke at redhat.com>
> To: "Miguel Angel" <miguelangel at ajo.es>
> Cc: dsulliva at redhat.com, arch at ovirt.org, vdsm-devel at fedorahosted.org
> Sent: Monday, January 6, 2014 3:32:07 PM
> Subject: Re: [vdsm] Smarter network_setup hooks
>
> On 04/01/14 20:08 +0100, Miguel Angel wrote:
> >Hi Adam
> >
> >Thanks for the feedback
> >
> >2014/1/3 Adam Litke <alitke at redhat.com>
> >
> >> On 03/01/14 12:20 +0000, Dan Kenigsberg wrote:
> >>
> >>> Recently, Miguel Angel Ajo (CCed) has added a nice functionality to the
> >>> implementation of setupNetworks in Vdsm: two hook points where added:
> >>> before and after the setupNetworks verb takes place.
> >>> [....]
> >>
> >> Seems like a logical thing to do.  What specific mechanism do you
> >> suggest for passing the JSON strings to the hook script?  If passed as
> >> arguments to the hook script we would need to consider shell escaping
> >> and argv length restrictions.
> >>
> >> As for the libvirt domain xml we pass to other hooks, we write a
> temporary
> >file
> >and we set an environment variable pointing to it before calling the
> script
> >
> >
> >> What about writing these out to a special file and adding a new
> >> getContext() call to the hooking module.  A script that is unconcerned
> >> with the context would not require any changes.  But a script that
> >> wants access would simply do:
> >>
> >>    ctx = hooking.getContext()
> >>
> >> and ctx would be the contents of the special file already decoded into
> >> a native Python object for easy consumption.  This could easily be
> >> extended to any hook which may want to provide some context to
> >> implementors.
> >>
> >
> >That would be nice, so scripts written in python wouldn't need to look
> for,
> >and parse
> >the file.
> >
> >This is an example of a simple hook:
> >
> >http://gerrit.ovirt.org/#/c/20330/7/tests/functional/networkTests.py (look
> >inside the ValidatesHook decorator)
> >
> >
> >It'd be quite simplified. We would also need a "setContext()..." to update
> >context with changes.
>
> Yeah seems reasonable.  Then hook scripts can become much simpler and
> easier to read and write:
>
> ctx = hooking.getContext()
> ctx['foo'] = 'bar'
> hooking.setContext(ctx)
>
> >
> >
> >>
> >> One more question comes to mind:  Are there any pieces of information
> >> that we would need to redact from the context (passwords or other
> >> sensitive information)?
> >>
> >>
> >I think there is no sensitive information as far as I know.
> >
> >Greetings,
> >Miguel ?ngel.
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20140108/3b718b7a/attachment.html>

From sbonazzo at redhat.com  Wed Jan  8 16:47:58 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Wed, 08 Jan 2014 17:47:58 +0100
Subject: oVirt 3.4.0 release schedule updated
Message-ID: <52CD813E.8030209@redhat.com>

oVirt team has updated the release schedule for 3.4.0 [1]

These are tentative planning dates and may change

General availability:       2014-02-24
oVirt 3.4 Second Test Day:  2014-02-19
RC Build:                   2014-02-17
oVirt 3.4 Test Day:         2014-01-27
Beta release:               2014-01-20
Branching / Feature freeze: 2014-01-15
Alpha release:              2014-01-09

more details on test days, etc to come in the next few weeks

[1] http://www.ovirt.org/OVirt_3.4_release-management#Timeline

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


From sbonazzo at redhat.com  Wed Jan  8 17:04:05 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Wed, 08 Jan 2014 18:04:05 +0100
Subject: oVirt 3.3.3 tracker
Message-ID: <52CD8505.40902@redhat.com>

Hi,
during today oVirt sync meeting it has been decided to release oVirt 3.3.3 [1] just after 3.4.0 alpha.
3.4.0 alpha will be composed tomorrow using next nightly build rpms.

It has been proposed to build 3.3.3 beta next Monday, so here is the proposed schedule:

    General availability: 2014-01-28
    RC Build: 2014-01-21
    Beta release: 2014-01-13

A tracker bug has been created for blockers tracking:  BZ 1050084 - Tracker: oVirt 3.3.3 release

We still have ~30 bugs targeted to 3.3.3 [2], please update target releases and add blocker bugs to the tracker.

Waiting approval before preparing the email for other mailing lists.

[1] http://www.ovirt.org/OVirt_3.3.z_release-management#oVirt_3.3.3
[2] http://red.ht/1cOYkMo

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


From iheim at redhat.com  Wed Jan  8 20:03:07 2014
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 08 Jan 2014 22:03:07 +0200
Subject: oVirt 3.3.3 tracker
In-Reply-To: <52CD8505.40902@redhat.com>
References: <52CD8505.40902@redhat.com>
Message-ID: <52CDAEFB.6050605@redhat.com>

On 01/08/2014 07:04 PM, Sandro Bonazzola wrote:
> Hi,
> during today oVirt sync meeting it has been decided to release oVirt 3.3.3 [1] just after 3.4.0 alpha.
> 3.4.0 alpha will be composed tomorrow using next nightly build rpms.
>
> It has been proposed to build 3.3.3 beta next Monday, so here is the proposed schedule:
>
>      General availability: 2014-01-28
>      RC Build: 2014-01-21
>      Beta release: 2014-01-13

make sense.

>
> A tracker bug has been created for blockers tracking:  BZ 1050084 - Tracker: oVirt 3.3.3 release
>
> We still have ~30 bugs targeted to 3.3.3 [2], please update target releases and add blocker bugs to the tracker.

I asked for 3.3.4 target release to be added, but i think folks should 
consider if to push bugs to 3.3.4, or to 3.4.0 by now.

I've added users mailing list, in case there is a specific bug someone 
would like to highlight a specific bug that should go into 3.3.3 or 3.3.4.


>
> Waiting approval before preparing the email for other mailing lists.
>
> [1] http://www.ovirt.org/OVirt_3.3.z_release-management#oVirt_3.3.3
> [2] http://red.ht/1cOYkMo
>



From stockhausen at collogia.de  Wed Jan  8 08:51:07 2014
From: stockhausen at collogia.de (Markus Stockhausen)
Date: Wed, 8 Jan 2014 08:51:07 +0000
Subject: AW: [Users] [QE] 3.4.0 Release tracker
In-Reply-To: <52CD105E.2040409@redhat.com>
References: <52CD105E.2040409@redhat.com>
Message-ID: <12EF8D94C6F8734FB2FF37B9FBEDD173585B8F52@EXCHANGE.collogia.de>

> integration     1037663 F20 - ovirt-log-collector: conflicts with file from package sos-3.0-3.fc20.noarch

Given the fact that F20 is already relased and Ovirt 3.4.0 is intended to support it ... shouldn't that be a blocker?

Markus
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: InterScan_Disclaimer.txt
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20140108/cfbf5936/attachment.txt>

From dneary at redhat.com  Wed Jan  8 22:20:14 2014
From: dneary at redhat.com (Dave Neary)
Date: Wed, 08 Jan 2014 23:20:14 +0100
Subject: Fwd: [OpenStack Marketing] Additional 2014 Industry Events' Call
	For Papers open
In-Reply-To: <1389203293.441518070@mail.openstack.org>
References: <1389203293.441518070@mail.openstack.org>
Message-ID: <52CDCF1E.5030602@redhat.com>

Hi all,

A couple of conferences which are relevant to oVirt - it would be great
to see some presentation proposals from the project - especially for
HostingCon, whose CfP closes on Friday.

Contact myself or Brian Proffitt if you are interested just to let us know.

Cheers,
Dave.


-------- Original Message --------
Subject: 	[OpenStack Marketing] Additional 2014 Industry Events' Call
For Papers open
Date: 	Wed, 8 Jan 2014 11:48:13 -0600 (CST)
From: 	Kathy Cacciatore <kathyc at openstack.org>
To: 	community at lists.openstack.org, marketing at lists.openstack.org



Call for Papers/presentations deadlines are coming up, in addition to
the 3 sent in December (below).  Please note the HostingCon deadline of
this Friday, January 10. The hosting industry is an important audience
for OpenStack; we appreciate your support for this event.

  * HostingCon <http://www.hostingcon.com/>, event date June 16-18 in
    Miami Beach, FL. Please submit talks at
    http://www.hostingcon.com/speakers/speaking-proposal-guidelines/, by
    *January 10.*

  * USENIX LISA <https://www.usenix.org/conference/lisa14>, event date
    November 9-14 in Seattle, WA.  CFP submissions due *April 14* at
    https://www.usenix.org/sites/default/files/lisa14cfp_102813.pdf

Note: LISA was a great event for OpenStack in 2013, with over 1000 Large
Installation System Admins participating. We'd like to propose a half
day hands-on tutorial this year. It's the week after the Paris Summit.
If you are interested in presenting the tutorial, please contact me
(Kathy).



Thank you.



On Thursday, December 19, 2013 3:58pm, "Kathy Cacciatore"
<kathyc at openstack.org> said:

OpenStack's 2013 industry event experience indicates speaking sessions
can be the best way to reach the most receptive audiences.  Speaking at
industry events is a great way to educate OpenStack users and potential
users while indirectly promoting your company's expertise.



Your innovative presentations are requested for these upcoming events.
The CFP hotlinks will direct you to details on the recommended topics
and the submission forms. Learn more about the events and attendees by
clicking on the event hotlinks.



As always, please feel free to contact me with questions -
kathyc at openstack.org.  Thank you and happy holidays!

 1. OSCON 2014 <http://www.oscon.com/oscon2014>, event date July 20-24
    in Portland, OR. CFP <http://www.oscon.com/oscon2014/public/cfp/308>
    due by *January 30*. Audience is primarily very technical, leading
    edge developers, sys admins and open source enthusiasts who are most
    likely familiar and/or working with OpenStack software. They will
    appreciate in-depth topics. OSCON 2014 coincides with the the
    software's 4th birthday.
 2. Cloud Expo East <http://www.cloudcomputingexpo.com/>, event date
    June 10-12 in New York City. CFP
    <http://www.cloudcomputingexpo.com/general/papers2014east.htm>due by
    *March 1*. Audience is primarily IT managers and staff. At the 2013
    event, we experienced most of this audience was looking for benefits
    of cloud computing, how cloud is differentiated from virtualization,
    and had heard of OpenStack but did not yet have specific knowledge
    of the software. On the other hand, there were a few very technical
    conversations. NYC-based user stories and business cases welcome.
 3. Cloud World Forum Europe
    <http://cloudwf.com/interested-in-speaking/>, event date June 17-18
    in London. CFP <http://cloudwf.com/interested-in-speaking/>*deadline
    to come*; not yet listed. Audience is a mix of IT decision makers
    and management, and evenly split between multinational enterprises
    and SMB. European case studies would be ideal.

-- 

Regards,

Kathy Cacciatore
OpenStack Industry Event Planner
1-512-970-2807 (mobile)
Part time: Monday - Thursday, 9am - 2pm US CT
kathyc at openstack.org







-- 
Regards,

Kathy Cacciatore
OpenStack Industry Event Planner
1-512-970-2807 (mobile)
Part time: Monday - Thursday, 9am - 2pm US CT
kathyc at openstack.org





-------------- next part --------------
_______________________________________________
Marketing mailing list
Marketing at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/marketing


From danken at redhat.com  Thu Jan  9 01:35:40 2014
From: danken at redhat.com (Dan Kenigsberg)
Date: Thu, 9 Jan 2014 01:35:40 +0000
Subject: [vdsm] Smarter network_setup hooks
In-Reply-To: <CADSDy2gmczTEsYuY0ap5o17-yz-hNWOWWSUDraD22josGqhzwg@mail.gmail.com>
References: <20140103122050.GE21494@redhat.com>
	<20140103163440.GA4790@redhat.com>
	<CADSDy2hyaz+xrXaJzPthwpNf7ydwmk7fuyMaF_=oBDDSn+fTnA@mail.gmail.com>
	<20140106133207.GA31032@redhat.com>
	<466343892.4789225.1389190322792.JavaMail.root@redhat.com>
	<CADSDy2gmczTEsYuY0ap5o17-yz-hNWOWWSUDraD22josGqhzwg@mail.gmail.com>
Message-ID: <20140109013540.GQ30055@redhat.com>

On Wed, Jan 08, 2014 at 03:34:24PM +0100, Miguel Angel wrote:
> Hi Assaf, Thank you very much for the summary,
> 
> Just a few questions, there are things I don't understand yet:
> 
> 2014/1/8 Assaf Muller <amuller at redhat.com>
> 
> > Mid-thread summary:
> >
> > First some terminology so we're all on the same page:
> > 'request' - The setupNetworks that just arrived
> > 'running config' - If unified persistence is being used - All networking
> > on the host as VDSM sees it
> > 'expected' - If unified persistence is being used - The running config
> > after the effects of the request, but before the hook is ran
> >
> >
> correct
> 
> 
> > I think we all agree that we have to expose the 'request' to the hook.
> > However, there's two different approaches:
> > 1) Allow the hook to rewrite parts of the request (For example, if two
> > networks were sent, and the hook handled one of them, it could
> >    then delete that network from the request, so VDSM will only continue
> > to configure the 2nd network).
> >
> 
> In this case ,if the hook deleted the "2nd network", VDSM couldn't handle
> the network config persistence anymore, right?,

Right. If the before_network_setup hook decides to drop an item from the
'request', it means that neither following hooks, nor Vdsm proper, would
see it. I find it as a useful and simple sematics: the hook practically
says "I'm taking it from here", and from then on, it is repsonsible for
everything. Implementation and persistence alike.

>
> I didn't expect this use case, I only expected tweaks, etc (before or after
> network setup), for example, setting special hardware
> capabilities using ethtool or those kind of things.

Neither have I expected this. But it's a powerful tool that's relatively
easy to implement.

>
> > 2) Toni's idea with marking devices as hook-configured. So if a network is
> > over a bridge over a VLAN over a bond over three NICs, hooks
> >    could configure only the NICs (For example) and VDSM would configure
> > the rest, whereas the first idea means that the hook would
> >    have to configure the entire network (Bridge, VLANs, bonds, and all 3
> > NICs) and then remove that network from the request.
> >    The disadvantage of this method is that it would be harder to
> > implement, and have references to the hooks flag throughout all of VDSM.
> >
> >
> You mean that if the hook marked a certain device as "hook handled" then,
> VDSM would just keep this information along with
> the network config, etc... and won't do any setup, just config-keeping,
> right?

That's my understanding, too. And I share the feeling that this is error
prone: Vdsm sees the config, but must remember that it should not touch
it or act upon it.

> > Then there's the matter of IF to expose the 'running config' and
> > 'expected'.
> >
> > My main argument is that it's very easy to expose to the hooks (But then
> > why not expose other 'random' data that is easy for VDSM to calculate?),
> > and that we don't understand all usages for the setupNetworks hooks. I'd
> > rather we expose too much information than not enough and screw
> > over hook writers.
> >
> >
> We have something important here, the hooks don't need to be
> python-written, they could be bash scripts, or any other thing...
> that means that they wouldn't have access to get "running config", but they
> could calculate "expected".
>
> So, my vote here goes for "request" + "running config".
>

The "running config" is accessible to any process, albeit not in its
Vdsm representation. All the information is available if you do `ip a`
and `virsh net-list`.

I do not imagine why a hook would need the "running config"; If it does
end up needing it, it could re-calculate it just as Vdsm does. Passing
this as argument to each hook script is a premature optimization imho.

If I end up wrong, it would not be hard to add the "running config" to
the Vdsm/hook API. Removing something from an API is a much harder
task.

My vote goes to only "request".

> 
> > Either way, let's get some votes in a timely manner so we could manage to
> > implement this for 3.4.
> >
> >
> Thanks Assaf! ;)


From emesika at redhat.com  Thu Jan  9 08:40:28 2014
From: emesika at redhat.com (Eli Mesika)
Date: Thu, 9 Jan 2014 03:40:28 -0500 (EST)
Subject: [Users] oVirt 3.4.0 release schedule updated
In-Reply-To: <52CD813E.8030209@redhat.com>
References: <52CD813E.8030209@redhat.com>
Message-ID: <960243580.46999232.1389256828090.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>, "VDSM Project Development" <vdsm-devel at lists.fedorahosted.org>,
> "vdsm-devel" <vdsm-devel at fedorahosted.org>, "arch" <arch at ovirt.org>, Users at ovirt.org
> Sent: Wednesday, January 8, 2014 6:47:58 PM
> Subject: [Users] oVirt 3.4.0 release schedule updated
> 
> oVirt team has updated the release schedule for 3.4.0 [1]
> 
> These are tentative planning dates and may change
> 
> General availability:       2014-02-24
> oVirt 3.4 Second Test Day:  2014-02-19
> RC Build:                   2014-02-17
> oVirt 3.4 Test Day:         2014-01-27

Please note that some guys from the TLV office could not attend to that due to an Advanced Python Course taking place (27-30 JAN) 

> Beta release:               2014-01-20
> Branching / Feature freeze: 2014-01-15
> Alpha release:              2014-01-09
> 
> more details on test days, etc to come in the next few weeks
> 
> [1] http://www.ovirt.org/OVirt_3.4_release-management#Timeline
> 
> --
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
> 


From asegurap at redhat.com  Thu Jan  9 11:04:20 2014
From: asegurap at redhat.com (Antoni Segura Puimedon)
Date: Thu, 9 Jan 2014 06:04:20 -0500 (EST)
Subject: [vdsm] Smarter network_setup hooks
In-Reply-To: <20140109013540.GQ30055@redhat.com>
References: <20140103122050.GE21494@redhat.com>
	<20140103163440.GA4790@redhat.com>
	<CADSDy2hyaz+xrXaJzPthwpNf7ydwmk7fuyMaF_=oBDDSn+fTnA@mail.gmail.com>
	<20140106133207.GA31032@redhat.com>
	<466343892.4789225.1389190322792.JavaMail.root@redhat.com>
	<CADSDy2gmczTEsYuY0ap5o17-yz-hNWOWWSUDraD22josGqhzwg@mail.gmail.com>
	<20140109013540.GQ30055@redhat.com>
Message-ID: <99982226.30258529.1389265460738.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Dan Kenigsberg" <danken at redhat.com>
> To: "Miguel Angel" <miguelangel at ajo.es>
> Cc: dsulliva at redhat.com, arch at ovirt.org, vdsm-devel at fedorahosted.org
> Sent: Thursday, January 9, 2014 2:35:40 AM
> Subject: Re: [vdsm] Smarter network_setup hooks
> 
> On Wed, Jan 08, 2014 at 03:34:24PM +0100, Miguel Angel wrote:
> > Hi Assaf, Thank you very much for the summary,
> > 
> > Just a few questions, there are things I don't understand yet:
> > 
> > 2014/1/8 Assaf Muller <amuller at redhat.com>
> > 
> > > Mid-thread summary:
> > >
> > > First some terminology so we're all on the same page:
> > > 'request' - The setupNetworks that just arrived
> > > 'running config' - If unified persistence is being used - All networking
> > > on the host as VDSM sees it
> > > 'expected' - If unified persistence is being used - The running config
> > > after the effects of the request, but before the hook is ran
> > >
> > >
> > correct
> > 
> > 
> > > I think we all agree that we have to expose the 'request' to the hook.
> > > However, there's two different approaches:
> > > 1) Allow the hook to rewrite parts of the request (For example, if two
> > > networks were sent, and the hook handled one of them, it could
> > >    then delete that network from the request, so VDSM will only continue
> > > to configure the 2nd network).
> > >
> > 
> > In this case ,if the hook deleted the "2nd network", VDSM couldn't handle
> > the network config persistence anymore, right?,
> 
> Right. If the before_network_setup hook decides to drop an item from the
> 'request', it means that neither following hooks, nor Vdsm proper, would
> see it. I find it as a useful and simple sematics: the hook practically
> says "I'm taking it from here", and from then on, it is repsonsible for
> everything. Implementation and persistence alike.
> 
> >
> > I didn't expect this use case, I only expected tweaks, etc (before or after
> > network setup), for example, setting special hardware
> > capabilities using ethtool or those kind of things.
> 
> Neither have I expected this. But it's a powerful tool that's relatively
> easy to implement.
> 
> >
> > > 2) Toni's idea with marking devices as hook-configured. So if a network
> > > is
> > > over a bridge over a VLAN over a bond over three NICs, hooks
> > >    could configure only the NICs (For example) and VDSM would configure
> > > the rest, whereas the first idea means that the hook would
> > >    have to configure the entire network (Bridge, VLANs, bonds, and all 3
> > > NICs) and then remove that network from the request.
> > >    The disadvantage of this method is that it would be harder to
> > > implement, and have references to the hooks flag throughout all of VDSM.
> > >
> > >
> > You mean that if the hook marked a certain device as "hook handled" then,
> > VDSM would just keep this information along with
> > the network config, etc... and won't do any setup, just config-keeping,
> > right?
> 
> That's my understanding, too. And I share the feeling that this is error
> prone: Vdsm sees the config, but must remember that it should not touch
> it or act upon it.
> 
> > > Then there's the matter of IF to expose the 'running config' and
> > > 'expected'.
> > >
> > > My main argument is that it's very easy to expose to the hooks (But then
> > > why not expose other 'random' data that is easy for VDSM to calculate?),
> > > and that we don't understand all usages for the setupNetworks hooks. I'd
> > > rather we expose too much information than not enough and screw
> > > over hook writers.
> > >
> > >
> > We have something important here, the hooks don't need to be
> > python-written, they could be bash scripts, or any other thing...
> > that means that they wouldn't have access to get "running config", but they
> > could calculate "expected".
> >
> > So, my vote here goes for "request" + "running config".
> >
> 
> The "running config" is accessible to any process, albeit not in its
> Vdsm representation. All the information is available if you do `ip a`
> and `virsh net-list`.
> 
> I do not imagine why a hook would need the "running config"; If it does
> end up needing it, it could re-calculate it just as Vdsm does. Passing
> this as argument to each hook script is a premature optimization imho.
> 
> If I end up wrong, it would not be hard to add the "running config" to
> the Vdsm/hook API. Removing something from an API is a much harder
> task.
> 
> My vote goes to only "request".

Only "request" for me too.
> 
> > 
> > > Either way, let's get some votes in a timely manner so we could manage to
> > > implement this for 3.4.
> > >
> > >
> > Thanks Assaf! ;)
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> 


From miguelangel at ajo.es  Thu Jan  9 11:16:04 2014
From: miguelangel at ajo.es (Miguel Angel)
Date: Thu, 9 Jan 2014 12:16:04 +0100
Subject: [vdsm] Smarter network_setup hooks
In-Reply-To: <99982226.30258529.1389265460738.JavaMail.root@redhat.com>
References: <20140103122050.GE21494@redhat.com>
	<20140103163440.GA4790@redhat.com>
	<CADSDy2hyaz+xrXaJzPthwpNf7ydwmk7fuyMaF_=oBDDSn+fTnA@mail.gmail.com>
	<20140106133207.GA31032@redhat.com>
	<466343892.4789225.1389190322792.JavaMail.root@redhat.com>
	<CADSDy2gmczTEsYuY0ap5o17-yz-hNWOWWSUDraD22josGqhzwg@mail.gmail.com>
	<20140109013540.GQ30055@redhat.com>
	<99982226.30258529.1389265460738.JavaMail.root@redhat.com>
Message-ID: <CADSDy2j1aCnU0VuYLTrN6iDpF7dxLoK4Y6oMY+mb4bWz84tF2g@mail.gmail.com>

Dan, your arguments conviced me,
changing my vote to "request" only.

---
irc: ajo / mangelajo
Miguel Angel Ajo Pelayo
+34 636 52 25 69
skype: ajoajoajo


2014/1/9 Antoni Segura Puimedon <asegurap at redhat.com>

>
>
> ----- Original Message -----
> > From: "Dan Kenigsberg" <danken at redhat.com>
> > To: "Miguel Angel" <miguelangel at ajo.es>
> > Cc: dsulliva at redhat.com, arch at ovirt.org, vdsm-devel at fedorahosted.org
> > Sent: Thursday, January 9, 2014 2:35:40 AM
> > Subject: Re: [vdsm] Smarter network_setup hooks
> >
> > On Wed, Jan 08, 2014 at 03:34:24PM +0100, Miguel Angel wrote:
> > > Hi Assaf, Thank you very much for the summary,
> > >
> > > Just a few questions, there are things I don't understand yet:
> > >
> > > 2014/1/8 Assaf Muller <amuller at redhat.com>
> > >
> > > > Mid-thread summary:
> > > >
> > > > First some terminology so we're all on the same page:
> > > > 'request' - The setupNetworks that just arrived
> > > > 'running config' - If unified persistence is being used - All
> networking
> > > > on the host as VDSM sees it
> > > > 'expected' - If unified persistence is being used - The running
> config
> > > > after the effects of the request, but before the hook is ran
> > > >
> > > >
> > > correct
> > >
> > >
> > > > I think we all agree that we have to expose the 'request' to the
> hook.
> > > > However, there's two different approaches:
> > > > 1) Allow the hook to rewrite parts of the request (For example, if
> two
> > > > networks were sent, and the hook handled one of them, it could
> > > >    then delete that network from the request, so VDSM will only
> continue
> > > > to configure the 2nd network).
> > > >
> > >
> > > In this case ,if the hook deleted the "2nd network", VDSM couldn't
> handle
> > > the network config persistence anymore, right?,
> >
> > Right. If the before_network_setup hook decides to drop an item from the
> > 'request', it means that neither following hooks, nor Vdsm proper, would
> > see it. I find it as a useful and simple sematics: the hook practically
> > says "I'm taking it from here", and from then on, it is repsonsible for
> > everything. Implementation and persistence alike.
> >
> > >
> > > I didn't expect this use case, I only expected tweaks, etc (before or
> after
> > > network setup), for example, setting special hardware
> > > capabilities using ethtool or those kind of things.
> >
> > Neither have I expected this. But it's a powerful tool that's relatively
> > easy to implement.
> >
> > >
> > > > 2) Toni's idea with marking devices as hook-configured. So if a
> network
> > > > is
> > > > over a bridge over a VLAN over a bond over three NICs, hooks
> > > >    could configure only the NICs (For example) and VDSM would
> configure
> > > > the rest, whereas the first idea means that the hook would
> > > >    have to configure the entire network (Bridge, VLANs, bonds, and
> all 3
> > > > NICs) and then remove that network from the request.
> > > >    The disadvantage of this method is that it would be harder to
> > > > implement, and have references to the hooks flag throughout all of
> VDSM.
> > > >
> > > >
> > > You mean that if the hook marked a certain device as "hook handled"
> then,
> > > VDSM would just keep this information along with
> > > the network config, etc... and won't do any setup, just config-keeping,
> > > right?
> >
> > That's my understanding, too. And I share the feeling that this is error
> > prone: Vdsm sees the config, but must remember that it should not touch
> > it or act upon it.
> >
> > > > Then there's the matter of IF to expose the 'running config' and
> > > > 'expected'.
> > > >
> > > > My main argument is that it's very easy to expose to the hooks (But
> then
> > > > why not expose other 'random' data that is easy for VDSM to
> calculate?),
> > > > and that we don't understand all usages for the setupNetworks hooks.
> I'd
> > > > rather we expose too much information than not enough and screw
> > > > over hook writers.
> > > >
> > > >
> > > We have something important here, the hooks don't need to be
> > > python-written, they could be bash scripts, or any other thing...
> > > that means that they wouldn't have access to get "running config", but
> they
> > > could calculate "expected".
> > >
> > > So, my vote here goes for "request" + "running config".
> > >
> >
> > The "running config" is accessible to any process, albeit not in its
> > Vdsm representation. All the information is available if you do `ip a`
> > and `virsh net-list`.
> >
> > I do not imagine why a hook would need the "running config"; If it does
> > end up needing it, it could re-calculate it just as Vdsm does. Passing
> > this as argument to each hook script is a premature optimization imho.
> >
> > If I end up wrong, it would not be hard to add the "running config" to
> > the Vdsm/hook API. Removing something from an API is a much harder
> > task.
> >
> > My vote goes to only "request".
>
> Only "request" for me too.
> >
> > >
> > > > Either way, let's get some votes in a timely manner so we could
> manage to
> > > > implement this for 3.4.
> > > >
> > > >
> > > Thanks Assaf! ;)
> > _______________________________________________
> > vdsm-devel mailing list
> > vdsm-devel at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20140109/271e571b/attachment.html>

From dfediuck at redhat.com  Thu Jan  9 14:02:43 2014
From: dfediuck at redhat.com (Doron Fediuck)
Date: Thu, 9 Jan 2014 09:02:43 -0500 (EST)
Subject: [Users] oVirt 3.4.0 release schedule updated
In-Reply-To: <960243580.46999232.1389256828090.JavaMail.root@redhat.com>
References: <52CD813E.8030209@redhat.com>
	<960243580.46999232.1389256828090.JavaMail.root@redhat.com>
Message-ID: <1966227353.47309088.1389276163825.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Eli Mesika" <emesika at redhat.com>
> To: "Sandro Bonazzola" <sbonazzo at redhat.com>
> Cc: "arch" <arch at ovirt.org>, "engine-devel" <engine-devel at ovirt.org>, "vdsm-devel" <vdsm-devel at fedorahosted.org>,
> "VDSM Project Development" <vdsm-devel at lists.fedorahosted.org>, Users at ovirt.org
> Sent: Thursday, January 9, 2014 10:40:28 AM
> Subject: Re: [Users] oVirt 3.4.0 release schedule updated
> 
> 
> 
> ----- Original Message -----
> > From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> > To: "engine-devel" <engine-devel at ovirt.org>, "VDSM Project Development"
> > <vdsm-devel at lists.fedorahosted.org>,
> > "vdsm-devel" <vdsm-devel at fedorahosted.org>, "arch" <arch at ovirt.org>,
> > Users at ovirt.org
> > Sent: Wednesday, January 8, 2014 6:47:58 PM
> > Subject: [Users] oVirt 3.4.0 release schedule updated
> > 
> > oVirt team has updated the release schedule for 3.4.0 [1]
> > 
> > These are tentative planning dates and may change
> > 
> > General availability:       2014-02-24
> > oVirt 3.4 Second Test Day:  2014-02-19
> > RC Build:                   2014-02-17
> > oVirt 3.4 Test Day:         2014-01-27
> 
> Please note that some guys from the TLV office could not attend to that due
> to an Advanced Python Course taking place (27-30 JAN)
> 

Hi Sandro,
Since there's some activity also around FOSDEM, I suggest we
will do the first test day on January 23.

Please let me know if there are any objections.

> > Beta release:               2014-01-20
> > Branching / Feature freeze: 2014-01-15
> > Alpha release:              2014-01-09
> > 
> > more details on test days, etc to come in the next few weeks
> > 
> > [1] http://www.ovirt.org/OVirt_3.4_release-management#Timeline
> > 
> > --
> > Sandro Bonazzola
> > Better technology. Faster innovation. Powered by community collaboration.
> > See how it works at redhat.com
> > _______________________________________________
> > Users mailing list
> > Users at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/users
> > 
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
> 


From sbonazzo at redhat.com  Thu Jan  9 14:11:07 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Thu, 09 Jan 2014 15:11:07 +0100
Subject: [Users] oVirt 3.4.0 release schedule updated
In-Reply-To: <1966227353.47309088.1389276163825.JavaMail.root@redhat.com>
References: <52CD813E.8030209@redhat.com>
	<960243580.46999232.1389256828090.JavaMail.root@redhat.com>
	<1966227353.47309088.1389276163825.JavaMail.root@redhat.com>
Message-ID: <52CEADFB.1090702@redhat.com>

Il 09/01/2014 15:02, Doron Fediuck ha scritto:
> 
> 
> ----- Original Message -----
>> From: "Eli Mesika" <emesika at redhat.com>
>> To: "Sandro Bonazzola" <sbonazzo at redhat.com>
>> Cc: "arch" <arch at ovirt.org>, "engine-devel" <engine-devel at ovirt.org>, "vdsm-devel" <vdsm-devel at fedorahosted.org>,
>> "VDSM Project Development" <vdsm-devel at lists.fedorahosted.org>, Users at ovirt.org
>> Sent: Thursday, January 9, 2014 10:40:28 AM
>> Subject: Re: [Users] oVirt 3.4.0 release schedule updated
>>
>>
>>
>> ----- Original Message -----
>>> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
>>> To: "engine-devel" <engine-devel at ovirt.org>, "VDSM Project Development"
>>> <vdsm-devel at lists.fedorahosted.org>,
>>> "vdsm-devel" <vdsm-devel at fedorahosted.org>, "arch" <arch at ovirt.org>,
>>> Users at ovirt.org
>>> Sent: Wednesday, January 8, 2014 6:47:58 PM
>>> Subject: [Users] oVirt 3.4.0 release schedule updated
>>>
>>> oVirt team has updated the release schedule for 3.4.0 [1]
>>>
>>> These are tentative planning dates and may change
>>>
>>> General availability:       2014-02-24
>>> oVirt 3.4 Second Test Day:  2014-02-19
>>> RC Build:                   2014-02-17
>>> oVirt 3.4 Test Day:         2014-01-27
>>
>> Please note that some guys from the TLV office could not attend to that due
>> to an Advanced Python Course taking place (27-30 JAN)
>>
> 
> Hi Sandro,
> Since there's some activity also around FOSDEM, I suggest we
> will do the first test day on January 23.
> 
> Please let me know if there are any objections.

I'll update the site with new date, thanks.


> 
>>> Beta release:               2014-01-20
>>> Branching / Feature freeze: 2014-01-15
>>> Alpha release:              2014-01-09
>>>
>>> more details on test days, etc to come in the next few weeks
>>>
>>> [1] http://www.ovirt.org/OVirt_3.4_release-management#Timeline
>>>
>>> --
>>> Sandro Bonazzola
>>> Better technology. Faster innovation. Powered by community collaboration.
>>> See how it works at redhat.com
>>> _______________________________________________
>>> Users mailing list
>>> Users at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/users
>>>
>> _______________________________________________
>> Users mailing list
>> Users at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>


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


From sbonazzo at redhat.com  Thu Jan  9 14:23:29 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Thu, 09 Jan 2014 15:23:29 +0100
Subject: [Users] oVirt 3.4.0 release schedule updated
In-Reply-To: <1966227353.47309088.1389276163825.JavaMail.root@redhat.com>
References: <52CD813E.8030209@redhat.com>
	<960243580.46999232.1389256828090.JavaMail.root@redhat.com>
	<1966227353.47309088.1389276163825.JavaMail.root@redhat.com>
Message-ID: <52CEB0E1.2030409@redhat.com>

Here is updated schedule.
I've added 3.3.3 too and attached an ICS calendar with the same dates

These are tentative planning dates and may change

oVirt 3.4 General availability:       2014-02-24
oVirt 3.4 Second Test Day:            2014-02-19
oVirt 3.4 RC Build:                   2014-02-17
oVirt 3.4 Test Day:                   2014-01-23
oVirt 3.4 Beta release:               2014-01-20
oVirt 3.4 Branching / Feature freeze: 2014-01-15
oVirt 3.4 Alpha release:              2014-01-09

more details on test days, etc to come in the next few weeks

oVirt 3.3.3 General availability: 2014-01-28
oVirt 3.3.3 RC Build:             2014-01-21
oVirt 3.3.3 Beta release:         2014-01-13


Il 09/01/2014 15:02, Doron Fediuck ha scritto:
> 
> 
> ----- Original Message -----
>> From: "Eli Mesika" <emesika at redhat.com>
>> To: "Sandro Bonazzola" <sbonazzo at redhat.com>
>> Cc: "arch" <arch at ovirt.org>, "engine-devel" <engine-devel at ovirt.org>, "vdsm-devel" <vdsm-devel at fedorahosted.org>,
>> "VDSM Project Development" <vdsm-devel at lists.fedorahosted.org>, Users at ovirt.org
>> Sent: Thursday, January 9, 2014 10:40:28 AM
>> Subject: Re: [Users] oVirt 3.4.0 release schedule updated
>>
>>
>>
>> ----- Original Message -----
>>> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
>>> To: "engine-devel" <engine-devel at ovirt.org>, "VDSM Project Development"
>>> <vdsm-devel at lists.fedorahosted.org>,
>>> "vdsm-devel" <vdsm-devel at fedorahosted.org>, "arch" <arch at ovirt.org>,
>>> Users at ovirt.org
>>> Sent: Wednesday, January 8, 2014 6:47:58 PM
>>> Subject: [Users] oVirt 3.4.0 release schedule updated
>>>
>>> oVirt team has updated the release schedule for 3.4.0 [1]
>>>
>>> These are tentative planning dates and may change
>>>
>>> General availability:       2014-02-24
>>> oVirt 3.4 Second Test Day:  2014-02-19
>>> RC Build:                   2014-02-17
>>> oVirt 3.4 Test Day:         2014-01-27
>>
>> Please note that some guys from the TLV office could not attend to that due
>> to an Advanced Python Course taking place (27-30 JAN)
>>
> 
> Hi Sandro,
> Since there's some activity also around FOSDEM, I suggest we
> will do the first test day on January 23.
> 
> Please let me know if there are any objections.
> 
>>> Beta release:               2014-01-20
>>> Branching / Feature freeze: 2014-01-15
>>> Alpha release:              2014-01-09
>>>
>>> more details on test days, etc to come in the next few weeks
>>>
>>> [1] http://www.ovirt.org/OVirt_3.4_release-management#Timeline
>>>
>>> --
>>> Sandro Bonazzola
>>> Better technology. Faster innovation. Powered by community collaboration.
>>> See how it works at redhat.com
>>> _______________________________________________
>>> Users mailing list
>>> Users at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/users
>>>
>> _______________________________________________
>> Users mailing list
>> Users at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>


-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ovirt-roadmap.ics
Type: text/calendar
Size: 2616 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20140109/e7d27f25/attachment.ics>

From ecohen at redhat.com  Thu Jan  9 17:13:44 2014
From: ecohen at redhat.com (Einav Cohen)
Date: Thu, 9 Jan 2014 12:13:44 -0500 (EST)
Subject: feature: low resolution support
In-Reply-To: <1878131433.47616868.1389287317590.JavaMail.root@redhat.com>
Message-ID: <1767636233.47620721.1389287624141.JavaMail.root@redhat.com>

Hi,

You are welcome to review the 'Low Resolution Support' feature page at:
http://www.ovirt.org/Features/Design/LowerResolutionSupport

feature owner: Alexander Wels (CC'd). 

[this has just been merged to 'master' and will be available in ovirt-3.4]

----
Thanks,
Einav


From sbonazzo at redhat.com  Fri Jan 10 07:48:52 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Fri, 10 Jan 2014 08:48:52 +0100
Subject: oVirt 3.4.0 alpha repository closure failure
Message-ID: <52CFA5E4.8000601@redhat.com>

Hi,
oVirt 3.4.0 alpha repository has been composed but alpha has not been announced due to repository closure failures:

on CentOS 6.5:

# repoclosure -r ovirt-3.4.0-alpha -l ovirt-3.3.2 -l base -l epel -l glusterfs-epel -l updates -l extra -l glusterfs-noarch-epel -l ovirt-stable -n
Reading in repository metadata - please wait....
Checking Dependencies
Repos looked at: 8
   base
   epel
   glusterfs-epel
   glusterfs-noarch-epel
   ovirt-3.3.2
   ovirt-3.4.0-alpha
   ovirt-stable
   updates
Num Packages in Repos: 16581
package: mom-0.3.2-20140101.git2691f25.el6.noarch from ovirt-3.4.0-alpha
  unresolved deps:
     procps-ng
package: otopi-devel-1.2.0-0.0.master.20130910.git4387efb.el6.noarch from ovirt-3.4.0-alpha
  unresolved deps:
     otopi-java = 0:1.2.0-0.0.master.20130910.git4387efb.el6
package: ovirt-engine-sdk-java-3.4.0.1-1.el6.noarch from ovirt-3.4.0-alpha
  unresolved deps:
     httpcomponents-client >= 0:4.2
     apache-commons-logging
     apache-commons-beanutils
package: vdsm-hook-vhostmd-4.14.0-1.git6fdd55f.el6.noarch from ovirt-3.4.0-alpha
  unresolved deps:
     vhostmd


On Fedora 19:
# repoclosure -n -r ovirt-3.4.0-alpha -l fedora -l updates -l ovirt-stable
Reading in repository metadata - please wait....
Checking Dependencies
Repos looked at: 4
   fedora
   ovirt-3.4.0-alpha
   ovirt-stable
   updates
Num Packages in Repos: 38832
package: otopi-devel-1.2.0-0.0.master.20130910.git4387efb.fc19.noarch from ovirt-3.4.0-alpha
  unresolved deps:
     otopi-java = 0:1.2.0-0.0.master.20130910.git4387efb.fc19
package: ovirt-engine-3.4.0-0.2.master.20140109103311.git6524789.fc19.noarch from ovirt-3.4.0-alpha
  unresolved deps:
     openstack-java-resteasy-connector >= 0:3.0.2
     openstack-java-quantum-model >= 0:3.0.2
     openstack-java-quantum-client >= 0:3.0.2
     openstack-java-keystone-model >= 0:3.0.2
     openstack-java-keystone-client >= 0:3.0.2
     openstack-java-glance-model >= 0:3.0.2
     openstack-java-glance-client >= 0:3.0.2
     openstack-java-client >= 0:3.0.2
package: ovirt-engine-reports-3.4.0-0.2.master.20140109102135.fc19.noarch from ovirt-3.4.0-alpha
  unresolved deps:
     ovirt-engine-dwh >= 0:3.4.0


On Fedora 20 (ovirt-stable doesn't support Fedora 20):

# repoclosure -n -r ovirt-3.4.0-alpha -l fedora -l updates
Reading in repository metadata - please wait....
Checking Dependencies
Repos looked at: 3
   fedora
   ovirt-3.4.0-alpha
   updates
Num Packages in Repos: 38822
package: otopi-devel-1.2.0-0.0.master.20130910.git4387efb.fc19.noarch from ovirt-3.4.0-alpha
  unresolved deps:
     otopi-java = 0:1.2.0-0.0.master.20130910.git4387efb.fc19
package: ovirt-engine-3.4.0-0.2.master.20140109103311.git6524789.fc19.noarch from ovirt-3.4.0-alpha
  unresolved deps:
     openstack-java-resteasy-connector >= 0:3.0.2
     openstack-java-quantum-model >= 0:3.0.2
     openstack-java-quantum-client >= 0:3.0.2
     openstack-java-keystone-model >= 0:3.0.2
     openstack-java-keystone-client >= 0:3.0.2
     openstack-java-glance-model >= 0:3.0.2
     openstack-java-glance-client >= 0:3.0.2
     openstack-java-client >= 0:3.0.2
package: ovirt-engine-reports-3.4.0-0.2.master.20140109102135.fc19.noarch from ovirt-3.4.0-alpha
  unresolved deps:
     ovirt-engine-dwh >= 0:3.4.0


Please fix dependencies / provide missing packages / provide additional repositories as soon as possible.
Thanks,

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


From sbonazzo at redhat.com  Fri Jan 10 09:50:52 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Fri, 10 Jan 2014 10:50:52 +0100
Subject: ovirt-specs project needed
Message-ID: <52CFC27C.1090308@redhat.com>

Hi,
can you please create a new gerrit project named ovirt-specs?
it will contain .spec files for needed packages not provided by downstream distributions.
It will contain:
- httpcomponents-core (needed by java sdk, missing on CentOS)
- httpcomponents-client (needed by java sdk, missing on CentOS)

It should contain also jasper server, actually in its own repository and jboss actually packaged by us but without a git repo for the spec file.

Thanks,

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


From danken at redhat.com  Fri Jan 10 10:01:37 2014
From: danken at redhat.com (Dan Kenigsberg)
Date: Fri, 10 Jan 2014 10:01:37 +0000
Subject: oVirt 3.4.0 alpha repository closure failure
In-Reply-To: <52CFA5E4.8000601@redhat.com>
References: <52CFA5E4.8000601@redhat.com>
Message-ID: <20140110100137.GD26642@redhat.com>

On Fri, Jan 10, 2014 at 08:48:52AM +0100, Sandro Bonazzola wrote:
> Hi,
> oVirt 3.4.0 alpha repository has been composed but alpha has not been announced due to repository closure failures:
> 
> on CentOS 6.5:
> 
> # repoclosure -r ovirt-3.4.0-alpha -l ovirt-3.3.2 -l base -l epel -l glusterfs-epel -l updates -l extra -l glusterfs-noarch-epel -l ovirt-stable -n
> Reading in repository metadata - please wait....
> Checking Dependencies
> Repos looked at: 8
>    base
>    epel
>    glusterfs-epel
>    glusterfs-noarch-epel
>    ovirt-3.3.2
>    ovirt-3.4.0-alpha
>    ovirt-stable
>    updates
> Num Packages in Repos: 16581
> package: mom-0.3.2-20140101.git2691f25.el6.noarch from ovirt-3.4.0-alpha
>   unresolved deps:
>      procps-ng

Adam, this seems like a real bug in http://gerrit.ovirt.org/#/c/22087/ :
el6 still carries the older "procps" (which is, btw, provided by
procps-ng).


> package: vdsm-hook-vhostmd-4.14.0-1.git6fdd55f.el6.noarch from ovirt-3.4.0-alpha
>   unresolved deps:
>      vhostmd

Douglas, could you add a with_vhostmd option to the spec, and have it
default to 0 on el*, and to 1 on fedoras?

Thanks,
Dan.


From dcaroest at redhat.com  Fri Jan 10 10:26:01 2014
From: dcaroest at redhat.com (David Caro)
Date: Fri, 10 Jan 2014 11:26:01 +0100
Subject: ovirt-specs project needed
In-Reply-To: <52CFC27C.1090308@redhat.com>
References: <52CFC27C.1090308@redhat.com>
Message-ID: <52CFCAB9.1080000@redhat.com>

El vie 10 ene 2014 10:50:52 CET, Sandro Bonazzola escribi?:
> Hi,
> can you please create a new gerrit project named ovirt-specs?
> it will contain .spec files for needed packages not provided by downstream distributions.
> It will contain:
> - httpcomponents-core (needed by java sdk, missing on CentOS)
> - httpcomponents-client (needed by java sdk, missing on CentOS)
>
> It should contain also jasper server, actually in its own repository and jboss actually packaged by us but without a git repo for the spec file.
>
> Thanks,
>

Maybe we can use the existing releng-tools repo to store the external 
projects specs that we need, I think that as they are part of the 
release process they fit well there.

--
David Caro

Red Hat S.L.
Continuous Integration Engineer - EMEA ENG Virtualization R&D

Email: dcaro at redhat.com
Web: www.redhat.com
RHT Global #: 82-62605

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20140110/18203442/attachment.sig>

From sbonazzo at redhat.com  Fri Jan 10 10:29:39 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Fri, 10 Jan 2014 11:29:39 +0100
Subject: oVirt 3.4.0 alpha delayed
Message-ID: <52CFCB93.20506@redhat.com>

Hi,
oVirt 3.4.0 alpha will be delayed due to packages dependencies issue.
Maintainers are already working on this, alpha will be released just after all dependency issues will have been fixed.

Details on dependency missing:

on CentOS 6.5:
[ovirt-3.4.0-alpha]
name=Alpha builds of the oVirt 3.4 project
baseurl=http://resources.ovirt.org/releases/3.4.0-alpha/rpm/EL/$releasever/
enabled=1
skip_if_unavailable=1
gpgcheck=0

# repoclosure -r ovirt-3.4.0-alpha -l ovirt-3.3.2 -l base -l epel -l glusterfs-epel -l updates -l extra -l glusterfs-noarch-epel -l ovirt-stable -n
Reading in repository metadata - please wait....
Checking Dependencies
Repos looked at: 8
   base
   epel
   glusterfs-epel
   glusterfs-noarch-epel
   ovirt-3.3.2
   ovirt-3.4.0-alpha
   ovirt-stable
   updates
Num Packages in Repos: 16581
package: mom-0.3.2-20140101.git2691f25.el6.noarch from ovirt-3.4.0-alpha
  unresolved deps:
     procps-ng
package: otopi-devel-1.2.0-0.0.master.20130910.git4387efb.el6.noarch from ovirt-3.4.0-alpha
  unresolved deps:
     otopi-java = 0:1.2.0-0.0.master.20130910.git4387efb.el6
package: ovirt-engine-sdk-java-3.4.0.1-1.el6.noarch from ovirt-3.4.0-alpha
  unresolved deps:
     httpcomponents-client >= 0:4.2
     apache-commons-logging
     apache-commons-beanutils
package: vdsm-hook-vhostmd-4.14.0-1.git6fdd55f.el6.noarch from ovirt-3.4.0-alpha
  unresolved deps:
     vhostmd


On Fedora 19:
[ovirt-3.4.0-alpha]
name=Alpha builds of the oVirt 3.4 project
baseurl=http://resources.ovirt.org/releases/3.4.0-alpha/rpm/Fedora/$releasever/
enabled=1
skip_if_unavailable=1
gpgcheck=0

# repoclosure -n -r ovirt-3.4.0-alpha -l fedora -l updates -l ovirt-stable
Reading in repository metadata - please wait....
Checking Dependencies
Repos looked at: 4
   fedora
   ovirt-3.4.0-alpha
   ovirt-stable
   updates
Num Packages in Repos: 38832
package: otopi-devel-1.2.0-0.0.master.20130910.git4387efb.fc19.noarch from ovirt-3.4.0-alpha
  unresolved deps:
     otopi-java = 0:1.2.0-0.0.master.20130910.git4387efb.fc19
package: ovirt-engine-3.4.0-0.2.master.20140109103311.git6524789.fc19.noarch from ovirt-3.4.0-alpha
  unresolved deps:
     openstack-java-resteasy-connector >= 0:3.0.2
     openstack-java-quantum-model >= 0:3.0.2
     openstack-java-quantum-client >= 0:3.0.2
     openstack-java-keystone-model >= 0:3.0.2
     openstack-java-keystone-client >= 0:3.0.2
     openstack-java-glance-model >= 0:3.0.2
     openstack-java-glance-client >= 0:3.0.2
     openstack-java-client >= 0:3.0.2
package: ovirt-engine-reports-3.4.0-0.2.master.20140109102135.fc19.noarch from ovirt-3.4.0-alpha
  unresolved deps:
     ovirt-engine-dwh >= 0:3.4.0


On Fedora 20 (ovirt-stable doesn't support Fedora 20):
[ovirt-3.4.0-alpha]
name=Alpha builds of the oVirt 3.4 project
baseurl=http://resources.ovirt.org/releases/3.4.0-alpha/rpm/Fedora/$releasever/
enabled=1
skip_if_unavailable=1
gpgcheck=0

# repoclosure -n -r ovirt-3.4.0-alpha -l fedora -l updates
Reading in repository metadata - please wait....
Checking Dependencies
Repos looked at: 3
   fedora
   ovirt-3.4.0-alpha
   updates
Num Packages in Repos: 38822
package: otopi-devel-1.2.0-0.0.master.20130910.git4387efb.fc19.noarch from ovirt-3.4.0-alpha
  unresolved deps:
     otopi-java = 0:1.2.0-0.0.master.20130910.git4387efb.fc19
package: ovirt-engine-3.4.0-0.2.master.20140109103311.git6524789.fc19.noarch from ovirt-3.4.0-alpha
  unresolved deps:
     openstack-java-resteasy-connector >= 0:3.0.2
     openstack-java-quantum-model >= 0:3.0.2
     openstack-java-quantum-client >= 0:3.0.2
     openstack-java-keystone-model >= 0:3.0.2
     openstack-java-keystone-client >= 0:3.0.2
     openstack-java-glance-model >= 0:3.0.2
     openstack-java-glance-client >= 0:3.0.2
     openstack-java-client >= 0:3.0.2
package: ovirt-engine-reports-3.4.0-0.2.master.20140109102135.fc19.noarch from ovirt-3.4.0-alpha
  unresolved deps:
     ovirt-engine-dwh >= 0:3.4.0

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


From sbonazzo at redhat.com  Fri Jan 10 10:36:08 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Fri, 10 Jan 2014 11:36:08 +0100
Subject: ovirt-specs project needed
In-Reply-To: <52CFCAB9.1080000@redhat.com>
References: <52CFC27C.1090308@redhat.com> <52CFCAB9.1080000@redhat.com>
Message-ID: <52CFCD18.6080604@redhat.com>

Il 10/01/2014 11:26, David Caro ha scritto:
> El vie 10 ene 2014 10:50:52 CET, Sandro Bonazzola escribi?:
>> Hi,
>> can you please create a new gerrit project named ovirt-specs?
>> it will contain .spec files for needed packages not provided by downstream distributions.
>> It will contain:
>> - httpcomponents-core (needed by java sdk, missing on CentOS)
>> - httpcomponents-client (needed by java sdk, missing on CentOS)
>>
>> It should contain also jasper server, actually in its own repository and jboss actually packaged by us but without a git repo for the spec file.
>>
>> Thanks,
>>
> 
> Maybe we can use the existing releng-tools repo to store the external 
> projects specs that we need, I think that as they are part of the 
> release process they fit well there.

looks good to me.
Juan, can you push needed spec file there?



> 
> --
> David Caro
> 
> Red Hat S.L.
> Continuous Integration Engineer - EMEA ENG Virtualization R&D
> 
> Email: dcaro at redhat.com
> Web: www.redhat.com
> RHT Global #: 82-62605
> 


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


From sander at grendelman.com  Fri Jan 10 11:52:48 2014
From: sander at grendelman.com (Sander Grendelman)
Date: Fri, 10 Jan 2014 12:52:48 +0100
Subject: [Users] [QE] 3.4.0 Release tracker
In-Reply-To: <52CD105E.2040409@redhat.com>
References: <52CD105E.2040409@redhat.com>
Message-ID: <CAHa6cRR3kscfByXDnUxovSn5z5J3dOMmtkzc9gJo_Y+3hXyZHA@mail.gmail.com>

Can I propose BZ#1035314 for 3.3.3 or 3.4.0, simple, trivial fix to a hook.

On Wed, Jan 8, 2014 at 9:46 AM, Sandro Bonazzola <sbonazzo at redhat.com> wrote:
> Hi,
>
> as you may know, we're planning to build oVirt 3.4.0 beta really soon and release 3.4.0 by end of January.
> A tracker bug (https://bugzilla.redhat.com/show_bug.cgi?id=1024889) has been created for this release.
>
> The following is a list of the current blocker bugs with target 3.4.0:
> Whiteboard      Bug ID  Summary
> storage 1032686 [RFE] API to save OVF on any location
> storage 1032679 [RFE] Single Disk Snapshots
> network 987813  [RFE] report BOOTPROTO and BONDING_OPTS independent of netdevice.cfg
>
>
> The following is a list of the bugs with target 3.4.0 not yet fixed:
>
> Whiteboard      Bug ID  Summary
> gluster         1008980 [oVirt] Option 'Select as SPM' available for a host in gluster-only mode of oVirt
> gluster         1038988 Gluster brick sync does not work when host has multiple interfaces
> i18n            1033730 [es-ES] need to revise the "create snapshot" translation
> infra           870330  Cache records in memory
> infra           904029  [engine-manage-domains] should use POSIX parameter form and aliases as values
> infra           979231  oVirt Node Upgrade: Support N configuration
> infra           986882  tar which is used by host-deploy is missing from fedora minimal installation
> infra           995362  [RFE] Support firewalld
> infra           1016634 Performance hit as a result of duplicate updates to VdsDynamic in VdsUpdateRuntimeInfo
> infra           1023751 [RFE] Create Bin Overrider for application context files changes we do in JRS
> infra           1023754 [RFE] add trigger to stop etl connection via engine db value.
> infra           1023759 [RFE] re-implement SSO solution based on JRS new SSO interface
> infra           1023761 [RFE] Build nightly JRS builds based on latest JRS version
> infra           1028793 systemctl start vdsmd blocks if dns server unreachable
> infra           1032682 Refactor authentication framework in engine
> infra           1035844 [oVirt][infra] Add host/Reinstall radio button text not actionable
> infra           1045350 REST error during VM creation via API
> infra           1046611 [oVirt][infra] Device custom properties syntax check is wrong
> integration     789040  [RFE] Log Collector should be able to run without asking questions
> integration     967350  [RFE] port dwh installer to otopi
> integration     967351  [RFE] port reports installer to otopi
> integration     1023752 [RFE] add upstream support for Centos el6 arch.
> integration     1024028 [RFE] add trigger to stop etl connection via engine db value.
> integration     1028489 [RFE] pre-populate ISO DOMAIN  with rhev-tools-setup.iso (or equiv)
> integration     1028913 'service network start' sometimes fails during setup
> integration     1037663 F20 - ovirt-log-collector: conflicts with file from package sos-3.0-3.fc20.noarch
> integration     1039616 Setting shmmax on F19 is not enough for starting postgres
> network         987832  failed to add ovirtmgmt bridge when the host has static ip
> network         1001186 With AIO installer and NetworkManager enabled, the ovirtmgmt bridge is not properly configured
> network         1010663 override mtu field allows only values up to 9000
> network         1018947 Yum update to oVirt 3.3 from 3.1.0 fails on CentOS 6.4 with EPEL dependency on python-inotify
> network         1037612 [oVirt][network][RFE] Add "sync" column to hosts sub tab under networks main tab
> network         1040580 [RFE] Apply networks changes to multiple hosts
> network         1040586 [RFE] Ability to configure network on multiple hosts at once
> network         1043220 [oVirt][network][RFE] Add Security-Group support for Neutron based networks
> network         1043230 Allow configuring Network QoS on host interfaces
> network         1044479 Make an iproute2 network configurator for vdsm
> network         1048738 [oVirt][network][RFE] Add subnet support for neutron  based networks
> network         1048740 [oVirt][network][RFE] Allow deleting Neutron based network (in Neutron)
> network         1048880 [vdsm][openstacknet] Migration fails for vNIC using OVS + security groups
> sla             994712  Remove underscores for pre-defined policy names
> sla             1038616 [RFE] Support for hosted engine
> storage         888711  PosixFS issues
> storage         961532  [RFE] Handle iSCSI lun resize
> storage         1009610 [RFE] Provide clear warning when SPM become inaccessible and needs fencing
> storage         1034081 Misleading error message when adding an existing Storage Domain
> storage         1038053 [RFE] Allow domain of multiple types in a single Data Center
> storage         1045842 After deleting image failed ui display message: Disk gluster-test was successfully removed from...
> ux              784779  [webadmin][RFE] Login page. Add a link to welcome page
> ux              1014859 [RFE] improve context-sensitive help csv mapping files
> ux              1035566 [RFE] [oVirt][webadmin] Change comment column title to icon, and move to right of name
> ux              1048916 sub-tab events in different main-tabs are being duplicated
> virt            953340  console from rhevm-shell/ovirt-shell using spicec does not work (linux client)
> virt            975730  [RFE] pass session id to spice via mime type to allow spice Menu Using REST
> virt            987957  [RFE] edit VM dialog - nics appear in random order (not sorted by name)
> virt            1031040 [RFE] RunOnce dialog can not set a vnc keymap itself
> virt            1033547 [RFE] Configure both SPICE and VNC display console
> virt            1035279 Allow to disable SSO per VM
> virt            1038587 Show name of the template in General tab for a vm if the vm is deployed from template via clone allocation.
> virt            1040088 [RFE] Add FreeBSD to the list of VM operating systems
> virt            1043469 ovirt-guest-agent for openSUSE
> virt            1043471 ovirt-guest-agent for SLES
> virt            1043473 ovirt-guest-agent for Ubuntu
> virt            1043474 ovirt-guest-agent for Debian
>                 753296  [RFE] Enable FIPS mode
>                 753306  SR-IOV support
>                 753309  [RFE] Workaround for enable/disable services via persist cmd
>                 806317  [RFE] ovirt-node regenerates kdump ramdisk image on every boot
>                 832000  Reduce number of kargs to enable a better automated installation with PXE
>                 846963  [oVirt-node] Upgrade ovirt-node with "ovirt_upgrade" parameter failed
>                 850386  Introduce new systemd-rpm macros in ovirt-node spec file
>                 893950  Make ovirt-node more FHS
>                 908902  Add specififc log handlers (log files) for transactions and ui
>                 909369  Use blivet during installation
>                 918270  Refactor and isolate block device discovery
>                 918957  [TUI] Confirmation for reboot
>                 947406  Add notice field
>                 947407  Status of caps-lock should be shown near password fields
>                 953870  Migrate to livemedia-creator
>                 966320  ovirt node will also enable ipv4 with dhcp protocol when only setting ipv6 with dhcp
>                 966498  Change sensitivity of widgets recursively
>                 969340  Migrate ovirt-node-installer backend and ovirt-auto-install backend to new code base
>                 974609  Add correct suffixes to scripts
>                 979067  [RFE] Add generic container handling
>                 979078  [RFE] <RETURN> can be used to Save a page
>                 979389  [RFE] use asciidoc for man pages
>                 980064  [RFE] Add mouse support to the console
>                 987824  [RFE] Need to add roll up and down ability to mouse control in multipage
>                 988337  Shown incorrect info for the item "VLAN ID" after configured nic with "vlan".
>                 988341  Should not create bond when report an error in configuration process
>                 995994  Could not add Fedora host when its version becomes "oVirt Node Hypervisor"
>                 997049  Allow nested transactions
>                 1001947 KeyboardInterrupt Exception when click mouse on UI
>                 1001950 RFE: same action on all ovirt-node-install page for press enter
>                 1002176 Not enough debugging informations in log files
>                 1002620 [RFE] Create central augeas object
>                 1003234 password.py: Using "set_admin_password" to change admin password failed in single mode
>                 1005148 [RFE] Add documentation on how to deploy Node with Puppet/Foreman
>                 1007191 RFE:  Support "BOOTIF=bondname" in auto-install parameters
>                 1008891 Installer goes to next page after returning from shell
>                 1011901 Report traceback infos about errors when starting ntpdate, rpcidmapd and rpcgssd services ...
>                 1013520 Miss some console info to show status by using "ovirt-node-upgrade" to upgrade ovirt-node
>                 1020227 /var/log/lastlog is missing
>                 1021647 Shared configuration keys to pass management informations
>                 1026646 Better to disable "enter" button works for the fan status table of ipmi page
>                 1027110 Better to disable cim transaction run and prompt ConfirmationDialog when configuring cim without providing password
>                 1027130 edit-node: Better to rename iso_name more simpler when install multiple packages
>                 1027161 plugin info shown incorrectly in plugins page when install multiple packages
>                 1029033 Link status shows disconnected although the cable is plugged.
>                 1032373 [RFE] enhance edit-node man page for uid/gid options help info a bit more
>                 1032374 [RFE] edit-node:Support specify multiple user, uid/group, gid elements changed
>                 1035441 [RFE] Sync versions between ovirt-node and overall ovirt
>
>
> Please set the target to 3.4.0 and add the bug to the tracker if you think that 3.4.0 should not be released without it fixed.
>
> Please also update the target to 3.4.1 or any next release for bugs that won't be in 3.4.0: it will ease gathering the blocking bugs for next releases.
>
> For those who want to help testing the bugs, I suggest to add yourself as QA contact for the bug.
>
>
> --
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users


From sbonazzo at redhat.com  Fri Jan 10 12:13:01 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Fri, 10 Jan 2014 13:13:01 +0100
Subject: [QE] oVirt 3.3.3 beta status
Message-ID: <52CFE3CD.4020405@redhat.com>

we're going to branch and build oVirt 3.3.3 beta on Monday 2014-01-13.
A bug tracker is available at [1] and it shows no bugs blocking the release
the following has been proposed as blocker for 3.3.3 or 3.4.0, not targeted to a specific version yet:

Bug 1035314 - vdsm-hook-nestedvt uses kvm_intel-only syntax

The following is a list of the non-blocking bugs still open with target 3.3.3:

Whiteboard	Bug ID	Summary
Whiteboard	Bug ID	Summary
infra		987982	When adding a host through the REST API, the error message says that "rootPassword" is required...
infra		1017267	Plaintext user passwords in async_tasks database
infra		1040022	vdsm-tool configurre errors when installing vdsm package
integration	902979	ovirt-live - firefox doesn't trust the installed engine
integration	1021805	[RFE] oVirt Live - use motd to show the admin password
integration	1022440	[RFE] AIO - configure the AIO host to be a gluster cluster/host
integration	1026930	Package virtio-win and put it in ovirt repositories
integration	1026933	pre-populate ISO domain with virtio-win ISO
network		906313	[oVirt-webadmin] [setupNetworks] "No valid Operation for <network_name> and Unassigned Logical Networks panel"
network		987916	[oVirt] [provider] Dialog doesn't update unless focus lost
network		997197	Some AppErrors messages are grammatically incorrect (singular vs plural)
network		1023722	[oVirt-webadmin][network] Network roles in cluster management should be radio buttons
sla		1049343	[oVirt] Disabled Balloon in Add Vm
storage		987917	[oVirt] [glance] API version not specified in provider dialog
ux		906394	[oVirt-webadmin] [network] Loading animation in network main tab 'hosts' and 'vms' subtab is stuck...
virt		1007940	Cannot clone from snapshot while using GlusterFS as POSIX Storage Domain
		906257	USB Flash Drive install of ovirt-node created via dd fails
		923049	ovirt-node fails to boot from local disk under UEFI mode
		965583	[RFE] add shortcut key on TUI
		976675	[wiki] Update contribution page
		979350	Changes admin password in the first time when log in is failed while finished auto-install
		979390	[RFE] Split defaults.py into smaller pieces
		982232	performance page takes >1sec to load (on first load)
		984441	kdump page crashed before configuring the network after ovirt-node intalled
		986285	UI crashes when no bond name is given
		991267	[RFE] Add TUI information to log file.
		1018374	ovirt-node-iso-3.0.1-1.0.2.vdsm.fc19: Failed on Auto-install
		1018710	[RFE] Enhance API documentation
		1032035	[RFE]re-write auto install function for the cim plugin
		1033286	ovirt-node-plugin-vdsm can not be added to ovirt node el6 base image

Maintainers:
Please add the bugs to the tracker if you think that 3.3.3 should not be released without them fixed.
Please re-target all bugs you don't think that should block 3.3.3.

For those who want to help testing the bugs, I suggest to add yourself as QA contact for the bug and add yourself to the testing page [2].

Maintainers are welcomed to start filling release notes, the page has been created here [3]


[1] http://bugzilla.redhat.com/1050084
[2] http://www.ovirt.org/Testing/Ovirt_3.3.3_testing
[3] http://www.ovirt.org/OVirt_3.3.3_release_notes

Thanks,


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


From dougsland at redhat.com  Fri Jan 10 15:15:24 2014
From: dougsland at redhat.com (Douglas Schilling Landgraf)
Date: Fri, 10 Jan 2014 10:15:24 -0500
Subject: oVirt 3.4.0 alpha repository closure failure
In-Reply-To: <20140110100137.GD26642@redhat.com>
References: <52CFA5E4.8000601@redhat.com> <20140110100137.GD26642@redhat.com>
Message-ID: <52D00E8C.2090108@redhat.com>

On 01/10/2014 05:01 AM, Dan Kenigsberg wrote:
> On Fri, Jan 10, 2014 at 08:48:52AM +0100, Sandro Bonazzola wrote:
>> Hi,
>> oVirt 3.4.0 alpha repository has been composed but alpha has not been announced due to repository closure failures:
>>
>> on CentOS 6.5:
>>
>> # repoclosure -r ovirt-3.4.0-alpha -l ovirt-3.3.2 -l base -l epel -l glusterfs-epel -l updates -l extra -l glusterfs-noarch-epel -l ovirt-stable -n
>> Reading in repository metadata - please wait....
>> Checking Dependencies
>> Repos looked at: 8
>>     base
>>     epel
>>     glusterfs-epel
>>     glusterfs-noarch-epel
>>     ovirt-3.3.2
>>     ovirt-3.4.0-alpha
>>     ovirt-stable
>>     updates
>> Num Packages in Repos: 16581
>> package: mom-0.3.2-20140101.git2691f25.el6.noarch from ovirt-3.4.0-alpha
>>    unresolved deps:
>>       procps-ng
>
> Adam, this seems like a real bug in http://gerrit.ovirt.org/#/c/22087/ :
> el6 still carries the older "procps" (which is, btw, provided by
> procps-ng).
>
>
>> package: vdsm-hook-vhostmd-4.14.0-1.git6fdd55f.el6.noarch from ovirt-3.4.0-alpha
>>    unresolved deps:
>>       vhostmd
>
> Douglas, could you add a with_vhostmd option to the spec, and have it
> default to 0 on el*, and to 1 on fedoras?

Done
http://gerrit.ovirt.org/#/c/23126/

-- 
Cheers
Douglas


From jhernand at redhat.com  Fri Jan 10 12:20:48 2014
From: jhernand at redhat.com (Juan Hernandez)
Date: Fri, 10 Jan 2014 13:20:48 +0100
Subject: ovirt-specs project needed
In-Reply-To: <52CFCD18.6080604@redhat.com>
References: <52CFC27C.1090308@redhat.com> <52CFCAB9.1080000@redhat.com>
	<52CFCD18.6080604@redhat.com>
Message-ID: <52CFE5A0.5050108@redhat.com>

On 01/10/2014 11:36 AM, Sandro Bonazzola wrote:
> Il 10/01/2014 11:26, David Caro ha scritto:
>> El vie 10 ene 2014 10:50:52 CET, Sandro Bonazzola escribi?:
>>> Hi,
>>> can you please create a new gerrit project named ovirt-specs?
>>> it will contain .spec files for needed packages not provided by downstream distributions.
>>> It will contain:
>>> - httpcomponents-core (needed by java sdk, missing on CentOS)
>>> - httpcomponents-client (needed by java sdk, missing on CentOS)
>>>
>>> It should contain also jasper server, actually in its own repository and jboss actually packaged by us but without a git repo for the spec file.
>>>
>>> Thanks,
>>>
>>
>> Maybe we can use the existing releng-tools repo to store the external 
>> projects specs that we need, I think that as they are part of the 
>> release process they fit well there.
> 
> looks good to me.
> Juan, can you push needed spec file there?
> 

Here they are:

http://gerrit.ovirt.org/23128


-- 
Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3?D, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat S.L.


From jhernand at redhat.com  Fri Jan 10 12:44:31 2014
From: jhernand at redhat.com (Juan Hernandez)
Date: Fri, 10 Jan 2014 13:44:31 +0100
Subject: ovirt-specs project needed
In-Reply-To: <52CFE5A0.5050108@redhat.com>
References: <52CFC27C.1090308@redhat.com> <52CFCAB9.1080000@redhat.com>
	<52CFCD18.6080604@redhat.com> <52CFE5A0.5050108@redhat.com>
Message-ID: <52CFEB2F.8090702@redhat.com>

On 01/10/2014 01:20 PM, Juan Hernandez wrote:
> On 01/10/2014 11:36 AM, Sandro Bonazzola wrote:
>> Il 10/01/2014 11:26, David Caro ha scritto:
>>> El vie 10 ene 2014 10:50:52 CET, Sandro Bonazzola escribi?:
>>>> Hi,
>>>> can you please create a new gerrit project named ovirt-specs?
>>>> it will contain .spec files for needed packages not provided by downstream distributions.
>>>> It will contain:
>>>> - httpcomponents-core (needed by java sdk, missing on CentOS)
>>>> - httpcomponents-client (needed by java sdk, missing on CentOS)
>>>>
>>>> It should contain also jasper server, actually in its own repository and jboss actually packaged by us but without a git repo for the spec file.
>>>>
>>>> Thanks,
>>>>
>>>
>>> Maybe we can use the existing releng-tools repo to store the external 
>>> projects specs that we need, I think that as they are part of the 
>>> release process they fit well there.
>>
>> looks good to me.
>> Juan, can you push needed spec file there?
>>
> 
> Here they are:
> 
> http://gerrit.ovirt.org/23128
> 
> 

Some thoughts on how I would suggest to manage these specs:

- We should have one directory per package, and store in that directory
the template for the .spec file, the build script and also the potential
patches.

- We should have one git branch for each major version of the RPM
distributions that we support. This is what the build systems of Fedora
and RHEL do, for example. So we should have branches like fc19, fc20,
el6, el7, etc. This way it is possible to have different specs for
different distributions without having to use multiple "if fedora/if
rhel" in the spec itself.

- I would even suggest to move the .spec files out from the main
repositories of other components and into this repository. In particular
I would like to do that for the SDKs and the CLI (that is why I
initially suggested to name it "ovirt-specs").

-- 
Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3?D, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat S.L.


From jhernand at redhat.com  Fri Jan 10 12:52:21 2014
From: jhernand at redhat.com (Juan Hernandez)
Date: Fri, 10 Jan 2014 13:52:21 +0100
Subject: [Engine-devel] oVirt 3.4.0 alpha repository closure failure
In-Reply-To: <52CFA5E4.8000601@redhat.com>
References: <52CFA5E4.8000601@redhat.com>
Message-ID: <52CFED05.1020304@redhat.com>

On 01/10/2014 08:48 AM, Sandro Bonazzola wrote:
> Hi,
> oVirt 3.4.0 alpha repository has been composed but alpha has not been announced due to repository closure failures:
> 
> on CentOS 6.5:
> 
> # repoclosure -r ovirt-3.4.0-alpha -l ovirt-3.3.2 -l base -l epel -l glusterfs-epel -l updates -l extra -l glusterfs-noarch-epel -l ovirt-stable -n
> Reading in repository metadata - please wait....
> Checking Dependencies
> Repos looked at: 8
>    base
>    epel
>    glusterfs-epel
>    glusterfs-noarch-epel
>    ovirt-3.3.2
>    ovirt-3.4.0-alpha
>    ovirt-stable
>    updates
> Num Packages in Repos: 16581
> package: mom-0.3.2-20140101.git2691f25.el6.noarch from ovirt-3.4.0-alpha
>   unresolved deps:
>      procps-ng
> package: otopi-devel-1.2.0-0.0.master.20130910.git4387efb.el6.noarch from ovirt-3.4.0-alpha
>   unresolved deps:
>      otopi-java = 0:1.2.0-0.0.master.20130910.git4387efb.el6
> package: ovirt-engine-sdk-java-3.4.0.1-1.el6.noarch from ovirt-3.4.0-alpha
>   unresolved deps:
>      httpcomponents-client >= 0:4.2
>      apache-commons-logging
>      apache-commons-beanutils

To solve this issue we need to provide our own HttpComponents packages:
for EL6, see here:

http://gerrit.ovirt.org/23128

And also we need to fix the Java SDK spec:

http://gerrit.ovirt.org/23132

> package: vdsm-hook-vhostmd-4.14.0-1.git6fdd55f.el6.noarch from ovirt-3.4.0-alpha
>   unresolved deps:
>      vhostmd
> 
> 
> On Fedora 19:
> # repoclosure -n -r ovirt-3.4.0-alpha -l fedora -l updates -l ovirt-stable
> Reading in repository metadata - please wait....
> Checking Dependencies
> Repos looked at: 4
>    fedora
>    ovirt-3.4.0-alpha
>    ovirt-stable
>    updates
> Num Packages in Repos: 38832
> package: otopi-devel-1.2.0-0.0.master.20130910.git4387efb.fc19.noarch from ovirt-3.4.0-alpha
>   unresolved deps:
>      otopi-java = 0:1.2.0-0.0.master.20130910.git4387efb.fc19
> package: ovirt-engine-3.4.0-0.2.master.20140109103311.git6524789.fc19.noarch from ovirt-3.4.0-alpha
>   unresolved deps:
>      openstack-java-resteasy-connector >= 0:3.0.2
>      openstack-java-quantum-model >= 0:3.0.2
>      openstack-java-quantum-client >= 0:3.0.2
>      openstack-java-keystone-model >= 0:3.0.2
>      openstack-java-keystone-client >= 0:3.0.2
>      openstack-java-glance-model >= 0:3.0.2
>      openstack-java-glance-client >= 0:3.0.2
>      openstack-java-client >= 0:3.0.2
> package: ovirt-engine-reports-3.4.0-0.2.master.20140109102135.fc19.noarch from ovirt-3.4.0-alpha
>   unresolved deps:
>      ovirt-engine-dwh >= 0:3.4.0
> 
> 
> On Fedora 20 (ovirt-stable doesn't support Fedora 20):
> 
> # repoclosure -n -r ovirt-3.4.0-alpha -l fedora -l updates
> Reading in repository metadata - please wait....
> Checking Dependencies
> Repos looked at: 3
>    fedora
>    ovirt-3.4.0-alpha
>    updates
> Num Packages in Repos: 38822
> package: otopi-devel-1.2.0-0.0.master.20130910.git4387efb.fc19.noarch from ovirt-3.4.0-alpha
>   unresolved deps:
>      otopi-java = 0:1.2.0-0.0.master.20130910.git4387efb.fc19
> package: ovirt-engine-3.4.0-0.2.master.20140109103311.git6524789.fc19.noarch from ovirt-3.4.0-alpha
>   unresolved deps:
>      openstack-java-resteasy-connector >= 0:3.0.2
>      openstack-java-quantum-model >= 0:3.0.2
>      openstack-java-quantum-client >= 0:3.0.2
>      openstack-java-keystone-model >= 0:3.0.2
>      openstack-java-keystone-client >= 0:3.0.2
>      openstack-java-glance-model >= 0:3.0.2
>      openstack-java-glance-client >= 0:3.0.2
>      openstack-java-client >= 0:3.0.2
> package: ovirt-engine-reports-3.4.0-0.2.master.20140109102135.fc19.noarch from ovirt-3.4.0-alpha
>   unresolved deps:
>      ovirt-engine-dwh >= 0:3.4.0
> 
> 
> Please fix dependencies / provide missing packages / provide additional repositories as soon as possible.
> Thanks,
> 


-- 
Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3?D, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat S.L.


From alitke at redhat.com  Fri Jan 10 13:46:56 2014
From: alitke at redhat.com (Adam Litke)
Date: Fri, 10 Jan 2014 08:46:56 -0500
Subject: oVirt 3.4.0 alpha repository closure failure
In-Reply-To: <20140110100137.GD26642@redhat.com>
References: <52CFA5E4.8000601@redhat.com> <20140110100137.GD26642@redhat.com>
Message-ID: <20140110134655.GD15795@redhat.com>

On 10/01/14 10:01 +0000, Dan Kenigsberg wrote:
>On Fri, Jan 10, 2014 at 08:48:52AM +0100, Sandro Bonazzola wrote:
>> Hi,
>> oVirt 3.4.0 alpha repository has been composed but alpha has not been announced due to repository closure failures:
>>
>> on CentOS 6.5:
>>
>> # repoclosure -r ovirt-3.4.0-alpha -l ovirt-3.3.2 -l base -l epel -l glusterfs-epel -l updates -l extra -l glusterfs-noarch-epel -l ovirt-stable -n
>> Reading in repository metadata - please wait....
>> Checking Dependencies
>> Repos looked at: 8
>>    base
>>    epel
>>    glusterfs-epel
>>    glusterfs-noarch-epel
>>    ovirt-3.3.2
>>    ovirt-3.4.0-alpha
>>    ovirt-stable
>>    updates
>> Num Packages in Repos: 16581
>> package: mom-0.3.2-20140101.git2691f25.el6.noarch from ovirt-3.4.0-alpha
>>   unresolved deps:
>>      procps-ng
>
>Adam, this seems like a real bug in http://gerrit.ovirt.org/#/c/22087/ :
>el6 still carries the older "procps" (which is, btw, provided by
>procps-ng).

Done.
http://gerrit.ovirt.org/23137

>
>
>> package: vdsm-hook-vhostmd-4.14.0-1.git6fdd55f.el6.noarch from ovirt-3.4.0-alpha
>>   unresolved deps:
>>      vhostmd
>
>Douglas, could you add a with_vhostmd option to the spec, and have it
>default to 0 on el*, and to 1 on fedoras?
>
>Thanks,
>Dan.


From iheim at redhat.com  Fri Jan 10 14:15:50 2014
From: iheim at redhat.com (Itamar Heim)
Date: Fri, 10 Jan 2014 16:15:50 +0200
Subject: [QE] 3.4.0 Release tracker
In-Reply-To: <52CD105E.2040409@redhat.com>
References: <52CD105E.2040409@redhat.com>
Message-ID: <52D00096.6040607@redhat.com>

On 01/08/2014 10:46 AM, Sandro Bonazzola wrote:
> Hi,
>
> as you may know, we're planning to build oVirt 3.4.0 beta really soon and release 3.4.0 by end of January.
> A tracker bug (https://bugzilla.redhat.com/show_bug.cgi?id=1024889) has been created for this release.
>
> The following is a list of the current blocker bugs with target 3.4.0:
> Whiteboard	Bug ID	Summary
> storage	1032686	[RFE] API to save OVF on any location
> storage	1032679	[RFE] Single Disk Snapshots
> network	987813	[RFE] report BOOTPROTO and BONDING_OPTS independent of netdevice.cfg

I don't think RFEs should be blocking the release by default.
(we may want to discuss if we allow any RFE not making the feature 
freeze and stable branch a few extra days).

>
>
> The following is a list of the bugs with target 3.4.0 not yet fixed:
>
> Whiteboard	Bug ID	Summary
> gluster		1008980	[oVirt] Option 'Select as SPM' available for a host in gluster-only mode of oVirt
> gluster		1038988	Gluster brick sync does not work when host has multiple interfaces
> i18n		1033730	[es-ES] need to revise the "create snapshot" translation
> infra		870330	Cache records in memory
> infra		904029	[engine-manage-domains] should use POSIX parameter form and aliases as values
> infra		979231	oVirt Node Upgrade: Support N configuration
> infra		986882	tar which is used by host-deploy is missing from fedora minimal installation
> infra		995362	[RFE] Support firewalld
> infra		1016634	Performance hit as a result of duplicate updates to VdsDynamic in VdsUpdateRuntimeInfo
> infra		1023751	[RFE] Create Bin Overrider for application context files changes we do in JRS
> infra		1023754	[RFE] add trigger to stop etl connection via engine db value.
> infra		1023759	[RFE] re-implement SSO solution based on JRS new SSO interface
> infra		1023761	[RFE] Build nightly JRS builds based on latest JRS version
> infra		1028793	systemctl start vdsmd blocks if dns server unreachable
> infra		1032682	Refactor authentication framework in engine
> infra		1035844	[oVirt][infra] Add host/Reinstall radio button text not actionable
> infra		1045350	REST error during VM creation via API
> infra		1046611	[oVirt][infra] Device custom properties syntax check is wrong
> integration	789040	[RFE] Log Collector should be able to run without asking questions
> integration	967350	[RFE] port dwh installer to otopi
> integration	967351	[RFE] port reports installer to otopi
> integration	1023752	[RFE] add upstream support for Centos el6 arch.
> integration	1024028	[RFE] add trigger to stop etl connection via engine db value.
> integration	1028489	[RFE] pre-populate ISO DOMAIN  with rhev-tools-setup.iso (or equiv)
> integration	1028913	'service network start' sometimes fails during setup
> integration	1037663	F20 - ovirt-log-collector: conflicts with file from package sos-3.0-3.fc20.noarch
> integration	1039616	Setting shmmax on F19 is not enough for starting postgres
> network		987832	failed to add ovirtmgmt bridge when the host has static ip
> network		1001186	With AIO installer and NetworkManager enabled, the ovirtmgmt bridge is not properly configured
> network		1010663	override mtu field allows only values up to 9000
> network		1018947	Yum update to oVirt 3.3 from 3.1.0 fails on CentOS 6.4 with EPEL dependency on python-inotify
> network		1037612	[oVirt][network][RFE] Add "sync" column to hosts sub tab under networks main tab
> network		1040580	[RFE] Apply networks changes to multiple hosts
> network		1040586	[RFE] Ability to configure network on multiple hosts at once
> network		1043220	[oVirt][network][RFE] Add Security-Group support for Neutron based networks
> network		1043230	Allow configuring Network QoS on host interfaces
> network		1044479	Make an iproute2 network configurator for vdsm
> network		1048738	[oVirt][network][RFE] Add subnet support for neutron  based networks
> network		1048740	[oVirt][network][RFE] Allow deleting Neutron based network (in Neutron)
> network		1048880	[vdsm][openstacknet] Migration fails for vNIC using OVS + security groups
> sla		994712	Remove underscores for pre-defined policy names
> sla		1038616	[RFE] Support for hosted engine
> storage		888711	PosixFS issues
> storage		961532	[RFE] Handle iSCSI lun resize
> storage		1009610	[RFE] Provide clear warning when SPM become inaccessible and needs fencing
> storage		1034081	Misleading error message when adding an existing Storage Domain
> storage		1038053	[RFE] Allow domain of multiple types in a single Data Center
> storage		1045842	After deleting image failed ui display message: Disk gluster-test was successfully removed from...
> ux		784779	[webadmin][RFE] Login page. Add a link to welcome page
> ux		1014859	[RFE] improve context-sensitive help csv mapping files
> ux		1035566	[RFE] [oVirt][webadmin] Change comment column title to icon, and move to right of name
> ux		1048916	sub-tab events in different main-tabs are being duplicated
> virt		953340	console from rhevm-shell/ovirt-shell using spicec does not work (linux client)
> virt		975730	[RFE] pass session id to spice via mime type to allow spice Menu Using REST
> virt		987957	[RFE] edit VM dialog - nics appear in random order (not sorted by name)
> virt		1031040	[RFE] RunOnce dialog can not set a vnc keymap itself
> virt		1033547	[RFE] Configure both SPICE and VNC display console
> virt		1035279	Allow to disable SSO per VM
> virt		1038587	Show name of the template in General tab for a vm if the vm is deployed from template via clone allocation.
> virt		1040088	[RFE] Add FreeBSD to the list of VM operating systems
> virt		1043469	ovirt-guest-agent for openSUSE
> virt		1043471	ovirt-guest-agent for SLES
> virt		1043473	ovirt-guest-agent for Ubuntu
> virt		1043474	ovirt-guest-agent for Debian
> 		753296	[RFE] Enable FIPS mode
> 		753306	SR-IOV support
> 		753309	[RFE] Workaround for enable/disable services via persist cmd
> 		806317	[RFE] ovirt-node regenerates kdump ramdisk image on every boot
> 		832000	Reduce number of kargs to enable a better automated installation with PXE
> 		846963	[oVirt-node] Upgrade ovirt-node with "ovirt_upgrade" parameter failed
> 		850386	Introduce new systemd-rpm macros in ovirt-node spec file
> 		893950	Make ovirt-node more FHS
> 		908902	Add specififc log handlers (log files) for transactions and ui
> 		909369	Use blivet during installation
> 		918270	Refactor and isolate block device discovery
> 		918957	[TUI] Confirmation for reboot
> 		947406	Add notice field
> 		947407	Status of caps-lock should be shown near password fields
> 		953870	Migrate to livemedia-creator
> 		966320	ovirt node will also enable ipv4 with dhcp protocol when only setting ipv6 with dhcp
> 		966498	Change sensitivity of widgets recursively
> 		969340	Migrate ovirt-node-installer backend and ovirt-auto-install backend to new code base
> 		974609	Add correct suffixes to scripts
> 		979067	[RFE] Add generic container handling
> 		979078	[RFE] <RETURN> can be used to Save a page
> 		979389	[RFE] use asciidoc for man pages
> 		980064	[RFE] Add mouse support to the console
> 		987824	[RFE] Need to add roll up and down ability to mouse control in multipage
> 		988337	Shown incorrect info for the item "VLAN ID" after configured nic with "vlan".
> 		988341	Should not create bond when report an error in configuration process
> 		995994	Could not add Fedora host when its version becomes "oVirt Node Hypervisor"
> 		997049	Allow nested transactions
> 		1001947	KeyboardInterrupt Exception when click mouse on UI
> 		1001950	RFE: same action on all ovirt-node-install page for press enter
> 		1002176	Not enough debugging informations in log files
> 		1002620	[RFE] Create central augeas object
> 		1003234	password.py: Using "set_admin_password" to change admin password failed in single mode
> 		1005148	[RFE] Add documentation on how to deploy Node with Puppet/Foreman
> 		1007191	RFE:  Support "BOOTIF=bondname" in auto-install parameters
> 		1008891	Installer goes to next page after returning from shell
> 		1011901	Report traceback infos about errors when starting ntpdate, rpcidmapd and rpcgssd services ...
> 		1013520	Miss some console info to show status by using "ovirt-node-upgrade" to upgrade ovirt-node
> 		1020227	/var/log/lastlog is missing
> 		1021647	Shared configuration keys to pass management informations
> 		1026646	Better to disable "enter" button works for the fan status table of ipmi page
> 		1027110	Better to disable cim transaction run and prompt ConfirmationDialog when configuring cim without providing password
> 		1027130	edit-node: Better to rename iso_name more simpler when install multiple packages
> 		1027161	plugin info shown incorrectly in plugins page when install multiple packages
> 		1029033	Link status shows disconnected although the cable is plugged.
> 		1032373	[RFE] enhance edit-node man page for uid/gid options help info a bit more
> 		1032374	[RFE] edit-node:Support specify multiple user, uid/group, gid elements changed
> 		1035441	[RFE] Sync versions between ovirt-node and overall ovirt
>
>
> Please set the target to 3.4.0 and add the bug to the tracker if you think that 3.4.0 should not be released without it fixed.
>
> Please also update the target to 3.4.1 or any next release for bugs that won't be in 3.4.0: it will ease gathering the blocking bugs for next releases.
>
> For those who want to help testing the bugs, I suggest to add yourself as QA contact for the bug.
>
>



From iheim at redhat.com  Fri Jan 10 14:18:51 2014
From: iheim at redhat.com (Itamar Heim)
Date: Fri, 10 Jan 2014 16:18:51 +0200
Subject: [Users] [QE] 3.4.0 Release tracker
In-Reply-To: <12EF8D94C6F8734FB2FF37B9FBEDD173585B8F52@EXCHANGE.collogia.de>
References: <52CD105E.2040409@redhat.com>
	<12EF8D94C6F8734FB2FF37B9FBEDD173585B8F52@EXCHANGE.collogia.de>
Message-ID: <52D0014B.20008@redhat.com>

On 01/08/2014 10:51 AM, Markus Stockhausen wrote:
>> integration     1037663 F20 - ovirt-log-collector: conflicts with file from package sos-3.0-3.fc20.noarch
>
> Given the fact that F20 is already relased and Ovirt 3.4.0 is intended to support it ... shouldn't that be a blocker?

well, it could also be released async if it has too many issues, but 
worth tracking, and having it for the test day.
I haven't seen the log collector used much (at all) when ovirt folks ask 
for help, so we could release without it for testing.




From iheim at redhat.com  Fri Jan 10 14:50:32 2014
From: iheim at redhat.com (Itamar Heim)
Date: Fri, 10 Jan 2014 16:50:32 +0200
Subject: [Users] [QE] 3.4.0 Release tracker
In-Reply-To: <CAHa6cRT4V6A4=UDu7G5coN_91m2jERWhNX=vtqj6eLJn=sWHcA@mail.gmail.com>
References: <52CD105E.2040409@redhat.com>
	<CAHa6cRT4V6A4=UDu7G5coN_91m2jERWhNX=vtqj6eLJn=sWHcA@mail.gmail.com>
Message-ID: <52D008B8.9060302@redhat.com>

On 01/08/2014 11:23 AM, Sander Grendelman wrote:
> Now that BZ#1038525 (live snapshot merge for backup api) is closed as a
> duplicate of BZ#647386 ( You are not authorized to access bug #647386.... )
>
> Shouldn't BZ#647386 targeted for 3.4? Or for a future version?

this is a rhev rfe. we're using ovirt RFEs to track ovirt development 
(all RFEs in the 3.4 planning googledoc are supposed to be ovirt ones).

live merge is high on the list (top of the list) - several items in 3.4 
are enablers to get it done.


From iheim at redhat.com  Fri Jan 10 14:52:07 2014
From: iheim at redhat.com (Itamar Heim)
Date: Fri, 10 Jan 2014 16:52:07 +0200
Subject: [Users] [QE] 3.4.0 Release tracker
In-Reply-To: <CAHa6cRTZdM=qiCX11szJ0a9PCstT-sVy9hTVYTwU=79TqPuxqw@mail.gmail.com>
References: <52CD105E.2040409@redhat.com>	<CAHa6cRT4V6A4=UDu7G5coN_91m2jERWhNX=vtqj6eLJn=sWHcA@mail.gmail.com>	<52CD1A60.3080002@redhat.com>
	<CAHa6cRTZdM=qiCX11szJ0a9PCstT-sVy9hTVYTwU=79TqPuxqw@mail.gmail.com>
Message-ID: <52D00917.5010906@redhat.com>

On 01/08/2014 11:45 AM, Sander Grendelman wrote:
> On Wed, Jan 8, 2014 at 10:29 AM, Sandro Bonazzola <sbonazzo at redhat.com> wrote:
>> Il 08/01/2014 10:23, Sander Grendelman ha scritto:
>>> Now that BZ#1038525 (live snapshot merge for backup api) is closed as a
>>> duplicate of BZ#647386 ( You are not authorized to access bug #647386.... )
>>>
>>> Shouldn't BZ#647386 targeted for 3.4? Or for a future version?
>>>
>>
>> BZ#1038525 is open and targeted to 3.5.0
> That is correct, I didn't scroll down far enough, my apologies.
> Any idea on why BZ#647386 is not visible for "regular" rhbz users?

there are various considerations for bugs or RFEs to be private in red 
hat. I'd rather we use ovirt RFEs to track ovirt development.





From iheim at redhat.com  Fri Jan 10 14:55:18 2014
From: iheim at redhat.com (Itamar Heim)
Date: Fri, 10 Jan 2014 16:55:18 +0200
Subject: [Users] [QE] 3.4.0 Release tracker
In-Reply-To: <CAHa6cRR3kscfByXDnUxovSn5z5J3dOMmtkzc9gJo_Y+3hXyZHA@mail.gmail.com>
References: <52CD105E.2040409@redhat.com>
	<CAHa6cRR3kscfByXDnUxovSn5z5J3dOMmtkzc9gJo_Y+3hXyZHA@mail.gmail.com>
Message-ID: <52D009D6.8010908@redhat.com>

On 01/10/2014 01:52 PM, Sander Grendelman wrote:
> Can I propose BZ#1035314 for 3.3.3 or 3.4.0, simple, trivial fix to a hook.

Hi Sander,

please use bug summary so folks won't have to go and look what the 
number means just to see if relevant to them.

this is about:
Bug 1035314 - vdsm-hook-nestedvt uses kvm_intel-only syntax

i see you posted a patch in the bug - can you post the patch to gerrit 
as well?

thanks,
    Itamar

>
> On Wed, Jan 8, 2014 at 9:46 AM, Sandro Bonazzola <sbonazzo at redhat.com> wrote:
>> Hi,
>>
>> as you may know, we're planning to build oVirt 3.4.0 beta really soon and release 3.4.0 by end of January.
>> A tracker bug (https://bugzilla.redhat.com/show_bug.cgi?id=1024889) has been created for this release.
>>
>> The following is a list of the current blocker bugs with target 3.4.0:
>> Whiteboard      Bug ID  Summary
>> storage 1032686 [RFE] API to save OVF on any location
>> storage 1032679 [RFE] Single Disk Snapshots
>> network 987813  [RFE] report BOOTPROTO and BONDING_OPTS independent of netdevice.cfg
>>
>>
>> The following is a list of the bugs with target 3.4.0 not yet fixed:
>>
>> Whiteboard      Bug ID  Summary
>> gluster         1008980 [oVirt] Option 'Select as SPM' available for a host in gluster-only mode of oVirt
>> gluster         1038988 Gluster brick sync does not work when host has multiple interfaces
>> i18n            1033730 [es-ES] need to revise the "create snapshot" translation
>> infra           870330  Cache records in memory
>> infra           904029  [engine-manage-domains] should use POSIX parameter form and aliases as values
>> infra           979231  oVirt Node Upgrade: Support N configuration
>> infra           986882  tar which is used by host-deploy is missing from fedora minimal installation
>> infra           995362  [RFE] Support firewalld
>> infra           1016634 Performance hit as a result of duplicate updates to VdsDynamic in VdsUpdateRuntimeInfo
>> infra           1023751 [RFE] Create Bin Overrider for application context files changes we do in JRS
>> infra           1023754 [RFE] add trigger to stop etl connection via engine db value.
>> infra           1023759 [RFE] re-implement SSO solution based on JRS new SSO interface
>> infra           1023761 [RFE] Build nightly JRS builds based on latest JRS version
>> infra           1028793 systemctl start vdsmd blocks if dns server unreachable
>> infra           1032682 Refactor authentication framework in engine
>> infra           1035844 [oVirt][infra] Add host/Reinstall radio button text not actionable
>> infra           1045350 REST error during VM creation via API
>> infra           1046611 [oVirt][infra] Device custom properties syntax check is wrong
>> integration     789040  [RFE] Log Collector should be able to run without asking questions
>> integration     967350  [RFE] port dwh installer to otopi
>> integration     967351  [RFE] port reports installer to otopi
>> integration     1023752 [RFE] add upstream support for Centos el6 arch.
>> integration     1024028 [RFE] add trigger to stop etl connection via engine db value.
>> integration     1028489 [RFE] pre-populate ISO DOMAIN  with rhev-tools-setup.iso (or equiv)
>> integration     1028913 'service network start' sometimes fails during setup
>> integration     1037663 F20 - ovirt-log-collector: conflicts with file from package sos-3.0-3.fc20.noarch
>> integration     1039616 Setting shmmax on F19 is not enough for starting postgres
>> network         987832  failed to add ovirtmgmt bridge when the host has static ip
>> network         1001186 With AIO installer and NetworkManager enabled, the ovirtmgmt bridge is not properly configured
>> network         1010663 override mtu field allows only values up to 9000
>> network         1018947 Yum update to oVirt 3.3 from 3.1.0 fails on CentOS 6.4 with EPEL dependency on python-inotify
>> network         1037612 [oVirt][network][RFE] Add "sync" column to hosts sub tab under networks main tab
>> network         1040580 [RFE] Apply networks changes to multiple hosts
>> network         1040586 [RFE] Ability to configure network on multiple hosts at once
>> network         1043220 [oVirt][network][RFE] Add Security-Group support for Neutron based networks
>> network         1043230 Allow configuring Network QoS on host interfaces
>> network         1044479 Make an iproute2 network configurator for vdsm
>> network         1048738 [oVirt][network][RFE] Add subnet support for neutron  based networks
>> network         1048740 [oVirt][network][RFE] Allow deleting Neutron based network (in Neutron)
>> network         1048880 [vdsm][openstacknet] Migration fails for vNIC using OVS + security groups
>> sla             994712  Remove underscores for pre-defined policy names
>> sla             1038616 [RFE] Support for hosted engine
>> storage         888711  PosixFS issues
>> storage         961532  [RFE] Handle iSCSI lun resize
>> storage         1009610 [RFE] Provide clear warning when SPM become inaccessible and needs fencing
>> storage         1034081 Misleading error message when adding an existing Storage Domain
>> storage         1038053 [RFE] Allow domain of multiple types in a single Data Center
>> storage         1045842 After deleting image failed ui display message: Disk gluster-test was successfully removed from...
>> ux              784779  [webadmin][RFE] Login page. Add a link to welcome page
>> ux              1014859 [RFE] improve context-sensitive help csv mapping files
>> ux              1035566 [RFE] [oVirt][webadmin] Change comment column title to icon, and move to right of name
>> ux              1048916 sub-tab events in different main-tabs are being duplicated
>> virt            953340  console from rhevm-shell/ovirt-shell using spicec does not work (linux client)
>> virt            975730  [RFE] pass session id to spice via mime type to allow spice Menu Using REST
>> virt            987957  [RFE] edit VM dialog - nics appear in random order (not sorted by name)
>> virt            1031040 [RFE] RunOnce dialog can not set a vnc keymap itself
>> virt            1033547 [RFE] Configure both SPICE and VNC display console
>> virt            1035279 Allow to disable SSO per VM
>> virt            1038587 Show name of the template in General tab for a vm if the vm is deployed from template via clone allocation.
>> virt            1040088 [RFE] Add FreeBSD to the list of VM operating systems
>> virt            1043469 ovirt-guest-agent for openSUSE
>> virt            1043471 ovirt-guest-agent for SLES
>> virt            1043473 ovirt-guest-agent for Ubuntu
>> virt            1043474 ovirt-guest-agent for Debian
>>                  753296  [RFE] Enable FIPS mode
>>                  753306  SR-IOV support
>>                  753309  [RFE] Workaround for enable/disable services via persist cmd
>>                  806317  [RFE] ovirt-node regenerates kdump ramdisk image on every boot
>>                  832000  Reduce number of kargs to enable a better automated installation with PXE
>>                  846963  [oVirt-node] Upgrade ovirt-node with "ovirt_upgrade" parameter failed
>>                  850386  Introduce new systemd-rpm macros in ovirt-node spec file
>>                  893950  Make ovirt-node more FHS
>>                  908902  Add specififc log handlers (log files) for transactions and ui
>>                  909369  Use blivet during installation
>>                  918270  Refactor and isolate block device discovery
>>                  918957  [TUI] Confirmation for reboot
>>                  947406  Add notice field
>>                  947407  Status of caps-lock should be shown near password fields
>>                  953870  Migrate to livemedia-creator
>>                  966320  ovirt node will also enable ipv4 with dhcp protocol when only setting ipv6 with dhcp
>>                  966498  Change sensitivity of widgets recursively
>>                  969340  Migrate ovirt-node-installer backend and ovirt-auto-install backend to new code base
>>                  974609  Add correct suffixes to scripts
>>                  979067  [RFE] Add generic container handling
>>                  979078  [RFE] <RETURN> can be used to Save a page
>>                  979389  [RFE] use asciidoc for man pages
>>                  980064  [RFE] Add mouse support to the console
>>                  987824  [RFE] Need to add roll up and down ability to mouse control in multipage
>>                  988337  Shown incorrect info for the item "VLAN ID" after configured nic with "vlan".
>>                  988341  Should not create bond when report an error in configuration process
>>                  995994  Could not add Fedora host when its version becomes "oVirt Node Hypervisor"
>>                  997049  Allow nested transactions
>>                  1001947 KeyboardInterrupt Exception when click mouse on UI
>>                  1001950 RFE: same action on all ovirt-node-install page for press enter
>>                  1002176 Not enough debugging informations in log files
>>                  1002620 [RFE] Create central augeas object
>>                  1003234 password.py: Using "set_admin_password" to change admin password failed in single mode
>>                  1005148 [RFE] Add documentation on how to deploy Node with Puppet/Foreman
>>                  1007191 RFE:  Support "BOOTIF=bondname" in auto-install parameters
>>                  1008891 Installer goes to next page after returning from shell
>>                  1011901 Report traceback infos about errors when starting ntpdate, rpcidmapd and rpcgssd services ...
>>                  1013520 Miss some console info to show status by using "ovirt-node-upgrade" to upgrade ovirt-node
>>                  1020227 /var/log/lastlog is missing
>>                  1021647 Shared configuration keys to pass management informations
>>                  1026646 Better to disable "enter" button works for the fan status table of ipmi page
>>                  1027110 Better to disable cim transaction run and prompt ConfirmationDialog when configuring cim without providing password
>>                  1027130 edit-node: Better to rename iso_name more simpler when install multiple packages
>>                  1027161 plugin info shown incorrectly in plugins page when install multiple packages
>>                  1029033 Link status shows disconnected although the cable is plugged.
>>                  1032373 [RFE] enhance edit-node man page for uid/gid options help info a bit more
>>                  1032374 [RFE] edit-node:Support specify multiple user, uid/group, gid elements changed
>>                  1035441 [RFE] Sync versions between ovirt-node and overall ovirt
>>
>>
>> Please set the target to 3.4.0 and add the bug to the tracker if you think that 3.4.0 should not be released without it fixed.
>>
>> Please also update the target to 3.4.1 or any next release for bugs that won't be in 3.4.0: it will ease gathering the blocking bugs for next releases.
>>
>> For those who want to help testing the bugs, I suggest to add yourself as QA contact for the bug.
>>
>>
>> --
>> Sandro Bonazzola
>> Better technology. Faster innovation. Powered by community collaboration.
>> See how it works at redhat.com
>> _______________________________________________
>> Users mailing list
>> Users at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
>



From sbonazzo at redhat.com  Fri Jan 10 15:48:39 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Fri, 10 Jan 2014 16:48:39 +0100
Subject: oVirt 3.4.0 alpha repository closure failure
In-Reply-To: <52CFA5E4.8000601@redhat.com>
References: <52CFA5E4.8000601@redhat.com>
Message-ID: <52D01657.4020505@redhat.com>

Il 10/01/2014 08:48, Sandro Bonazzola ha scritto:
> Hi,
> oVirt 3.4.0 alpha repository has been composed but alpha has not been announced due to repository closure failures:
> 
> on CentOS 6.5:
> 
> # repoclosure -r ovirt-3.4.0-alpha -l ovirt-3.3.2 -l base -l epel -l glusterfs-epel -l updates -l extra -l glusterfs-noarch-epel -l ovirt-stable -n
> Reading in repository metadata - please wait....
> Checking Dependencies
> Repos looked at: 8
>    base
>    epel
>    glusterfs-epel
>    glusterfs-noarch-epel
>    ovirt-3.3.2
>    ovirt-3.4.0-alpha
>    ovirt-stable
>    updates
> Num Packages in Repos: 16581
> package: mom-0.3.2-20140101.git2691f25.el6.noarch from ovirt-3.4.0-alpha
>   unresolved deps:
>      procps-ng
> package: otopi-devel-1.2.0-0.0.master.20130910.git4387efb.el6.noarch from ovirt-3.4.0-alpha
>   unresolved deps:
>      otopi-java = 0:1.2.0-0.0.master.20130910.git4387efb.el6
> package: ovirt-engine-sdk-java-3.4.0.1-1.el6.noarch from ovirt-3.4.0-alpha
>   unresolved deps:
>      httpcomponents-client >= 0:4.2
>      apache-commons-logging
>      apache-commons-beanutils
> package: vdsm-hook-vhostmd-4.14.0-1.git6fdd55f.el6.noarch from ovirt-3.4.0-alpha
>   unresolved deps:
>      vhostmd
> 
> 
> On Fedora 19:
> # repoclosure -n -r ovirt-3.4.0-alpha -l fedora -l updates -l ovirt-stable
> Reading in repository metadata - please wait....
> Checking Dependencies
> Repos looked at: 4
>    fedora
>    ovirt-3.4.0-alpha
>    ovirt-stable
>    updates
> Num Packages in Repos: 38832
> package: otopi-devel-1.2.0-0.0.master.20130910.git4387efb.fc19.noarch from ovirt-3.4.0-alpha
>   unresolved deps:
>      otopi-java = 0:1.2.0-0.0.master.20130910.git4387efb.fc19

Should have been solved rebuilding otopi package.

> package: ovirt-engine-3.4.0-0.2.master.20140109103311.git6524789.fc19.noarch from ovirt-3.4.0-alpha
>   unresolved deps:
>      openstack-java-resteasy-connector >= 0:3.0.2
>      openstack-java-quantum-model >= 0:3.0.2
>      openstack-java-quantum-client >= 0:3.0.2
>      openstack-java-keystone-model >= 0:3.0.2
>      openstack-java-keystone-client >= 0:3.0.2
>      openstack-java-glance-model >= 0:3.0.2
>      openstack-java-glance-client >= 0:3.0.2
>      openstack-java-client >= 0:3.0.2


Will be solved by adding them to 3.4.0-alpha repository from http://koji.fedoraproject.org/koji/packageinfo?packageID=16232 , thanks Federico.



> package: ovirt-engine-reports-3.4.0-0.2.master.20140109102135.fc19.noarch from ovirt-3.4.0-alpha
>   unresolved deps:
>      ovirt-engine-dwh >= 0:3.4.0

David fixed nightly publisher job.


> 
> 
> On Fedora 20 (ovirt-stable doesn't support Fedora 20):
> 
> # repoclosure -n -r ovirt-3.4.0-alpha -l fedora -l updates
> Reading in repository metadata - please wait....
> Checking Dependencies
> Repos looked at: 3
>    fedora
>    ovirt-3.4.0-alpha
>    updates
> Num Packages in Repos: 38822
> package: otopi-devel-1.2.0-0.0.master.20130910.git4387efb.fc19.noarch from ovirt-3.4.0-alpha
>   unresolved deps:
>      otopi-java = 0:1.2.0-0.0.master.20130910.git4387efb.fc19
> package: ovirt-engine-3.4.0-0.2.master.20140109103311.git6524789.fc19.noarch from ovirt-3.4.0-alpha
>   unresolved deps:
>      openstack-java-resteasy-connector >= 0:3.0.2
>      openstack-java-quantum-model >= 0:3.0.2
>      openstack-java-quantum-client >= 0:3.0.2
>      openstack-java-keystone-model >= 0:3.0.2
>      openstack-java-keystone-client >= 0:3.0.2
>      openstack-java-glance-model >= 0:3.0.2
>      openstack-java-glance-client >= 0:3.0.2
>      openstack-java-client >= 0:3.0.2
> package: ovirt-engine-reports-3.4.0-0.2.master.20140109102135.fc19.noarch from ovirt-3.4.0-alpha
>   unresolved deps:
>      ovirt-engine-dwh >= 0:3.4.0
> 
> 
> Please fix dependencies / provide missing packages / provide additional repositories as soon as possible.
> Thanks,
> 


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


From emesika at redhat.com  Sat Jan 11 23:28:55 2014
From: emesika at redhat.com (Eli Mesika)
Date: Sat, 11 Jan 2014 18:28:55 -0500 (EST)
Subject: [Users] [QE] oVirt 3.3.3 beta status
In-Reply-To: <52CFE3CD.4020405@redhat.com>
References: <52CFE3CD.4020405@redhat.com>
Message-ID: <2026007139.181237.1389482935492.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>, Users at ovirt.org, "vdsm-devel" <vdsm-devel at fedorahosted.org>, "VDSM
> Project Development" <vdsm-devel at lists.fedorahosted.org>, "arch" <arch at ovirt.org>
> Sent: Friday, January 10, 2014 2:13:01 PM
> Subject: [Users] [QE] oVirt 3.3.3 beta status
> 
> we're going to branch and build oVirt 3.3.3 beta on Monday 2014-01-13.
> A bug tracker is available at [1] and it shows no bugs blocking the release
> the following has been proposed as blocker for 3.3.3 or 3.4.0, not targeted
> to a specific version yet:
> 
> Bug 1035314 - vdsm-hook-nestedvt uses kvm_intel-only syntax
> 
> The following is a list of the non-blocking bugs still open with target
> 3.3.3:
> 
> Whiteboard	Bug ID	Summary
> Whiteboard	Bug ID	Summary
> infra		987982	When adding a host through the REST API, the error message says
> that "rootPassword" is required...
> infra		1017267	Plaintext user passwords in async_tasks database

BZ is in MODIFIED 

> infra		1040022	vdsm-tool configurre errors when installing vdsm package
> integration	902979	ovirt-live - firefox doesn't trust the installed engine
> integration	1021805	[RFE] oVirt Live - use motd to show the admin password
> integration	1022440	[RFE] AIO - configure the AIO host to be a gluster
> cluster/host
> integration	1026930	Package virtio-win and put it in ovirt repositories
> integration	1026933	pre-populate ISO domain with virtio-win ISO
> network		906313	[oVirt-webadmin] [setupNetworks] "No valid Operation for
> <network_name> and Unassigned Logical Networks panel"
> network		987916	[oVirt] [provider] Dialog doesn't update unless focus lost
> network		997197	Some AppErrors messages are grammatically incorrect (singular
> vs plural)
> network		1023722	[oVirt-webadmin][network] Network roles in cluster
> management should be radio buttons
> sla		1049343	[oVirt] Disabled Balloon in Add Vm
> storage		987917	[oVirt] [glance] API version not specified in provider dialog
> ux		906394	[oVirt-webadmin] [network] Loading animation in network main tab
> 'hosts' and 'vms' subtab is stuck...
> virt		1007940	Cannot clone from snapshot while using GlusterFS as POSIX
> Storage Domain
> 		906257	USB Flash Drive install of ovirt-node created via dd fails
> 		923049	ovirt-node fails to boot from local disk under UEFI mode
> 		965583	[RFE] add shortcut key on TUI
> 		976675	[wiki] Update contribution page
> 		979350	Changes admin password in the first time when log in is failed while
> 		finished auto-install
> 		979390	[RFE] Split defaults.py into smaller pieces
> 		982232	performance page takes >1sec to load (on first load)
> 		984441	kdump page crashed before configuring the network after ovirt-node
> 		intalled
> 		986285	UI crashes when no bond name is given
> 		991267	[RFE] Add TUI information to log file.
> 		1018374	ovirt-node-iso-3.0.1-1.0.2.vdsm.fc19: Failed on Auto-install
> 		1018710	[RFE] Enhance API documentation
> 		1032035	[RFE]re-write auto install function for the cim plugin
> 		1033286	ovirt-node-plugin-vdsm can not be added to ovirt node el6 base
> 		image
> 
> Maintainers:
> Please add the bugs to the tracker if you think that 3.3.3 should not be
> released without them fixed.
> Please re-target all bugs you don't think that should block 3.3.3.
> 
> For those who want to help testing the bugs, I suggest to add yourself as QA
> contact for the bug and add yourself to the testing page [2].
> 
> Maintainers are welcomed to start filling release notes, the page has been
> created here [3]
> 
> 
> [1] http://bugzilla.redhat.com/1050084
> [2] http://www.ovirt.org/Testing/Ovirt_3.3.3_testing
> [3] http://www.ovirt.org/OVirt_3.3.3_release_notes
> 
> Thanks,
> 
> 
> --
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
> 


From danken at redhat.com  Sun Jan 12 23:32:48 2014
From: danken at redhat.com (Dan Kenigsberg)
Date: Sun, 12 Jan 2014 23:32:48 +0000
Subject: [Users] [QE] 3.4.0 Release tracker
In-Reply-To: <52D009D6.8010908@redhat.com>
References: <52CD105E.2040409@redhat.com>
	<CAHa6cRR3kscfByXDnUxovSn5z5J3dOMmtkzc9gJo_Y+3hXyZHA@mail.gmail.com>
	<52D009D6.8010908@redhat.com>
Message-ID: <20140112233247.GA29615@redhat.com>

On Fri, Jan 10, 2014 at 04:55:18PM +0200, Itamar Heim wrote:
> On 01/10/2014 01:52 PM, Sander Grendelman wrote:
> >Can I propose BZ#1035314 for 3.3.3 or 3.4.0, simple, trivial fix to a hook.
> 
> Hi Sander,
> 
> please use bug summary so folks won't have to go and look what the
> number means just to see if relevant to them.
> 
> this is about:
> Bug 1035314 - vdsm-hook-nestedvt uses kvm_intel-only syntax
> 
> i see you posted a patch in the bug - can you post the patch to
> gerrit as well?

I've done that alraedy: http://gerrit.ovirt.org/#/c/23164/

Sander (and others), could you review and formally verify it?


From sbonazzo at redhat.com  Mon Jan 13 09:27:35 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Mon, 13 Jan 2014 10:27:35 +0100
Subject: ovirt-engine 3.3.3 branching
Message-ID: <52D3B187.7010204@redhat.com>

Hi,
this is just a reminder we're going to build ovirt-engine 3.3.3 beta today.
We're going to branch ovirt-engine around 10am EST to allow you to get your patches in.
Thanks,

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


From sander at grendelman.com  Mon Jan 13 10:05:05 2014
From: sander at grendelman.com (Sander Grendelman)
Date: Mon, 13 Jan 2014 11:05:05 +0100
Subject: [Users] [QE] 3.4.0 Release tracker
In-Reply-To: <20140112233247.GA29615@redhat.com>
References: <52CD105E.2040409@redhat.com>
	<CAHa6cRR3kscfByXDnUxovSn5z5J3dOMmtkzc9gJo_Y+3hXyZHA@mail.gmail.com>
	<52D009D6.8010908@redhat.com> <20140112233247.GA29615@redhat.com>
Message-ID: <CAHa6cRT-YkpePE4sxOAp745zx3nLjciWn2dH5EPeUoe0voYBBg@mail.gmail.com>

On Mon, Jan 13, 2014 at 12:32 AM, Dan Kenigsberg <danken at redhat.com> wrote:
> On Fri, Jan 10, 2014 at 04:55:18PM +0200, Itamar Heim wrote:
>> On 01/10/2014 01:52 PM, Sander Grendelman wrote:
>> >Can I propose BZ#1035314 for 3.3.3 or 3.4.0, simple, trivial fix to a hook.
>>
>> Hi Sander,
>>
>> please use bug summary so folks won't have to go and look what the
>> number means just to see if relevant to them.
>>
>> this is about:
>> Bug 1035314 - vdsm-hook-nestedvt uses kvm_intel-only syntax

OK, I'll keep that in mind!

>> i see you posted a patch in the bug - can you post the patch to
>> gerrit as well?
>
> I've done that alraedy: http://gerrit.ovirt.org/#/c/23164/
>
> Sander (and others), could you review and formally verify it?

Looks fine to me, should I also do/confirm something in gerrit?


From michal.skrivanek at redhat.com  Mon Jan 13 12:20:55 2014
From: michal.skrivanek at redhat.com (Michal Skrivanek)
Date: Mon, 13 Jan 2014 13:20:55 +0100
Subject: [vdsm] [Users] [QE] 3.4.0 Release tracker
In-Reply-To: <CAHa6cRT-YkpePE4sxOAp745zx3nLjciWn2dH5EPeUoe0voYBBg@mail.gmail.com>
References: <52CD105E.2040409@redhat.com>
	<CAHa6cRR3kscfByXDnUxovSn5z5J3dOMmtkzc9gJo_Y+3hXyZHA@mail.gmail.com>
	<52D009D6.8010908@redhat.com> <20140112233247.GA29615@redhat.com>
	<CAHa6cRT-YkpePE4sxOAp745zx3nLjciWn2dH5EPeUoe0voYBBg@mail.gmail.com>
Message-ID: <351F379F-2543-4022-82EA-C6219511A5C2@redhat.com>


On Jan 13, 2014, at 11:05 , Sander Grendelman <sander at grendelman.com> wrote:

> On Mon, Jan 13, 2014 at 12:32 AM, Dan Kenigsberg <danken at redhat.com> wrote:
>> On Fri, Jan 10, 2014 at 04:55:18PM +0200, Itamar Heim wrote:
>>> On 01/10/2014 01:52 PM, Sander Grendelman wrote:
>>>> Can I propose BZ#1035314 for 3.3.3 or 3.4.0, simple, trivial fix to a hook.
>>> 
>>> Hi Sander,
>>> 
>>> please use bug summary so folks won't have to go and look what the
>>> number means just to see if relevant to them.
>>> 
>>> this is about:
>>> Bug 1035314 - vdsm-hook-nestedvt uses kvm_intel-only syntax
> 
> OK, I'll keep that in mind!
> 
>>> i see you posted a patch in the bug - can you post the patch to
>>> gerrit as well?
>> 
>> I've done that alraedy: http://gerrit.ovirt.org/#/c/23164/
>> 
>> Sander (and others), could you review and formally verify it?
> 
> Looks fine to me, should I also do/confirm something in gerrit?

if you gave it a try and it works I'll just put V+1 in gerrit for you?

> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel



From danken at redhat.com  Mon Jan 13 13:05:10 2014
From: danken at redhat.com (Dan Kenigsberg)
Date: Mon, 13 Jan 2014 13:05:10 +0000
Subject: [Users] [QE] 3.4.0 Release tracker
In-Reply-To: <CAHa6cRT-YkpePE4sxOAp745zx3nLjciWn2dH5EPeUoe0voYBBg@mail.gmail.com>
References: <52CD105E.2040409@redhat.com>
	<CAHa6cRR3kscfByXDnUxovSn5z5J3dOMmtkzc9gJo_Y+3hXyZHA@mail.gmail.com>
	<52D009D6.8010908@redhat.com> <20140112233247.GA29615@redhat.com>
	<CAHa6cRT-YkpePE4sxOAp745zx3nLjciWn2dH5EPeUoe0voYBBg@mail.gmail.com>
Message-ID: <20140113130510.GI1694@redhat.com>

On Mon, Jan 13, 2014 at 11:05:05AM +0100, Sander Grendelman wrote:
> On Mon, Jan 13, 2014 at 12:32 AM, Dan Kenigsberg <danken at redhat.com> wrote:
> > On Fri, Jan 10, 2014 at 04:55:18PM +0200, Itamar Heim wrote:
> >> On 01/10/2014 01:52 PM, Sander Grendelman wrote:
> >> >Can I propose BZ#1035314 for 3.3.3 or 3.4.0, simple, trivial fix to a hook.
> >>
> >> Hi Sander,
> >>
> >> please use bug summary so folks won't have to go and look what the
> >> number means just to see if relevant to them.
> >>
> >> this is about:
> >> Bug 1035314 - vdsm-hook-nestedvt uses kvm_intel-only syntax
> 
> OK, I'll keep that in mind!
> 
> >> i see you posted a patch in the bug - can you post the patch to
> >> gerrit as well?
> >
> > I've done that alraedy: http://gerrit.ovirt.org/#/c/23164/
> >
> > Sander (and others), could you review and formally verify it?
> 
> Looks fine to me, should I also do/confirm something in gerrit?

Yes, it would be great if you tick the patch as verified, as I did not
try it myself.


From sbonazzo at redhat.com  Mon Jan 13 13:33:45 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Mon, 13 Jan 2014 14:33:45 +0100
Subject: oVirt 3.4.0 alpha is now available
Message-ID: <52D3EB39.4000800@redhat.com>

The oVirt team is pleased to announce that the 3.4.0 Alpha is now
available in 3.4.0-alpha [1] repository for testing.

Feel free to join us testing it!
You'll find all needed info for installing it on the release notes page,
already available on the wiki [2].

A new oVirt Node build will be available soon as well.

[1] http://resources.ovirt.org/releases/3.4.0-alpha/
[2] http://www.ovirt.org/OVirt_3.4.0_release_notes


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


From danken at redhat.com  Mon Jan 13 18:49:19 2014
From: danken at redhat.com (Dan Kenigsberg)
Date: Mon, 13 Jan 2014 18:49:19 +0000
Subject: [vdsm] Smarter network_setup hooks
In-Reply-To: <CADSDy2j1aCnU0VuYLTrN6iDpF7dxLoK4Y6oMY+mb4bWz84tF2g@mail.gmail.com>
References: <20140103122050.GE21494@redhat.com>
	<20140103163440.GA4790@redhat.com>
	<CADSDy2hyaz+xrXaJzPthwpNf7ydwmk7fuyMaF_=oBDDSn+fTnA@mail.gmail.com>
	<20140106133207.GA31032@redhat.com>
	<466343892.4789225.1389190322792.JavaMail.root@redhat.com>
	<CADSDy2gmczTEsYuY0ap5o17-yz-hNWOWWSUDraD22josGqhzwg@mail.gmail.com>
	<20140109013540.GQ30055@redhat.com>
	<99982226.30258529.1389265460738.JavaMail.root@redhat.com>
	<CADSDy2j1aCnU0VuYLTrN6iDpF7dxLoK4Y6oMY+mb4bWz84tF2g@mail.gmail.com>
Message-ID: <20140113184919.GR1694@redhat.com>

On Thu, Jan 09, 2014 at 12:16:04PM +0100, Miguel Angel wrote:
> Dan, your arguments conviced me,
> changing my vote to "request" only.

Ok, so let's start with the "request" only. And let a hook script change
it to notify follow-up scripts (and/or Vdsm) that more/less changes are
required.

Do you think we can make it before ovirt-3.4 beta (Jan 20th) ?
(I hope we do!)

Dan.


From dneary at redhat.com  Mon Jan 13 19:02:50 2014
From: dneary at redhat.com (Dave Neary)
Date: Mon, 13 Jan 2014 20:02:50 +0100
Subject: Venue for oVirt meet-up, Saturday Feb 1st
Message-ID: <52D4385A.8000305@redhat.com>

Hi all,

I have a venue for our meet-up in Brussels!

We will meet from 19h30 in "Au Bon Vieux Temps", a very nice Belgian bar at:

Impasse Saint-Nicolas 4,
1000 Brussels,
Belgium

We will be there from about 19h30. Bear in mind, this is a bar, not a
restaurant - but there are lots of places nearby where you can partake
in pomme-frites and sausages, or step out for a quick meal and come back.

See you all there!

Cheers,
Dave.
-- 
Dave Neary - Community Action and Impact
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13


From amedeo at oscert.net  Mon Jan 13 19:10:23 2014
From: amedeo at oscert.net (Amedeo Salvati)
Date: Mon, 13 Jan 2014 20:10:23 +0100
Subject: rpms signed - why not?
Message-ID: <52D43A1F.60405@oscert.net>

I was setting up our spacewalk repo for ovirt due to auto provisioning 
engine and node based on centos distro, but I was surprised that you 
can't sign with gpg key your rpms, instead gluster rpms is signed with 
key id 89ccae8b available on her site

Why you don't sign your rpms?

e.g:
$ wget 
http://resources.ovirt.org/releases/3.3.2/rpm/EL/6/noarch/ovirt-engine-3.3.2-1.el6.noarch.rpm
$ rpm -K -v ovirt-engine-3.3.2-1.el6.noarch.rpm
ovirt-engine-3.3.2-1.el6.noarch.rpm:
     Digest SHA1 header: OK (f8cf0a7592ae3d8d298813cf61ec8b4e2ad6b6f6)
     MD5 digest: OK (bc4b66e0791b3ef5dd8e9b49828ad7d8)

instead gluster rpms:
$ wget 
http://download.gluster.org/pub/gluster/glusterfs/LATEST/EPEL.repo/epel-6/x86_64/glusterfs-3.4.2-1.el6.x86_64.rpm
$ rpm -K -v glusterfs-3.4.2-1.el6.x86_64.rpm
glusterfs-3.4.2-1.el6.x86_64.rpm:
     Header V4 RSA/SHA1 Signature, key ID 89ccae8b: NOKEY
     Header SHA1 digest: OK (e71040f320da087e6e9012102e0e59f134259d2a)
     V4 RSA/SHA1 Signature, key ID 89ccae8b: NOKEY
     MD5 digest: OK (01e72fe3ed97ba849327cafe43ca5d45)

best regards
a

-- 
Amedeo Salvati
RHC{DS,E,VA} - LPIC-3 - UCP - NCLA 11
email: amedeo at oscert.net
email: amedeo at linux.com
http://plugcomputing.it/redhatcert.php
http://plugcomputing.it/lpicert.php



From bproffit at redhat.com  Mon Jan 13 19:35:22 2014
From: bproffit at redhat.com (Brian Proffitt)
Date: Mon, 13 Jan 2014 14:35:22 -0500 (EST)
Subject: Suggestion for Handling Pre-Releases
In-Reply-To: <619731664.470972.1389641443792.JavaMail.root@redhat.com>
Message-ID: <917218950.472726.1389641722389.JavaMail.root@redhat.com>

Kiril, Dave and I were discussing how to update the community on pre-releases, while still keeping newer users on track to download and install the most stable release. What would be some suggestions on how to ensure new users are getting stable and veteran users are getting to development releases, if they want? We were pondering a separate link on the home page to something like this (http://www.ovirt.org/Download_devel_release), but other ideas are more than welcome.

Ideally, we want to make the onboarding process as (a) efficient and (b) easy as possible.

Looking forward to hearing from you,
BKP


-- 
Brian Proffitt - oVirt Community Manager
Open Source and Standards, Red Hat - http://community.redhat.com
Phone: +1 312 477 4320 / Cell: +1 574 383 9BKP
IRC: bkp


From lvernia at redhat.com  Mon Jan 13 19:51:17 2014
From: lvernia at redhat.com (Lior Vernia)
Date: Mon, 13 Jan 2014 21:51:17 +0200
Subject: Suggestion for Handling Pre-Releases
In-Reply-To: <917218950.472726.1389641722389.JavaMail.root@redhat.com>
References: <917218950.472726.1389641722389.JavaMail.root@redhat.com>
Message-ID: <52D443B5.4040103@redhat.com>

Hey Brian,

This might be far fetched, but what about having a small notification
panel in the top part of the webadmin GUI giving information about
upcoming releases?

This could be refreshed periodically or triggered by a "Check for
Updates" button.

It would be fairly easy to reach most oVirt users this way, and not
necessarily only supply the updates, but also information about release
dates as soon as they're known, while distinguishing between stable and
alpha/beta releases.

Yours, Lior.

On 13/01/14 21:35, Brian Proffitt wrote:
> Kiril, Dave and I were discussing how to update the community on pre-releases, while still keeping newer users on track to download and install the most stable release. What would be some suggestions on how to ensure new users are getting stable and veteran users are getting to development releases, if they want? We were pondering a separate link on the home page to something like this (http://www.ovirt.org/Download_devel_release), but other ideas are more than welcome.
> 
> Ideally, we want to make the onboarding process as (a) efficient and (b) easy as possible.
> 
> Looking forward to hearing from you,
> BKP
> 
> 


From bproffit at redhat.com  Mon Jan 13 20:38:33 2014
From: bproffit at redhat.com (Brian Proffitt)
Date: Mon, 13 Jan 2014 15:38:33 -0500 (EST)
Subject: Suggestion for Handling Pre-Releases
In-Reply-To: <52D443B5.4040103@redhat.com>
References: <917218950.472726.1389641722389.JavaMail.root@redhat.com>
	<52D443B5.4040103@redhat.com>
Message-ID: <2135278327.489358.1389645513661.JavaMail.root@redhat.com>

Just to get a little more detail... would this be in place of announcements on the wiki page/oVirt site, or alongside?

BKP

----- Original Message -----
From: "Lior Vernia" <lvernia at redhat.com>
To: "Brian Proffitt" <bproffit at redhat.com>
Cc: arch at ovirt.org
Sent: Monday, January 13, 2014 2:51:17 PM
Subject: Re: Suggestion for Handling Pre-Releases

Hey Brian,

This might be far fetched, but what about having a small notification
panel in the top part of the webadmin GUI giving information about
upcoming releases?

This could be refreshed periodically or triggered by a "Check for
Updates" button.

It would be fairly easy to reach most oVirt users this way, and not
necessarily only supply the updates, but also information about release
dates as soon as they're known, while distinguishing between stable and
alpha/beta releases.

Yours, Lior.

On 13/01/14 21:35, Brian Proffitt wrote:
> Kiril, Dave and I were discussing how to update the community on pre-releases, while still keeping newer users on track to download and install the most stable release. What would be some suggestions on how to ensure new users are getting stable and veteran users are getting to development releases, if they want? We were pondering a separate link on the home page to something like this (http://www.ovirt.org/Download_devel_release), but other ideas are more than welcome.
> 
> Ideally, we want to make the onboarding process as (a) efficient and (b) easy as possible.
> 
> Looking forward to hearing from you,
> BKP
> 
> 


From miguelangel at ajo.es  Mon Jan 13 21:48:07 2014
From: miguelangel at ajo.es (Miguel Angel)
Date: Mon, 13 Jan 2014 22:48:07 +0100
Subject: [vdsm] Smarter network_setup hooks
In-Reply-To: <20140113184919.GR1694@redhat.com>
References: <20140103122050.GE21494@redhat.com>
	<20140103163440.GA4790@redhat.com>
	<CADSDy2hyaz+xrXaJzPthwpNf7ydwmk7fuyMaF_=oBDDSn+fTnA@mail.gmail.com>
	<20140106133207.GA31032@redhat.com>
	<466343892.4789225.1389190322792.JavaMail.root@redhat.com>
	<CADSDy2gmczTEsYuY0ap5o17-yz-hNWOWWSUDraD22josGqhzwg@mail.gmail.com>
	<20140109013540.GQ30055@redhat.com>
	<99982226.30258529.1389265460738.JavaMail.root@redhat.com>
	<CADSDy2j1aCnU0VuYLTrN6iDpF7dxLoK4Y6oMY+mb4bWz84tF2g@mail.gmail.com>
	<20140113184919.GR1694@redhat.com>
Message-ID: <CADSDy2jmrn+4AnJvYJS1Lu=CpMi0vspiHuFtstYCkiJq=m1JqA@mail.gmail.com>

So, you mean current but removing the "current" part?

I could do that during Thursday morning, just let me know if I'm miss
anything.

Cheers!
Miguel ?ngel

---
irc: ajo / mangelajo
Miguel Angel Ajo Pelayo
+34 636 52 25 69
skype: ajoajoajo


2014/1/13 Dan Kenigsberg <danken at redhat.com>

> On Thu, Jan 09, 2014 at 12:16:04PM +0100, Miguel Angel wrote:
> > Dan, your arguments conviced me,
> > changing my vote to "request" only.
>
> Ok, so let's start with the "request" only. And let a hook script change
> it to notify follow-up scripts (and/or Vdsm) that more/less changes are
> required.
>
> Do you think we can make it before ovirt-3.4 beta (Jan 20th) ?
> (I hope we do!)
>
> Dan.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20140113/ebc1ee9d/attachment.html>

From danken at redhat.com  Mon Jan 13 21:57:03 2014
From: danken at redhat.com (Dan Kenigsberg)
Date: Mon, 13 Jan 2014 21:57:03 +0000
Subject: [Users] rpms signed - why not?
In-Reply-To: <52D43A1F.60405@oscert.net>
References: <52D43A1F.60405@oscert.net>
Message-ID: <20140113215703.GU1694@redhat.com>

On Mon, Jan 13, 2014 at 08:10:23PM +0100, Amedeo Salvati wrote:
> I was setting up our spacewalk repo for ovirt due to auto
> provisioning engine and node based on centos distro, but I was
> surprised that you can't sign with gpg key your rpms, instead
> gluster rpms is signed with key id 89ccae8b available on her site
> 
> Why you don't sign your rpms?
> 
> e.g:
> $ wget http://resources.ovirt.org/releases/3.3.2/rpm/EL/6/noarch/ovirt-engine-3.3.2-1.el6.noarch.rpm
> $ rpm -K -v ovirt-engine-3.3.2-1.el6.noarch.rpm
> ovirt-engine-3.3.2-1.el6.noarch.rpm:
>     Digest SHA1 header: OK (f8cf0a7592ae3d8d298813cf61ec8b4e2ad6b6f6)
>     MD5 digest: OK (bc4b66e0791b3ef5dd8e9b49828ad7d8)
> 
> instead gluster rpms:
> $ wget http://download.gluster.org/pub/gluster/glusterfs/LATEST/EPEL.repo/epel-6/x86_64/glusterfs-3.4.2-1.el6.x86_64.rpm
> $ rpm -K -v glusterfs-3.4.2-1.el6.x86_64.rpm
> glusterfs-3.4.2-1.el6.x86_64.rpm:
>     Header V4 RSA/SHA1 Signature, key ID 89ccae8b: NOKEY
>     Header SHA1 digest: OK (e71040f320da087e6e9012102e0e59f134259d2a)
>     V4 RSA/SHA1 Signature, key ID 89ccae8b: NOKEY
>     MD5 digest: OK (01e72fe3ed97ba849327cafe43ca5d45)
> 

+1

https://fedorahosted.org/ovirt/ticket/99 "improvements for our release
process"


From lvernia at redhat.com  Mon Jan 13 22:42:24 2014
From: lvernia at redhat.com (Lior Vernia)
Date: Tue, 14 Jan 2014 00:42:24 +0200
Subject: Suggestion for Handling Pre-Releases
In-Reply-To: <2135278327.489358.1389645513661.JavaMail.root@redhat.com>
References: <917218950.472726.1389641722389.JavaMail.root@redhat.com>
	<52D443B5.4040103@redhat.com>
	<2135278327.489358.1389645513661.JavaMail.root@redhat.com>
Message-ID: <52D46BD0.4010201@redhat.com>

Well, as we wish. Probably alongside, because releases have to be noted
in the official website (of any product in the world, not oVirt
specifically). I'm just suggesting a general way in which existing users
could get information about releases in a "push" manner rather than by
polling the website (I'm assuming many users are not subscribed to
mailing lists); specifically it could also easily be used to distinguish
between pre-release and stable versions (color coding, and/or when
announcing a pre-release also announce the following stable release,
and/or...).

On 13/01/14 22:38, Brian Proffitt wrote:
> Just to get a little more detail... would this be in place of announcements on the wiki page/oVirt site, or alongside?
> 
> BKP
> 
> ----- Original Message -----
> From: "Lior Vernia" <lvernia at redhat.com>
> To: "Brian Proffitt" <bproffit at redhat.com>
> Cc: arch at ovirt.org
> Sent: Monday, January 13, 2014 2:51:17 PM
> Subject: Re: Suggestion for Handling Pre-Releases
> 
> Hey Brian,
> 
> This might be far fetched, but what about having a small notification
> panel in the top part of the webadmin GUI giving information about
> upcoming releases?
> 
> This could be refreshed periodically or triggered by a "Check for
> Updates" button.
> 
> It would be fairly easy to reach most oVirt users this way, and not
> necessarily only supply the updates, but also information about release
> dates as soon as they're known, while distinguishing between stable and
> alpha/beta releases.
> 
> Yours, Lior.
> 
> On 13/01/14 21:35, Brian Proffitt wrote:
>> Kiril, Dave and I were discussing how to update the community on pre-releases, while still keeping newer users on track to download and install the most stable release. What would be some suggestions on how to ensure new users are getting stable and veteran users are getting to development releases, if they want? We were pondering a separate link on the home page to something like this (http://www.ovirt.org/Download_devel_release), but other ideas are more than welcome.
>>
>> Ideally, we want to make the onboarding process as (a) efficient and (b) easy as possible.
>>
>> Looking forward to hearing from you,
>> BKP
>>
>>


From emesika at redhat.com  Mon Jan 13 22:56:32 2014
From: emesika at redhat.com (Eli Mesika)
Date: Mon, 13 Jan 2014 17:56:32 -0500 (EST)
Subject: Suggestion for Handling Pre-Releases
In-Reply-To: <52D46BD0.4010201@redhat.com>
References: <917218950.472726.1389641722389.JavaMail.root@redhat.com>
	<52D443B5.4040103@redhat.com>
	<2135278327.489358.1389645513661.JavaMail.root@redhat.com>
	<52D46BD0.4010201@redhat.com>
Message-ID: <1993112011.829389.1389653792300.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Lior Vernia" <lvernia at redhat.com>
> To: "Brian Proffitt" <bproffit at redhat.com>
> Cc: arch at ovirt.org
> Sent: Tuesday, January 14, 2014 12:42:24 AM
> Subject: Re: Suggestion for Handling Pre-Releases
> 
> Well, as we wish. Probably alongside, because releases have to be noted
> in the official website (of any product in the world, not oVirt
> specifically). I'm just suggesting a general way in which existing users
> could get information about releases in a "push" manner rather than by
> polling the website (I'm assuming many users are not subscribed to
> mailing lists); specifically it could also easily be used to distinguish
> between pre-release and stable versions (color coding, and/or when
> announcing a pre-release also announce the following stable release,
> and/or...).

I think alongside for sure , information should be available for both oVirt users or new potential ones.
One point we should aware of if we will make this info available on the UI is how to enforce synchronization such that we will not display "old" information 

> 
> On 13/01/14 22:38, Brian Proffitt wrote:
> > Just to get a little more detail... would this be in place of announcements
> > on the wiki page/oVirt site, or alongside?
> > 
> > BKP
> > 
> > ----- Original Message -----
> > From: "Lior Vernia" <lvernia at redhat.com>
> > To: "Brian Proffitt" <bproffit at redhat.com>
> > Cc: arch at ovirt.org
> > Sent: Monday, January 13, 2014 2:51:17 PM
> > Subject: Re: Suggestion for Handling Pre-Releases
> > 
> > Hey Brian,
> > 
> > This might be far fetched, but what about having a small notification
> > panel in the top part of the webadmin GUI giving information about
> > upcoming releases?
> > 
> > This could be refreshed periodically or triggered by a "Check for
> > Updates" button.
> > 
> > It would be fairly easy to reach most oVirt users this way, and not
> > necessarily only supply the updates, but also information about release
> > dates as soon as they're known, while distinguishing between stable and
> > alpha/beta releases.
> > 
> > Yours, Lior.
> > 
> > On 13/01/14 21:35, Brian Proffitt wrote:
> >> Kiril, Dave and I were discussing how to update the community on
> >> pre-releases, while still keeping newer users on track to download and
> >> install the most stable release. What would be some suggestions on how to
> >> ensure new users are getting stable and veteran users are getting to
> >> development releases, if they want? We were pondering a separate link on
> >> the home page to something like this
> >> (http://www.ovirt.org/Download_devel_release), but other ideas are more
> >> than welcome.
> >>
> >> Ideally, we want to make the onboarding process as (a) efficient and (b)
> >> easy as possible.
> >>
> >> Looking forward to hearing from you,
> >> BKP
> >>
> >>
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From yzaslavs at redhat.com  Tue Jan 14 01:16:52 2014
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Mon, 13 Jan 2014 20:16:52 -0500 (EST)
Subject: Suggestion for Handling Pre-Releases
In-Reply-To: <1993112011.829389.1389653792300.JavaMail.root@redhat.com>
References: <917218950.472726.1389641722389.JavaMail.root@redhat.com>
	<52D443B5.4040103@redhat.com>
	<2135278327.489358.1389645513661.JavaMail.root@redhat.com>
	<52D46BD0.4010201@redhat.com>
	<1993112011.829389.1389653792300.JavaMail.root@redhat.com>
Message-ID: <1991984759.1510546.1389662212984.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Eli Mesika" <emesika at redhat.com>
> To: "Brian Proffitt" <bproffit at redhat.com>
> Cc: arch at ovirt.org
> Sent: Tuesday, January 14, 2014 12:56:32 AM
> Subject: Re: Suggestion for Handling Pre-Releases
> 
> 
> 
> ----- Original Message -----
> > From: "Lior Vernia" <lvernia at redhat.com>
> > To: "Brian Proffitt" <bproffit at redhat.com>
> > Cc: arch at ovirt.org
> > Sent: Tuesday, January 14, 2014 12:42:24 AM
> > Subject: Re: Suggestion for Handling Pre-Releases
> > 
> > Well, as we wish. Probably alongside, because releases have to be noted
> > in the official website (of any product in the world, not oVirt
> > specifically). I'm just suggesting a general way in which existing users
> > could get information about releases in a "push" manner rather than by
> > polling the website (I'm assuming many users are not subscribed to
> > mailing lists); specifically it could also easily be used to distinguish
> > between pre-release and stable versions (color coding, and/or when
> > announcing a pre-release also announce the following stable release,
> > and/or...).
> 
> I think alongside for sure , information should be available for both oVirt
> users or new potential ones.
> One point we should aware of if we will make this info available on the UI is
> how to enforce synchronization such that we will not display "old"
> information

Perhaps a new BLL query that will fetch this info from oVirt wiki?

> 
> > 
> > On 13/01/14 22:38, Brian Proffitt wrote:
> > > Just to get a little more detail... would this be in place of
> > > announcements
> > > on the wiki page/oVirt site, or alongside?
> > > 
> > > BKP
> > > 
> > > ----- Original Message -----
> > > From: "Lior Vernia" <lvernia at redhat.com>
> > > To: "Brian Proffitt" <bproffit at redhat.com>
> > > Cc: arch at ovirt.org
> > > Sent: Monday, January 13, 2014 2:51:17 PM
> > > Subject: Re: Suggestion for Handling Pre-Releases
> > > 
> > > Hey Brian,
> > > 
> > > This might be far fetched, but what about having a small notification
> > > panel in the top part of the webadmin GUI giving information about
> > > upcoming releases?
> > > 
> > > This could be refreshed periodically or triggered by a "Check for
> > > Updates" button.
> > > 
> > > It would be fairly easy to reach most oVirt users this way, and not
> > > necessarily only supply the updates, but also information about release
> > > dates as soon as they're known, while distinguishing between stable and
> > > alpha/beta releases.
> > > 
> > > Yours, Lior.
> > > 
> > > On 13/01/14 21:35, Brian Proffitt wrote:
> > >> Kiril, Dave and I were discussing how to update the community on
> > >> pre-releases, while still keeping newer users on track to download and
> > >> install the most stable release. What would be some suggestions on how
> > >> to
> > >> ensure new users are getting stable and veteran users are getting to
> > >> development releases, if they want? We were pondering a separate link on
> > >> the home page to something like this
> > >> (http://www.ovirt.org/Download_devel_release), but other ideas are more
> > >> than welcome.
> > >>
> > >> Ideally, we want to make the onboarding process as (a) efficient and (b)
> > >> easy as possible.
> > >>
> > >> Looking forward to hearing from you,
> > >> BKP
> > >>
> > >>
> > _______________________________________________
> > Arch mailing list
> > Arch at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/arch
> > 
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From danken at redhat.com  Tue Jan 14 08:42:32 2014
From: danken at redhat.com (Dan Kenigsberg)
Date: Tue, 14 Jan 2014 08:42:32 +0000
Subject: [vdsm] Smarter network_setup hooks
In-Reply-To: <CADSDy2jmrn+4AnJvYJS1Lu=CpMi0vspiHuFtstYCkiJq=m1JqA@mail.gmail.com>
References: <20140103163440.GA4790@redhat.com>
	<CADSDy2hyaz+xrXaJzPthwpNf7ydwmk7fuyMaF_=oBDDSn+fTnA@mail.gmail.com>
	<20140106133207.GA31032@redhat.com>
	<466343892.4789225.1389190322792.JavaMail.root@redhat.com>
	<CADSDy2gmczTEsYuY0ap5o17-yz-hNWOWWSUDraD22josGqhzwg@mail.gmail.com>
	<20140109013540.GQ30055@redhat.com>
	<99982226.30258529.1389265460738.JavaMail.root@redhat.com>
	<CADSDy2j1aCnU0VuYLTrN6iDpF7dxLoK4Y6oMY+mb4bWz84tF2g@mail.gmail.com>
	<20140113184919.GR1694@redhat.com>
	<CADSDy2jmrn+4AnJvYJS1Lu=CpMi0vspiHuFtstYCkiJq=m1JqA@mail.gmail.com>
Message-ID: <20140114084232.GA12758@redhat.com>

On Mon, Jan 13, 2014 at 10:48:07PM +0100, Miguel Angel wrote:
> So, you mean current but removing the "current" part?

Frankly yes. Adam's "getContext" helper can wait for a followup patch.
I have a couple of minor comments on gerrit.

> 
> I could do that during Thursday morning, just let me know if I'm miss
> anything.

Thanks!


From lpeer at redhat.com  Tue Jan 14 09:15:44 2014
From: lpeer at redhat.com (Livnat Peer)
Date: Tue, 14 Jan 2014 11:15:44 +0200
Subject: Suggestion for Handling Pre-Releases
In-Reply-To: <917218950.472726.1389641722389.JavaMail.root@redhat.com>
References: <917218950.472726.1389641722389.JavaMail.root@redhat.com>
Message-ID: <52D50040.2000504@redhat.com>

On 01/13/2014 09:35 PM, Brian Proffitt wrote:
> Kiril, Dave and I were discussing how to update the community on pre-releases, while still keeping newer users on track to download and install the most stable release. What would be some suggestions on how to ensure new users are getting stable and veteran users are getting to development releases, if they want? We were pondering a separate link on the home page to something like this (http://www.ovirt.org/Download_devel_release), but other ideas are more than welcome.
> 
> Ideally, we want to make the onboarding process as (a) efficient and (b) easy as possible.
> 

Brian,

Just making sure I got the question right, we are looking on a way to
make the alpha/beta build more available for users?

If that is the question, how about the jboss( Wildfly :) ) approach
http://wildfly.org/downloads/


Livnat

> Looking forward to hearing from you,
> BKP
> 
> 



From iheim at redhat.com  Tue Jan 14 15:26:16 2014
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 14 Jan 2014 17:26:16 +0200
Subject: Suggestion for Handling Pre-Releases
In-Reply-To: <52D50040.2000504@redhat.com>
References: <917218950.472726.1389641722389.JavaMail.root@redhat.com>
	<52D50040.2000504@redhat.com>
Message-ID: <52D55718.8050400@redhat.com>

On 01/14/2014 11:15 AM, Livnat Peer wrote:
> On 01/13/2014 09:35 PM, Brian Proffitt wrote:
>> Kiril, Dave and I were discussing how to update the community on pre-releases, while still keeping newer users on track to download and install the most stable release. What would be some suggestions on how to ensure new users are getting stable and veteran users are getting to development releases, if they want? We were pondering a separate link on the home page to something like this (http://www.ovirt.org/Download_devel_release), but other ideas are more than welcome.
>>
>> Ideally, we want to make the onboarding process as (a) efficient and (b) easy as possible.
>>
>
> Brian,
>
> Just making sure I got the question right, we are looking on a way to
> make the alpha/beta build more available for users?
>
> If that is the question, how about the jboss( Wildfly :) ) approach
> http://wildfly.org/downloads/
>
>
> Livnat
>
>> Looking forward to hearing from you,
>> BKP
>>
>>
>
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
>

I think Lior was talking about making this visible via the webadmin.
I think the right way of doing this is not related to the web site, 
rather to the ovirt engine showing if there are newer (relevant) 
packages in the engine-check-update queue.


From dneary at redhat.com  Tue Jan 14 17:16:04 2014
From: dneary at redhat.com (Dave Neary)
Date: Tue, 14 Jan 2014 18:16:04 +0100
Subject: Feature template
Message-ID: <52D570D4.8090501@redhat.com>

Hi everyone,

To resolve a long-standing issue with feature pages in the wiki, I have
created a wiki template for features. I would appreciate it if you could
add it to the top of every feature page you're responsible for.

The feature is really simple:

http://www.ovirt.org/Template:Feature

You use it as so:

{{Feature|name=Network QoS|modules=network|version=3.3|status=Released}}

You can see an example of its usage in "All in One":
http://www.ovirt.org/Feature/AllInOne

If you keep status to one of "Released" (meaning: in a release), "In
testing" (complete in Git, not yet released), "In progress" (coding
happening, perhaps on a branch), "Not started", we should be able to
colour code feature panels to indicate the status of the feature in the box.

Thanks!
Dave.

-- 
Dave Neary - Community Action and Impact
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13


From lpeer at redhat.com  Tue Jan 14 17:51:40 2014
From: lpeer at redhat.com (Livnat Peer)
Date: Tue, 14 Jan 2014 19:51:40 +0200
Subject: Suggestion for Handling Pre-Releases
In-Reply-To: <52D55718.8050400@redhat.com>
References: <917218950.472726.1389641722389.JavaMail.root@redhat.com>
	<52D50040.2000504@redhat.com> <52D55718.8050400@redhat.com>
Message-ID: <52D5792C.8080807@redhat.com>

On 01/14/2014 05:26 PM, Itamar Heim wrote:
> On 01/14/2014 11:15 AM, Livnat Peer wrote:
>> On 01/13/2014 09:35 PM, Brian Proffitt wrote:
>>> Kiril, Dave and I were discussing how to update the community on
>>> pre-releases, while still keeping newer users on track to download
>>> and install the most stable release. What would be some suggestions
>>> on how to ensure new users are getting stable and veteran users are
>>> getting to development releases, if they want? We were pondering a
>>> separate link on the home page to something like this
>>> (http://www.ovirt.org/Download_devel_release), but other ideas are
>>> more than welcome.
>>>
>>> Ideally, we want to make the onboarding process as (a) efficient and
>>> (b) easy as possible.
>>>
>>
>> Brian,
>>
>> Just making sure I got the question right, we are looking on a way to
>> make the alpha/beta build more available for users?
>>
>> If that is the question, how about the jboss( Wildfly :) ) approach
>> http://wildfly.org/downloads/
>>
>>
>> Livnat
>>
>>> Looking forward to hearing from you,
>>> BKP
>>>
>>>
>>
>> _______________________________________________
>> Arch mailing list
>> Arch at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/arch
>>
> 
> I think Lior was talking about making this visible via the webadmin.

That was my understanding as well.

> I think the right way of doing this is not related to the web site,
> rather to the ovirt engine showing if there are newer (relevant)
> packages in the engine-check-update queue.

I don't think the two are exclusive or, I think we should have both.
I rather d/l bits from a website over clicking on d/l buttons in the app.



From herrold at owlriver.com  Tue Jan 14 18:53:03 2014
From: herrold at owlriver.com (R P Herrold)
Date: Tue, 14 Jan 2014 13:53:03 -0500 (EST)
Subject: [wiki curation] Feature template
In-Reply-To: <52D570D4.8090501@redhat.com>
References: <52D570D4.8090501@redhat.com>
Message-ID: <alpine.LRH.2.03.1401141344380.24648@bjyevire.pbz>

On Tue, 14 Jan 2014, Dave Neary wrote:

> {{Feature|name=Network QoS|modules=network|version=3.3|status=Released}}

Three additional suggestions:

Isn't there a need for way to see:
	Appeared at
	Stable by
	Retired after

Features come and go, and the end user community may not be 
able to 'live at HEAD'

As I read setup articles in the wiki, there seems to be such a 
life-cycle


2. Also, exposing:
	Last editted on:
	Last editor:

would be a goodness -- I regularly receive direct email from 
folks not willing for wnatever reason to wade into a high 
volume mailing list, but seeking help, and having the ability 
to ** find ** someone, anyone authoring in a subject matter 
area is part of the FOSS ethic


3. And having a formal machanism to formally catch
	Potentially stale: 

content, so that pages might be marked in one pass and 'on the 
fly', then later searched, and finally curated back to not 
'Potentially stale'

were markings I used when maintaininthg CentOS wiki presence, 
to combat entropy



From sbonazzo at redhat.com  Tue Jan 14 19:21:47 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Tue, 14 Jan 2014 20:21:47 +0100
Subject: oVirt 3.3.3 beta is now available
Message-ID: <52D58E4B.50509@redhat.com>

The oVirt team is pleased to announce that the 3.3.3 Beta is now
available in beta [1] repository for testing.

Feel free to join us testing it!
You'll find all needed info for installing it on the release notes page,
already available on the wiki [2].

A new oVirt Node build will be available soon as well.

[1] http://resources.ovirt.org/releases/beta/
[2] http://www.ovirt.org/OVirt_3.3.3_release_notes


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


From iheim at redhat.com  Tue Jan 14 20:31:46 2014
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 14 Jan 2014 22:31:46 +0200
Subject: Suggestion for Handling Pre-Releases
In-Reply-To: <52D5792C.8080807@redhat.com>
References: <917218950.472726.1389641722389.JavaMail.root@redhat.com>
	<52D50040.2000504@redhat.com> <52D55718.8050400@redhat.com>
	<52D5792C.8080807@redhat.com>
Message-ID: <52D59EB2.4040105@redhat.com>

On 01/14/2014 07:51 PM, Livnat Peer wrote:
> On 01/14/2014 05:26 PM, Itamar Heim wrote:
>> On 01/14/2014 11:15 AM, Livnat Peer wrote:
>>> On 01/13/2014 09:35 PM, Brian Proffitt wrote:
>>>> Kiril, Dave and I were discussing how to update the community on
>>>> pre-releases, while still keeping newer users on track to download
>>>> and install the most stable release. What would be some suggestions
>>>> on how to ensure new users are getting stable and veteran users are
>>>> getting to development releases, if they want? We were pondering a
>>>> separate link on the home page to something like this
>>>> (http://www.ovirt.org/Download_devel_release), but other ideas are
>>>> more than welcome.
>>>>
>>>> Ideally, we want to make the onboarding process as (a) efficient and
>>>> (b) easy as possible.
>>>>
>>>
>>> Brian,
>>>
>>> Just making sure I got the question right, we are looking on a way to
>>> make the alpha/beta build more available for users?
>>>
>>> If that is the question, how about the jboss( Wildfly :) ) approach
>>> http://wildfly.org/downloads/
>>>
>>>
>>> Livnat
>>>
>>>> Looking forward to hearing from you,
>>>> BKP
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Arch mailing list
>>> Arch at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/arch
>>>
>>
>> I think Lior was talking about making this visible via the webadmin.
>
> That was my understanding as well.
>
>> I think the right way of doing this is not related to the web site,
>> rather to the ovirt engine showing if there are newer (relevant)
>> packages in the engine-check-update queue.
>
> I don't think the two are exclusive or, I think we should have both.
> I rather d/l bits from a website over clicking on d/l buttons in the app.
>

d/l bits from the website doesn't work for rpm based deployments for 
updates.
the website download link should point to latest stable release, maybe 
also to latest unstable (next version alpha/beta/etc.).

the webadmin should show an existing admin that there is a newer version 
available, without the admin visiting the website.


From jbrooks at redhat.com  Tue Jan 14 21:57:13 2014
From: jbrooks at redhat.com (Jason Brooks)
Date: Tue, 14 Jan 2014 16:57:13 -0500 (EST)
Subject: Feature template
In-Reply-To: <52D570D4.8090501@redhat.com>
References: <52D570D4.8090501@redhat.com>
Message-ID: <2044582828.1862520.1389736633454.JavaMail.root@redhat.com>

It'd be good to include "how to test"

----- Original Message -----
> From: "Dave Neary" <dneary at redhat.com>
> To: "arch" <arch at ovirt.org>
> Sent: Tuesday, January 14, 2014 9:16:04 AM
> Subject: Feature template
> 
> Hi everyone,
> 
> To resolve a long-standing issue with feature pages in the wiki, I have
> created a wiki template for features. I would appreciate it if you could
> add it to the top of every feature page you're responsible for.
> 
> The feature is really simple:
> 
> http://www.ovirt.org/Template:Feature
> 
> You use it as so:
> 
> {{Feature|name=Network QoS|modules=network|version=3.3|status=Released}}
> 
> You can see an example of its usage in "All in One":
> http://www.ovirt.org/Feature/AllInOne
> 
> If you keep status to one of "Released" (meaning: in a release), "In
> testing" (complete in Git, not yet released), "In progress" (coding
> happening, perhaps on a branch), "Not started", we should be able to
> colour code feature panels to indicate the status of the feature in the box.
> 
> Thanks!
> Dave.
> 
> --
> Dave Neary - Community Action and Impact
> Open Source and Standards, Red Hat - http://community.redhat.com
> Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From dneary at redhat.com  Wed Jan 15 07:32:27 2014
From: dneary at redhat.com (Dave Neary)
Date: Wed, 15 Jan 2014 08:32:27 +0100
Subject: Feature template
In-Reply-To: <2044582828.1862520.1389736633454.JavaMail.root@redhat.com>
References: <52D570D4.8090501@redhat.com>
	<2044582828.1862520.1389736633454.JavaMail.root@redhat.com>
Message-ID: <52D6398B.7050402@redhat.com>

Hi,

That belongs in the Feature page, not in the little side-bar which
informs you of its status.

It should definitely be there, though.

Cheers,
Dave.

On 01/14/2014 10:57 PM, Jason Brooks wrote:
> It'd be good to include "how to test"
> 
> ----- Original Message -----
>> From: "Dave Neary" <dneary at redhat.com>
>> To: "arch" <arch at ovirt.org>
>> Sent: Tuesday, January 14, 2014 9:16:04 AM
>> Subject: Feature template
>>
>> Hi everyone,
>>
>> To resolve a long-standing issue with feature pages in the wiki, I have
>> created a wiki template for features. I would appreciate it if you could
>> add it to the top of every feature page you're responsible for.
>>
>> The feature is really simple:
>>
>> http://www.ovirt.org/Template:Feature
>>
>> You use it as so:
>>
>> {{Feature|name=Network QoS|modules=network|version=3.3|status=Released}}
>>
>> You can see an example of its usage in "All in One":
>> http://www.ovirt.org/Feature/AllInOne
>>
>> If you keep status to one of "Released" (meaning: in a release), "In
>> testing" (complete in Git, not yet released), "In progress" (coding
>> happening, perhaps on a branch), "Not started", we should be able to
>> colour code feature panels to indicate the status of the feature in the box.
>>
>> Thanks!
>> Dave.
>>
>> --
>> Dave Neary - Community Action and Impact
>> Open Source and Standards, Red Hat - http://community.redhat.com
>> Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13
>> _______________________________________________
>> Arch mailing list
>> Arch at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/arch
>>

-- 
Dave Neary - Community Action and Impact
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13


From lpeer at redhat.com  Wed Jan 15 08:38:06 2014
From: lpeer at redhat.com (Livnat Peer)
Date: Wed, 15 Jan 2014 10:38:06 +0200
Subject: Suggestion for Handling Pre-Releases
In-Reply-To: <52D59EB2.4040105@redhat.com>
References: <917218950.472726.1389641722389.JavaMail.root@redhat.com>
	<52D50040.2000504@redhat.com> <52D55718.8050400@redhat.com>
	<52D5792C.8080807@redhat.com> <52D59EB2.4040105@redhat.com>
Message-ID: <52D648EE.3070404@redhat.com>

On 01/14/2014 10:31 PM, Itamar Heim wrote:
> On 01/14/2014 07:51 PM, Livnat Peer wrote:
>> On 01/14/2014 05:26 PM, Itamar Heim wrote:
>>> On 01/14/2014 11:15 AM, Livnat Peer wrote:
>>>> On 01/13/2014 09:35 PM, Brian Proffitt wrote:
>>>>> Kiril, Dave and I were discussing how to update the community on
>>>>> pre-releases, while still keeping newer users on track to download
>>>>> and install the most stable release. What would be some suggestions
>>>>> on how to ensure new users are getting stable and veteran users are
>>>>> getting to development releases, if they want? We were pondering a
>>>>> separate link on the home page to something like this
>>>>> (http://www.ovirt.org/Download_devel_release), but other ideas are
>>>>> more than welcome.
>>>>>
>>>>> Ideally, we want to make the onboarding process as (a) efficient and
>>>>> (b) easy as possible.
>>>>>
>>>>
>>>> Brian,
>>>>
>>>> Just making sure I got the question right, we are looking on a way to
>>>> make the alpha/beta build more available for users?
>>>>
>>>> If that is the question, how about the jboss( Wildfly :) ) approach
>>>> http://wildfly.org/downloads/
>>>>
>>>>
>>>> Livnat
>>>>
>>>>> Looking forward to hearing from you,
>>>>> BKP
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Arch mailing list
>>>> Arch at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/arch
>>>>
>>>
>>> I think Lior was talking about making this visible via the webadmin.
>>
>> That was my understanding as well.
>>
>>> I think the right way of doing this is not related to the web site,
>>> rather to the ovirt engine showing if there are newer (relevant)
>>> packages in the engine-check-update queue.
>>
>> I don't think the two are exclusive or, I think we should have both.
>> I rather d/l bits from a website over clicking on d/l buttons in the app.
>>
> 
> d/l bits from the website doesn't work for rpm based deployments for
> updates.
> the website download link should point to latest stable release, maybe
> also to latest unstable (next version alpha/beta/etc.).
> 
> the webadmin should show an existing admin that there is a newer version
> available, without the admin visiting the website.

The webadmin should indicate that there are new bits, for getting them
you need to go to the website and d/l them.

The original question was how do we add exposure to the pre-releases
which are not available today for users, and the webadmin can not be the
only way to get alpha/beta release.





From mkolesni at redhat.com  Wed Jan 15 09:35:29 2014
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Wed, 15 Jan 2014 04:35:29 -0500 (EST)
Subject: Suggestion for Handling Pre-Releases
In-Reply-To: <917218950.472726.1389641722389.JavaMail.root@redhat.com>
References: <917218950.472726.1389641722389.JavaMail.root@redhat.com>
Message-ID: <770314005.1580170.1389778529898.JavaMail.root@redhat.com>


----- Original Message -----
> Kiril, Dave and I were discussing how to update the community on
> pre-releases, while still keeping newer users on track to download and
> install the most stable release. What would be some suggestions on how to
> ensure new users are getting stable and veteran users are getting to
> development releases, if they want? We were pondering a separate link on the
> home page to something like this
> (http://www.ovirt.org/Download_devel_release), but other ideas are more than
> welcome.

I found the way Fedora do it very nice (on: http://fedoraproject.org/get-fedora)
Basically they always point you to the latest stable release,
but when an newer version is available in Alpha/Beta they have a frame there that points you in that direction.

i.e. https://web.archive.org/web/20131029211621/https://fedoraproject.org/get-fedora

So maybe something similar when a new version of oVirt is approaching?

> 
> Ideally, we want to make the onboarding process as (a) efficient and (b) easy
> as possible.
> 
> Looking forward to hearing from you,
> BKP
> 
> 
> --
> Brian Proffitt - oVirt Community Manager
> Open Source and Standards, Red Hat - http://community.redhat.com
> Phone: +1 312 477 4320 / Cell: +1 574 383 9BKP
> IRC: bkp
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From sbonazzo at redhat.com  Wed Jan 15 10:51:26 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Wed, 15 Jan 2014 11:51:26 +0100
Subject: [QE] oVirt 3.3.3 beta status
In-Reply-To: <52CFE3CD.4020405@redhat.com>
References: <52CFE3CD.4020405@redhat.com>
Message-ID: <52D6682E.5000402@redhat.com>

Hi,
oVirt 3.3.3 beta has been released and is actually on QA.

The bug tracker [1] shows no bugs blocking the release

The following is a list of the non-blocking bugs still open with target 3.3 - 3.3.3:

Whiteboard	Bug ID	Summary
infra		987982	When adding a host through the REST API, the error message says that "rootPassword" is required...
infra		1040022	vdsm-tool configurre errors when installing vdsm package
integration	902979	ovirt-live - firefox doesn't trust the installed engine
integration	1021805	[RFE] oVirt Live - use motd to show the admin password
integration	1022440	[RFE] AIO - configure the AIO host to be a gluster cluster/host
integration	1026930	Package virtio-win and put it in ovirt repositories
integration	1026933	pre-populate ISO domain with virtio-win ISO
network		997197	Some AppErrors messages are grammatically incorrect (singular vs plural)
storage		987917	[oVirt] [glance] API version not specified in provider dialog
virt		1007940	Cannot clone from snapshot while using GlusterFS as POSIX Storage Domain
		906257	USB Flash Drive install of ovirt-node created via dd fails
		923049	ovirt-node fails to boot from local disk under UEFI mode
		965583	[RFE] add shortcut key on TUI
		976675	[wiki] Update contribution page
		979350	Changes admin password in the first time when log in is failed while finished auto-install
		979390	[RFE] Split defaults.py into smaller pieces
		982232	performance page takes >1sec to load (on first load)
		984441	kdump page crashed before configuring the network after ovirt-node intalled
		986285	UI crashes when no bond name is given
		991267	[RFE] Add TUI information to log file.
		1018374	ovirt-node-iso-3.0.1-1.0.2.vdsm.fc19: Failed on Auto-install
		1018710	[RFE] Enhance API documentation
		1032035	[RFE]re-write auto install function for the cim plugin
		1033286	ovirt-node-plugin-vdsm can not be added to ovirt node el6 base image


Maintainers:
- Please add the bugs to the tracker if you think that 3.3.3 should not be released without them fixed.
- Please provide ETA on bugs you add as blockers
- Please re-target all bugs you don't think that should block 3.3.3.
- Please fill release notes, the page has been created here [3]

For those who want to help testing the bugs, I suggest to add yourself as QA contact for the bug and add yourself to the testing page [2].

[1] http://bugzilla.redhat.com/1050084
[2] http://www.ovirt.org/Testing/Ovirt_3.3.3_testing
[3] http://www.ovirt.org/OVirt_3.3.3_release_notes

Thanks,


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


From sbonazzo at redhat.com  Wed Jan 15 11:24:00 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Wed, 15 Jan 2014 12:24:00 +0100
Subject: [QE] 3.4.0 alpha release status
In-Reply-To: <52CD105E.2040409@redhat.com>
References: <52CD105E.2040409@redhat.com>
Message-ID: <52D66FD0.3050400@redhat.com>

Hi,
oVirt 3.4.0 alpha has been released and is actually on QA.

The bug tracker [1] shows the following bugs blocking the release:

There are still 280 bugs [2] targeted to 3.4.0 so please review them as soon as possible

Maintainers:
- Please add the bugs to the tracker if you think that 3.4.0 should not be released without them fixed.
- Please provide ETA on bugs you add as blockers
- Please start updating the target to 3.4.1 or any next release for bugs that won't be in 3.4.0:
  it will ease gathering the blocking bugs for next releases.
- Please start filling release notes, the page has been created here [3]


For those who want to help testing the bugs, I suggest to add yourself as QA contact for the bug.


[1] https://bugzilla.redhat.com/1024889
[2] http://red.ht/1eIRZXM
[3] http://www.ovirt.org/OVirt_3.4.0_release_notes


Thanks,


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


From iheim at redhat.com  Wed Jan 15 11:49:25 2014
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 15 Jan 2014 13:49:25 +0200
Subject: Suggestion for Handling Pre-Releases
In-Reply-To: <52D648EE.3070404@redhat.com>
References: <917218950.472726.1389641722389.JavaMail.root@redhat.com>
	<52D50040.2000504@redhat.com> <52D55718.8050400@redhat.com>
	<52D5792C.8080807@redhat.com> <52D59EB2.4040105@redhat.com>
	<52D648EE.3070404@redhat.com>
Message-ID: <52D675C5.5060300@redhat.com>

On 01/15/2014 10:38 AM, Livnat Peer wrote:
> On 01/14/2014 10:31 PM, Itamar Heim wrote:
>> On 01/14/2014 07:51 PM, Livnat Peer wrote:
>>> On 01/14/2014 05:26 PM, Itamar Heim wrote:
>>>> On 01/14/2014 11:15 AM, Livnat Peer wrote:
>>>>> On 01/13/2014 09:35 PM, Brian Proffitt wrote:
>>>>>> Kiril, Dave and I were discussing how to update the community on
>>>>>> pre-releases, while still keeping newer users on track to download
>>>>>> and install the most stable release. What would be some suggestions
>>>>>> on how to ensure new users are getting stable and veteran users are
>>>>>> getting to development releases, if they want? We were pondering a
>>>>>> separate link on the home page to something like this
>>>>>> (http://www.ovirt.org/Download_devel_release), but other ideas are
>>>>>> more than welcome.
>>>>>>
>>>>>> Ideally, we want to make the onboarding process as (a) efficient and
>>>>>> (b) easy as possible.
>>>>>>
>>>>>
>>>>> Brian,
>>>>>
>>>>> Just making sure I got the question right, we are looking on a way to
>>>>> make the alpha/beta build more available for users?
>>>>>
>>>>> If that is the question, how about the jboss( Wildfly :) ) approach
>>>>> http://wildfly.org/downloads/
>>>>>
>>>>>
>>>>> Livnat
>>>>>
>>>>>> Looking forward to hearing from you,
>>>>>> BKP
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Arch mailing list
>>>>> Arch at ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/arch
>>>>>
>>>>
>>>> I think Lior was talking about making this visible via the webadmin.
>>>
>>> That was my understanding as well.
>>>
>>>> I think the right way of doing this is not related to the web site,
>>>> rather to the ovirt engine showing if there are newer (relevant)
>>>> packages in the engine-check-update queue.
>>>
>>> I don't think the two are exclusive or, I think we should have both.
>>> I rather d/l bits from a website over clicking on d/l buttons in the app.
>>>
>>
>> d/l bits from the website doesn't work for rpm based deployments for
>> updates.
>> the website download link should point to latest stable release, maybe
>> also to latest unstable (next version alpha/beta/etc.).
>>
>> the webadmin should show an existing admin that there is a newer version
>> available, without the admin visiting the website.
>
> The webadmin should indicate that there are new bits, for getting them
> you need to go to the website and d/l them.

download what - 50 rpm's?

engine should just execute yum update on the engine/hosts when asked by 
admin after showing there are updates.

>
> The original question was how do we add exposure to the pre-releases
> which are not available today for users, and the webadmin can not be the
> only way to get alpha/beta release.

this should be prominent on the home page, i agree.



From dneary at redhat.com  Wed Jan 15 11:18:13 2014
From: dneary at redhat.com (Dave Neary)
Date: Wed, 15 Jan 2014 12:18:13 +0100
Subject: [wiki curation] Feature template
In-Reply-To: <alpine.LRH.2.03.1401141344380.24648@bjyevire.pbz>
References: <52D570D4.8090501@redhat.com>
	<alpine.LRH.2.03.1401141344380.24648@bjyevire.pbz>
Message-ID: <52D66E75.5090600@redhat.com>

Hi Russ,

On 01/14/2014 07:53 PM, R P Herrold wrote:
> On Tue, 14 Jan 2014, Dave Neary wrote:
>> {{Feature|name=Network QoS|modules=network|version=3.3|status=Released}}
> 
> Three additional suggestions:
> 
> Isn't there a need for way to see:
> 	Appeared at
> 	Stable by
> 	Retired after

I would suggest no - perhaps a "deprecated" field would be useful, but
I'm unaware of any feature which was added then later removed from the
project.

There may be a use for a "Proposed" status - that is, the feature page
exists, but no-one's stepped up to code it yet - and an "Owner" field,
so that we can identify the primary developer of the feature.

> As I read setup articles in the wiki, there seems to be such a 
> life-cycle

Set-up articles are slightly different - we will continually try to
improve and streamline the installation experience. But they wouldn't
come under "Feature pages" for me.

> 2. Also, exposing:
> 	Last edited on:
> 	Last editor:
> 
> would be a goodness -- I regularly receive direct email from 
> folks not willing for wnatever reason to wade into a high 
> volume mailing list, but seeking help, and having the ability 
> to ** find ** someone, anyone authoring in a subject matter 
> area is part of the FOSS ethic

Yes, I think an "Updated on:" field would be good. In combination with
an "Owner" field, that should take care of your need.

> 3. And having a formal machanism to formally catch
> 	Potentially stale: 
> 
> content, so that pages might be marked in one pass and 'on the 
> fly', then later searched, and finally curated back to not 
> 'Potentially stale'
> 
> were markings I used when maintaininthg CentOS wiki presence, 
> to combat entropy

Again, it seems like you're thinking of this as something which might be
on all pages - its specifically for "feature pages" - they are
functional specs and design documents for features to be added to oVirt.
I don't think "potentially stale" applies (perhaps I'm wrong?).

Cheers,
Dave.

-- 
Dave Neary - Community Action and Impact
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13


From mkolesni at redhat.com  Wed Jan 15 12:56:22 2014
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Wed, 15 Jan 2014 07:56:22 -0500 (EST)
Subject: [wiki curation] Feature template
In-Reply-To: <52D66E75.5090600@redhat.com>
References: <52D570D4.8090501@redhat.com>
	<alpine.LRH.2.03.1401141344380.24648@bjyevire.pbz>
	<52D66E75.5090600@redhat.com>
Message-ID: <679921684.1677382.1389790582289.JavaMail.root@redhat.com>

----- Original Message -----
> Hi Russ,
> 
> On 01/14/2014 07:53 PM, R P Herrold wrote:
> > On Tue, 14 Jan 2014, Dave Neary wrote:
> >> {{Feature|name=Network QoS|modules=network|version=3.3|status=Released}}
> > 
> > Three additional suggestions:
> > 
> > Isn't there a need for way to see:
> > 	Appeared at
> > 	Stable by
> > 	Retired after
> 
> I would suggest no - perhaps a "deprecated" field would be useful, but
> I'm unaware of any feature which was added then later removed from the
> project.
> 
> There may be a use for a "Proposed" status - that is, the feature page
> exists, but no-one's stepped up to code it yet - and an "Owner" field,
> so that we can identify the primary developer of the feature.
> 
> > As I read setup articles in the wiki, there seems to be such a
> > life-cycle
> 
> Set-up articles are slightly different - we will continually try to
> improve and streamline the installation experience. But they wouldn't
> come under "Feature pages" for me.
> 
> > 2. Also, exposing:
> > 	Last edited on:
> > 	Last editor:
> > 
> > would be a goodness -- I regularly receive direct email from
> > folks not willing for wnatever reason to wade into a high
> > volume mailing list, but seeking help, and having the ability
> > to ** find ** someone, anyone authoring in a subject matter
> > area is part of the FOSS ethic
> 
> Yes, I think an "Updated on:" field would be good. In combination with

Wouldn't this be the same as the "last updated" field that we already have in the feature pages?

> an "Owner" field, that should take care of your need.

We have an entire "owner" section in the feature pages as well..

> 
> > 3. And having a formal machanism to formally catch
> > 	Potentially stale:
> > 
> > content, so that pages might be marked in one pass and 'on the
> > fly', then later searched, and finally curated back to not
> > 'Potentially stale'
> > 
> > were markings I used when maintaininthg CentOS wiki presence,
> > to combat entropy
> 
> Again, it seems like you're thinking of this as something which might be
> on all pages - its specifically for "feature pages" - they are
> functional specs and design documents for features to be added to oVirt.
> I don't think "potentially stale" applies (perhaps I'm wrong?).
> 
> Cheers,
> Dave.
> 
> --
> Dave Neary - Community Action and Impact
> Open Source and Standards, Red Hat - http://community.redhat.com
> Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From sbonazzo at redhat.com  Wed Jan 15 13:08:55 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Wed, 15 Jan 2014 14:08:55 +0100
Subject: [QE] 3.4.0 alpha release status
In-Reply-To: <52D66FD0.3050400@redhat.com>
References: <52CD105E.2040409@redhat.com> <52D66FD0.3050400@redhat.com>
Message-ID: <52D68867.9080608@redhat.com>

Il 15/01/2014 12:24, Sandro Bonazzola ha scritto:
> Hi,
> oVirt 3.4.0 alpha has been released and is actually on QA.
> 
> The bug tracker [1] shows the following bugs blocking the release:

Sorry, missed the blocker list:

network - Bug 987813 - [RFE] report BOOTPROTO and BONDING_OPTS independent of netdevice.cfg
storage - Bug 1032686 - [RFE] API to save OVF on any location
gluster - Bug 1038988 - Gluster brick sync does not work when host has multiple interfaces


> 
> There are still 280 bugs [2] targeted to 3.4.0 so please review them as soon as possible
> 
> Maintainers:
> - Please add the bugs to the tracker if you think that 3.4.0 should not be released without them fixed.
> - Please provide ETA on bugs you add as blockers
> - Please start updating the target to 3.4.1 or any next release for bugs that won't be in 3.4.0:
>   it will ease gathering the blocking bugs for next releases.
> - Please start filling release notes, the page has been created here [3]
> 
> 
> For those who want to help testing the bugs, I suggest to add yourself as QA contact for the bug.
> 
> 
> [1] https://bugzilla.redhat.com/1024889
> [2] http://red.ht/1eIRZXM
> [3] http://www.ovirt.org/OVirt_3.4.0_release_notes
> 
> 
> Thanks,
> 
> 


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


From jbrooks at redhat.com  Wed Jan 15 15:23:05 2014
From: jbrooks at redhat.com (Jason Brooks)
Date: Wed, 15 Jan 2014 10:23:05 -0500 (EST)
Subject: Feature template
In-Reply-To: <52D6398B.7050402@redhat.com>
References: <52D570D4.8090501@redhat.com>
	<2044582828.1862520.1389736633454.JavaMail.root@redhat.com>
	<52D6398B.7050402@redhat.com>
Message-ID: <729692075.2398420.1389799385792.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Dave Neary" <dneary at redhat.com>
> To: "Jason Brooks" <jbrooks at redhat.com>
> Cc: "arch" <arch at ovirt.org>
> Sent: Tuesday, January 14, 2014 11:32:27 PM
> Subject: Re: Feature template
> 
> Hi,
> 
> That belongs in the Feature page, not in the little side-bar which
> informs you of its status.
> 
> It should definitely be there, though.

Ah, I see. A name like http://www.ovirt.org/Template:Feature-Status
would make more sense, then.

> 
> Cheers,
> Dave.
> 
> On 01/14/2014 10:57 PM, Jason Brooks wrote:
> > It'd be good to include "how to test"
> > 
> > ----- Original Message -----
> >> From: "Dave Neary" <dneary at redhat.com>
> >> To: "arch" <arch at ovirt.org>
> >> Sent: Tuesday, January 14, 2014 9:16:04 AM
> >> Subject: Feature template
> >>
> >> Hi everyone,
> >>
> >> To resolve a long-standing issue with feature pages in the wiki, I have
> >> created a wiki template for features. I would appreciate it if you could
> >> add it to the top of every feature page you're responsible for.
> >>
> >> The feature is really simple:
> >>
> >> http://www.ovirt.org/Template:Feature
> >>
> >> You use it as so:
> >>
> >> {{Feature|name=Network QoS|modules=network|version=3.3|status=Released}}
> >>
> >> You can see an example of its usage in "All in One":
> >> http://www.ovirt.org/Feature/AllInOne
> >>
> >> If you keep status to one of "Released" (meaning: in a release), "In
> >> testing" (complete in Git, not yet released), "In progress" (coding
> >> happening, perhaps on a branch), "Not started", we should be able to
> >> colour code feature panels to indicate the status of the feature in the
> >> box.
> >>
> >> Thanks!
> >> Dave.
> >>
> >> --
> >> Dave Neary - Community Action and Impact
> >> Open Source and Standards, Red Hat - http://community.redhat.com
> >> Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13
> >> _______________________________________________
> >> Arch mailing list
> >> Arch at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/arch
> >>
> 
> --
> Dave Neary - Community Action and Impact
> Open Source and Standards, Red Hat - http://community.redhat.com
> Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13
> 


From herrold at owlriver.com  Wed Jan 15 15:29:02 2014
From: herrold at owlriver.com (R P Herrold)
Date: Wed, 15 Jan 2014 10:29:02 -0500 (EST)
Subject: [wiki curation] Feature template
In-Reply-To: <679921684.1677382.1389790582289.JavaMail.root@redhat.com>
References: <52D570D4.8090501@redhat.com>
	<alpine.LRH.2.03.1401141344380.24648@bjyevire.pbz>
	<52D66E75.5090600@redhat.com>
	<679921684.1677382.1389790582289.JavaMail.root@redhat.com>
Message-ID: <alpine.LRH.2.03.1401151019110.18055@bjyevire.pbz>

On Wed, 15 Jan 2014, Mike Kolesnik wrote:

> > I would suggest no - perhaps a "deprecated" field would be useful, but
> > I'm unaware of any feature which was added then later removed from the
> > project.

I missed the fact that you were limiting your discussion to 
the extension for 'Features' rather than the wiki generally, 
and so my scope and yours did not match, as I was thinking 
generally across the wiki, and not limited to specific Feature 
pages.  I had not intended to hijack a thread ;(
 
> > > As I read setup articles in the wiki, there seems to be such a
> > > life-cycle
> > 
> > Set-up articles are slightly different - we will continually try to
> > improve and streamline the installation experience. But they wouldn't
> > come under "Feature pages" for me.

concur

> > > 2. Also, exposing:
> > > 	Last edited on:
> > > 	Last editor:

> > > would be a goodness -- I regularly receive direct email 
> > > from folks not willing for wnatever reason to wade into 
> > > a high volume mailing list, but seeking help, and having 
> > > the ability to ** find ** someone, anyone authoring in a 
> > > subject matter area is part of the FOSS ethic
> > 
> > Yes, I think an "Updated on:" field would be good. In combination with
> 
> Wouldn't this be the same as the "last updated" field that we already have in the feature pages?
> 
> > an "Owner" field, that should take care of your need.

As I read it, and as I look, Owner is really more tied to 
Features -- I was discussing a simple way from for a end user 
coming to the wiki (usually without edit rights) to identify 
someone (the last person doing edits) who may have subject 
matter expertise in general

> > > 3. And having a formal machanism to formally catch
> > > 	Potentially stale:
> > > 
> > > content, so that pages might be marked in one pass and 'on the
> > > fly', then later searched, and finally curated back to not
> > > 'Potentially stale'
> > > 
> > > were markings I used when maintaining CentOS wiki presence,
> > > to combat entropy
> > 
> > Again, it seems like you're thinking of this as something which might be
> > on all pages - its specifically for "feature pages" - they are
> > functional specs and design documents for features to be added to oVirt.
> > I don't think "potentially stale" applies (perhaps I'm wrong?).

Yes -- my comments were out of scope for Feature subset of 
pages

Thanks for the feedback

-- Russ herrold


From danken at redhat.com  Wed Jan 15 16:56:50 2014
From: danken at redhat.com (Dan Kenigsberg)
Date: Wed, 15 Jan 2014 16:56:50 +0000
Subject: Feature template
In-Reply-To: <52D570D4.8090501@redhat.com>
References: <52D570D4.8090501@redhat.com>
Message-ID: <20140115165649.GF25223@redhat.com>

On Tue, Jan 14, 2014 at 06:16:04PM +0100, Dave Neary wrote:
> Hi everyone,
> 
> To resolve a long-standing issue with feature pages in the wiki, I have
> created a wiki template for features. I would appreciate it if you could
> add it to the top of every feature page you're responsible for.
> 
> The feature is really simple:
> 
> http://www.ovirt.org/Template:Feature
> 
> You use it as so:
> 
> {{Feature|name=Network QoS|modules=network|version=3.3|status=Released}}
> 
> You can see an example of its usage in "All in One":
> http://www.ovirt.org/Feature/AllInOne
> 
> If you keep status to one of "Released" (meaning: in a release), "In
> testing" (complete in Git, not yet released), "In progress" (coding
> happening, perhaps on a branch), "Not started", we should be able to
> colour code feature panels to indicate the status of the feature in the box.

Is it possible to have the template automatically translate
"modules=networking" bit into a [[Category:Networking]] referece?
Similarly, an automatically [[Category:oVirt-3.3_Feature]] would be
useful.



From dneary at redhat.com  Wed Jan 15 19:56:29 2014
From: dneary at redhat.com (Dave Neary)
Date: Wed, 15 Jan 2014 20:56:29 +0100
Subject: Feature template
In-Reply-To: <20140115165649.GF25223@redhat.com>
References: <52D570D4.8090501@redhat.com> <20140115165649.GF25223@redhat.com>
Message-ID: <52D6E7ED.5060200@redhat.com>

Hi,

On 01/15/2014 05:56 PM, Dan Kenigsberg wrote:
> On Tue, Jan 14, 2014 at 06:16:04PM +0100, Dave Neary wrote:
> Is it possible to have the template automatically translate
> "modules=networking" bit into a [[Category:Networking]] referece?
> Similarly, an automatically [[Category:oVirt-3.3_Feature]] would be
> useful.

Everything is possible... templates are a Turing complete programming
language.

Would you like to have a go? :-)

Cheers,
Dave.

-- 
Dave Neary - Community Action and Impact
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13


From danken at redhat.com  Wed Jan 15 22:30:23 2014
From: danken at redhat.com (Dan Kenigsberg)
Date: Wed, 15 Jan 2014 22:30:23 +0000
Subject: Feature template
In-Reply-To: <52D6E7ED.5060200@redhat.com>
References: <52D570D4.8090501@redhat.com> <20140115165649.GF25223@redhat.com>
	<52D6E7ED.5060200@redhat.com>
Message-ID: <20140115223023.GH25223@redhat.com>

On Wed, Jan 15, 2014 at 08:56:29PM +0100, Dave Neary wrote:
> Hi,
> 
> On 01/15/2014 05:56 PM, Dan Kenigsberg wrote:
> > On Tue, Jan 14, 2014 at 06:16:04PM +0100, Dave Neary wrote:
> > Is it possible to have the template automatically translate
> > "modules=networking" bit into a [[Category:Networking]] referece?
> > Similarly, an automatically [[Category:oVirt-3.3_Feature]] would be
> > useful.
> 
> Everything is possible... templates are a Turing complete programming
> language.
> 
> Would you like to have a go? :-)

Not today, I'm afraid :-(
Luckily for me, not only patches count; RFEs are important, too.


From herrold at owlriver.com  Wed Jan 15 22:48:37 2014
From: herrold at owlriver.com (R P Herrold)
Date: Wed, 15 Jan 2014 17:48:37 -0500 (EST)
Subject: Feature template
In-Reply-To: <52D6E7ED.5060200@redhat.com>
References: <52D570D4.8090501@redhat.com> <20140115165649.GF25223@redhat.com>
	<52D6E7ED.5060200@redhat.com>
Message-ID: <alpine.LRH.2.03.1401151747580.5834@bjyevire.pbz>

On Wed, 15 Jan 2014, Dave Neary wrote:

> Everything is possible... templates are a Turing complete programming
> language.
> 
> Would you like to have a go? :-)

from which VCS may I CO the existing code?

-- Russ herrold


From dneary at redhat.com  Wed Jan 15 22:51:58 2014
From: dneary at redhat.com (Dave Neary)
Date: Wed, 15 Jan 2014 23:51:58 +0100
Subject: Feature template
In-Reply-To: <alpine.LRH.2.03.1401151747580.5834@bjyevire.pbz>
References: <52D570D4.8090501@redhat.com> <20140115165649.GF25223@redhat.com>
	<52D6E7ED.5060200@redhat.com>
	<alpine.LRH.2.03.1401151747580.5834@bjyevire.pbz>
Message-ID: <52D7110E.2040405@redhat.com>



On 01/15/2014 11:48 PM, R P Herrold wrote:
> On Wed, 15 Jan 2014, Dave Neary wrote:
> 
>> Everything is possible... templates are a Turing complete programming
>> language.
>>
>> Would you like to have a go? :-)
> 
> from which VCS may I CO the existing code?

MediaWiki is, itself, a VCS :-)

Note, I did not say that MediaWiki templates were a good programming
language, or that MediaWiki is a good VCS.

Dave.

-- 
Dave Neary - Community Action and Impact
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13


From herrold at owlriver.com  Wed Jan 15 23:01:51 2014
From: herrold at owlriver.com (R P Herrold)
Date: Wed, 15 Jan 2014 18:01:51 -0500 (EST)
Subject: Feature template
In-Reply-To: <52D7110E.2040405@redhat.com>
References: <52D570D4.8090501@redhat.com> <20140115165649.GF25223@redhat.com>
	<52D6E7ED.5060200@redhat.com>
	<alpine.LRH.2.03.1401151747580.5834@bjyevire.pbz>
	<52D7110E.2040405@redhat.com>
Message-ID: <alpine.LRH.2.03.1401151758590.15221@bjyevire.pbz>

On Wed, 15 Jan 2014, Dave Neary wrote:

> On 01/15/2014 11:48 PM, R P Herrold wrote:
> > On Wed, 15 Jan 2014, Dave Neary wrote:
> > 
> >> Everything is possible... templates are a Turing complete programming
> >> language.
> >>
> >> Would you like to have a go? :-)
> > 
> > from which VCS may I CO the existing code?
> 
> MediaWiki is, itself, a VCS :-)
> 
> Note, I did not say that MediaWiki templates were a good programming
> language, or that MediaWiki is a good VCS.

I separately package MW variants for customers, and know what 
a cesspool it is :(

But as such, I own the needed rubber gloves and galoshes and 
goggles

Access to a RO CO without inadvertently releasing any 
credentials would be useful

-- Russ herrold


From sbonazzo at redhat.com  Thu Jan 16 08:08:13 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Thu, 16 Jan 2014 09:08:13 +0100
Subject: ovirt-engine 3.4.0 branching
Message-ID: <52D7936D.6040009@redhat.com>

Hi,
 this is the last call for pending patches on master branch for ovirt-engine.
The ovirt-engine-3.4 branch will be created at 9:00 AM UTC (11:00 AM Israel time).

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


From sbonazzo at redhat.com  Thu Jan 16 10:09:46 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Thu, 16 Jan 2014 11:09:46 +0100
Subject: proposal for moving nightly to 3.4 stabilization branch
Message-ID: <52D7AFEA.4050700@redhat.com>

Hi,
since it seems not possible to have both master and 3.4 nightly builds, I suggest to move nightly to 3.4 branches.
At this stage nobody really needs master nightly, while 3.4.0 branches nightly will be more useful.


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


From alonbl at redhat.com  Thu Jan 16 10:12:12 2014
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Thu, 16 Jan 2014 05:12:12 -0500 (EST)
Subject: proposal for moving nightly to 3.4 stabilization branch
In-Reply-To: <52D7AFEA.4050700@redhat.com>
References: <52D7AFEA.4050700@redhat.com>
Message-ID: <958542607.1128230.1389867132207.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> To: "infra" <infra at ovirt.org>, "arch" <arch at ovirt.org>
> Sent: Thursday, January 16, 2014 12:09:46 PM
> Subject: proposal for moving nightly to 3.4 stabilization branch
> 
> Hi,
> since it seems not possible to have both master and 3.4 nightly builds, I
> suggest to move nightly to 3.4 branches.
> At this stage nobody really needs master nightly, while 3.4.0 branches
> nightly will be more useful.

Why is that?

Kiril is working on splitting repo per version, so you have multiple nightly.

> 
> 
> --
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From sbonazzo at redhat.com  Thu Jan 16 10:15:52 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Thu, 16 Jan 2014 11:15:52 +0100
Subject: proposal for moving nightly to 3.4 stabilization branch
In-Reply-To: <958542607.1128230.1389867132207.JavaMail.root@redhat.com>
References: <52D7AFEA.4050700@redhat.com>
	<958542607.1128230.1389867132207.JavaMail.root@redhat.com>
Message-ID: <52D7B158.1020801@redhat.com>

Il 16/01/2014 11:12, Alon Bar-Lev ha scritto:
> 
> 
> ----- Original Message -----
>> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
>> To: "infra" <infra at ovirt.org>, "arch" <arch at ovirt.org>
>> Sent: Thursday, January 16, 2014 12:09:46 PM
>> Subject: proposal for moving nightly to 3.4 stabilization branch
>>
>> Hi,
>> since it seems not possible to have both master and 3.4 nightly builds, I
>> suggest to move nightly to 3.4 branches.
>> At this stage nobody really needs master nightly, while 3.4.0 branches
>> nightly will be more useful.
> 
> Why is that?
> 
> Kiril is working on splitting repo per version, so you have multiple nightly.

nightly requires 6GB of disk space and we have just 3GB left there.
We're short on resources for having multiple nightlies right now.



> 
>>
>>
>> --
>> Sandro Bonazzola
>> Better technology. Faster innovation. Powered by community collaboration.
>> See how it works at redhat.com
>> _______________________________________________
>> Arch mailing list
>> Arch at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/arch
>>


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


From dcaroest at redhat.com  Thu Jan 16 10:18:41 2014
From: dcaroest at redhat.com (David Caro)
Date: Thu, 16 Jan 2014 11:18:41 +0100
Subject: proposal for moving nightly to 3.4 stabilization branch
In-Reply-To: <52D7B158.1020801@redhat.com>
References: <52D7AFEA.4050700@redhat.com>
	<958542607.1128230.1389867132207.JavaMail.root@redhat.com>
	<52D7B158.1020801@redhat.com>
Message-ID: <52D7B201.5020204@redhat.com>

El jue 16 ene 2014 11:15:52 CET, Sandro Bonazzola escribi?:
> Il 16/01/2014 11:12, Alon Bar-Lev ha scritto:
>>
>>
>> ----- Original Message -----
>>> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
>>> To: "infra" <infra at ovirt.org>, "arch" <arch at ovirt.org>
>>> Sent: Thursday, January 16, 2014 12:09:46 PM
>>> Subject: proposal for moving nightly to 3.4 stabilization branch
>>>
>>> Hi,
>>> since it seems not possible to have both master and 3.4 nightly builds, I
>>> suggest to move nightly to 3.4 branches.
>>> At this stage nobody really needs master nightly, while 3.4.0 branches
>>> nightly will be more useful.
>>
>> Why is that?
>>
>> Kiril is working on splitting repo per version, so you have multiple nightly.
>
> nightly requires 6GB of disk space and we have just 3GB left there.
> We're short on resources for having multiple nightlies right now.

I correct myself, right now nightly takes ~3GB of space. I can try to 
make some space, but if the repo size increases a little we'll run out 
f space there.

>
>
>
>>
>>>
>>>
>>> --
>>> Sandro Bonazzola
>>> Better technology. Faster innovation. Powered by community collaboration.
>>> See how it works at redhat.com
>>> _______________________________________________
>>> Arch mailing list
>>> Arch at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/arch
>>>
>
>



--
David Caro

Red Hat S.L.
Continuous Integration Engineer - EMEA ENG Virtualization R&D

Email: dcaro at redhat.com
Web: www.redhat.com
RHT Global #: 82-62605

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20140116/6b11b542/attachment.sig>

From alonbl at redhat.com  Thu Jan 16 10:37:59 2014
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Thu, 16 Jan 2014 05:37:59 -0500 (EST)
Subject: proposal for moving nightly to 3.4 stabilization branch
In-Reply-To: <52D7B201.5020204@redhat.com>
References: <52D7AFEA.4050700@redhat.com>
	<958542607.1128230.1389867132207.JavaMail.root@redhat.com>
	<52D7B158.1020801@redhat.com> <52D7B201.5020204@redhat.com>
Message-ID: <708502818.1130869.1389868679351.JavaMail.root@redhat.com>



----- Original Message -----
> From: "David Caro" <dcaroest at redhat.com>
> To: "Sandro Bonazzola" <sbonazzo at redhat.com>
> Cc: "arch" <arch at ovirt.org>, "infra" <infra at ovirt.org>, "Alon Bar-Lev" <alonbl at redhat.com>
> Sent: Thursday, January 16, 2014 12:18:41 PM
> Subject: Re: proposal for moving nightly to 3.4 stabilization branch
> 
> El jue 16 ene 2014 11:15:52 CET, Sandro Bonazzola escribi?:
> > Il 16/01/2014 11:12, Alon Bar-Lev ha scritto:
> >>
> >>
> >> ----- Original Message -----
> >>> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> >>> To: "infra" <infra at ovirt.org>, "arch" <arch at ovirt.org>
> >>> Sent: Thursday, January 16, 2014 12:09:46 PM
> >>> Subject: proposal for moving nightly to 3.4 stabilization branch
> >>>
> >>> Hi,
> >>> since it seems not possible to have both master and 3.4 nightly builds, I
> >>> suggest to move nightly to 3.4 branches.
> >>> At this stage nobody really needs master nightly, while 3.4.0 branches
> >>> nightly will be more useful.
> >>
> >> Why is that?
> >>
> >> Kiril is working on splitting repo per version, so you have multiple
> >> nightly.
> >
> > nightly requires 6GB of disk space and we have just 3GB left there.
> > We're short on resources for having multiple nightlies right now.
> 
> I correct myself, right now nightly takes ~3GB of space. I can try to
> make some space, but if the repo size increases a little we'll run out
> f space there.

if nobody will test master then we will be in big problem when trying to stabilize it.

> 
> >
> >
> >
> >>
> >>>
> >>>
> >>> --
> >>> Sandro Bonazzola
> >>> Better technology. Faster innovation. Powered by community collaboration.
> >>> See how it works at redhat.com
> >>> _______________________________________________
> >>> Arch mailing list
> >>> Arch at ovirt.org
> >>> http://lists.ovirt.org/mailman/listinfo/arch
> >>>
> >
> >
> 
> 
> 
> --
> David Caro
> 
> Red Hat S.L.
> Continuous Integration Engineer - EMEA ENG Virtualization R&D
> 
> Email: dcaro at redhat.com
> Web: www.redhat.com
> RHT Global #: 82-62605
> 
> 


From iheim at redhat.com  Thu Jan 16 11:51:43 2014
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 16 Jan 2014 13:51:43 +0200
Subject: proposal for moving nightly to 3.4 stabilization branch
In-Reply-To: <708502818.1130869.1389868679351.JavaMail.root@redhat.com>
References: <52D7AFEA.4050700@redhat.com>	<958542607.1128230.1389867132207.JavaMail.root@redhat.com>	<52D7B158.1020801@redhat.com>
	<52D7B201.5020204@redhat.com>
	<708502818.1130869.1389868679351.JavaMail.root@redhat.com>
Message-ID: <52D7C7CF.6060204@redhat.com>

On 01/16/2014 12:37 PM, Alon Bar-Lev wrote:
>
>
> ----- Original Message -----
>> From: "David Caro" <dcaroest at redhat.com>
>> To: "Sandro Bonazzola" <sbonazzo at redhat.com>
>> Cc: "arch" <arch at ovirt.org>, "infra" <infra at ovirt.org>, "Alon Bar-Lev" <alonbl at redhat.com>
>> Sent: Thursday, January 16, 2014 12:18:41 PM
>> Subject: Re: proposal for moving nightly to 3.4 stabilization branch
>>
>> El jue 16 ene 2014 11:15:52 CET, Sandro Bonazzola escribi?:
>>> Il 16/01/2014 11:12, Alon Bar-Lev ha scritto:
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
>>>>> To: "infra" <infra at ovirt.org>, "arch" <arch at ovirt.org>
>>>>> Sent: Thursday, January 16, 2014 12:09:46 PM
>>>>> Subject: proposal for moving nightly to 3.4 stabilization branch
>>>>>
>>>>> Hi,
>>>>> since it seems not possible to have both master and 3.4 nightly builds, I
>>>>> suggest to move nightly to 3.4 branches.
>>>>> At this stage nobody really needs master nightly, while 3.4.0 branches
>>>>> nightly will be more useful.
>>>>
>>>> Why is that?
>>>>
>>>> Kiril is working on splitting repo per version, so you have multiple
>>>> nightly.
>>>
>>> nightly requires 6GB of disk space and we have just 3GB left there.
>>> We're short on resources for having multiple nightlies right now.
>>
>> I correct myself, right now nightly takes ~3GB of space. I can try to
>> make some space, but if the repo size increases a little we'll run out
>> f space there.
>
> if nobody will test master then we will be in big problem when trying to stabilize it.

agree - we need master tested and we should have nightlies on it as well

>
>>
>>>
>>>
>>>
>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Sandro Bonazzola
>>>>> Better technology. Faster innovation. Powered by community collaboration.
>>>>> See how it works at redhat.com
>>>>> _______________________________________________
>>>>> Arch mailing list
>>>>> Arch at ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/arch
>>>>>
>>>
>>>
>>
>>
>>
>> --
>> David Caro
>>
>> Red Hat S.L.
>> Continuous Integration Engineer - EMEA ENG Virtualization R&D
>>
>> Email: dcaro at redhat.com
>> Web: www.redhat.com
>> RHT Global #: 82-62605
>>
>>
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
>



From sbonazzo at redhat.com  Thu Jan 16 12:07:25 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Thu, 16 Jan 2014 13:07:25 +0100
Subject: ovirt-engine 3.4.0 branching
In-Reply-To: <52D7936D.6040009@redhat.com>
References: <52D7936D.6040009@redhat.com>
Message-ID: <52D7CB7D.8050006@redhat.com>

Il 16/01/2014 09:08, Sandro Bonazzola ha scritto:
> Hi,
>  this is the last call for pending patches on master branch for ovirt-engine.
> The ovirt-engine-3.4 branch will be created at 9:00 AM UTC (11:00 AM Israel time).
> 

The ovirt-engine-3.4 branch has been created on:

* ad87adf - (HEAD, origin/ovirt-engine-3.4, ovirt-engine-3.4) restapi: Add Reboot VM action <Martin Betak>

Please remember to push to the new branch all patches you're targeting to 3.4.0 release.
Thanks,

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


From sbonazzo at redhat.com  Thu Jan 16 15:59:42 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Thu, 16 Jan 2014 16:59:42 +0100
Subject: proposal for moving nightly to 3.4 stabilization branch
In-Reply-To: <52D7C7CF.6060204@redhat.com>
References: <52D7AFEA.4050700@redhat.com>	<958542607.1128230.1389867132207.JavaMail.root@redhat.com>	<52D7B158.1020801@redhat.com>	<52D7B201.5020204@redhat.com>	<708502818.1130869.1389868679351.JavaMail.root@redhat.com>
	<52D7C7CF.6060204@redhat.com>
Message-ID: <52D801EE.7040907@redhat.com>

Il 16/01/2014 12:51, Itamar Heim ha scritto:
> On 01/16/2014 12:37 PM, Alon Bar-Lev wrote:
>>
>>
>> ----- Original Message -----
>>> From: "David Caro" <dcaroest at redhat.com>
>>> To: "Sandro Bonazzola" <sbonazzo at redhat.com>
>>> Cc: "arch" <arch at ovirt.org>, "infra" <infra at ovirt.org>, "Alon Bar-Lev" <alonbl at redhat.com>
>>> Sent: Thursday, January 16, 2014 12:18:41 PM
>>> Subject: Re: proposal for moving nightly to 3.4 stabilization branch
>>>
>>> El jue 16 ene 2014 11:15:52 CET, Sandro Bonazzola escribi?:
>>>> Il 16/01/2014 11:12, Alon Bar-Lev ha scritto:
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
>>>>>> To: "infra" <infra at ovirt.org>, "arch" <arch at ovirt.org>
>>>>>> Sent: Thursday, January 16, 2014 12:09:46 PM
>>>>>> Subject: proposal for moving nightly to 3.4 stabilization branch
>>>>>>
>>>>>> Hi,
>>>>>> since it seems not possible to have both master and 3.4 nightly builds, I
>>>>>> suggest to move nightly to 3.4 branches.
>>>>>> At this stage nobody really needs master nightly, while 3.4.0 branches
>>>>>> nightly will be more useful.
>>>>>
>>>>> Why is that?
>>>>>
>>>>> Kiril is working on splitting repo per version, so you have multiple
>>>>> nightly.
>>>>
>>>> nightly requires 6GB of disk space and we have just 3GB left there.
>>>> We're short on resources for having multiple nightlies right now.
>>>
>>> I correct myself, right now nightly takes ~3GB of space. I can try to
>>> make some space, but if the repo size increases a little we'll run out
>>> f space there.
>>
>> if nobody will test master then we will be in big problem when trying to stabilize it.
> 
> agree - we need master tested and we should have nightlies on it as well

We'll need more storage then...
Just to understand how much we need and if we can gather it, how many nightly has to be taken for allowing rollback?
just latest and previous?
Ignore rollback and just keep latest?


> 
>>
>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> -- 
>>>>>> Sandro Bonazzola
>>>>>> Better technology. Faster innovation. Powered by community collaboration.
>>>>>> See how it works at redhat.com
>>>>>> _______________________________________________
>>>>>> Arch mailing list
>>>>>> Arch at ovirt.org
>>>>>> http://lists.ovirt.org/mailman/listinfo/arch
>>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> -- 
>>> David Caro
>>>
>>> Red Hat S.L.
>>> Continuous Integration Engineer - EMEA ENG Virtualization R&D
>>>
>>> Email: dcaro at redhat.com
>>> Web: www.redhat.com
>>> RHT Global #: 82-62605
>>>
>>>
>> _______________________________________________
>> Arch mailing list
>> Arch at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/arch
>>
> 
> _______________________________________________
> Infra mailing list
> Infra at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra


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


From sbonazzo at redhat.com  Fri Jan 17 07:49:30 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Fri, 17 Jan 2014 08:49:30 +0100
Subject: [QE] oVirt bugzilla updates
Message-ID: <52D8E08A.9010706@redhat.com>

Hi oVirt community,
for all people interested in joining QE effort, we've created a new user in bugzilla as default QA assignee: bugs at ovirt.org.
If you want to be updated on QE bugs activity you can just add that user to your bugzilla account watch list:

https://bugzilla.redhat.com/userprefs.cgi?tab=email
Watch user list -> add "bugs at ovirt.org"

Any email sent by bugzilla to that user will be also sent to you.

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


From sbonazzo at redhat.com  Fri Jan 17 08:51:12 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Fri, 17 Jan 2014 09:51:12 +0100
Subject: [QE] oVirt 3.3.3 beta / RC status
Message-ID: <52D8EF00.4010505@redhat.com>

Hi,
oVirt 3.3.3 beta has been released and is actually on QA.
We'll start composing oVirt 3.3.3 RC on 2014-01-21 12:00 UTC.

The bug tracker [1] shows no bugs blocking the release

The following is a list of the non-blocking bugs still open with target 3.3 - 3.3.3:

Whiteboard	Bug ID	Summary
integration	902979	ovirt-live - firefox doesn't trust the installed engine
integration	1021805	[RFE] oVirt Live - use motd to show the admin password
integration	1022440	[RFE] AIO - configure the AIO host to be a gluster cluster/host
integration	1026930	Package virtio-win and put it in ovirt repositories
integration	1026933	pre-populate ISO domain with virtio-win ISO
integration	1050084	Tracker: oVirt 3.3.3 release
network		997197	Some AppErrors messages are grammatically incorrect (singular vs plural)
node		906257	USB Flash Drive install of ovirt-node created via dd fails
node		923049	ovirt-node fails to boot from local disk under UEFI mode
node		965583	[RFE] add shortcut key on TUI
node		976675	[wiki] Update contribution page
node		979350	Changes admin password in the first time when log in is failed while finished auto-install
node		979390	[RFE] Split defaults.py into smaller pieces
node		982232	performance page takes >1sec to load (on first load)
node		984441	kdump page crashed before configuring the network after ovirt-node intalled
node		986285	UI crashes when no bond name is given
node		991267	[RFE] Add TUI information to log file.
node		1018374	ovirt-node-iso-3.0.1-1.0.2.vdsm.fc19: Failed on Auto-install
node		1018710	[RFE] Enhance API documentation
node		1032035	[RFE]re-write auto install function for the cim plugin
node		1033286	ovirt-node-plugin-vdsm can not be added to ovirt node el6 base image
storage		987917	[oVirt] [glance] API version not specified in provider dialog
virt		1007940	Cannot clone from snapshot while using GlusterFS as POSIX Storage Domain



Maintainers:
- We'll start composing oVirt 3.3.3 RC on 2014-01-21 12:00 UTC: all non blockers bug still open after the build will be moved to 3.3.4.
- Please add the bugs to the tracker if you think that 3.3.3 should not be released without them fixed.
- Please provide ETA on bugs you add as blockers
- Please re-target all bugs you don't think that should block 3.3.3.
- Please fill release notes, the page has been created here [3]
- Please remember to rebuild your packages before 2014-01-21 12:00 UTC if you want them to be included in 3.3.3 RC.

For those who want to help testing the bugs, I suggest to add yourself as QA contact for the bug and add yourself to the testing page [2].
Thanks to Gianluca Cecchi for his testing of oVirt 3.3.3 beta on Gluster storage!

[1] http://bugzilla.redhat.com/1050084
[2] http://www.ovirt.org/Testing/Ovirt_3.3.3_testing
[3] http://www.ovirt.org/OVirt_3.3.3_release_notes

Thanks,


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


From sbonazzo at redhat.com  Fri Jan 17 09:16:40 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Fri, 17 Jan 2014 10:16:40 +0100
Subject: [QE] oVirt 3.4.0 alpha / beta status
Message-ID: <52D8F4F8.2020204@redhat.com>

Hi,
oVirt 3.4.0 alpha has been released and is actually on QA.
An issue has been found in VDSM so we have updated the packages in alpha repositories for Fedora.
We had an issue with nightly build for EL6 packages yesterday so EL6 repository is not yet updated.
We'll try to sync it today, I'm sorry for the inconvenient.
We'll start composing oVirt 3.4.0 beta on 2014-01-20 14:00 UTC from 3.4 branches.

The bug tracker [1] shows the following bugs blocking the release:
Whiteboard	Bug ID	Summary
gluster		1038988	Gluster brick sync does not work when host has multiple interfaces
integration	1054080 gracefully warn about unsupported upgrade from legacy releases
network		1054195	[NetworkLabels] Attaching two labeled networks to a cluster result in failure of the latter


There are still 280 bugs [2] targeted to 3.4.0.
Excluding node and documentation bugs we still have 237 bugs [3] targeted to 3.4.0.
Please review them as soon as possible.

Maintainers:
- Please remember to rebuild your packages before 2014-01-21 12:00 UTC if you want them to be included in 3.4.0 beta.
- Please add the bugs to the tracker if you think that 3.4.0 should not be released without them fixed.
- Please provide ETA on blockers bugs
- Please update the target to 3.4.1 or any next release for bugs that won't be in 3.4.0:
  it will ease gathering the blocking bugs for next releases.
- Please fill release notes, the page has been created here [4]
- Please update http://www.ovirt.org/OVirt_3.4_TestDay before 2014-01-23


For those who want to help testing the bugs, I suggest to add yourself as QA contact for the bug.
Please also be prepared for upcoming oVirt 3.4.0 Test Day on 2014-01-23!
Thanks to all people already testing 3.4.0 alpha!

[1] https://bugzilla.redhat.com/1024889
[2] http://red.ht/1eIRZXM
[3] http://red.ht/1auBU3r
[4] http://www.ovirt.org/OVirt_3.4.0_release_notes

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


From gianluca.cecchi at gmail.com  Thu Jan 16 16:05:39 2014
From: gianluca.cecchi at gmail.com (Gianluca Cecchi)
Date: Thu, 16 Jan 2014 17:05:39 +0100
Subject: [Users] oVirt 3.3.3 beta is now available
In-Reply-To: <52D58E4B.50509@redhat.com>
References: <52D58E4B.50509@redhat.com>
Message-ID: <CAG2kNCy74EvP2KH0F2q2Fo5mPVLsicXdwipn3XzpXEugd35CDQ@mail.gmail.com>

On Tue, Jan 14, 2014 at 8:21 PM, Sandro Bonazzola <sbonazzo at redhat.com> wrote:
> The oVirt team is pleased to announce that the 3.3.3 Beta is now
> available in beta [1] repository for testing.

I would like to say that I was able to pass from 3.3.2 to 3.3.3beta1
without any downtime as far as VMs are concerned and my GlusterFS
based DC.
I also put my line inside wiki testing page.
My setup is composed by a fedora 19 server used as engine (actually a
vSphere VM) + 2 Fedora 19 server used as Hypervisors (BL685 G1
blades).
3 VMs configured: CentOS 5.10, CentOS 6.4, Fedora 20
Starting point is Fedora 19 with stable repo and a GlusterFS Datacenter.
Gluster version on the two nodes is 3.4.2-1.fc19 and I have set quorum
policy this way:

gluster volume set gvdata cluster.quorum-type none

This lets me maintain DC and VMs active also with only one host active
at a time.

Steps done:
- enable beta repo on engine
- engine-setup --> proposed to update ovirt-engine-setup package
- yum update ovirt-engine-setup
- engine-setup --> ok, downloaded new packages and setup
- 1 day test with new engine and keep hosts the same version
- migrate all 3 VMs to the currently SPM host (host2)
- put non SPM host1 in maintenance
- enable beta repo on host1
- stop vdsmd on host1 (possibly not necessary...)
- yum update on host1
- merge between /etc/vdsm/logger.conf and created .rpmnew
NOTE: in December I previously changed DEBUG entries to INFO in this file.
In 3.3.3 they are yet set to DEBUG, but there is a new entry for ha engine
-> it could be useful to put this note in release notes if one simply
updates host and doesn't redeploy it
(in this last case I don't know if a yum remove / yum install is made
or the same "problem" is present...)
In my case before merge this was the situation:
# diff logger.conf logger.conf.rpmnew
2c2
< keys=root,vds,Storage,metadata
---
> keys=root,vds,Storage,metadata,ovirt_hosted_engine_ha
11c11
< level=INFO
---
> level=DEBUG
16c16
< level=INFO
---
> level=DEBUG
22c22
< level=INFO
---
> level=DEBUG
32a33,38
> [logger_ovirt_hosted_engine_ha]
> level=ERROR
> handlers=
> qualname=ovirt_hosted_engine_ha
> propagate=1
>
43c49
< level=INFO
---
> level=DEBUG

So after the merge I have the new config file but with the INFO
settings instead of DEBUG.
- shutdown -r of host1
- activate host1 in webadmin gui
- migrate all 3 VMs to the new version host1
- some tests accessing consoles
- select host1 as SPM in webadmin gui before working on update for
host2; wait and see --> ok
- put host2 in maintenance
- enable beta repo on host2
- stop vdsmd on host2
- yum update on host2
- merge new /etc/vdsm/logger.conf
- shutdown -r of host2
- activate host2 in webadmin gui
- migrate all 3 VMs to the new version host2
- test access to consoles

Bye,
Gianluca


From andrew at andrewklau.com  Fri Jan 17 09:36:32 2014
From: andrew at andrewklau.com (andrew at andrewklau.com)
Date: Fri, 17 Jan 2014 09:36:32 +0000
Subject: =?utf-8?Q?Re:_[Users]_[QE]_oVirt_3.4.0_alpha_/_beta_status?=
In-Reply-To: <52D8F4F8.2020204@redhat.com>
References: <52D8F4F8.2020204@redhat.com>
Message-ID: <52d8f9ad.01f6420a.3a2e.ffffc569@mx.google.com>








Cheers,
Andrew





From: Sandro Bonazzola
Sent: ?Friday?, ?January? ?17?, ?2014 ?8?:?16? ?PM
To: arch, engine-devel, VDSM Project Development, users





Hi,
oVirt 3.4.0 alpha has been released and is actually on QA.
An issue has been found in VDSM so we have updated the packages in alpha repositories for Fedora.
We had an issue with nightly build for EL6 packages yesterday so EL6 repository is not yet updated.
We'll try to sync it today, I'm sorry for the inconvenient.
We'll start composing oVirt 3.4.0 beta on 2014-01-20 14:00 UTC from 3.4 branches.

The bug tracker [1] shows the following bugs blocking the release:
Whiteboard Bug ID Summary
gluster  1038988 Gluster brick sync does not work when host has multiple interfaces
integration 1054080 gracefully warn about unsupported upgrade from legacy releases
network  1054195 [NetworkLabels] Attaching two labeled networks to a cluster result in failure of the latter


There are still 280 bugs [2] targeted to 3.4.0.
Excluding node and documentation bugs we still have 237 bugs [3] targeted to 3.4.0.
Please review them as soon as possible.

Maintainers:
- Please remember to rebuild your packages before 2014-01-21 12:00 UTC if you want them to be included in 3.4.0 beta.
- Please add the bugs to the tracker if you think that 3.4.0 should not be released without them fixed.
- Please provide ETA on blockers bugs
- Please update the target to 3.4.1 or any next release for bugs that won't be in 3.4.0:
  it will ease gathering the blocking bugs for next releases.
- Please fill release notes, the page has been created here [4]
- Please update http://www.ovirt.org/OVirt_3.4_TestDay before 2014-01-23


For those who want to help testing the bugs, I suggest to add yourself as QA contact for the bug.
Please also be prepared for upcoming oVirt 3.4.0 Test Day on 2014-01-23!
Thanks to all people already testing 3.4.0 alpha!

[1] https://bugzilla.redhat.com/1024889
[2] http://red.ht/1eIRZXM
[3] http://red.ht/1auBU3r
[4] http://www.ovirt.org/OVirt_3.4.0_release_notes

-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
_______________________________________________
Users mailing list
Users at ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20140117/83873850/attachment.html>

From dneary at redhat.com  Fri Jan 17 13:54:25 2014
From: dneary at redhat.com (Dave Neary)
Date: Fri, 17 Jan 2014 14:54:25 +0100
Subject: Tip: staying informed for all oVirt bugs
Message-ID: <52D93611.9000903@redhat.com>

Hi all,

We recently created a "fictitious" Bugzilla user who is the QE contact
for oVirt bugs - bugs at ovirt.org

In Bugzilla, it is possible to get notifications of all changes to bugs
where this user is QE contact (which is usually all of them), by the
following procedure:

* Log into Bugzilla
* Click on "Preferences"
* Click on "Email Preferences"
* At the bottom of that page, add "bugs at ovirt.org" to the list of users
you are watching

You should now receive an email every time an oVirt bug is created, or
closed, or a comment is added.

Hope you find this helpful!

Cheers,
Dave.

-- 
Dave Neary - Community Action and Impact
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13


From sbonazzo at redhat.com  Fri Jan 17 14:33:57 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Fri, 17 Jan 2014 15:33:57 +0100
Subject: [Users] [QE] oVirt 3.4.0 alpha / beta status
In-Reply-To: <52D8F4F8.2020204@redhat.com>
References: <52D8F4F8.2020204@redhat.com>
Message-ID: <52D93F55.7080700@redhat.com>

Il 17/01/2014 10:16, Sandro Bonazzola ha scritto:
> Hi,
> oVirt 3.4.0 alpha has been released and is actually on QA.
> An issue has been found in VDSM so we have updated the packages in alpha repositories for Fedora.
> We had an issue with nightly build for EL6 packages yesterday so EL6 repository is not yet updated.
> We'll try to sync it today, I'm sorry for the inconvenient.

3.4.0 alpha repository has been refreshed also for EL6.


> We'll start composing oVirt 3.4.0 beta on 2014-01-20 14:00 UTC from 3.4 branches.
> 
> The bug tracker [1] shows the following bugs blocking the release:
> Whiteboard	Bug ID	Summary
> gluster		1038988	Gluster brick sync does not work when host has multiple interfaces
> integration	1054080 gracefully warn about unsupported upgrade from legacy releases
> network		1054195	[NetworkLabels] Attaching two labeled networks to a cluster result in failure of the latter
> 
> 
> There are still 280 bugs [2] targeted to 3.4.0.
> Excluding node and documentation bugs we still have 237 bugs [3] targeted to 3.4.0.
> Please review them as soon as possible.
> 
> Maintainers:
> - Please remember to rebuild your packages before 2014-01-21 12:00 UTC if you want them to be included in 3.4.0 beta.
> - Please add the bugs to the tracker if you think that 3.4.0 should not be released without them fixed.
> - Please provide ETA on blockers bugs
> - Please update the target to 3.4.1 or any next release for bugs that won't be in 3.4.0:
>   it will ease gathering the blocking bugs for next releases.
> - Please fill release notes, the page has been created here [4]
> - Please update http://www.ovirt.org/OVirt_3.4_TestDay before 2014-01-23
> 
> 
> For those who want to help testing the bugs, I suggest to add yourself as QA contact for the bug.
> Please also be prepared for upcoming oVirt 3.4.0 Test Day on 2014-01-23!
> Thanks to all people already testing 3.4.0 alpha!
> 
> [1] https://bugzilla.redhat.com/1024889
> [2] http://red.ht/1eIRZXM
> [3] http://red.ht/1auBU3r
> [4] http://www.ovirt.org/OVirt_3.4.0_release_notes
> 


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


From eedri at redhat.com  Sun Jan 19 10:01:03 2014
From: eedri at redhat.com (Eyal Edri)
Date: Sun, 19 Jan 2014 05:01:03 -0500 (EST)
Subject: proposal for moving nightly to 3.4 stabilization branch
In-Reply-To: <1765323159.7168679.1390124147330.JavaMail.root@redhat.com>
References: <52D7AFEA.4050700@redhat.com>
	<958542607.1128230.1389867132207.JavaMail.root@redhat.com>
	<52D7B158.1020801@redhat.com> <52D7B201.5020204@redhat.com>
	<708502818.1130869.1389868679351.JavaMail.root@redhat.com>
	<52D7C7CF.6060204@redhat.com> <52D801EE.7040907@redhat.com>
	<1765323159.7168679.1390124147330.JavaMail.root@redhat.com>
Message-ID: <352990545.3455849.1390125663426.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Kiril Nesenko" <knesenko at redhat.com>
> To: "Sandro Bonazzola" <sbonazzo at redhat.com>
> Cc: "arch" <arch at ovirt.org>, "infra" <infra at ovirt.org>
> Sent: Sunday, January 19, 2014 11:35:47 AM
> Subject: Re: proposal for moving nightly to 3.4 stabilization branch
> 
> 
> 
> ----- Original Message -----
> > From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> > To: "Itamar Heim" <iheim at redhat.com>, "Alon Bar-Lev" <alonbl at redhat.com>,
> > "David Caro" <dcaroest at redhat.com>
> > Cc: "arch" <arch at ovirt.org>, "infra" <infra at ovirt.org>
> > Sent: Thursday, January 16, 2014 5:59:42 PM
> > Subject: Re: proposal for moving nightly to 3.4 stabilization branch
> > 
> > Il 16/01/2014 12:51, Itamar Heim ha scritto:
> > > On 01/16/2014 12:37 PM, Alon Bar-Lev wrote:
> > >>
> > >>
> > >> ----- Original Message -----
> > >>> From: "David Caro" <dcaroest at redhat.com>
> > >>> To: "Sandro Bonazzola" <sbonazzo at redhat.com>
> > >>> Cc: "arch" <arch at ovirt.org>, "infra" <infra at ovirt.org>, "Alon Bar-Lev"
> > >>> <alonbl at redhat.com>
> > >>> Sent: Thursday, January 16, 2014 12:18:41 PM
> > >>> Subject: Re: proposal for moving nightly to 3.4 stabilization branch
> > >>>
> > >>> El jue 16 ene 2014 11:15:52 CET, Sandro Bonazzola escribi?:
> > >>>> Il 16/01/2014 11:12, Alon Bar-Lev ha scritto:
> > >>>>>
> > >>>>>
> > >>>>> ----- Original Message -----
> > >>>>>> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> > >>>>>> To: "infra" <infra at ovirt.org>, "arch" <arch at ovirt.org>
> > >>>>>> Sent: Thursday, January 16, 2014 12:09:46 PM
> > >>>>>> Subject: proposal for moving nightly to 3.4 stabilization branch
> > >>>>>>
> > >>>>>> Hi,
> > >>>>>> since it seems not possible to have both master and 3.4 nightly
> > >>>>>> builds, I
> > >>>>>> suggest to move nightly to 3.4 branches.
> > >>>>>> At this stage nobody really needs master nightly, while 3.4.0
> > >>>>>> branches
> > >>>>>> nightly will be more useful.
> > >>>>>
> > >>>>> Why is that?
> > >>>>>
> > >>>>> Kiril is working on splitting repo per version, so you have multiple
> > >>>>> nightly.
> > >>>>
> > >>>> nightly requires 6GB of disk space and we have just 3GB left there.
> > >>>> We're short on resources for having multiple nightlies right now.
> > >>>
> > >>> I correct myself, right now nightly takes ~3GB of space. I can try to
> > >>> make some space, but if the repo size increases a little we'll run out
> > >>> f space there.
> > >>
> > >> if nobody will test master then we will be in big problem when trying to
> > >> stabilize it.
> > > 
> > > agree - we need master tested and we should have nightlies on it as well
> > 
> > We'll need more storage then...
> 
> Agree.

we tried doing that with adding storage to rackspace, but we hit a wall there with various ticket problems
regarding firewall issues and other restrictions which forced us to look for other alternatives.

i'm still trying to think on how best configuration on softlayer going forward, with a dedicated storage server,
that might solve the issue, but that could take a while.

meantime, i think the simplest solution is just to increase space on resourcs.ovirt.org or to move the gerrit backups (9.5GB)
somewhere else.

> 
> > Just to understand how much we need and if we can gather it, how many
> > nightly
> > has to be taken for allowing rollback?
> > just latest and previous?
> > Ignore rollback and just keep latest?
> 
> Currently we planned to have nightly for each version:
> 
> ovirt-<version>-snapshot - for nightly builds
> ovirt-snapshot - master nightly
> ovirt-<version> - released version
> 
> 
> So we need some more space to handle that. To avoid RPM dups on the
> filesystem, we can create
>  a root directory to save RPMs there and use hardlinks. For example:
> 
> Packages-<version> -
>                    |
>                     - rpm1, rpm2 ...
> 
> and link rpms from ovirt-<version>-snapshot and ovirt-<version> to
> Packages-<version>.
> 
> In that way you will avoid dup rpms.

this will surely help as well +1
and the refactoring of the cleanup script for deleting old nighthly rpms also.

> 
> Kiril
> > 
> > 
> > > 
> > >>
> > >>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> --
> > >>>>>> Sandro Bonazzola
> > >>>>>> Better technology. Faster innovation. Powered by community
> > >>>>>> collaboration.
> > >>>>>> See how it works at redhat.com
> > >>>>>> _______________________________________________
> > >>>>>> Arch mailing list
> > >>>>>> Arch at ovirt.org
> > >>>>>> http://lists.ovirt.org/mailman/listinfo/arch
> > >>>>>>
> > >>>>
> > >>>>
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> David Caro
> > >>>
> > >>> Red Hat S.L.
> > >>> Continuous Integration Engineer - EMEA ENG Virtualization R&D
> > >>>
> > >>> Email: dcaro at redhat.com
> > >>> Web: www.redhat.com
> > >>> RHT Global #: 82-62605
> > >>>
> > >>>
> > >> _______________________________________________
> > >> Arch mailing list
> > >> Arch at ovirt.org
> > >> http://lists.ovirt.org/mailman/listinfo/arch
> > >>
> > > 
> > > _______________________________________________
> > > Infra mailing list
> > > Infra at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/infra
> > 
> > 
> > --
> > Sandro Bonazzola
> > Better technology. Faster innovation. Powered by community collaboration.
> > See how it works at redhat.com
> > _______________________________________________
> > Infra mailing list
> > Infra at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
> > 
> _______________________________________________
> Infra mailing list
> Infra at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
> 


From invite at bluejeans.com  Tue Jan 21 11:36:49 2014
From: invite at bluejeans.com (Shubhendu Tripathi via Blue Jeans Network)
Date: Tue, 21 Jan 2014 11:36:49 +0000 (UTC)
Subject: Feature Review: Gluster Volume Snapshots
Message-ID: <1798685696.751390304209581.JavaMail.denimuser@sj1-app-01-12>

Shubhendu Ram Tripathi (shtripat at redhat.com) has invited you to a video meeting.



Meeting Title:
Feature Review: Gluster Volume Snapshots

Meeting Time:
Monday January 27, 2014 6:30 p.m. IST / 1 hr

************************************************

To join or start the meeting, go to:
https://bluejeans.com/298626980/6439?g=mfzgg2can53gs4tufzxxezy=


No Computer or Internet Connection?

Join via phone:
1) Dial-in phone number: +1 408 740 7256 or +1 888 240 2560 (US or Canada only)  (http://bluejeans.com/numbers)
2) Enter Conference ID: 298626980
3) Enter Participant PIN: 6439

Join via room system:
1) Dial-in IP: 199.48.152.152 or bjn.vc
2) Enter Meeting ID: 298626980
3) Enter Participant passcode: 6439

************************************************

First time joining a Blue Jeans Video Meeting?
http://bluejeans.com/faq#connecting

************************************************

Want to test your video connection?
http://bluejeans.com/111

************************************************

Blue Jeans Network 2012
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20140121/23f07657/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 1790 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20140121/23f07657/attachment.ics>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: invite.ics
Type: application/ics
Size: 1790 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20140121/23f07657/attachment.bin>

From shtripat at redhat.com  Tue Jan 21 11:40:04 2014
From: shtripat at redhat.com (Shubhendu Tripathi)
Date: Tue, 21 Jan 2014 06:40:04 -0500 (EST)
Subject: Feature Review: Gluster Volume Snapshot
Message-ID: <2085714992.4459754.1390304404610.JavaMail.root@redhat.com>

The following is a new meeting request:

Subject: Feature Review: Gluster Volume Snapshot 
Organizer: "Shubhendu Tripathi" <shtripat at redhat.com> 

Location: "Vijayanagara - BLR" <vijayanagara-blr at redhat.com> 
Resources: "Vijayanagara - BLR" <vijayanagara-blr at redhat.com> 
Time: Monday, January 27, 2014, 6:30:00 PM - 7:30:00 PM GMT +05:30 Chennai, Kolkata, Mumbai, New Delhi
 
Invitees: arch at ovirt.org; users at ovirt.org 


*~*~*~*~*~*~*~*~*~*

Hi,

In this talk I intend to present a short overview of the feature Gluster Volume Snapshots in oVirt.

BlueJeans session details:
https://bluejeans.com/298626980/6439/browser

WIKI Page:
http://www.ovirt.org/Features/GlusterVolumeSnapshots

Call bridge details:
Would be shared separately.

Thanks and Regards,
Shubhendu Tripathi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: meeting.ics
Type: text/calendar
Size: 1943 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20140121/dd6b52e1/attachment.ics>

From sbonazzo at redhat.com  Wed Jan 22 09:40:33 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Wed, 22 Jan 2014 10:40:33 +0100
Subject: Proposal for dropping packages from ovirt rpm repositories
Message-ID: <52DF9211.9030409@redhat.com>

Hi,
I think that having the same package on different repositories must be avoided.

The last python-cpopen-1.3 release broke repository closure of ovirt-stable which provides a vdsm release still requiring vdsm-python-cpopen.
I think that since vdsm and other packages are delivered in Fedora repositories we should not deliver them in ovirt repositories.
An example is:
https://bugzilla.redhat.com/show_bug.cgi?id=1056470
https://bugzilla.redhat.com/show_bug.cgi?id=1056464

python-cpopen affects both Fedora and oVirt repositories, hitting 2 different products.
but other packages are handled as vdsm.
So i suggest to keep just .tar.gz files on ovirt site for allowing fedora packagers to build referencing the source tarball and drop at all any
package already provided by Fedora from ovirt site.

Comments as always are welcome.


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


From alonbl at redhat.com  Wed Jan 22 10:00:17 2014
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Wed, 22 Jan 2014 05:00:17 -0500 (EST)
Subject: Proposal for dropping packages from ovirt rpm repositories
In-Reply-To: <52DF9211.9030409@redhat.com>
References: <52DF9211.9030409@redhat.com>
Message-ID: <1894960416.2795233.1390384817868.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> To: "arch" <arch at ovirt.org>, "infra" <infra at ovirt.org>
> Cc: "Kiril Nesenko" <knesenko at redhat.com>, "Ohad Basan" <obasan at redhat.com>
> Sent: Wednesday, January 22, 2014 11:40:33 AM
> Subject: Proposal for dropping packages from ovirt rpm repositories
> 
> Hi,
> I think that having the same package on different repositories must be
> avoided.
> 
> The last python-cpopen-1.3 release broke repository closure of ovirt-stable
> which provides a vdsm release still requiring vdsm-python-cpopen.
> I think that since vdsm and other packages are delivered in Fedora
> repositories we should not deliver them in ovirt repositories.
> An example is:
> https://bugzilla.redhat.com/show_bug.cgi?id=1056470
> https://bugzilla.redhat.com/show_bug.cgi?id=1056464
> 
> python-cpopen affects both Fedora and oVirt repositories, hitting 2 different
> products.
> but other packages are handled as vdsm.
> So i suggest to keep just .tar.gz files on ovirt site for allowing fedora
> packagers to build referencing the source tarball and drop at all any
> package already provided by Fedora from ovirt site.
> 
> Comments as always are welcome.

We should build pre-release as fedora will wait for release, and we might depend on pre-release for our own pre-releases right?

Also, if we are not the ones that control the fedora packaging, then we probably need to provide even release until fedora adds to their repo.

Maybe these components should go into different non ovirt repositories that can be easily disabled? even one per such package?

If this is the only example and it is quite static, then no need to invest any resource... just remove it.

Alon


From sbonazzo at redhat.com  Wed Jan 22 10:56:19 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Wed, 22 Jan 2014 11:56:19 +0100
Subject: oVirt 3.4.0 beta is now available
Message-ID: <52DFA3D3.9030003@redhat.com>

The oVirt team is pleased to announce that the 3.4.0 Release is now available in beta for testing.

Release notes and information on the changes for this update are still being worked on and will be available soon on the wiki[1].
Please ensure to follow install instruction from release notes if you're going to test it.
A new repository ovirt-3.4.0-prerelease has been added for delivering this beta and future refreshes until release candidate.

A new oVirt Node build will be available soon as well.

You're welcome to join us testing this beta release in tomorrow test day [2]!


[1] http://www.ovirt.org/OVirt_3.4.0_release_notes
[2] http://www.ovirt.org/OVirt_3.4_Test_Day

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


From sbonazzo at redhat.com  Wed Jan 22 11:20:40 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Wed, 22 Jan 2014 12:20:40 +0100
Subject: oVirt 3.3.3 Release Candidate is now available
Message-ID: <52DFA988.3050106@redhat.com>

The oVirt team is pleased to announce that the 3.3.3 Release Candidate is now
available in ovirt-updates-testing [1].

Feel free to join us testing it[2] and verifying the bugzilla entries actually
under verification [3].

Release notes for this update are available on the wiki [4].

A new oVirt Node build will be available soon as well.

[1] http://resources.ovirt.org/releases/updates-testing
[2] http://www.ovirt.org/Testing/Ovirt_3.3.3_testing
[3] http://red.ht/KEesdK
[4] http://www.ovirt.org/OVirt_3.3.3_release_notes

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


From sbonazzo at redhat.com  Wed Jan 22 13:07:23 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Wed, 22 Jan 2014 14:07:23 +0100
Subject: [ANN] oVirt 3.4.0 Test Day - Tomorrow Jan 23th
Message-ID: <52DFC28B.7060709@redhat.com>

Hi all,
tomorrow Jan 23th we'll have oVirt 3.4.0 test day.

On this day all relevant engineers will be online ready to support
any issues you find during install / operating this new release.

Just make sure you have 1 hosts or more to test drive the new release.
If you're curious to see how it works, this is your chance.

Thanks again for everyone who will join us tomorrow!

Location
    #ovirt irc channel
    Please communicate here to allow others to see any issues

What
    In this test day you have a license to kill ;)
    Follow the documentation to setup your environment, and test drive the new features.
    Please remember we expect to see some issues, and anything you come up with will save a you when you'll install final release
    Remember to try daily tasks you'd usually do in the engine, to see there are no regressions.
    Write down the configuration you used (HW, console, etc) in the report etherpad[1].

Documentation
    Release notes: http://www.ovirt.org/OVirt_3.4.0_release_notes
    Features pages links: http://bit.ly/17qBn6F
    If you find errors in the wiki please annotate it as well in report etherpad [1]

Prerequisites / recommendations
    Use CentOS or RHEL 6.5 only. 6.4 is unsupported due to various issues (sanlock, libvirt, etc).
    Use Fedora 19 only. Fedora 20 is unsupported due to various issues (sos, jboss).

Latest RPMs
    repository to be enabled for testing the release are listed in the release notes page [2].

NEW issues / reports
    For any new issue, please update the reports etherpad [1]

Feature owners, please make sure:
    your feature is updated and referenced on release page [2].
    you have testing instruction for your feature either on test day page [3] or in your feature page.
    your team regression testing section is organized and up to date on test day page [3].


[1] http://etherpad.ovirt.org/p/3.4-testday-1
[2] http://www.ovirt.org/OVirt_3.4.0_release_notes
[3] http://www.ovirt.org/OVirt_3.4_Test_Day


Thanks.

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


From danken at redhat.com  Wed Jan 22 13:57:31 2014
From: danken at redhat.com (Dan Kenigsberg)
Date: Wed, 22 Jan 2014 13:57:31 +0000
Subject: Proposal for dropping packages from ovirt rpm repositories
In-Reply-To: <52DF9211.9030409@redhat.com>
References: <52DF9211.9030409@redhat.com>
Message-ID: <20140122135731.GD10344@redhat.com>

On Wed, Jan 22, 2014 at 10:40:33AM +0100, Sandro Bonazzola wrote:
> Hi,
> I think that having the same package on different repositories must be avoided.
> 
> The last python-cpopen-1.3 release broke repository closure of ovirt-stable which provides a vdsm release still requiring vdsm-python-cpopen.
> I think that since vdsm and other packages are delivered in Fedora repositories we should not deliver them in ovirt repositories.
> An example is:
> https://bugzilla.redhat.com/show_bug.cgi?id=1056470
> https://bugzilla.redhat.com/show_bug.cgi?id=1056464
> 
> python-cpopen affects both Fedora and oVirt repositories, hitting 2 different products.
> but other packages are handled as vdsm.
> So i suggest to keep just .tar.gz files on ovirt site for allowing fedora packagers to build referencing the source tarball and drop at all any
> package already provided by Fedora from ovirt site.
> 
> Comments as always are welcome.

Only problem with this is that epel would not agree to ship the el6
build of rpm - we'd need to carry it on our own.

Dan.


From sbonazzo at redhat.com  Wed Jan 22 14:11:38 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Wed, 22 Jan 2014 15:11:38 +0100
Subject: Proposal for dropping packages from ovirt rpm repositories
In-Reply-To: <20140122135731.GD10344@redhat.com>
References: <52DF9211.9030409@redhat.com> <20140122135731.GD10344@redhat.com>
Message-ID: <52DFD19A.4090108@redhat.com>

Il 22/01/2014 14:57, Dan Kenigsberg ha scritto:
> On Wed, Jan 22, 2014 at 10:40:33AM +0100, Sandro Bonazzola wrote:
>> Hi,
>> I think that having the same package on different repositories must be avoided.
>>
>> The last python-cpopen-1.3 release broke repository closure of ovirt-stable which provides a vdsm release still requiring vdsm-python-cpopen.
>> I think that since vdsm and other packages are delivered in Fedora repositories we should not deliver them in ovirt repositories.
>> An example is:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1056470
>> https://bugzilla.redhat.com/show_bug.cgi?id=1056464
>>
>> python-cpopen affects both Fedora and oVirt repositories, hitting 2 different products.
>> but other packages are handled as vdsm.
>> So i suggest to keep just .tar.gz files on ovirt site for allowing fedora packagers to build referencing the source tarball and drop at all any
>> package already provided by Fedora from ovirt site.
>>
>> Comments as always are welcome.
> 
> Only problem with this is that epel would not agree to ship the el6
> build of rpm - we'd need to carry it on our own.

with epel we won't have duplicates in different repos

> 
> Dan.
> 


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


From rnachimu at redhat.com  Thu Jan 23 06:45:29 2014
From: rnachimu at redhat.com (Ramesh Nachimuthu)
Date: Thu, 23 Jan 2014 01:45:29 -0500 (EST)
Subject: [ANN] oVirt 3.4.0 Test Day - Tomorrow Jan 23th
In-Reply-To: <52DFC28B.7060709@redhat.com>
References: <52DFC28B.7060709@redhat.com>
Message-ID: <1204943240.4430760.1390459529275.JavaMail.root@redhat.com>

Hi,

   After adding the node to engine, it goes to non operational state with the error "Host 10.70.43.160 is compatible with versions (3.0,3.1,3.2,3.3) and cannot join Cluster Default which is set to version 3.4.". 

I have enabled the repo http://resources.ovirt.org/releases/3.4.0_pre/rpm/Fedora/$releasever/ in host. 

  Following is the vdsm version installed in F19 node:

[root at localhost ~]# rpm -qa | grep vdsm
vdsm-cli-4.14.1-2.fc19.noarch
vdsm-4.14.1-2.fc19.x86_64
vdsm-python-4.14.1-2.fc19.x86_64
vdsm-python-zombiereaper-4.14.1-2.fc19.noarch
vdsm-xmlrpc-4.14.1-2.fc19.noarch
vdsm-gluster-4.14.1-2.fc19.noarch


[root at localhost ~]# vdsClient -s 0 getVdsCaps
	clusterLevels = ['3.0', '3.1', '3.2', '3.3']

Anything I am missing here?


Regards,
Ramesh
----- Original Message -----
From: "Sandro Bonazzola" <sbonazzo at redhat.com>
To: "arch" <arch at ovirt.org>, "engine-devel" <engine-devel at ovirt.org>, Users at ovirt.org
Sent: Wednesday, January 22, 2014 6:37:23 PM
Subject: [ANN] oVirt 3.4.0 Test Day - Tomorrow Jan 23th

Hi all,
tomorrow Jan 23th we'll have oVirt 3.4.0 test day.

On this day all relevant engineers will be online ready to support
any issues you find during install / operating this new release.

Just make sure you have 1 hosts or more to test drive the new release.
If you're curious to see how it works, this is your chance.

Thanks again for everyone who will join us tomorrow!

Location
    #ovirt irc channel
    Please communicate here to allow others to see any issues

What
    In this test day you have a license to kill ;)
    Follow the documentation to setup your environment, and test drive the new features.
    Please remember we expect to see some issues, and anything you come up with will save a you when you'll install final release
    Remember to try daily tasks you'd usually do in the engine, to see there are no regressions.
    Write down the configuration you used (HW, console, etc) in the report etherpad[1].

Documentation
    Release notes: http://www.ovirt.org/OVirt_3.4.0_release_notes
    Features pages links: http://bit.ly/17qBn6F
    If you find errors in the wiki please annotate it as well in report etherpad [1]

Prerequisites / recommendations
    Use CentOS or RHEL 6.5 only. 6.4 is unsupported due to various issues (sanlock, libvirt, etc).
    Use Fedora 19 only. Fedora 20 is unsupported due to various issues (sos, jboss).

Latest RPMs
    repository to be enabled for testing the release are listed in the release notes page [2].

NEW issues / reports
    For any new issue, please update the reports etherpad [1]

Feature owners, please make sure:
    your feature is updated and referenced on release page [2].
    you have testing instruction for your feature either on test day page [3] or in your feature page.
    your team regression testing section is organized and up to date on test day page [3].


[1] http://etherpad.ovirt.org/p/3.4-testday-1
[2] http://www.ovirt.org/OVirt_3.4.0_release_notes
[3] http://www.ovirt.org/OVirt_3.4_Test_Day


Thanks.

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


From fabiand at redhat.com  Thu Jan 23 09:48:34 2014
From: fabiand at redhat.com (Fabian Deutsch)
Date: Thu, 23 Jan 2014 10:48:34 +0100
Subject: [Users] [ANN] oVirt 3.4.0 Test Day - Tomorrow Jan 23th -- oVirt
	Node ISO for the Test Day
In-Reply-To: <52DFC28B.7060709@redhat.com>
References: <52DFC28B.7060709@redhat.com>
Message-ID: <1390470514.3029.9.camel@fdeutsch-laptop.local>

Am Mittwoch, den 22.01.2014, 14:07 +0100 schrieb Sandro Bonazzola:
> Latest RPMs
>     repository to be enabled for testing the release are listed in the
> release notes page [2].

Hey,

the following oVirt Node ISO (based on CentOS 6.5 and oVirt 3.4
components) can be used for the Test Day:
http://fedorapeople.org/~fabiand/node/3.0.4/ovirt-node-iso-3.0.4-TestDay.vdsm.el6.iso

Important: You need to append enforcing=0 to the kernel when booting the
ISO to prevent SELinux denials.

Please provide your audit.log after the Test Day by replying to this
email.

Greetings
fabian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20140123/65c8d749/attachment.sig>

From sbonazzo at redhat.com  Fri Jan 24 12:13:29 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Fri, 24 Jan 2014 13:13:29 +0100
Subject: [Engine-devel] [ANN] oVirt 3.4.0 Test Day - Tomorrow Jan 23th
In-Reply-To: <52DFC28B.7060709@redhat.com>
References: <52DFC28B.7060709@redhat.com>
Message-ID: <52E258E9.8030206@redhat.com>

Il 22/01/2014 14:07, Sandro Bonazzola ha scritto:
> Hi all,
> tomorrow Jan 23th we'll have oVirt 3.4.0 test day.


Hi all,
   Just wanted to say a big THANK YOU to all participants!


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


From dneary at redhat.com  Fri Jan 24 08:20:24 2014
From: dneary at redhat.com (Dave Neary)
Date: Fri, 24 Jan 2014 09:20:24 +0100
Subject: Tip: staying informed for all oVirt bugs
In-Reply-To: <52D93611.9000903@redhat.com>
References: <52D93611.9000903@redhat.com>
Message-ID: <52E22248.4060202@redhat.com>

Hi again,

As any of you who followed this advice have noticed, Bugzilla can
generate a *lot* of traffic!

If you would like to add a mail filter, as I have, to channel BZ mail
into a separate folder, you should add a filter like this:

Header: X-Bugzilla-Watch-Reason
Value contains: bugs at ovirt.org

This will allow you to filter email related to following bugs at ovirt.org
without affecting bugs where you are asigned, CCed or otherwise want to
pay special attention.

Hope this is helpful!
Dave.

On 01/17/2014 02:54 PM, Dave Neary wrote:
> Hi all,
> 
> We recently created a "fictitious" Bugzilla user who is the QE contact
> for oVirt bugs - bugs at ovirt.org
> 
> In Bugzilla, it is possible to get notifications of all changes to bugs
> where this user is QE contact (which is usually all of them), by the
> following procedure:
> 
> * Log into Bugzilla
> * Click on "Preferences"
> * Click on "Email Preferences"
> * At the bottom of that page, add "bugs at ovirt.org" to the list of users
> you are watching
> 
> You should now receive an email every time an oVirt bug is created, or
> closed, or a comment is added.
> 
> Hope you find this helpful!
> 
> Cheers,
> Dave.
> 

-- 
Dave Neary - Community Action and Impact
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13


From shtripat at redhat.com  Mon Jan 27 05:43:37 2014
From: shtripat at redhat.com (Shubhendu Tripathi)
Date: Mon, 27 Jan 2014 00:43:37 -0500 (EST)
Subject: Cancelled: Feature Review: Gluster Volume Snapshot
Message-ID: <471768463.8859060.1390801417196.JavaMail.root@redhat.com>

The following meeting has been cancelled:

Subject: Feature Review: Gluster Volume Snapshot 
Organizer: "Shubhendu Tripathi" <shtripat at redhat.com> 

Location: "Vijayanagara - BLR" <vijayanagara-blr at redhat.com> 
Resources: "Vijayanagara - BLR" <vijayanagara-blr at redhat.com> (Vijayanagara - BLR) 
Time: Monday, January 27, 2014, 6:30:00 PM - 7:30:00 PM GMT +05:30 Chennai, Kolkata, Mumbai, New Delhi
 
Invitees: arch at ovirt.org; users at ovirt.org; rnachimu at redhat.com; don at techcetera.com; otavio.ferranti at eldorado.org.br; lucas.lima at suinfra.ufrgs.br; pagupta at redhat.com; ehildesh at redhat.com; srevivo at redhat.com; Karli.Sjoberg at slu.se; pportant at redhat.com ... 


*~*~*~*~*~*~*~*~*~*

Hi,

The meeting is cancelled as the feature is being dropped from the current release because of other high priority features being taken up.
Extremely sorry for the last moment cancellation.

Will schedule the feature review later once we take up this feature.

Thanks and Regards,
Shubhendu Tripathi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: meeting.ics
Type: text/calendar
Size: 3150 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20140127/9badbcf3/attachment.ics>

From invite at bluejeans.com  Mon Jan 27 05:46:15 2014
From: invite at bluejeans.com (Blue Jeans Network)
Date: Mon, 27 Jan 2014 05:46:15 +0000 (UTC)
Subject: CANCELED: Feature Review: Gluster Volume Snapshots
Message-ID: <913546592.2831390801575723.JavaMail.denimuser@sj1-app-01-13>

Shubhendu Ram Tripathi (shtripat at redhat.com) has cancelled the following meeting:

Meeting Title: Feature Review: Gluster Volume Snapshots
Meeting Time: Monday January 27, 2014 6:30 p.m. IST / 1 hr

************************************************

Message/Description: Cancelled


************************************************

Blue Jeans Network 2012
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20140127/e002d018/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 1042 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20140127/e002d018/attachment.ics>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: invite.ics
Type: application/ics
Size: 1042 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20140127/e002d018/attachment.bin>

From sbonazzo at redhat.com  Mon Jan 27 14:00:44 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Mon, 27 Jan 2014 15:00:44 +0100
Subject: Bug status
Message-ID: <52E6668C.7070603@redhat.com>

Hi maintainers,
since there's no automation in place for moving bz from MODIFIED to ON_QA
when we build a new release, please remember to take care of your bz and move them to ON_QA when you build
your packages for beta / rc testing.
I can just move to ON_QA bz moved to MODIFIED before yum repository composition but it's not a good way to go.
Thanks,

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


From sbonazzo at redhat.com  Tue Jan 28 12:55:43 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Tue, 28 Jan 2014 13:55:43 +0100
Subject: ovirt-3.3.3 release postponed due to blockers
Message-ID: <52E7A8CF.6040301@redhat.com>

Hi,
oVirt 3.3.3 release need to be postponed.
A recent release of python-cpopen-1.3 is breaking dependency resolution on EL6 and F19 so vdsm can't be installed and node can't be composed.
A recent change in vdsm-python-cpopen added the needed conflict against python-cpopen and removed Provides / Obsoletes on python-cpopen.
But no new releases of python-cpopen is available fixing the correct Provides / Obsoletes pair.

oVirt 3.3.2 / stable is affected too.

Please fix
Bug 1056470 - python-cpopen-1.3 is not providing obsoleted package.
Bug 1056464 - python-cpopen-1.3 is not providing obsoleted package.
ASAP.


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


From nsoffer at redhat.com  Wed Jan 29 14:03:30 2014
From: nsoffer at redhat.com (Nir Soffer)
Date: Wed, 29 Jan 2014 09:03:30 -0500 (EST)
Subject: No mail notifivations when ovirt wiki pages are changed
In-Reply-To: <880935251.6832835.1391004178503.JavaMail.root@redhat.com>
Message-ID: <129027358.6832946.1391004210721.JavaMail.root@redhat.com>

----- Original Message -----
> From: "Dave Neary" <dneary at redhat.com>
> To: "Nir Soffer" <nsoffer at redhat.com>, infra at ovirt.org
> Sent: Wednesday, January 29, 2014 3:42:28 PM
> Subject: Re: No mail notifivations when ovirt wiki pages are changed
>
> Hi Nir,
>
> I resolved this some time ago, can you check that it works now? If not,
> please check your email preferences to make sure you've checked "E-mail
> me when a page or file on my watchlist is changed".

If found that these email preferences were disabled on my account:

 Enable e-mail from other users
          E-mail me when a page or file on my watchlist is changed
          E-mail me when my user talk page is changed
          E-mail me also for minor edits of pages and files

So this seems to be a problem of bad defaults. Since most people
do not look for these defaults, and even more people keep the defaults,
there is little chance that people will get mail when page change.

I think that the best thing would be to tell the mailing list
about these options.

http://www.ovirt.org/Special:Preferences#mw-prefsection-personal

Then, we should change the defaults if possible, so new accounts will
automatically receive email notifications when pages change.

Finally, if possible, it would be a good idea to enable these settings
automatically for everyone. Maybe consult with the mailing list about
that.

Thanks,
Nir


From sbonazzo at redhat.com  Fri Jan 31 08:36:48 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Fri, 31 Jan 2014 09:36:48 +0100
Subject: [Users] ovirt-3.3.3 release postponed due to blockers
In-Reply-To: <20140130163805.535ec676@ispx.vb.futz.org>
References: <52E7A8CF.6040301@redhat.com>	<CAN0oX1YhD5kNOEYTP9jynOx3od_oDN1=+UwZ_KCu66_OUd9eSg@mail.gmail.com>	<52E8BA32.7060600@mittwald.de>	<52E8BA86.8090300@redhat.com>	<52EA12DD.30500@mittwald.de>	<20140130092021.GC26360@redhat.com>	<52EA1B06.2000106@redhat.com>	<20140130140212.GF26360@redhat.com>	<2035318599.4883138.1391094839988.JavaMail.root@redhat.com>	<52EA6F3B.9070701@redhat.com>
	<20140130163805.535ec676@ispx.vb.futz.org>
Message-ID: <52EB60A0.5040500@redhat.com>

Il 30/01/2014 22:38, Robert Story ha scritto:
> Can we revert these packages to previous versions in the 3.3.2 stable repo
> so those of us who want/need to install new hosts in our clusters aren't
> dead in the water waiting for 3.3.3?

Hi Robert, I think you can still install 3.3.2 on your clusters with the requirement of adding
manually oython-cpopen before trying to install vdsm.

About 3.3.3, I think vdsm should really drop dependency on vdsm-python-cpopen:
it's a package obsoleted by python-cpopen so there's no point in still requiring it especially if keeping that requirement still break dependency
resolution.


> 
> On Thu, 30 Jan 2014 16:26:51 +0100 Sandro wrote:
> SB> Il 30/01/2014 16:13, Yaniv Bronheim ha scritto:
> SB> > Hey, 
> SB> > 
> SB> > we found this yum bug and still struggling with more issuing
> SB> > according to the relation between those packages 
> SB> > 
> SB> > if we drop vdsm-python-cpopen the requirement in vdsm takes
> SB> > python-cpopen instead. in python-cpopen we have the same code base
> SB> > and it provides all vdsm-ptyhon-cpopen provides, so shouldn't be any
> SB> > issues with dropping it from the repository
> SB> > 
> SB> > is it possible to ship 3.3.3 release that way ? we don't need to
> SB> > change the requirement in the code, if python-cpopen 1.3-1 is part of
> SB> > the release, it will be taken by vdsm spec (tried with vdsm 4.13.3-2
> SB> > with the available cpopen 1.3-1)
> SB> > 
> SB> 
> SB> I can't release 3.3.3 that way.
> SB> We're keeping rolling releases on stable repository so if I don't
> SB> provide 4.13.3-2, previous one will still be available.
> 
> 
> Robert
> 
> --
> Senior Software Engineer @ Parsons
> 


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


From danken at redhat.com  Fri Jan 31 10:17:44 2014
From: danken at redhat.com (Dan Kenigsberg)
Date: Fri, 31 Jan 2014 10:17:44 +0000
Subject: [Users] ovirt-3.3.3 release postponed due to blockers
In-Reply-To: <52EB60A0.5040500@redhat.com>
References: <52E8BA32.7060600@mittwald.de> <52E8BA86.8090300@redhat.com>
	<52EA12DD.30500@mittwald.de> <20140130092021.GC26360@redhat.com>
	<52EA1B06.2000106@redhat.com> <20140130140212.GF26360@redhat.com>
	<2035318599.4883138.1391094839988.JavaMail.root@redhat.com>
	<52EA6F3B.9070701@redhat.com>
	<20140130163805.535ec676@ispx.vb.futz.org>
	<52EB60A0.5040500@redhat.com>
Message-ID: <20140131101743.GB9811@redhat.com>

On Fri, Jan 31, 2014 at 09:36:48AM +0100, Sandro Bonazzola wrote:
> Il 30/01/2014 22:38, Robert Story ha scritto:
> > Can we revert these packages to previous versions in the 3.3.2 stable repo
> > so those of us who want/need to install new hosts in our clusters aren't
> > dead in the water waiting for 3.3.3?
> 
> Hi Robert, I think you can still install 3.3.2 on your clusters with the requirement of adding
> manually oython-cpopen before trying to install vdsm.
> 
> About 3.3.3, I think vdsm should really drop dependency on vdsm-python-cpopen:
> it's a package obsoleted by python-cpopen so there's no point in still requiring it especially if keeping that requirement still break dependency
> resolution.

I really wanted to avoid eliminating a subpackage during a micro
release. That's impolite and surprising.
But given the awkward yum bug, persistent dependency problems, and
the current release delay, I give up.

Let's eliminate vdsm-python-cpopen from ovirt-3.3 branch, and require
python-cpopen. Yaniv, Douglas: could you handle it?


From sbonazzo at redhat.com  Fri Jan 31 10:43:42 2014
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Fri, 31 Jan 2014 11:43:42 +0100
Subject: [Users] ovirt-3.3.3 release postponed due to blockers
In-Reply-To: <20140131101743.GB9811@redhat.com>
References: <52E8BA32.7060600@mittwald.de> <52E8BA86.8090300@redhat.com>
	<52EA12DD.30500@mittwald.de> <20140130092021.GC26360@redhat.com>
	<52EA1B06.2000106@redhat.com> <20140130140212.GF26360@redhat.com>
	<2035318599.4883138.1391094839988.JavaMail.root@redhat.com>
	<52EA6F3B.9070701@redhat.com>
	<20140130163805.535ec676@ispx.vb.futz.org>
	<52EB60A0.5040500@redhat.com> <20140131101743.GB9811@redhat.com>
Message-ID: <52EB7E5E.5060303@redhat.com>

Il 31/01/2014 11:17, Dan Kenigsberg ha scritto:
> On Fri, Jan 31, 2014 at 09:36:48AM +0100, Sandro Bonazzola wrote:
>> Il 30/01/2014 22:38, Robert Story ha scritto:
>>> Can we revert these packages to previous versions in the 3.3.2 stable repo
>>> so those of us who want/need to install new hosts in our clusters aren't
>>> dead in the water waiting for 3.3.3?
>>
>> Hi Robert, I think you can still install 3.3.2 on your clusters with the requirement of adding
>> manually oython-cpopen before trying to install vdsm.
>>
>> About 3.3.3, I think vdsm should really drop dependency on vdsm-python-cpopen:
>> it's a package obsoleted by python-cpopen so there's no point in still requiring it especially if keeping that requirement still break dependency
>> resolution.
> 
> I really wanted to avoid eliminating a subpackage during a micro
> release. That's impolite and surprising.

I'm not telling you to not provide vdsm-python-cpopen while you build vdsm.
I'm telling you to not require it. You can still build it and let it to be unused.
Just treat vdsm-python-cpopen as something not provided anymore by the distro while python-cpopen is the new one replacing it.

> But given the awkward yum bug, persistent dependency problems, and
> the current release delay, I give up.
> 
> Let's eliminate vdsm-python-cpopen from ovirt-3.3 branch, and require
> python-cpopen. Yaniv, Douglas: could you handle it?
> 


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


From dougsland at redhat.com  Fri Jan 31 21:16:54 2014
From: dougsland at redhat.com (Douglas Schilling Landgraf)
Date: Fri, 31 Jan 2014 16:16:54 -0500
Subject: [Users] ovirt-3.3.3 release postponed due to blockers
In-Reply-To: <20140131101743.GB9811@redhat.com>
References: <52E8BA32.7060600@mittwald.de> <52E8BA86.8090300@redhat.com>
	<52EA12DD.30500@mittwald.de> <20140130092021.GC26360@redhat.com>
	<52EA1B06.2000106@redhat.com> <20140130140212.GF26360@redhat.com>
	<2035318599.4883138.1391094839988.JavaMail.root@redhat.com>
	<52EA6F3B.9070701@redhat.com>
	<20140130163805.535ec676@ispx.vb.futz.org>
	<52EB60A0.5040500@redhat.com> <20140131101743.GB9811@redhat.com>
Message-ID: <52EC12C6.6090302@redhat.com>

On 01/31/2014 05:17 AM, Dan Kenigsberg wrote:
> On Fri, Jan 31, 2014 at 09:36:48AM +0100, Sandro Bonazzola wrote:
>> Il 30/01/2014 22:38, Robert Story ha scritto:
>>> Can we revert these packages to previous versions in the 3.3.2 stable repo
>>> so those of us who want/need to install new hosts in our clusters aren't
>>> dead in the water waiting for 3.3.3?
>>
>> Hi Robert, I think you can still install 3.3.2 on your clusters with the requirement of adding
>> manually oython-cpopen before trying to install vdsm.
>>
>> About 3.3.3, I think vdsm should really drop dependency on vdsm-python-cpopen:
>> it's a package obsoleted by python-cpopen so there's no point in still requiring it especially if keeping that requirement still break dependency
>> resolution.
>
> I really wanted to avoid eliminating a subpackage during a micro
> release. That's impolite and surprising.
> But given the awkward yum bug, persistent dependency problems, and
> the current release delay, I give up.
>
> Let's eliminate vdsm-python-cpopen from ovirt-3.3 branch, and require
> python-cpopen. Yaniv, Douglas: could you handle it?
>

Sure. Done: http://gerrit.ovirt.org/#/c/23942/

-- 
Cheers
Douglas