From lvernia at redhat.com  Mon Dec  2 08:04:38 2013
From: lvernia at redhat.com (Lior Vernia)
Date: Mon, 2 Dec 2013 03:04:38 -0500 (EST)
Subject: oVirt 3.4 network features review
Message-ID: <1164790775.10365851.1385971478067.JavaMail.root@redhat.com>

The following meeting has been modified:

Subject: oVirt 3.4 network features review 
Organiser: "Lior Vernia" <lvernia at redhat.com> 

Location: "Pangaea-tlv" <pangaea-tlv at redhat.com> 
Resources: "Pangaea-tlv" <pangaea-tlv at redhat.com> (Pangaea-tlv) 
Time: Tuesday, 3 December, 2013, 3:00:00 PM - 4:00:00 PM GMT +02:00 Jerusalem [MODIFIED]
 
Invitees: users at ovirt.org; arch at ovirt.org; asegurap at redhat.com; mvanhorssen at vluchtelingenwerk.nl; sbonazzo at redhat.com; gcheresh at redhat.com; jorick at netbulae.eu; mkolesni at redhat.com; sgordon at redhat.com; emesika at redhat.com; otavio.ferranti at eldorado.org.br ... 


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

In this talk I intend to present a short overview of the network features for oVirt 3.4 (several minutes per feature + Q&A). 

Conference call details will follow, and possibly a link to an Elluminate session. 

Link to oVirt 3.4 planning spreadsheet (links to feature pages): 
https://docs.google.com/spreadsheet/ccc?key=0AuAtmJW_VMCRdHJ6N1M3d1F1UTJTS1dSMnZwMF9XWVE&usp=drive_web#gid=0 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: meeting.ics
Type: text/calendar
Size: 3643 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20131202/c9ec9ea3/attachment.ics>

From lvernia at redhat.com  Mon Dec  2 11:57:57 2013
From: lvernia at redhat.com (Lior Vernia)
Date: Mon, 2 Dec 2013 06:57:57 -0500 (EST)
Subject: oVirt 3.4 network features review
Message-ID: <36315103.10501263.1385985476917.JavaMail.root@redhat.com>

The following meeting has been modified:

Subject: oVirt 3.4 network features review 
Organiser: "Lior Vernia" <lvernia at redhat.com> 

Location:  [MODIFIED]
Time: Tuesday, 3 December, 2013, 3:00:00 PM - 4:00:00 PM GMT +02:00 Jerusalem
 
Invitees: users at ovirt.org; arch at ovirt.org; asegurap at redhat.com; mvanhorssen at vluchtelingenwerk.nl; sbonazzo at redhat.com; gcheresh at redhat.com; jorick at netbulae.eu; mkolesni at redhat.com; sgordon at redhat.com; emesika at redhat.com; otavio.ferranti at eldorado.org.br ... 


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

In this talk I intend to present a short overview of the network features for oVirt 3.4 (several minutes per feature + Q&A). 

Conference call bridge (audio only): 
Country-specific toll-free phone numbers: https://www.intercallonline.com/listNumbersByCode.action?confCode=972506565679 
Bridge ID: 972506565679 

Link to Elluminate session (screen sharing): 
https://sas.elluminate.com/m.jnlp?sid=819&password=M.DD596C1A50ED59505244EE0905F364

Link to oVirt 3.4 planning spreadsheet (links to feature pages): 
https://docs.google.com/spreadsheet/ccc?key=0AuAtmJW_VMCRdHJ6N1M3d1F1UTJTS1dSMnZwMF9XWVE&usp=drive_web#gid=0 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: meeting.ics
Type: text/calendar
Size: 3864 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20131202/de7fa455/attachment.ics>

From sbonazzo at redhat.com  Tue Dec  3 07:09:04 2013
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Tue, 03 Dec 2013 08:09:04 +0100
Subject: oVirt 3.3.2 Beta now available
Message-ID: <529D8390.30200@redhat.com>

The oVirt team is pleased to announce that the 3.3.2 Release is now available in beta.

Release notes and information on the changes for this update are still being worked on and will be available soon on the wiki[1].

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

You're welcome to join us testing [2] this beta release.


[1] http://www.ovirt.org/OVirt_3.3.2_release_notes
[2] http://www.ovirt.org/Testing/Ovirt_3.3.2_testing


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


From masayag at redhat.com  Sun Dec  8 13:22:50 2013
From: masayag at redhat.com (Moti Asayag)
Date: Sun, 8 Dec 2013 08:22:50 -0500 (EST)
Subject: Networks label feature
In-Reply-To: <158158271.1625292.1386508890782.JavaMail.root@redhat.com>
Message-ID: <1257093362.1625319.1386508970320.JavaMail.root@redhat.com>

Hi All,

Another network feature planned for ovirt-engine-3.4 is
the network labels [1].

Please review and share your feedbacks.

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

Thanks,
Moti


From lpeer at redhat.com  Sun Dec  8 14:06:17 2013
From: lpeer at redhat.com (Livnat Peer)
Date: Sun, 08 Dec 2013 16:06:17 +0200
Subject: Networks label feature
In-Reply-To: <1257093362.1625319.1386508970320.JavaMail.root@redhat.com>
References: <1257093362.1625319.1386508970320.JavaMail.root@redhat.com>
Message-ID: <52A47CD9.9010807@redhat.com>

On 12/08/2013 03:22 PM, Moti Asayag wrote:
> Hi All,
> 
> Another network feature planned for ovirt-engine-3.4 is
> the network labels [1].
> 
> Please review and share your feedbacks.
> 
> [1] http://www.ovirt.org/Features/NetworkLabels
> 
> Thanks,
> Moti

Hi Moti,

Thanks for writing a detailed feature page, good work.

I have a few questions -

1. What does it mean to rename a network label. How does it work with
the fact that label is not a managed entity.
"Renaming a network label" - It seems from the document that you meant
edit network label (instead of rename), and why do we want to add that
unpredictable action in the first phase? I would start without this option.

2. on the 'More examples' section you give an example with two labels on
a single network while at the beginning of the page you specified that
only one label is supported on a network.

3. Do you plan to have the 'Apply to all hosts' check box? in the add
label section is says -"no further indication is required " and then on
the delete label it says - "The property 'Apply to all hosts' will be
reused"

4. Why does the delete label action is not symmetric with add label?
specifically why "Deleting the label from the host interface will not
cause the removal of the networks.."?

5."Pre-'Setup Networks' execution"
It looks to me that we are playing catch 22 with the user there :)
If the user manually removed the network, although he labeled the NIC
then he does not expect the engine to add it again automatically on next
setup network.
I understand the need for exceptions but in this case I would start with
implementing this feature as simple as possible (it is already
complicated enough). So my suggestion is do not let the user remove the
network manually, if he want s to manage this NIC as an exception then
he needs to remove the label.

In this specific case I think it would make the behavior more
predictable to the user which is crucial (at least for the first phase)
for such a complicated feature IMO.


6. How does the system reflect failures? If we added a label to a new
network and we failed to provisioned it on the host, how will the user
know about this? Can you please this to the feature page.


7. After reading this page I wonder why not use the existing object Tag
that we have for labeling the networks and NICs?

Livnat


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



From masayag at redhat.com  Sun Dec  8 16:32:14 2013
From: masayag at redhat.com (Moti Asayag)
Date: Sun, 8 Dec 2013 11:32:14 -0500 (EST)
Subject: Networks label feature
In-Reply-To: <52A47CD9.9010807@redhat.com>
References: <1257093362.1625319.1386508970320.JavaMail.root@redhat.com>
	<52A47CD9.9010807@redhat.com>
Message-ID: <1178971434.1652590.1386520334701.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Livnat Peer" <lpeer at redhat.com>
> To: "Moti Asayag" <masayag at redhat.com>, "arch" <arch at ovirt.org>
> Sent: Sunday, December 8, 2013 4:06:17 PM
> Subject: Re: Networks label feature
> 
> On 12/08/2013 03:22 PM, Moti Asayag wrote:
> > Hi All,
> > 
> > Another network feature planned for ovirt-engine-3.4 is
> > the network labels [1].
> > 
> > Please review and share your feedbacks.
> > 
> > [1] http://www.ovirt.org/Features/NetworkLabels
> > 
> > Thanks,
> > Moti
> 
> Hi Moti,
> 
> Thanks for writing a detailed feature page, good work.
> 
> I have a few questions -
> 
> 1. What does it mean to rename a network label. How does it work with
> the fact that label is not a managed entity.
> "Renaming a network label" - It seems from the document that you meant
> edit network label (instead of rename), and why do we want to add that
> unpredictable action in the first phase? I would start without this option.
> 


The network labels related actions will be executed either from the add/edit
network dialog by editing the 'label' property, or by editing the label of
'interface/bond' on the 'setup networks' dialog. Since the label designed to
be a plan text property on the network, renaming it means changing its value
to other. Removing a label stands for clearing this field.

The notation of label actions meant to clarify what are the result of each
action.

Without this option we won't allow the admin to change a label once it is created.
That seems like a harsh limitation. What if the user wishes to manage a specific 
network by other label that the network was originally added with ? 

And it goes for the host direction as well: changing the label of the host nic 
indicates the user wishes to manage the networks attached to that nic by other
label. That seems like a reasonable use case to me.

> 2. on the 'More examples' section you give an example with two labels on
> a single network while at the beginning of the page you specified that
> only one label is supported on a network.
> 

This is a leftover from a wider solution. we'll start with a design for
a single label per network and we'll see how it will evolves from there.

> 3. Do you plan to have the 'Apply to all hosts' check box? in the add
> label section is says -"no further indication is required " and then on
> the delete label it says - "The property 'Apply to all hosts' will be
> reused"
> 

In 'Add network' dialog there will be no 'Apply to all hosts' checkbox.
This operation by itself cannot cause the network to be added to hosts 
without assigning the network to the clusters (even if the hosts' nics are labelled).

The 'delete labels' is basically using the 'Edit network' command for
clearing this field. Therefore i suggest to make the already existing
'Apply to all hosts' property to indicates the network should be removed from 
all the labelled hosts, the alternative is not to remove a network
from hosts if the label was cleared from the network.

> 4. Why does the delete label action is not symmetric with add label?
> specifically why "Deleting the label from the host interface will not
> cause the removal of the networks.."?
> 

As stated in previous section - this is an alternative. Fine by me:
Removing a label from network/host nic won't trigger its removal from
the hosts. 

> 5."Pre-'Setup Networks' execution"
> It looks to me that we are playing catch 22 with the user there :)
> If the user manually removed the network, although he labeled the NIC
> then he does not expect the engine to add it again automatically on next
> setup network.
> I understand the need for exceptions but in this case I would start with
> implementing this feature as simple as possible (it is already
> complicated enough). So my suggestion is do not let the user remove the
> network manually, if he want s to manage this NIC as an exception then
> he needs to remove the label.
> 
> In this specific case I think it would make the behavior more
> predictable to the user which is crucial (at least for the first phase)
> for such a complicated feature IMO.
>

As I see it, if the user provided label for the host nic (especially via the api), 
all the eligible networks labelled should be added to that nic.
Therefore if the label wasn't removed, we should preserve the label definition on
that host. Therefore limiting the removal seems a reasonable restriction.

> 
> 6. How does the system reflect failures? If we added a label to a new
> network and we failed to provisioned it on the host, how will the user
> know about this? Can you please this to the feature page.
> 

I'll add the 'events' section to the feature page. Basically, we should separate
between the Add/Update network command to their extension behind the scenes by
the labels or the 'apply to all hosts' option. So the correct place in the 
system to file those events will be in the event log, same as does for the
'Edit provisioned networks' feature.

> 
> 7. After reading this page I wonder why not use the existing object Tag
> that we have for labeling the networks and NICs?
> 

The 'Tag' entity in the system is a hierarchical managed object, designed to
tag mainly main entities in the system AFAICT. While the tags might work
for network (after adding respectively the support of it, as there are no 'generic'
tags), using the tags will raise further complexities for the host nics: 
In this case will require fetching a list of tags from the tag table for each nic.
I would rather avoid using the tags, while all needed is a simple property.

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


From lpeer at redhat.com  Mon Dec  9 07:57:27 2013
From: lpeer at redhat.com (Livnat Peer)
Date: Mon, 09 Dec 2013 09:57:27 +0200
Subject: Networks label feature
In-Reply-To: <1178971434.1652590.1386520334701.JavaMail.root@redhat.com>
References: <1257093362.1625319.1386508970320.JavaMail.root@redhat.com>
	<52A47CD9.9010807@redhat.com>
	<1178971434.1652590.1386520334701.JavaMail.root@redhat.com>
Message-ID: <52A577E7.4040705@redhat.com>

On 12/08/2013 06:32 PM, Moti Asayag wrote:
> 
> 
> ----- Original Message -----
>> From: "Livnat Peer" <lpeer at redhat.com>
>> To: "Moti Asayag" <masayag at redhat.com>, "arch" <arch at ovirt.org>
>> Sent: Sunday, December 8, 2013 4:06:17 PM
>> Subject: Re: Networks label feature
>>
>> On 12/08/2013 03:22 PM, Moti Asayag wrote:
>>> Hi All,
>>>
>>> Another network feature planned for ovirt-engine-3.4 is
>>> the network labels [1].
>>>
>>> Please review and share your feedbacks.
>>>
>>> [1] http://www.ovirt.org/Features/NetworkLabels
>>>
>>> Thanks,
>>> Moti
>>
>> Hi Moti,
>>
>> Thanks for writing a detailed feature page, good work.
>>
>> I have a few questions -
>>
>> 1. What does it mean to rename a network label. How does it work with
>> the fact that label is not a managed entity.
>> "Renaming a network label" - It seems from the document that you meant
>> edit network label (instead of rename), and why do we want to add that
>> unpredictable action in the first phase? I would start without this option.
>>
> 
> 
> The network labels related actions will be executed either from the add/edit
> network dialog by editing the 'label' property, or by editing the label of
> 'interface/bond' on the 'setup networks' dialog. Since the label designed to
> be a plan text property on the network, renaming it means changing its value
> to other. Removing a label stands for clearing this field.
> 

So I guess it all about terminology, I think that since we are not
managing labels as entities we can't rename them, what we do is edit the
label on the network, changing one label to another.

> The notation of label actions meant to clarify what are the result of each
> action.
> 
> Without this option we won't allow the admin to change a label once it is created.

I think the user should be able to change the network label of course,
but that would translate to remove and add label from the implementation
perspective.

Which means you'll have to remove the network from all NICs with the
original label and add the network to all the NICs with the new label,
hopefully it would be done using a single setupNetwork operation per host.

> That seems like a harsh limitation. What if the user wishes to manage a specific 
> network by other label that the network was originally added with ? 
> 
> And it goes for the host direction as well: changing the label of the host nic 
> indicates the user wishes to manage the networks attached to that nic by other
> label. That seems like a reasonable use case to me.
> 
>> 2. on the 'More examples' section you give an example with two labels on
>> a single network while at the beginning of the page you specified that
>> only one label is supported on a network.
>>
> 
> This is a leftover from a wider solution. we'll start with a design for
> a single label per network and we'll see how it will evolves from there.
> 
>> 3. Do you plan to have the 'Apply to all hosts' check box? in the add
>> label section is says -"no further indication is required " and then on
>> the delete label it says - "The property 'Apply to all hosts' will be
>> reused"
>>
> 
> In 'Add network' dialog there will be no 'Apply to all hosts' checkbox.
> This operation by itself cannot cause the network to be added to hosts 
> without assigning the network to the clusters (even if the hosts' nics are labelled).
> 

The point is about add label, not about add network :)

> The 'delete labels' is basically using the 'Edit network' command for
> clearing this field. Therefore i suggest to make the already existing
> 'Apply to all hosts' property to indicates the network should be removed from 
> all the labelled hosts, the alternative is not to remove a network
> from hosts if the label was cleared from the network.
> 

I think this checkbox is redundant in delete, same as you suggested,
rightfully, in add.

>> 4. Why does the delete label action is not symmetric with add label?
>> specifically why "Deleting the label from the host interface will not
>> cause the removal of the networks.."?
>>
> 
> As stated in previous section - this is an alternative. Fine by me:
> Removing a label from network/host nic won't trigger its removal from
> the hosts. 
> 

I think that removing a label from the host and from the network should
effect the setup configuration - for consistency and for predictability.

removing a label from a NIC would remove the networks associated with
that label from the NIC
removing a label from the network would remove the network from all NICS
that have this label.


>> 5."Pre-'Setup Networks' execution"
>> It looks to me that we are playing catch 22 with the user there :)
>> If the user manually removed the network, although he labeled the NIC
>> then he does not expect the engine to add it again automatically on next
>> setup network.
>> I understand the need for exceptions but in this case I would start with
>> implementing this feature as simple as possible (it is already
>> complicated enough). So my suggestion is do not let the user remove the
>> network manually, if he want s to manage this NIC as an exception then
>> he needs to remove the label.
>>
>> In this specific case I think it would make the behavior more
>> predictable to the user which is crucial (at least for the first phase)
>> for such a complicated feature IMO.
>>
> 
> As I see it, if the user provided label for the host nic (especially via the api), 
> all the eligible networks labelled should be added to that nic.
> Therefore if the label wasn't removed, we should preserve the label definition on
> that host. Therefore limiting the removal seems a reasonable restriction.
> 

Great

>>
>> 6. How does the system reflect failures? If we added a label to a new
>> network and we failed to provisioned it on the host, how will the user
>> know about this? Can you please this to the feature page.
>>
> 
> I'll add the 'events' section to the feature page. Basically, we should separate
> between the Add/Update network command to their extension behind the scenes by
> the labels or the 'apply to all hosts' option. So the correct place in the 
> system to file those events will be in the event log, same as does for the
> 'Edit provisioned networks' feature.
> 

The audit log are good for the action itself but I guess my question is
would the setup network dialog reflect that the labels and the networks
are not in sync?

>>
>> 7. After reading this page I wonder why not use the existing object Tag
>> that we have for labeling the networks and NICs?
>>
> 
> The 'Tag' entity in the system is a hierarchical managed object, designed to
> tag mainly main entities in the system AFAICT. While the tags might work
> for network (after adding respectively the support of it, as there are no 'generic'
> tags), using the tags will raise further complexities for the host nics: 
> In this case will require fetching a list of tags from the tag table for each nic.
> I would rather avoid using the tags, while all needed is a simple property.
> 

ack
I agree that the fact the host NICs are not managed entities could make
using TAGs not a good idea.



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



From danken at redhat.com  Mon Dec  9 09:28:54 2013
From: danken at redhat.com (Dan Kenigsberg)
Date: Mon, 9 Dec 2013 09:28:54 +0000
Subject: Networks label feature
In-Reply-To: <52A577E7.4040705@redhat.com>
References: <1257093362.1625319.1386508970320.JavaMail.root@redhat.com>
	<52A47CD9.9010807@redhat.com>
	<1178971434.1652590.1386520334701.JavaMail.root@redhat.com>
	<52A577E7.4040705@redhat.com>
Message-ID: <20131209092854.GC19191@redhat.com>

On Mon, Dec 09, 2013 at 09:57:27AM +0200, Livnat Peer wrote:
> On 12/08/2013 06:32 PM, Moti Asayag wrote:
> > 
> > 
> > ----- Original Message -----
> >> From: "Livnat Peer" <lpeer at redhat.com>
> >> To: "Moti Asayag" <masayag at redhat.com>, "arch" <arch at ovirt.org>
> >> Sent: Sunday, December 8, 2013 4:06:17 PM
> >> Subject: Re: Networks label feature
> >>
> >> On 12/08/2013 03:22 PM, Moti Asayag wrote:
> >>> Hi All,
> >>>
> >>> Another network feature planned for ovirt-engine-3.4 is
> >>> the network labels [1].
> >>>
> >>> Please review and share your feedbacks.
> >>>
> >>> [1] http://www.ovirt.org/Features/NetworkLabels
> >>>
> >>> Thanks,
> >>> Moti
> >>
> >> Hi Moti,
> >>
> >> Thanks for writing a detailed feature page, good work.
> >>
> >> I have a few questions -
> >>
> >> 1. What does it mean to rename a network label. How does it work with
> >> the fact that label is not a managed entity.
> >> "Renaming a network label" - It seems from the document that you meant
> >> edit network label (instead of rename), and why do we want to add that
> >> unpredictable action in the first phase? I would start without this option.
> >>
> > 
> > 
> > The network labels related actions will be executed either from the add/edit
> > network dialog by editing the 'label' property, or by editing the label of
> > 'interface/bond' on the 'setup networks' dialog. Since the label designed to
> > be a plan text property on the network, renaming it means changing its value
> > to other. Removing a label stands for clearing this field.
> > 
> 
> So I guess it all about terminology, I think that since we are not
> managing labels as entities we can't rename them, what we do is edit the
> label on the network, changing one label to another.

I understand the added complexity of managing a Label as an entity, but
do we have an experience with a user-editable foreign key like this?

My concern is that an American defines a GRAY label, attaches it to host
nics, while an English starts to use GREY on another set of hosts.
Understanding why a network is deployed only to some of the hosts may be
hard, and fixing the spelling on multiple dialogs is going to be
frustrating.


From masayag at redhat.com  Mon Dec  9 12:44:55 2013
From: masayag at redhat.com (Moti Asayag)
Date: Mon, 9 Dec 2013 07:44:55 -0500 (EST)
Subject: Networks label feature
In-Reply-To: <20131209092854.GC19191@redhat.com>
References: <1257093362.1625319.1386508970320.JavaMail.root@redhat.com>
	<52A47CD9.9010807@redhat.com>
	<1178971434.1652590.1386520334701.JavaMail.root@redhat.com>
	<52A577E7.4040705@redhat.com> <20131209092854.GC19191@redhat.com>
Message-ID: <1180196403.1930340.1386593095669.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Dan Kenigsberg" <danken at redhat.com>
> To: "Livnat Peer" <lpeer at redhat.com>
> Cc: "Moti Asayag" <masayag at redhat.com>, "arch" <arch at ovirt.org>
> Sent: Monday, December 9, 2013 11:28:54 AM
> Subject: Re: Networks label feature
> 
> On Mon, Dec 09, 2013 at 09:57:27AM +0200, Livnat Peer wrote:
> > On 12/08/2013 06:32 PM, Moti Asayag wrote:
> > > 
> > > 
> > > ----- Original Message -----
> > >> From: "Livnat Peer" <lpeer at redhat.com>
> > >> To: "Moti Asayag" <masayag at redhat.com>, "arch" <arch at ovirt.org>
> > >> Sent: Sunday, December 8, 2013 4:06:17 PM
> > >> Subject: Re: Networks label feature
> > >>
> > >> On 12/08/2013 03:22 PM, Moti Asayag wrote:
> > >>> Hi All,
> > >>>
> > >>> Another network feature planned for ovirt-engine-3.4 is
> > >>> the network labels [1].
> > >>>
> > >>> Please review and share your feedbacks.
> > >>>
> > >>> [1] http://www.ovirt.org/Features/NetworkLabels
> > >>>
> > >>> Thanks,
> > >>> Moti
> > >>
> > >> Hi Moti,
> > >>
> > >> Thanks for writing a detailed feature page, good work.
> > >>
> > >> I have a few questions -
> > >>
> > >> 1. What does it mean to rename a network label. How does it work with
> > >> the fact that label is not a managed entity.
> > >> "Renaming a network label" - It seems from the document that you meant
> > >> edit network label (instead of rename), and why do we want to add that
> > >> unpredictable action in the first phase? I would start without this
> > >> option.
> > >>
> > > 
> > > 
> > > The network labels related actions will be executed either from the
> > > add/edit
> > > network dialog by editing the 'label' property, or by editing the label
> > > of
> > > 'interface/bond' on the 'setup networks' dialog. Since the label designed
> > > to
> > > be a plan text property on the network, renaming it means changing its
> > > value
> > > to other. Removing a label stands for clearing this field.
> > > 
> > 
> > So I guess it all about terminology, I think that since we are not
> > managing labels as entities we can't rename them, what we do is edit the
> > label on the network, changing one label to another.
> 
> I understand the added complexity of managing a Label as an entity, but
> do we have an experience with a user-editable foreign key like this?
> 

In order to ease the label selection/stating, the label will be typed into
a combo-box which includes the already exist labels in the system. Similar
to the 'bond name' combo-box.

So after the user adds network with labelled 'GRAY', he'll be aware of it 
when he'll attempt to specify a label starts with 'GR..' which will pop
the list containing 'GRAY'.

> My concern is that an American defines a GRAY label, attaches it to host
> nics, while an English starts to use GREY on another set of hosts.
> Understanding why a network is deployed only to some of the hosts may be
> hard, and fixing the spelling on multiple dialogs is going to be
> frustrating.
> 


From danken at redhat.com  Mon Dec  9 13:14:46 2013
From: danken at redhat.com (Dan Kenigsberg)
Date: Mon, 9 Dec 2013 13:14:46 +0000
Subject: Networks label feature
In-Reply-To: <1180196403.1930340.1386593095669.JavaMail.root@redhat.com>
References: <1257093362.1625319.1386508970320.JavaMail.root@redhat.com>
	<52A47CD9.9010807@redhat.com>
	<1178971434.1652590.1386520334701.JavaMail.root@redhat.com>
	<52A577E7.4040705@redhat.com> <20131209092854.GC19191@redhat.com>
	<1180196403.1930340.1386593095669.JavaMail.root@redhat.com>
Message-ID: <20131209131446.GJ19191@redhat.com>

On Mon, Dec 09, 2013 at 07:44:55AM -0500, Moti Asayag wrote:
> 
> 
> ----- Original Message -----
> > From: "Dan Kenigsberg" <danken at redhat.com>
> > To: "Livnat Peer" <lpeer at redhat.com>
> > Cc: "Moti Asayag" <masayag at redhat.com>, "arch" <arch at ovirt.org>
> > Sent: Monday, December 9, 2013 11:28:54 AM
> > Subject: Re: Networks label feature
> > 
> > On Mon, Dec 09, 2013 at 09:57:27AM +0200, Livnat Peer wrote:
> > > On 12/08/2013 06:32 PM, Moti Asayag wrote:
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > >> From: "Livnat Peer" <lpeer at redhat.com>
> > > >> To: "Moti Asayag" <masayag at redhat.com>, "arch" <arch at ovirt.org>
> > > >> Sent: Sunday, December 8, 2013 4:06:17 PM
> > > >> Subject: Re: Networks label feature
> > > >>
> > > >> On 12/08/2013 03:22 PM, Moti Asayag wrote:
> > > >>> Hi All,
> > > >>>
> > > >>> Another network feature planned for ovirt-engine-3.4 is
> > > >>> the network labels [1].
> > > >>>
> > > >>> Please review and share your feedbacks.
> > > >>>
> > > >>> [1] http://www.ovirt.org/Features/NetworkLabels
> > > >>>
> > > >>> Thanks,
> > > >>> Moti
> > > >>
> > > >> Hi Moti,
> > > >>
> > > >> Thanks for writing a detailed feature page, good work.
> > > >>
> > > >> I have a few questions -
> > > >>
> > > >> 1. What does it mean to rename a network label. How does it work with
> > > >> the fact that label is not a managed entity.
> > > >> "Renaming a network label" - It seems from the document that you meant
> > > >> edit network label (instead of rename), and why do we want to add that
> > > >> unpredictable action in the first phase? I would start without this
> > > >> option.
> > > >>
> > > > 
> > > > 
> > > > The network labels related actions will be executed either from the
> > > > add/edit
> > > > network dialog by editing the 'label' property, or by editing the label
> > > > of
> > > > 'interface/bond' on the 'setup networks' dialog. Since the label designed
> > > > to
> > > > be a plan text property on the network, renaming it means changing its
> > > > value
> > > > to other. Removing a label stands for clearing this field.
> > > > 
> > > 
> > > So I guess it all about terminology, I think that since we are not
> > > managing labels as entities we can't rename them, what we do is edit the
> > > label on the network, changing one label to another.
> > 
> > I understand the added complexity of managing a Label as an entity, but
> > do we have an experience with a user-editable foreign key like this?
> > 
> 
> In order to ease the label selection/stating, the label will be typed into
> a combo-box which includes the already exist labels in the system. Similar
> to the 'bond name' combo-box.
> 
> So after the user adds network with labelled 'GRAY', he'll be aware of it 
> when he'll attempt to specify a label starts with 'GR..' which will pop
> the list containing 'GRAY'.

This is receful in a way (if the Englishman is working late), and
depends on user's prudence.. I just wonder if we have anything like this
in our UI, to see if my fear is real.


From emesika at redhat.com  Mon Dec  9 14:50:44 2013
From: emesika at redhat.com (Eli Mesika)
Date: Mon, 9 Dec 2013 09:50:44 -0500 (EST)
Subject: Networks label feature
In-Reply-To: <1178971434.1652590.1386520334701.JavaMail.root@redhat.com>
References: <1257093362.1625319.1386508970320.JavaMail.root@redhat.com>
	<52A47CD9.9010807@redhat.com>
	<1178971434.1652590.1386520334701.JavaMail.root@redhat.com>
Message-ID: <1897829692.37141472.1386600644778.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Moti Asayag" <masayag at redhat.com>
> To: "Livnat Peer" <lpeer at redhat.com>
> Cc: "arch" <arch at ovirt.org>
> Sent: Sunday, December 8, 2013 6:32:14 PM
> Subject: Re: Networks label feature
> 
> 
> 
> ----- Original Message -----
> > From: "Livnat Peer" <lpeer at redhat.com>
> > To: "Moti Asayag" <masayag at redhat.com>, "arch" <arch at ovirt.org>
> > Sent: Sunday, December 8, 2013 4:06:17 PM
> > Subject: Re: Networks label feature
> > 
> > On 12/08/2013 03:22 PM, Moti Asayag wrote:
> > > Hi All,
> > > 
> > > Another network feature planned for ovirt-engine-3.4 is
> > > the network labels [1].
> > > 
> > > Please review and share your feedbacks.
> > > 
> > > [1] http://www.ovirt.org/Features/NetworkLabels
> > > 
> > > Thanks,
> > > Moti
> > 
> > Hi Moti,
> > 
> > Thanks for writing a detailed feature page, good work.
> > 
> > I have a few questions -
> > 
> > 1. What does it mean to rename a network label. How does it work with
> > the fact that label is not a managed entity.
> > "Renaming a network label" - It seems from the document that you meant
> > edit network label (instead of rename), and why do we want to add that
> > unpredictable action in the first phase? I would start without this option.
> > 
> 
> 
> The network labels related actions will be executed either from the add/edit
> network dialog by editing the 'label' property, or by editing the label of
> 'interface/bond' on the 'setup networks' dialog. Since the label designed to
> be a plan text property on the network, renaming it means changing its value
> to other. Removing a label stands for clearing this field.
> 
> The notation of label actions meant to clarify what are the result of each
> action.
> 
> Without this option we won't allow the admin to change a label once it is
> created.
> That seems like a harsh limitation. What if the user wishes to manage a
> specific
> network by other label that the network was originally added with ?
> 
> And it goes for the host direction as well: changing the label of the host
> nic
> indicates the user wishes to manage the networks attached to that nic by
> other
> label. That seems like a reasonable use case to me.
> 
> > 2. on the 'More examples' section you give an example with two labels on
> > a single network while at the beginning of the page you specified that
> > only one label is supported on a network.
> > 
> 
> This is a leftover from a wider solution. we'll start with a design for
> a single label per network and we'll see how it will evolves from there.

I think that even this is what you are going to support on 1st phase, it is good to
build things correctly right from the beginning, so , I would not add the label as a property
to an entity, rather , it should be a Many<-Many relation between entities and labels which 
implies an entity_label table.

>From past experience, this will not cots more than the simple 1 label solution, but changing it 
to a many-to-many relation in future will cost more ....


> 
> > 3. Do you plan to have the 'Apply to all hosts' check box? in the add
> > label section is says -"no further indication is required " and then on
> > the delete label it says - "The property 'Apply to all hosts' will be
> > reused"
> > 
> 
> In 'Add network' dialog there will be no 'Apply to all hosts' checkbox.
> This operation by itself cannot cause the network to be added to hosts
> without assigning the network to the clusters (even if the hosts' nics are
> labelled).
> 
> The 'delete labels' is basically using the 'Edit network' command for
> clearing this field. Therefore i suggest to make the already existing
> 'Apply to all hosts' property to indicates the network should be removed from
> all the labelled hosts, the alternative is not to remove a network
> from hosts if the label was cleared from the network.
> 
> > 4. Why does the delete label action is not symmetric with add label?
> > specifically why "Deleting the label from the host interface will not
> > cause the removal of the networks.."?
> > 
> 
> As stated in previous section - this is an alternative. Fine by me:
> Removing a label from network/host nic won't trigger its removal from
> the hosts.
> 
> > 5."Pre-'Setup Networks' execution"
> > It looks to me that we are playing catch 22 with the user there :)
> > If the user manually removed the network, although he labeled the NIC
> > then he does not expect the engine to add it again automatically on next
> > setup network.
> > I understand the need for exceptions but in this case I would start with
> > implementing this feature as simple as possible (it is already
> > complicated enough). So my suggestion is do not let the user remove the
> > network manually, if he want s to manage this NIC as an exception then
> > he needs to remove the label.
> > 
> > In this specific case I think it would make the behavior more
> > predictable to the user which is crucial (at least for the first phase)
> > for such a complicated feature IMO.
> >
> 
> As I see it, if the user provided label for the host nic (especially via the
> api),
> all the eligible networks labelled should be added to that nic.
> Therefore if the label wasn't removed, we should preserve the label
> definition on
> that host. Therefore limiting the removal seems a reasonable restriction.
> 
> > 
> > 6. How does the system reflect failures? If we added a label to a new
> > network and we failed to provisioned it on the host, how will the user
> > know about this? Can you please this to the feature page.
> > 
> 
> I'll add the 'events' section to the feature page. Basically, we should
> separate
> between the Add/Update network command to their extension behind the scenes
> by
> the labels or the 'apply to all hosts' option. So the correct place in the
> system to file those events will be in the event log, same as does for the
> 'Edit provisioned networks' feature.
> 
> > 
> > 7. After reading this page I wonder why not use the existing object Tag
> > that we have for labeling the networks and NICs?
> > 
> 
> The 'Tag' entity in the system is a hierarchical managed object, designed to
> tag mainly main entities in the system AFAICT. While the tags might work
> for network (after adding respectively the support of it, as there are no
> 'generic'
> tags), using the tags will raise further complexities for the host nics:
> In this case will require fetching a list of tags from the tag table for each
> nic.
> I would rather avoid using the tags, while all needed is a simple property.
> 
> > Livnat
> > 
> > 
> > > _______________________________________________
> > > 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 masayag at redhat.com  Mon Dec  9 22:31:58 2013
From: masayag at redhat.com (Moti Asayag)
Date: Mon, 9 Dec 2013 17:31:58 -0500 (EST)
Subject: Networks label feature
In-Reply-To: <52A577E7.4040705@redhat.com>
References: <1257093362.1625319.1386508970320.JavaMail.root@redhat.com>
	<52A47CD9.9010807@redhat.com>
	<1178971434.1652590.1386520334701.JavaMail.root@redhat.com>
	<52A577E7.4040705@redhat.com>
Message-ID: <1960252203.2263376.1386628318085.JavaMail.root@redhat.com>

I've incorporated the comments from the mail into the feature page.
Please read the inline comments below:

----- Original Message -----
> From: "Livnat Peer" <lpeer at redhat.com>
> To: "Moti Asayag" <masayag at redhat.com>
> Cc: "arch" <arch at ovirt.org>
> Sent: Monday, December 9, 2013 9:57:27 AM
> Subject: Re: Networks label feature
> 
> On 12/08/2013 06:32 PM, Moti Asayag wrote:
> > 
> > 
> > ----- Original Message -----
> >> From: "Livnat Peer" <lpeer at redhat.com>
> >> To: "Moti Asayag" <masayag at redhat.com>, "arch" <arch at ovirt.org>
> >> Sent: Sunday, December 8, 2013 4:06:17 PM
> >> Subject: Re: Networks label feature
> >>
> >> On 12/08/2013 03:22 PM, Moti Asayag wrote:
> >>> Hi All,
> >>>
> >>> Another network feature planned for ovirt-engine-3.4 is
> >>> the network labels [1].
> >>>
> >>> Please review and share your feedbacks.
> >>>
> >>> [1] http://www.ovirt.org/Features/NetworkLabels
> >>>
> >>> Thanks,
> >>> Moti
> >>
> >> Hi Moti,
> >>
> >> Thanks for writing a detailed feature page, good work.
> >>
> >> I have a few questions -
> >>
> >> 1. What does it mean to rename a network label. How does it work with
> >> the fact that label is not a managed entity.
> >> "Renaming a network label" - It seems from the document that you meant
> >> edit network label (instead of rename), and why do we want to add that
> >> unpredictable action in the first phase? I would start without this
> >> option.
> >>
> > 
> > 
> > The network labels related actions will be executed either from the
> > add/edit
> > network dialog by editing the 'label' property, or by editing the label of
> > 'interface/bond' on the 'setup networks' dialog. Since the label designed
> > to
> > be a plan text property on the network, renaming it means changing its
> > value
> > to other. Removing a label stands for clearing this field.
> > 
> 
> So I guess it all about terminology, I think that since we are not
> managing labels as entities we can't rename them, what we do is edit the
> label on the network, changing one label to another.

The new actions naming:

1.5.1 Labeling a network or an interface
1.5.2 Unlabeling a network or an interface
1.5.3 Changing a label of a network or an interface

> 
> > The notation of label actions meant to clarify what are the result of each
> > action.
> > 
> > Without this option we won't allow the admin to change a label once it is
> > created.
> 
> I think the user should be able to change the network label of course,
> but that would translate to remove and add label from the implementation
> perspective.
> 
> Which means you'll have to remove the network from all NICs with the
> original label and add the network to all the NICs with the new label,
> hopefully it would be done using a single setupNetwork operation per host.
> 

I think it should be achievable in a single 'setup networks' call. It will
require a more extensive parameters construction than the other use cases.

> > That seems like a harsh limitation. What if the user wishes to manage a
> > specific
> > network by other label that the network was originally added with ?
> > 
> > And it goes for the host direction as well: changing the label of the host
> > nic
> > indicates the user wishes to manage the networks attached to that nic by
> > other
> > label. That seems like a reasonable use case to me.
> > 
> >> 2. on the 'More examples' section you give an example with two labels on
> >> a single network while at the beginning of the page you specified that
> >> only one label is supported on a network.
> >>
> > 
> > This is a leftover from a wider solution. we'll start with a design for
> > a single label per network and we'll see how it will evolves from there.
> > 
> >> 3. Do you plan to have the 'Apply to all hosts' check box? in the add
> >> label section is says -"no further indication is required " and then on
> >> the delete label it says - "The property 'Apply to all hosts' will be
> >> reused"
> >>
> > 
> > In 'Add network' dialog there will be no 'Apply to all hosts' checkbox.
> > This operation by itself cannot cause the network to be added to hosts
> > without assigning the network to the clusters (even if the hosts' nics are
> > labelled).
> > 
> 
> The point is about add label, not about add network :)
> 

The property 'Apply to all hosts' will appear in the 'Edit Network' dialog
as part of the Multi-Host Network Configuration [1]. It should instruct the
appliance of the network changes on all of the hosts. This feature should 
co-exit with the network labels. I've added a section for it to the 'Unlabel
a network' section:

"In conjunction with the 'apply to all hosts', the network will be removed 
from all of the labelled interfaces, and the network will be updated on all 
of the other eligible hosts."

IMO, the 'apply all' property of the 'Update Network' command will apply the
network change to all of the hosts. If no change was made to the label, it
will sync the network on all of the hosts. If 'apply all' wasn't set, the
network change should be applied to the labelled interfaces only.

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

> > The 'delete labels' is basically using the 'Edit network' command for
> > clearing this field. Therefore i suggest to make the already existing
> > 'Apply to all hosts' property to indicates the network should be removed
> > from
> > all the labelled hosts, the alternative is not to remove a network
> > from hosts if the label was cleared from the network.
> > 
> 
> I think this checkbox is redundant in delete, same as you suggested,
> rightfully, in add.
> 
> >> 4. Why does the delete label action is not symmetric with add label?
> >> specifically why "Deleting the label from the host interface will not
> >> cause the removal of the networks.."?
> >>
> > 
> > As stated in previous section - this is an alternative. Fine by me:
> > Removing a label from network/host nic won't trigger its removal from
> > the hosts.
> > 
> 
> I think that removing a label from the host and from the network should
> effect the setup configuration - for consistency and for predictability.
> 
> removing a label from a NIC would remove the networks associated with
> that label from the NIC
> removing a label from the network would remove the network from all NICS
> that have this label.
> 
> 
> >> 5."Pre-'Setup Networks' execution"
> >> It looks to me that we are playing catch 22 with the user there :)
> >> If the user manually removed the network, although he labeled the NIC
> >> then he does not expect the engine to add it again automatically on next
> >> setup network.
> >> I understand the need for exceptions but in this case I would start with
> >> implementing this feature as simple as possible (it is already
> >> complicated enough). So my suggestion is do not let the user remove the
> >> network manually, if he want s to manage this NIC as an exception then
> >> he needs to remove the label.
> >>
> >> In this specific case I think it would make the behavior more
> >> predictable to the user which is crucial (at least for the first phase)
> >> for such a complicated feature IMO.
> >>
> > 
> > As I see it, if the user provided label for the host nic (especially via
> > the api),
> > all the eligible networks labelled should be added to that nic.
> > Therefore if the label wasn't removed, we should preserve the label
> > definition on
> > that host. Therefore limiting the removal seems a reasonable restriction.
> > 
> 
> Great
> 
> >>
> >> 6. How does the system reflect failures? If we added a label to a new
> >> network and we failed to provisioned it on the host, how will the user
> >> know about this? Can you please this to the feature page.
> >>
> > 
> > I'll add the 'events' section to the feature page. Basically, we should
> > separate
> > between the Add/Update network command to their extension behind the scenes
> > by
> > the labels or the 'apply to all hosts' option. So the correct place in the
> > system to file those events will be in the event log, same as does for the
> > 'Edit provisioned networks' feature.
> > 
> 
> The audit log are good for the action itself but I guess my question is
> would the setup network dialog reflect that the labels and the networks
> are not in sync?
> 

We should be able to provide such a feedback to the user. It may vary between
clusters according to the network assignment to the cluster. The indication for
it should be near the label configuration on the host and we should reflect it
as well in the networks main tab ---> host sub-tab.

Which leads to another question regarding 'Network Label constraints' [1]:
Wouldn't we like to prevent label definition which its appliance will fail 
for sure if all of the label associated networks are assigned to a cluster ? 
In this case we should extend the can-do-actions of add-update network commands
to validate the network label correctness. However, since the label is on dc level,
the user may configure invalid label that will function well according to
the assignment of the networks to cluster. I'm in favor of blocking the action
if the label isn't supported. I'd like to hear other opinion on this matter.

[1] http://www.ovirt.org/Features/NetworkLabels#Network_Label_constraints

> >>
> >> 7. After reading this page I wonder why not use the existing object Tag
> >> that we have for labeling the networks and NICs?
> >>
> > 
> > The 'Tag' entity in the system is a hierarchical managed object, designed
> > to
> > tag mainly main entities in the system AFAICT. While the tags might work
> > for network (after adding respectively the support of it, as there are no
> > 'generic'
> > tags), using the tags will raise further complexities for the host nics:
> > In this case will require fetching a list of tags from the tag table for
> > each nic.
> > I would rather avoid using the tags, while all needed is a simple property.
> > 
> 
> ack
> I agree that the fact the host NICs are not managed entities could make
> using TAGs not a good idea.
> 
> 
> 
> >> Livnat
> >>
> >>
> >>> _______________________________________________
> >>> Arch mailing list
> >>> Arch at ovirt.org
> >>> http://lists.ovirt.org/mailman/listinfo/arch
> >>>
> >>
> >>
> 
> 


From masayag at redhat.com  Tue Dec 10 15:56:31 2013
From: masayag at redhat.com (Moti Asayag)
Date: Tue, 10 Dec 2013 10:56:31 -0500 (EST)
Subject: Edit Provisioned Network Feature --> Multi-Host Network
	Configuration
In-Reply-To: <260448418.286241.1385394434059.JavaMail.root@redhat.com>
References: <260448418.286241.1385394434059.JavaMail.root@redhat.com>
Message-ID: <595461226.2746790.1386690991922.JavaMail.root@redhat.com>

The feature page was updated since its previous version.

Main changes:
1. new name: Multi-Host Network Configuration
2. No UI/api changes. Updating the network action will automatically apply the changes to
all of the eligible hosts (support from DC 3.1 where setup networks was introduced).
3. Renaming the network will be blocked if used by hosts, vms or templates.

Please review the entire changes on:

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

Regards,
Moti

----- Original Message -----
> From: "Moti Asayag" <masayag at redhat.com>
> To: "arch" <arch at ovirt.org>
> Sent: Monday, November 25, 2013 5:47:14 PM
> Subject: Edit Provisioned Network Feature
> 
> Hi,
> 
> Another network feature for 3.4 is "Edit Provisioned Network".
> Please review and add your comments.
> 
> [1] http://www.ovirt.org/Features/EditProvisionedNetwork
> 
> Thanks,
> Moti


From ovedo at redhat.com  Sun Dec 15 08:24:24 2013
From: ovedo at redhat.com (Oved Ourfalli)
Date: Sun, 15 Dec 2013 03:24:24 -0500 (EST)
Subject: domain name for a glance.ovirt.org
In-Reply-To: <941151004.42292997.1387095835843.JavaMail.root@redhat.com>
Message-ID: <1001459980.42293014.1387095864850.JavaMail.root@redhat.com>

Hi

I'd like to work on a public glance repo to be used with oVirt.
I'll need a domain name for that I guess, I guess glance.ovirt.org is the best choice.

How can I get this domain name?
What details do you need from me?

Thank you,
Oved


From dfediuck at redhat.com  Sun Dec 15 13:12:20 2013
From: dfediuck at redhat.com (Doron Fediuck)
Date: Sun, 15 Dec 2013 08:12:20 -0500 (EST)
Subject: [Engine-devel] Help to review the design of Feature/NUMA and
	Virtual NUMA
In-Reply-To: <B63C858E777679458338A30A991BB5240155E248@G1W3780.americas.hpqcorp.net>
References: <B63C858E777679458338A30A991BB5240155E248@G1W3780.americas.hpqcorp.net>
Message-ID: <206088558.31446311.1387113140987.JavaMail.root@redhat.com>

Adding arch list as this may effect other sub-projects
as well.

----- Original Message -----
> From: "Chuan Liao (Jason, MCXS-CQ)" <chuan.liao at hp.com>
> To: engine-devel at ovirt.org
> Sent: Friday, December 13, 2013 9:37:59 AM
> Subject: [Engine-devel] Help to review the design of Feature/NUMA and	Virtual NUMA
> 
> 
> 
> Hi Everyone,
> 
> 
> 
> I am Jason Liao from HP, now focus on the NUMA feature integration into
> oVirt.
> 
> 
> 
> Now we finish the first step of High-level design document.
> 
> 
> 
> Please help to review the design of Features/NUMA_and_Virtual_NUMA on oVirt
> community wiki page.
> 
> 
> 
> If anyone have some question and suggestion, please let me know.
> 
> 
> 
> Thanks all.
> 
> 
> 
> Best Regards,
> Jason Liao
> 
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From nsoffer at redhat.com  Sun Dec 15 16:02:00 2013
From: nsoffer at redhat.com (Nir Soffer)
Date: Sun, 15 Dec 2013 11:02:00 -0500 (EST)
Subject: Community Gardener for week starting at December 16
In-Reply-To: <453505673.30699772.1387123050472.JavaMail.root@redhat.com>
Message-ID: <528824838.30699958.1387123320239.JavaMail.root@redhat.com>

Hi all,

I will be the cloud storage group community gardener next week, starting at
December 16.

I plan to work on:

- Adding a Python mocking library and integrating it with the vdsm unit-tests
- Improving ovirt-live documentation
- Other ovirt-live stuff

Thanks,
Nir


From derez at redhat.com  Sun Dec 15 17:40:06 2013
From: derez at redhat.com (Daniel Erez)
Date: Sun, 15 Dec 2013 12:40:06 -0500 (EST)
Subject: Single Disk Snapshot Feature
In-Reply-To: <1963535672.52035792.1387128483367.JavaMail.root@redhat.com>
Message-ID: <1289649020.52035943.1387129206895.JavaMail.root@redhat.com>

Hi,

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

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

Regards,
Daniel


From tnisan at redhat.com  Mon Dec 16 12:21:25 2013
From: tnisan at redhat.com (Tal Nisan)
Date: Mon, 16 Dec 2013 07:21:25 -0500 (EST)
Subject: OVF on any domain feature overview
Message-ID: <184138425.31767802.1387196485662.JavaMail.root@redhat.com>

The following is a new meeting request:

Subject: OVF on any domain feature overview 
Organizer: "Tal Nisan" <tnisan at redhat.com> 

Time: Monday, December 23, 2013, 6:00:00 PM - 6:30:00 PM GMT +02:00 Jerusalem
 
Invitees: users at ovirt.org; arch at ovirt.org 


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

Etherpad link: http://etherpad.ovirt.org/p/OvfOnAnyDomain 

Intercall Conf ID: 8425973915# 

Reservationless-Plus Toll Free Dial-In Number (US & Canada): (800) 451-8679 
Reservationless-Plus International Dial-In Number: (212) 729-5016 
Reservationless-Plus Israel dial in - 1809462557 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: meeting.ics
Type: text/calendar
Size: 1721 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20131216/ffdbe345/attachment.ics>

From sbonazzo at redhat.com  Mon Dec 16 15:39:55 2013
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Mon, 16 Dec 2013 16:39:55 +0100
Subject: oVirt 3.3.2 RC
Message-ID: <52AF1ECB.5000405@redhat.com>

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

We planned to release it on Wed Dec 18th 2013 but it will probably be postponed
to next week for allowing more testing on the RC.
The release date will be decided in next oVrit sync meeting on Wed Dec 18th.
Feel free to join us testing it[2] and verifying the bugzilla entries actually
under verification [3].

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

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

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

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


From dneary at redhat.com  Tue Dec 17 09:00:31 2013
From: dneary at redhat.com (Dave Neary)
Date: Tue, 17 Dec 2013 11:00:31 +0200
Subject: Fwd: Your stand proposal for oVirt has been accepted
In-Reply-To: <20131216212820.74EE23F4C3@toad.stack.nl>
References: <20131216212820.74EE23F4C3@toad.stack.nl>
Message-ID: <52B012AF.1070608@redhat.com>

Hi everyone,

Great news! We will have an oVirt stand at FOSDEM in Brussels this year!

Brian and I will be looking for volunteers to man the stand and spread
the love about oVirt over the next few weeks - please let us know if you
plan to attend FOSDEM, we would love to see you there!

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

Thanks,
Dave.


-------- Original Message --------
Subject: Your stand proposal for oVirt has been accepted
Date: Mon, 16 Dec 2013 22:28:20 +0100 (CET)
From: FOSDEM Stands Team <stands at fosdem.org>
To: Dave Neary <dneary at redhat.com>

Hi Dave,

The FOSDEM stands team is glad to be able to inform you that your request
for a stand for oVirt has been accepted.
There will be one table reserved for you.

You will receive further information about what's expected of you closer
to the event date.

Looking forward to seeing you at FOSDEM 2014!


Kind regards,

Wynke Stulemeijer
FOSDEM stands team




From nsoffer at redhat.com  Wed Dec 18 10:40:42 2013
From: nsoffer at redhat.com (Nir Soffer)
Date: Wed, 18 Dec 2013 05:40:42 -0500 (EST)
Subject: Community Gardener for week starting at December 16
In-Reply-To: <528824838.30699958.1387123320239.JavaMail.root@redhat.com>
References: <528824838.30699958.1387123320239.JavaMail.root@redhat.com>
Message-ID: <301086782.32217046.1387363242075.JavaMail.root@redhat.com>

----- Original Message -----
> From: "Nir Soffer" <nsoffer at redhat.com>
> To: arch at ovirt.org, "oVirt Mailing List" <users at ovirt.org>
> Sent: Sunday, December 15, 2013 6:02:00 PM
> Subject: Community Gardener for week starting at December 16
> 
> Hi all,
> 
> I will be the cloud storage group community gardener next week, starting at
> December 16.
> 
> I plan to work on:
> 
> - Adding a Python mocking library and integrating it with the vdsm unit-tests
> - Improving ovirt-live documentation
> - Other ovirt-live stuff

Updates:

- Ovirt live is more lively now, booting also on USB3 ports [1].
  I tested in on Lenovo T430s. You are invited to test it on your hardware.

- Plan to add a Python mocking library canceled, one of vdsm maintainers objects
  to these libraries.

- Next: avoiding the browser warning about self signed certificate when opening
  ovirt page in the browser.

  I think that the issue is adding the signer of the ovirt certificate to the 
  browser/system root ca list.
  
  If you happen to know how to do this, ping me on #ovirt or here.

[1] http://gerrit.ovirt.org/22495

Nir



From dneary at redhat.com  Wed Dec 18 12:01:14 2013
From: dneary at redhat.com (Dave Neary)
Date: Wed, 18 Dec 2013 14:01:14 +0200
Subject: Community Gardener for week starting at December 16
In-Reply-To: <301086782.32217046.1387363242075.JavaMail.root@redhat.com>
References: <528824838.30699958.1387123320239.JavaMail.root@redhat.com>
	<301086782.32217046.1387363242075.JavaMail.root@redhat.com>
Message-ID: <52B18E8A.6030304@redhat.com>



On 12/18/2013 12:40 PM, Nir Soffer wrote:
> - Ovirt live is more lively now, booting also on USB3 ports [1].
>   I tested in on Lenovo T430s. You are invited to test it on your hardware.
> [1] http://gerrit.ovirt.org/22495

Awesome! Thank you Nir. Do we have an ISO built from your patch? Is the
one linked to from ovirt.org/oVirt_Live correct?

> - Next: avoiding the browser warning about self signed certificate when opening
>   ovirt page in the browser.
> 
>   I think that the issue is adding the signer of the ovirt certificate to the 
>   browser/system root ca list.
>   
>   If you happen to know how to do this, ping me on #ovirt or here.

I'm no help I'm afraid. I don't have any major issues with self-signed
certificates myself (too used to the warnings, perhaps) - do you think
it's a big issue for oVirt Live users?

Cheers,
Dave.

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


From nsoffer at redhat.com  Wed Dec 18 12:15:15 2013
From: nsoffer at redhat.com (Nir Soffer)
Date: Wed, 18 Dec 2013 07:15:15 -0500 (EST)
Subject: Community Gardener for week starting at December 16
In-Reply-To: <52B18E8A.6030304@redhat.com>
References: <528824838.30699958.1387123320239.JavaMail.root@redhat.com>
	<301086782.32217046.1387363242075.JavaMail.root@redhat.com>
	<52B18E8A.6030304@redhat.com>
Message-ID: <2061322446.32270979.1387368915257.JavaMail.root@redhat.com>

----- Original Message -----
> From: "Dave Neary" <dneary at redhat.com>
> To: "Nir Soffer" <nsoffer at redhat.com>, arch at ovirt.org, "oVirt Mailing List" <users at ovirt.org>
> Sent: Wednesday, December 18, 2013 2:01:14 PM
> Subject: Re: Community Gardener for week starting at December 16
> 
> 
> 
> On 12/18/2013 12:40 PM, Nir Soffer wrote:
> > - Ovirt live is more lively now, booting also on USB3 ports [1].
> >   I tested in on Lenovo T430s. You are invited to test it on your hardware.
> > [1] http://gerrit.ovirt.org/22495
> 
> Awesome! Thank you Nir. Do we have an ISO built from your patch? Is the
> one linked to from ovirt.org/oVirt_Live correct?

The latest version there is from Oct 14.

I think that we need a nightly version, so people can test it easily.

Currently the only way to test this version is to setup a Centos machine, get
the source and build it.

I think documenting how to do this will be a useful addition so other can 
participate in this effort.

> 
> > - Next: avoiding the browser warning about self signed certificate when
> > opening
> >   ovirt page in the browser.
> > 
> >   I think that the issue is adding the signer of the ovirt certificate to
> >   the
> >   browser/system root ca list.
> >   
> >   If you happen to know how to do this, ping me on #ovirt or here.
> 
> I'm no help I'm afraid. I don't have any major issues with self-signed
> certificates myself (too used to the warnings, perhaps) - do you think
> it's a big issue for oVirt Live users?

This was the second painful issue when I discussed with Ohad. I think this is sloppy
to create a demo displaying such errors. Fixing this should be easy.

I have a bigger issue with the setup process and the way it runs from a console,
but that should be much harder to fix.

Do you want to suggest other work instead?

Nir


From dneary at redhat.com  Wed Dec 18 12:55:53 2013
From: dneary at redhat.com (Dave Neary)
Date: Wed, 18 Dec 2013 14:55:53 +0200
Subject: Host Network QoS feature
In-Reply-To: <5292F175.6090906@redhat.com>
References: <5292F175.6090906@redhat.com>
Message-ID: <52B19B59.9050309@redhat.com>

Hi Lior,

On 11/25/2013 08:43 AM, Lior Vernia wrote:
> Hello everybody,
> 
> One of the upcoming network features for oVirt 3.4 is Host Network QoS,
> i.e. being to configure Quality of Service over networks attached to
> hosts' interfaces. The primary motivation is to be able to cap traffic
> related to specific networks, so that other networks residing on the
> same interface could function. The feature pages are up and I would like
> to open the discussion over them.
> 
> Overview:
> http://www.ovirt.org/Features/Host_Network_QoS

The user-level description of the feature looks great to me! I can't
reallyspeak to the design, but the goal of per-network bandwidth quotas
is an awesome feature.

Cheers,
Dave.

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


From lvernia at redhat.com  Wed Dec 18 13:43:54 2013
From: lvernia at redhat.com (Lior Vernia)
Date: Wed, 18 Dec 2013 15:43:54 +0200
Subject: Host Network QoS feature
In-Reply-To: <52B19B59.9050309@redhat.com>
References: <5292F175.6090906@redhat.com> <52B19B59.9050309@redhat.com>
Message-ID: <52B1A69A.10303@redhat.com>

Hey Dave,

On 18/12/13 14:55, Dave Neary wrote:
> Hi Lior,
> 
> On 11/25/2013 08:43 AM, Lior Vernia wrote:
>> Hello everybody,
>>
>> One of the upcoming network features for oVirt 3.4 is Host Network QoS,
>> i.e. being to configure Quality of Service over networks attached to
>> hosts' interfaces. The primary motivation is to be able to cap traffic
>> related to specific networks, so that other networks residing on the
>> same interface could function. The feature pages are up and I would like
>> to open the discussion over them.
>>
>> Overview:
>> http://www.ovirt.org/Features/Host_Network_QoS
> 
> The user-level description of the feature looks great to me! I can't
> reallyspeak to the design, but the goal of per-network bandwidth quotas
> is an awesome feature.

Thanks, the congestion of the management network traffic is a common
pain-point related to live migration in oVirt. The feature aims to
provide a solution, and in a way that should allow users with existing
pre-3.4 DCs to cap the traffic of a single network on all their hosts
within one simple operation.

> 
> Cheers,
> Dave.
> 


From iheim at redhat.com  Thu Dec 19 10:36:49 2013
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 19 Dec 2013 05:36:49 -0500
Subject: Community Gardener for week starting at December 16
In-Reply-To: <2061322446.32270979.1387368915257.JavaMail.root@redhat.com>
References: <528824838.30699958.1387123320239.JavaMail.root@redhat.com>	<301086782.32217046.1387363242075.JavaMail.root@redhat.com>	<52B18E8A.6030304@redhat.com>
	<2061322446.32270979.1387368915257.JavaMail.root@redhat.com>
Message-ID: <52B2CC41.3080002@redhat.com>

On 12/18/2013 07:15 AM, Nir Soffer wrote:
> ----- Original Message -----
>> From: "Dave Neary" <dneary at redhat.com>
>> To: "Nir Soffer" <nsoffer at redhat.com>, arch at ovirt.org, "oVirt Mailing List" <users at ovirt.org>
>> Sent: Wednesday, December 18, 2013 2:01:14 PM
>> Subject: Re: Community Gardener for week starting at December 16
>>
>>
>>
>> On 12/18/2013 12:40 PM, Nir Soffer wrote:
>>> - Ovirt live is more lively now, booting also on USB3 ports [1].
>>>    I tested in on Lenovo T430s. You are invited to test it on your hardware.
>>> [1] http://gerrit.ovirt.org/22495
>>
>> Awesome! Thank you Nir. Do we have an ISO built from your patch? Is the
>> one linked to from ovirt.org/oVirt_Live correct?
>
> The latest version there is from Oct 14.
>
> I think that we need a nightly version, so people can test it easily.
>
> Currently the only way to test this version is to setup a Centos machine, get
> the source and build it.
>
> I think documenting how to do this will be a useful addition so other can
> participate in this effort.
>
>>
>>> - Next: avoiding the browser warning about self signed certificate when
>>> opening
>>>    ovirt page in the browser.
>>>
>>>    I think that the issue is adding the signer of the ovirt certificate to
>>>    the
>>>    browser/system root ca list.
>>>
>>>    If you happen to know how to do this, ping me on #ovirt or here.
>>
>> I'm no help I'm afraid. I don't have any major issues with self-signed
>> certificates myself (too used to the warnings, perhaps) - do you think
>> it's a big issue for oVirt Live users?

i think easiest is to monitor your .firefox folder, approve it, check 
the diff. then have the installer inject the same.

>
> This was the second painful issue when I discussed with Ohad. I think this is sloppy
> to create a demo displaying such errors. Fixing this should be easy.
>
> I have a bigger issue with the setup process and the way it runs from a console,
> but that should be much harder to fix.
>
> Do you want to suggest other work instead?
>
> Nir
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
>



From sbonazzo at redhat.com  Thu Dec 19 14:03:45 2013
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Thu, 19 Dec 2013 15:03:45 +0100
Subject: oVirt 3.3.2 release
Message-ID: <52B2FCC1.7030206@redhat.com>

The oVirt development team is very happy to announce the general
availability of oVirt 3.3.2 as of December 19th 2013. This release
solidifies oVirt as a leading KVM management application and open
source alternative to VMware vSphere.

oVirt is available now for Fedora 19 and Red Hat Enterprise Linux 6.5
(or similar).

This release of oVirt includes 175 bug fixes and the first release of the
Backup and Restore API, which enables backup programs to integrate with oVirt.
This release also simplifies the Guide Me VM-creation wizard. See the release
notes [1] for a list of the new features and bugs fixed.

IMPORTANT NOTE: If you're upgrading from a previous version, please update
ovirt-release to the latest version (10) and verify you have the correct
repositories enabled by running the following commands

# yum update ovirt-release
# yum repolist enabled

before upgrading with the usual procedure. You should see the ovirt-3.3.2 and
ovirt-stable repositories listed in the output of the repolist command.



[1] http://www.ovirt.org/OVirt_3.3.2_release_notes

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


From dfediuck at redhat.com  Fri Dec 20 05:44:25 2013
From: dfediuck at redhat.com (Doron Fediuck)
Date: Fri, 20 Dec 2013 00:44:25 -0500 (EST)
Subject: =?UTF-8?Q?=D7=94=D7=A9=D7=91:_oVirt_3.3.2_Beta_now_available?=
Message-ID: <1ny208jeqv99lpijaph0sm6y.1387518261352@email.android.com>

Beta?

-------- ????? ?????? --------
???: Sandro Bonazzola <sbonazzo at redhat.com> 
?????:  
??: announce at ovirt.org,arch <arch at ovirt.org>,Users at ovirt.org,engine-devel <engine-devel at ovirt.org> 
????: oVirt 3.3.2 Beta now available 
 
The oVirt team is pleased to announce that the 3.3.2 Release is now available in beta.

Release notes and information on the changes for this update are still being worked on and will be available soon on the wiki[1].

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

You're welcome to join us testing [2] this beta release.


[1] http://www.ovirt.org/OVirt_3.3.2_release_notes
[2] http://www.ovirt.org/Testing/Ovirt_3.3.2_testing


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

From sbonazzo at redhat.com  Fri Dec 20 06:47:50 2013
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Fri, 20 Dec 2013 07:47:50 +0100
Subject: =?UTF-8?B?15TXqdeROiBvVmlydCAzLjMuMiBCZXRhIG5vdyBhdmFpbGFibGU=?=
In-Reply-To: <1ny208jeqv99lpijaph0sm6y.1387518261352@email.android.com>
References: <1ny208jeqv99lpijaph0sm6y.1387518261352@email.android.com>
Message-ID: <52B3E816.20409@redhat.com>

Il 20/12/2013 06:44, Doron Fediuck ha scritto:
> Beta?
> 

the email is from december 3rd. It seems that moderator approved the email only yesterday...



> 
> 
> -------- ????? ?????? --------
> ???: Sandro Bonazzola <sbonazzo at redhat.com>
> ?????:
> ??: announce at ovirt.org,arch <arch at ovirt.org>,Users at ovirt.org,engine-devel <engine-devel at ovirt.org>
> ????: oVirt 3.3.2 Beta now available
> 
> 
> The oVirt team is pleased to announce that the 3.3.2 Release is now available in beta.
> 
> Release notes and information on the changes for this update are still being worked on and will be available soon on the wiki[1].
> 
> A new oVirt Node build will be available soon as well.
> 
> You're welcome to join us testing [2] this beta release.
> 
> 
> [1] http://www.ovirt.org/OVirt_3.3.2_release_notes
> [2] http://www.ovirt.org/Testing/Ovirt_3.3.2_testing
> 
> 
> -- 
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
> _______________________________________________
> Announce mailing list
> Announce at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/announce
> 
> 
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


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


From shtripat at redhat.com  Fri Dec 20 11:52:50 2013
From: shtripat at redhat.com (Shubhendu Tripathi)
Date: Fri, 20 Dec 2013 17:22:50 +0530
Subject: Gluster volume capacity feature
Message-ID: <52B42F92.9080809@redhat.com>

Hi All,

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

Please review the same and provide your comments.

Added Michael and Ori specifically for review of REST apis.

Thanks,
Shubhendu Tripathi



From bob at doolittle.us.com  Fri Dec 20 16:12:08 2013
From: bob at doolittle.us.com (Bob Doolittle)
Date: Fri, 20 Dec 2013 11:12:08 -0500
Subject: oVirt 3.3.2 release
In-Reply-To: <52B2FCC1.7030206@redhat.com>
References: <52B2FCC1.7030206@redhat.com>
Message-ID: <52B46C58.6000701@doolittle.us.com>

I can't do an update of Engine for RHEL 6.

The 3.3.2 packages do not seem to have been pushed here:

http://resources.ovirt.org/releases/stable/rpm/EL/6/noarch/

-Bob

On 12/19/2013 09:03 AM, Sandro Bonazzola wrote:
> The oVirt development team is very happy to announce the general
> availability of oVirt 3.3.2 as of December 19th 2013. This release
> solidifies oVirt as a leading KVM management application and open
> source alternative to VMware vSphere.
>
> oVirt is available now for Fedora 19 and Red Hat Enterprise Linux 6.5
> (or similar).
>
> This release of oVirt includes 175 bug fixes and the first release of the
> Backup and Restore API, which enables backup programs to integrate with oVirt.
> This release also simplifies the Guide Me VM-creation wizard. See the release
> notes [1] for a list of the new features and bugs fixed.
>
> IMPORTANT NOTE: If you're upgrading from a previous version, please update
> ovirt-release to the latest version (10) and verify you have the correct
> repositories enabled by running the following commands
>
> # yum update ovirt-release
> # yum repolist enabled
>
> before upgrading with the usual procedure. You should see the ovirt-3.3.2 and
> ovirt-stable repositories listed in the output of the repolist command.
>
>
>
> [1] http://www.ovirt.org/OVirt_3.3.2_release_notes
>



From fabiand at redhat.com  Fri Dec 20 16:13:53 2013
From: fabiand at redhat.com (Fabian Deutsch)
Date: Fri, 20 Dec 2013 17:13:53 +0100
Subject: oVirt 3.3.2 release
In-Reply-To: <52B46C58.6000701@doolittle.us.com>
References: <52B2FCC1.7030206@redhat.com> <52B46C58.6000701@doolittle.us.com>
Message-ID: <1387556033.12243.0.camel@fdeutsch-laptop.local>

Am Freitag, den 20.12.2013, 11:12 -0500 schrieb Bob Doolittle:
> I can't do an update of Engine for RHEL 6.
> 
> The 3.3.2 packages do not seem to have been pushed here:
> 
> http://resources.ovirt.org/releases/stable/rpm/EL/6/noarch/

Thanks - I observed the same.

- fabian

> -Bob
> 
> On 12/19/2013 09:03 AM, Sandro Bonazzola wrote:
> > The oVirt development team is very happy to announce the general
> > availability of oVirt 3.3.2 as of December 19th 2013. This release
> > solidifies oVirt as a leading KVM management application and open
> > source alternative to VMware vSphere.
> >
> > oVirt is available now for Fedora 19 and Red Hat Enterprise Linux 6.5
> > (or similar).
> >
> > This release of oVirt includes 175 bug fixes and the first release of the
> > Backup and Restore API, which enables backup programs to integrate with oVirt.
> > This release also simplifies the Guide Me VM-creation wizard. See the release
> > notes [1] for a list of the new features and bugs fixed.
> >
> > IMPORTANT NOTE: If you're upgrading from a previous version, please update
> > ovirt-release to the latest version (10) and verify you have the correct
> > repositories enabled by running the following commands
> >
> > # yum update ovirt-release
> > # yum repolist enabled
> >
> > before upgrading with the usual procedure. You should see the ovirt-3.3.2 and
> > ovirt-stable repositories listed in the output of the repolist command.
> >
> >
> >
> > [1] http://www.ovirt.org/OVirt_3.3.2_release_notes
> >
> 
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20131220/984daa6c/attachment.sig>

From bob at doolittle.us.com  Fri Dec 20 16:23:44 2013
From: bob at doolittle.us.com (Bob Doolittle)
Date: Fri, 20 Dec 2013 11:23:44 -0500
Subject: oVirt 3.3.2 release
In-Reply-To: <1387556033.12243.0.camel@fdeutsch-laptop.local>
References: <52B2FCC1.7030206@redhat.com>	 <52B46C58.6000701@doolittle.us.com>
	<1387556033.12243.0.camel@fdeutsch-laptop.local>
Message-ID: <52B46F10.5000005@doolittle.us.com>

I think the problem may be other than I indicated, however, because I 
don't see ovirt-engine-3.3.2 in the FC19 stable repo either. Here's the 
error output of my update command:

Error: Package: ovirt-engine-3.3.1-2.el6.noarch (@ovirt-stable)
            Requires: ovirt-engine-websocket-proxy = 3.3.1-2.el6
            Removing: ovirt-engine-websocket-proxy-3.3.1-2.el6.noarch 
(@ovirt-stable)
                ovirt-engine-websocket-proxy = 3.3.1-2.el6
            Updated By: ovirt-engine-websocket-proxy-3.3.2-1.el6.noarch 
(ovirt-3.3.2)
                ovirt-engine-websocket-proxy = 3.3.2-1.el6
            Available: ovirt-engine-websocket-proxy-3.3.0-3.el6.noarch 
(ovirt-stable)
                ovirt-engine-websocket-proxy = 3.3.0-3.el6
            Available: ovirt-engine-websocket-proxy-3.3.0-4.el6.noarch 
(ovirt-stable)
                ovirt-engine-websocket-proxy = 3.3.0-4.el6
            Available: ovirt-engine-websocket-proxy-3.3.0.1-1.el6.noarch 
(ovirt-stable)
                ovirt-engine-websocket-proxy = 3.3.0.1-1.el6
            Available: ovirt-engine-websocket-proxy-3.3.1-1.el6.noarch 
(ovirt-stable)
                ovirt-engine-websocket-proxy = 3.3.1-1.el6

I have attached my current repo config, after the update of 
ovirt-release-el6-10-1

I'm not sure why it's not seeing 
http://resources.ovirt.org/releases/3.3.2/rpm/EL/6/noarch/ovirt-engine-3.3.2-1.el6.noarch.rpm

I do see that repository enabled in "yum repolist enabled" output.

-Bob

On 12/20/2013 11:13 AM, Fabian Deutsch wrote:
> Am Freitag, den 20.12.2013, 11:12 -0500 schrieb Bob Doolittle:
>> I can't do an update of Engine for RHEL 6.
>>
>> The 3.3.2 packages do not seem to have been pushed here:
>>
>> http://resources.ovirt.org/releases/stable/rpm/EL/6/noarch/
> Thanks - I observed the same.
>
> - fabian
>
>> -Bob
>>
>> On 12/19/2013 09:03 AM, Sandro Bonazzola wrote:
>>> The oVirt development team is very happy to announce the general
>>> availability of oVirt 3.3.2 as of December 19th 2013. This release
>>> solidifies oVirt as a leading KVM management application and open
>>> source alternative to VMware vSphere.
>>>
>>> oVirt is available now for Fedora 19 and Red Hat Enterprise Linux 6.5
>>> (or similar).
>>>
>>> This release of oVirt includes 175 bug fixes and the first release of the
>>> Backup and Restore API, which enables backup programs to integrate with oVirt.
>>> This release also simplifies the Guide Me VM-creation wizard. See the release
>>> notes [1] for a list of the new features and bugs fixed.
>>>
>>> IMPORTANT NOTE: If you're upgrading from a previous version, please update
>>> ovirt-release to the latest version (10) and verify you have the correct
>>> repositories enabled by running the following commands
>>>
>>> # yum update ovirt-release
>>> # yum repolist enabled
>>>
>>> before upgrading with the usual procedure. You should see the ovirt-3.3.2 and
>>> ovirt-stable repositories listed in the output of the repolist command.
>>>
>>>
>>>
>>> [1] http://www.ovirt.org/OVirt_3.3.2_release_notes
>>>
>> _______________________________________________
>> Arch mailing list
>> Arch at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/arch

-------------- next part --------------
[ovirt-stable]
name=Older Stable builds of the oVirt project
baseurl=http://ovirt.org/releases/stable/rpm/EL/$releasever/
enabled=1
skip_if_unavailable=1
gpgcheck=0

[ovirt-3.3.2]
name=oVirt 3.3.2 release
baseurl=http://resources.ovirt.org/releases/3.3.2/rpm/EL/$releasever/
enabled=1
skip_if_unavailable=1
gpgcheck=0

[ovirt-updates-testing]
name=Test Updates builds of the oVirt project
baseurl=http://ovirt.org/releases/updates-testing/rpm/EL/$releasever/
enabled=0
skip_if_unavailable=1
gpgcheck=0

[ovirt-beta]
name=Beta builds of the oVirt project
baseurl=http://ovirt.org/releases/beta/rpm/EL/$releasever/
enabled=0
skip_if_unavailable=1
gpgcheck=0

[ovirt-nightly]
name=Nightly builds of the oVirt project
baseurl=http://ovirt.org/releases/nightly/rpm/EL/$releasever/
enabled=0
skip_if_unavailable=1
gpgcheck=0

From bob at doolittle.us.com  Sat Dec 21 12:24:40 2013
From: bob at doolittle.us.com (Bob Doolittle)
Date: Sat, 21 Dec 2013 07:24:40 -0500
Subject: AW: Re: [Users] oVirt 3.3.2 release
In-Reply-To: <9a3eqe9cmlqcfluko0wta6k1.1387619712990@email.android.com>
References: <52B2FCC1.7030206@redhat.com> <52B46C58.6000701@doolittle.us.com>
	<1387556033.12243.0.camel@fdeutsch-laptop.local>
	<52B46F10.5000005@doolittle.us.com>
	<9a3eqe9cmlqcfluko0wta6k1.1387619712990@email.android.com>
Message-ID: <CA+4jJ+tyhMHD6bTgZcqA8zByS8s+FeZSkUPXuHx7roPMa1fnyQ@mail.gmail.com>

Thanks. I considered that but I've been hesitant to try manual workarounds
in case my environment proves helpful for troubleshooting or verifying a
solution. Clearly the community needs a real fix, although the lack of
response to this issue surprised me. Must be the holidays :-)

-Bob
On Dec 21, 2013 4:55 AM, "Markus Stockhausen" <stockhausen at collogia.de>
wrote:

> We are on centos 6.5 and got similar dependency errors but simply replaced
> ovirt-release with ovirt-release-el6 in the guide. Afterwards everything
> worked smoothly.
>
> Do not know if it helps
>
> Von meinem Xperia?-Smartphone  gesendet
>
> Bob Doolittle <bob at doolittle.us.com> schrieb:
>
>
> I think the problem may be other than I indicated, however, because I
> don't see ovirt-engine-3.3.2 in the FC19 stable repo either. Here's the
> error output of my update command:
>
> Error: Package: ovirt-engine-3.3.1-2.el6.noarch (@ovirt-stable)
>             Requires: ovirt-engine-websocket-proxy = 3.3.1-2.el6
>             Removing: ovirt-engine-websocket-proxy-3.3.1-2.el6.noarch
> (@ovirt-stable)
>                 ovirt-engine-websocket-proxy = 3.3.1-2.el6
>             Updated By: ovirt-engine-websocket-proxy-3.3.2-1.el6.noarch
> (ovirt-3.3.2)
>                 ovirt-engine-websocket-proxy = 3.3.2-1.el6
>             Available: ovirt-engine-websocket-proxy-3.3.0-3.el6.noarch
> (ovirt-stable)
>                 ovirt-engine-websocket-proxy = 3.3.0-3.el6
>             Available: ovirt-engine-websocket-proxy-3.3.0-4.el6.noarch
> (ovirt-stable)
>                 ovirt-engine-websocket-proxy = 3.3.0-4.el6
>             Available: ovirt-engine-websocket-proxy-3.3.0.1-1.el6.noarch
> (ovirt-stable)
>                 ovirt-engine-websocket-proxy = 3.3.0.1-1.el6
>             Available: ovirt-engine-websocket-proxy-3.3.1-1.el6.noarch
> (ovirt-stable)
>                 ovirt-engine-websocket-proxy = 3.3.1-1.el6
>
> I have attached my current repo config, after the update of
> ovirt-release-el6-10-1
>
> I'm not sure why it's not seeing
>
> http://resources.ovirt.org/releases/3.3.2/rpm/EL/6/noarch/ovirt-engine-3.3.2-1.el6.noarch.rpm
>
> I do see that repository enabled in "yum repolist enabled" output.
>
> -Bob
>
> On 12/20/2013 11:13 AM, Fabian Deutsch wrote:
> > Am Freitag, den 20.12.2013, 11:12 -0500 schrieb Bob Doolittle:
> >> I can't do an update of Engine for RHEL 6.
> >>
> >> The 3.3.2 packages do not seem to have been pushed here:
> >>
> >> http://resources.ovirt.org/releases/stable/rpm/EL/6/noarch/
> > Thanks - I observed the same.
> >
> > - fabian
> >
> >> -Bob
> >>
> >> On 12/19/2013 09:03 AM, Sandro Bonazzola wrote:
> >>> The oVirt development team is very happy to announce the general
> >>> availability of oVirt 3.3.2 as of December 19th 2013. This release
> >>> solidifies oVirt as a leading KVM management application and open
> >>> source alternative to VMware vSphere.
> >>>
> >>> oVirt is available now for Fedora 19 and Red Hat Enterprise Linux 6.5
> >>> (or similar).
> >>>
> >>> This release of oVirt includes 175 bug fixes and the first release of
> the
> >>> Backup and Restore API, which enables backup programs to integrate
> with oVirt.
> >>> This release also simplifies the Guide Me VM-creation wizard. See the
> release
> >>> notes [1] for a list of the new features and bugs fixed.
> >>>
> >>> IMPORTANT NOTE: If you're upgrading from a previous version, please
> update
> >>> ovirt-release to the latest version (10) and verify you have the
> correct
> >>> repositories enabled by running the following commands
> >>>
> >>> # yum update ovirt-release
> >>> # yum repolist enabled
> >>>
> >>> before upgrading with the usual procedure. You should see the
> ovirt-3.3.2 and
> >>> ovirt-stable repositories listed in the output of the repolist command.
> >>>
> >>>
> >>>
> >>> [1] http://www.ovirt.org/OVirt_3.3.2_release_notes
> >>>
> >> _______________________________________________
> >> 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/20131221/71fe177c/attachment.html>

From nthomas at redhat.com  Sun Dec 22 18:49:59 2013
From: nthomas at redhat.com (Nishanth Thomas)
Date: Mon, 23 Dec 2013 00:19:59 +0530
Subject: Nagios Integration Feature
Message-ID: <52B73457.9090601@redhat.com>

Hi All,

A new feature page has been published for feature "Nagios Integation"
http://www.ovirt.org/Features/Nagios_Integration

Please review the and share your feedback.

Thanks,
Nishanth
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20131223/3efa3d11/attachment.html>

From sbonazzo at redhat.com  Mon Dec 23 06:56:55 2013
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Mon, 23 Dec 2013 07:56:55 +0100
Subject: oVirt 3.3.2 release
In-Reply-To: <52B46F10.5000005@doolittle.us.com>
References: <52B2FCC1.7030206@redhat.com>	 <52B46C58.6000701@doolittle.us.com>
	<1387556033.12243.0.camel@fdeutsch-laptop.local>
	<52B46F10.5000005@doolittle.us.com>
Message-ID: <52B7DEB7.6080801@redhat.com>

Il 20/12/2013 17:23, Bob Doolittle ha scritto:
> I think the problem may be other than I indicated, however, because I don't see ovirt-engine-3.3.2 in the FC19 stable repo either. Here's the error
> output of my update command:
> 
> Error: Package: ovirt-engine-3.3.1-2.el6.noarch (@ovirt-stable)
>            Requires: ovirt-engine-websocket-proxy = 3.3.1-2.el6
>            Removing: ovirt-engine-websocket-proxy-3.3.1-2.el6.noarch (@ovirt-stable)
>                ovirt-engine-websocket-proxy = 3.3.1-2.el6
>            Updated By: ovirt-engine-websocket-proxy-3.3.2-1.el6.noarch (ovirt-3.3.2)
>                ovirt-engine-websocket-proxy = 3.3.2-1.el6
>            Available: ovirt-engine-websocket-proxy-3.3.0-3.el6.noarch (ovirt-stable)
>                ovirt-engine-websocket-proxy = 3.3.0-3.el6
>            Available: ovirt-engine-websocket-proxy-3.3.0-4.el6.noarch (ovirt-stable)
>                ovirt-engine-websocket-proxy = 3.3.0-4.el6
>            Available: ovirt-engine-websocket-proxy-3.3.0.1-1.el6.noarch (ovirt-stable)
>                ovirt-engine-websocket-proxy = 3.3.0.1-1.el6
>            Available: ovirt-engine-websocket-proxy-3.3.1-1.el6.noarch (ovirt-stable)
>                ovirt-engine-websocket-proxy = 3.3.1-1.el6


This is a bug in ovirt-engine-3.3.1 dependencies fixed in 3.3.2
(Bug 1033629 - Unable to run regular yum update due to implicit (undeclared) version lock on rhevm-websocket-proxy )
please follow upgrade path as in release notes:

# yum update ovirt-release
# yum repolist enabled
# yum update ovirt-engine-setup
# engine-setup





> 
> I have attached my current repo config, after the update of ovirt-release-el6-10-1
> 
> I'm not sure why it's not seeing http://resources.ovirt.org/releases/3.3.2/rpm/EL/6/noarch/ovirt-engine-3.3.2-1.el6.noarch.rpm
> 
> I do see that repository enabled in "yum repolist enabled" output.
> 
> -Bob
> 
> On 12/20/2013 11:13 AM, Fabian Deutsch wrote:
>> Am Freitag, den 20.12.2013, 11:12 -0500 schrieb Bob Doolittle:
>>> I can't do an update of Engine for RHEL 6.
>>>
>>> The 3.3.2 packages do not seem to have been pushed here:
>>>
>>> http://resources.ovirt.org/releases/stable/rpm/EL/6/noarch/
>> Thanks - I observed the same.
>>
>> - fabian
>>
>>> -Bob
>>>
>>> On 12/19/2013 09:03 AM, Sandro Bonazzola wrote:
>>>> The oVirt development team is very happy to announce the general
>>>> availability of oVirt 3.3.2 as of December 19th 2013. This release
>>>> solidifies oVirt as a leading KVM management application and open
>>>> source alternative to VMware vSphere.
>>>>
>>>> oVirt is available now for Fedora 19 and Red Hat Enterprise Linux 6.5
>>>> (or similar).
>>>>
>>>> This release of oVirt includes 175 bug fixes and the first release of the
>>>> Backup and Restore API, which enables backup programs to integrate with oVirt.
>>>> This release also simplifies the Guide Me VM-creation wizard. See the release
>>>> notes [1] for a list of the new features and bugs fixed.
>>>>
>>>> IMPORTANT NOTE: If you're upgrading from a previous version, please update
>>>> ovirt-release to the latest version (10) and verify you have the correct
>>>> repositories enabled by running the following commands
>>>>
>>>> # yum update ovirt-release
>>>> # yum repolist enabled
>>>>
>>>> before upgrading with the usual procedure. You should see the ovirt-3.3.2 and
>>>> ovirt-stable repositories listed in the output of the repolist command.
>>>>
>>>>
>>>>
>>>> [1] http://www.ovirt.org/OVirt_3.3.2_release_notes
>>>>
>>> _______________________________________________
>>> Arch mailing list
>>> Arch at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/arch
> 


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


From bproffit at redhat.com  Mon Dec 23 13:56:33 2013
From: bproffit at redhat.com (Brian Proffitt)
Date: Mon, 23 Dec 2013 08:56:33 -0500 (EST)
Subject: [CFP] OSCON CFP Open Through Jan. 30, 2014
In-Reply-To: <1227461472.7273281.1387806319019.JavaMail.root@redhat.com>
Message-ID: <496612136.7275027.1387806993759.JavaMail.root@redhat.com>

This is a reminder that the Call for Papers for the Open Source Convention, better known as OSCON, is currently open until Jan. 30. 

http://www.oscon.com/oscon2014/public/cfp/308

oVirt community members are encouraged to participate in this major open source event in Portland, OR, USA on July 20-24, 2014. If you need help on
phrasing the proposal abstract, or figuring out the scope of your topic, please do not hesitate to contact myself or Dave Neary for assistance.

OSCON is a great opportunity to meet fellow engineers in the oVirt community, and beyond, as well as a chance to get oVirt front and center in the minds of potential users and contributors!

Peace,
BKP


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


From iheim at redhat.com  Sun Dec 15 17:27:42 2013
From: iheim at redhat.com (Itamar Heim)
Date: Sun, 15 Dec 2013 17:27:42 -0000
Subject: domain name for a glance.ovirt.org
In-Reply-To: <1001459980.42293014.1387095864850.JavaMail.root@redhat.com>
References: <1001459980.42293014.1387095864850.JavaMail.root@redhat.com>
Message-ID: <52ADE689.7000704@redhat.com>

On 12/15/2013 10:24 AM, Oved Ourfalli wrote:
> Hi
>
> I'd like to work on a public glance repo to be used with oVirt.
> I'll need a domain name for that I guess, I guess glance.ovirt.org is the best choice.
>
> How can I get this domain name?
> What details do you need from me?
>
> Thank you,
> Oved
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
>

moving this to infra mailing list.