From didi at redhat.com  Tue Nov 12 11:38:40 2013
From: didi at redhat.com (Yedidyah Bar David)
Date: Tue, 12 Nov 2013 06:38:40 -0500 (EST)
Subject: Migrating an existing installation to hosted engine
In-Reply-To: <292728432.29929102.1384255154815.JavaMail.root@redhat.com>
Message-ID: <1599883010.29941308.1384256320402.JavaMail.root@redhat.com>

Hi all,

A message with the same subject was sent to arch around a month ago, see [1].

In short, it suggested two approaches:
1. Use p2v (or v2v)
2. Clean install of OS/engine software and use backup/restore.

Following that, I pushed a few changes for engine-backup and engine-setup,
with the intention of doing, briefly:
1. hosted-engine --deploy on new host
2. Install OS/software on new vm
3. backup on old engine machine
4. On new vm, do restore, which only restores the database and files,
followed by engine-setup, which will fix whatever else needs to be fixed.

Some of the changes are still pending, and are under some controversy. See
[2], [3], [4].

A more detailed description of the suggested migration path is in [5].

What do you think?

Should engine-setup do as little as possible to the system, or as much as
needed to save the admin from any manual work?

Should engine-setup doing an upgrade do the same as a new setup, or just
whatever that's needed to adapt the config/database to the new code?

A specific example: if admin chose during initial setup to automatically
configure the firewall (iptables/firewalld), should upgrade update it again,
or not touch it?

Should engine-backup do all these things when doing a restore?

Should we have some other utility to do these things?

Should we merely document them and let the admin do this manually?

[1] http://lists.ovirt.org/pipermail/arch/2013-October/001677.html
[2] https://bugzilla.redhat.com/1024707
[3] http://gerrit.ovirt.org/20736
[4] http://gerrit.ovirt.org/20737
[5] http://www.ovirt.org/Migrate_to_Hosted_Engine
-- 
Didi


From michal.skrivanek at redhat.com  Wed Nov 13 14:15:02 2013
From: michal.skrivanek at redhat.com (Michal Skrivanek)
Date: Wed, 13 Nov 2013 15:15:02 +0100
Subject: [Engine-devel] Migrating an existing installation to hosted engine
In-Reply-To: <1599883010.29941308.1384256320402.JavaMail.root@redhat.com>
References: <1599883010.29941308.1384256320402.JavaMail.root@redhat.com>
Message-ID: <F5849D0C-E529-494F-BA68-8168582FDB7D@redhat.com>


On Nov 12, 2013, at 12:38 , Yedidyah Bar David <didi at redhat.com> wrote:

> Hi all,
> 
> A message with the same subject was sent to arch around a month ago, see [1].
> 
> In short, it suggested two approaches:
> 1. Use p2v (or v2v)
> 2. Clean install of OS/engine software and use backup/restore.
> 
> Following that, I pushed a few changes for engine-backup and engine-setup,
> with the intention of doing, briefly:
> 1. hosted-engine --deploy on new host
> 2. Install OS/software on new vm
> 3. backup on old engine machine
> 4. On new vm, do restore, which only restores the database and files,
> followed by engine-setup, which will fix whatever else needs to be fixed.
> 
> Some of the changes are still pending, and are under some controversy. See
> [2], [3], [4].
> 
> A more detailed description of the suggested migration path is in [5].
> 
> What do you think?
> 
> Should engine-setup do as little as possible to the system, or as much as
> needed to save the admin from any manual work?
> 
> Should engine-setup doing an upgrade do the same as a new setup, or just
> whatever that's needed to adapt the config/database to the new code?
> 
> A specific example: if admin chose during initial setup to automatically
> configure the firewall (iptables/firewalld), should upgrade update it again,
> or not touch it?
> 
> Should engine-backup do all these things when doing a restore?

I think using the same tool for both tasks(backup, migration to hosted engine) has an advantage that you only address issues (like missing item to backup/restore) once and both usecases benefit from a fix

> 
> Should we have some other utility to do these things?
> 
> Should we merely document them and let the admin do this manually?
> 
> [1] http://lists.ovirt.org/pipermail/arch/2013-October/001677.html
> [2] https://bugzilla.redhat.com/1024707
> [3] http://gerrit.ovirt.org/20736
> [4] http://gerrit.ovirt.org/20737
> [5] http://www.ovirt.org/Migrate_to_Hosted_Engine
> -- 
> Didi
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From r.koch at ovido.at  Wed Nov 13 14:27:51 2013
From: r.koch at ovido.at (=?ISO-8859-1?Q?Ren=E9?= Koch (ovido))
Date: Wed, 13 Nov 2013 15:27:51 +0100
Subject: [Users] oVirt 3.4 planning
In-Reply-To: <526FF491.5000204@redhat.com>
References: <526FF491.5000204@redhat.com>
Message-ID: <1384352871.22934.55.camel@pc-ovido02.lan.ovido.at>

Hi,

There are 2 features I can maybe add to existing projects of mine
(check_rhev3 and Monitoring UI-Plugin), but it would be good to know
what users require to decide if this can be done via an external
(ui)plugin or if this needs to be integrated into oVirt itself.

* gluster: Monitoring (UI plugin)
What's expected here - monitoring glusterfs volumes (including
performance data) and displaying the results in your favored monitoring
solution and oVirt?

* other: Zabbix monitoring
Monitoring the oVirt environment should work with my check_rhev3 plugin
by adding it as an external check to Zabbix. I'll test this and if it's
working I'll provide a short guide on how to do it.
Displaying data/triggers in oVirt isn't possible yet with my Monitoring
UI-plugin, but on the feature list (help is welcome)...


Before I add myself to the list - can you give me more information on
the role/tasks of a testing owner? Are there more steps required then
testing a feature, getting in contact with the devel owner to fix issues
and update the oVirt BZ (and join the IRC weekly meetings)?


Regards,
Ren?



On Tue, 2013-10-29 at 19:46 +0200, Itamar Heim wrote:
> To try and improve 3.4 planning over the wiki approach in 3.3, I've 
> placed the items i collected on users list last time into a google doc[1]
> 
> now, the main thing each item needs is a requirements owner, devel owner 
> and a testing owner (well, devel owner is really needed to make it 
> happen, but all are important).
> 
> then we need an oVirt BZ for each, and for some a feature page.
> 
> I also added columns indicating if the item will require an API design 
> review and a GUI design review.
> 
> this list is just the start of course for items from it to get 
> ownership. i expect more items will be added as well, as long as they 
> have owners, etc.
> 
> the doc is public read-only, please request read-write access to be able 
> to edit it.
> 
> feel free to ask questions, etc.
> 
> Thanks,
>     Itamar
> 
> 
> [1] http://bit.ly/17qBn6F
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users



From iheim at redhat.com  Wed Nov 13 14:50:24 2013
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 13 Nov 2013 09:50:24 -0500
Subject: [Users] oVirt 3.4 planning
In-Reply-To: <1384352871.22934.55.camel@pc-ovido02.lan.ovido.at>
References: <526FF491.5000204@redhat.com>
	<1384352871.22934.55.camel@pc-ovido02.lan.ovido.at>
Message-ID: <528391B0.5010508@redhat.com>

On 11/13/2013 09:27 AM, Ren? Koch (ovido) wrote:
> Hi,
>
> There are 2 features I can maybe add to existing projects of mine
> (check_rhev3 and Monitoring UI-Plugin), but it would be good to know
> what users require to decide if this can be done via an external
> (ui)plugin or if this needs to be integrated into oVirt itself.
>
> * gluster: Monitoring (UI plugin)
> What's expected here - monitoring glusterfs volumes (including
> performance data) and displaying the results in your favored monitoring
> solution and oVirt?

vijay/dpati/sahina - thoughts on this one?

>
> * other: Zabbix monitoring
> Monitoring the oVirt environment should work with my check_rhev3 plugin
> by adding it as an external check to Zabbix. I'll test this and if it's
> working I'll provide a short guide on how to do it.
> Displaying data/triggers in oVirt isn't possible yet with my Monitoring
> UI-plugin, but on the feature list (help is welcome)...
>
>
> Before I add myself to the list - can you give me more information on
> the role/tasks of a testing owner? Are there more steps required then
> testing a feature, getting in contact with the devel owner to fix issues
> and update the oVirt BZ (and join the IRC weekly meetings)?

communicate with the other two owner on scope of what to test, then when 
feature is ready - test it, open bugs, and communicate if too broken to 
be considered in the version, etc.

>
>
> Regards,
> Ren?
>
>
>
> On Tue, 2013-10-29 at 19:46 +0200, Itamar Heim wrote:
>> To try and improve 3.4 planning over the wiki approach in 3.3, I've
>> placed the items i collected on users list last time into a google doc[1]
>>
>> now, the main thing each item needs is a requirements owner, devel owner
>> and a testing owner (well, devel owner is really needed to make it
>> happen, but all are important).
>>
>> then we need an oVirt BZ for each, and for some a feature page.
>>
>> I also added columns indicating if the item will require an API design
>> review and a GUI design review.
>>
>> this list is just the start of course for items from it to get
>> ownership. i expect more items will be added as well, as long as they
>> have owners, etc.
>>
>> the doc is public read-only, please request read-write access to be able
>> to edit it.
>>
>> feel free to ask questions, etc.
>>
>> Thanks,
>>      Itamar
>>
>>
>> [1] http://bit.ly/17qBn6F
>> _______________________________________________
>> Users mailing list
>> Users at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>



From sabose at redhat.com  Wed Nov 13 15:20:25 2013
From: sabose at redhat.com (Sahina Bose)
Date: Wed, 13 Nov 2013 20:50:25 +0530
Subject: [Users] oVirt 3.4 planning
In-Reply-To: <528391B0.5010508@redhat.com>
References: <526FF491.5000204@redhat.com>
	<1384352871.22934.55.camel@pc-ovido02.lan.ovido.at>
	<528391B0.5010508@redhat.com>
Message-ID: <528398B9.2060403@redhat.com>


On 11/13/2013 08:20 PM, Itamar Heim wrote:
> On 11/13/2013 09:27 AM, Ren? Koch (ovido) wrote:
>> Hi,
>>
>> There are 2 features I can maybe add to existing projects of mine
>> (check_rhev3 and Monitoring UI-Plugin), but it would be good to know
>> what users require to decide if this can be done via an external
>> (ui)plugin or if this needs to be integrated into oVirt itself.
>>
>> * gluster: Monitoring (UI plugin)
>> What's expected here - monitoring glusterfs volumes (including
>> performance data) and displaying the results in your favored monitoring
>> solution and oVirt?
>
> vijay/dpati/sahina - thoughts on this one?
At a high level,

Monitoring of volume
Storage metrics - capacity, network, CPU, disk utilization
Detecting split-brain/self-heal activity

Vijay/Dusmant - please add.

>
>>
>> * other: Zabbix monitoring
>> Monitoring the oVirt environment should work with my check_rhev3 plugin
>> by adding it as an external check to Zabbix. I'll test this and if it's
>> working I'll provide a short guide on how to do it.
>> Displaying data/triggers in oVirt isn't possible yet with my Monitoring
>> UI-plugin, but on the feature list (help is welcome)...
>>
>>
>> Before I add myself to the list - can you give me more information on
>> the role/tasks of a testing owner? Are there more steps required then
>> testing a feature, getting in contact with the devel owner to fix issues
>> and update the oVirt BZ (and join the IRC weekly meetings)?
>
> communicate with the other two owner on scope of what to test, then 
> when feature is ready - test it, open bugs, and communicate if too 
> broken to be considered in the version, etc.
>
>>
>>
>> Regards,
>> Ren?
>>
>>
>>
>> On Tue, 2013-10-29 at 19:46 +0200, Itamar Heim wrote:
>>> To try and improve 3.4 planning over the wiki approach in 3.3, I've
>>> placed the items i collected on users list last time into a google 
>>> doc[1]
>>>
>>> now, the main thing each item needs is a requirements owner, devel 
>>> owner
>>> and a testing owner (well, devel owner is really needed to make it
>>> happen, but all are important).
>>>
>>> then we need an oVirt BZ for each, and for some a feature page.
>>>
>>> I also added columns indicating if the item will require an API design
>>> review and a GUI design review.
>>>
>>> this list is just the start of course for items from it to get
>>> ownership. i expect more items will be added as well, as long as they
>>> have owners, etc.
>>>
>>> the doc is public read-only, please request read-write access to be 
>>> able
>>> to edit it.
>>>
>>> feel free to ask questions, etc.
>>>
>>> Thanks,
>>>      Itamar
>>>
>>>
>>> [1] http://bit.ly/17qBn6F
>>> _______________________________________________
>>> Users mailing list
>>> Users at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/users
>>
>



From iheim at redhat.com  Wed Nov 13 15:23:25 2013
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 13 Nov 2013 10:23:25 -0500
Subject: [Users] oVirt 3.4 planning
In-Reply-To: <528398B9.2060403@redhat.com>
References: <526FF491.5000204@redhat.com>
	<1384352871.22934.55.camel@pc-ovido02.lan.ovido.at>
	<528391B0.5010508@redhat.com> <528398B9.2060403@redhat.com>
Message-ID: <5283996D.50401@redhat.com>

On 11/13/2013 10:20 AM, Sahina Bose wrote:
>
> On 11/13/2013 08:20 PM, Itamar Heim wrote:
>> On 11/13/2013 09:27 AM, Ren? Koch (ovido) wrote:
>>> Hi,
>>>
>>> There are 2 features I can maybe add to existing projects of mine
>>> (check_rhev3 and Monitoring UI-Plugin), but it would be good to know
>>> what users require to decide if this can be done via an external
>>> (ui)plugin or if this needs to be integrated into oVirt itself.
>>>
>>> * gluster: Monitoring (UI plugin)
>>> What's expected here - monitoring glusterfs volumes (including
>>> performance data) and displaying the results in your favored monitoring
>>> solution and oVirt?
>>
>> vijay/dpati/sahina - thoughts on this one?
> At a high level,
>
> Monitoring of volume
> Storage metrics - capacity, network, CPU, disk utilization
> Detecting split-brain/self-heal activity

would help specyfing which REST API calls are involved.

>
> Vijay/Dusmant - please add.
>
>>
>>>
>>> * other: Zabbix monitoring
>>> Monitoring the oVirt environment should work with my check_rhev3 plugin
>>> by adding it as an external check to Zabbix. I'll test this and if it's
>>> working I'll provide a short guide on how to do it.
>>> Displaying data/triggers in oVirt isn't possible yet with my Monitoring
>>> UI-plugin, but on the feature list (help is welcome)...
>>>
>>>
>>> Before I add myself to the list - can you give me more information on
>>> the role/tasks of a testing owner? Are there more steps required then
>>> testing a feature, getting in contact with the devel owner to fix issues
>>> and update the oVirt BZ (and join the IRC weekly meetings)?
>>
>> communicate with the other two owner on scope of what to test, then
>> when feature is ready - test it, open bugs, and communicate if too
>> broken to be considered in the version, etc.
>>
>>>
>>>
>>> Regards,
>>> Ren?
>>>
>>>
>>>
>>> On Tue, 2013-10-29 at 19:46 +0200, Itamar Heim wrote:
>>>> To try and improve 3.4 planning over the wiki approach in 3.3, I've
>>>> placed the items i collected on users list last time into a google
>>>> doc[1]
>>>>
>>>> now, the main thing each item needs is a requirements owner, devel
>>>> owner
>>>> and a testing owner (well, devel owner is really needed to make it
>>>> happen, but all are important).
>>>>
>>>> then we need an oVirt BZ for each, and for some a feature page.
>>>>
>>>> I also added columns indicating if the item will require an API design
>>>> review and a GUI design review.
>>>>
>>>> this list is just the start of course for items from it to get
>>>> ownership. i expect more items will be added as well, as long as they
>>>> have owners, etc.
>>>>
>>>> the doc is public read-only, please request read-write access to be
>>>> able
>>>> to edit it.
>>>>
>>>> feel free to ask questions, etc.
>>>>
>>>> Thanks,
>>>>      Itamar
>>>>
>>>>
>>>> [1] http://bit.ly/17qBn6F
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/users
>>>
>>
>



From sabose at redhat.com  Wed Nov 13 15:35:48 2013
From: sabose at redhat.com (Sahina Bose)
Date: Wed, 13 Nov 2013 21:05:48 +0530
Subject: [Users] oVirt 3.4 planning
In-Reply-To: <5283996D.50401@redhat.com>
References: <526FF491.5000204@redhat.com>
	<1384352871.22934.55.camel@pc-ovido02.lan.ovido.at>
	<528391B0.5010508@redhat.com> <528398B9.2060403@redhat.com>
	<5283996D.50401@redhat.com>
Message-ID: <52839C54.6000605@redhat.com>


On 11/13/2013 08:53 PM, Itamar Heim wrote:
> On 11/13/2013 10:20 AM, Sahina Bose wrote:
>>
>> On 11/13/2013 08:20 PM, Itamar Heim wrote:
>>> On 11/13/2013 09:27 AM, Ren? Koch (ovido) wrote:
>>>> Hi,
>>>>
>>>> There are 2 features I can maybe add to existing projects of mine
>>>> (check_rhev3 and Monitoring UI-Plugin), but it would be good to know
>>>> what users require to decide if this can be done via an external
>>>> (ui)plugin or if this needs to be integrated into oVirt itself.
>>>>
>>>> * gluster: Monitoring (UI plugin)
>>>> What's expected here - monitoring glusterfs volumes (including
>>>> performance data) and displaying the results in your favored 
>>>> monitoring
>>>> solution and oVirt?
>>>
>>> vijay/dpati/sahina - thoughts on this one?
>> At a high level,
>>
>> Monitoring of volume
>> Storage metrics - capacity, network, CPU, disk utilization
>> Detecting split-brain/self-heal activity
>
> would help specyfing which REST API calls are involved.

Hmm.. would monitoring work on top of engine via REST API calls? I was 
thinking more in line of monitoring the nodes directly - maybe a push 
mechanism from nodes.

>
>>
>> Vijay/Dusmant - please add.
>>
>>>
>>>>
>>>> * other: Zabbix monitoring
>>>> Monitoring the oVirt environment should work with my check_rhev3 
>>>> plugin
>>>> by adding it as an external check to Zabbix. I'll test this and if 
>>>> it's
>>>> working I'll provide a short guide on how to do it.
>>>> Displaying data/triggers in oVirt isn't possible yet with my 
>>>> Monitoring
>>>> UI-plugin, but on the feature list (help is welcome)...
>>>>
>>>>
>>>> Before I add myself to the list - can you give me more information on
>>>> the role/tasks of a testing owner? Are there more steps required then
>>>> testing a feature, getting in contact with the devel owner to fix 
>>>> issues
>>>> and update the oVirt BZ (and join the IRC weekly meetings)?
>>>
>>> communicate with the other two owner on scope of what to test, then
>>> when feature is ready - test it, open bugs, and communicate if too
>>> broken to be considered in the version, etc.
>>>
>>>>
>>>>
>>>> Regards,
>>>> Ren?
>>>>
>>>>
>>>>
>>>> On Tue, 2013-10-29 at 19:46 +0200, Itamar Heim wrote:
>>>>> To try and improve 3.4 planning over the wiki approach in 3.3, I've
>>>>> placed the items i collected on users list last time into a google
>>>>> doc[1]
>>>>>
>>>>> now, the main thing each item needs is a requirements owner, devel
>>>>> owner
>>>>> and a testing owner (well, devel owner is really needed to make it
>>>>> happen, but all are important).
>>>>>
>>>>> then we need an oVirt BZ for each, and for some a feature page.
>>>>>
>>>>> I also added columns indicating if the item will require an API 
>>>>> design
>>>>> review and a GUI design review.
>>>>>
>>>>> this list is just the start of course for items from it to get
>>>>> ownership. i expect more items will be added as well, as long as they
>>>>> have owners, etc.
>>>>>
>>>>> the doc is public read-only, please request read-write access to be
>>>>> able
>>>>> to edit it.
>>>>>
>>>>> feel free to ask questions, etc.
>>>>>
>>>>> Thanks,
>>>>>      Itamar
>>>>>
>>>>>
>>>>> [1] http://bit.ly/17qBn6F
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users at ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/users
>>>>
>>>
>>
>



From r.koch at ovido.at  Wed Nov 13 17:17:09 2013
From: r.koch at ovido.at (=?ISO-8859-1?Q?Ren=E9?= Koch (ovido))
Date: Wed, 13 Nov 2013 18:17:09 +0100
Subject: [Users] oVirt 3.4 planning
In-Reply-To: <52839C54.6000605@redhat.com>
References: <526FF491.5000204@redhat.com>
	<1384352871.22934.55.camel@pc-ovido02.lan.ovido.at>
	<528391B0.5010508@redhat.com> <528398B9.2060403@redhat.com>
	<5283996D.50401@redhat.com> <52839C54.6000605@redhat.com>
Message-ID: <1384363029.22934.80.camel@pc-ovido02.lan.ovido.at>

On Wed, 2013-11-13 at 21:05 +0530, Sahina Bose wrote:
> On 11/13/2013 08:53 PM, Itamar Heim wrote:
> > On 11/13/2013 10:20 AM, Sahina Bose wrote:
> >>
> >> On 11/13/2013 08:20 PM, Itamar Heim wrote:
> >>> On 11/13/2013 09:27 AM, Ren? Koch (ovido) wrote:
> >>>> Hi,
> >>>>
> >>>> There are 2 features I can maybe add to existing projects of mine
> >>>> (check_rhev3 and Monitoring UI-Plugin), but it would be good to know
> >>>> what users require to decide if this can be done via an external
> >>>> (ui)plugin or if this needs to be integrated into oVirt itself.
> >>>>
> >>>> * gluster: Monitoring (UI plugin)
> >>>> What's expected here - monitoring glusterfs volumes (including
> >>>> performance data) and displaying the results in your favored 
> >>>> monitoring
> >>>> solution and oVirt?
> >>>
> >>> vijay/dpati/sahina - thoughts on this one?
> >> At a high level,
> >>
> >> Monitoring of volume
> >> Storage metrics - capacity, network, CPU, disk utilization
> >> Detecting split-brain/self-heal activity
> >
> > would help specyfing which REST API calls are involved.
> 
> Hmm.. would monitoring work on top of engine via REST API calls? I was 
> thinking more in line of monitoring the nodes directly - maybe a push 
> mechanism from nodes.


The advantage of monitoring via REST-API is that you don't need an
agent/script installed on the host/node. Especially for oVirt node I
think this is a huge advantage (haven't looked into 3rd party plugin
support yet).

The downside of it is that if REST-API isn't available (e.g. due to
engine maintenance jobs) you can't monitor your environment...

Especially for Nagios both options are valid - gathering data from
REST-API or directly from the host. Other monitoring solutions may
require an agent (or maybe snmp) on the host if data aren't available
via REST-API...


> 
> >
> >>
> >> Vijay/Dusmant - please add.
> >>
> >>>
> >>>>
> >>>> * other: Zabbix monitoring
> >>>> Monitoring the oVirt environment should work with my check_rhev3 
> >>>> plugin
> >>>> by adding it as an external check to Zabbix. I'll test this and if 
> >>>> it's
> >>>> working I'll provide a short guide on how to do it.
> >>>> Displaying data/triggers in oVirt isn't possible yet with my 
> >>>> Monitoring
> >>>> UI-plugin, but on the feature list (help is welcome)...
> >>>>
> >>>>
> >>>> Before I add myself to the list - can you give me more information on
> >>>> the role/tasks of a testing owner? Are there more steps required then
> >>>> testing a feature, getting in contact with the devel owner to fix 
> >>>> issues
> >>>> and update the oVirt BZ (and join the IRC weekly meetings)?
> >>>
> >>> communicate with the other two owner on scope of what to test, then
> >>> when feature is ready - test it, open bugs, and communicate if too
> >>> broken to be considered in the version, etc.
> >>>
> >>>>
> >>>>
> >>>> Regards,
> >>>> Ren?
> >>>>
> >>>>
> >>>>
> >>>> On Tue, 2013-10-29 at 19:46 +0200, Itamar Heim wrote:
> >>>>> To try and improve 3.4 planning over the wiki approach in 3.3, I've
> >>>>> placed the items i collected on users list last time into a google
> >>>>> doc[1]
> >>>>>
> >>>>> now, the main thing each item needs is a requirements owner, devel
> >>>>> owner
> >>>>> and a testing owner (well, devel owner is really needed to make it
> >>>>> happen, but all are important).
> >>>>>
> >>>>> then we need an oVirt BZ for each, and for some a feature page.
> >>>>>
> >>>>> I also added columns indicating if the item will require an API 
> >>>>> design
> >>>>> review and a GUI design review.
> >>>>>
> >>>>> this list is just the start of course for items from it to get
> >>>>> ownership. i expect more items will be added as well, as long as they
> >>>>> have owners, etc.
> >>>>>
> >>>>> the doc is public read-only, please request read-write access to be
> >>>>> able
> >>>>> to edit it.
> >>>>>
> >>>>> feel free to ask questions, etc.
> >>>>>
> >>>>> Thanks,
> >>>>>      Itamar
> >>>>>
> >>>>>
> >>>>> [1] http://bit.ly/17qBn6F
> >>>>> _______________________________________________
> >>>>> Users mailing list
> >>>>> Users at ovirt.org
> >>>>> http://lists.ovirt.org/mailman/listinfo/users
> >>>>
> >>>
> >>
> >
> 



From sander at grendelman.com  Wed Nov 13 14:46:36 2013
From: sander at grendelman.com (Sander Grendelman)
Date: Wed, 13 Nov 2013 15:46:36 +0100
Subject: [Users] oVirt 3.4 planning
In-Reply-To: <1384352871.22934.55.camel@pc-ovido02.lan.ovido.at>
References: <526FF491.5000204@redhat.com>
	<1384352871.22934.55.camel@pc-ovido02.lan.ovido.at>
Message-ID: <CAHa6cRTz_EMY4CwnmUTuLqvTCCDvg1qe9MgcjBwWTLWMWUPBqg@mail.gmail.com>

> * other: Zabbix monitoring
> Monitoring the oVirt environment should work with my check_rhev3 plugin
> by adding it as an external check to Zabbix. I'll test this and if it's
> working I'll provide a short guide on how to do it.
> Displaying data/triggers in oVirt isn't possible yet with my Monitoring
> UI-plugin, but on the feature list (help is welcome)...

I'm very interested in this Zabbix plugin/check, was thinking about implementing
something myself.


From iheim at redhat.com  Mon Nov 18 11:47:50 2013
From: iheim at redhat.com (Itamar Heim)
Date: Mon, 18 Nov 2013 13:47:50 +0200
Subject: oVirt 3.3.1 RC
In-Reply-To: <5289CF69.2050104@redhat.com>
References: <5289CF69.2050104@redhat.com>
Message-ID: <5289FE66.2010400@redhat.com>

On 11/18/2013 10:27 AM, Sandro Bonazzola wrote:
> The oVirt team is pleased to announce that the 3.3.1 Release candidate is now
> available in beta [1] and will be released on Tue Nov 19th 2013 if no other blockers
> will be found while we're testing it [2].
> Feel free to join us 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/beta
> [2] http://www.ovirt.org/Testing/Ovirt_3.3.1_testing
> [3] http://red.ht/1gQAdEo
> [4] http://www.ovirt.org/OVirt_3.3.1_release_notes
>
>

next time, I'd send to announce and users mailing lists.


From dneary at redhat.com  Wed Nov 20 11:30:46 2013
From: dneary at redhat.com (Dave Neary)
Date: Wed, 20 Nov 2013 12:30:46 +0100
Subject: CfP: Virtualisation and IaaS DevRoom at FOSDEM'14
In-Reply-To: <5266E624.3050506@redhat.com>
References: <5266E624.3050506@redhat.com>
Message-ID: <528C9D66.3020001@redhat.com>

Hi,

A reminder to everyone, we're getting close to the deadline! I would
love to see some dev/DevOps-focussed presentations about oVirt at the
conference. Again, I would love to see some oVirt users propose topics
about how the use, manage and deploy oVirt in real life circumstances.

Some ideas I think might get in, if you've done any of these and are
interested in presenting, let me know:

* Using Foreman/Puppet/Ansible/... with the oVirt APIs & CLI to
orchestrate & provision VMs on oVirt
* Using oVirt for VDI
* Migrating from vSphere to oVirt
* Using VDSM hooks and scripts to tweak VM lifecycle management
* Storage - how to add a new storage engine type to oVirt (using
libgfapi support as an example, perhaps?)

Thanks!
Dave.

On 10/22/2013 10:55 PM, Itamar Heim wrote:
> https://groups.google.com/forum/#!forum/fosdem14-virt-and-iaas-devroom
> 
> Call for Participation
> 
> The scope for this devroom is open source, openly-developed projects in
> the areas of virtualisation and IaaS type clouds, ranging from low level
> to data center, up to cloud management platforms and cloud resource
> orchestration.
> 
> Sessions should always target a developer audience. Bonus points for
> collaborative sessions that would be appealing to developers from
> multiple projects.
> 
> We are particularly interested in the following themes:
> - low level virtualisation aspects
> - new features in classic and container-based virtualisation
>   technologies
> - new use cases for virtualisation, such as virtualisation in mobile,
>   automotive and embedded in general
> - other resource virtualisation technologies: networking, storage, ?
> - deep technical dives into specific IaaS or virtualisation management
>   projects features
> - relationship between IaaS projects and specific dependencies (not
>   just virtualisation)
> - integration and development leveraging solutions from multiple
>   projects
> 
> Important dates
>   Submission deadline: Sunday, December 1st, 2013
>   Acceptance notifications: Sunday, December 15th, 2013
>   Final schedule announcement: Friday January 10th, 2014
>   Devroom @ FOSDEM'14: February 1st & 2nd, 2014
> 
> Practical
> 
> Submissions should be 40 minutes, and consist of a 30 minute
> presentation with 10 minutes of Q&A or 40 minutes of discussions (e.g.,
> requests for feedback, open discussions, etc.). Interactivity is
> encouraged, but optional. Talks are in English only.
> 
> We do not provide travel assistance or reimbursement of travel expenses
> for accepted speakers.
> 
> Submissions should be made via the FOSDEM submission page at
> https://penta.fosdem.org/submission/FOSDEM14 :
> - If necessary, create a Pentabarf account and activate it
> - In the ?Person? section, provide First name, Last name (in the
>   ?General? tab), Email (in the ?Contact? tab) and Bio (?Abstract?
>   field in the ?Description? tab)
> - Submit a proposal by clicking on ?Create event"
> - Important! Select the "Virtualisation and IaaS" track (on the
>   ?General? tab)
> - Provide the title of your talk (?Event title? in the ?General? tab)
> - Provide a 250-word description of the subject of the talk and the
>   intended audience (in the ?Abstract? field of the ?Description? tab)
> - Provide a rough outline of the talk or goals of the session (a short
>   list of bullet points covering topics that will be discussed) in the
>   ?Full description? field in the ?Description? tab
> 
> Contact
> 
> For questions w.r.t. the Virtualisation and IaaS DevRoom at FOSDEM'14,
> please contact the organizers via
> fosdem14-virt-and-iaas-devroom at googlegroups.com (or via
> https://groups.google.com/forum/#!forum/fosdem14-virt-and-iaas-devroom).
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch

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


From iheim at redhat.com  Thu Nov 21 11:10:01 2013
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 21 Nov 2013 13:10:01 +0200
Subject: 3.4 planning sheet
Message-ID: <528DEA09.3010605@redhat.com>

Just an update:
All feature requests which did not have a devel owner were moved to a 
separate sheet.

 From experience, not all features with a devel owner make the version, 
and some more items will probably get devel owners over the next couple 
of weeks.

Thanks,
    itamar


From kiril at redhat.com  Thu Nov 21 15:43:41 2013
From: kiril at redhat.com (Kiril Nesenko)
Date: Thu, 21 Nov 2013 10:43:41 -0500 (EST)
Subject: oVirt 3.3.1 rlease
In-Reply-To: <708970996.5979108.1385048574899.JavaMail.root@redhat.com>
Message-ID: <1838374536.5979660.1385048621587.JavaMail.root@redhat.com>

The oVirt development team is very happy to announce the general
availability of oVirt 3.3.1 as of November 21th 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.4
(or similar).

See release notes [1] for a list of the new features and bug fixed.

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

- Kiril



From sbonazzo at redhat.com  Thu Nov 21 15:49:53 2013
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Thu, 21 Nov 2013 10:49:53 -0500 (EST)
Subject: oVirt 3.4 planning - integration features review
Message-ID: <809012808.20375446.1385048992995.JavaMail.root@redhat.com>

The following is a new meeting request:

Subject: oVirt 3.4 planning - integration features review 
Organizer: "Sandro Bonazzola" <sbonazzo at redhat.com> 

Location: #ovirt IRC channel 
Time: Wednesday, November 27, 2013, 3:00:00 PM - 4:00:00 PM GMT +01:00 Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna
 
Invitees: users at ovirt.org; arch at ovirt.org; iheim at redhat.com; oschreib at redhat.com; obasan at redhat.com; ydary at redhat.com; didi at redhat.com; alonbl at redhat.com 


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

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

From fabiand at redhat.com  Fri Nov 22 10:41:08 2013
From: fabiand at redhat.com (Fabian Deutsch)
Date: Fri, 22 Nov 2013 11:41:08 +0100
Subject: [Users] oVirt 3.3.1 rlease
In-Reply-To: <1838374536.5979660.1385048621587.JavaMail.root@redhat.com>
References: <1838374536.5979660.1385048621587.JavaMail.root@redhat.com>
Message-ID: <1385116868.2819.3.camel@fdeutsch-laptop.local>

Am Donnerstag, den 21.11.2013, 10:43 -0500 schrieb Kiril Nesenko:
> The oVirt development team is very happy to announce the general
> availability of oVirt 3.3.1 as of November 21th 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.4
> (or similar).
> 
> See release notes [1] for a list of the new features and bug fixed.
> 
> [1] http://www.ovirt.org/OVirt_3.3.1_release_notes

Hey,

matching oVirt Node isos will be available shortly and will be announced
here.

- fabian



From lvernia at redhat.com  Mon Nov 25 06:43:01 2013
From: lvernia at redhat.com (Lior Vernia)
Date: Mon, 25 Nov 2013 08:43:01 +0200
Subject: Host Network QoS feature
Message-ID: <5292F175.6090906@redhat.com>

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

Detailed:
http://www.ovirt.org/Features/Detailed_Host_Network_QoS#Current_Status

I also refer you to a previous thread that discussed an earlier
iteration of this feature a few months ago:
http://lists.ovirt.org/pipermail/arch/2013-July/001502.html

Yours, Lior.


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

The following is a new meeting request:

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, 5:00:00 PM - 6:00:00 PM GMT +02:00 Jerusalem
 
Invitees: users at ovirt.org; arch at ovirt.org 


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

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: 2120 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20131125/74e8d5a8/attachment.ics>

From masayag at redhat.com  Mon Nov 25 15:47:14 2013
From: masayag at redhat.com (Moti Asayag)
Date: Mon, 25 Nov 2013 10:47:14 -0500 (EST)
Subject: Edit Provisioned Network Feature
In-Reply-To: <632794817.284060.1385394235753.JavaMail.root@redhat.com>
Message-ID: <260448418.286241.1385394434059.JavaMail.root@redhat.com>

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 mrao at redhat.com  Mon Nov 25 20:09:42 2013
From: mrao at redhat.com (Malini Rao)
Date: Mon, 25 Nov 2013 15:09:42 -0500 (EST)
Subject: Edit Provisioned Network Feature
In-Reply-To: <260448418.286241.1385394434059.JavaMail.root@redhat.com>
References: <260448418.286241.1385394434059.JavaMail.root@redhat.com>
Message-ID: <1700531467.30620103.1385410182683.JavaMail.root@redhat.com>

I had one question/ comment regarding the statement - "Modifying the network name is permitted, but it will not be applied to hosts. Therefore attempt to modify network name and applying it to hosts will be blocked." Does this mean that the user can change the network name by going to the networks tab but not via the host setup networks? Or does it mean that name can be overridden per host but not be applied across hosts? I am not clear what you mean when you say it is permitted but blocked from modification.

Thanks
Malini

----- Original Message -----
From: "Moti Asayag" <masayag at redhat.com>
To: "arch" <arch at ovirt.org>
Sent: Monday, November 25, 2013 10:47:14 AM
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
_______________________________________________
Arch mailing list
Arch at ovirt.org
http://lists.ovirt.org/mailman/listinfo/arch


From mkolesni at redhat.com  Tue Nov 26 05:38:43 2013
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Tue, 26 Nov 2013 00:38:43 -0500 (EST)
Subject: Edit Provisioned Network Feature
In-Reply-To: <260448418.286241.1385394434059.JavaMail.root@redhat.com>
References: <260448418.286241.1385394434059.JavaMail.root@redhat.com>
Message-ID: <693643003.40738769.1385444323311.JavaMail.root@redhat.com>

Very nice feature page, and a very good feature!

I have a couple of questions:

* Is the first part of the update command non-transactive? It's not clear from
"The 'UpdateNetworkCommand' will be changed to a non-transactive"
I would think the first part is still transactive, and the second one is not..

* How can you apply the non-VM network if VMs/vNICs are down?
I think it makes most sense to block if the network is being used to avoid
confusion (otherwise say you changed to non-VM and later some VM using the
network will always fail to launch, not sure it's a good thing).

* From REST API perspective it looks like apply is a field on the network?
If it is a field, perhaps worth saving it to DB so that it is used every time
the network is edited?
i.e. the "edit network" dialog will show this field value and this value will
also be used later to determine whether to apply on all hosts or not..

* Not sure how you plan to apply on some of the hosts, so not sure it's worth
mentioning at this point..

* You need to take into consideration the "Save network configuration" behavior
in conjunction with this feature, i.e. the changes should probably be saved.

Also a couple suggestions which are related:
* When standing on a network (in networks tab), you have the Hosts sub-tab.

** Can we have a column for the sync status?

** Can we have a button to sync to specific host (very useful when network
got applied only to some of the hosts)?

*** This also answers (IMHO) the capability to apply only to specific hosts.

Regards,
Mike

----- Original Message -----
> 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
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From masayag at redhat.com  Tue Nov 26 09:16:08 2013
From: masayag at redhat.com (Moti Asayag)
Date: Tue, 26 Nov 2013 04:16:08 -0500 (EST)
Subject: Edit Provisioned Network Feature
In-Reply-To: <1700531467.30620103.1385410182683.JavaMail.root@redhat.com>
References: <260448418.286241.1385394434059.JavaMail.root@redhat.com>
	<1700531467.30620103.1385410182683.JavaMail.root@redhat.com>
Message-ID: <1892155515.744908.1385457368092.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Malini Rao" <mrao at redhat.com>
> To: "Moti Asayag" <masayag at redhat.com>
> Cc: "arch" <arch at ovirt.org>
> Sent: Monday, November 25, 2013 10:09:42 PM
> Subject: Re: Edit Provisioned Network Feature
> 
> I had one question/ comment regarding the statement - "Modifying the network
> name is permitted, but it will not be applied to hosts. Therefore attempt to
> modify network name and applying it to hosts will be blocked." Does this
> mean that the user can change the network name by going to the networks tab
> but not via the host setup networks? 

This option isn't supported in ovirt-engine. User cannot modify the network name
via setup network. Only add/remove an existing network which is attached to the
cluster or remove unmanaged networks.

> Or does it mean that name can be
> overridden per host but not be applied across hosts? I am not clear what you
> mean when you say it is permitted but blocked from modification.
> 

The added checkbox to 'Edit Network' dialog will be used to determine if the admin
wishes to apply the network changes to all of the hosts.

The feature enhance the 'Sync network' ability of the 'Setup Network' feature to 
perform the appliance on the hosts.

If the network name is modified while it is being used on hosts, the network becomes
unmanaged on the hosts, since we identify the attached network to a host by its name.
Therefore in such case we cannot leverage the 'Sync network' to apply the network change.

When the user selects the 'apply to all hosts' new checkbox and modifies the network name,
we should block this option to reduce the complexity of this feature (at least for phase 1).

Renaming a network being used will be supported of the 'apply to all hosts' checkbox will not
be selected. It results on the network being identified as 'unmanaged' on the hosts.

> Thanks
> Malini
> 
> ----- Original Message -----
> From: "Moti Asayag" <masayag at redhat.com>
> To: "arch" <arch at ovirt.org>
> Sent: Monday, November 25, 2013 10:47:14 AM
> 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
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From masayag at redhat.com  Tue Nov 26 13:30:40 2013
From: masayag at redhat.com (Moti Asayag)
Date: Tue, 26 Nov 2013 08:30:40 -0500 (EST)
Subject: Edit Provisioned Network Feature
In-Reply-To: <693643003.40738769.1385444323311.JavaMail.root@redhat.com>
References: <260448418.286241.1385394434059.JavaMail.root@redhat.com>
	<693643003.40738769.1385444323311.JavaMail.root@redhat.com>
Message-ID: <818573927.1015594.1385472640420.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Mike Kolesnik" <mkolesni at redhat.com>
> To: "Moti Asayag" <masayag at redhat.com>
> Cc: "arch" <arch at ovirt.org>
> Sent: Tuesday, November 26, 2013 7:38:43 AM
> Subject: Re: Edit Provisioned Network Feature
> 
> Very nice feature page, and a very good feature!
> 
> I have a couple of questions:
> 
> * Is the first part of the update command non-transactive? It's not clear
> from
> "The 'UpdateNetworkCommand' will be changed to a non-transactive"
> I would think the first part is still transactive, and the second one is
> not..
> 

The scope of the transaction include updating the network in the DB and removing
its vnic profiles if network was changed from vm network to non-vm network.
The rest of the command (apply changes to host) should run with no transaction.
Therefore the command itself will be marked as @NonTransactiveCommandAttribute
and specific transaction will be opened to the described scope.

> * How can you apply the non-VM network if VMs/vNICs are down?
> I think it makes most sense to block if the network is being used to avoid
> confusion (otherwise say you changed to non-VM and later some VM using the
> network will always fail to launch, not sure it's a good thing).
> 

Agree - such change should be blocked.

> * From REST API perspective it looks like apply is a field on the network?
> If it is a field, perhaps worth saving it to DB so that it is used every time
> the network is edited?
> i.e. the "edit network" dialog will show this field value and this value will
> also be used later to determine whether to apply on all hosts or not..
> 

Since we're using the PUT method, we provide the network entity for the action,
and any additional parameter as it sub-element.
One can claim that this field which doesn't serve as a network property, rather
as an additional action to perform for the given operation. Therefore I find it
more suitable to be passed as a parameter. 

> * Not sure how you plan to apply on some of the hosts, so not sure it's worth
> mentioning at this point..
> 

It should have been marked as p2. I thought as an enhancement to the UI where
hierarchical cluster-hosts tree allows specific selection, something like:

(x) Cluster 1
    (x) host A
    ( ) host B
(x) Cluster 2
    (x) host C
    (X) host D
( ) Cluster 3
    ( ) host E

But since it is not planned for p1 we can postpone the discussion of it.

> * You need to take into consideration the "Save network configuration"
> behavior
> in conjunction with this feature, i.e. the changes should probably be saved.
> 

Indeed, the user should be aware that any non-committed changes applied to the host
will be committed once using this feature.

> Also a couple suggestions which are related:
> * When standing on a network (in networks tab), you have the Hosts sub-tab.
> 
> ** Can we have a column for the sync status?
> 
> ** Can we have a button to sync to specific host (very useful when network
> got applied only to some of the hosts)?
> 

Those are nice improvements and should get their own RFE. Could you open one
so we can prioritize and target it properly?

> *** This also answers (IMHO) the capability to apply only to specific hosts.
> 
> Regards,
> Mike
> 
> ----- Original Message -----
> > 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
> > _______________________________________________
> > Arch mailing list
> > Arch at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/arch
> > 
> 


From alonbl at redhat.com  Tue Nov 26 13:39:39 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Tue, 26 Nov 2013 08:39:39 -0500 (EST)
Subject: [Users] oVirt 3.3.1 rlease
In-Reply-To: <1838374536.5979660.1385048621587.JavaMail.root@redhat.com>
References: <1838374536.5979660.1385048621587.JavaMail.root@redhat.com>
Message-ID: <1294729297.19225102.1385473179774.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Kiril Nesenko" <kiril at redhat.com>
> To: "arch" <arch at ovirt.org>, announce at ovirt.org, users at ovirt.org
> Sent: Thursday, November 21, 2013 5:43:41 PM
> Subject: [Users] oVirt 3.3.1 rlease
> 
> The oVirt development team is very happy to announce the general
> availability of oVirt 3.3.1 as of November 21th 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.4
> (or similar).
> 
> See release notes [1] for a list of the new features and bug fixed.
> 
> [1] http://www.ovirt.org/OVirt_3.3.1_release_notes
> 
> - Kiril

Hello,

Experimental Gentoo support for ovirt-engine-3.3.1 is available[1], feedback is welcomed.

Regards,
Alon Bar-Lev.

[1] https://github.com/alonbl/ovirt-overlay


From ecohen at redhat.com  Tue Nov 26 18:45:06 2013
From: ecohen at redhat.com (Einav Cohen)
Date: Tue, 26 Nov 2013 13:45:06 -0500 (EST)
Subject: Edit Provisioned Network Feature
In-Reply-To: <818573927.1015594.1385472640420.JavaMail.root@redhat.com>
References: <260448418.286241.1385394434059.JavaMail.root@redhat.com>
	<693643003.40738769.1385444323311.JavaMail.root@redhat.com>
	<818573927.1015594.1385472640420.JavaMail.root@redhat.com>
Message-ID: <250145037.16664793.1385491506068.JavaMail.root@redhat.com>

Hi Moti, question:

what will happen if the 'Apply network change to all hosts' check-box will not be checked?
i.e. the logical network business entity and the networking configuration on the Host will 
be out of sync? do we plan to indicate that somewhere in the GUI / allow a way to "sync" 
the Hosts' networking configuration with the up-to-date logical network business entities? 

maybe it is the exact same thing that Mike asked at the end of his e-mail (not sure) and 
you mentioned that it is worthy a separate RFE; I am not sure if handling it separately 
is such a good idea - question is how important it is to indicate that a Host networking 
configuration is not sync'd with the logical network business entities (i.e. we can have 
two Hosts, one configured before the provisioned-network change and one configured after 
the provisioned-network change, and their networking configuration may seem "identical" 
even though it is not really the case). 

we can, at the first stage, decide that the 'Apply network change to all hosts' check-box 
is always checked and disabled, so Hosts would never be out of sync, or agree upon a 
similar limitation that will allow us to not need the 'sync' action / 'out of sync' 
indication immediately.

----
Thanks,
Einav

----- Original Message -----
> From: "Moti Asayag" <masayag at redhat.com>
> To: "Mike Kolesnik" <mkolesni at redhat.com>
> Cc: "arch" <arch at ovirt.org>
> Sent: Tuesday, November 26, 2013 8:30:40 AM
> Subject: Re: Edit Provisioned Network Feature
> 
> 
> 
> ----- Original Message -----
> > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > To: "Moti Asayag" <masayag at redhat.com>
> > Cc: "arch" <arch at ovirt.org>
> > Sent: Tuesday, November 26, 2013 7:38:43 AM
> > Subject: Re: Edit Provisioned Network Feature
> > 
> > Very nice feature page, and a very good feature!
> > 
> > I have a couple of questions:
> > 
> > * Is the first part of the update command non-transactive? It's not clear
> > from
> > "The 'UpdateNetworkCommand' will be changed to a non-transactive"
> > I would think the first part is still transactive, and the second one is
> > not..
> > 
> 
> The scope of the transaction include updating the network in the DB and
> removing
> its vnic profiles if network was changed from vm network to non-vm network.
> The rest of the command (apply changes to host) should run with no
> transaction.
> Therefore the command itself will be marked as
> @NonTransactiveCommandAttribute
> and specific transaction will be opened to the described scope.
> 
> > * How can you apply the non-VM network if VMs/vNICs are down?
> > I think it makes most sense to block if the network is being used to avoid
> > confusion (otherwise say you changed to non-VM and later some VM using the
> > network will always fail to launch, not sure it's a good thing).
> > 
> 
> Agree - such change should be blocked.
> 
> > * From REST API perspective it looks like apply is a field on the network?
> > If it is a field, perhaps worth saving it to DB so that it is used every
> > time
> > the network is edited?
> > i.e. the "edit network" dialog will show this field value and this value
> > will
> > also be used later to determine whether to apply on all hosts or not..
> > 
> 
> Since we're using the PUT method, we provide the network entity for the
> action,
> and any additional parameter as it sub-element.
> One can claim that this field which doesn't serve as a network property,
> rather
> as an additional action to perform for the given operation. Therefore I find
> it
> more suitable to be passed as a parameter.
> 
> > * Not sure how you plan to apply on some of the hosts, so not sure it's
> > worth
> > mentioning at this point..
> > 
> 
> It should have been marked as p2. I thought as an enhancement to the UI where
> hierarchical cluster-hosts tree allows specific selection, something like:
> 
> (x) Cluster 1
>     (x) host A
>     ( ) host B
> (x) Cluster 2
>     (x) host C
>     (X) host D
> ( ) Cluster 3
>     ( ) host E
> 
> But since it is not planned for p1 we can postpone the discussion of it.
> 
> > * You need to take into consideration the "Save network configuration"
> > behavior
> > in conjunction with this feature, i.e. the changes should probably be
> > saved.
> > 
> 
> Indeed, the user should be aware that any non-committed changes applied to
> the host
> will be committed once using this feature.
> 
> > Also a couple suggestions which are related:
> > * When standing on a network (in networks tab), you have the Hosts sub-tab.
> > 
> > ** Can we have a column for the sync status?
> > 
> > ** Can we have a button to sync to specific host (very useful when network
> > got applied only to some of the hosts)?
> > 
> 
> Those are nice improvements and should get their own RFE. Could you open one
> so we can prioritize and target it properly?
> 
> > *** This also answers (IMHO) the capability to apply only to specific
> > hosts.
> > 
> > Regards,
> > Mike
> > 
> > ----- Original Message -----
> > > 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
> > > _______________________________________________
> > > 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  Wed Nov 27 07:42:39 2013
From: masayag at redhat.com (Moti Asayag)
Date: Wed, 27 Nov 2013 02:42:39 -0500 (EST)
Subject: Edit Provisioned Network Feature
In-Reply-To: <250145037.16664793.1385491506068.JavaMail.root@redhat.com>
References: <260448418.286241.1385394434059.JavaMail.root@redhat.com>
	<693643003.40738769.1385444323311.JavaMail.root@redhat.com>
	<818573927.1015594.1385472640420.JavaMail.root@redhat.com>
	<250145037.16664793.1385491506068.JavaMail.root@redhat.com>
Message-ID: <1400856723.1809079.1385538159570.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Einav Cohen" <ecohen at redhat.com>
> To: "Moti Asayag" <masayag at redhat.com>
> Cc: "Mike Kolesnik" <mkolesni at redhat.com>, "arch" <arch at ovirt.org>
> Sent: Tuesday, November 26, 2013 8:45:06 PM
> Subject: Re: Edit Provisioned Network Feature
> 
> Hi Moti, question:
> 
> what will happen if the 'Apply network change to all hosts' check-box will
> not be checked?
> i.e. the logical network business entity and the networking configuration on
> the Host will
> be out of sync? do we plan to indicate that somewhere in the GUI / allow a
> way to "sync"
> the Hosts' networking configuration with the up-to-date logical network
> business entities?
> 

Yes, it updating the network without sync it with the hosts will result in 
host-network-out-of-sync with the logical network definition. This is the
same behaviour as exist today.

Why would we like to preserve it and not automatically to sync the change with
all hosts ? I think it is up to the administrator to decide whether change should
take effect immediately or to apply it by demand. 

> maybe it is the exact same thing that Mike asked at the end of his e-mail
> (not sure) and
> you mentioned that it is worthy a separate RFE; I am not sure if handling it
> separately
> is such a good idea - question is how important it is to indicate that a Host
> networking
> configuration is not sync'd with the logical network business entities (i.e.
> we can have
> two Hosts, one configured before the provisioned-network change and one
> configured after
> the provisioned-network change, and their networking configuration may seem
> "identical"
> even though it is not really the case).
> 

What you and Mike suggest is exposing already existing functionality in the 'setup networks'
dialog: In the 'setup networks' dialog each network is marked as synced or not, and the user
can select to 'sync' the network with its logical network definition.

So all the building blocks are there:
1. Indication on the network 'sync-ness' on the host
2. Ability to sync a specific network with its logical network definition

The idea of exposing that information in the network main tab as part of its hosts sub-tab
could have been included as part of the 'network main tab' feature which seems more appropriate
and could have been implemented regardless of the the $subject.

In addition, looking from the API perspective - the 'sync' operation is executed via
the 'setup networks' api, and not via the extension to the PUT method of the network.

I agree that those extensions to the network main tab should be added and they have a great value,
but as I see it, it is not tied to this feature.

> we can, at the first stage, decide that the 'Apply network change to all
> hosts' check-box
> is always checked and disabled, so Hosts would never be out of sync, or agree
> upon a
> similar limitation that will allow us to not need the 'sync' action / 'out of
> sync'
> indication immediately.
> 
> ----
> Thanks,
> Einav
> 
> ----- Original Message -----
> > From: "Moti Asayag" <masayag at redhat.com>
> > To: "Mike Kolesnik" <mkolesni at redhat.com>
> > Cc: "arch" <arch at ovirt.org>
> > Sent: Tuesday, November 26, 2013 8:30:40 AM
> > Subject: Re: Edit Provisioned Network Feature
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > > To: "Moti Asayag" <masayag at redhat.com>
> > > Cc: "arch" <arch at ovirt.org>
> > > Sent: Tuesday, November 26, 2013 7:38:43 AM
> > > Subject: Re: Edit Provisioned Network Feature
> > > 
> > > Very nice feature page, and a very good feature!
> > > 
> > > I have a couple of questions:
> > > 
> > > * Is the first part of the update command non-transactive? It's not clear
> > > from
> > > "The 'UpdateNetworkCommand' will be changed to a non-transactive"
> > > I would think the first part is still transactive, and the second one is
> > > not..
> > > 
> > 
> > The scope of the transaction include updating the network in the DB and
> > removing
> > its vnic profiles if network was changed from vm network to non-vm network.
> > The rest of the command (apply changes to host) should run with no
> > transaction.
> > Therefore the command itself will be marked as
> > @NonTransactiveCommandAttribute
> > and specific transaction will be opened to the described scope.
> > 
> > > * How can you apply the non-VM network if VMs/vNICs are down?
> > > I think it makes most sense to block if the network is being used to
> > > avoid
> > > confusion (otherwise say you changed to non-VM and later some VM using
> > > the
> > > network will always fail to launch, not sure it's a good thing).
> > > 
> > 
> > Agree - such change should be blocked.
> > 
> > > * From REST API perspective it looks like apply is a field on the
> > > network?
> > > If it is a field, perhaps worth saving it to DB so that it is used every
> > > time
> > > the network is edited?
> > > i.e. the "edit network" dialog will show this field value and this value
> > > will
> > > also be used later to determine whether to apply on all hosts or not..
> > > 
> > 
> > Since we're using the PUT method, we provide the network entity for the
> > action,
> > and any additional parameter as it sub-element.
> > One can claim that this field which doesn't serve as a network property,
> > rather
> > as an additional action to perform for the given operation. Therefore I
> > find
> > it
> > more suitable to be passed as a parameter.
> > 
> > > * Not sure how you plan to apply on some of the hosts, so not sure it's
> > > worth
> > > mentioning at this point..
> > > 
> > 
> > It should have been marked as p2. I thought as an enhancement to the UI
> > where
> > hierarchical cluster-hosts tree allows specific selection, something like:
> > 
> > (x) Cluster 1
> >     (x) host A
> >     ( ) host B
> > (x) Cluster 2
> >     (x) host C
> >     (X) host D
> > ( ) Cluster 3
> >     ( ) host E
> > 
> > But since it is not planned for p1 we can postpone the discussion of it.
> > 
> > > * You need to take into consideration the "Save network configuration"
> > > behavior
> > > in conjunction with this feature, i.e. the changes should probably be
> > > saved.
> > > 
> > 
> > Indeed, the user should be aware that any non-committed changes applied to
> > the host
> > will be committed once using this feature.
> > 
> > > Also a couple suggestions which are related:
> > > * When standing on a network (in networks tab), you have the Hosts
> > > sub-tab.
> > > 
> > > ** Can we have a column for the sync status?
> > > 
> > > ** Can we have a button to sync to specific host (very useful when
> > > network
> > > got applied only to some of the hosts)?
> > > 
> > 
> > Those are nice improvements and should get their own RFE. Could you open
> > one
> > so we can prioritize and target it properly?
> > 
> > > *** This also answers (IMHO) the capability to apply only to specific
> > > hosts.
> > > 
> > > Regards,
> > > Mike
> > > 
> > > ----- Original Message -----
> > > > 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
> > > > _______________________________________________
> > > > Arch mailing list
> > > > Arch at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/arch
> > > > 
> > > 
> > _______________________________________________
> > Arch mailing list
> > Arch at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/arch
> > 
> 


From sbonazzo at redhat.com  Wed Nov 27 07:49:47 2013
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Wed, 27 Nov 2013 08:49:47 +0100
Subject: [Users] oVirt 3.3.1 rlease
In-Reply-To: <1294729297.19225102.1385473179774.JavaMail.root@redhat.com>
References: <1838374536.5979660.1385048621587.JavaMail.root@redhat.com>
	<1294729297.19225102.1385473179774.JavaMail.root@redhat.com>
Message-ID: <5295A41B.30901@redhat.com>

Il 26/11/2013 14:39, Alon Bar-Lev ha scritto:
> 
> 
> ----- Original Message -----
>> From: "Kiril Nesenko" <kiril at redhat.com>
>> To: "arch" <arch at ovirt.org>, announce at ovirt.org, users at ovirt.org
>> Sent: Thursday, November 21, 2013 5:43:41 PM
>> Subject: [Users] oVirt 3.3.1 rlease
>>
>> The oVirt development team is very happy to announce the general
>> availability of oVirt 3.3.1 as of November 21th 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.4
>> (or similar).
>>
>> See release notes [1] for a list of the new features and bug fixed.
>>
>> [1] http://www.ovirt.org/OVirt_3.3.1_release_notes
>>
>> - Kiril
> 
> Hello,
> 
> Experimental Gentoo support for ovirt-engine-3.3.1 is available[1], feedback is welcomed.

Added to release notes [2]
Alon can you write a few lines about upgrading / installing on Gentoo?

[2] http://www.ovirt.org/OVirt_3.3.1_release_notes#Gentoo

> 
> Regards,
> Alon Bar-Lev.
> 
> [1] https://github.com/alonbl/ovirt-overlay
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
> 


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


From alonbl at redhat.com  Wed Nov 27 07:52:43 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Wed, 27 Nov 2013 02:52:43 -0500 (EST)
Subject: [Users] oVirt 3.3.1 rlease
In-Reply-To: <5295A41B.30901@redhat.com>
References: <1838374536.5979660.1385048621587.JavaMail.root@redhat.com>
	<1294729297.19225102.1385473179774.JavaMail.root@redhat.com>
	<5295A41B.30901@redhat.com>
Message-ID: <1297711273.19508735.1385538763370.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>, "Kiril Nesenko" <kiril at redhat.com>
> Cc: "arch" <arch at ovirt.org>, users at ovirt.org
> Sent: Wednesday, November 27, 2013 9:49:47 AM
> Subject: Re: [Users] oVirt 3.3.1 rlease
> 
> Il 26/11/2013 14:39, Alon Bar-Lev ha scritto:
> > 
> > 
> > ----- Original Message -----
> >> From: "Kiril Nesenko" <kiril at redhat.com>
> >> To: "arch" <arch at ovirt.org>, announce at ovirt.org, users at ovirt.org
> >> Sent: Thursday, November 21, 2013 5:43:41 PM
> >> Subject: [Users] oVirt 3.3.1 rlease
> >>
> >> The oVirt development team is very happy to announce the general
> >> availability of oVirt 3.3.1 as of November 21th 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.4
> >> (or similar).
> >>
> >> See release notes [1] for a list of the new features and bug fixed.
> >>
> >> [1] http://www.ovirt.org/OVirt_3.3.1_release_notes
> >>
> >> - Kiril
> > 
> > Hello,
> > 
> > Experimental Gentoo support for ovirt-engine-3.3.1 is available[1],
> > feedback is welcomed.
> 
> Added to release notes [2]
> Alon can you write a few lines about upgrading / installing on Gentoo?

There is no upgrade as it is the first actual release...

Instructions are at [1]

[1] http://wiki.gentoo.org/wiki/OVirt

> 
> [2] http://www.ovirt.org/OVirt_3.3.1_release_notes#Gentoo
> 
> > 
> > Regards,
> > Alon Bar-Lev.
> > 
> > [1] https://github.com/alonbl/ovirt-overlay
> > _______________________________________________
> > Users mailing list
> > Users at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/users
> > 
> 
> 
> --
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
> 


From sbonazzo at redhat.com  Wed Nov 27 07:58:36 2013
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Wed, 27 Nov 2013 08:58:36 +0100
Subject: [Users] oVirt 3.3.1 rlease
In-Reply-To: <1297711273.19508735.1385538763370.JavaMail.root@redhat.com>
References: <1838374536.5979660.1385048621587.JavaMail.root@redhat.com>
	<1294729297.19225102.1385473179774.JavaMail.root@redhat.com>
	<5295A41B.30901@redhat.com>
	<1297711273.19508735.1385538763370.JavaMail.root@redhat.com>
Message-ID: <5295A62C.9070600@redhat.com>

Il 27/11/2013 08:52, Alon Bar-Lev ha scritto:
> 
> 
> ----- Original Message -----
>> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
>> To: "Alon Bar-Lev" <alonbl at redhat.com>, "Kiril Nesenko" <kiril at redhat.com>
>> Cc: "arch" <arch at ovirt.org>, users at ovirt.org
>> Sent: Wednesday, November 27, 2013 9:49:47 AM
>> Subject: Re: [Users] oVirt 3.3.1 rlease
>>
>> Il 26/11/2013 14:39, Alon Bar-Lev ha scritto:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Kiril Nesenko" <kiril at redhat.com>
>>>> To: "arch" <arch at ovirt.org>, announce at ovirt.org, users at ovirt.org
>>>> Sent: Thursday, November 21, 2013 5:43:41 PM
>>>> Subject: [Users] oVirt 3.3.1 rlease
>>>>
>>>> The oVirt development team is very happy to announce the general
>>>> availability of oVirt 3.3.1 as of November 21th 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.4
>>>> (or similar).
>>>>
>>>> See release notes [1] for a list of the new features and bug fixed.
>>>>
>>>> [1] http://www.ovirt.org/OVirt_3.3.1_release_notes
>>>>
>>>> - Kiril
>>>
>>> Hello,
>>>
>>> Experimental Gentoo support for ovirt-engine-3.3.1 is available[1],
>>> feedback is welcomed.
>>
>> Added to release notes [2]
>> Alon can you write a few lines about upgrading / installing on Gentoo?
> 
> There is no upgrade as it is the first actual release...
> 
> Instructions are at [1]
> 
> [1] http://wiki.gentoo.org/wiki/OVirt

Thanks, added.


> 
>>
>> [2] http://www.ovirt.org/OVirt_3.3.1_release_notes#Gentoo
>>
>>>
>>> Regards,
>>> Alon Bar-Lev.
>>>
>>> [1] https://github.com/alonbl/ovirt-overlay
>>> _______________________________________________
>>> Users mailing list
>>> Users at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/users
>>>
>>
>>
>> --
>> Sandro Bonazzola
>> Better technology. Faster innovation. Powered by community collaboration.
>> See how it works at redhat.com
>>


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


From ecohen at redhat.com  Wed Nov 27 12:10:34 2013
From: ecohen at redhat.com (Einav Cohen)
Date: Wed, 27 Nov 2013 07:10:34 -0500 (EST)
Subject: Edit Provisioned Network Feature
In-Reply-To: <1400856723.1809079.1385538159570.JavaMail.root@redhat.com>
References: <260448418.286241.1385394434059.JavaMail.root@redhat.com>
	<693643003.40738769.1385444323311.JavaMail.root@redhat.com>
	<818573927.1015594.1385472640420.JavaMail.root@redhat.com>
	<250145037.16664793.1385491506068.JavaMail.root@redhat.com>
	<1400856723.1809079.1385538159570.JavaMail.root@redhat.com>
Message-ID: <488306014.17646106.1385554234120.JavaMail.root@redhat.com>

Hi Moti, many thanks for the explanation. I was sure that up until now, we simply 
blocked editing logical networks that were already attached to Hosts, and only 
with this feature we would allow it, but this is not the case. 

IMO - it is important to show this information in the Hosts main tab (or at least 
in the Networks sub-tab of the Hosts main tab), but as you mentioned - it is not 
directly related to this feature in particular, as out-of-sync networks can 
already exist today, and this feature is not "making things any worse" in that 
sense or anything like that. 
I also was not aware that we have the 'sync' indication/method available via the 
'Setup Host Networks' dialog, so that's good as well. 

----
Regards,
Einav

----- Original Message -----
> From: "Moti Asayag" <masayag at redhat.com>
> To: "Einav Cohen" <ecohen at redhat.com>
> Cc: "Mike Kolesnik" <mkolesni at redhat.com>, "arch" <arch at ovirt.org>
> Sent: Wednesday, November 27, 2013 2:42:39 AM
> Subject: Re: Edit Provisioned Network Feature
> 
> 
> 
> ----- Original Message -----
> > From: "Einav Cohen" <ecohen at redhat.com>
> > To: "Moti Asayag" <masayag at redhat.com>
> > Cc: "Mike Kolesnik" <mkolesni at redhat.com>, "arch" <arch at ovirt.org>
> > Sent: Tuesday, November 26, 2013 8:45:06 PM
> > Subject: Re: Edit Provisioned Network Feature
> > 
> > Hi Moti, question:
> > 
> > what will happen if the 'Apply network change to all hosts' check-box will
> > not be checked?
> > i.e. the logical network business entity and the networking configuration
> > on
> > the Host will
> > be out of sync? do we plan to indicate that somewhere in the GUI / allow a
> > way to "sync"
> > the Hosts' networking configuration with the up-to-date logical network
> > business entities?
> > 
> 
> Yes, it updating the network without sync it with the hosts will result in
> host-network-out-of-sync with the logical network definition. This is the
> same behaviour as exist today.
> 
> Why would we like to preserve it and not automatically to sync the change
> with
> all hosts ? I think it is up to the administrator to decide whether change
> should
> take effect immediately or to apply it by demand.
> 
> > maybe it is the exact same thing that Mike asked at the end of his e-mail
> > (not sure) and
> > you mentioned that it is worthy a separate RFE; I am not sure if handling
> > it
> > separately
> > is such a good idea - question is how important it is to indicate that a
> > Host
> > networking
> > configuration is not sync'd with the logical network business entities
> > (i.e.
> > we can have
> > two Hosts, one configured before the provisioned-network change and one
> > configured after
> > the provisioned-network change, and their networking configuration may seem
> > "identical"
> > even though it is not really the case).
> > 
> 
> What you and Mike suggest is exposing already existing functionality in the
> 'setup networks'
> dialog: In the 'setup networks' dialog each network is marked as synced or
> not, and the user
> can select to 'sync' the network with its logical network definition.
> 
> So all the building blocks are there:
> 1. Indication on the network 'sync-ness' on the host
> 2. Ability to sync a specific network with its logical network definition
> 
> The idea of exposing that information in the network main tab as part of its
> hosts sub-tab
> could have been included as part of the 'network main tab' feature which
> seems more appropriate
> and could have been implemented regardless of the the $subject.
> 
> In addition, looking from the API perspective - the 'sync' operation is
> executed via
> the 'setup networks' api, and not via the extension to the PUT method of the
> network.
> 
> I agree that those extensions to the network main tab should be added and
> they have a great value,
> but as I see it, it is not tied to this feature.
> 
> > we can, at the first stage, decide that the 'Apply network change to all
> > hosts' check-box
> > is always checked and disabled, so Hosts would never be out of sync, or
> > agree
> > upon a
> > similar limitation that will allow us to not need the 'sync' action / 'out
> > of
> > sync'
> > indication immediately.
> > 
> > ----
> > Thanks,
> > Einav
> > 
> > ----- Original Message -----
> > > From: "Moti Asayag" <masayag at redhat.com>
> > > To: "Mike Kolesnik" <mkolesni at redhat.com>
> > > Cc: "arch" <arch at ovirt.org>
> > > Sent: Tuesday, November 26, 2013 8:30:40 AM
> > > Subject: Re: Edit Provisioned Network Feature
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > > > To: "Moti Asayag" <masayag at redhat.com>
> > > > Cc: "arch" <arch at ovirt.org>
> > > > Sent: Tuesday, November 26, 2013 7:38:43 AM
> > > > Subject: Re: Edit Provisioned Network Feature
> > > > 
> > > > Very nice feature page, and a very good feature!
> > > > 
> > > > I have a couple of questions:
> > > > 
> > > > * Is the first part of the update command non-transactive? It's not
> > > > clear
> > > > from
> > > > "The 'UpdateNetworkCommand' will be changed to a non-transactive"
> > > > I would think the first part is still transactive, and the second one
> > > > is
> > > > not..
> > > > 
> > > 
> > > The scope of the transaction include updating the network in the DB and
> > > removing
> > > its vnic profiles if network was changed from vm network to non-vm
> > > network.
> > > The rest of the command (apply changes to host) should run with no
> > > transaction.
> > > Therefore the command itself will be marked as
> > > @NonTransactiveCommandAttribute
> > > and specific transaction will be opened to the described scope.
> > > 
> > > > * How can you apply the non-VM network if VMs/vNICs are down?
> > > > I think it makes most sense to block if the network is being used to
> > > > avoid
> > > > confusion (otherwise say you changed to non-VM and later some VM using
> > > > the
> > > > network will always fail to launch, not sure it's a good thing).
> > > > 
> > > 
> > > Agree - such change should be blocked.
> > > 
> > > > * From REST API perspective it looks like apply is a field on the
> > > > network?
> > > > If it is a field, perhaps worth saving it to DB so that it is used
> > > > every
> > > > time
> > > > the network is edited?
> > > > i.e. the "edit network" dialog will show this field value and this
> > > > value
> > > > will
> > > > also be used later to determine whether to apply on all hosts or not..
> > > > 
> > > 
> > > Since we're using the PUT method, we provide the network entity for the
> > > action,
> > > and any additional parameter as it sub-element.
> > > One can claim that this field which doesn't serve as a network property,
> > > rather
> > > as an additional action to perform for the given operation. Therefore I
> > > find
> > > it
> > > more suitable to be passed as a parameter.
> > > 
> > > > * Not sure how you plan to apply on some of the hosts, so not sure it's
> > > > worth
> > > > mentioning at this point..
> > > > 
> > > 
> > > It should have been marked as p2. I thought as an enhancement to the UI
> > > where
> > > hierarchical cluster-hosts tree allows specific selection, something
> > > like:
> > > 
> > > (x) Cluster 1
> > >     (x) host A
> > >     ( ) host B
> > > (x) Cluster 2
> > >     (x) host C
> > >     (X) host D
> > > ( ) Cluster 3
> > >     ( ) host E
> > > 
> > > But since it is not planned for p1 we can postpone the discussion of it.
> > > 
> > > > * You need to take into consideration the "Save network configuration"
> > > > behavior
> > > > in conjunction with this feature, i.e. the changes should probably be
> > > > saved.
> > > > 
> > > 
> > > Indeed, the user should be aware that any non-committed changes applied
> > > to
> > > the host
> > > will be committed once using this feature.
> > > 
> > > > Also a couple suggestions which are related:
> > > > * When standing on a network (in networks tab), you have the Hosts
> > > > sub-tab.
> > > > 
> > > > ** Can we have a column for the sync status?
> > > > 
> > > > ** Can we have a button to sync to specific host (very useful when
> > > > network
> > > > got applied only to some of the hosts)?
> > > > 
> > > 
> > > Those are nice improvements and should get their own RFE. Could you open
> > > one
> > > so we can prioritize and target it properly?
> > > 
> > > > *** This also answers (IMHO) the capability to apply only to specific
> > > > hosts.
> > > > 
> > > > Regards,
> > > > Mike
> > > > 
> > > > ----- Original Message -----
> > > > > 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
> > > > > _______________________________________________
> > > > > 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 fabiand at redhat.com  Wed Nov 27 14:56:11 2013
From: fabiand at redhat.com (Fabian Deutsch)
Date: Wed, 27 Nov 2013 15:56:11 +0100
Subject: oVirt Node 3.0.3-1 for oVirt 3.3 release
Message-ID: <1385564171.2781.34.camel@fdeutsch-laptop.local>

Hello,

finally also oVirt Node images for oVirt 3.3.1 are available.

The latest ISO can be downloaded here:
http://resources.ovirt.org/releases/3.3/iso/

To get started take a look at the section in the Quick Start Guide:
http://www.ovirt.org/Quick_Start_Guide#Install_oVirt_Node

oVirt Node is a small image with yet enough software for bare metal
hosts which shall be managed by oVirt Engine. It is easy to handle and
can be deployed using CD/DVD, PXE/Foreman and USB.
http://www.ovirt.org/Node

- fabian



From sbonazzo at redhat.com  Thu Nov 28 15:22:18 2013
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Thu, 28 Nov 2013 16:22:18 +0100
Subject: [Users] Trouble upgrading
In-Reply-To: <20131128121540.GF20978@redhat.com>
References: <1838374536.5979660.1385048621587.JavaMail.root@redhat.com>	<528E35A0.3040403@doolittle.us.com>	<5294E9E8.8010302@doolittle.us.com>	<465667757.42185704.1385618766511.JavaMail.root@redhat.com>
	<20131128121540.GF20978@redhat.com>
Message-ID: <52975FAA.1030303@redhat.com>

Il 28/11/2013 13:15, Dan Kenigsberg ha scritto:
> On Thu, Nov 28, 2013 at 01:06:06AM -0500, Balamurugan Arumugam wrote:
>>
>>> On 11/21/2013 11:32 AM, Bob Doolittle wrote:
>>>> But I don't know how to upgrade my RH 6.4 KVM host. When I try to run
>>>> "yum update" it fails due to dependency errors notably in:
>>>> glusterfs
>>>> qemu
>>>> vdsm
>>>>
>>>> and also to a multilib version error due to vdsm-python 4.12 and 4.13.
>>>>
>>>> What's the proper upgrade procedure for a Host?
>>>
>>> Just to summarize:
>>>
>>> There is a bug (https://bugzilla.redhat.com/show_bug.cgi?id=1033587)
>>> which prevents updates of the Host/Node for users of the Red Hat 6
>>> official channels. A fix will be forthcoming.
>>>
>>> In the meantime, a workaround is to edit
>>> /etc/yum.repos.d/glusterfs-epel.repo to globally change the version
>>> string "3.4.0" to "LATEST".


A new ovirt-release-9-1 rpm has been published in stable repo updating glusterfs release to LATEST.




>>>
>>
>> I sent a fix [1] to vdsm to add glusterfs dependency conditionally.  Please let me know if this helps.
>>
>>
>> Regards,
>> Bala
>>
>> [1] http://gerrit.ovirt.org/#/c/21705/
> 
> I think that this is unhelpful for two reasons:
> 1. Bob complains about ovirt-3.3, and you patch master.
> 2. We cannot take your patch to master since we already have code that
>    expects glusterfs>=3.4.1 (http://gerrit.ovirt.org/10200).
> 
> I believe that taking http://gerrit.ovirt.org/#/c/21794/ into
> ovirt-release would fix Bob's issues.
> 
> Dan.
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
> 


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


From gchaplik at redhat.com  Thu Nov 28 16:18:11 2013
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Thu, 28 Nov 2013 11:18:11 -0500 (EST)
Subject: oVirt 3.4 SLA & Scheduling feature overview
Message-ID: <1754687861.42557409.1385655491892.JavaMail.root@redhat.com>

The following is a new meeting request:

Subject: oVirt 3.4 SLA &amp; Scheduling feature overview 
Organizer: "Gilad Chaplik" <gchaplik at redhat.com> 

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


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

Hi all, 

I invite you to a overview for planed SLA & Scheduling features for oVirt 3.4.
We will talk briefly about every suggested feature including:
- positive/negative affinity between group of VMs
- power saving policy moving hosts to sleep
- time based policy (SLA during the day, power saving at night)
- application level HA (monitor the service inside the VM) 

People are welcome to join in the #ovirt channel on irc.OFTC.net.

Thanks

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

From sbonazzo at redhat.com  Fri Nov 29 12:18:53 2013
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Fri, 29 Nov 2013 13:18:53 +0100
Subject: [Users] oVirt Weekly Meeting Minutes -- 2013-11-27
In-Reply-To: <20131129121352.GH9681@redhat.com>
References: <1839115795.18144890.1385570095111.JavaMail.root@redhat.com>
	<529848F2.1040508@redhat.com>
	<CAG2kNCztW2OQ20uzE2nBFEs5nNiAa2FX1rQOQjdGLfkkpgCg=A@mail.gmail.com>
	<52987157.5040605@redhat.com> <20131129121352.GH9681@redhat.com>
Message-ID: <5298862D.7080700@redhat.com>

Il 29/11/2013 13:13, Dan Kenigsberg ha scritto:
> On Fri, Nov 29, 2013 at 11:49:59AM +0100, Sandro Bonazzola wrote:
>> Il 29/11/2013 09:43, Gianluca Cecchi ha scritto:
>>> On Fri, Nov 29, 2013 at 8:57 AM, Sandro Bonazzola  wrote:
>>>
>>>>>
>>>>> Meeting summary
>>>>> ---------------
>>>>> * Agenda and roll Call  (doron, 15:02:42)
>>>>>   * 3.3 update releases  (doron, 15:04:23)
>>>>>   * 3.4 planning  (doron, 15:04:24)
>>>>>   * conferences and workshops  (doron, 15:04:26)
>>>>>   * infra update  (doron, 15:04:27)
>>>>>   * other topics  (doron, 15:04:29)
>>>>>   * LINK: http://gerrit.ovirt.org/#/admin/projects/ovirt-release ~
>>>>>     (danken, 15:12:58)
>>>>>   * LINK: http://gerrit.ovirt.org/21794   (mburns, 15:15:04)
>>>>>   * LINK: http://jenkins.ovirt.org/job/ovirt-release/16800/   (mburns,
>>>>>     15:15:48)
>>>>>   * mburns to add sbonazzo as a maintainer to support ovirt-release
>>>>>     project  (doron, 15:18:17)
>>>>
>>>> ovirt-release-9 released yesterday
>>>
>>> BTW: I see that this package contains
>>> /etc/yum.repos.d/fedora-virt-preview.repo
>>> (and ovirt-release-fedora-8-1.noarch already did so)
>>> By default all lines are disabled in it.
>>> When and how this repo should be enabled? Only when using nightly or
>>> only under developers/maintainers indications?
>>
>> I think that fedora-virt-preview should be used with nightly, stable shouldn't need it.
>> However, since fedora-virt-preview contains vdsm - related packages not needed if you run only ovirt-engine (without using the same host as
>> hypervisor) I think it's better to wait for VDSM guys answer.
> 
> Vdsm is not in
> http://fedorapeople.org/groups/virt/virt-preview/fedora-20/x86_64/
> 
> virt-preview is not needed for ovirt-3.3, and frankly, I think it should
> be dropped from ovirt-release.
> 
> It used to be needed on the nodes when vdsm required a version of
> libvirt that was not yet in Fedora. Now that we have el6 as a
> fully-supported platform, and given that el6 is missing from
> virt-preview, virt-preview is much less helpful to us.
> 
> Dan.
> 

So, any objection in removing virt-preview from ovirt-release?
What about nightly? Will it be needed there?

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


From danken at redhat.com  Fri Nov 29 12:38:38 2013
From: danken at redhat.com (Dan Kenigsberg)
Date: Fri, 29 Nov 2013 12:38:38 +0000
Subject: [Users] oVirt Weekly Meeting Minutes -- 2013-11-27
In-Reply-To: <5298862D.7080700@redhat.com>
References: <1839115795.18144890.1385570095111.JavaMail.root@redhat.com>
	<529848F2.1040508@redhat.com>
	<CAG2kNCztW2OQ20uzE2nBFEs5nNiAa2FX1rQOQjdGLfkkpgCg=A@mail.gmail.com>
	<52987157.5040605@redhat.com> <20131129121352.GH9681@redhat.com>
	<5298862D.7080700@redhat.com>
Message-ID: <20131129123838.GK9681@redhat.com>

On Fri, Nov 29, 2013 at 01:18:53PM +0100, Sandro Bonazzola wrote:
> Il 29/11/2013 13:13, Dan Kenigsberg ha scritto:
> > On Fri, Nov 29, 2013 at 11:49:59AM +0100, Sandro Bonazzola wrote:
> >> Il 29/11/2013 09:43, Gianluca Cecchi ha scritto:
> >>> On Fri, Nov 29, 2013 at 8:57 AM, Sandro Bonazzola  wrote:
> >>>
> >>>>>
> >>>>> Meeting summary
> >>>>> ---------------
> >>>>> * Agenda and roll Call  (doron, 15:02:42)
> >>>>>   * 3.3 update releases  (doron, 15:04:23)
> >>>>>   * 3.4 planning  (doron, 15:04:24)
> >>>>>   * conferences and workshops  (doron, 15:04:26)
> >>>>>   * infra update  (doron, 15:04:27)
> >>>>>   * other topics  (doron, 15:04:29)
> >>>>>   * LINK: http://gerrit.ovirt.org/#/admin/projects/ovirt-release ~
> >>>>>     (danken, 15:12:58)
> >>>>>   * LINK: http://gerrit.ovirt.org/21794   (mburns, 15:15:04)
> >>>>>   * LINK: http://jenkins.ovirt.org/job/ovirt-release/16800/   (mburns,
> >>>>>     15:15:48)
> >>>>>   * mburns to add sbonazzo as a maintainer to support ovirt-release
> >>>>>     project  (doron, 15:18:17)
> >>>>
> >>>> ovirt-release-9 released yesterday
> >>>
> >>> BTW: I see that this package contains
> >>> /etc/yum.repos.d/fedora-virt-preview.repo
> >>> (and ovirt-release-fedora-8-1.noarch already did so)
> >>> By default all lines are disabled in it.
> >>> When and how this repo should be enabled? Only when using nightly or
> >>> only under developers/maintainers indications?
> >>
> >> I think that fedora-virt-preview should be used with nightly, stable shouldn't need it.
> >> However, since fedora-virt-preview contains vdsm - related packages not needed if you run only ovirt-engine (without using the same host as
> >> hypervisor) I think it's better to wait for VDSM guys answer.
> > 
> > Vdsm is not in
> > http://fedorapeople.org/groups/virt/virt-preview/fedora-20/x86_64/
> > 
> > virt-preview is not needed for ovirt-3.3, and frankly, I think it should
> > be dropped from ovirt-release.
> > 
> > It used to be needed on the nodes when vdsm required a version of
> > libvirt that was not yet in Fedora. Now that we have el6 as a
> > fully-supported platform, and given that el6 is missing from
> > virt-preview, virt-preview is much less helpful to us.
> > 
> > Dan.
> > 
> 
> So, any objection in removing virt-preview from ovirt-release?
> What about nightly? Will it be needed there?

Should be removed from both, since it is currently unused. We could
reintroduce it if the need arises.