From psebek at redhat.com  Thu Jul  4 11:56:56 2013
From: psebek at redhat.com (Petr Sebek)
Date: Thu, 4 Jul 2013 07:56:56 -0400 (EDT)
Subject: Change of vdsStats
In-Reply-To: <72049741.9071152.1372938339530.JavaMail.root@redhat.com>
Message-ID: <849742748.9075232.1372939016392.JavaMail.root@redhat.com>

Hi,

I've made patch [1] according to RFE [2]. Basically I just added information about bridges and vlans in vdsStats. I wanted to start discussion if is this change needed and suitable? I'm asking because with more statistics comes bigger size of output. So I'm asking You if we need this information in Engine and about which devices in particular.


[1] http://gerrit.ovirt.org/#/c/16227/
[2] https://bugzilla.redhat.com/show_bug.cgi?id=675560

Regards,
Petr ?ebek.


From vszocs at redhat.com  Thu Jul  4 14:08:18 2013
From: vszocs at redhat.com (Vojtech Szocs)
Date: Thu, 4 Jul 2013 10:08:18 -0400 (EDT)
Subject: Upgrading oVirt UI technology stack
In-Reply-To: <526288595.5644695.1372946839995.JavaMail.root@redhat.com>
References: <526288595.5644695.1372946839995.JavaMail.root@redhat.com>
Message-ID: <1480731235.5644811.1372946898774.JavaMail.root@redhat.com>

Hello everyone,

I wrote a wiki page to summarize our effort to upgrade existing UI technology stack shared by oVirt web applications:

http://www.ovirt.org/Features/GWT_Platform_Upgrade

The wiki page divides GWT and GWTP changes into Essential and Non-essential. All Essential changes will be part of the initial upgrade patch (currently in progress), all Non-essential changes will be addressed later on, based on their priority.

There's still one open issue (Essential change) related to GWTP framework, however we should come to a conclusion pretty soon. The corresponding (Essential change) patch will follow shortly after that.

Any feedback is greatly appreciated, let me know what you think.

Regards,
Vojtech


From psebek at redhat.com  Mon Jul  8 09:25:35 2013
From: psebek at redhat.com (Petr Sebek)
Date: Mon, 8 Jul 2013 05:25:35 -0400 (EDT)
Subject: Change of vdsStats
In-Reply-To: <849742748.9075232.1372939016392.JavaMail.root@redhat.com>
References: <849742748.9075232.1372939016392.JavaMail.root@redhat.com>
Message-ID: <2024234935.495479.1373275535768.JavaMail.root@redhat.com>

The bug on bugzilla was for unknown reasons locked. Now it is unlocked for
everybody.

----- Original Message -----
> From: "Petr Sebek" <psebek at redhat.com>
> To: arch at ovirt.org
> Sent: Thursday, July 4, 2013 1:56:56 PM
> Subject: Change of vdsStats
> 
> Hi,
> 
> I've made patch [1] according to RFE [2]. Basically I just added information
> about bridges and vlans in vdsStats. I wanted to start discussion if is this
> change needed and suitable? I'm asking because with more statistics comes
> bigger size of output. So I'm asking You if we need this information in
> Engine and about which devices in particular.
> 
> 
> [1] http://gerrit.ovirt.org/#/c/16227/
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=675560
> 
> Regards,
> Petr ?ebek.
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From gvallare at redhat.com  Mon Jul  8 10:45:41 2013
From: gvallare at redhat.com (Giuseppe Vallarelli)
Date: Mon, 8 Jul 2013 06:45:41 -0400 (EDT)
Subject: Network traffic shaping.
In-Reply-To: <589270552.398732.1373279847657.JavaMail.root@redhat.com>
Message-ID: <1809186597.402470.1373280341185.JavaMail.root@redhat.com>

Hi everybody, I'm working to implement traffic shaping at the network level [1].
This feature is composed by two distinct parts: definition of traffic shaping
for a logical network entity and optional redefinition of traffic shaping when
the user is doing a Setup Host Networks task. Initial focus will be on first
part. There are some points of contact with Network Qos [2] that's why I proposed
to reuse some code backend side.

Cheers, Giuseppe

[1] http://www.ovirt.org/Features/Network_traffic_shaping
[2] http://www.ovirt.org/Features/Network_QoS


From danken at redhat.com  Mon Jul  8 20:07:49 2013
From: danken at redhat.com (Dan Kenigsberg)
Date: Mon, 8 Jul 2013 23:07:49 +0300
Subject: Change of vdsStats
In-Reply-To: <2024234935.495479.1373275535768.JavaMail.root@redhat.com>
References: <849742748.9075232.1372939016392.JavaMail.root@redhat.com>
	<2024234935.495479.1373275535768.JavaMail.root@redhat.com>
Message-ID: <20130708200749.GE21626@redhat.com>

On Mon, Jul 08, 2013 at 05:25:35AM -0400, Petr Sebek wrote:
> The bug on bugzilla was for unknown reasons locked. Now it is unlocked for
> everybody.
> 
> ----- Original Message -----
> > From: "Petr Sebek" <psebek at redhat.com>
> > To: arch at ovirt.org
> > Sent: Thursday, July 4, 2013 1:56:56 PM
> > Subject: Change of vdsStats
> > 
> > Hi,
> > 
> > I've made patch [1] according to RFE [2]. Basically I just added information
> > about bridges and vlans in vdsStats. I wanted to start discussion if is this
> > change needed and suitable? I'm asking because with more statistics comes
> > bigger size of output. So I'm asking You if we need this information in
> > Engine and about which devices in particular.
> > 
> > 
> > [1] http://gerrit.ovirt.org/#/c/16227/
> > [2] https://bugzilla.redhat.com/show_bug.cgi?id=675560

Thanks for your patch, Petr.

It makes vdsm provide all interface information for bridges and vlans -
where this information includes mac address, tx/rx rates, 0 in the
speed field, and the device state.

Only the latter element is interesting for the purposes of the opened
bug.  For example, there's an old patch by Mark Wu suggesting to drop
macAddr from the stats of actual nics
(http://gerrit.ovirt.org/#/c/13840/); we certainly do not need to report
the quite-random mac address of bridge devices.

Similarly, I am not sure that the rxRate of the vlan device has any
significance.

Finally, does Engine have plans to collect the state field from bridge
devices and report an error if the state is down?

Can you think of cases, other than manual "ifdown" by an evil admin,
where the state if a vlan device is expected to change?

Regards,
Dan.


From masayag at redhat.com  Tue Jul  9 08:13:27 2013
From: masayag at redhat.com (Moti Asayag)
Date: Tue, 9 Jul 2013 04:13:27 -0400 (EDT)
Subject: Change of vdsStats
In-Reply-To: <20130708200749.GE21626@redhat.com>
References: <849742748.9075232.1372939016392.JavaMail.root@redhat.com>
	<2024234935.495479.1373275535768.JavaMail.root@redhat.com>
	<20130708200749.GE21626@redhat.com>
Message-ID: <370845292.961365.1373357607025.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Dan Kenigsberg" <danken at redhat.com>
> To: "Petr Sebek" <psebek at redhat.com>, "Moti Asayag" <masayag at redhat.com>
> Cc: arch at ovirt.org
> Sent: Monday, July 8, 2013 11:07:49 PM
> Subject: Re: Change of vdsStats
> 
> On Mon, Jul 08, 2013 at 05:25:35AM -0400, Petr Sebek wrote:
> > The bug on bugzilla was for unknown reasons locked. Now it is unlocked for
> > everybody.
> > 
> > ----- Original Message -----
> > > From: "Petr Sebek" <psebek at redhat.com>
> > > To: arch at ovirt.org
> > > Sent: Thursday, July 4, 2013 1:56:56 PM
> > > Subject: Change of vdsStats
> > > 
> > > Hi,
> > > 
> > > I've made patch [1] according to RFE [2]. Basically I just added
> > > information
> > > about bridges and vlans in vdsStats. I wanted to start discussion if is
> > > this
> > > change needed and suitable? I'm asking because with more statistics comes
> > > bigger size of output. So I'm asking You if we need this information in
> > > Engine and about which devices in particular.
> > > 
> > > 
> > > [1] http://gerrit.ovirt.org/#/c/16227/
> > > [2] https://bugzilla.redhat.com/show_bug.cgi?id=675560
> 
> Thanks for your patch, Petr.
> 
> It makes vdsm provide all interface information for bridges and vlans -
> where this information includes mac address, tx/rx rates, 0 in the
> speed field, and the device state.
> 
> Only the latter element is interesting for the purposes of the opened
> bug.  For example, there's an old patch by Mark Wu suggesting to drop
> macAddr from the stats of actual nics
> (http://gerrit.ovirt.org/#/c/13840/); we certainly do not need to report
> the quite-random mac address of bridge devices.
> 
> Similarly, I am not sure that the rxRate of the vlan device has any
> significance.
> 
> Finally, does Engine have plans to collect the state field from bridge
> devices and report an error if the state is down?

The engine should move the host to non-operational if the bridge or the vlan 
are reported from VDSM as down. If it doesn't implemented that way - it is 
an engine bug.

> 
> Can you think of cases, other than manual "ifdown" by an evil admin,
> where the state if a vlan device is expected to change?
> 
> Regards,
> Dan.
> 


From masayag at redhat.com  Wed Jul 10 09:57:56 2013
From: masayag at redhat.com (Moti Asayag)
Date: Wed, 10 Jul 2013 05:57:56 -0400 (EDT)
Subject: Network traffic shaping.
In-Reply-To: <1809186597.402470.1373280341185.JavaMail.root@redhat.com>
References: <1809186597.402470.1373280341185.JavaMail.root@redhat.com>
Message-ID: <1538914369.1676771.1373450276477.JavaMail.root@redhat.com>

Hi Giuseppe,

I'm in favour of reusing the entities which represent the network QoS for a network
interface. However I'd store the vnic network QoS and host network QoS entries in
different tables, else we miss the distinguish between network QoS designed for VMs
to these used for hosts.

Which leads to the next issue: The network traffic shaping will follow the Vnic Network QoS [1],
therefore the Vnic network QoS should be have an upper limit set by the host's VM network QoS for
the same VM network. What would be the behaviour in case the total average bit-rate of the VMs
exceeds the host network bit-rate ?

Is there any limit for the peak or burst ? and if there is, are they differ between the host network
QoS to the vnic QoS? 

Regarding the 'New Logical Network' dialog, I'd suggest to add the Network QoS as a left tab, rather
than having it on the main dialog. See [2] a mock-up of the new dialog shortly which includes the 
vnic profile left-tab, and also the QoS left-tab.

In addition, should there be a new 'QoS' sub-tab for the networks tab ?


[1] http://www.ovirt.org/Features/Network_QoS
[2] http://www.ovirt.org/File:New_netwrok_profiles.png

Moti

----- Original Message -----
> From: "Giuseppe Vallarelli" <gvallare at redhat.com>
> To: arch at ovirt.org
> Sent: Monday, July 8, 2013 1:45:41 PM
> Subject: Network traffic shaping.
> 
> Hi everybody, I'm working to implement traffic shaping at the network level
> [1].
> This feature is composed by two distinct parts: definition of traffic shaping
> for a logical network entity and optional redefinition of traffic shaping
> when
> the user is doing a Setup Host Networks task. Initial focus will be on first
> part. There are some points of contact with Network Qos [2] that's why I
> proposed
> to reuse some code backend side.
> 
> Cheers, Giuseppe
> 
> [1] http://www.ovirt.org/Features/Network_traffic_shaping
> [2] http://www.ovirt.org/Features/Network_QoS
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From gvallare at redhat.com  Wed Jul 10 12:03:20 2013
From: gvallare at redhat.com (Giuseppe Vallarelli)
Date: Wed, 10 Jul 2013 08:03:20 -0400 (EDT)
Subject: Network traffic shaping.
In-Reply-To: <1538914369.1676771.1373450276477.JavaMail.root@redhat.com>
References: <1809186597.402470.1373280341185.JavaMail.root@redhat.com>
	<1538914369.1676771.1373450276477.JavaMail.root@redhat.com>
Message-ID: <1826722997.2554310.1373457800634.JavaMail.root@redhat.com>

----- Original Message -----
| From: "Moti Asayag" <masayag at redhat.com>
| To: "Giuseppe Vallarelli" <gvallare at redhat.com>
| Cc: arch at ovirt.org
| Sent: Wednesday, July 10, 2013 11:57:56 AM
| Subject: Re: Network traffic shaping.
| 
| Hi Giuseppe,
| 
| I'm in favour of reusing the entities which represent the network QoS for a
| network
| interface. However I'd store the vnic network QoS and host network QoS
| entries in
| different tables, else we miss the distinguish between network QoS designed
| for VMs
| to these used for hosts.

I would rather not duplicate or having two different tables which in practice
are almost the same. I would add a new attribute like qos_type with 2 possible
values for now: vnic and network to distinguish between the 2. What do you think?

| Which leads to the next issue: The network traffic shaping will follow the
| Vnic Network QoS [1],
| therefore the Vnic network QoS should be have an upper limit set by the
| host's VM network QoS for
| the same VM network. What would be the behaviour in case the total average
| bit-rate of the VMs
| exceeds the host network bit-rate ?

The underlying implementation of libvirt works in this way:
if you shape the network bandwidth and it's tighter than the vnic
shaped bandwidth than you will not have a bandwidth throughput of vnic
higher than the one defined by the shaped network. The network
bandwidth act as a constraint here. If the user gets the bandwidth
values wrong the traffic can't go faster of what the underlying
technology provides.

Now given this premise we can have 2 different scenarios:

Scenario 1:

User defines network QoS and vnics QoS whose values (vnic)
for average, burst and peak should be lesser or equal
to the ones defined in the network.

Scenario 2:

User only defines vnics QoS which is in practice still constrained by
the underlying nic's capacity, no matter of user's wishes.

| Is there any limit for the peak or burst ? and if there is, are they differ
| between the host network
| QoS to the vnic QoS?

There is no limit for peak and burst or default value that libvirt provides.
I need to add that the only compulsory attribute for bandwidth definition is
only average, burst and peak are optional values as well as incoming and
outgoing traffic can be shaped independently (I would use incoming and outgoing
respectively for inbound and outbound, I think they're better terms for labels
in the mockups)

| Regarding the 'New Logical Network' dialog, I'd suggest to add the Network
| QoS as a left tab, rather
| than having it on the main dialog. See [2] a mock-up of the new dialog
| shortly which includes the
| vnic profile left-tab, and also the QoS left-tab.

I agree on having a unified UI. Not much with the multiple tabs.
I consider the multiple tabs approach valid when they're related
to different concepts, where each concept is independent.
Which is not valid in this case. I would expect to have a single
unified tab for QoS which includes both network and vnics.

| 
| In addition, should there be a new 'QoS' sub-tab for the networks tab ?

See previous answer. Perhaps it might have more sense to have a vnic profiles
as a sub-tab due to the previous considerations.

Cheers, Giuseppe

| 
| 
| [1] http://www.ovirt.org/Features/Network_QoS
| [2] http://www.ovirt.org/File:New_netwrok_profiles.png
| 
| Moti
| 
| ----- Original Message -----
| > From: "Giuseppe Vallarelli" <gvallare at redhat.com>
| > To: arch at ovirt.org
| > Sent: Monday, July 8, 2013 1:45:41 PM
| > Subject: Network traffic shaping.
| > 
| > Hi everybody, I'm working to implement traffic shaping at the network level
| > [1].
| > This feature is composed by two distinct parts: definition of traffic
| > shaping
| > for a logical network entity and optional redefinition of traffic shaping
| > when
| > the user is doing a Setup Host Networks task. Initial focus will be on
| > first
| > part. There are some points of contact with Network Qos [2] that's why I
| > proposed
| > to reuse some code backend side.
| > 
| > Cheers, Giuseppe
| > 
| > [1] http://www.ovirt.org/Features/Network_traffic_shaping
| > [2] http://www.ovirt.org/Features/Network_QoS
| > _______________________________________________
| > Arch mailing list
| > Arch at ovirt.org
| > http://lists.ovirt.org/mailman/listinfo/arch
| > 
| 


From mkolesni at redhat.com  Thu Jul 11 06:10:18 2013
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Thu, 11 Jul 2013 02:10:18 -0400 (EDT)
Subject: Network traffic shaping.
In-Reply-To: <1826722997.2554310.1373457800634.JavaMail.root@redhat.com>
References: <1809186597.402470.1373280341185.JavaMail.root@redhat.com>
	<1538914369.1676771.1373450276477.JavaMail.root@redhat.com>
	<1826722997.2554310.1373457800634.JavaMail.root@redhat.com>
Message-ID: <1179017427.2260567.1373523018814.JavaMail.root@redhat.com>

----- Original Message -----
> ----- Original Message -----
> | From: "Moti Asayag" <masayag at redhat.com>
> | To: "Giuseppe Vallarelli" <gvallare at redhat.com>
> | Cc: arch at ovirt.org
> | Sent: Wednesday, July 10, 2013 11:57:56 AM
> | Subject: Re: Network traffic shaping.
> | 
> | Hi Giuseppe,
> | 
> | I'm in favour of reusing the entities which represent the network QoS for a
> | network
> | interface. However I'd store the vnic network QoS and host network QoS
> | entries in
> | different tables, else we miss the distinguish between network QoS designed
> | for VMs
> | to these used for hosts.
> 
> I would rather not duplicate or having two different tables which in practice
> are almost the same. I would add a new attribute like qos_type with 2
> possible
> values for now: vnic and network to distinguish between the 2. What do you
> think?
> 
> | Which leads to the next issue: The network traffic shaping will follow the
> | Vnic Network QoS [1],
> | therefore the Vnic network QoS should be have an upper limit set by the
> | host's VM network QoS for
> | the same VM network. What would be the behaviour in case the total average
> | bit-rate of the VMs
> | exceeds the host network bit-rate ?
> 
> The underlying implementation of libvirt works in this way:
> if you shape the network bandwidth and it's tighter than the vnic
> shaped bandwidth than you will not have a bandwidth throughput of vnic
> higher than the one defined by the shaped network. The network
> bandwidth act as a constraint here. If the user gets the bandwidth
> values wrong the traffic can't go faster of what the underlying
> technology provides.
> 
> Now given this premise we can have 2 different scenarios:
> 
> Scenario 1:
> 
> User defines network QoS and vnics QoS whose values (vnic)
> for average, burst and peak should be lesser or equal
> to the ones defined in the network.
> 
> Scenario 2:
> 
> User only defines vnics QoS which is in practice still constrained by
> the underlying nic's capacity, no matter of user's wishes.
> 
> | Is there any limit for the peak or burst ? and if there is, are they differ
> | between the host network
> | QoS to the vnic QoS?
> 
> There is no limit for peak and burst or default value that libvirt provides.
> I need to add that the only compulsory attribute for bandwidth definition is
> only average, burst and peak are optional values as well as incoming and
> outgoing traffic can be shaped independently (I would use incoming and
> outgoing
> respectively for inbound and outbound, I think they're better terms for
> labels
> in the mockups)
> 
> | Regarding the 'New Logical Network' dialog, I'd suggest to add the Network
> | QoS as a left tab, rather
> | than having it on the main dialog. See [2] a mock-up of the new dialog
> | shortly which includes the
> | vnic profile left-tab, and also the QoS left-tab.
> 
> I agree on having a unified UI. Not much with the multiple tabs.
> I consider the multiple tabs approach valid when they're related
> to different concepts, where each concept is independent.
> Which is not valid in this case. I would expect to have a single
> unified tab for QoS which includes both network and vnics.

In your case the QoS is not really tied to the network parameters - is it VM, is it VLAN, etc..
Hence, by your logic, this should be on a separate left tab (there is an upcoming change to introduce these into the new/edit network dialogs).

> 
> | 
> | In addition, should there be a new 'QoS' sub-tab for the networks tab ?
> 
> See previous answer. Perhaps it might have more sense to have a vnic profiles
> as a sub-tab due to the previous considerations.

I think what Moti meant is when in the view you're viewing a network in the "networks" main tab, how would you see it's QoS.

> 
> Cheers, Giuseppe
> 
> | 
> | 
> | [1] http://www.ovirt.org/Features/Network_QoS
> | [2] http://www.ovirt.org/File:New_netwrok_profiles.png
> | 
> | Moti
> | 
> | ----- Original Message -----
> | > From: "Giuseppe Vallarelli" <gvallare at redhat.com>
> | > To: arch at ovirt.org
> | > Sent: Monday, July 8, 2013 1:45:41 PM
> | > Subject: Network traffic shaping.
> | > 
> | > Hi everybody, I'm working to implement traffic shaping at the network
> | > level
> | > [1].
> | > This feature is composed by two distinct parts: definition of traffic
> | > shaping
> | > for a logical network entity and optional redefinition of traffic shaping
> | > when
> | > the user is doing a Setup Host Networks task. Initial focus will be on
> | > first
> | > part. There are some points of contact with Network Qos [2] that's why I
> | > proposed
> | > to reuse some code backend side.
> | > 
> | > Cheers, Giuseppe
> | > 
> | > [1] http://www.ovirt.org/Features/Network_traffic_shaping
> | > [2] http://www.ovirt.org/Features/Network_QoS
> | > _______________________________________________
> | > 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 mkolesni at redhat.com  Thu Jul 11 06:35:05 2013
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Thu, 11 Jul 2013 02:35:05 -0400 (EDT)
Subject: Network traffic shaping.
In-Reply-To: <1809186597.402470.1373280341185.JavaMail.root@redhat.com>
References: <1809186597.402470.1373280341185.JavaMail.root@redhat.com>
Message-ID: <1092887824.2272052.1373524505316.JavaMail.root@redhat.com>

Hi Giuseppe,

The feature looks like it will be good to have.
I have some thoughts:

1. If the QoS is a different entity that you're creating when creating the network,
I think there should be an option to choose an existing QoS or create a new one,
say a combo box where you can choose an existing QoS (Then the parameters appear, but read-only)
or enter the name of a new QoS and fill the parameters by yourself.

2. What is the proposed permissions model?

3. Please consider how you would handle this in Setup Networks:
3.1. How will you handle only delta?
3.2. Are you going to handle this with regards to sync between host actual definition, and logical definition?
3.3. This would imply that you need to report this data back from VDSM and save it per host NIC..

4. In the DB change section you should specify which columns/constraints you're going to add.

Regards,
Mike

----- Original Message -----
> Hi everybody, I'm working to implement traffic shaping at the network level
> [1].
> This feature is composed by two distinct parts: definition of traffic shaping
> for a logical network entity and optional redefinition of traffic shaping
> when
> the user is doing a Setup Host Networks task. Initial focus will be on first
> part. There are some points of contact with Network Qos [2] that's why I
> proposed
> to reuse some code backend side.
> 
> Cheers, Giuseppe
> 
> [1] http://www.ovirt.org/Features/Network_traffic_shaping
> [2] http://www.ovirt.org/Features/Network_QoS
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From gvallare at redhat.com  Thu Jul 11 12:48:02 2013
From: gvallare at redhat.com (Giuseppe Vallarelli)
Date: Thu, 11 Jul 2013 08:48:02 -0400 (EDT)
Subject: Network traffic shaping.
In-Reply-To: <1092887824.2272052.1373524505316.JavaMail.root@redhat.com>
References: <1809186597.402470.1373280341185.JavaMail.root@redhat.com>
	<1092887824.2272052.1373524505316.JavaMail.root@redhat.com>
Message-ID: <1988060655.3213378.1373546882837.JavaMail.root@redhat.com>

----- Original Message -----
| From: "Mike Kolesnik" <mkolesni at redhat.com>
| To: "Giuseppe Vallarelli" <gvallare at redhat.com>
| Cc: arch at ovirt.org
| Sent: Thursday, July 11, 2013 8:35:05 AM
| Subject: Re: Network traffic shaping.
| 
| Hi Giuseppe,
| 
| The feature looks like it will be good to have.
| I have some thoughts:
| 
| 1. If the QoS is a different entity that you're creating when creating the
| network,
| I think there should be an option to choose an existing QoS or create a new
| one,
| say a combo box where you can choose an existing QoS (Then the parameters
| appear, but read-only)
| or enter the name of a new QoS and fill the parameters by yourself.

Ok I agree with you, makes sense. Always related to this matter mostly
to the quality of service table, wouldn't be better to have a db table
formed with these attributes: id, avg, burst, peak (table name qos)
so a vnic or a network can link to it - without 'owning' these attributes.

| 2. What is the proposed permissions model?

I form an idea still and update the feature page accordingly.

| 
| 3. Please consider how you would handle this in Setup Networks:
| 3.1. How will you handle only delta?
| 3.2. Are you going to handle this with regards to sync between host actual
| definition, and logical definition?
| 3.3. This would imply that you need to report this data back from VDSM and
| save it per host NIC..
| 
| 4. In the DB change section you should specify which columns/constraints
| you're going to add.

same as point 2. Thanks for the feedback I need to refine furthermore
the proposal.

Cheers, Giuseppe

| 
| Regards,
| Mike


| 
| ----- Original Message -----
| > Hi everybody, I'm working to implement traffic shaping at the network level
| > [1].
| > This feature is composed by two distinct parts: definition of traffic
| > shaping
| > for a logical network entity and optional redefinition of traffic shaping
| > when
| > the user is doing a Setup Host Networks task. Initial focus will be on
| > first
| > part. There are some points of contact with Network Qos [2] that's why I
| > proposed
| > to reuse some code backend side.
| > 
| > Cheers, Giuseppe
| > 
| > [1] http://www.ovirt.org/Features/Network_traffic_shaping
| > [2] http://www.ovirt.org/Features/Network_QoS
| > _______________________________________________
| > Arch mailing list
| > Arch at ovirt.org
| > http://lists.ovirt.org/mailman/listinfo/arch
| > 
| 


From gvallare at redhat.com  Thu Jul 11 15:14:59 2013
From: gvallare at redhat.com (Giuseppe Vallarelli)
Date: Thu, 11 Jul 2013 11:14:59 -0400 (EDT)
Subject: network and vnic qos
In-Reply-To: <1519387408.3309463.1373553826481.JavaMail.root@redhat.com>
Message-ID: <293956441.3359594.1373555699680.JavaMail.root@redhat.com>

Hi Ofri, me, Moti and Mike have been looking carefully through the design spec of the vnic profiles[0]
and lately to the network traffic shaping [1] which is very closely related.
A reason of concern is the current design of network qos table[2].

First issue is the one related to the attributes associated to the traffic shaping (either inbound
or outbound), I got the chance to talk with Michal (a libvirt developer in Brno) which confirmed me
that the only compulsory attribute is average both burst and peak are optional, also he told me that
libvirt doesn't provide any default values in case those are missing ones. Looking at missingValue()
method in [3] seems that all 3 values are compulsory.

Second issue is mostly related to the decision of creating a single table with traffic shaping
for both incoming and outgoing traffic (in table defined respectively as inbound and outbound).
Incoming and outgoing traffic are independent and practically the same. If a network admin defines
only incoming traffic, outgoing traffic attributes are nulls.

An alternative approach that we discussed is the following one: a table named simply qos
or if you prefer qos_profile with the three attributes average (not null), burst and peak and an id.
In this case after the user creates a profile, that one can be associated, as you defined in your spec,
to a vnic (and in the future to a network). I'm not sure if we need a different attribute
to specify for convenience the traffic at which the qos profile is applied (incoming/inbound, ougoing/outbound).

Cheers, Giuseppe


[0]http://www.ovirt.org/Features/Network_QoS
[1]http://www.ovirt.org/Features/Network_traffic_shaping
[2]http://gerrit.ovirt.org/#/c/16294/8/packaging/dbscripts/upgrade/03_03_0400_add_network_qos_tabel.sql
[3]http://gerrit.ovirt.org/#/c/16294/8/backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/qos/NetworkQoSCommandBase.java


From leonardo.bianconi at eldorado.org.br  Thu Jul 11 17:04:20 2013
From: leonardo.bianconi at eldorado.org.br (Leonardo Bianconi)
Date: Thu, 11 Jul 2013 17:04:20 +0000
Subject: oVirt on IBM POWER (PPC64) - new feature contributors
In-Reply-To: <51A0B899.9030600@redhat.com>
References: <50EB20226B72D6419356FC320AB62B871896B600@SERV070.corp.eldorado.org.br>
	<5193A8AE.5000600@redhat.com>
	<50EB20226B72D6419356FC320AB62B871896BB19@SERV070.corp.eldorado.org.br>
	<61C18AFB-AF93-48F3-BC90-6AA1B341DF27@redhat.com>
	<51A0B899.9030600@redhat.com>
Message-ID: <50EB20226B72D6419356FC320AB62B8719170EE6@SERV070.corp.eldorado.org.br>



-----Original Message-----
From: Itamar Heim [mailto:iheim at redhat.com] 
Sent: s?bado, 25 de maio de 2013 10:12
To: Michal Skrivanek
Cc: Leonardo Bianconi; arch at ovirt.org; Roy Golan
Subject: Re: oVirt on IBM POWER (PPC64) - new feature contributors

On 05/22/2013 10:46 AM, Michal Skrivanek wrote:
>
> On May 21, 2013, at 17:33 , Leonardo Bianconi <leonardo.bianconi at eldorado.org.br> wrote:
>
>> Hi all,
>>
>> We are planning to deliver support for PPC64 in 4 phases. We will manage to deliver a set of patches at the end of each phase.
>>
>> Phase 1
>>
>> 	 Change oVirt to handle other architectures by encapsulating all the architecture specific code and queries about the capabilities of the hypervisor into a new class called ArchStrategy (based on the Strategy Design Pattern). Every operation involving clusters and hosts will be validated by this new class. Some hard-coded parameters are going to be replaced by queries in the backend in order to accommodate the support for new architectures into the engine.
>
> If you would like to discuss some internals or if anything is unclear please feel free to set up a quick mtg with myself, Omer and Roy.
> Sometimes (e.g. in the case of VmInterfaceType as mentioned on feature page) it would be actually beneficial for oVirt on x86 as well to have a greater flexibility directly in the code, without Strategy encapsulation.
>
>>
>>
>> Phase 2
>>
>> 	Currently, each host hypervisor capabilities are obtained using hard-coded data structures. These structures will be replaced either by some form of integration with libosinfo or by reading internal configuration files describing these capabilities. It will be handled after Roy's patch.
> Roy's osinfo will soon be merged.

link to patches?
does it cover adding arch at cluster level?

Sorry about the late reply. We have already handled the gap between the osinfo patch, the architecture parameters are being stored the same way as the OS info.

We didn't add a specific architecture field on each cluster, because based on the cpu name and cluster compatibility version of the cluster the architecture can be determined. Do you think it is really necessary to add another way to describe the architecture of each cluster?

>
>>
>>
>> Phase 3
>>
>> 	The code for providing the support for IBM POWER systems will be added. The encapsulation done in the previous phase will reduce the effort to include this feature into the engine. The other changes that will be introduced in this phase include:
>>
>> 	- Modifications in the frontend to avoid running a VM created on a POWER host in a x86-64 host (and vice-versa),
>> 	- All the dynamically provided capacities of the first phase will be implemented according to the capacities of the QEMU/KVM on POWER
>> 	- The POWER processors will be available as an option in the list of 
>> processor names (this will imply in significant changes in the 
>> backend)
>>
>>
>> Phase 4
>>
>> 	Adapt secondary features to polish the support for POWER:
>>
>> 	- OVF import and export of VMs running in POWER hosts
>> 	- Dynamic searches capable of finding hosts, pools, vms and clusters 
>> according to their architectures
>>
>>
>> Is there any ongoing oVirt architecture refactoring ? (that may 
>> conflict with Phase 1, for instance)
> no, nothing major going on
>
>>
>> Any comments ?
> Looking forward to your patches!:-)
>
> Thanks,
> michal
>
>>
>> Regards,
>> Vitor (vitor.lima at eldorado.org.br) / Leonardo 
>> (leonardo.bianconi at eldorado.org.br)
>>
>>
>> -----Original Message-----
>> From: Dave Neary [mailto:dneary at redhat.com]
>> Sent: quarta-feira, 15 de maio de 2013 12:25
>> To: Leonardo Bianconi
>> Cc: arch at ovirt.org; Adam Litke
>> Subject: Re: oVirt on IBM POWER (PPC64) - new feature contributors
>>
>> Hi,
>>
>> On 05/14/2013 08:05 PM, Leonardo Bianconi wrote:
>>> We would like to introduce ourselves: Leonardo Bianconi and Vitor Lima.
>>
>> Welcome!
>>
>>> We would like to work on the features "Engine support for PPC64" (http://wiki.ovirt.org/Features/Engine_support_for_PPC64) and the "Vdsm for PPC64" (http://wiki.ovirt.org/Features/Vdsm_for_PPC64). This work has already been started by some developers at IBM.
>>
>> <snip>
>>
>>> About libosinfo:
>>> =============
>>>
>>> In the previous discussion about this topic (http://lists.ovirt.org/pipermail/arch/2012-November/000976.html), occurred in November 2012, it was suggested that integrating the libosinfo into the engine would be a better way to handle the differences between the architectures that would be supported in the future.
>>>
>>> Is this approach still valid? If so, when will it be available? It seems to be a dependency for oVirt "Engine_support_for_PPC64" feature implementation.
>>
>>
>> This is great news. I don't know who, specifically, has been working on this issue in IBM - perhaps Adam Litke (CCed) can update you on the progress that has been made.
>
>>
>> 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
>
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
>



From iheim at redhat.com  Thu Jul 11 17:18:29 2013
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 11 Jul 2013 20:18:29 +0300
Subject: oVirt on IBM POWER (PPC64) - new feature contributors
In-Reply-To: <50EB20226B72D6419356FC320AB62B8719170EE6@SERV070.corp.eldorado.org.br>
References: <50EB20226B72D6419356FC320AB62B871896B600@SERV070.corp.eldorado.org.br>
	<5193A8AE.5000600@redhat.com>
	<50EB20226B72D6419356FC320AB62B871896BB19@SERV070.corp.eldorado.org.br>
	<61C18AFB-AF93-48F3-BC90-6AA1B341DF27@redhat.com>
	<51A0B899.9030600@redhat.com>
	<50EB20226B72D6419356FC320AB62B8719170EE6@SERV070.corp.eldorado.org.br>
Message-ID: <51DEE8E5.2020806@redhat.com>

On 07/11/2013 08:04 PM, Leonardo Bianconi wrote:
>
>
> -----Original Message-----
> From: Itamar Heim [mailto:iheim at redhat.com]
> Sent: s?bado, 25 de maio de 2013 10:12
> To: Michal Skrivanek
> Cc: Leonardo Bianconi; arch at ovirt.org; Roy Golan
> Subject: Re: oVirt on IBM POWER (PPC64) - new feature contributors
>
> On 05/22/2013 10:46 AM, Michal Skrivanek wrote:
>>
>> On May 21, 2013, at 17:33 , Leonardo Bianconi <leonardo.bianconi at eldorado.org.br> wrote:
>>
>>> Hi all,
>>>
>>> We are planning to deliver support for PPC64 in 4 phases. We will manage to deliver a set of patches at the end of each phase.
>>>
>>> Phase 1
>>>
>>> 	 Change oVirt to handle other architectures by encapsulating all the architecture specific code and queries about the capabilities of the hypervisor into a new class called ArchStrategy (based on the Strategy Design Pattern). Every operation involving clusters and hosts will be validated by this new class. Some hard-coded parameters are going to be replaced by queries in the backend in order to accommodate the support for new architectures into the engine.
>>
>> If you would like to discuss some internals or if anything is unclear please feel free to set up a quick mtg with myself, Omer and Roy.
>> Sometimes (e.g. in the case of VmInterfaceType as mentioned on feature page) it would be actually beneficial for oVirt on x86 as well to have a greater flexibility directly in the code, without Strategy encapsulation.
>>
>>>
>>>
>>> Phase 2
>>>
>>> 	Currently, each host hypervisor capabilities are obtained using hard-coded data structures. These structures will be replaced either by some form of integration with libosinfo or by reading internal configuration files describing these capabilities. It will be handled after Roy's patch.
>> Roy's osinfo will soon be merged.
>
> link to patches?
> does it cover adding arch at cluster level?
>
> Sorry about the late reply. We have already handled the gap between the osinfo patch, the architecture parameters are being stored the same way as the OS info.
>
> We didn't add a specific architecture field on each cluster, because based on the cpu name and cluster compatibility version of the cluster the architecture can be determined. Do you think it is really necessary to add another way to describe the architecture of each cluster?

i think it would be much easier to specify the list of OSs per arch 
type, rather than per list of cpu's. it will also be easier to know if a 
VM can be created from a template based on their arch, rather than cpu 
lists (since x86_64 has a new cpu family every 6 months usually).
similarly, it will be easier to know if you can move a VM between two 
clusters, according to their arch, rather trying to understand if their 
cpu families allow that or not (you can move a VM between intel and amd 
cpu families).

so i think cluster arch is a good grouping for cpu families that are 
compatible.

(and I wonder if anyone will get to add an arm arch as well...)

in any case, I was very happy to see the set of patches arriving.

Thanks,
    Itamar

>
>>
>>>
>>>
>>> Phase 3
>>>
>>> 	The code for providing the support for IBM POWER systems will be added. The encapsulation done in the previous phase will reduce the effort to include this feature into the engine. The other changes that will be introduced in this phase include:
>>>
>>> 	- Modifications in the frontend to avoid running a VM created on a POWER host in a x86-64 host (and vice-versa),
>>> 	- All the dynamically provided capacities of the first phase will be implemented according to the capacities of the QEMU/KVM on POWER
>>> 	- The POWER processors will be available as an option in the list of
>>> processor names (this will imply in significant changes in the
>>> backend)
>>>
>>>
>>> Phase 4
>>>
>>> 	Adapt secondary features to polish the support for POWER:
>>>
>>> 	- OVF import and export of VMs running in POWER hosts
>>> 	- Dynamic searches capable of finding hosts, pools, vms and clusters
>>> according to their architectures
>>>
>>>
>>> Is there any ongoing oVirt architecture refactoring ? (that may
>>> conflict with Phase 1, for instance)
>> no, nothing major going on
>>
>>>
>>> Any comments ?
>> Looking forward to your patches!:-)
>>
>> Thanks,
>> michal
>>
>>>
>>> Regards,
>>> Vitor (vitor.lima at eldorado.org.br) / Leonardo
>>> (leonardo.bianconi at eldorado.org.br)
>>>
>>>
>>> -----Original Message-----
>>> From: Dave Neary [mailto:dneary at redhat.com]
>>> Sent: quarta-feira, 15 de maio de 2013 12:25
>>> To: Leonardo Bianconi
>>> Cc: arch at ovirt.org; Adam Litke
>>> Subject: Re: oVirt on IBM POWER (PPC64) - new feature contributors
>>>
>>> Hi,
>>>
>>> On 05/14/2013 08:05 PM, Leonardo Bianconi wrote:
>>>> We would like to introduce ourselves: Leonardo Bianconi and Vitor Lima.
>>>
>>> Welcome!
>>>
>>>> We would like to work on the features "Engine support for PPC64" (http://wiki.ovirt.org/Features/Engine_support_for_PPC64) and the "Vdsm for PPC64" (http://wiki.ovirt.org/Features/Vdsm_for_PPC64). This work has already been started by some developers at IBM.
>>>
>>> <snip>
>>>
>>>> About libosinfo:
>>>> =============
>>>>
>>>> In the previous discussion about this topic (http://lists.ovirt.org/pipermail/arch/2012-November/000976.html), occurred in November 2012, it was suggested that integrating the libosinfo into the engine would be a better way to handle the differences between the architectures that would be supported in the future.
>>>>
>>>> Is this approach still valid? If so, when will it be available? It seems to be a dependency for oVirt "Engine_support_for_PPC64" feature implementation.
>>>
>>>
>>> This is great news. I don't know who, specifically, has been working on this issue in IBM - perhaps Adam Litke (CCed) can update you on the progress that has been made.
>>
>>>
>>> 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
>>
>> _______________________________________________
>> Arch mailing list
>> Arch at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/arch
>>
>



From iheim at redhat.com  Thu Jul 11 19:42:48 2013
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 11 Jul 2013 22:42:48 +0300
Subject: oVirt on IBM POWER (PPC64) - new feature contributors
In-Reply-To: <51DEE8E5.2020806@redhat.com>
References: <50EB20226B72D6419356FC320AB62B871896B600@SERV070.corp.eldorado.org.br>
	<5193A8AE.5000600@redhat.com>
	<50EB20226B72D6419356FC320AB62B871896BB19@SERV070.corp.eldorado.org.br>
	<61C18AFB-AF93-48F3-BC90-6AA1B341DF27@redhat.com>
	<51A0B899.9030600@redhat.com>
	<50EB20226B72D6419356FC320AB62B8719170EE6@SERV070.corp.eldorado.org.br>
	<51DEE8E5.2020806@redhat.com>
Message-ID: <51DF0AB8.3080703@redhat.com>

On 07/11/2013 08:18 PM, Itamar Heim wrote:
> On 07/11/2013 08:04 PM, Leonardo Bianconi wrote:
>>
>>
>> -----Original Message-----
>> From: Itamar Heim [mailto:iheim at redhat.com]
>> Sent: s?bado, 25 de maio de 2013 10:12
>> To: Michal Skrivanek
>> Cc: Leonardo Bianconi; arch at ovirt.org; Roy Golan
>> Subject: Re: oVirt on IBM POWER (PPC64) - new feature contributors
>>
>> On 05/22/2013 10:46 AM, Michal Skrivanek wrote:
>>>
>>> On May 21, 2013, at 17:33 , Leonardo Bianconi
>>> <leonardo.bianconi at eldorado.org.br> wrote:
>>>
>>>> Hi all,
>>>>
>>>> We are planning to deliver support for PPC64 in 4 phases. We will
>>>> manage to deliver a set of patches at the end of each phase.
>>>>
>>>> Phase 1
>>>>
>>>>      Change oVirt to handle other architectures by encapsulating all
>>>> the architecture specific code and queries about the capabilities of
>>>> the hypervisor into a new class called ArchStrategy (based on the
>>>> Strategy Design Pattern). Every operation involving clusters and
>>>> hosts will be validated by this new class. Some hard-coded
>>>> parameters are going to be replaced by queries in the backend in
>>>> order to accommodate the support for new architectures into the engine.
>>>
>>> If you would like to discuss some internals or if anything is unclear
>>> please feel free to set up a quick mtg with myself, Omer and Roy.
>>> Sometimes (e.g. in the case of VmInterfaceType as mentioned on
>>> feature page) it would be actually beneficial for oVirt on x86 as
>>> well to have a greater flexibility directly in the code, without
>>> Strategy encapsulation.
>>>
>>>>
>>>>
>>>> Phase 2
>>>>
>>>>     Currently, each host hypervisor capabilities are obtained using
>>>> hard-coded data structures. These structures will be replaced either
>>>> by some form of integration with libosinfo or by reading internal
>>>> configuration files describing these capabilities. It will be
>>>> handled after Roy's patch.
>>> Roy's osinfo will soon be merged.
>>
>> link to patches?
>> does it cover adding arch at cluster level?
>>
>> Sorry about the late reply. We have already handled the gap between
>> the osinfo patch, the architecture parameters are being stored the
>> same way as the OS info.
>>
>> We didn't add a specific architecture field on each cluster, because
>> based on the cpu name and cluster compatibility version of the cluster
>> the architecture can be determined. Do you think it is really
>> necessary to add another way to describe the architecture of each
>> cluster?
>
> i think it would be much easier to specify the list of OSs per arch
> type, rather than per list of cpu's. it will also be easier to know if a
> VM can be created from a template based on their arch, rather than cpu
> lists (since x86_64 has a new cpu family every 6 months usually).
> similarly, it will be easier to know if you can move a VM between two
> clusters, according to their arch, rather trying to understand if their
> cpu families allow that or not (you can move a VM between intel and amd
> cpu families).
>
> so i think cluster arch is a good grouping for cpu families that are
> compatible.
>
> (and I wonder if anyone will get to add an arm arch as well...)
>
> in any case, I was very happy to see the set of patches arriving.


i took a look at the patches and commented on some things on them.

assuming i undestood it correclty,  i think i under stand how you tried 
to avoid the need for arch by having it implied from the cpu family.

could be just a matter of taste, i guess even if i didn't want user to 
set it per cluster, i'd still add a field for it and persist it, then 
use the persisted field instead of all the code/strategies around it?

another question is around the new arch repo - do we need per arch 
definitions, or in any case OSs would be per arch (even if they are the 
same), hence any fine tuning per arch could be done at the "default os" 
of that arch?

it seems similarly, instead of keeping an arch field for a VM or 
template, you are just assuming it based on the cluster its in.

for VMs, this could be enough as long as they are in the system.
I'm a bit torn about templates, since it seems you are re-using the 
cluster approach for them as well. however, for a template, which is a 
DC level entity, the cluster is just a default cluster.
more so, with the advent of instance types, which are just images, 
without a default cluster.

it also seems we'll be losing the information on which arch a 
vm/template belong to when exporting it (user will have to import it to 
the "right cluster" for that cluster to imply the arch)?

Thanks,
    Itamar


>
> Thanks,
>     Itamar
>
>>
>>>
>>>>
>>>>
>>>> Phase 3
>>>>
>>>>     The code for providing the support for IBM POWER systems will be
>>>> added. The encapsulation done in the previous phase will reduce the
>>>> effort to include this feature into the engine. The other changes
>>>> that will be introduced in this phase include:
>>>>
>>>>     - Modifications in the frontend to avoid running a VM created on
>>>> a POWER host in a x86-64 host (and vice-versa),
>>>>     - All the dynamically provided capacities of the first phase
>>>> will be implemented according to the capacities of the QEMU/KVM on
>>>> POWER
>>>>     - The POWER processors will be available as an option in the
>>>> list of
>>>> processor names (this will imply in significant changes in the
>>>> backend)
>>>>
>>>>
>>>> Phase 4
>>>>
>>>>     Adapt secondary features to polish the support for POWER:
>>>>
>>>>     - OVF import and export of VMs running in POWER hosts
>>>>     - Dynamic searches capable of finding hosts, pools, vms and
>>>> clusters
>>>> according to their architectures
>>>>
>>>>
>>>> Is there any ongoing oVirt architecture refactoring ? (that may
>>>> conflict with Phase 1, for instance)
>>> no, nothing major going on
>>>
>>>>
>>>> Any comments ?
>>> Looking forward to your patches!:-)
>>>
>>> Thanks,
>>> michal
>>>
>>>>
>>>> Regards,
>>>> Vitor (vitor.lima at eldorado.org.br) / Leonardo
>>>> (leonardo.bianconi at eldorado.org.br)
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Dave Neary [mailto:dneary at redhat.com]
>>>> Sent: quarta-feira, 15 de maio de 2013 12:25
>>>> To: Leonardo Bianconi
>>>> Cc: arch at ovirt.org; Adam Litke
>>>> Subject: Re: oVirt on IBM POWER (PPC64) - new feature contributors
>>>>
>>>> Hi,
>>>>
>>>> On 05/14/2013 08:05 PM, Leonardo Bianconi wrote:
>>>>> We would like to introduce ourselves: Leonardo Bianconi and Vitor
>>>>> Lima.
>>>>
>>>> Welcome!
>>>>
>>>>> We would like to work on the features "Engine support for PPC64"
>>>>> (http://wiki.ovirt.org/Features/Engine_support_for_PPC64) and the
>>>>> "Vdsm for PPC64" (http://wiki.ovirt.org/Features/Vdsm_for_PPC64).
>>>>> This work has already been started by some developers at IBM.
>>>>
>>>> <snip>
>>>>
>>>>> About libosinfo:
>>>>> =============
>>>>>
>>>>> In the previous discussion about this topic
>>>>> (http://lists.ovirt.org/pipermail/arch/2012-November/000976.html),
>>>>> occurred in November 2012, it was suggested that integrating the
>>>>> libosinfo into the engine would be a better way to handle the
>>>>> differences between the architectures that would be supported in
>>>>> the future.
>>>>>
>>>>> Is this approach still valid? If so, when will it be available? It
>>>>> seems to be a dependency for oVirt "Engine_support_for_PPC64"
>>>>> feature implementation.
>>>>
>>>>
>>>> This is great news. I don't know who, specifically, has been working
>>>> on this issue in IBM - perhaps Adam Litke (CCed) can update you on
>>>> the progress that has been made.
>>>
>>>>
>>>> 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
>>>
>>> _______________________________________________
>>> Arch mailing list
>>> Arch at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/arch
>>>
>>
>



From leonardo.bianconi at eldorado.org.br  Fri Jul 12 12:52:42 2013
From: leonardo.bianconi at eldorado.org.br (Leonardo Bianconi)
Date: Fri, 12 Jul 2013 12:52:42 +0000
Subject: oVirt on IBM POWER (PPC64) - new feature contributors
In-Reply-To: <51DEE8E5.2020806@redhat.com>
References: <50EB20226B72D6419356FC320AB62B871896B600@SERV070.corp.eldorado.org.br>
	<5193A8AE.5000600@redhat.com>
	<50EB20226B72D6419356FC320AB62B871896BB19@SERV070.corp.eldorado.org.br>
	<61C18AFB-AF93-48F3-BC90-6AA1B341DF27@redhat.com>
	<51A0B899.9030600@redhat.com>
	<50EB20226B72D6419356FC320AB62B8719170EE6@SERV070.corp.eldorado.org.br>
	<51DEE8E5.2020806@redhat.com>
Message-ID: <50EB20226B72D6419356FC320AB62B8719170F7F@SERV070.corp.eldorado.org.br>



>-----Original Message-----
>From: Itamar Heim [mailto:iheim at redhat.com]
>Sent: quinta-feira, 11 de julho de 2013 14:18
>To: Leonardo Bianconi
>Cc: Michal Skrivanek; arch at ovirt.org; Roy Golan
>Subject: Re: oVirt on IBM POWER (PPC64) - new feature contributors
>
>On 07/11/2013 08:04 PM, Leonardo Bianconi wrote:
>>
>>
>> -----Original Message-----
>> From: Itamar Heim [mailto:iheim at redhat.com]
>> Sent: s?bado, 25 de maio de 2013 10:12
>> To: Michal Skrivanek
>> Cc: Leonardo Bianconi; arch at ovirt.org; Roy Golan
>> Subject: Re: oVirt on IBM POWER (PPC64) - new feature contributors
>>
>> On 05/22/2013 10:46 AM, Michal Skrivanek wrote:
>>>
>>> On May 21, 2013, at 17:33 , Leonardo Bianconi <leonardo.bianconi at eldorado.org.br> wrote:
>>>
>>>> Hi all,
>>>>
>>>> We are planning to deliver support for PPC64 in 4 phases. We will manage to deliver a set of patches at the end of each phase.
>>>>
>>>> Phase 1
>>>>
>>>> 	 Change oVirt to handle other architectures by encapsulating all the architecture specific code and queries about the
>capabilities of the hypervisor into a new class called ArchStrategy (based on the Strategy Design Pattern). Every operation involving
>clusters and hosts will be validated by this new class. Some hard-coded parameters are going to be replaced by queries in the backend
>in order to accommodate the support for new architectures into the engine.
>>>
>>> If you would like to discuss some internals or if anything is unclear please feel free to set up a quick mtg with myself, Omer and
>Roy.
>>> Sometimes (e.g. in the case of VmInterfaceType as mentioned on feature page) it would be actually beneficial for oVirt on x86 as
>well to have a greater flexibility directly in the code, without Strategy encapsulation.
>>>
>>>>
>>>>
>>>> Phase 2
>>>>
>>>> 	Currently, each host hypervisor capabilities are obtained using hard-coded data structures. These structures will be replaced
>either by some form of integration with libosinfo or by reading internal configuration files describing these capabilities. It will be
>handled after Roy's patch.
>>> Roy's osinfo will soon be merged.
>>
>>> link to patches?
>>> does it cover adding arch at cluster level?
>>
>> Sorry about the late reply. We have already handled the gap between the osinfo patch, the architecture parameters are being
>stored the same way as the OS info.
>>
>> We didn't add a specific architecture field on each cluster, because based on the cpu name and cluster compatibility version of the
>cluster the architecture can be determined. Do you think it is really necessary to add another way to describe the architecture of each
>cluster?
>
>i think it would be much easier to specify the list of OSs per arch type, rather than per list of cpu's. it will also be easier to know if a VM
>can be created from a template based on their arch, rather than cpu lists (since x86_64 has a new cpu family every 6 months usually).

We are not specifying the OS (or any other architecture specific detail) based on the cpu family directly. The ServerCpuList was modified to associate each
processor family name to an architecture (currently there are only two possible values for this association, x86_64 and ppc64). For example:

"3:Intel Conroe Family:vmx,nx,model_Conroe:Conroe:x86_64"

Every architecture specific operation checks which is the associated architecture, and all the operations are done based only on this value. When initializing the engine this parameter is read by CpuFlagsManagerHandler. The OS property file (osinfo-defaults.properties) contains the architecture for each OS, so internally the ArchStrategy (the class responsible for abstracting architecture specific code) checks the compatibility based on the architecture name, not on the cpu family.

>similarly, it will be easier to know if you can move a VM between two clusters, according to their arch, rather trying to understand if
>their cpu families allow that or not (you can move a VM between intel and amd cpu families).

Actually we have already thought about it. The ArchStrategy class has a method to compare two CPU families and return if they are compatible. On this case, like above, it is using the architecture name added for each cpu family on the ServerCpuList and will be compatible only if both CPUs have the same architecture.

Another advantage besides having the architecture encapsulated in the ArchStrategy is that every place on the code that the cpu name and compatibility version is accessible, the ArchStrategy can be obtained and there is no need to retrieve the cluster object.



We are checking the comments on the patch and we will reply soon.

>
>so i think cluster arch is a good grouping for cpu families that are compatible.
>
>(and I wonder if anyone will get to add an arm arch as well...)
>
>in any case, I was very happy to see the set of patches arriving.
>
>Thanks,
>    Itamar
>
>>
>>>
>>>>
>>>>
>>>> Phase 3
>>>>
>>>> 	The code for providing the support for IBM POWER systems will be added. The encapsulation done in the previous phase will
>reduce the effort to include this feature into the engine. The other changes that will be introduced in this phase include:
>>>>
>>>> 	- Modifications in the frontend to avoid running a VM created on a POWER host in a x86-64 host (and vice-versa),
>>>> 	- All the dynamically provided capacities of the first phase will be implemented according to the capacities of the QEMU/KVM
>on POWER
>>>> 	- The POWER processors will be available as an option in the list
>>>> of processor names (this will imply in significant changes in the
>>>> backend)
>>>>
>>>>
>>>> Phase 4
>>>>
>>>> 	Adapt secondary features to polish the support for POWER:
>>>>
>>>> 	- OVF import and export of VMs running in POWER hosts
>>>> 	- Dynamic searches capable of finding hosts, pools, vms and
>>>> clusters according to their architectures
>>>>
>>>>
>>>> Is there any ongoing oVirt architecture refactoring ? (that may
>>>> conflict with Phase 1, for instance)
>>> no, nothing major going on
>>>
>>>>
>>>> Any comments ?
>>> Looking forward to your patches!:-)
>>>
>>> Thanks,
>>> michal
>>>
>>>>
>>>> Regards,
>>>> Vitor (vitor.lima at eldorado.org.br) / Leonardo
>>>> (leonardo.bianconi at eldorado.org.br)
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Dave Neary [mailto:dneary at redhat.com]
>>>> Sent: quarta-feira, 15 de maio de 2013 12:25
>>>> To: Leonardo Bianconi
>>>> Cc: arch at ovirt.org; Adam Litke
>>>> Subject: Re: oVirt on IBM POWER (PPC64) - new feature contributors
>>>>
>>>> Hi,
>>>>
>>>> On 05/14/2013 08:05 PM, Leonardo Bianconi wrote:
>>>>> We would like to introduce ourselves: Leonardo Bianconi and Vitor Lima.
>>>>
>>>> Welcome!
>>>>
>>>>> We would like to work on the features "Engine support for PPC64" (http://wiki.ovirt.org/Features/Engine_support_for_PPC64)
>and the "Vdsm for PPC64" (http://wiki.ovirt.org/Features/Vdsm_for_PPC64). This work has already been started by some developers
>at IBM.
>>>>
>>>> <snip>
>>>>
>>>>> About libosinfo:
>>>>> =============
>>>>>
>>>>> In the previous discussion about this topic (http://lists.ovirt.org/pipermail/arch/2012-November/000976.html), occurred in
>November 2012, it was suggested that integrating the libosinfo into the engine would be a better way to handle the differences
>between the architectures that would be supported in the future.
>>>>>
>>>>> Is this approach still valid? If so, when will it be available? It seems to be a dependency for oVirt "Engine_support_for_PPC64"
>feature implementation.
>>>>
>>>>
>>>> This is great news. I don't know who, specifically, has been working on this issue in IBM - perhaps Adam Litke (CCed) can update
>you on the progress that has been made.
>>>
>>>>
>>>> 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
>>>
>>> _______________________________________________
>>> Arch mailing list
>>> Arch at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/arch
>>>
>>



From iheim at redhat.com  Fri Jul 12 15:09:46 2013
From: iheim at redhat.com (Itamar Heim)
Date: Fri, 12 Jul 2013 18:09:46 +0300
Subject: oVirt on IBM POWER (PPC64) - new feature contributors
In-Reply-To: <50EB20226B72D6419356FC320AB62B8719170F7F@SERV070.corp.eldorado.org.br>
References: <50EB20226B72D6419356FC320AB62B871896B600@SERV070.corp.eldorado.org.br>
	<5193A8AE.5000600@redhat.com>
	<50EB20226B72D6419356FC320AB62B871896BB19@SERV070.corp.eldorado.org.br>
	<61C18AFB-AF93-48F3-BC90-6AA1B341DF27@redhat.com>
	<51A0B899.9030600@redhat.com>
	<50EB20226B72D6419356FC320AB62B8719170EE6@SERV070.corp.eldorado.org.br>
	<51DEE8E5.2020806@redhat.com>
	<50EB20226B72D6419356FC320AB62B8719170F7F@SERV070.corp.eldorado.org.br>
Message-ID: <51E01C3A.9010903@redhat.com>

On 07/12/2013 03:52 PM, Leonardo Bianconi wrote:
>
>
>> -----Original Message-----
>> From: Itamar Heim [mailto:iheim at redhat.com]
>> Sent: quinta-feira, 11 de julho de 2013 14:18
>> To: Leonardo Bianconi
>> Cc: Michal Skrivanek; arch at ovirt.org; Roy Golan
>> Subject: Re: oVirt on IBM POWER (PPC64) - new feature contributors
>>
>> On 07/11/2013 08:04 PM, Leonardo Bianconi wrote:
>>>
>>>
>>> -----Original Message-----
>>> From: Itamar Heim [mailto:iheim at redhat.com]
>>> Sent: s?bado, 25 de maio de 2013 10:12
>>> To: Michal Skrivanek
>>> Cc: Leonardo Bianconi; arch at ovirt.org; Roy Golan
>>> Subject: Re: oVirt on IBM POWER (PPC64) - new feature contributors
>>>
>>> On 05/22/2013 10:46 AM, Michal Skrivanek wrote:
>>>>
>>>> On May 21, 2013, at 17:33 , Leonardo Bianconi <leonardo.bianconi at eldorado.org.br> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> We are planning to deliver support for PPC64 in 4 phases. We will manage to deliver a set of patches at the end of each phase.
>>>>>
>>>>> Phase 1
>>>>>
>>>>> 	 Change oVirt to handle other architectures by encapsulating all the architecture specific code and queries about the
>> capabilities of the hypervisor into a new class called ArchStrategy (based on the Strategy Design Pattern). Every operation involving
>> clusters and hosts will be validated by this new class. Some hard-coded parameters are going to be replaced by queries in the backend
>> in order to accommodate the support for new architectures into the engine.
>>>>
>>>> If you would like to discuss some internals or if anything is unclear please feel free to set up a quick mtg with myself, Omer and
>> Roy.
>>>> Sometimes (e.g. in the case of VmInterfaceType as mentioned on feature page) it would be actually beneficial for oVirt on x86 as
>> well to have a greater flexibility directly in the code, without Strategy encapsulation.
>>>>
>>>>>
>>>>>
>>>>> Phase 2
>>>>>
>>>>> 	Currently, each host hypervisor capabilities are obtained using hard-coded data structures. These structures will be replaced
>> either by some form of integration with libosinfo or by reading internal configuration files describing these capabilities. It will be
>> handled after Roy's patch.
>>>> Roy's osinfo will soon be merged.
>>>
>>>> link to patches?
>>>> does it cover adding arch at cluster level?
>>>
>>> Sorry about the late reply. We have already handled the gap between the osinfo patch, the architecture parameters are being
>> stored the same way as the OS info.
>>>
>>> We didn't add a specific architecture field on each cluster, because based on the cpu name and cluster compatibility version of the
>> cluster the architecture can be determined. Do you think it is really necessary to add another way to describe the architecture of each
>> cluster?
>>
>> i think it would be much easier to specify the list of OSs per arch type, rather than per list of cpu's. it will also be easier to know if a VM
>> can be created from a template based on their arch, rather than cpu lists (since x86_64 has a new cpu family every 6 months usually).
>
> We are not specifying the OS (or any other architecture specific detail) based on the cpu family directly. The ServerCpuList was modified to associate each
> processor family name to an architecture (currently there are only two possible values for this association, x86_64 and ppc64). For example:
>
> "3:Intel Conroe Family:vmx,nx,model_Conroe:Conroe:x86_64"
>
> Every architecture specific operation checks which is the associated architecture, and all the operations are done based only on this value. When initializing the engine this parameter is read by CpuFlagsManagerHandler. The OS property file (osinfo-defaults.properties) contains the architecture for each OS, so internally the ArchStrategy (the class responsible for abstracting architecture specific code) checks the compatibility based on the architecture name, not on the cpu family.

yes, i saw that, and it will work (just more code level comparisons than 
db ones, but as i said, just a matter of taste and i'm not strongly 
opinionated about this).

the question is if arch specific are part of the OS (there is a 
RHEL6_x64 and a RHEL6_ppc7 OSs).

if we separate the OSs, than why do we need the arch level repo, as you 
can do the limitation on the base default_os_ppc7?

the other concern is behavior with export/import.
since some issues are also discussed at patch level - lets move there 
and come back here if there is a conceptual issue worth revisiting.

one question though to help me read the patches - what guest OSs can run 
on ppc7 arch (fedora? .el6? debian? other (i know windows isn't 
relevant, but what to expect there)?

Thanks,
    Itamar

>
>> similarly, it will be easier to know if you can move a VM between two clusters, according to their arch, rather trying to understand if
>> their cpu families allow that or not (you can move a VM between intel and amd cpu families).
>
> Actually we have already thought about it. The ArchStrategy class has a method to compare two CPU families and return if they are compatible. On this case, like above, it is using the architecture name added for each cpu family on the ServerCpuList and will be compatible only if both CPUs have the same architecture.
>
> Another advantage besides having the architecture encapsulated in the ArchStrategy is that every place on the code that the cpu name and compatibility version is accessible, the ArchStrategy can be obtained and there is no need to retrieve the cluster object.
>
>
>
> We are checking the comments on the patch and we will reply soon.
>
>>
>> so i think cluster arch is a good grouping for cpu families that are compatible.
>>
>> (and I wonder if anyone will get to add an arm arch as well...)
>>
>> in any case, I was very happy to see the set of patches arriving.
>>
>> Thanks,
>>     Itamar
>>
>>>
>>>>
>>>>>
>>>>>
>>>>> Phase 3
>>>>>
>>>>> 	The code for providing the support for IBM POWER systems will be added. The encapsulation done in the previous phase will
>> reduce the effort to include this feature into the engine. The other changes that will be introduced in this phase include:
>>>>>
>>>>> 	- Modifications in the frontend to avoid running a VM created on a POWER host in a x86-64 host (and vice-versa),
>>>>> 	- All the dynamically provided capacities of the first phase will be implemented according to the capacities of the QEMU/KVM
>> on POWER
>>>>> 	- The POWER processors will be available as an option in the list
>>>>> of processor names (this will imply in significant changes in the
>>>>> backend)
>>>>>
>>>>>
>>>>> Phase 4
>>>>>
>>>>> 	Adapt secondary features to polish the support for POWER:
>>>>>
>>>>> 	- OVF import and export of VMs running in POWER hosts
>>>>> 	- Dynamic searches capable of finding hosts, pools, vms and
>>>>> clusters according to their architectures
>>>>>
>>>>>
>>>>> Is there any ongoing oVirt architecture refactoring ? (that may
>>>>> conflict with Phase 1, for instance)
>>>> no, nothing major going on
>>>>
>>>>>
>>>>> Any comments ?
>>>> Looking forward to your patches!:-)
>>>>
>>>> Thanks,
>>>> michal
>>>>
>>>>>
>>>>> Regards,
>>>>> Vitor (vitor.lima at eldorado.org.br) / Leonardo
>>>>> (leonardo.bianconi at eldorado.org.br)
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Dave Neary [mailto:dneary at redhat.com]
>>>>> Sent: quarta-feira, 15 de maio de 2013 12:25
>>>>> To: Leonardo Bianconi
>>>>> Cc: arch at ovirt.org; Adam Litke
>>>>> Subject: Re: oVirt on IBM POWER (PPC64) - new feature contributors
>>>>>
>>>>> Hi,
>>>>>
>>>>> On 05/14/2013 08:05 PM, Leonardo Bianconi wrote:
>>>>>> We would like to introduce ourselves: Leonardo Bianconi and Vitor Lima.
>>>>>
>>>>> Welcome!
>>>>>
>>>>>> We would like to work on the features "Engine support for PPC64" (http://wiki.ovirt.org/Features/Engine_support_for_PPC64)
>> and the "Vdsm for PPC64" (http://wiki.ovirt.org/Features/Vdsm_for_PPC64). This work has already been started by some developers
>> at IBM.
>>>>>
>>>>> <snip>
>>>>>
>>>>>> About libosinfo:
>>>>>> =============
>>>>>>
>>>>>> In the previous discussion about this topic (http://lists.ovirt.org/pipermail/arch/2012-November/000976.html), occurred in
>> November 2012, it was suggested that integrating the libosinfo into the engine would be a better way to handle the differences
>> between the architectures that would be supported in the future.
>>>>>>
>>>>>> Is this approach still valid? If so, when will it be available? It seems to be a dependency for oVirt "Engine_support_for_PPC64"
>> feature implementation.
>>>>>
>>>>>
>>>>> This is great news. I don't know who, specifically, has been working on this issue in IBM - perhaps Adam Litke (CCed) can update
>> you on the progress that has been made.
>>>>
>>>>>
>>>>> 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
>>>>
>>>> _______________________________________________
>>>> Arch mailing list
>>>> Arch at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/arch
>>>>
>>>
>



From gvallare at redhat.com  Sun Jul 14 08:36:45 2013
From: gvallare at redhat.com (Giuseppe Vallarelli)
Date: Sun, 14 Jul 2013 04:36:45 -0400 (EDT)
Subject: network and vnic qos
In-Reply-To: <138549202.56945.1373786536742.JavaMail.root@redhat.com>
References: <293956441.3359594.1373555699680.JavaMail.root@redhat.com>
	<138549202.56945.1373786536742.JavaMail.root@redhat.com>
Message-ID: <1614927894.239343.1373791005929.JavaMail.root@redhat.com>

----- Original Message -----
| From: "Ofri Masad" <omasad at redhat.com>
| To: "Giuseppe Vallarelli" <gvallare at redhat.com>
| Cc: arch at ovirt.org, "Moti Asayag" <masayag at redhat.com>, "Mike Kolesnik" <mkolesni at redhat.com>, "Michal Privoznik"
| <mprivozn at redhat.com>, "Doron Fediuck" <dfediuck at redhat.com>
| Sent: Sunday, July 14, 2013 9:22:16 AM
| Subject: Re: network and vnic qos
| 
| Hi Giuseppe,

Hi Ofri,

| First of all, thanks for reviewing the design and the implementation.
| as for your comments, as I see it, we need to separate between what we can do
| (using libvirt) and what we would like to expose to the user.
| in my point of view, when a user is working with out engine (in appose to
| working directly with libvirt or vdsm) he expects different things.
| this is why we sometime take different choices from libvirt, to make the
| usage more simple/intuitive, to allow more complex abstraction
| or to get better control over the full system.

I understand the need of taking different decisions or not being completely
tied to the underlying implementation. What I feel is that libvirt is much
more flexible and we're limiting the usage. If you feel this the right way to
go it's perfectly fine to me. In case users will have different expectations
than we might revise this decision in the future.  

| 
| specific comment inline
|      
| ----- Original Message -----
| > From: "Giuseppe Vallarelli" <gvallare at redhat.com>
| > To: arch at ovirt.org
| > Cc: "Ofri Masad" <omasad at redhat.com>, "Moti Asayag" <masayag at redhat.com>,
| > "Mike Kolesnik" <mkolesni at redhat.com>,
| > "Michal Privoznik" <mprivozn at redhat.com>
| > Sent: Thursday, July 11, 2013 6:14:59 PM
| > Subject: network and vnic qos
| > 
| > Hi Ofri, me, Moti and Mike have been looking carefully through the design
| > spec of the vnic profiles[0]
| > and lately to the network traffic shaping [1] which is very closely
| > related.
| > A reason of concern is the current design of network qos table[2].
| > 
| > First issue is the one related to the attributes associated to the traffic
| > shaping (either inbound
| > or outbound), I got the chance to talk with Michal (a libvirt developer in
| > Brno) which confirmed me
| > that the only compulsory attribute is average both burst and peak are
| > optional, also he told me that
| > libvirt doesn't provide any default values in case those are missing ones.
| > Looking at missingValue()
| > method in [3] seems that all 3 values are compulsory.
| 
| By not defining the other two values, we actually leave the decision to
| libvirt. that means that the different libvirt releases
| may take different decision. when the user is setting a specific QoS for his
| network, he expect to see the same behavior over
| all of the VNICs using that QoS (even if they are running on different
| libvirt versions).

I will let Michal answer to this specific concern, I'm not fully convinced
that libvirt might place default values for unspecified attributes in the future.

 setting all three values in the engine
| allows us to force this unity. I will, however, add some default relations to
| the UI. so that when a user is setting the Average
| value, the Peak and Burst values will be automatically derived (but could be
| edited, of course).
| 
| > 
| > Second issue is mostly related to the decision of creating a single table
| > with traffic shaping
| > for both incoming and outgoing traffic (in table defined respectively as
| > inbound and outbound).
| > Incoming and outgoing traffic are independent and practically the same. If
| > a
| > network admin defines
| > only incoming traffic, outgoing traffic attributes are nulls.
| > 
| > An alternative approach that we discussed is the following one: a table
| > named
| > simply qos
| > or if you prefer qos_profile with the three attributes average (not null),
| > burst and peak and an id.
| > In this case after the user creates a profile, that one can be associated,
| > as
| > you defined in your spec,
| > to a vnic (and in the future to a network). I'm not sure if we need a
| > different attribute
| > to specify for convenience the traffic at which the qos profile is applied
| > (incoming/inbound, ougoing/outbound).
| 
| As for the difference between inbound and outbound, this is one of the most
| common use cases, i believe both your home and office
| networks have different inbound and outbound limits.
| As for the single table. first, in the future we plan on adding another
| attribute, "floor". which apply only to outbound.
| second, I don't really see in what way this is better than the current design

For how you've conceived the traffic shaping, which means having the user
define all values and traffic type, my proposal is no better than yours
but I was looking from a different angle.

| - and so I don't see why we should rewrite this
| feature from scratch one day before feature freeze.

There's no need to do that, right now, as said previously.

Thanks Giuseppe

| 
| > 
| > Cheers, Giuseppe
| > 
| > 
| > [0]http://www.ovirt.org/Features/Network_QoS
| > [1]http://www.ovirt.org/Features/Network_traffic_shaping
| > [2]http://gerrit.ovirt.org/#/c/16294/8/packaging/dbscripts/upgrade/03_03_0400_add_network_qos_tabel.sql
| > [3]http://gerrit.ovirt.org/#/c/16294/8/backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/qos/NetworkQoSCommandBase.java
| > 
| 
| thanks again,
| 
| Ofri
| 


From gvallare at redhat.com  Sun Jul 14 09:23:38 2013
From: gvallare at redhat.com (Giuseppe Vallarelli)
Date: Sun, 14 Jul 2013 05:23:38 -0400 (EDT)
Subject: network and vnic qos
In-Reply-To: <1368561802.241998.1373793362311.JavaMail.root@redhat.com>
References: <293956441.3359594.1373555699680.JavaMail.root@redhat.com>
	<138549202.56945.1373786536742.JavaMail.root@redhat.com>
	<1614927894.239343.1373791005929.JavaMail.root@redhat.com>
	<1368561802.241998.1373793362311.JavaMail.root@redhat.com>
Message-ID: <1542134556.242161.1373793818922.JavaMail.root@redhat.com>

----- Original Message -----
| From: "Doron Fediuck" <dfediuck at redhat.com>
| To: "Giuseppe Vallarelli" <gvallare at redhat.com>
| Cc: "Ofri Masad" <omasad at redhat.com>, arch at ovirt.org, "Moti Asayag" <masayag at redhat.com>, "Mike Kolesnik"
| <mkolesni at redhat.com>, "Michal Privoznik" <mprivozn at redhat.com>
| Sent: Sunday, July 14, 2013 11:16:02 AM
| Subject: Re: network and vnic qos
| 
| 
| 
| ----- Original Message -----
| | From: "Giuseppe Vallarelli" <gvallare at redhat.com>
| | To: "Ofri Masad" <omasad at redhat.com>
| | Cc: arch at ovirt.org, "Moti Asayag" <masayag at redhat.com>, "Mike Kolesnik"
| | <mkolesni at redhat.com>, "Michal Privoznik"
| | <mprivozn at redhat.com>, "Doron Fediuck" <dfediuck at redhat.com>
| | Sent: Sunday, July 14, 2013 11:36:45 AM
| | Subject: Re: network and vnic qos
| | 
| | ----- Original Message -----
| | | From: "Ofri Masad" <omasad at redhat.com>
| | | To: "Giuseppe Vallarelli" <gvallare at redhat.com>
| | | Cc: arch at ovirt.org, "Moti Asayag" <masayag at redhat.com>, "Mike Kolesnik"
| | | <mkolesni at redhat.com>, "Michal Privoznik"
| | | <mprivozn at redhat.com>, "Doron Fediuck" <dfediuck at redhat.com>
| | | Sent: Sunday, July 14, 2013 9:22:16 AM
| | | Subject: Re: network and vnic qos
| | | 
| | | Hi Giuseppe,
| | 
| | Hi Ofri,
| | 
| | | First of all, thanks for reviewing the design and the implementation.
| | | as for your comments, as I see it, we need to separate between what we
| | | can
| | | do
| | | (using libvirt) and what we would like to expose to the user.
| | | in my point of view, when a user is working with out engine (in appose to
| | | working directly with libvirt or vdsm) he expects different things.
| | | this is why we sometime take different choices from libvirt, to make the
| | | usage more simple/intuitive, to allow more complex abstraction
| | | or to get better control over the full system.
| | 
| | I understand the need of taking different decisions or not being completely
| | tied to the underlying implementation. What I feel is that libvirt is much
| | more flexible and we're limiting the usage. If you feel this the right way
| | to
| | go it's perfectly fine to me. In case users will have different
| | expectations
| | than we might revise this decision in the future.
| | 
| | | 
| | | specific comment inline
| | |      
| | | ----- Original Message -----
| | | > From: "Giuseppe Vallarelli" <gvallare at redhat.com>
| | | > To: arch at ovirt.org
| | | > Cc: "Ofri Masad" <omasad at redhat.com>, "Moti Asayag"
| | | > <masayag at redhat.com>,
| | | > "Mike Kolesnik" <mkolesni at redhat.com>,
| | | > "Michal Privoznik" <mprivozn at redhat.com>
| | | > Sent: Thursday, July 11, 2013 6:14:59 PM
| | | > Subject: network and vnic qos
| | | > 
| | | > Hi Ofri, me, Moti and Mike have been looking carefully through the
| | | > design
| | | > spec of the vnic profiles[0]
| | | > and lately to the network traffic shaping [1] which is very closely
| | | > related.
| | | > A reason of concern is the current design of network qos table[2].
| | | > 
| | | > First issue is the one related to the attributes associated to the
| | | > traffic
| | | > shaping (either inbound
| | | > or outbound), I got the chance to talk with Michal (a libvirt developer
| | | > in
| | | > Brno) which confirmed me
| | | > that the only compulsory attribute is average both burst and peak are
| | | > optional, also he told me that
| | | > libvirt doesn't provide any default values in case those are missing
| | | > ones.
| | | > Looking at missingValue()
| | | > method in [3] seems that all 3 values are compulsory.
| | | 
| | | By not defining the other two values, we actually leave the decision to
| | | libvirt. that means that the different libvirt releases
| | | may take different decision. when the user is setting a specific QoS for
| | | his
| | | network, he expect to see the same behavior over
| | | all of the VNICs using that QoS (even if they are running on different
| | | libvirt versions).
| | 
| | I will let Michal answer to this specific concern, I'm not fully convinced
| | that libvirt might place default values for unspecified attributes in the
| | future.
| | 
| 
| Giuseppe, you need to remember that a value may not necessarily be a number.
| It can also be a formula which will behave differently on overutilized VS
| underutilized hosts. Either way, undefined means exactly that. As a concept
| SLA cannot assume it, or we're loosing the upper bound capabilities.

Hi Doron, thanks for the explanation I wasn't aware of this concern.

| So for this reasoning we will start with as stable implementation as
| possible.
| Going forwards we may re-visit based on users feedback.

Ok, I'm going to update my proposal to conform with this choice.
Thanks for the feedback!

Cheers, Giuseppe

| 
| |  setting all three values in the engine
| | | allows us to force this unity. I will, however, add some default
| | | relations
| | | to
| | | the UI. so that when a user is setting the Average
| | | value, the Peak and Burst values will be automatically derived (but could
| | | be
| | | edited, of course).
| | | 
| | | > 
| | | > Second issue is mostly related to the decision of creating a single
| | | > table
| | | > with traffic shaping
| | | > for both incoming and outgoing traffic (in table defined respectively
| | | > as
| | | > inbound and outbound).
| | | > Incoming and outgoing traffic are independent and practically the same.
| | | > If
| | | > a
| | | > network admin defines
| | | > only incoming traffic, outgoing traffic attributes are nulls.
| | | > 
| | | > An alternative approach that we discussed is the following one: a table
| | | > named
| | | > simply qos
| | | > or if you prefer qos_profile with the three attributes average (not
| | | > null),
| | | > burst and peak and an id.
| | | > In this case after the user creates a profile, that one can be
| | | > associated,
| | | > as
| | | > you defined in your spec,
| | | > to a vnic (and in the future to a network). I'm not sure if we need a
| | | > different attribute
| | | > to specify for convenience the traffic at which the qos profile is
| | | > applied
| | | > (incoming/inbound, ougoing/outbound).
| | | 
| | | As for the difference between inbound and outbound, this is one of the
| | | most
| | | common use cases, i believe both your home and office
| | | networks have different inbound and outbound limits.
| | | As for the single table. first, in the future we plan on adding another
| | | attribute, "floor". which apply only to outbound.
| | | second, I don't really see in what way this is better than the current
| | | design
| | 
| | For how you've conceived the traffic shaping, which means having the user
| | define all values and traffic type, my proposal is no better than yours
| | but I was looking from a different angle.
| | 
| | | - and so I don't see why we should rewrite this
| | | feature from scratch one day before feature freeze.
| | 
| | There's no need to do that, right now, as said previously.
| | 
| | Thanks Giuseppe
| | 
| | | 
| | | > 
| | | > Cheers, Giuseppe
| | | > 
| | | > 
| | | > [0]http://www.ovirt.org/Features/Network_QoS
| | | > [1]http://www.ovirt.org/Features/Network_traffic_shaping
| | | > [2]http://gerrit.ovirt.org/#/c/16294/8/packaging/dbscripts/upgrade/03_03_0400_add_network_qos_tabel.sql
| | | > [3]http://gerrit.ovirt.org/#/c/16294/8/backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/qos/NetworkQoSCommandBase.java
| | | > 
| | | 
| | | thanks again,
| | | 
| | | Ofri
| | | 
| | 
| 


From dfediuck at redhat.com  Sun Jul 14 09:16:02 2013
From: dfediuck at redhat.com (Doron Fediuck)
Date: Sun, 14 Jul 2013 05:16:02 -0400 (EDT)
Subject: network and vnic qos
In-Reply-To: <1614927894.239343.1373791005929.JavaMail.root@redhat.com>
References: <293956441.3359594.1373555699680.JavaMail.root@redhat.com>
	<138549202.56945.1373786536742.JavaMail.root@redhat.com>
	<1614927894.239343.1373791005929.JavaMail.root@redhat.com>
Message-ID: <1368561802.241998.1373793362311.JavaMail.root@redhat.com>



----- Original Message -----
| From: "Giuseppe Vallarelli" <gvallare at redhat.com>
| To: "Ofri Masad" <omasad at redhat.com>
| Cc: arch at ovirt.org, "Moti Asayag" <masayag at redhat.com>, "Mike Kolesnik" <mkolesni at redhat.com>, "Michal Privoznik"
| <mprivozn at redhat.com>, "Doron Fediuck" <dfediuck at redhat.com>
| Sent: Sunday, July 14, 2013 11:36:45 AM
| Subject: Re: network and vnic qos
| 
| ----- Original Message -----
| | From: "Ofri Masad" <omasad at redhat.com>
| | To: "Giuseppe Vallarelli" <gvallare at redhat.com>
| | Cc: arch at ovirt.org, "Moti Asayag" <masayag at redhat.com>, "Mike Kolesnik"
| | <mkolesni at redhat.com>, "Michal Privoznik"
| | <mprivozn at redhat.com>, "Doron Fediuck" <dfediuck at redhat.com>
| | Sent: Sunday, July 14, 2013 9:22:16 AM
| | Subject: Re: network and vnic qos
| | 
| | Hi Giuseppe,
| 
| Hi Ofri,
| 
| | First of all, thanks for reviewing the design and the implementation.
| | as for your comments, as I see it, we need to separate between what we can
| | do
| | (using libvirt) and what we would like to expose to the user.
| | in my point of view, when a user is working with out engine (in appose to
| | working directly with libvirt or vdsm) he expects different things.
| | this is why we sometime take different choices from libvirt, to make the
| | usage more simple/intuitive, to allow more complex abstraction
| | or to get better control over the full system.
| 
| I understand the need of taking different decisions or not being completely
| tied to the underlying implementation. What I feel is that libvirt is much
| more flexible and we're limiting the usage. If you feel this the right way to
| go it's perfectly fine to me. In case users will have different expectations
| than we might revise this decision in the future.
| 
| | 
| | specific comment inline
| |      
| | ----- Original Message -----
| | > From: "Giuseppe Vallarelli" <gvallare at redhat.com>
| | > To: arch at ovirt.org
| | > Cc: "Ofri Masad" <omasad at redhat.com>, "Moti Asayag" <masayag at redhat.com>,
| | > "Mike Kolesnik" <mkolesni at redhat.com>,
| | > "Michal Privoznik" <mprivozn at redhat.com>
| | > Sent: Thursday, July 11, 2013 6:14:59 PM
| | > Subject: network and vnic qos
| | > 
| | > Hi Ofri, me, Moti and Mike have been looking carefully through the design
| | > spec of the vnic profiles[0]
| | > and lately to the network traffic shaping [1] which is very closely
| | > related.
| | > A reason of concern is the current design of network qos table[2].
| | > 
| | > First issue is the one related to the attributes associated to the
| | > traffic
| | > shaping (either inbound
| | > or outbound), I got the chance to talk with Michal (a libvirt developer
| | > in
| | > Brno) which confirmed me
| | > that the only compulsory attribute is average both burst and peak are
| | > optional, also he told me that
| | > libvirt doesn't provide any default values in case those are missing
| | > ones.
| | > Looking at missingValue()
| | > method in [3] seems that all 3 values are compulsory.
| | 
| | By not defining the other two values, we actually leave the decision to
| | libvirt. that means that the different libvirt releases
| | may take different decision. when the user is setting a specific QoS for
| | his
| | network, he expect to see the same behavior over
| | all of the VNICs using that QoS (even if they are running on different
| | libvirt versions).
| 
| I will let Michal answer to this specific concern, I'm not fully convinced
| that libvirt might place default values for unspecified attributes in the
| future.
| 

Giuseppe, you need to remember that a value may not necessarily be a number.
It can also be a formula which will behave differently on overutilized VS
underutilized hosts. Either way, undefined means exactly that. As a concept
SLA cannot assume it, or we're loosing the upper bound capabilities.
So for this reasoning we will start with as stable implementation as possible.
Going forwards we may re-visit based on users feedback.

|  setting all three values in the engine
| | allows us to force this unity. I will, however, add some default relations
| | to
| | the UI. so that when a user is setting the Average
| | value, the Peak and Burst values will be automatically derived (but could
| | be
| | edited, of course).
| | 
| | > 
| | > Second issue is mostly related to the decision of creating a single table
| | > with traffic shaping
| | > for both incoming and outgoing traffic (in table defined respectively as
| | > inbound and outbound).
| | > Incoming and outgoing traffic are independent and practically the same.
| | > If
| | > a
| | > network admin defines
| | > only incoming traffic, outgoing traffic attributes are nulls.
| | > 
| | > An alternative approach that we discussed is the following one: a table
| | > named
| | > simply qos
| | > or if you prefer qos_profile with the three attributes average (not
| | > null),
| | > burst and peak and an id.
| | > In this case after the user creates a profile, that one can be
| | > associated,
| | > as
| | > you defined in your spec,
| | > to a vnic (and in the future to a network). I'm not sure if we need a
| | > different attribute
| | > to specify for convenience the traffic at which the qos profile is
| | > applied
| | > (incoming/inbound, ougoing/outbound).
| | 
| | As for the difference between inbound and outbound, this is one of the most
| | common use cases, i believe both your home and office
| | networks have different inbound and outbound limits.
| | As for the single table. first, in the future we plan on adding another
| | attribute, "floor". which apply only to outbound.
| | second, I don't really see in what way this is better than the current
| | design
| 
| For how you've conceived the traffic shaping, which means having the user
| define all values and traffic type, my proposal is no better than yours
| but I was looking from a different angle.
| 
| | - and so I don't see why we should rewrite this
| | feature from scratch one day before feature freeze.
| 
| There's no need to do that, right now, as said previously.
| 
| Thanks Giuseppe
| 
| | 
| | > 
| | > Cheers, Giuseppe
| | > 
| | > 
| | > [0]http://www.ovirt.org/Features/Network_QoS
| | > [1]http://www.ovirt.org/Features/Network_traffic_shaping
| | > [2]http://gerrit.ovirt.org/#/c/16294/8/packaging/dbscripts/upgrade/03_03_0400_add_network_qos_tabel.sql
| | > [3]http://gerrit.ovirt.org/#/c/16294/8/backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/qos/NetworkQoSCommandBase.java
| | > 
| | 
| | thanks again,
| | 
| | Ofri
| | 
| 


From gustavo.pedrosa at eldorado.org.br  Mon Jul 15 12:55:25 2013
From: gustavo.pedrosa at eldorado.org.br (Gustavo Frederico Temple Pedrosa)
Date: Mon, 15 Jul 2013 12:55:25 +0000
Subject: Question about hardware system information
Message-ID: <EF26FC1776F7FF46BFC072393EFD13A299F88C@SERV070.corp.eldorado.org.br>

Hello,

The VDSM uses Dmidecode to retrieve the information that will be used in the method VdsBrokerObjectsBuilder.UpdateHardwareSystemInformation().
The IBM POWER architecture does not have the information from the Dmidecode, however, it has other information.
In the case of new information for IBM POWER architecture, there are two options: (1) add new columns in the method VdsDAODbFacadeImpl.mapRow() and in the database, or (2) map the new set of information into a single column (using, for example, JSON).
What would be the best option? And in case of a future new architecture?

Regards,
Gustavo F Temple Pedrosa.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20130715/3ab5c2ac/attachment.html>

From iheim at redhat.com  Mon Jul 15 13:15:26 2013
From: iheim at redhat.com (Itamar Heim)
Date: Mon, 15 Jul 2013 16:15:26 +0300
Subject: Question about hardware system information
In-Reply-To: <EF26FC1776F7FF46BFC072393EFD13A299F88C@SERV070.corp.eldorado.org.br>
References: <EF26FC1776F7FF46BFC072393EFD13A299F88C@SERV070.corp.eldorado.org.br>
Message-ID: <51E3F5EE.1050708@redhat.com>

On 07/15/2013 03:55 PM, Gustavo Frederico Temple Pedrosa wrote:
> Hello,
>
> The VDSM uses Dmidecode to retrieve the information that will be used in
> the method VdsBrokerObjectsBuilder.UpdateHardwareSystemInformation().
>
> The IBM POWER architecture does not have the information from the
> Dmidecode, however, it has other information.
>
> In the case of new information for IBM POWER architecture, there are two
> options: (1) add new columns in the method VdsDAODbFacadeImpl.mapRow()
> and in the database, or (2) map the new set of information into a single
> column (using, for example, JSON).
>
> What would be the best option? And in case of a future new architecture?
>
> Regards,
>
> Gustavo F Temple Pedrosa.
>
>
>
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
>

can you give an example of how different are the fields? we take basic 
fields iirc - vendor, serial number, etc.?


From yzaslavs at redhat.com  Mon Jul 15 13:19:44 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Mon, 15 Jul 2013 09:19:44 -0400 (EDT)
Subject: Question about hardware system information
In-Reply-To: <EF26FC1776F7FF46BFC072393EFD13A299F88C@SERV070.corp.eldorado.org.br>
References: <EF26FC1776F7FF46BFC072393EFD13A299F88C@SERV070.corp.eldorado.org.br>
Message-ID: <1392745066.706945.1373894384100.JavaMail.root@redhat.com>

----- Original Message -----

> From: "Gustavo Frederico Temple Pedrosa" <gustavo.pedrosa at eldorado.org.br>
> To: arch at ovirt.org
> Sent: Monday, July 15, 2013 3:55:25 PM
> Subject: Question about hardware system information

> Hello,

> The VDSM uses Dmidecode to retrieve the information that will be used in the
> method VdsBrokerObjectsBuilder.UpdateHardwareSystemInformation().

> The IBM POWER architecture does not have the information from the Dmidecode,
> however, it has other information.

> In the case of new information for IBM POWER architecture, there are two
> options: (1) add new columns in the method VdsDAODbFacadeImpl.mapRow() and
> in the database, or (2) map the new set of information into a single column
> (using, for example, JSON).

> What would be the best option? And in case of a future new architecture?

> Regards,

> Gustavo F Temple Pedrosa.

Hi, 
Doesn't it effect API and UI as well? (present different info) ? 

> _______________________________________________
> 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/20130715/d9fd5394/attachment.html>

From gustavo.pedrosa at eldorado.org.br  Mon Jul 15 19:07:15 2013
From: gustavo.pedrosa at eldorado.org.br (Gustavo Frederico Temple Pedrosa)
Date: Mon, 15 Jul 2013 19:07:15 +0000
Subject: Question about hardware system information
In-Reply-To: <51E3F5EE.1050708@redhat.com>
References: <EF26FC1776F7FF46BFC072393EFD13A299F88C@SERV070.corp.eldorado.org.br>
	<51E3F5EE.1050708@redhat.com>
Message-ID: <EF26FC1776F7FF46BFC072393EFD13A299FA6E@SERV070.corp.eldorado.org.br>

> -----Original Message-----
> From: Itamar Heim [mailto:iheim at redhat.com]
> Sent: segunda-feira, 15 de julho de 2013 10:15
> To: Gustavo Frederico Temple Pedrosa
> Cc: arch at ovirt.org
> Subject: Re: Question about hardware system information
> 
> On 07/15/2013 03:55 PM, Gustavo Frederico Temple Pedrosa wrote:
> > Hello,
> >
> > The VDSM uses Dmidecode to retrieve the information that will be used
> > in the method
> VdsBrokerObjectsBuilder.UpdateHardwareSystemInformation().
> >
> > The IBM POWER architecture does not have the information from the
> > Dmidecode, however, it has other information.
> >
> > In the case of new information for IBM POWER architecture, there are
> > two
> > options: (1) add new columns in the method
> VdsDAODbFacadeImpl.mapRow()
> > and in the database, or (2) map the new set of information into a
> > single column (using, for example, JSON).
> >
> > What would be the best option? And in case of a future new architecture?
> >
> > Regards,
> >
> > Gustavo F Temple Pedrosa.
> >
> >
> >
> > _______________________________________________
> > Arch mailing list
> > Arch at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/arch
> >
> 
> can you give an example of how different are the fields? we take basic fields
> iirc - vendor, serial number, etc.?


- Examples:
    System Id: IBM,0310050AA (/proc/device-tree/system-id)
    Platform: pSeries (/proc/cpuinfo)
    Model: IBM,8246-L2D (/proc/cpuinfo)
    Machine: CHRP IBM,8246-L2D (/proc/cpuinfo)


From gustavo.pedrosa at eldorado.org.br  Mon Jul 15 19:09:19 2013
From: gustavo.pedrosa at eldorado.org.br (Gustavo Frederico Temple Pedrosa)
Date: Mon, 15 Jul 2013 19:09:19 +0000
Subject: Question about hardware system information
In-Reply-To: <1392745066.706945.1373894384100.JavaMail.root@redhat.com>
References: <EF26FC1776F7FF46BFC072393EFD13A299F88C@SERV070.corp.eldorado.org.br>
	<1392745066.706945.1373894384100.JavaMail.root@redhat.com>
Message-ID: <EF26FC1776F7FF46BFC072393EFD13A299FA80@SERV070.corp.eldorado.org.br>

Yes, it does.
It is necessary changes in the VDSM, in the database, in the entities, in the SDK and in the UI (SubTabHostHardwareView).



From: Yair Zaslavsky [mailto:yzaslavs at redhat.com]
Sent: segunda-feira, 15 de julho de 2013 10:20
To: Gustavo Frederico Temple Pedrosa
Cc: arch at ovirt.org; Yaniv Bronheim
Subject: Re: Question about hardware system information



________________________________
From: "Gustavo Frederico Temple Pedrosa" <gustavo.pedrosa at eldorado.org.br>
To: arch at ovirt.org
Sent: Monday, July 15, 2013 3:55:25 PM
Subject: Question about hardware system information

Hello,

The VDSM uses Dmidecode to retrieve the information that will be used in the method VdsBrokerObjectsBuilder.UpdateHardwareSystemInformation().
The IBM POWER architecture does not have the information from the Dmidecode, however, it has other information.
In the case of new information for IBM POWER architecture, there are two options: (1) add new columns in the method VdsDAODbFacadeImpl.mapRow() and in the database, or (2) map the new set of information into a single column (using, for example, JSON).
What would be the best option? And in case of a future new architecture?

Regards,
Gustavo F Temple Pedrosa.

Hi,
Doesn't it effect API and UI as well? (present different info) ?


_______________________________________________
Arch mailing list
Arch at ovirt.org<mailto: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/20130715/c557153e/attachment.html>

From danken at redhat.com  Mon Jul 15 20:12:52 2013
From: danken at redhat.com (Dan Kenigsberg)
Date: Mon, 15 Jul 2013 23:12:52 +0300
Subject: Change of vdsStats
In-Reply-To: <370845292.961365.1373357607025.JavaMail.root@redhat.com>
References: <849742748.9075232.1372939016392.JavaMail.root@redhat.com>
	<2024234935.495479.1373275535768.JavaMail.root@redhat.com>
	<20130708200749.GE21626@redhat.com>
	<370845292.961365.1373357607025.JavaMail.root@redhat.com>
Message-ID: <20130715201252.GA4509@redhat.com>

On Tue, Jul 09, 2013 at 04:13:27AM -0400, Moti Asayag wrote:
> 
> 
> ----- Original Message -----
> > From: "Dan Kenigsberg" <danken at redhat.com>
> > To: "Petr Sebek" <psebek at redhat.com>, "Moti Asayag" <masayag at redhat.com>
> > Cc: arch at ovirt.org
> > Sent: Monday, July 8, 2013 11:07:49 PM
> > Subject: Re: Change of vdsStats
> > 
> > On Mon, Jul 08, 2013 at 05:25:35AM -0400, Petr Sebek wrote:
> > > The bug on bugzilla was for unknown reasons locked. Now it is unlocked for
> > > everybody.
> > > 
> > > ----- Original Message -----
> > > > From: "Petr Sebek" <psebek at redhat.com>
> > > > To: arch at ovirt.org
> > > > Sent: Thursday, July 4, 2013 1:56:56 PM
> > > > Subject: Change of vdsStats
> > > > 
> > > > Hi,
> > > > 
> > > > I've made patch [1] according to RFE [2]. Basically I just added
> > > > information
> > > > about bridges and vlans in vdsStats. I wanted to start discussion if is
> > > > this
> > > > change needed and suitable? I'm asking because with more statistics comes
> > > > bigger size of output. So I'm asking You if we need this information in
> > > > Engine and about which devices in particular.
> > > > 
> > > > 
> > > > [1] http://gerrit.ovirt.org/#/c/16227/
> > > > [2] https://bugzilla.redhat.com/show_bug.cgi?id=675560
> > 
> > Thanks for your patch, Petr.
> > 
> > It makes vdsm provide all interface information for bridges and vlans -
> > where this information includes mac address, tx/rx rates, 0 in the
> > speed field, and the device state.
> > 
> > Only the latter element is interesting for the purposes of the opened
> > bug.  For example, there's an old patch by Mark Wu suggesting to drop
> > macAddr from the stats of actual nics
> > (http://gerrit.ovirt.org/#/c/13840/); we certainly do not need to report
> > the quite-random mac address of bridge devices.
> > 
> > Similarly, I am not sure that the rxRate of the vlan device has any
> > significance.
> > 
> > Finally, does Engine have plans to collect the state field from bridge
> > devices and report an error if the state is down?
> 
> The engine should move the host to non-operational if the bridge or the vlan 
> are reported from VDSM as down. If it doesn't implemented that way - it is 
> an engine bug.
> 
> > 
> > Can you think of cases, other than manual "ifdown" by an evil admin,
> > where the state if a vlan device is expected to change?

Still, if we cannot think of any use case, besides that of an evil
admin, I think we should CLOSE|WONTFIX the bug.

Dan.


From iheim at redhat.com  Tue Jul 16 07:01:47 2013
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 16 Jul 2013 10:01:47 +0300
Subject: Question about hardware system information
In-Reply-To: <EF26FC1776F7FF46BFC072393EFD13A299FA6E@SERV070.corp.eldorado.org.br>
References: <EF26FC1776F7FF46BFC072393EFD13A299F88C@SERV070.corp.eldorado.org.br>
	<51E3F5EE.1050708@redhat.com>
	<EF26FC1776F7FF46BFC072393EFD13A299FA6E@SERV070.corp.eldorado.org.br>
Message-ID: <51E4EFDB.1020802@redhat.com>

On 07/15/2013 10:07 PM, Gustavo Frederico Temple Pedrosa wrote:
>> -----Original Message-----
>> From: Itamar Heim [mailto:iheim at redhat.com]
>> Sent: segunda-feira, 15 de julho de 2013 10:15
>> To: Gustavo Frederico Temple Pedrosa
>> Cc: arch at ovirt.org
>> Subject: Re: Question about hardware system information
>>
>> On 07/15/2013 03:55 PM, Gustavo Frederico Temple Pedrosa wrote:
>>> Hello,
>>>
>>> The VDSM uses Dmidecode to retrieve the information that will be used
>>> in the method
>> VdsBrokerObjectsBuilder.UpdateHardwareSystemInformation().
>>>
>>> The IBM POWER architecture does not have the information from the
>>> Dmidecode, however, it has other information.
>>>
>>> In the case of new information for IBM POWER architecture, there are
>>> two
>>> options: (1) add new columns in the method
>> VdsDAODbFacadeImpl.mapRow()
>>> and in the database, or (2) map the new set of information into a
>>> single column (using, for example, JSON).
>>>
>>> What would be the best option? And in case of a future new architecture?
>>>
>>> Regards,
>>>
>>> Gustavo F Temple Pedrosa.
>>>
>>>
>>>
>>> _______________________________________________
>>> Arch mailing list
>>> Arch at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/arch
>>>
>>
>> can you give an example of how different are the fields? we take basic fields
>> iirc - vendor, serial number, etc.?
>
>
> - Examples:
>      System Id: IBM,0310050AA (/proc/device-tree/system-id)
>      Platform: pSeries (/proc/cpuinfo)
>      Model: IBM,8246-L2D (/proc/cpuinfo)
>      Machine: CHRP IBM,8246-L2D (/proc/cpuinfo)
>

ok - these seem to be identical to what we do with dmidecode, why can't 
you just send these in same way/fields and engine will just show them 
the same?


From iheim at redhat.com  Tue Jul 16 10:32:34 2013
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 16 Jul 2013 13:32:34 +0300
Subject: Question about hardware system information
In-Reply-To: <EF26FC1776F7FF46BFC072393EFD13A299FA80@SERV070.corp.eldorado.org.br>
References: <EF26FC1776F7FF46BFC072393EFD13A299F88C@SERV070.corp.eldorado.org.br>
	<1392745066.706945.1373894384100.JavaMail.root@redhat.com>
	<EF26FC1776F7FF46BFC072393EFD13A299FA80@SERV070.corp.eldorado.org.br>
Message-ID: <51E52142.6060106@redhat.com>

On 07/15/2013 10:09 PM, Gustavo Frederico Temple Pedrosa wrote:
> Yes, it does.
>
> It is necessary changes in the VDSM, in the database, in the entities,
> in the SDK and in the UI (SubTabHostHardwareView).

the list for ppc as i understand it is:
- Examples:
     System Id: IBM,0310050AA (/proc/device-tree/system-id)
     Platform: pSeries (/proc/cpuinfo)
     Model: IBM,8246-L2D (/proc/cpuinfo)
     Machine: CHRP IBM,8246-L2D (/proc/cpuinfo)

this seems close enough to what we already have: Manufacturer, Product 
Name, UUID, Version, Serial Number and Family

is there no easy way to map these?


From gustavo.pedrosa at eldorado.org.br  Tue Jul 16 12:48:03 2013
From: gustavo.pedrosa at eldorado.org.br (Gustavo Frederico Temple Pedrosa)
Date: Tue, 16 Jul 2013 12:48:03 +0000
Subject: Question about hardware system information
In-Reply-To: <51E52142.6060106@redhat.com>
References: <EF26FC1776F7FF46BFC072393EFD13A299F88C@SERV070.corp.eldorado.org.br>
	<1392745066.706945.1373894384100.JavaMail.root@redhat.com>
	<EF26FC1776F7FF46BFC072393EFD13A299FA80@SERV070.corp.eldorado.org.br>
	<51E52142.6060106@redhat.com>
Message-ID: <EF26FC1776F7FF46BFC072393EFD13A299FAD9@SERV070.corp.eldorado.org.br>

> -----Original Message-----
> From: Itamar Heim [mailto:iheim at redhat.com]
> Sent: ter?a-feira, 16 de julho de 2013 07:33
> To: Gustavo Frederico Temple Pedrosa
> Cc: Yair Zaslavsky; arch at ovirt.org
> Subject: Re: Question about hardware system information
> 
> On 07/15/2013 10:09 PM, Gustavo Frederico Temple Pedrosa wrote:
> > Yes, it does.
> >
> > It is necessary changes in the VDSM, in the database, in the entities,
> > in the SDK and in the UI (SubTabHostHardwareView).
> 
> the list for ppc as i understand it is:
> - Examples:
>      System Id: IBM,0310050AA (/proc/device-tree/system-id)
>      Platform: pSeries (/proc/cpuinfo)
>      Model: IBM,8246-L2D (/proc/cpuinfo)
>      Machine: CHRP IBM,8246-L2D (/proc/cpuinfo)
> 
> this seems close enough to what we already have: Manufacturer, Product
> Name, UUID, Version, Serial Number and Family
> 
> is there no easy way to map these?


Yes, there is.
After an analysis of your tip, we saw that the easiest way is to map the existing fields in the VDSM, thank you very much!


From leonardo.bianconi at eldorado.org.br  Tue Jul 16 13:25:18 2013
From: leonardo.bianconi at eldorado.org.br (Leonardo Bianconi)
Date: Tue, 16 Jul 2013 13:25:18 +0000
Subject: oVirt on IBM POWER (PPC64) - new feature contributors
In-Reply-To: <51E01C3A.9010903@redhat.com>
References: <50EB20226B72D6419356FC320AB62B871896B600@SERV070.corp.eldorado.org.br>
	<5193A8AE.5000600@redhat.com>
	<50EB20226B72D6419356FC320AB62B871896BB19@SERV070.corp.eldorado.org.br>
	<61C18AFB-AF93-48F3-BC90-6AA1B341DF27@redhat.com>
	<51A0B899.9030600@redhat.com>
	<50EB20226B72D6419356FC320AB62B8719170EE6@SERV070.corp.eldorado.org.br>
	<51DEE8E5.2020806@redhat.com>
	<50EB20226B72D6419356FC320AB62B8719170F7F@SERV070.corp.eldorado.org.br>
	<51E01C3A.9010903@redhat.com>
Message-ID: <50EB20226B72D6419356FC320AB62B8719171159@SERV070.corp.eldorado.org.br>



>-----Original Message-----
>From: Itamar Heim [mailto:iheim at redhat.com]
>Sent: sexta-feira, 12 de julho de 2013 12:10
>To: Leonardo Bianconi
>Cc: Michal Skrivanek; arch at ovirt.org; Roy Golan
>Subject: Re: oVirt on IBM POWER (PPC64) - new feature contributors
>
>On 07/12/2013 03:52 PM, Leonardo Bianconi wrote:
>>
>>
>>> -----Original Message-----
>>> From: Itamar Heim [mailto:iheim at redhat.com]
>>> Sent: quinta-feira, 11 de julho de 2013 14:18
>>> To: Leonardo Bianconi
>>> Cc: Michal Skrivanek; arch at ovirt.org; Roy Golan
>>> Subject: Re: oVirt on IBM POWER (PPC64) - new feature contributors
>>>
>>> On 07/11/2013 08:04 PM, Leonardo Bianconi wrote:
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Itamar Heim [mailto:iheim at redhat.com]
>>>> Sent: s?bado, 25 de maio de 2013 10:12
>>>> To: Michal Skrivanek
>>>> Cc: Leonardo Bianconi; arch at ovirt.org; Roy Golan
>>>> Subject: Re: oVirt on IBM POWER (PPC64) - new feature contributors
>>>>
>>>> On 05/22/2013 10:46 AM, Michal Skrivanek wrote:
>>>>>
>>>>> On May 21, 2013, at 17:33 , Leonardo Bianconi <leonardo.bianconi at eldorado.org.br> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> We are planning to deliver support for PPC64 in 4 phases. We will manage to deliver a set of patches at the end of each phase.
>>>>>>
>>>>>> Phase 1
>>>>>>
>>>>>> 	 Change oVirt to handle other architectures by encapsulating all
>>>>>> the architecture specific code and queries about the
>>> capabilities of the hypervisor into a new class called ArchStrategy
>>> (based on the Strategy Design Pattern). Every operation involving
>>> clusters and hosts will be validated by this new class. Some hard-coded parameters are going to be replaced by queries in the
>backend in order to accommodate the support for new architectures into the engine.
>>>>>
>>>>> If you would like to discuss some internals or if anything is
>>>>> unclear please feel free to set up a quick mtg with myself, Omer
>>>>> and
>>> Roy.
>>>>> Sometimes (e.g. in the case of VmInterfaceType as mentioned on
>>>>> feature page) it would be actually beneficial for oVirt on x86 as
>>> well to have a greater flexibility directly in the code, without Strategy encapsulation.
>>>>>
>>>>>>
>>>>>>
>>>>>> Phase 2
>>>>>>
>>>>>> 	Currently, each host hypervisor capabilities are obtained using
>>>>>> hard-coded data structures. These structures will be replaced
>>> either by some form of integration with libosinfo or by reading
>>> internal configuration files describing these capabilities. It will be handled after Roy's patch.
>>>>> Roy's osinfo will soon be merged.
>>>>
>>>>> link to patches?
>>>>> does it cover adding arch at cluster level?
>>>>
>>>> Sorry about the late reply. We have already handled the gap between
>>>> the osinfo patch, the architecture parameters are being
>>> stored the same way as the OS info.
>>>>
>>>> We didn't add a specific architecture field on each cluster, because
>>>> based on the cpu name and cluster compatibility version of the
>>> cluster the architecture can be determined. Do you think it is really
>>> necessary to add another way to describe the architecture of each cluster?
>>>
>>> i think it would be much easier to specify the list of OSs per arch
>>> type, rather than per list of cpu's. it will also be easier to know if a VM can be created from a template based on their arch, rather
>than cpu lists (since x86_64 has a new cpu family every 6 months usually).
>>
>> We are not specifying the OS (or any other architecture specific
>> detail) based on the cpu family directly. The ServerCpuList was modified to associate each processor family name to an architecture
>(currently there are only two possible values for this association, x86_64 and ppc64). For example:
>>
>> "3:Intel Conroe Family:vmx,nx,model_Conroe:Conroe:x86_64"
>>
>> Every architecture specific operation checks which is the associated architecture, and all the operations are done based only on this
>value. When initializing the engine this parameter is read by CpuFlagsManagerHandler. The OS property file (osinfo-
>defaults.properties) contains the architecture for each OS, so internally the ArchStrategy (the class responsible for abstracting
>architecture specific code) checks the compatibility based on the architecture name, not on the cpu family.
>
>yes, i saw that, and it will work (just more code level comparisons than db ones, but as i said, just a matter of taste and i'm not strongly
>opinionated about this).
>
>the question is if arch specific are part of the OS (there is a
>RHEL6_x64 and a RHEL6_ppc7 OSs).
>
>if we separate the OSs, than why do we need the arch level repo, as you can do the limitation on the base default_os_ppc7?
Yes, that is right, we are going to change that (as commented on the patch)
>
>the other concern is behavior with export/import.
>since some issues are also discussed at patch level - lets move there and come back here if there is a conceptual issue worth revisiting.
>
Ok
>one question though to help me read the patches - what guest OSs can run on ppc7 arch (fedora? .el6? debian? other (i know
>windows isn't relevant, but what to expect there)?
About the guest OSes, we expect run all available linux for PPC64, but initially mainly Fedora and RHEL.
>
>Thanks,
>    Itamar
Thanks
Leonardo Bianconi/Vitor de Lima/Gustavo Pedrosa
>
>>
>>> similarly, it will be easier to know if you can move a VM between two
>>> clusters, according to their arch, rather trying to understand if their cpu families allow that or not (you can move a VM between
>intel and amd cpu families).
>>
>> Actually we have already thought about it. The ArchStrategy class has a method to compare two CPU families and return if they are
>compatible. On this case, like above, it is using the architecture name added for each cpu family on the ServerCpuList and will be
>compatible only if both CPUs have the same architecture.
>>
>> Another advantage besides having the architecture encapsulated in the ArchStrategy is that every place on the code that the cpu
>name and compatibility version is accessible, the ArchStrategy can be obtained and there is no need to retrieve the cluster object.
>>
>>
>>
>> We are checking the comments on the patch and we will reply soon.
>>
>>>
>>> so i think cluster arch is a good grouping for cpu families that are compatible.
>>>
>>> (and I wonder if anyone will get to add an arm arch as well...)
>>>
>>> in any case, I was very happy to see the set of patches arriving.
>>>
>>> Thanks,
>>>     Itamar
>>>
>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> Phase 3
>>>>>>
>>>>>> 	The code for providing the support for IBM POWER systems will be
>>>>>> added. The encapsulation done in the previous phase will
>>> reduce the effort to include this feature into the engine. The other changes that will be introduced in this phase include:
>>>>>>
>>>>>> 	- Modifications in the frontend to avoid running a VM created on a POWER host in a x86-64 host (and vice-versa),
>>>>>> 	- All the dynamically provided capacities of the first phase will
>>>>>> be implemented according to the capacities of the QEMU/KVM
>>> on POWER
>>>>>> 	- The POWER processors will be available as an option in the list
>>>>>> of processor names (this will imply in significant changes in the
>>>>>> backend)
>>>>>>
>>>>>>
>>>>>> Phase 4
>>>>>>
>>>>>> 	Adapt secondary features to polish the support for POWER:
>>>>>>
>>>>>> 	- OVF import and export of VMs running in POWER hosts
>>>>>> 	- Dynamic searches capable of finding hosts, pools, vms and
>>>>>> clusters according to their architectures
>>>>>>
>>>>>>
>>>>>> Is there any ongoing oVirt architecture refactoring ? (that may
>>>>>> conflict with Phase 1, for instance)
>>>>> no, nothing major going on
>>>>>
>>>>>>
>>>>>> Any comments ?
>>>>> Looking forward to your patches!:-)
>>>>>
>>>>> Thanks,
>>>>> michal
>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Vitor (vitor.lima at eldorado.org.br) / Leonardo
>>>>>> (leonardo.bianconi at eldorado.org.br)
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Dave Neary [mailto:dneary at redhat.com]
>>>>>> Sent: quarta-feira, 15 de maio de 2013 12:25
>>>>>> To: Leonardo Bianconi
>>>>>> Cc: arch at ovirt.org; Adam Litke
>>>>>> Subject: Re: oVirt on IBM POWER (PPC64) - new feature contributors
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> On 05/14/2013 08:05 PM, Leonardo Bianconi wrote:
>>>>>>> We would like to introduce ourselves: Leonardo Bianconi and Vitor Lima.
>>>>>>
>>>>>> Welcome!
>>>>>>
>>>>>>> We would like to work on the features "Engine support for PPC64"
>>>>>>> (http://wiki.ovirt.org/Features/Engine_support_for_PPC64)
>>> and the "Vdsm for PPC64"
>>> (http://wiki.ovirt.org/Features/Vdsm_for_PPC64). This work has already been started by some developers at IBM.
>>>>>>
>>>>>> <snip>
>>>>>>
>>>>>>> About libosinfo:
>>>>>>> =============
>>>>>>>
>>>>>>> In the previous discussion about this topic
>>>>>>> (http://lists.ovirt.org/pipermail/arch/2012-November/000976.html)
>>>>>>> , occurred in
>>> November 2012, it was suggested that integrating the libosinfo into
>>> the engine would be a better way to handle the differences between the architectures that would be supported in the future.
>>>>>>>
>>>>>>> Is this approach still valid? If so, when will it be available? It seems to be a dependency for oVirt "Engine_support_for_PPC64"
>>> feature implementation.
>>>>>>
>>>>>>
>>>>>> This is great news. I don't know who, specifically, has been
>>>>>> working on this issue in IBM - perhaps Adam Litke (CCed) can
>>>>>> update
>>> you on the progress that has been made.
>>>>>
>>>>>>
>>>>>> 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
>>>>>
>>>>> _______________________________________________
>>>>> Arch mailing list
>>>>> Arch at ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/arch
>>>>>
>>>>
>>



From alonbl at redhat.com  Tue Jul 16 18:01:21 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Tue, 16 Jul 2013 14:01:21 -0400 (EDT)
Subject: installing otopi-devel on fedora-19 nodes
In-Reply-To: <2030664576.682741.1373997619232.JavaMail.root@redhat.com>
Message-ID: <800376764.683083.1373997681295.JavaMail.root@redhat.com>

Hi,

Can anyone install otopi-devel from latest nightly on fedora-19 nodes?

I cannot do this[1].

Thanks,
Alon

[1] http://jenkins.ovirt.org/view/system-monitoring/job/install_missing_packages_on_slaves/label=fedora19/79/console


From alonbl at redhat.com  Tue Jul 16 19:38:57 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Tue, 16 Jul 2013 15:38:57 -0400 (EDT)
Subject: installing otopi-devel on fedora-19 nodes
In-Reply-To: <1888891911.1863131.1374002486658.JavaMail.root@redhat.com>
References: <800376764.683083.1373997681295.JavaMail.root@redhat.com>
	<1888891911.1863131.1374002486658.JavaMail.root@redhat.com>
Message-ID: <328027126.714791.1374003537354.JavaMail.root@redhat.com>


Thanks!
Working.

----- Original Message -----
> From: "Kiril Nesenko" <kiril at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "arch" <arch at ovirt.org>, "Eyal Edri" <eedri at redhat.com>
> Sent: Tuesday, July 16, 2013 10:21:26 PM
> Subject: Re: installing otopi-devel on fedora-19 nodes
> 
> Done
> 
> - Kiril
> 
> 
> ----- Original Message -----
> > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > To: "arch" <arch at ovirt.org>
> > Cc: "Kiril Nesenko" <kiril at redhat.com>, "Eyal Edri" <eedri at redhat.com>
> > Sent: Tuesday, July 16, 2013 9:01:21 PM
> > Subject: installing otopi-devel on fedora-19 nodes
> > 
> > Hi,
> > 
> > Can anyone install otopi-devel from latest nightly on fedora-19 nodes?
> > 
> > I cannot do this[1].
> > 
> > Thanks,
> > Alon
> > 
> > [1]
> > http://jenkins.ovirt.org/view/system-monitoring/job/install_missing_packages_on_slaves/label=fedora19/79/console
> > 
> 


From iheim at redhat.com  Tue Jul 16 13:28:44 2013
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 16 Jul 2013 16:28:44 +0300
Subject: oVirt updates - July 16th 2013
Message-ID: <51E54A8C.7020305@redhat.com>

(some updates I collected from past weeks)

General:
- oVirt 3.3 feature freeze is upon us - a great version with many
   features! looking forward for people joining the test day next week

- new mailing list for users in Portugu?s
   http://lists.ovirt.org/mailman/listinfo/users-pt

Past Conferences:
- oVirt Shanghai (Intel) workshop videos published
   http://software.intel.com/zh-cn/2013_Intel_oVirt_Workshop

- FISL14 oVirt was a success - thanks to all who helped!
   http://dougsland.livejournal.com/122744.html
   and (Portugu?s)
 
http://mr-marcelo-barbosa.tumblr.com/post/54945916221/fisl14-apresentando-o-ovirt

Upcoming conferences:
- Alterway, Wednesday 17th July - oVirt: principles and demo (french)
   http://moonbar.org/reader/event_20130702_074742_813902

- August Pinguin (Israel) will have an intro to oVirt session
   http://august.penguin.org.il/

- LinuxCon/CloudOpen NA will have an oVirt SLA session (more details to
   come)

- LinuxCon/CloudOpen Europe, KVM Forum CFPs are open and oVirt
   developer days in planning

Upcoming:
- Ubuntu and SUSE guest OSs will be added to oVirt
   http://gerrit.ovirt.org/#/c/16680/

- Power PC engine patches arrived
   http://alturl.com/fxpg5

Devel/integration:

- Gluster 3.4 was released (good timing for cleaning up the vdsm
   dependnecy for oVirt 3.3)

- libgovirt 0.2.0 was released by Christophe Fergeau
   http://lists.ovirt.org/pipermail/users/2013-July/015098.html

- Gianluca Cecchi reported oVirt works with samba (ad compatibility)
   http://lists.ovirt.org/pipermail/users/2013-June/015030.html

- spice mime launcher for mac (OS X)
   https://github.com/brianwcook/launchvv

- oVirt Python SDK review (Portugu?s)
   http://www.ibm.com/developerworks/br/local/linux/ovirt_python_sdk/

Other:
- ZENOSS webinar on oVirt (rhev) monitoring
 
http://www.zenoss.com/in/wb_monitoring_red_hat_enterprise_virtualization.html



From omasad at redhat.com  Sun Jul 14 07:22:16 2013
From: omasad at redhat.com (Ofri Masad)
Date: Sun, 14 Jul 2013 03:22:16 -0400 (EDT)
Subject: network and vnic qos
In-Reply-To: <293956441.3359594.1373555699680.JavaMail.root@redhat.com>
References: <293956441.3359594.1373555699680.JavaMail.root@redhat.com>
Message-ID: <138549202.56945.1373786536742.JavaMail.root@redhat.com>

Hi Giuseppe,

First of all, thanks for reviewing the design and the implementation.
as for your comments, as I see it, we need to separate between what we can do (using libvirt) and what we would like to expose to the user.
in my point of view, when a user is working with out engine (in appose to working directly with libvirt or vdsm) he expects different things.
this is why we sometime take different choices from libvirt, to make the usage more simple/intuitive, to allow more complex abstraction 
or to get better control over the full system.

specific comment inline
     
----- Original Message -----
> From: "Giuseppe Vallarelli" <gvallare at redhat.com>
> To: arch at ovirt.org
> Cc: "Ofri Masad" <omasad at redhat.com>, "Moti Asayag" <masayag at redhat.com>, "Mike Kolesnik" <mkolesni at redhat.com>,
> "Michal Privoznik" <mprivozn at redhat.com>
> Sent: Thursday, July 11, 2013 6:14:59 PM
> Subject: network and vnic qos
> 
> Hi Ofri, me, Moti and Mike have been looking carefully through the design
> spec of the vnic profiles[0]
> and lately to the network traffic shaping [1] which is very closely related.
> A reason of concern is the current design of network qos table[2].
> 
> First issue is the one related to the attributes associated to the traffic
> shaping (either inbound
> or outbound), I got the chance to talk with Michal (a libvirt developer in
> Brno) which confirmed me
> that the only compulsory attribute is average both burst and peak are
> optional, also he told me that
> libvirt doesn't provide any default values in case those are missing ones.
> Looking at missingValue()
> method in [3] seems that all 3 values are compulsory.

By not defining the other two values, we actually leave the decision to libvirt. that means that the different libvirt releases 
may take different decision. when the user is setting a specific QoS for his network, he expect to see the same behavior over 
all of the VNICs using that QoS (even if they are running on different libvirt versions). setting all three values in the engine
allows us to force this unity. I will, however, add some default relations to the UI. so that when a user is setting the Average
value, the Peak and Burst values will be automatically derived (but could be edited, of course).  

> 
> Second issue is mostly related to the decision of creating a single table
> with traffic shaping
> for both incoming and outgoing traffic (in table defined respectively as
> inbound and outbound).
> Incoming and outgoing traffic are independent and practically the same. If a
> network admin defines
> only incoming traffic, outgoing traffic attributes are nulls.
> 
> An alternative approach that we discussed is the following one: a table named
> simply qos
> or if you prefer qos_profile with the three attributes average (not null),
> burst and peak and an id.
> In this case after the user creates a profile, that one can be associated, as
> you defined in your spec,
> to a vnic (and in the future to a network). I'm not sure if we need a
> different attribute
> to specify for convenience the traffic at which the qos profile is applied
> (incoming/inbound, ougoing/outbound).

As for the difference between inbound and outbound, this is one of the most common use cases, i believe both your home and office 
networks have different inbound and outbound limits. 
As for the single table. first, in the future we plan on adding another attribute, "floor". which apply only to outbound. 
second, I don't really see in what way this is better than the current design - and so I don't see why we should rewrite this 
feature from scratch one day before feature freeze.     

> 
> Cheers, Giuseppe
> 
> 
> [0]http://www.ovirt.org/Features/Network_QoS
> [1]http://www.ovirt.org/Features/Network_traffic_shaping
> [2]http://gerrit.ovirt.org/#/c/16294/8/packaging/dbscripts/upgrade/03_03_0400_add_network_qos_tabel.sql
> [3]http://gerrit.ovirt.org/#/c/16294/8/backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/qos/NetworkQoSCommandBase.java
> 

thanks again,

Ofri


From mprivozn at redhat.com  Mon Jul 15 07:24:31 2013
From: mprivozn at redhat.com (Michal Privoznik)
Date: Mon, 15 Jul 2013 09:24:31 +0200
Subject: network and vnic qos
In-Reply-To: <138549202.56945.1373786536742.JavaMail.root@redhat.com>
References: <293956441.3359594.1373555699680.JavaMail.root@redhat.com>
	<138549202.56945.1373786536742.JavaMail.root@redhat.com>
Message-ID: <51E3A3AF.7030601@redhat.com>

On 14.07.2013 09:22, Ofri Masad wrote:
> Hi Giuseppe,
> 
> First of all, thanks for reviewing the design and the implementation.
> as for your comments, as I see it, we need to separate between what we can do (using libvirt) and what we would like to expose to the user.
> in my point of view, when a user is working with out engine (in appose to working directly with libvirt or vdsm) he expects different things.
> this is why we sometime take different choices from libvirt, to make the usage more simple/intuitive, to allow more complex abstraction 
> or to get better control over the full system.
> 
> specific comment inline
>      
> ----- Original Message -----
>> From: "Giuseppe Vallarelli" <gvallare at redhat.com>
>> To: arch at ovirt.org
>> Cc: "Ofri Masad" <omasad at redhat.com>, "Moti Asayag" <masayag at redhat.com>, "Mike Kolesnik" <mkolesni at redhat.com>,
>> "Michal Privoznik" <mprivozn at redhat.com>
>> Sent: Thursday, July 11, 2013 6:14:59 PM
>> Subject: network and vnic qos
>>
>> Hi Ofri, me, Moti and Mike have been looking carefully through the design
>> spec of the vnic profiles[0]
>> and lately to the network traffic shaping [1] which is very closely related.
>> A reason of concern is the current design of network qos table[2].
>>
>> First issue is the one related to the attributes associated to the traffic
>> shaping (either inbound
>> or outbound), I got the chance to talk with Michal (a libvirt developer in
>> Brno) which confirmed me
>> that the only compulsory attribute is average both burst and peak are
>> optional, also he told me that
>> libvirt doesn't provide any default values in case those are missing ones.
>> Looking at missingValue()
>> method in [3] seems that all 3 values are compulsory.
> 
> By not defining the other two values, we actually leave the decision to libvirt. that means that the different libvirt releases 
> may take different decision. when the user is setting a specific QoS for his network, he expect to see the same behavior over 
> all of the VNICs using that QoS (even if they are running on different libvirt versions). setting all three values in the engine
> allows us to force this unity. I will, however, add some default relations to the UI. so that when a user is setting the Average
> value, the Peak and Burst values will be automatically derived (but could be edited, of course).  

Libvirt doesn't set any of optional attributes if there's none set in
XML. We don't want to make any auto detection or AI for guessing the
correct values neither. I mean, for instance libvirt doesn't auto detect
the maximal bandwidth for a network but lets user to tell us the proper
values instead.

Michal


From kiril at redhat.com  Tue Jul 16 19:21:26 2013
From: kiril at redhat.com (Kiril Nesenko)
Date: Tue, 16 Jul 2013 15:21:26 -0400 (EDT)
Subject: installing otopi-devel on fedora-19 nodes
In-Reply-To: <800376764.683083.1373997681295.JavaMail.root@redhat.com>
References: <800376764.683083.1373997681295.JavaMail.root@redhat.com>
Message-ID: <1888891911.1863131.1374002486658.JavaMail.root@redhat.com>

Done

- Kiril


----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "arch" <arch at ovirt.org>
> Cc: "Kiril Nesenko" <kiril at redhat.com>, "Eyal Edri" <eedri at redhat.com>
> Sent: Tuesday, July 16, 2013 9:01:21 PM
> Subject: installing otopi-devel on fedora-19 nodes
> 
> Hi,
> 
> Can anyone install otopi-devel from latest nightly on fedora-19 nodes?
> 
> I cannot do this[1].
> 
> Thanks,
> Alon
> 
> [1]
> http://jenkins.ovirt.org/view/system-monitoring/job/install_missing_packages_on_slaves/label=fedora19/79/console
> 


From masayag at redhat.com  Fri Jul 19 15:07:35 2013
From: masayag at redhat.com (Moti Asayag)
Date: Fri, 19 Jul 2013 11:07:35 -0400 (EDT)
Subject: Network traffic shaping.
In-Reply-To: <1809186597.402470.1373280341185.JavaMail.root@redhat.com>
References: <1809186597.402470.1373280341185.JavaMail.root@redhat.com>
Message-ID: <1742027705.3406607.1374246455114.JavaMail.root@redhat.com>

Hi,

According to the 'Detailed description' section in the wiki, it is stated that the
admin may override the traffic shaping of the network on the data-center level with
a specific one per host.

Is there a need to persist this configuration on the engine side and to present it 
to the user or we just passing these settings to the host while configuring the
network on the host and abandoning them afterwards? Meaning, VDSM will report the QoS per
host's network and it will be presented to the user. But the actual values that
were used to set these network QoS won't be persistent on the engine side?

The answer to the above has further implication on the design on engine side,
therefore before starting futile discussion, is there such a requirement ?

----- Original Message -----
> From: "Giuseppe Vallarelli" <gvallare at redhat.com>
> To: arch at ovirt.org
> Sent: Monday, July 8, 2013 1:45:41 PM
> Subject: Network traffic shaping.
> 
> Hi everybody, I'm working to implement traffic shaping at the network level
> [1].
> This feature is composed by two distinct parts: definition of traffic shaping
> for a logical network entity and optional redefinition of traffic shaping
> when
> the user is doing a Setup Host Networks task. Initial focus will be on first
> part. There are some points of contact with Network Qos [2] that's why I
> proposed
> to reuse some code backend side.
> 
> Cheers, Giuseppe
> 
> [1] http://www.ovirt.org/Features/Network_traffic_shaping
> [2] http://www.ovirt.org/Features/Network_QoS
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From dfediuck at redhat.com  Sun Jul 21 08:09:01 2013
From: dfediuck at redhat.com (Doron Fediuck)
Date: Sun, 21 Jul 2013 04:09:01 -0400 (EDT)
Subject: Network traffic shaping.
In-Reply-To: <1742027705.3406607.1374246455114.JavaMail.root@redhat.com>
References: <1809186597.402470.1373280341185.JavaMail.root@redhat.com>
	<1742027705.3406607.1374246455114.JavaMail.root@redhat.com>
Message-ID: <2059884441.5151895.1374394141589.JavaMail.root@redhat.com>



----- Original Message -----
| From: "Moti Asayag" <masayag at redhat.com>
| To: "Giuseppe Vallarelli" <gvallare at redhat.com>
| Cc: arch at ovirt.org
| Sent: Friday, July 19, 2013 6:07:35 PM
| Subject: Re: Network traffic shaping.
| 
| Hi,
| 
| According to the 'Detailed description' section in the wiki, it is stated
| that the
| admin may override the traffic shaping of the network on the data-center
| level with
| a specific one per host.
| 
| Is there a need to persist this configuration on the engine side and to
| present it
| to the user or we just passing these settings to the host while configuring
| the
| network on the host and abandoning them afterwards? Meaning, VDSM will report
| the QoS per
| host's network and it will be presented to the user. But the actual values
| that
| were used to set these network QoS won't be persistent on the engine side?
| 
| The answer to the above has further implication on the design on engine side,
| therefore before starting futile discussion, is there such a requirement ?
| 
| ----- Original Message -----
| > From: "Giuseppe Vallarelli" <gvallare at redhat.com>
| > To: arch at ovirt.org
| > Sent: Monday, July 8, 2013 1:45:41 PM
| > Subject: Network traffic shaping.
| > 
| > Hi everybody, I'm working to implement traffic shaping at the network level
| > [1].
| > This feature is composed by two distinct parts: definition of traffic
| > shaping
| > for a logical network entity and optional redefinition of traffic shaping
| > when
| > the user is doing a Setup Host Networks task. Initial focus will be on
| > first
| > part. There are some points of contact with Network Qos [2] that's why I
| > proposed
| > to reuse some code backend side.
| > 
| > Cheers, Giuseppe
| > 
| > [1] http://www.ovirt.org/Features/Network_traffic_shaping
| > [2] http://www.ovirt.org/Features/Network_QoS

Hi guys,
Adding my comments to Moti's;

First of all Giuseppe, looks like a good start for a much needed functionality in oVirt.
So thumbs' up on driving it forward and having this discussion in place ;)
Somehow, your writing was taken out of context, so I think we should
clarify the concepts to begin with;

Host-level traffic shaping handles one aspect in the domain of QoS. For
3.3 we're already planning VM-level networking QoS and your feature is
completing it.
Network traffic shaping is one implementation libvirt chose, in order
to provide quality of service at host level. Look for "quality of service"
in [1]. But we should also remember that it may have additional implementations
which goes all the way to the network device, as we will need to handle in
provided networks.

So for completeness and clarification we should align host-level network QoS
with VM-level network QoS. Let's start with renaming the feature from it's
implementation to what it should provide: host network QoS. Ofri may assist
you with renaming current pages as needed to improve things. This may also
help me find the detailed description Moti was referring to.

As a next step we should verify there are no conflicts in functionality
and UI in both levels. Implementation wise, I like your re-use attempts, 
and I'd suggest revisiting the UI part based on network profiles. Network
profiles are consumers for network QoS entities just as logical network is a
consumer of network QoS entities. IIUC, you should be using the QoS left tab
as depicted in [2] in the new/edit logical network dialog.

Going forward we'll have to close the gaps of the API for both levels,
and make sure these QoS settings are managed properly as a policy and
delivered to the host, where it will be enforced by MoM.

Doron

[1] http://libvirt.org/formatnetwork.html 
[2] http://www.ovirt.org/File:New_netwrok_profiles.png




From dneary at redhat.com  Sun Jul 21 18:41:51 2013
From: dneary at redhat.com (Dave Neary)
Date: Sun, 21 Jul 2013 20:41:51 +0200
Subject: oVirt developer meeting @ KVM Forum
Message-ID: <51EC2B6F.1090406@redhat.com>

Hi everyone,

Put the date in your calendar! The oVirt developer meeting will be held
in Edinburgh on October 23rd alongside the KVM Forum.

As most of you know, the KVM Forum is happening alongside LinuxCon
Europe and CloudOpen Europe in Edinburgh this year, on October 21-23.

As we proposed to the oVirt board in January, we would like to take
advantage of this gathering of KVM core developers to plan the future of
the oVirt project too.

In addition to the numerous oVirt presentations which have been proposed
both for CloudOpen and the KVM Forum, we will be setting aside one day
for developer working sessions. The agenda for these sessions is not
(yet) set - we will have subject matter experts leading discussions on
the future of their component, where oVirt fits into the broader world
of virtualization and the cloud, and how we can grow the community.

Among the topics which may be on the table are:
* Storage - integration with Gluster, Ceph, Swift, Cinder, NetApp, EMC
* Core virtualization - what's missing to make oVirt the best
  virtualization solution on the market? What's next? How can oVirt
  best take advantage of the latest KVM features?
* Networking - Going beyond Quantum integration: L2 and L3 networking
  in oVirt
* User interface & engine - making oVirt nicer to use and easeir to
  learn
* Ecosystem - Integration with OpenStack, CloudStack; migration
  strategy from vSphere; integration with other 3rd party projects -
  what is our place in the world?
* Community and marketing - Should we add a forum? How can we grow the
  user base and community of oVirt?

(Note, these are just my ideas - topics will be set by session leaders
on a specific topic).

What next?

First, if you are interested in the future of the oVirt project, please
plan to attend the developer meeting. If you are active in oVirt, but
cannot finance your travel to the event, please send an email to
dneary at redhat.com - I can't promise anything, but we do not want budget
constraints to be the main reason for someone missing the meeting.

Second, if you are interested in leading a working session on one of the
topics above, or a different topic which is important to you, please
send an email to the Workshop program committee at workshop-pc at ovirt.org

We will keep you posted with schedule updates and more details as
plannign advances during the coming weeks.

Thanks for your interest, and for your support of oVirt!

Regards,
Dave Neary.


-- 
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 gvallare at redhat.com  Tue Jul 23 12:14:14 2013
From: gvallare at redhat.com (Giuseppe Vallarelli)
Date: Tue, 23 Jul 2013 08:14:14 -0400 (EDT)
Subject: Network traffic shaping.
In-Reply-To: <2059884441.5151895.1374394141589.JavaMail.root@redhat.com>
References: <1809186597.402470.1373280341185.JavaMail.root@redhat.com>
	<1742027705.3406607.1374246455114.JavaMail.root@redhat.com>
	<2059884441.5151895.1374394141589.JavaMail.root@redhat.com>
Message-ID: <1708477447.222186.1374581654700.JavaMail.root@redhat.com>

----- Original Message -----
| From: "Doron Fediuck" <dfediuck at redhat.com>
| To: "Moti Asayag" <masayag at redhat.com>
| Cc: "Giuseppe Vallarelli" <gvallare at redhat.com>, arch at ovirt.org
| Sent: Sunday, July 21, 2013 10:09:01 AM
| Subject: Re: Network traffic shaping.
| 
| 
| 
| ----- Original Message -----
| | From: "Moti Asayag" <masayag at redhat.com>
| | To: "Giuseppe Vallarelli" <gvallare at redhat.com>
| | Cc: arch at ovirt.org
| | Sent: Friday, July 19, 2013 6:07:35 PM
| | Subject: Re: Network traffic shaping.
| | 
| | Hi,
| | 
| | According to the 'Detailed description' section in the wiki, it is stated
| | that the
| | admin may override the traffic shaping of the network on the data-center
| | level with
| | a specific one per host.
| | 
| | Is there a need to persist this configuration on the engine side and to
| | present it
| | to the user or we just passing these settings to the host while configuring
| | the
| | network on the host and abandoning them afterwards? Meaning, VDSM will
| | report
| | the QoS per
| | host's network and it will be presented to the user. But the actual values
| | that
| | were used to set these network QoS won't be persistent on the engine side?
| | 
| | The answer to the above has further implication on the design on engine
| | side,
| | therefore before starting futile discussion, is there such a requirement ?
| | 
| | ----- Original Message -----
| | > From: "Giuseppe Vallarelli" <gvallare at redhat.com>
| | > To: arch at ovirt.org
| | > Sent: Monday, July 8, 2013 1:45:41 PM
| | > Subject: Network traffic shaping.
| | > 
| | > Hi everybody, I'm working to implement traffic shaping at the network
| | > level
| | > [1].
| | > This feature is composed by two distinct parts: definition of traffic
| | > shaping
| | > for a logical network entity and optional redefinition of traffic shaping
| | > when
| | > the user is doing a Setup Host Networks task. Initial focus will be on
| | > first
| | > part. There are some points of contact with Network Qos [2] that's why I
| | > proposed
| | > to reuse some code backend side.
| | > 
| | > Cheers, Giuseppe
| | > 
| | > [1] http://www.ovirt.org/Features/Network_traffic_shaping
| | > [2] http://www.ovirt.org/Features/Network_QoS
| 
| Hi guys,
| Adding my comments to Moti's;
| 
| First of all Giuseppe, looks like a good start for a much needed
| functionality in oVirt.
| So thumbs' up on driving it forward and having this discussion in place ;)
| Somehow, your writing was taken out of context, so I think we should
| clarify the concepts to begin with;

Hi Doron,

| Host-level traffic shaping handles one aspect in the domain of QoS. For
| 3.3 we're already planning VM-level networking QoS and your feature is
| completing it.
| Network traffic shaping is one implementation libvirt chose, in order
| to provide quality of service at host level. Look for "quality of service"
| in [1]. But we should also remember that it may have additional
| implementations
| which goes all the way to the network device, as we will need to handle in
| provided networks.

All right.

| 
| So for completeness and clarification we should align host-level network QoS
| with VM-level network QoS. Let's start with renaming the feature from it's
| implementation to what it should provide: host network QoS. Ofri may assist
| you with renaming current pages as needed to improve things. This may also
| help me find the detailed description Moti was referring to.

Ok I agree on the naming issue, I wanted to get Network QoS (still not the
best name) but that was already used. Host network QoS sounds good to me.

| As a next step we should verify there are no conflicts in functionality
| and UI in both levels. Implementation wise, I like your re-use attempts,
| and I'd suggest revisiting the UI part based on network profiles. Network
| profiles are consumers for network QoS entities just as logical network is a
| consumer of network QoS entities. IIUC, you should be using the QoS left tab
| as depicted in [2] in the new/edit logical network dialog.

For your UI concern, the actual mockups are rough sketches it's probably
going to look different. I agree with you on the need of having a possible
uniform UI look'n'feel. A possible idea for future releases would be to
have a sort of unified QoS dashboard where the admin can have an overall
picture of the defined QoS at multiple levels.

| Going forward we'll have to close the gaps of the API for both levels,
| and make sure these QoS settings are managed properly as a policy and
| delivered to the host, where it will be enforced by MoM.

Ok, thanks for the feedback,
Giuseppe

| 
| Doron
| 
| [1] http://libvirt.org/formatnetwork.html
| [2] http://www.ovirt.org/File:New_netwrok_profiles.png
| 
| 
| 


From mburns at redhat.com  Wed Jul 24 14:01:35 2013
From: mburns at redhat.com (Mike Burns)
Date: Wed, 24 Jul 2013 10:01:35 -0400 (EDT)
Subject: Cancelled: oVirt Weekly Meeting
Message-ID: <502245939.5356060.1374674495471.JavaMail.root@redhat.com>

A single instance of the following meeting has been cancelled:

Subject: oVirt Weekly Meeting 
Organizer: "Mike Burns" <mburns at redhat.com> 

Location: #ovirt of oftc.net 
Time: Wednesday, July 24, 2013, 10:00:00 AM - 11:00:00 AM GMT -05:00 US/Canada Eastern
 
Required: danken at redhat.com; oschreib at redhat.com; ykaul at redhat.com; sgordon at redhat.com; dfediuck at redhat.com; Jon.Benedict at netapp.com; pmyers at redhat.com; simon at redhat.com; imad.sousou at intel.com; aliguori at us.ibm.com; lhawthor at redhat.com ... 
Optional: arch at ovirt.org; board at ovirt.org; menescu at cisco.com 

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

Due to the ongoing test day, I'm cancelling this meeting for the week.  If there are any issues or topics to discuss, please send them to board at ovirt.org or users at ovirt.org

Thanks

Mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: meeting.ics
Type: text/calendar
Size: 4117 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20130724/ab410fdd/attachment.ics>

From alonbl at redhat.com  Sun Jul 28 07:46:09 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Sun, 28 Jul 2013 03:46:09 -0400 (EDT)
Subject: [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup
In-Reply-To: <1121392319.3565764.1374996539046.JavaMail.root@redhat.com>
Message-ID: <733894071.3566217.1374997569084.JavaMail.root@redhat.com>

Hello All,

I would like to receive feedback regarding how we should cope with a state presented to use by Fedora.

Fedora-19 minimal setup does not install tar utility which is required to deploy files during the host-deploy process (Hosts->Add Host).

I guess because of 2.8M in size (including translations) -- a standard commonly used utility was removed.

There are two alternatives :

1. Instruct users who are using minimal installations to manually install tar utility just like they configure repository, dns, etc..

Benefit: simplicity.
Benefit: use standard tools.
Benefit: lower payload to transmit.
Drawback: require tar at destination machine.

2. Do not use tar but self extracting python script, a patch is ready[1].

Benefit: ability to deploy environment in which tar is missing.
Drawback: non standard tool at destination machine.
Drawback: complexity within our code.

[[[
There was 3rd alternative, using python tar module to deploy tar.
However, there is a bug in that module when processing last block if empty.
This is edge condition but happened to at least one of the users and I could
reproduce it.
]]]

Regards,
Alon Bar-Lev

[1] http://gerrit.ovirt.org/#/c/17295/


From jhernand at redhat.com  Sun Jul 28 09:26:56 2013
From: jhernand at redhat.com (Juan Hernandez)
Date: Sun, 28 Jul 2013 11:26:56 +0200
Subject: [Users] [Feedback required][host-deploy] Fedora-19 misses tar
	at minimal setup
In-Reply-To: <733894071.3566217.1374997569084.JavaMail.root@redhat.com>
References: <733894071.3566217.1374997569084.JavaMail.root@redhat.com>
Message-ID: <51F4E3E0.600@redhat.com>

On 07/28/2013 09:46 AM, Alon Bar-Lev wrote:
> Hello All,
>
> I would like to receive feedback regarding how we should cope with a state presented to use by Fedora.
>
> Fedora-19 minimal setup does not install tar utility which is required to deploy files during the host-deploy process (Hosts->Add Host).
>
> I guess because of 2.8M in size (including translations) -- a standard commonly used utility was removed.
>
> There are two alternatives :
>
> 1. Instruct users who are using minimal installations to manually install tar utility just like they configure repository, dns, etc..
>
> Benefit: simplicity.
> Benefit: use standard tools.
> Benefit: lower payload to transmit.
> Drawback: require tar at destination machine.
>
> 2. Do not use tar but self extracting python script, a patch is ready[1].
>
> Benefit: ability to deploy environment in which tar is missing.
> Drawback: non standard tool at destination machine.
> Drawback: complexity within our code.
>
> [[[
> There was 3rd alternative, using python tar module to deploy tar.
> However, there is a bug in that module when processing last block if empty.
> This is edge condition but happened to at least one of the users and I could
> reproduce it.
> ]]]
>
> Regards,
> Alon Bar-Lev

Consider using cpio instead of tar. It is required to build initrd, so 
available in any installation. It is also supported by the library 
currently used in the engine to build the tar archive.

-- 
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 alonbl at redhat.com  Sun Jul 28 10:42:58 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Sun, 28 Jul 2013 06:42:58 -0400 (EDT)
Subject: [Users] [Feedback required][host-deploy] Fedora-19 misses tar
	at minimal setup
In-Reply-To: <51F4E3E0.600@redhat.com>
References: <733894071.3566217.1374997569084.JavaMail.root@redhat.com>
	<51F4E3E0.600@redhat.com>
Message-ID: <1199327522.3570177.1375008177999.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Juan Hernandez" <jhernand at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "arch" <arch at ovirt.org>, "users" <users at ovirt.org>
> Sent: Sunday, July 28, 2013 12:26:56 PM
> Subject: Re: [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup
> 
> On 07/28/2013 09:46 AM, Alon Bar-Lev wrote:
> > Hello All,
> >
> > I would like to receive feedback regarding how we should cope with a state
> > presented to use by Fedora.
> >
> > Fedora-19 minimal setup does not install tar utility which is required to
> > deploy files during the host-deploy process (Hosts->Add Host).
> >
> > I guess because of 2.8M in size (including translations) -- a standard
> > commonly used utility was removed.
> >
> > There are two alternatives :
> >
> > 1. Instruct users who are using minimal installations to manually install
> > tar utility just like they configure repository, dns, etc..
> >
> > Benefit: simplicity.
> > Benefit: use standard tools.
> > Benefit: lower payload to transmit.
> > Drawback: require tar at destination machine.
> >
> > 2. Do not use tar but self extracting python script, a patch is ready[1].
> >
> > Benefit: ability to deploy environment in which tar is missing.
> > Drawback: non standard tool at destination machine.
> > Drawback: complexity within our code.
> >
> > [[[
> > There was 3rd alternative, using python tar module to deploy tar.
> > However, there is a bug in that module when processing last block if empty.
> > This is edge condition but happened to at least one of the users and I
> > could
> > reproduce it.
> > ]]]
> >
> > Regards,
> > Alon Bar-Lev
> 
> Consider using cpio instead of tar. It is required to build initrd, so
> available in any installation. It is also supported by the library
> currently used in the engine to build the tar archive.

Thanks Juan, it is good idea.

I did not thought of using cpio, as I remembered that cpio has no embedded eof (a.cpio+b.cpio=cpio), but now I experiments and see that I was mistaken.

Will try to establish a working solution.

Thanks,
Alon


From alonbl at redhat.com  Mon Jul 29 07:15:33 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Mon, 29 Jul 2013 03:15:33 -0400 (EDT)
Subject: [Users] [Feedback required][host-deploy] Fedora-19 misses tar
	at minimal setup
In-Reply-To: <1199327522.3570177.1375008177999.JavaMail.root@redhat.com>
References: <733894071.3566217.1374997569084.JavaMail.root@redhat.com>
	<51F4E3E0.600@redhat.com>
	<1199327522.3570177.1375008177999.JavaMail.root@redhat.com>
Message-ID: <1832045797.3650023.1375082133389.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Juan Hernandez" <jhernand at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "arch" <arch at ovirt.org>, "users" <users at ovirt.org>
> Sent: Sunday, July 28, 2013 1:42:58 PM
> Subject: Re: [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup
> 
> 
> 
> ----- Original Message -----
> > From: "Juan Hernandez" <jhernand at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>, "arch" <arch at ovirt.org>,
> > "users" <users at ovirt.org>
> > Sent: Sunday, July 28, 2013 12:26:56 PM
> > Subject: Re: [Users] [Feedback required][host-deploy] Fedora-19 misses tar
> > at minimal setup
> > 
> > On 07/28/2013 09:46 AM, Alon Bar-Lev wrote:
> > > Hello All,
> > >
> > > I would like to receive feedback regarding how we should cope with a
> > > state
> > > presented to use by Fedora.
> > >
> > > Fedora-19 minimal setup does not install tar utility which is required to
> > > deploy files during the host-deploy process (Hosts->Add Host).
> > >
> > > I guess because of 2.8M in size (including translations) -- a standard
> > > commonly used utility was removed.
> > >
> > > There are two alternatives :
> > >
> > > 1. Instruct users who are using minimal installations to manually install
> > > tar utility just like they configure repository, dns, etc..
> > >
> > > Benefit: simplicity.
> > > Benefit: use standard tools.
> > > Benefit: lower payload to transmit.
> > > Drawback: require tar at destination machine.
> > >
> > > 2. Do not use tar but self extracting python script, a patch is ready[1].
> > >
> > > Benefit: ability to deploy environment in which tar is missing.
> > > Drawback: non standard tool at destination machine.
> > > Drawback: complexity within our code.
> > >
> > > [[[
> > > There was 3rd alternative, using python tar module to deploy tar.
> > > However, there is a bug in that module when processing last block if
> > > empty.
> > > This is edge condition but happened to at least one of the users and I
> > > could
> > > reproduce it.
> > > ]]]
> > >
> > > Regards,
> > > Alon Bar-Lev
> > 
> > Consider using cpio instead of tar. It is required to build initrd, so
> > available in any installation. It is also supported by the library
> > currently used in the engine to build the tar archive.
> 
> Thanks Juan, it is good idea.
> 
> I did not thought of using cpio, as I remembered that cpio has no embedded
> eof (a.cpio+b.cpio=cpio), but now I experiments and see that I was mistaken.
> 
> Will try to establish a working solution.

Done[1].
Thanks!

host-deploy: use cpio instead of tar for bundle transfer


for some reason fedora-18/19 got tar out of base system, so we are
forced to find some solution, although manual configuration is required
anyway (repository, networking etc...).

there was attempt to use python tar module, however this module has a
bug when last block is empty, so it is not suitable for usage.

cpio is alternative for fedora, however it is rightfully missing from
other distributions as it is much less used. as we do not support hosts
using different distributions, we are ok now.

in future, we can use python self extract script, work already performed
at: I1e5ddab9ae87979da7d7296c4f3c7ef08e21e903 at the price of
complexity.

Change-Id: I1386e7d688a9ec7e28519fb407478fd17cbab4ca
Signed-off-by: Alon Bar-Lev <alonbl at redhat.com>

[1] http://gerrit.ovirt.org/#/c/17396/


From dcaroest at redhat.com  Tue Jul 30 06:05:52 2013
From: dcaroest at redhat.com (David Caro)
Date: Tue, 30 Jul 2013 08:05:52 +0200
Subject: Gerrit hooks
Message-ID: <51F757C0.8050709@redhat.com>

Good morning!

Some basic gerrit hooks will be installed between today and tomorrow,
the first part is only the basic scripts that allow the individualized
execution of the hooks and the second part will bu the hooks themselves.

In a few minutes I'll start the installation of the infrastructure to
support the hooks, no service downtime is expected, in the worst case a
restart will be required though.

The second intervention will take place tomorrow morning (earlier than
today), and should not cause any service downtime neither (but as before
in the worst case a restart will be required).

I'll send another email later today explaining what this first set of
hooks will control.


Thanks!

-- 
David Caro

Red Hat Czech s.r.o.
Continuous Integration Engineer - EMEA ENG Virtualization R&D

Tel.: +420 532 294 605
Email: dcaro at redhat.com
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic
RHT Global #: 82-62605

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

From dcaroest at redhat.com  Tue Jul 30 06:36:05 2013
From: dcaroest at redhat.com (David Caro)
Date: Tue, 30 Jul 2013 08:36:05 +0200
Subject: Gerrit hooks
In-Reply-To: <51F757C0.8050709@redhat.com>
References: <51F757C0.8050709@redhat.com>
Message-ID: <51F75ED5.1050401@redhat.com>

On Tue 30 Jul 2013 08:05:52 AM CEST, David Caro wrote:
> Good morning!
>
> Some basic gerrit hooks will be installed between today and tomorrow,
> the first part is only the basic scripts that allow the individualized
> execution of the hooks and the second part will bu the hooks themselves.
>
> In a few minutes I'll start the installation of the infrastructure to
> support the hooks, no service downtime is expected, in the worst case a
> restart will be required though.
>
> The second intervention will take place tomorrow morning (earlier than
> today), and should not cause any service downtime neither (but as before
> in the worst case a restart will be required).
>
> I'll send another email later today explaining what this first set of
> hooks will control.
>
>
> Thanks!
>

First step successfully done!
Next intervention tomorrow morning (around 7:00 am CEST).

--
David Caro

Red Hat Czech s.r.o.
Continuous Integration Engineer - EMEA ENG Virtualization R&D

Tel.: +420 532 294 605
Email: dcaro at redhat.com
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic
RHT Global #: 82-62605


From alonbl at redhat.com  Tue Jul 30 13:12:03 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Tue, 30 Jul 2013 09:12:03 -0400 (EDT)
Subject: [Users] [Feedback required][host-deploy] Fedora-19 misses tar
	at minimal setup
In-Reply-To: <1832045797.3650023.1375082133389.JavaMail.root@redhat.com>
References: <733894071.3566217.1374997569084.JavaMail.root@redhat.com>
	<51F4E3E0.600@redhat.com>
	<1199327522.3570177.1375008177999.JavaMail.root@redhat.com>
	<1832045797.3650023.1375082133389.JavaMail.root@redhat.com>
Message-ID: <1031113778.4037715.1375189923523.JavaMail.root@redhat.com>

Hello All,

Starting the discussion again...

I would like to receive feedback regarding how we should cope with a state presented to use by Fedora.

Fedora-19 minimal setup does not install tar utility which is required to deploy files during the host-deploy process (Hosts->Add Host).

I guess because of 2.8M in size (including translations) -- a standard commonly used utility was removed.

There are three alternatives :

1. Instruct users who are using minimal installations to manually install tar utility just like they configure repository, dns, etc..

Benefit: simplicity.
Benefit: use standard tools.
Benefit: lower payload to transmit.
Drawback: require tar at destination machine.

2. Do not use tar but self extracting python script, a patch is ready[1].

Benefit: ability to deploy environment in which tar is missing.
Drawback: non standard tool at destination machine.
Drawback: complexity within our code.

3. Do not use tar but cpio, a patch is ready[2].

Benefit: simplicity.
Benefit: use standard tools.
Benefit: lower payload to transmit.
Benefit: ability to use Fedora-19 minimal.
Drawback: cpio is even less common than tar, even if it exists in Fedora-19 it can be removed without anyone notice.
Drawback: most other distributions will not have cpio in their minimal installation.

[[[
There was 4rd alternative, using python tar module to deploy tar.
However, there is a bug in that module when processing last block if empty.
This is edge condition but happened to at least one of the users and I could
reproduce it.
]]]

What option do you prefer?

Regards,
Alon Bar-Lev

[1] http://gerrit.ovirt.org/#/c/17295/
[2] http://gerrit.ovirt.org/#/c/17396/


From michal.skrivanek at redhat.com  Tue Jul 30 13:25:24 2013
From: michal.skrivanek at redhat.com (Michal Skrivanek)
Date: Tue, 30 Jul 2013 15:25:24 +0200
Subject: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19
	misses tar at minimal setup
In-Reply-To: <1031113778.4037715.1375189923523.JavaMail.root@redhat.com>
References: <733894071.3566217.1374997569084.JavaMail.root@redhat.com>
	<51F4E3E0.600@redhat.com>
	<1199327522.3570177.1375008177999.JavaMail.root@redhat.com>
	<1832045797.3650023.1375082133389.JavaMail.root@redhat.com>
	<1031113778.4037715.1375189923523.JavaMail.root@redhat.com>
Message-ID: <2E2BF622-110C-47C1-8C45-111F4B74C379@redhat.com>


On Jul 30, 2013, at 15:12 , Alon Bar-Lev <alonbl at redhat.com> wrote:

> Hello All,
> 
> Starting the discussion again...
> 
> I would like to receive feedback regarding how we should cope with a state presented to use by Fedora.
> 
> Fedora-19 minimal setup does not install tar utility which is required to deploy files during the host-deploy process (Hosts->Add Host).
> 
> I guess because of 2.8M in size (including translations) -- a standard commonly used utility was removed.

How about filing bug on that? This is such a basic utility I can't imagine anyone removing it.

> 
> There are three alternatives :
> 
> 1. Instruct users who are using minimal installations to manually install tar utility just like they configure repository, dns, etc..
> 
> Benefit: simplicity.
> Benefit: use standard tools.
> Benefit: lower payload to transmit.
> Drawback: require tar at destination machine.
> 
> 2. Do not use tar but self extracting python script, a patch is ready[1].
> 
> Benefit: ability to deploy environment in which tar is missing.
> Drawback: non standard tool at destination machine.
> Drawback: complexity within our code.
> 
> 3. Do not use tar but cpio, a patch is ready[2].
> 
> Benefit: simplicity.
> Benefit: use standard tools.
> Benefit: lower payload to transmit.
> Benefit: ability to use Fedora-19 minimal.
> Drawback: cpio is even less common than tar, even if it exists in Fedora-19 it can be removed without anyone notice.
> Drawback: most other distributions will not have cpio in their minimal installation.
> 
> [[[
> There was 4rd alternative, using python tar module to deploy tar.
> However, there is a bug in that module when processing last block if empty.
> This is edge condition but happened to at least one of the users and I could
> reproduce it.
> ]]]
> 
> What option do you prefer?
> 
> Regards,
> Alon Bar-Lev
> 
> [1] http://gerrit.ovirt.org/#/c/17295/
> [2] http://gerrit.ovirt.org/#/c/17396/
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From asegurap at redhat.com  Tue Jul 30 14:09:47 2013
From: asegurap at redhat.com (Antoni Segura Puimedon)
Date: Tue, 30 Jul 2013 10:09:47 -0400 (EDT)
Subject: [Engine-devel] [Users] [Feedback required][host-deploy]
	Fedora-19	misses tar at minimal setup
In-Reply-To: <2E2BF622-110C-47C1-8C45-111F4B74C379@redhat.com>
References: <733894071.3566217.1374997569084.JavaMail.root@redhat.com>
	<51F4E3E0.600@redhat.com>
	<1199327522.3570177.1375008177999.JavaMail.root@redhat.com>
	<1832045797.3650023.1375082133389.JavaMail.root@redhat.com>
	<1031113778.4037715.1375189923523.JavaMail.root@redhat.com>
	<2E2BF622-110C-47C1-8C45-111F4B74C379@redhat.com>
Message-ID: <1118719160.4093235.1375193387063.JavaMail.root@redhat.com>

I would advocate for  option 2.

----- Original Message -----
> From: "Michal Skrivanek" <michal.skrivanek at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Juan Hernandez" <jhernand at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, "arch" <arch at ovirt.org>, "users"
> <users at ovirt.org>
> Sent: Tuesday, July 30, 2013 3:25:24 PM
> Subject: Re: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19	misses tar at minimal setup
> 
> 
> On Jul 30, 2013, at 15:12 , Alon Bar-Lev <alonbl at redhat.com> wrote:
> 
> > Hello All,
> > 
> > Starting the discussion again...
> > 
> > I would like to receive feedback regarding how we should cope with a state
> > presented to use by Fedora.
> > 
> > Fedora-19 minimal setup does not install tar utility which is required to
> > deploy files during the host-deploy process (Hosts->Add Host).
> > 
> > I guess because of 2.8M in size (including translations) -- a standard
> > commonly used utility was removed.
> 
> How about filing bug on that? This is such a basic utility I can't imagine
> anyone removing it.
> 
> > 
> > There are three alternatives :
> > 
> > 1. Instruct users who are using minimal installations to manually install
> > tar utility just like they configure repository, dns, etc..
> > 
> > Benefit: simplicity.
> > Benefit: use standard tools.
> > Benefit: lower payload to transmit.
> > Drawback: require tar at destination machine.
> > 
> > 2. Do not use tar but self extracting python script, a patch is ready[1].
> > 
> > Benefit: ability to deploy environment in which tar is missing.
> > Drawback: non standard tool at destination machine.
> > Drawback: complexity within our code.
> > 
> > 3. Do not use tar but cpio, a patch is ready[2].
> > 
> > Benefit: simplicity.
> > Benefit: use standard tools.
> > Benefit: lower payload to transmit.
> > Benefit: ability to use Fedora-19 minimal.
> > Drawback: cpio is even less common than tar, even if it exists in Fedora-19
> > it can be removed without anyone notice.
> > Drawback: most other distributions will not have cpio in their minimal
> > installation.
> > 
> > [[[
> > There was 4rd alternative, using python tar module to deploy tar.
> > However, there is a bug in that module when processing last block if empty.
> > This is edge condition but happened to at least one of the users and I
> > could
> > reproduce it.
> > ]]]
> > 
> > What option do you prefer?
> > 
> > Regards,
> > Alon Bar-Lev
> > 
> > [1] http://gerrit.ovirt.org/#/c/17295/
> > [2] http://gerrit.ovirt.org/#/c/17396/
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From alonbl at redhat.com  Tue Jul 30 15:17:48 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Tue, 30 Jul 2013 11:17:48 -0400 (EDT)
Subject: [Engine-devel] [Users] [Feedback required][host-deploy]
	Fedora-19 misses tar at minimal setup
In-Reply-To: <51F7D7AA.2020102@redhat.com>
References: <733894071.3566217.1374997569084.JavaMail.root@redhat.com>
	<51F4E3E0.600@redhat.com>
	<1199327522.3570177.1375008177999.JavaMail.root@redhat.com>
	<1832045797.3650023.1375082133389.JavaMail.root@redhat.com>
	<1031113778.4037715.1375189923523.JavaMail.root@redhat.com>
	<51F7D7AA.2020102@redhat.com>
Message-ID: <251998728.4130707.1375197468062.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "users" <users at ovirt.org>, "arch" <arch at ovirt.org>, "engine-devel" <engine-devel at ovirt.org>, "Juan Hernandez"
> <jhernand at redhat.com>
> Sent: Tuesday, July 30, 2013 6:11:38 PM
> Subject: Re: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup
> 
> Il 30/07/2013 15:12, Alon Bar-Lev ha scritto:
> > Hello All,
> >
> > Starting the discussion again...
> >
> > I would like to receive feedback regarding how we should cope with a state
> > presented to use by Fedora.
> >
> > Fedora-19 minimal setup does not install tar utility which is required to
> > deploy files during the host-deploy process (Hosts->Add Host).
> >
> > I guess because of 2.8M in size (including translations) -- a standard
> > commonly used utility was removed.
> >
> > There are three alternatives :
> >
> > 1. Instruct users who are using minimal installations to manually install
> > tar utility just like they configure repository, dns, etc..
> >
> > Benefit: simplicity.
> > Benefit: use standard tools.
> > Benefit: lower payload to transmit.
> > Drawback: require tar at destination machine.
> >
> > 2. Do not use tar but self extracting python script, a patch is ready[1].
> >
> > Benefit: ability to deploy environment in which tar is missing.
> > Drawback: non standard tool at destination machine.
> > Drawback: complexity within our code.
> >
> > 3. Do not use tar but cpio, a patch is ready[2].
> >
> > Benefit: simplicity.
> > Benefit: use standard tools.
> > Benefit: lower payload to transmit.
> > Benefit: ability to use Fedora-19 minimal.
> > Drawback: cpio is even less common than tar, even if it exists in Fedora-19
> > it can be removed without anyone notice.
> > Drawback: most other distributions will not have cpio in their minimal
> > installation.
> >
> > [[[
> > There was 4rd alternative, using python tar module to deploy tar.
> > However, there is a bug in that module when processing last block if empty.
> > This is edge condition but happened to at least one of the users and I
> > could
> > reproduce it.
> > ]]]
> >
> > What option do you prefer?
> 
> Well, honestly, the solution I like more than the others is having the
> python tar bug fixed and be free to use the python tar lib.
> 
> I would like to exclude cpio: it's on rpm based distro but not commonly
> available on others.
> 
> I would like to exclude the RTFM solution, having it working out of the box.
> 
> So my second choice is using a self extracting script.
> If you think pyar is a non standard tool, do you have considered the use
> of shar?
> Or do you think it's also a non standard tool?

shar needs dependencies on remote:
- md5sum
- uudecode

> 
> 
> 
> >
> > Regards,
> > Alon Bar-Lev
> >
> > [1] http://gerrit.ovirt.org/#/c/17295/
> > [2] http://gerrit.ovirt.org/#/c/17396/
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 
> --
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
> 
> 


From dcaroest at redhat.com  Tue Jul 30 19:02:46 2013
From: dcaroest at redhat.com (David Caro)
Date: Tue, 30 Jul 2013 21:02:46 +0200
Subject: What the new gerrit hoks will do
Message-ID: <51F80DD6.8030405@redhat.com>

Hi all!

As promised here's an explanation of what the hooks will take care of:

When a patch is submitted:
  If the commit message has Bug-Url tag:
    - for each Bug-Url:
      * Check that the bug is public
      * Add an external tracker to the patch if not there already
      * Move the bug status to POST
    - Report back the result of all the previous actions
    - Review with +1 if the bug was public, -1 if it was private

When a comment is added:
  If the "Rerun-Hooks: all" line was added:
    - Rerun all the hooks that ran when the hook was submitted

When a patch is submitted:
  If the commit message has Bug-Url:
    - For each Bug-Url:
      * Check if the product for the bug is correct
      * If it was, move the bug status to MODIFIED

Keep in mind that this is a first step towards automation of the whole
process.

Also, as always any input, ideas, or even complaints are welcome :)

pd. Yes I will add this and more info to the wiki as soon as I have some
spare time to do it.

-- 
David Caro

Red Hat Czech s.r.o.
Continuous Integration Engineer - EMEA ENG Virtualization R&D

Tel.: +420 532 294 605
Email: dcaro at redhat.com
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic
RHT Global #: 82-62605

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

From iheim at redhat.com  Tue Jul 30 19:11:22 2013
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 30 Jul 2013 22:11:22 +0300
Subject: What the new gerrit hoks will do
In-Reply-To: <51F80DD6.8030405@redhat.com>
References: <51F80DD6.8030405@redhat.com>
Message-ID: <51F80FDA.80902@redhat.com>

On 07/30/2013 10:02 PM, David Caro wrote:
> Hi all!
>
> As promised here's an explanation of what the hooks will take care of:
>
> When a patch is submitted:
>    If the commit message has Bug-Url tag:
>      - for each Bug-Url:
>        * Check that the bug is public
>        * Add an external tracker to the patch if not there already
>        * Move the bug status to POST
>      - Report back the result of all the previous actions
>      - Review with +1 if the bug was public, -1 if it was private

shouldn't +1, only -1.

>
> When a comment is added:
>    If the "Rerun-Hooks: all" line was added:
>      - Rerun all the hooks that ran when the hook was submitted
>
> When a patch is submitted:
>    If the commit message has Bug-Url:
>      - For each Bug-Url:
>        * Check if the product for the bug is correct

meaning it checks the bug is on the ovirt bugzilla?

>        * If it was, move the bug status to MODIFIED
>
> Keep in mind that this is a first step towards automation of the whole
> process.
>
> Also, as always any input, ideas, or even complaints are welcome :)
>
> pd. Yes I will add this and more info to the wiki as soon as I have some
> spare time to do it.
>
>
>
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
>



From dougsland at redhat.com  Tue Jul 30 21:24:34 2013
From: dougsland at redhat.com (Douglas Schilling Landgraf)
Date: Tue, 30 Jul 2013 17:24:34 -0400
Subject: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19
	misses tar at minimal setup
In-Reply-To: <2E2BF622-110C-47C1-8C45-111F4B74C379@redhat.com>
References: <733894071.3566217.1374997569084.JavaMail.root@redhat.com>
	<51F4E3E0.600@redhat.com>
	<1199327522.3570177.1375008177999.JavaMail.root@redhat.com>
	<1832045797.3650023.1375082133389.JavaMail.root@redhat.com>
	<1031113778.4037715.1375189923523.JavaMail.root@redhat.com>
	<2E2BF622-110C-47C1-8C45-111F4B74C379@redhat.com>
Message-ID: <51F82F12.1010608@redhat.com>

On 07/30/2013 09:25 AM, Michal Skrivanek wrote:
>
> On Jul 30, 2013, at 15:12 , Alon Bar-Lev <alonbl at redhat.com> wrote:
>
>> Hello All,
>>
>> Starting the discussion again...
>>
>> I would like to receive feedback regarding how we should cope with a state presented to use by Fedora.
>>
>> Fedora-19 minimal setup does not install tar utility which is required to deploy files during the host-deploy process (Hosts->Add Host).
>>
>> I guess because of 2.8M in size (including translations) -- a standard commonly used utility was removed.
>
> How about filing bug on that? This is such a basic utility I can't imagine anyone removing it.

+1 I do agree with Michael. I have opened a thread in fedora devel 
mailing list anyway.



>
>>
>> There are three alternatives :
>>
>> 1. Instruct users who are using minimal installations to manually install tar utility just like they configure repository, dns, etc..
>>
>> Benefit: simplicity.
>> Benefit: use standard tools.
>> Benefit: lower payload to transmit.
>> Drawback: require tar at destination machine.
>>
>> 2. Do not use tar but self extracting python script, a patch is ready[1].
>>
>> Benefit: ability to deploy environment in which tar is missing.
>> Drawback: non standard tool at destination machine.
>> Drawback: complexity within our code.
>>
>> 3. Do not use tar but cpio, a patch is ready[2].
>>
>> Benefit: simplicity.
>> Benefit: use standard tools.
>> Benefit: lower payload to transmit.
>> Benefit: ability to use Fedora-19 minimal.
>> Drawback: cpio is even less common than tar, even if it exists in Fedora-19 it can be removed without anyone notice.
>> Drawback: most other distributions will not have cpio in their minimal installation.
>>
>> [[[
>> There was 4rd alternative, using python tar module to deploy tar.
>> However, there is a bug in that module when processing last block if empty.
>> This is edge condition but happened to at least one of the users and I could
>> reproduce it.
>> ]]]
>>
>> What option do you prefer?
>>
>> Regards,
>> Alon Bar-Lev
>>
>> [1] http://gerrit.ovirt.org/#/c/17295/
>> [2] http://gerrit.ovirt.org/#/c/17396/
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>


-- 
Cheers
Douglas


From danken at redhat.com  Tue Jul 30 21:40:29 2013
From: danken at redhat.com (Dan Kenigsberg)
Date: Wed, 31 Jul 2013 00:40:29 +0300
Subject: [Users] [Engine-devel] [Feedback required][host-deploy]
	Fedora-19	misses tar at minimal setup
In-Reply-To: <1118719160.4093235.1375193387063.JavaMail.root@redhat.com>
References: <733894071.3566217.1374997569084.JavaMail.root@redhat.com>
	<51F4E3E0.600@redhat.com>
	<1199327522.3570177.1375008177999.JavaMail.root@redhat.com>
	<1832045797.3650023.1375082133389.JavaMail.root@redhat.com>
	<1031113778.4037715.1375189923523.JavaMail.root@redhat.com>
	<2E2BF622-110C-47C1-8C45-111F4B74C379@redhat.com>
	<1118719160.4093235.1375193387063.JavaMail.root@redhat.com>
Message-ID: <20130730214029.GA24058@redhat.com>

On Tue, Jul 30, 2013 at 10:09:47AM -0400, Antoni Segura Puimedon wrote:
> I would advocate for  option 2.
> 
> ----- Original Message -----
> > From: "Michal Skrivanek" <michal.skrivanek at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: "Juan Hernandez" <jhernand at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, "arch" <arch at ovirt.org>, "users"
> > <users at ovirt.org>
> > Sent: Tuesday, July 30, 2013 3:25:24 PM
> > Subject: Re: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19	misses tar at minimal setup
> > 
> > 
> > On Jul 30, 2013, at 15:12 , Alon Bar-Lev <alonbl at redhat.com> wrote:
> > 
> > > Hello All,
> > > 
> > > Starting the discussion again...
> > > 
> > > I would like to receive feedback regarding how we should cope with a state
> > > presented to use by Fedora.
> > > 
> > > Fedora-19 minimal setup does not install tar utility which is required to
> > > deploy files during the host-deploy process (Hosts->Add Host).
> > > 
> > > I guess because of 2.8M in size (including translations) -- a standard
> > > commonly used utility was removed.
> > 
> > How about filing bug on that? This is such a basic utility I can't imagine
> > anyone removing it.
> > 
> > > 
> > > There are three alternatives :
> > > 
> > > 1. Instruct users who are using minimal installations to manually install
> > > tar utility just like they configure repository, dns, etc..
> > > 
> > > Benefit: simplicity.
> > > Benefit: use standard tools.
> > > Benefit: lower payload to transmit.
> > > Drawback: require tar at destination machine.
> > > 
> > > 2. Do not use tar but self extracting python script, a patch is ready[1].
> > > 
> > > Benefit: ability to deploy environment in which tar is missing.
> > > Drawback: non standard tool at destination machine.
> > > Drawback: complexity within our code.

How about option 2.1: convince Fedora to reintroduce tar? It is ironic
that Gnome is shipped by default, but not such a staple utility.

Where in Fedora did this decision take place? Can it be undone?
Is it commonplace these days among other distros to boycot tar?

Dan.


From dcaroest at redhat.com  Wed Jul 31 05:58:57 2013
From: dcaroest at redhat.com (David Caro)
Date: Wed, 31 Jul 2013 07:58:57 +0200
Subject: Gerrit hooks, second step
Message-ID: <51F8A7A1.3030503@redhat.com>

Hi everyone!
The installation of the second step for the gerrit hooks has to be
delayed due to the lack of user permissions for the automation bugzilla
user, will update again as soon as those permissions get changed.

In the meantime, the hooks will be disabled as there is no point on
running them without being able to do anything about it.

Sorry for the waiting!

-- 
David Caro

Red Hat Czech s.r.o.
Continuous Integration Engineer - EMEA ENG Virtualization R&D

Tel.: +420 532 294 605
Email: dcaro at redhat.com
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic
RHT Global #: 82-62605

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

From dcaroest at redhat.com  Wed Jul 31 06:07:33 2013
From: dcaroest at redhat.com (David Caro)
Date: Wed, 31 Jul 2013 08:07:33 +0200
Subject: What the new gerrit hoks will do
In-Reply-To: <51F80FDA.80902@redhat.com>
References: <51F80DD6.8030405@redhat.com> <51F80FDA.80902@redhat.com>
Message-ID: <51F8A9A5.1020105@redhat.com>

On Tue 30 Jul 2013 09:11:22 PM CEST, Itamar Heim wrote:
> On 07/30/2013 10:02 PM, David Caro wrote:
>> Hi all!
>>
>> As promised here's an explanation of what the hooks will take care of:
>>
>> When a patch is submitted:
>>    If the commit message has Bug-Url tag:
>>      - for each Bug-Url:
>>        * Check that the bug is public
>>        * Add an external tracker to the patch if not there already
>>        * Move the bug status to POST
>>      - Report back the result of all the previous actions
>>      - Review with +1 if the bug was public, -1 if it was private
>
> shouldn't +1, only -1.

You are right! It only reviews the patch and clears it's previous 
review (set's it as neutral, not +1).

>
>>
>> When a comment is added:
>>    If the "Rerun-Hooks: all" line was added:
>>      - Rerun all the hooks that ran when the hook was submitted
>>
>> When a patch is submitted:
>>    If the commit message has Bug-Url:
>>      - For each Bug-Url:
>>        * Check if the product for the bug is correct
>
> meaning it checks the bug is on the ovirt bugzilla?

Correct, it checks that the bug belongs to the oVirt product.

>
>>        * If it was, move the bug status to MODIFIED
>>
>> Keep in mind that this is a first step towards automation of the whole
>> process.
>>
>> Also, as always any input, ideas, or even complaints are welcome :)
>>
>> pd. Yes I will add this and more info to the wiki as soon as I have some
>> spare time to do it.
>>
>>
>>
>> _______________________________________________
>> Arch mailing list
>> Arch at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/arch
>>
>



--
David Caro

Red Hat Czech s.r.o.
Continuous Integration Engineer - EMEA ENG Virtualization R&D

Tel.: +420 532 294 605
Email: dcaro at redhat.com
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic
RHT Global #: 82-62605


From alonbl at redhat.com  Wed Jul 31 07:23:17 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Wed, 31 Jul 2013 03:23:17 -0400 (EDT)
Subject: What the new gerrit hoks will do
In-Reply-To: <51F80DD6.8030405@redhat.com>
References: <51F80DD6.8030405@redhat.com>
Message-ID: <1783325633.4424023.1375255397075.JavaMail.root@redhat.com>


Hi,

I don't think it is good to have auto POST/MODIFIED.
As there can be more than one patch per bug.

Alon

----- Original Message -----
> From: "David Caro" <dcaroest at redhat.com>
> To: arch at ovirt.org
> Sent: Tuesday, July 30, 2013 10:02:46 PM
> Subject: What the new gerrit hoks will do
> 
> Hi all!
> 
> As promised here's an explanation of what the hooks will take care of:
> 
> When a patch is submitted:
>   If the commit message has Bug-Url tag:
>     - for each Bug-Url:
>       * Check that the bug is public
>       * Add an external tracker to the patch if not there already
>       * Move the bug status to POST
>     - Report back the result of all the previous actions
>     - Review with +1 if the bug was public, -1 if it was private
> 
> When a comment is added:
>   If the "Rerun-Hooks: all" line was added:
>     - Rerun all the hooks that ran when the hook was submitted
> 
> When a patch is submitted:
>   If the commit message has Bug-Url:
>     - For each Bug-Url:
>       * Check if the product for the bug is correct
>       * If it was, move the bug status to MODIFIED
> 
> Keep in mind that this is a first step towards automation of the whole
> process.
> 
> Also, as always any input, ideas, or even complaints are welcome :)
> 
> pd. Yes I will add this and more info to the wiki as soon as I have some
> spare time to do it.
> 
> --
> David Caro
> 
> Red Hat Czech s.r.o.
> Continuous Integration Engineer - EMEA ENG Virtualization R&D
> 
> Tel.: +420 532 294 605
> Email: dcaro at redhat.com
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic
> RHT Global #: 82-62605
> 
> 
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From iheim at redhat.com  Wed Jul 31 07:24:56 2013
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 31 Jul 2013 10:24:56 +0300
Subject: What the new gerrit hoks will do
In-Reply-To: <1783325633.4424023.1375255397075.JavaMail.root@redhat.com>
References: <51F80DD6.8030405@redhat.com>
	<1783325633.4424023.1375255397075.JavaMail.root@redhat.com>
Message-ID: <51F8BBC8.8020404@redhat.com>

On 07/31/2013 10:23 AM, Alon Bar-Lev wrote:
>
> Hi,
>
> I don't think it is good to have auto POST/MODIFIED.
> As there can be more than one patch per bug.

i think post is still correct.
modified will only move if all patches with this bug-url are merged iiuc.
a new patch with same bug-url will move the bug back to POST.

>
> Alon
>
> ----- Original Message -----
>> From: "David Caro" <dcaroest at redhat.com>
>> To: arch at ovirt.org
>> Sent: Tuesday, July 30, 2013 10:02:46 PM
>> Subject: What the new gerrit hoks will do
>>
>> Hi all!
>>
>> As promised here's an explanation of what the hooks will take care of:
>>
>> When a patch is submitted:
>>    If the commit message has Bug-Url tag:
>>      - for each Bug-Url:
>>        * Check that the bug is public
>>        * Add an external tracker to the patch if not there already
>>        * Move the bug status to POST
>>      - Report back the result of all the previous actions
>>      - Review with +1 if the bug was public, -1 if it was private
>>
>> When a comment is added:
>>    If the "Rerun-Hooks: all" line was added:
>>      - Rerun all the hooks that ran when the hook was submitted
>>
>> When a patch is submitted:
>>    If the commit message has Bug-Url:
>>      - For each Bug-Url:
>>        * Check if the product for the bug is correct
>>        * If it was, move the bug status to MODIFIED
>>
>> Keep in mind that this is a first step towards automation of the whole
>> process.
>>
>> Also, as always any input, ideas, or even complaints are welcome :)
>>
>> pd. Yes I will add this and more info to the wiki as soon as I have some
>> spare time to do it.
>>
>> --
>> David Caro
>>
>> Red Hat Czech s.r.o.
>> Continuous Integration Engineer - EMEA ENG Virtualization R&D
>>
>> Tel.: +420 532 294 605
>> Email: dcaro at redhat.com
>> Web: www.cz.redhat.com
>> Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic
>> RHT Global #: 82-62605
>>
>>
>> _______________________________________________
>> 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  Tue Jul 30 15:11:38 2013
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Tue, 30 Jul 2013 17:11:38 +0200
Subject: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19
	misses tar at minimal setup
In-Reply-To: <1031113778.4037715.1375189923523.JavaMail.root@redhat.com>
References: <733894071.3566217.1374997569084.JavaMail.root@redhat.com>
	<51F4E3E0.600@redhat.com>
	<1199327522.3570177.1375008177999.JavaMail.root@redhat.com>
	<1832045797.3650023.1375082133389.JavaMail.root@redhat.com>
	<1031113778.4037715.1375189923523.JavaMail.root@redhat.com>
Message-ID: <51F7D7AA.2020102@redhat.com>

Il 30/07/2013 15:12, Alon Bar-Lev ha scritto:
> Hello All,
>
> Starting the discussion again...
>
> I would like to receive feedback regarding how we should cope with a state presented to use by Fedora.
>
> Fedora-19 minimal setup does not install tar utility which is required to deploy files during the host-deploy process (Hosts->Add Host).
>
> I guess because of 2.8M in size (including translations) -- a standard commonly used utility was removed.
>
> There are three alternatives :
>
> 1. Instruct users who are using minimal installations to manually install tar utility just like they configure repository, dns, etc..
>
> Benefit: simplicity.
> Benefit: use standard tools.
> Benefit: lower payload to transmit.
> Drawback: require tar at destination machine.
>
> 2. Do not use tar but self extracting python script, a patch is ready[1].
>
> Benefit: ability to deploy environment in which tar is missing.
> Drawback: non standard tool at destination machine.
> Drawback: complexity within our code.
>
> 3. Do not use tar but cpio, a patch is ready[2].
>
> Benefit: simplicity.
> Benefit: use standard tools.
> Benefit: lower payload to transmit.
> Benefit: ability to use Fedora-19 minimal.
> Drawback: cpio is even less common than tar, even if it exists in Fedora-19 it can be removed without anyone notice.
> Drawback: most other distributions will not have cpio in their minimal installation.
>
> [[[
> There was 4rd alternative, using python tar module to deploy tar.
> However, there is a bug in that module when processing last block if empty.
> This is edge condition but happened to at least one of the users and I could
> reproduce it.
> ]]]
>
> What option do you prefer?

Well, honestly, the solution I like more than the others is having the
python tar bug fixed and be free to use the python tar lib.

I would like to exclude cpio: it's on rpm based distro but not commonly
available on others.

I would like to exclude the RTFM solution, having it working out of the box.

So my second choice is using a self extracting script.
If you think pyar is a non standard tool, do you have considered the use
of shar?
Or do you think it's also a non standard tool?



>
> Regards,
> Alon Bar-Lev
>
> [1] http://gerrit.ovirt.org/#/c/17295/
> [2] http://gerrit.ovirt.org/#/c/17396/
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel


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



From alonbl at redhat.com  Wed Jul 31 07:34:14 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Wed, 31 Jul 2013 03:34:14 -0400 (EDT)
Subject: What the new gerrit hoks will do
In-Reply-To: <51F8BBC8.8020404@redhat.com>
References: <51F80DD6.8030405@redhat.com>
	<1783325633.4424023.1375255397075.JavaMail.root@redhat.com>
	<51F8BBC8.8020404@redhat.com>
Message-ID: <1239768242.4425906.1375256054395.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "David Caro" <dcaroest at redhat.com>, arch at ovirt.org
> Sent: Wednesday, July 31, 2013 10:24:56 AM
> Subject: Re: What the new gerrit hoks will do
> 
> On 07/31/2013 10:23 AM, Alon Bar-Lev wrote:
> >
> > Hi,
> >
> > I don't think it is good to have auto POST/MODIFIED.
> > As there can be more than one patch per bug.
> 
> i think post is still correct.
> modified will only move if all patches with this bug-url are merged iiuc.
> a new patch with same bug-url will move the bug back to POST.

And the robot will move this to ONQA if there is a gap and there is a build.
Too much automation is also bad.

> 
> >
> > Alon
> >
> > ----- Original Message -----
> >> From: "David Caro" <dcaroest at redhat.com>
> >> To: arch at ovirt.org
> >> Sent: Tuesday, July 30, 2013 10:02:46 PM
> >> Subject: What the new gerrit hoks will do
> >>
> >> Hi all!
> >>
> >> As promised here's an explanation of what the hooks will take care of:
> >>
> >> When a patch is submitted:
> >>    If the commit message has Bug-Url tag:
> >>      - for each Bug-Url:
> >>        * Check that the bug is public
> >>        * Add an external tracker to the patch if not there already
> >>        * Move the bug status to POST
> >>      - Report back the result of all the previous actions
> >>      - Review with +1 if the bug was public, -1 if it was private
> >>
> >> When a comment is added:
> >>    If the "Rerun-Hooks: all" line was added:
> >>      - Rerun all the hooks that ran when the hook was submitted
> >>
> >> When a patch is submitted:
> >>    If the commit message has Bug-Url:
> >>      - For each Bug-Url:
> >>        * Check if the product for the bug is correct
> >>        * If it was, move the bug status to MODIFIED
> >>
> >> Keep in mind that this is a first step towards automation of the whole
> >> process.
> >>
> >> Also, as always any input, ideas, or even complaints are welcome :)
> >>
> >> pd. Yes I will add this and more info to the wiki as soon as I have some
> >> spare time to do it.
> >>
> >> --
> >> David Caro
> >>
> >> Red Hat Czech s.r.o.
> >> Continuous Integration Engineer - EMEA ENG Virtualization R&D
> >>
> >> Tel.: +420 532 294 605
> >> Email: dcaro at redhat.com
> >> Web: www.cz.redhat.com
> >> Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic
> >> RHT Global #: 82-62605
> >>
> >>
> >> _______________________________________________
> >> 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 dcaroest at redhat.com  Wed Jul 31 08:01:20 2013
From: dcaroest at redhat.com (David Caro)
Date: Wed, 31 Jul 2013 10:01:20 +0200
Subject: What the new gerrit hoks will do
In-Reply-To: <51F8BBC8.8020404@redhat.com>
References: <51F80DD6.8030405@redhat.com>
	<1783325633.4424023.1375255397075.JavaMail.root@redhat.com>
	<51F8BBC8.8020404@redhat.com>
Message-ID: <51F8C450.8030205@redhat.com>

On 07/31/2013 09:24 AM, Itamar Heim wrote:
> On 07/31/2013 10:23 AM, Alon Bar-Lev wrote:
>>
>> Hi,
>>
>> I don't think it is good to have auto POST/MODIFIED.
>> As there can be more than one patch per bug.
> 
> i think post is still correct.
> modified will only move if all patches with this bug-url are merged iiuc.
> a new patch with same bug-url will move the bug back to POST.

Right, I forgot to clarify that only those bugs with all their external
tracked patches closed will be changed to MODIFIED.

> 
>>
>> Alon
>>
>> ----- Original Message -----
>>> From: "David Caro" <dcaroest at redhat.com>
>>> To: arch at ovirt.org
>>> Sent: Tuesday, July 30, 2013 10:02:46 PM
>>> Subject: What the new gerrit hoks will do
>>>
>>> Hi all!
>>>
>>> As promised here's an explanation of what the hooks will take care of:
>>>
>>> When a patch is submitted:
>>>    If the commit message has Bug-Url tag:
>>>      - for each Bug-Url:
>>>        * Check that the bug is public
>>>        * Add an external tracker to the patch if not there already
>>>        * Move the bug status to POST
>>>      - Report back the result of all the previous actions
>>>      - Review with +1 if the bug was public, -1 if it was private
>>>
>>> When a comment is added:
>>>    If the "Rerun-Hooks: all" line was added:
>>>      - Rerun all the hooks that ran when the hook was submitted
>>>
>>> When a patch is submitted:
>>>    If the commit message has Bug-Url:
>>>      - For each Bug-Url:
>>>        * Check if the product for the bug is correct
>>>        * If it was, move the bug status to MODIFIED
>>>
>>> Keep in mind that this is a first step towards automation of the whole
>>> process.
>>>
>>> Also, as always any input, ideas, or even complaints are welcome :)
>>>
>>> pd. Yes I will add this and more info to the wiki as soon as I have some
>>> spare time to do it.
>>>
>>> -- 
>>> David Caro
>>>
>>> Red Hat Czech s.r.o.
>>> Continuous Integration Engineer - EMEA ENG Virtualization R&D
>>>
>>> Tel.: +420 532 294 605
>>> Email: dcaro at redhat.com
>>> Web: www.cz.redhat.com
>>> Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic
>>> RHT Global #: 82-62605
>>>
>>>
>>> _______________________________________________
>>> 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
>>
> 


-- 
David Caro

Red Hat Czech s.r.o.
Continuous Integration Engineer - EMEA ENG Virtualization R&D

Tel.: +420 532 294 605
Email: dcaro at redhat.com
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic
RHT Global #: 82-62605

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

From alonbl at redhat.com  Wed Jul 31 08:06:24 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Wed, 31 Jul 2013 04:06:24 -0400 (EDT)
Subject: What the new gerrit hoks will do
In-Reply-To: <51F8C450.8030205@redhat.com>
References: <51F80DD6.8030405@redhat.com>
	<1783325633.4424023.1375255397075.JavaMail.root@redhat.com>
	<51F8BBC8.8020404@redhat.com> <51F8C450.8030205@redhat.com>
Message-ID: <225582292.4435664.1375257984437.JavaMail.root@redhat.com>



----- Original Message -----
> From: "David Caro" <dcaroest at redhat.com>
> To: "Itamar Heim" <iheim at redhat.com>
> Cc: "Alon Bar-Lev" <alonbl at redhat.com>, arch at ovirt.org
> Sent: Wednesday, July 31, 2013 11:01:20 AM
> Subject: Re: What the new gerrit hoks will do
> 
> On 07/31/2013 09:24 AM, Itamar Heim wrote:
> > On 07/31/2013 10:23 AM, Alon Bar-Lev wrote:
> >>
> >> Hi,
> >>
> >> I don't think it is good to have auto POST/MODIFIED.
> >> As there can be more than one patch per bug.
> > 
> > i think post is still correct.
> > modified will only move if all patches with this bug-url are merged iiuc.
> > a new patch with same bug-url will move the bug back to POST.
> 
> Right, I forgot to clarify that only those bugs with all their external
> tracked patches closed will be changed to MODIFIED.

And if it takes 3 or 4 weeks to post the other patch?

> 
> > 
> >>
> >> Alon
> >>
> >> ----- Original Message -----
> >>> From: "David Caro" <dcaroest at redhat.com>
> >>> To: arch at ovirt.org
> >>> Sent: Tuesday, July 30, 2013 10:02:46 PM
> >>> Subject: What the new gerrit hoks will do
> >>>
> >>> Hi all!
> >>>
> >>> As promised here's an explanation of what the hooks will take care of:
> >>>
> >>> When a patch is submitted:
> >>>    If the commit message has Bug-Url tag:
> >>>      - for each Bug-Url:
> >>>        * Check that the bug is public
> >>>        * Add an external tracker to the patch if not there already
> >>>        * Move the bug status to POST
> >>>      - Report back the result of all the previous actions
> >>>      - Review with +1 if the bug was public, -1 if it was private
> >>>
> >>> When a comment is added:
> >>>    If the "Rerun-Hooks: all" line was added:
> >>>      - Rerun all the hooks that ran when the hook was submitted
> >>>
> >>> When a patch is submitted:
> >>>    If the commit message has Bug-Url:
> >>>      - For each Bug-Url:
> >>>        * Check if the product for the bug is correct
> >>>        * If it was, move the bug status to MODIFIED
> >>>
> >>> Keep in mind that this is a first step towards automation of the whole
> >>> process.
> >>>
> >>> Also, as always any input, ideas, or even complaints are welcome :)
> >>>
> >>> pd. Yes I will add this and more info to the wiki as soon as I have some
> >>> spare time to do it.
> >>>
> >>> --
> >>> David Caro
> >>>
> >>> Red Hat Czech s.r.o.
> >>> Continuous Integration Engineer - EMEA ENG Virtualization R&D
> >>>
> >>> Tel.: +420 532 294 605
> >>> Email: dcaro at redhat.com
> >>> Web: www.cz.redhat.com
> >>> Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic
> >>> RHT Global #: 82-62605
> >>>
> >>>
> >>> _______________________________________________
> >>> 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
> >>
> > 
> 
> 
> --
> David Caro
> 
> Red Hat Czech s.r.o.
> Continuous Integration Engineer - EMEA ENG Virtualization R&D
> 
> Tel.: +420 532 294 605
> Email: dcaro at redhat.com
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic
> RHT Global #: 82-62605
> 
> 


From mlipchuk at redhat.com  Wed Jul 31 08:35:11 2013
From: mlipchuk at redhat.com (Maor Lipchuk)
Date: Wed, 31 Jul 2013 11:35:11 +0300
Subject: What the new gerrit hoks will do
In-Reply-To: <51F8C450.8030205@redhat.com>
References: <51F80DD6.8030405@redhat.com>
	<1783325633.4424023.1375255397075.JavaMail.root@redhat.com>
	<51F8BBC8.8020404@redhat.com> <51F8C450.8030205@redhat.com>
Message-ID: <51F8CC3F.6090707@redhat.com>

Would not having the dependency of gerrit with bugzilla might cause us
latency issues when pushing patches while bugzilla server will encounter
network issues or will be unavailable?

Regards,
Maor

On 07/31/2013 11:01 AM, David Caro wrote:
> On 07/31/2013 09:24 AM, Itamar Heim wrote:
>> On 07/31/2013 10:23 AM, Alon Bar-Lev wrote:
>>>
>>> Hi,
>>>
>>> I don't think it is good to have auto POST/MODIFIED.
>>> As there can be more than one patch per bug.
>>
>> i think post is still correct.
>> modified will only move if all patches with this bug-url are merged iiuc.
>> a new patch with same bug-url will move the bug back to POST.
> 
> Right, I forgot to clarify that only those bugs with all their external
> tracked patches closed will be changed to MODIFIED.
> 
>>
>>>
>>> Alon
>>>
>>> ----- Original Message -----
>>>> From: "David Caro" <dcaroest at redhat.com>
>>>> To: arch at ovirt.org
>>>> Sent: Tuesday, July 30, 2013 10:02:46 PM
>>>> Subject: What the new gerrit hoks will do
>>>>
>>>> Hi all!
>>>>
>>>> As promised here's an explanation of what the hooks will take care of:
>>>>
>>>> When a patch is submitted:
>>>>    If the commit message has Bug-Url tag:
>>>>      - for each Bug-Url:
>>>>        * Check that the bug is public
>>>>        * Add an external tracker to the patch if not there already
>>>>        * Move the bug status to POST
>>>>      - Report back the result of all the previous actions
>>>>      - Review with +1 if the bug was public, -1 if it was private
>>>>
>>>> When a comment is added:
>>>>    If the "Rerun-Hooks: all" line was added:
>>>>      - Rerun all the hooks that ran when the hook was submitted
>>>>
>>>> When a patch is submitted:
>>>>    If the commit message has Bug-Url:
>>>>      - For each Bug-Url:
>>>>        * Check if the product for the bug is correct
>>>>        * If it was, move the bug status to MODIFIED
>>>>
>>>> Keep in mind that this is a first step towards automation of the whole
>>>> process.
>>>>
>>>> Also, as always any input, ideas, or even complaints are welcome :)
>>>>
>>>> pd. Yes I will add this and more info to the wiki as soon as I have some
>>>> spare time to do it.
>>>>
>>>> -- 
>>>> David Caro
>>>>
>>>> Red Hat Czech s.r.o.
>>>> Continuous Integration Engineer - EMEA ENG Virtualization R&D
>>>>
>>>> Tel.: +420 532 294 605
>>>> Email: dcaro at redhat.com
>>>> Web: www.cz.redhat.com
>>>> Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic
>>>> RHT Global #: 82-62605
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>
> 
> 
> 
> 
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 



From abaron at redhat.com  Wed Jul 31 10:05:27 2013
From: abaron at redhat.com (Ayal Baron)
Date: Wed, 31 Jul 2013 06:05:27 -0400 (EDT)
Subject: What the new gerrit hoks will do
In-Reply-To: <225582292.4435664.1375257984437.JavaMail.root@redhat.com>
References: <51F80DD6.8030405@redhat.com>
	<1783325633.4424023.1375255397075.JavaMail.root@redhat.com>
	<51F8BBC8.8020404@redhat.com> <51F8C450.8030205@redhat.com>
	<225582292.4435664.1375257984437.JavaMail.root@redhat.com>
Message-ID: <1720991526.7424433.1375265127302.JavaMail.root@redhat.com>



----- Original Message -----
> 
> 
> ----- Original Message -----
> > From: "David Caro" <dcaroest at redhat.com>
> > To: "Itamar Heim" <iheim at redhat.com>
> > Cc: "Alon Bar-Lev" <alonbl at redhat.com>, arch at ovirt.org
> > Sent: Wednesday, July 31, 2013 11:01:20 AM
> > Subject: Re: What the new gerrit hoks will do
> > 
> > On 07/31/2013 09:24 AM, Itamar Heim wrote:
> > > On 07/31/2013 10:23 AM, Alon Bar-Lev wrote:
> > >>
> > >> Hi,
> > >>
> > >> I don't think it is good to have auto POST/MODIFIED.
> > >> As there can be more than one patch per bug.
> > > 
> > > i think post is still correct.
> > > modified will only move if all patches with this bug-url are merged iiuc.
> > > a new patch with same bug-url will move the bug back to POST.
> > 
> > Right, I forgot to clarify that only those bugs with all their external
> > tracked patches closed will be changed to MODIFIED.
> 
> And if it takes 3 or 4 weeks to post the other patch?

If your patch does not solve the bug entirely then it should not have Bug-url, rather 'Related-To: XXXXXX
And if this patch needs the others to complete the job then it should depend on them (i.e. patch set).
Only the last patch should be marked with bug-url as only after it (and the patches it depends on) are merged the bug is really solved.  The reason is that maintainer would do an even worse job than this script in tracking whether all patches required for solving a bug have been merged. 

> 
> > 
> > > 
> > >>
> > >> Alon
> > >>
> > >> ----- Original Message -----
> > >>> From: "David Caro" <dcaroest at redhat.com>
> > >>> To: arch at ovirt.org
> > >>> Sent: Tuesday, July 30, 2013 10:02:46 PM
> > >>> Subject: What the new gerrit hoks will do
> > >>>
> > >>> Hi all!
> > >>>
> > >>> As promised here's an explanation of what the hooks will take care of:
> > >>>
> > >>> When a patch is submitted:
> > >>>    If the commit message has Bug-Url tag:
> > >>>      - for each Bug-Url:
> > >>>        * Check that the bug is public
> > >>>        * Add an external tracker to the patch if not there already
> > >>>        * Move the bug status to POST
> > >>>      - Report back the result of all the previous actions
> > >>>      - Review with +1 if the bug was public, -1 if it was private
> > >>>
> > >>> When a comment is added:
> > >>>    If the "Rerun-Hooks: all" line was added:
> > >>>      - Rerun all the hooks that ran when the hook was submitted
> > >>>
> > >>> When a patch is submitted:
> > >>>    If the commit message has Bug-Url:
> > >>>      - For each Bug-Url:
> > >>>        * Check if the product for the bug is correct
> > >>>        * If it was, move the bug status to MODIFIED
> > >>>
> > >>> Keep in mind that this is a first step towards automation of the whole
> > >>> process.
> > >>>
> > >>> Also, as always any input, ideas, or even complaints are welcome :)
> > >>>
> > >>> pd. Yes I will add this and more info to the wiki as soon as I have
> > >>> some
> > >>> spare time to do it.
> > >>>
> > >>> --
> > >>> David Caro
> > >>>
> > >>> Red Hat Czech s.r.o.
> > >>> Continuous Integration Engineer - EMEA ENG Virtualization R&D
> > >>>
> > >>> Tel.: +420 532 294 605
> > >>> Email: dcaro at redhat.com
> > >>> Web: www.cz.redhat.com
> > >>> Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic
> > >>> RHT Global #: 82-62605
> > >>>
> > >>>
> > >>> _______________________________________________
> > >>> 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
> > >>
> > > 
> > 
> > 
> > --
> > David Caro
> > 
> > Red Hat Czech s.r.o.
> > Continuous Integration Engineer - EMEA ENG Virtualization R&D
> > 
> > Tel.: +420 532 294 605
> > Email: dcaro at redhat.com
> > Web: www.cz.redhat.com
> > Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic
> > RHT Global #: 82-62605
> > 
> > 
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From alonbl at redhat.com  Wed Jul 31 10:13:12 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Wed, 31 Jul 2013 06:13:12 -0400 (EDT)
Subject: What the new gerrit hoks will do
In-Reply-To: <1720991526.7424433.1375265127302.JavaMail.root@redhat.com>
References: <51F80DD6.8030405@redhat.com>
	<1783325633.4424023.1375255397075.JavaMail.root@redhat.com>
	<51F8BBC8.8020404@redhat.com> <51F8C450.8030205@redhat.com>
	<225582292.4435664.1375257984437.JavaMail.root@redhat.com>
	<1720991526.7424433.1375265127302.JavaMail.root@redhat.com>
Message-ID: <694656940.4467489.1375265592294.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Ayal Baron" <abaron at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "David Caro" <dcaroest at redhat.com>, arch at ovirt.org
> Sent: Wednesday, July 31, 2013 1:05:27 PM
> Subject: Re: What the new gerrit hoks will do
> 
> 
> 
> ----- Original Message -----
> > 
> > 
> > ----- Original Message -----
> > > From: "David Caro" <dcaroest at redhat.com>
> > > To: "Itamar Heim" <iheim at redhat.com>
> > > Cc: "Alon Bar-Lev" <alonbl at redhat.com>, arch at ovirt.org
> > > Sent: Wednesday, July 31, 2013 11:01:20 AM
> > > Subject: Re: What the new gerrit hoks will do
> > > 
> > > On 07/31/2013 09:24 AM, Itamar Heim wrote:
> > > > On 07/31/2013 10:23 AM, Alon Bar-Lev wrote:
> > > >>
> > > >> Hi,
> > > >>
> > > >> I don't think it is good to have auto POST/MODIFIED.
> > > >> As there can be more than one patch per bug.
> > > > 
> > > > i think post is still correct.
> > > > modified will only move if all patches with this bug-url are merged
> > > > iiuc.
> > > > a new patch with same bug-url will move the bug back to POST.
> > > 
> > > Right, I forgot to clarify that only those bugs with all their external
> > > tracked patches closed will be changed to MODIFIED.
> > 
> > And if it takes 3 or 4 weeks to post the other patch?
> 
> If your patch does not solve the bug entirely then it should not have
> Bug-url, rather 'Related-To: XXXXXX
> And if this patch needs the others to complete the job then it should depend
> on them (i.e. patch set).
> Only the last patch should be marked with bug-url as only after it (and the
> patches it depends on) are merged the bug is really solved.  The reason is
> that maintainer would do an even worse job than this script in tracking
> whether all patches required for solving a bug have been merged.

Related-To are other bugs and changes that are related to the actual fixing.
A fix can have many components and can be broken into smaller parts to ease review or even because it is split between deferent repositories.
It also need to pull some other unrelated patches to ease rebasing.
And finally, we are humans, and we do not always know that whatever we are doing is correct and last.

> 
> > 
> > > 
> > > > 
> > > >>
> > > >> Alon
> > > >>
> > > >> ----- Original Message -----
> > > >>> From: "David Caro" <dcaroest at redhat.com>
> > > >>> To: arch at ovirt.org
> > > >>> Sent: Tuesday, July 30, 2013 10:02:46 PM
> > > >>> Subject: What the new gerrit hoks will do
> > > >>>
> > > >>> Hi all!
> > > >>>
> > > >>> As promised here's an explanation of what the hooks will take care
> > > >>> of:
> > > >>>
> > > >>> When a patch is submitted:
> > > >>>    If the commit message has Bug-Url tag:
> > > >>>      - for each Bug-Url:
> > > >>>        * Check that the bug is public
> > > >>>        * Add an external tracker to the patch if not there already
> > > >>>        * Move the bug status to POST
> > > >>>      - Report back the result of all the previous actions
> > > >>>      - Review with +1 if the bug was public, -1 if it was private
> > > >>>
> > > >>> When a comment is added:
> > > >>>    If the "Rerun-Hooks: all" line was added:
> > > >>>      - Rerun all the hooks that ran when the hook was submitted
> > > >>>
> > > >>> When a patch is submitted:
> > > >>>    If the commit message has Bug-Url:
> > > >>>      - For each Bug-Url:
> > > >>>        * Check if the product for the bug is correct
> > > >>>        * If it was, move the bug status to MODIFIED
> > > >>>
> > > >>> Keep in mind that this is a first step towards automation of the
> > > >>> whole
> > > >>> process.
> > > >>>
> > > >>> Also, as always any input, ideas, or even complaints are welcome :)
> > > >>>
> > > >>> pd. Yes I will add this and more info to the wiki as soon as I have
> > > >>> some
> > > >>> spare time to do it.
> > > >>>
> > > >>> --
> > > >>> David Caro
> > > >>>
> > > >>> Red Hat Czech s.r.o.
> > > >>> Continuous Integration Engineer - EMEA ENG Virtualization R&D
> > > >>>
> > > >>> Tel.: +420 532 294 605
> > > >>> Email: dcaro at redhat.com
> > > >>> Web: www.cz.redhat.com
> > > >>> Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic
> > > >>> RHT Global #: 82-62605
> > > >>>
> > > >>>
> > > >>> _______________________________________________
> > > >>> 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
> > > >>
> > > > 
> > > 
> > > 
> > > --
> > > David Caro
> > > 
> > > Red Hat Czech s.r.o.
> > > Continuous Integration Engineer - EMEA ENG Virtualization R&D
> > > 
> > > Tel.: +420 532 294 605
> > > Email: dcaro at redhat.com
> > > Web: www.cz.redhat.com
> > > Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic
> > > RHT Global #: 82-62605
> > > 
> > > 
> > _______________________________________________
> > Arch mailing list
> > Arch at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/arch
> > 
> 


From abaron at redhat.com  Wed Jul 31 10:23:39 2013
From: abaron at redhat.com (Ayal Baron)
Date: Wed, 31 Jul 2013 06:23:39 -0400 (EDT)
Subject: What the new gerrit hoks will do
In-Reply-To: <694656940.4467489.1375265592294.JavaMail.root@redhat.com>
References: <51F80DD6.8030405@redhat.com>
	<1783325633.4424023.1375255397075.JavaMail.root@redhat.com>
	<51F8BBC8.8020404@redhat.com> <51F8C450.8030205@redhat.com>
	<225582292.4435664.1375257984437.JavaMail.root@redhat.com>
	<1720991526.7424433.1375265127302.JavaMail.root@redhat.com>
	<694656940.4467489.1375265592294.JavaMail.root@redhat.com>
Message-ID: <911762059.7433630.1375266219603.JavaMail.root@redhat.com>



----- Original Message -----
> 
> 
> ----- Original Message -----
> > From: "Ayal Baron" <abaron at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: "David Caro" <dcaroest at redhat.com>, arch at ovirt.org
> > Sent: Wednesday, July 31, 2013 1:05:27 PM
> > Subject: Re: What the new gerrit hoks will do
> > 
> > 
> > 
> > ----- Original Message -----
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "David Caro" <dcaroest at redhat.com>
> > > > To: "Itamar Heim" <iheim at redhat.com>
> > > > Cc: "Alon Bar-Lev" <alonbl at redhat.com>, arch at ovirt.org
> > > > Sent: Wednesday, July 31, 2013 11:01:20 AM
> > > > Subject: Re: What the new gerrit hoks will do
> > > > 
> > > > On 07/31/2013 09:24 AM, Itamar Heim wrote:
> > > > > On 07/31/2013 10:23 AM, Alon Bar-Lev wrote:
> > > > >>
> > > > >> Hi,
> > > > >>
> > > > >> I don't think it is good to have auto POST/MODIFIED.
> > > > >> As there can be more than one patch per bug.
> > > > > 
> > > > > i think post is still correct.
> > > > > modified will only move if all patches with this bug-url are merged
> > > > > iiuc.
> > > > > a new patch with same bug-url will move the bug back to POST.
> > > > 
> > > > Right, I forgot to clarify that only those bugs with all their external
> > > > tracked patches closed will be changed to MODIFIED.
> > > 
> > > And if it takes 3 or 4 weeks to post the other patch?
> > 
> > If your patch does not solve the bug entirely then it should not have
> > Bug-url, rather 'Related-To: XXXXXX
> > And if this patch needs the others to complete the job then it should
> > depend
> > on them (i.e. patch set).
> > Only the last patch should be marked with bug-url as only after it (and the
> > patches it depends on) are merged the bug is really solved.  The reason is
> > that maintainer would do an even worse job than this script in tracking
> > whether all patches required for solving a bug have been merged.
> 
> Related-To are other bugs and changes that are related to the actual fixing.

Exactly, if a fix isn't solving the bug entirely but is related to it then it should have 'Related-To'.

> A fix can have many components and can be broken into smaller parts to ease
> review or even because it is split between deferent repositories.
> It also need to pull some other unrelated patches to ease rebasing.
> And finally, we are humans, and we do not always know that whatever we are
> doing is correct and last.

Not sure how all this is related to what I said. There are definitely cases where you want to write multiple patches to solve an issue, that is indeed the use case we are discussing here.
The process is very simple, makes maintainer's life simpler and reduces chances of error, plus allows for automating things:
If you have a bug which you solve in a series of patches then you make a patch set where only the last patch (which is dependent on the rest) is marked with Bug-Url and all the other patches have 'Related-To'.  This way all the confusion and errors that you discussed before disappear.


> 
> > 
> > > 
> > > > 
> > > > > 
> > > > >>
> > > > >> Alon
> > > > >>
> > > > >> ----- Original Message -----
> > > > >>> From: "David Caro" <dcaroest at redhat.com>
> > > > >>> To: arch at ovirt.org
> > > > >>> Sent: Tuesday, July 30, 2013 10:02:46 PM
> > > > >>> Subject: What the new gerrit hoks will do
> > > > >>>
> > > > >>> Hi all!
> > > > >>>
> > > > >>> As promised here's an explanation of what the hooks will take care
> > > > >>> of:
> > > > >>>
> > > > >>> When a patch is submitted:
> > > > >>>    If the commit message has Bug-Url tag:
> > > > >>>      - for each Bug-Url:
> > > > >>>        * Check that the bug is public
> > > > >>>        * Add an external tracker to the patch if not there already
> > > > >>>        * Move the bug status to POST
> > > > >>>      - Report back the result of all the previous actions
> > > > >>>      - Review with +1 if the bug was public, -1 if it was private
> > > > >>>
> > > > >>> When a comment is added:
> > > > >>>    If the "Rerun-Hooks: all" line was added:
> > > > >>>      - Rerun all the hooks that ran when the hook was submitted
> > > > >>>
> > > > >>> When a patch is submitted:
> > > > >>>    If the commit message has Bug-Url:
> > > > >>>      - For each Bug-Url:
> > > > >>>        * Check if the product for the bug is correct
> > > > >>>        * If it was, move the bug status to MODIFIED
> > > > >>>
> > > > >>> Keep in mind that this is a first step towards automation of the
> > > > >>> whole
> > > > >>> process.
> > > > >>>
> > > > >>> Also, as always any input, ideas, or even complaints are welcome :)
> > > > >>>
> > > > >>> pd. Yes I will add this and more info to the wiki as soon as I have
> > > > >>> some
> > > > >>> spare time to do it.
> > > > >>>
> > > > >>> --
> > > > >>> David Caro
> > > > >>>
> > > > >>> Red Hat Czech s.r.o.
> > > > >>> Continuous Integration Engineer - EMEA ENG Virtualization R&D
> > > > >>>
> > > > >>> Tel.: +420 532 294 605
> > > > >>> Email: dcaro at redhat.com
> > > > >>> Web: www.cz.redhat.com
> > > > >>> Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic
> > > > >>> RHT Global #: 82-62605
> > > > >>>
> > > > >>>
> > > > >>> _______________________________________________
> > > > >>> 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
> > > > >>
> > > > > 
> > > > 
> > > > 
> > > > --
> > > > David Caro
> > > > 
> > > > Red Hat Czech s.r.o.
> > > > Continuous Integration Engineer - EMEA ENG Virtualization R&D
> > > > 
> > > > Tel.: +420 532 294 605
> > > > Email: dcaro at redhat.com
> > > > Web: www.cz.redhat.com
> > > > Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic
> > > > RHT Global #: 82-62605
> > > > 
> > > > 
> > > _______________________________________________
> > > Arch mailing list
> > > Arch at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/arch
> > > 
> > 
> 


From alonbl at redhat.com  Wed Jul 31 10:29:14 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Wed, 31 Jul 2013 06:29:14 -0400 (EDT)
Subject: What the new gerrit hoks will do
In-Reply-To: <911762059.7433630.1375266219603.JavaMail.root@redhat.com>
References: <51F80DD6.8030405@redhat.com>
	<1783325633.4424023.1375255397075.JavaMail.root@redhat.com>
	<51F8BBC8.8020404@redhat.com> <51F8C450.8030205@redhat.com>
	<225582292.4435664.1375257984437.JavaMail.root@redhat.com>
	<1720991526.7424433.1375265127302.JavaMail.root@redhat.com>
	<694656940.4467489.1375265592294.JavaMail.root@redhat.com>
	<911762059.7433630.1375266219603.JavaMail.root@redhat.com>
Message-ID: <2144784809.4470403.1375266554484.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Ayal Baron" <abaron at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "David Caro" <dcaroest at redhat.com>, arch at ovirt.org
> Sent: Wednesday, July 31, 2013 1:23:39 PM
> Subject: Re: What the new gerrit hoks will do
> 
> 
> 
> ----- Original Message -----
> > 
> > 
> > ----- Original Message -----
> > > From: "Ayal Baron" <abaron at redhat.com>
> > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > Cc: "David Caro" <dcaroest at redhat.com>, arch at ovirt.org
> > > Sent: Wednesday, July 31, 2013 1:05:27 PM
> > > Subject: Re: What the new gerrit hoks will do
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "David Caro" <dcaroest at redhat.com>
> > > > > To: "Itamar Heim" <iheim at redhat.com>
> > > > > Cc: "Alon Bar-Lev" <alonbl at redhat.com>, arch at ovirt.org
> > > > > Sent: Wednesday, July 31, 2013 11:01:20 AM
> > > > > Subject: Re: What the new gerrit hoks will do
> > > > > 
> > > > > On 07/31/2013 09:24 AM, Itamar Heim wrote:
> > > > > > On 07/31/2013 10:23 AM, Alon Bar-Lev wrote:
> > > > > >>
> > > > > >> Hi,
> > > > > >>
> > > > > >> I don't think it is good to have auto POST/MODIFIED.
> > > > > >> As there can be more than one patch per bug.
> > > > > > 
> > > > > > i think post is still correct.
> > > > > > modified will only move if all patches with this bug-url are merged
> > > > > > iiuc.
> > > > > > a new patch with same bug-url will move the bug back to POST.
> > > > > 
> > > > > Right, I forgot to clarify that only those bugs with all their
> > > > > external
> > > > > tracked patches closed will be changed to MODIFIED.
> > > > 
> > > > And if it takes 3 or 4 weeks to post the other patch?
> > > 
> > > If your patch does not solve the bug entirely then it should not have
> > > Bug-url, rather 'Related-To: XXXXXX
> > > And if this patch needs the others to complete the job then it should
> > > depend
> > > on them (i.e. patch set).
> > > Only the last patch should be marked with bug-url as only after it (and
> > > the
> > > patches it depends on) are merged the bug is really solved.  The reason
> > > is
> > > that maintainer would do an even worse job than this script in tracking
> > > whether all patches required for solving a bug have been merged.
> > 
> > Related-To are other bugs and changes that are related to the actual
> > fixing.
> 
> Exactly, if a fix isn't solving the bug entirely but is related to it then it
> should have 'Related-To'.
> 
> > A fix can have many components and can be broken into smaller parts to ease
> > review or even because it is split between deferent repositories.
> > It also need to pull some other unrelated patches to ease rebasing.
> > And finally, we are humans, and we do not always know that whatever we are
> > doing is correct and last.
> 
> Not sure how all this is related to what I said. There are definitely cases
> where you want to write multiple patches to solve an issue, that is indeed
> the use case we are discussing here.
> The process is very simple, makes maintainer's life simpler and reduces
> chances of error, plus allows for automating things:
> If you have a bug which you solve in a series of patches then you make a
> patch set where only the last patch (which is dependent on the rest) is
> marked with Bug-Url and all the other patches have 'Related-To'.  This way
> all the confusion and errors that you discussed before disappear.

I disagree but I will stop here.

Just to fix, once again, a misconception that is spread around this project.

    "makes maintainer's" - maintainer != anyone who fix bugs nor whoever has commit access.


> 
> 
> > 
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > >>
> > > > > >> Alon
> > > > > >>
> > > > > >> ----- Original Message -----
> > > > > >>> From: "David Caro" <dcaroest at redhat.com>
> > > > > >>> To: arch at ovirt.org
> > > > > >>> Sent: Tuesday, July 30, 2013 10:02:46 PM
> > > > > >>> Subject: What the new gerrit hoks will do
> > > > > >>>
> > > > > >>> Hi all!
> > > > > >>>
> > > > > >>> As promised here's an explanation of what the hooks will take
> > > > > >>> care
> > > > > >>> of:
> > > > > >>>
> > > > > >>> When a patch is submitted:
> > > > > >>>    If the commit message has Bug-Url tag:
> > > > > >>>      - for each Bug-Url:
> > > > > >>>        * Check that the bug is public
> > > > > >>>        * Add an external tracker to the patch if not there
> > > > > >>>        already
> > > > > >>>        * Move the bug status to POST
> > > > > >>>      - Report back the result of all the previous actions
> > > > > >>>      - Review with +1 if the bug was public, -1 if it was private
> > > > > >>>
> > > > > >>> When a comment is added:
> > > > > >>>    If the "Rerun-Hooks: all" line was added:
> > > > > >>>      - Rerun all the hooks that ran when the hook was submitted
> > > > > >>>
> > > > > >>> When a patch is submitted:
> > > > > >>>    If the commit message has Bug-Url:
> > > > > >>>      - For each Bug-Url:
> > > > > >>>        * Check if the product for the bug is correct
> > > > > >>>        * If it was, move the bug status to MODIFIED
> > > > > >>>
> > > > > >>> Keep in mind that this is a first step towards automation of the
> > > > > >>> whole
> > > > > >>> process.
> > > > > >>>
> > > > > >>> Also, as always any input, ideas, or even complaints are welcome
> > > > > >>> :)
> > > > > >>>
> > > > > >>> pd. Yes I will add this and more info to the wiki as soon as I
> > > > > >>> have
> > > > > >>> some
> > > > > >>> spare time to do it.
> > > > > >>>
> > > > > >>> --
> > > > > >>> David Caro
> > > > > >>>
> > > > > >>> Red Hat Czech s.r.o.
> > > > > >>> Continuous Integration Engineer - EMEA ENG Virtualization R&D
> > > > > >>>
> > > > > >>> Tel.: +420 532 294 605
> > > > > >>> Email: dcaro at redhat.com
> > > > > >>> Web: www.cz.redhat.com
> > > > > >>> Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech
> > > > > >>> Republic
> > > > > >>> RHT Global #: 82-62605
> > > > > >>>
> > > > > >>>
> > > > > >>> _______________________________________________
> > > > > >>> 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
> > > > > >>
> > > > > > 
> > > > > 
> > > > > 
> > > > > --
> > > > > David Caro
> > > > > 
> > > > > Red Hat Czech s.r.o.
> > > > > Continuous Integration Engineer - EMEA ENG Virtualization R&D
> > > > > 
> > > > > Tel.: +420 532 294 605
> > > > > Email: dcaro at redhat.com
> > > > > Web: www.cz.redhat.com
> > > > > Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic
> > > > > RHT Global #: 82-62605
> > > > > 
> > > > > 
> > > > _______________________________________________
> > > > Arch mailing list
> > > > Arch at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/arch
> > > > 
> > > 
> > 
> 


From iheim at redhat.com  Wed Jul 31 11:22:54 2013
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 31 Jul 2013 14:22:54 +0300
Subject: What the new gerrit hoks will do
In-Reply-To: <1239768242.4425906.1375256054395.JavaMail.root@redhat.com>
References: <51F80DD6.8030405@redhat.com>
	<1783325633.4424023.1375255397075.JavaMail.root@redhat.com>
	<51F8BBC8.8020404@redhat.com>
	<1239768242.4425906.1375256054395.JavaMail.root@redhat.com>
Message-ID: <51F8F38E.7040609@redhat.com>

On 07/31/2013 10:34 AM, Alon Bar-Lev wrote:
> And the robot will move this to ONQA if there is a gap and there is a build.
> Too much automation is also bad.

there is no bot moving ovirt bugs to ON_QA.
we do this manually when building the RC build today.


From alonbl at redhat.com  Wed Jul 31 11:27:53 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Wed, 31 Jul 2013 07:27:53 -0400 (EDT)
Subject: What the new gerrit hoks will do
In-Reply-To: <51F8F38E.7040609@redhat.com>
References: <51F80DD6.8030405@redhat.com>
	<1783325633.4424023.1375255397075.JavaMail.root@redhat.com>
	<51F8BBC8.8020404@redhat.com>
	<1239768242.4425906.1375256054395.JavaMail.root@redhat.com>
	<51F8F38E.7040609@redhat.com>
Message-ID: <1536070005.4483459.1375270073680.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "David Caro" <dcaroest at redhat.com>, arch at ovirt.org
> Sent: Wednesday, July 31, 2013 2:22:54 PM
> Subject: Re: What the new gerrit hoks will do
> 
> On 07/31/2013 10:34 AM, Alon Bar-Lev wrote:
> > And the robot will move this to ONQA if there is a gap and there is a
> > build.
> > Too much automation is also bad.
> 
> there is no bot moving ovirt bugs to ON_QA.
> we do this manually when building the RC build today.
> 

Based on what information? If based on bugzilla status it is not important if it is a bot or human.
I got bugs moved to ON_QA by <something> automatically already.

Alon


From dcaroest at redhat.com  Wed Jul 31 11:57:25 2013
From: dcaroest at redhat.com (David Caro)
Date: Wed, 31 Jul 2013 13:57:25 +0200
Subject: What the new gerrit hoks will do
In-Reply-To: <51F8CC3F.6090707@redhat.com>
References: <51F80DD6.8030405@redhat.com>
	<1783325633.4424023.1375255397075.JavaMail.root@redhat.com>
	<51F8BBC8.8020404@redhat.com> <51F8C450.8030205@redhat.com>
	<51F8CC3F.6090707@redhat.com>
Message-ID: <51F8FBA5.60802@redhat.com>

On 07/31/2013 10:35 AM, Maor Lipchuk wrote:
> Would not having the dependency of gerrit with bugzilla might cause us
> latency issues when pushing patches while bugzilla server will encounter
> network issues or will be unavailable?

No, as the hooks are execute post-action. They are also executed in
another thread so the user does not experience any change in gerrit's
behavior, any action that you do on gerrit will take the same amount of
time it did before, .

It can become a problem if there are lots of slow hooks and lots of
commits, but that will only slow down the machine, and right now we have
a huge margin of operation in that aspect.

> 
> Regards,
> Maor
> 
> On 07/31/2013 11:01 AM, David Caro wrote:
>> On 07/31/2013 09:24 AM, Itamar Heim wrote:
>>> On 07/31/2013 10:23 AM, Alon Bar-Lev wrote:
>>>>
>>>> Hi,
>>>>
>>>> I don't think it is good to have auto POST/MODIFIED.
>>>> As there can be more than one patch per bug.
>>>
>>> i think post is still correct.
>>> modified will only move if all patches with this bug-url are merged iiuc.
>>> a new patch with same bug-url will move the bug back to POST.
>>
>> Right, I forgot to clarify that only those bugs with all their external
>> tracked patches closed will be changed to MODIFIED.
>>
>>>
>>>>
>>>> Alon
>>>>
>>>> ----- Original Message -----
>>>>> From: "David Caro" <dcaroest at redhat.com>
>>>>> To: arch at ovirt.org
>>>>> Sent: Tuesday, July 30, 2013 10:02:46 PM
>>>>> Subject: What the new gerrit hoks will do
>>>>>
>>>>> Hi all!
>>>>>
>>>>> As promised here's an explanation of what the hooks will take care of:
>>>>>
>>>>> When a patch is submitted:
>>>>>    If the commit message has Bug-Url tag:
>>>>>      - for each Bug-Url:
>>>>>        * Check that the bug is public
>>>>>        * Add an external tracker to the patch if not there already
>>>>>        * Move the bug status to POST
>>>>>      - Report back the result of all the previous actions
>>>>>      - Review with +1 if the bug was public, -1 if it was private
>>>>>
>>>>> When a comment is added:
>>>>>    If the "Rerun-Hooks: all" line was added:
>>>>>      - Rerun all the hooks that ran when the hook was submitted
>>>>>
>>>>> When a patch is submitted:
>>>>>    If the commit message has Bug-Url:
>>>>>      - For each Bug-Url:
>>>>>        * Check if the product for the bug is correct
>>>>>        * If it was, move the bug status to MODIFIED
>>>>>
>>>>> Keep in mind that this is a first step towards automation of the whole
>>>>> process.
>>>>>
>>>>> Also, as always any input, ideas, or even complaints are welcome :)
>>>>>
>>>>> pd. Yes I will add this and more info to the wiki as soon as I have some
>>>>> spare time to do it.
>>>>>
>>>>> -- 
>>>>> David Caro
>>>>>
>>>>> Red Hat Czech s.r.o.
>>>>> Continuous Integration Engineer - EMEA ENG Virtualization R&D
>>>>>
>>>>> Tel.: +420 532 294 605
>>>>> Email: dcaro at redhat.com
>>>>> Web: www.cz.redhat.com
>>>>> Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic
>>>>> RHT Global #: 82-62605
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>
>>
>>
>>
>>
>> _______________________________________________
>> Arch mailing list
>> Arch at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/arch
>>
> 


-- 
David Caro

Red Hat Czech s.r.o.
Continuous Integration Engineer - EMEA ENG Virtualization R&D

Tel.: +420 532 294 605
Email: dcaro at redhat.com
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic
RHT Global #: 82-62605

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