From iheim at redhat.com  Sun Aug  4 11:45:12 2013
From: iheim at redhat.com (Itamar Heim)
Date: Sun, 04 Aug 2013 14:45:12 +0300
Subject: gerrit will be upgraded to 2.6.1
Message-ID: <51FE3EC8.40700@redhat.com>

a small service interruption is expected


From iheim at redhat.com  Sun Aug  4 11:50:35 2013
From: iheim at redhat.com (Itamar Heim)
Date: Sun, 04 Aug 2013 14:50:35 +0300
Subject: gerrit will be upgraded to 2.6.1
In-Reply-To: <51FE3EC8.40700@redhat.com>
References: <51FE3EC8.40700@redhat.com>
Message-ID: <51FE400B.80308@redhat.com>

On 08/04/2013 02:45 PM, Itamar Heim wrote:
> a small service interruption is expected

upgrade is done. please report any issues.

changes worth noting:
- 42x improvement on git clone and git fetch
- Completely customizable workflow
   Individual projects can add (or remove) score categories through
   labels and Prolog rules.


http://gerrit-documentation.googlecode.com/svn/ReleaseNotes/ReleaseNotes-2.6.html


From alonbl at redhat.com  Sun Aug  4 14:03:13 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Sun, 4 Aug 2013 10:03:13 -0400 (EDT)
Subject: gerrit will be upgraded to 2.6.1
In-Reply-To: <51FE400B.80308@redhat.com>
References: <51FE3EC8.40700@redhat.com> <51FE400B.80308@redhat.com>
Message-ID: <2048152429.5603589.1375624993094.JavaMail.root@redhat.com>

Hi,

There is new permission "View Drafts"[1].

If we add "Registered Users" this permission, we can get rid of the WIP patches and submit these are drafts.

Drafs has major advantage, apart the fact that it cannot be mistakenly consider as final... it can be actually deleted... the entire draft or specific changesets within. So it does not bloat the database.

Regards,
Alon

[1] http://gerrit-documentation.googlecode.com/svn/Documentation/2.6/access-control.html#category_view_drafts

----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "infra" <infra at ovirt.org>, "arch" <arch at ovirt.org>
> Sent: Sunday, August 4, 2013 2:50:35 PM
> Subject: Re: gerrit will be upgraded to 2.6.1
> 
> On 08/04/2013 02:45 PM, Itamar Heim wrote:
> > a small service interruption is expected
> 
> upgrade is done. please report any issues.
> 
> changes worth noting:
> - 42x improvement on git clone and git fetch
> - Completely customizable workflow
>    Individual projects can add (or remove) score categories through
>    labels and Prolog rules.
> 
> 
> http://gerrit-documentation.googlecode.com/svn/ReleaseNotes/ReleaseNotes-2.6.html
> _______________________________________________
> Infra mailing list
> Infra at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
> 


From iheim at redhat.com  Sun Aug  4 14:08:28 2013
From: iheim at redhat.com (Itamar Heim)
Date: Sun, 04 Aug 2013 17:08:28 +0300
Subject: gerrit will be upgraded to 2.6.1 - chrome issues
In-Reply-To: <51FE400B.80308@redhat.com>
References: <51FE3EC8.40700@redhat.com> <51FE400B.80308@redhat.com>
Message-ID: <51FE605C.6010303@redhat.com>

On 08/04/2013 02:50 PM, Itamar Heim wrote:
> On 08/04/2013 02:45 PM, Itamar Heim wrote:
>> a small service interruption is expected
>
> upgrade is done. please report any issues.
>
> changes worth noting:
> - 42x improvement on git clone and git fetch
> - Completely customizable workflow
>    Individual projects can add (or remove) score categories through
>    labels and Prolog rules.
>
>
> http://gerrit-documentation.googlecode.com/svn/ReleaseNotes/ReleaseNotes-2.6.html
>

there are some reports on bad performance with the chrome browser.
please report if so.
no such reports so far for firefox


From eedri at redhat.com  Sun Aug  4 14:11:29 2013
From: eedri at redhat.com (Eyal Edri)
Date: Sun, 4 Aug 2013 10:11:29 -0400 (EDT)
Subject: gerrit will be upgraded to 2.6.1
In-Reply-To: <2048152429.5603589.1375624993094.JavaMail.root@redhat.com>
References: <51FE3EC8.40700@redhat.com> <51FE400B.80308@redhat.com>
	<2048152429.5603589.1375624993094.JavaMail.root@redhat.com>
Message-ID: <881682753.12120083.1375625489378.JavaMail.root@redhat.com>

Also, it might help jenkins differ from real patches pending to be merged (thus require a verification)
from a draft WIP that doesn't need verification.

Types of events from gerrit jenkins listens too: (currently set to patchset created)

    Draft Published: Sent when a change moves from draft state to new. (only available in version 2.5 or higher of Gerrit).
    Patchset Created: Sent when a new patchset arrives on a change. Before version 2.6.0, this was the only event you could trigger on.
    Change Merged: Sent when a change is merged on the Gerrit server.
    Comment Added: Sent when a comment is added to a change. Which category and value to trigger on can be configured. 
    Ref Updated: Sent when a ref is updated on the Gerrit server, i.e. someone pushes past code review.


----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Itamar Heim" <iheim at redhat.com>
> Cc: "arch" <arch at ovirt.org>, "infra" <infra at ovirt.org>
> Sent: Sunday, August 4, 2013 5:03:13 PM
> Subject: Re: gerrit will be upgraded to 2.6.1
> 
> Hi,
> 
> There is new permission "View Drafts"[1].
> 
> If we add "Registered Users" this permission, we can get rid of the WIP
> patches and submit these are drafts.
> 
> Drafs has major advantage, apart the fact that it cannot be mistakenly
> consider as final... it can be actually deleted... the entire draft or
> specific changesets within. So it does not bloat the database.
> 
> Regards,
> Alon
> 
> [1]
> http://gerrit-documentation.googlecode.com/svn/Documentation/2.6/access-control.html#category_view_drafts
> 
> ----- Original Message -----
> > From: "Itamar Heim" <iheim at redhat.com>
> > To: "infra" <infra at ovirt.org>, "arch" <arch at ovirt.org>
> > Sent: Sunday, August 4, 2013 2:50:35 PM
> > Subject: Re: gerrit will be upgraded to 2.6.1
> > 
> > On 08/04/2013 02:45 PM, Itamar Heim wrote:
> > > a small service interruption is expected
> > 
> > upgrade is done. please report any issues.
> > 
> > changes worth noting:
> > - 42x improvement on git clone and git fetch
> > - Completely customizable workflow
> >    Individual projects can add (or remove) score categories through
> >    labels and Prolog rules.
> > 
> > 
> > http://gerrit-documentation.googlecode.com/svn/ReleaseNotes/ReleaseNotes-2.6.html
> > _______________________________________________
> > Infra mailing list
> > Infra at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
> > 
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From iheim at redhat.com  Sun Aug  4 14:14:16 2013
From: iheim at redhat.com (Itamar Heim)
Date: Sun, 04 Aug 2013 17:14:16 +0300
Subject: gerrit will be upgraded to 2.6.1
In-Reply-To: <2048152429.5603589.1375624993094.JavaMail.root@redhat.com>
References: <51FE3EC8.40700@redhat.com> <51FE400B.80308@redhat.com>
	<2048152429.5603589.1375624993094.JavaMail.root@redhat.com>
Message-ID: <51FE61B8.8070203@redhat.com>

On 08/04/2013 05:03 PM, Alon Bar-Lev wrote:
> Hi,
>
> There is new permission "View Drafts"[1].
>
> If we add "Registered Users" this permission, we can get rid of the WIP patches and submit these are drafts.
>
> Drafs has major advantage, apart the fact that it cannot be mistakenly consider as final... it can be actually deleted... the entire draft or specific changesets within. So it does not bloat the database.

any reason to limit this to registered users (we allow everyone to see 
all patches currently without logging in)?


From alonbl at redhat.com  Sun Aug  4 14:17:55 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Sun, 4 Aug 2013 10:17:55 -0400 (EDT)
Subject: gerrit will be upgraded to 2.6.1
In-Reply-To: <51FE61B8.8070203@redhat.com>
References: <51FE3EC8.40700@redhat.com> <51FE400B.80308@redhat.com>
	<2048152429.5603589.1375624993094.JavaMail.root@redhat.com>
	<51FE61B8.8070203@redhat.com>
Message-ID: <1801185338.5603974.1375625875090.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "infra" <infra at ovirt.org>, "arch" <arch at ovirt.org>
> Sent: Sunday, August 4, 2013 5:14:16 PM
> Subject: Re: gerrit will be upgraded to 2.6.1
> 
> On 08/04/2013 05:03 PM, Alon Bar-Lev wrote:
> > Hi,
> >
> > There is new permission "View Drafts"[1].
> >
> > If we add "Registered Users" this permission, we can get rid of the WIP
> > patches and submit these are drafts.
> >
> > Drafs has major advantage, apart the fact that it cannot be mistakenly
> > consider as final... it can be actually deleted... the entire draft or
> > specific changesets within. So it does not bloat the database.
> 
> any reason to limit this to registered users (we allow everyone to see
> all patches currently without logging in)?
> 

No... I thought we require users to login anyway...


From iheim at redhat.com  Sun Aug  4 14:52:03 2013
From: iheim at redhat.com (Itamar Heim)
Date: Sun, 04 Aug 2013 17:52:03 +0300
Subject: gerrit will be upgraded to 2.6.1
In-Reply-To: <1801185338.5603974.1375625875090.JavaMail.root@redhat.com>
References: <51FE3EC8.40700@redhat.com> <51FE400B.80308@redhat.com>
	<2048152429.5603589.1375624993094.JavaMail.root@redhat.com>
	<51FE61B8.8070203@redhat.com>
	<1801185338.5603974.1375625875090.JavaMail.root@redhat.com>
Message-ID: <51FE6A93.50609@redhat.com>

On 08/04/2013 05:17 PM, Alon Bar-Lev wrote:
>
>
> ----- Original Message -----
>> From: "Itamar Heim" <iheim at redhat.com>
>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>> Cc: "infra" <infra at ovirt.org>, "arch" <arch at ovirt.org>
>> Sent: Sunday, August 4, 2013 5:14:16 PM
>> Subject: Re: gerrit will be upgraded to 2.6.1
>>
>> On 08/04/2013 05:03 PM, Alon Bar-Lev wrote:
>>> Hi,
>>>
>>> There is new permission "View Drafts"[1].
>>>
>>> If we add "Registered Users" this permission, we can get rid of the WIP
>>> patches and submit these are drafts.
>>>
>>> Drafs has major advantage, apart the fact that it cannot be mistakenly
>>> consider as final... it can be actually deleted... the entire draft or
>>> specific changesets within. So it does not bloat the database.
>>
>> any reason to limit this to registered users (we allow everyone to see
>> all patches currently without logging in)?
>>
>
> No... I thought we require users to login anyway...
>

done


From danken at redhat.com  Sun Aug  4 15:26:36 2013
From: danken at redhat.com (Dan Kenigsberg)
Date: Sun, 4 Aug 2013 18:26:36 +0300
Subject: gerrit will be upgraded to 2.6.1
In-Reply-To: <51FE400B.80308@redhat.com>
References: <51FE3EC8.40700@redhat.com>
 <51FE400B.80308@redhat.com>
Message-ID: <20130804152636.GC2515@redhat.com>

On Sun, Aug 04, 2013 at 02:50:35PM +0300, Itamar Heim wrote:
> On 08/04/2013 02:45 PM, Itamar Heim wrote:
> >a small service interruption is expected
> 
> upgrade is done. please report any issues.
> 
> changes worth noting:
> - 42x improvement on git clone and git fetch
> - Completely customizable workflow
>   Individual projects can add (or remove) score categories through
>   labels and Prolog rules.

The down size of this is that currently old searches, with the likes of
    CodeReview>=1

have to be updated to
    label:Code-Review>=1

(notice the annoying dash in the middle)

I suppose we can configure the server side for backward compatibility,
but I do not think that we should bother.

> 
> 
> http://gerrit-documentation.googlecode.com/svn/ReleaseNotes/ReleaseNotes-2.6.html
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch


From alonbl at redhat.com  Sun Aug  4 18:20:25 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Sun, 4 Aug 2013 14:20:25 -0400 (EDT)
Subject: Work in progress patches
In-Reply-To: <671222127.5616264.1375640180055.JavaMail.root@redhat.com>
Message-ID: <881000716.5616307.1375640425125.JavaMail.root@redhat.com>

Hi All,

Gerrit 2.6 allows everyone to see all drafts.

This means that no more WIP patches should be submitted, but drafts, once work is done, draft can be published into real change.

Drafts has advantages:

1. It cannot be mistakenly merged.

2. Drafts can be deleted, even a specific change within draft.

3. Drafts have their own category in UI.

4. CI can distiguish between drafts and non drafts and skip steps, for example do not perform integration tests.

Pushing drafts:

Just replace /for/ with /drafts/:

$ git push upstream HEAD:refs/drafts/master/topic

Regards,
Alon Bar-Lev.


From yzaslavs at redhat.com  Mon Aug  5 05:01:38 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Mon, 5 Aug 2013 01:01:38 -0400 (EDT)
Subject: gerrit will be upgraded to 2.6.1
In-Reply-To: <20130804152636.GC2515@redhat.com>
References: <51FE3EC8.40700@redhat.com> <51FE400B.80308@redhat.com>
	<20130804152636.GC2515@redhat.com>
Message-ID: <746935650.11233983.1375678898700.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Dan Kenigsberg" <danken at redhat.com>
> To: "Itamar Heim" <iheim at redhat.com>
> Cc: "arch" <arch at ovirt.org>, "infra" <infra at ovirt.org>
> Sent: Sunday, August 4, 2013 6:26:36 PM
> Subject: Re: gerrit will be upgraded to 2.6.1
> 
> On Sun, Aug 04, 2013 at 02:50:35PM +0300, Itamar Heim wrote:
> > On 08/04/2013 02:45 PM, Itamar Heim wrote:
> > >a small service interruption is expected
> > 
> > upgrade is done. please report any issues.

Maybe I missed this before, Maybe old habit - but, can we do something about the color scheme? or was that intentional?


> > 
> > changes worth noting:
> > - 42x improvement on git clone and git fetch
> > - Completely customizable workflow
> >   Individual projects can add (or remove) score categories through
> >   labels and Prolog rules.
> 
> The down size of this is that currently old searches, with the likes of
>     CodeReview>=1
> 
> have to be updated to
>     label:Code-Review>=1
> 
> (notice the annoying dash in the middle)
> 
> I suppose we can configure the server side for backward compatibility,
> but I do not think that we should bother.
> 
> > 
> > 
> > http://gerrit-documentation.googlecode.com/svn/ReleaseNotes/ReleaseNotes-2.6.html
> > _______________________________________________
> > Arch mailing list
> > Arch at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/arch
> _______________________________________________
> Infra mailing list
> Infra at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
> 


From lvernia at redhat.com  Mon Aug  5 08:12:58 2013
From: lvernia at redhat.com (Lior Vernia)
Date: Mon, 05 Aug 2013 11:12:58 +0300
Subject: Network traffic shaping.
In-Reply-To: <1809186597.402470.1373280341185.JavaMail.root@redhat.com>
References: <1809186597.402470.1373280341185.JavaMail.root@redhat.com>
Message-ID: <51FF5E8A.4010409@redhat.com>

Hey Giuseppe and everyone else,

Sorry for being late to the party. I've read all the e-mails and have
been rolling the idea around in my head for a couple of days. Here are
my two main thoughts, more UX-oriented, let me know what you think.

1. I would prefer not to be able to create a host network QoS entity,
which doesn't really have any significance as an independent entity.
However, I would like to be able to copy the configuration from one host
to another for the same network, right? So how about we add a
"Copy/Clone from" UI field that lets you choose a host from which to
copy the QoS configuration for that network?

This would appear next to the manual configuration, so users would still
be able to input other custom values if they prefer. Once we do this, we
also won't need to enable to define it on a per-network basis, where it
doesn't really make sense, but we could do with just defining it for
<host,network> pairs (i.e. say in the edit network dialog when attaching
a network to a host NIC).

To further clarify, copying/cloning would be INSTEAD OF creating a
Network QoS through some subtab, naming it, and then picking it in a
list box. There would be no way to create a named host network QoS
configuration.

2. I would prefer to not have to fill six fields to define QoS. Even if
there are default values to these fields, it makes it look complicated.
I think these six values could be replaced by just one typical value for
the network's traffic. The six-field configuration would still be
accessible somehow, but I don't want it to be necessary.

Regarding the empty values discussion, I'm not saying to leave the
values empty. I get why we want to fill them. But fill them ourselves in
some reasonable way that users won't be aware of unless they go into
advanced settings.

An alternative might be to allow two values, one for inbound traffic and
another for outbound traffic. However, I think this would only be
necessary if a user wants to actually manage both inbound and outbound
traffic in detail, which sounds to me like the uncommon use case. In
general people would just want to avoid host traffic, either inbound or
outbound, being taken over by one network. And again, distinguishing
between inbound and outbound would still be accessible through some
advanced settings.

Lior.

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


From iheim at redhat.com  Mon Aug  5 13:11:43 2013
From: iheim at redhat.com (Itamar Heim)
Date: Mon, 05 Aug 2013 16:11:43 +0300
Subject: gerrit will be upgraded to 2.6.1
In-Reply-To: <746935650.11233983.1375678898700.JavaMail.root@redhat.com>
References: <51FE3EC8.40700@redhat.com> <51FE400B.80308@redhat.com>
	<20130804152636.GC2515@redhat.com>
	<746935650.11233983.1375678898700.JavaMail.root@redhat.com>
Message-ID: <51FFA48F.3090609@redhat.com>

On 08/05/2013 08:01 AM, Yair Zaslavsky wrote:
>
>
> ----- Original Message -----
>> From: "Dan Kenigsberg" <danken at redhat.com>
>> To: "Itamar Heim" <iheim at redhat.com>
>> Cc: "arch" <arch at ovirt.org>, "infra" <infra at ovirt.org>
>> Sent: Sunday, August 4, 2013 6:26:36 PM
>> Subject: Re: gerrit will be upgraded to 2.6.1
>>
>> On Sun, Aug 04, 2013 at 02:50:35PM +0300, Itamar Heim wrote:
>>> On 08/04/2013 02:45 PM, Itamar Heim wrote:
>>>> a small service interruption is expected
>>>
>>> upgrade is done. please report any issues.
>
> Maybe I missed this before, Maybe old habit - but, can we do something about the color scheme? or was that intentional?

I try to not do any unneeded changes from upstream to avoid overhead on 
upgrades, etc.
so this is "how it looks" out of the box (for each version/change so far).
if it will get worse, we can consider re-themeing, etc.



From ewoud+ovirt at kohlvanwijngaarden.nl  Mon Aug  5 13:24:26 2013
From: ewoud+ovirt at kohlvanwijngaarden.nl (Ewoud Kohl van Wijngaarden)
Date: Mon, 5 Aug 2013 15:24:26 +0200
Subject: gerrit will be upgraded to 2.6.1
In-Reply-To: <51FFA48F.3090609@redhat.com>
References: <51FE3EC8.40700@redhat.com> <51FE400B.80308@redhat.com>
	<20130804152636.GC2515@redhat.com>
	<746935650.11233983.1375678898700.JavaMail.root@redhat.com>
	<51FFA48F.3090609@redhat.com>
Message-ID: <20130805132426.GL28963@bogey.xentower.nl>

On Mon, Aug 05, 2013 at 04:11:43PM +0300, Itamar Heim wrote:
> On 08/05/2013 08:01 AM, Yair Zaslavsky wrote:
> >
> >
> >----- Original Message -----
> >>From: "Dan Kenigsberg" <danken at redhat.com>
> >>To: "Itamar Heim" <iheim at redhat.com>
> >>Cc: "arch" <arch at ovirt.org>, "infra" <infra at ovirt.org>
> >>Sent: Sunday, August 4, 2013 6:26:36 PM
> >>Subject: Re: gerrit will be upgraded to 2.6.1
> >>
> >>On Sun, Aug 04, 2013 at 02:50:35PM +0300, Itamar Heim wrote:
> >>>On 08/04/2013 02:45 PM, Itamar Heim wrote:
> >>>>a small service interruption is expected
> >>>
> >>>upgrade is done. please report any issues.
> >
> >Maybe I missed this before, Maybe old habit - but, can we do something about the color scheme? or was that intentional?
> 
> I try to not do any unneeded changes from upstream to avoid overhead
> on upgrades, etc.
> so this is "how it looks" out of the box (for each version/change so far).
> if it will get worse, we can consider re-themeing, etc.

Personally I think the new design is an improvement over the old so +1
for keeping the defaults.


From alonbl at redhat.com  Mon Aug  5 22:01:59 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Mon, 5 Aug 2013 18:01:59 -0400 (EDT)
Subject: [Engine-devel] [Users] [Feedback required][host-deploy]
	Fedora-19 misses tar at minimal setup
In-Reply-To: <1031113778.4037715.1375189923523.JavaMail.root@redhat.com>
References: <733894071.3566217.1374997569084.JavaMail.root@redhat.com>
	<51F4E3E0.600@redhat.com>
	<1199327522.3570177.1375008177999.JavaMail.root@redhat.com>
	<1832045797.3650023.1375082133389.JavaMail.root@redhat.com>
	<1031113778.4037715.1375189923523.JavaMail.root@redhat.com>
Message-ID: <51845645.5954749.1375740119243.JavaMail.root@redhat.com>

Hello Again,

I tend to keep state as-is, require tar at host machine.

Whoever installs Fedora minimal should install tar manually.

I hope Fedora people will add tar per some of the requests, as tar is important utility in *NIX environment.

I do not think that the extra complexity is required.

If you strongly think otherwise, then I prefer to merge the self extracting python script.

Speak now, and emphasis.

Regards,
Alon Bar-Lev.

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


From didi at redhat.com  Tue Aug  6 05:07:49 2013
From: didi at redhat.com (Yedidyah Bar David)
Date: Tue, 6 Aug 2013 01:07:49 -0400 (EDT)
Subject: [Users] [Engine-devel] [Feedback required][host-deploy]
	Fedora-19 misses tar at minimal setup
In-Reply-To: <BLU404-EAS74852DFC9519F7F3FE8270A75D0@phx.gbl>
References: <BLU404-EAS74852DFC9519F7F3FE8270A75D0@phx.gbl>
Message-ID: <1893404528.11744649.1375765669830.JavaMail.root@redhat.com>

Hi all, 

+1 for Alon's summary - first preference to remain as-is, second pyar. 

In addition: 
----- Original Message -----


From: "Nicholas Kesick" <cybertimber2000 at hotmail.com> 
To: "oVirt Mailing List" <users at ovirt.org>, "arch" <arch at ovirt.org>, "engine-devel" <engine-devel at ovirt.org>, "Alon Bar-Lev" <alonbl at redhat.com> 
Sent: Tuesday, August 6, 2013 4:57:41 AM 
Subject: Re: [Users] [Engine-devel] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup 

I did some testing with Fedora 18 (waiting for the Fedora 19 dvd to finish downloading) and I think that the behavior was the same way in Fedora 18. In Fedora 18 when installing from DVD if you select ?Minimal Install?, you do not get tar. 




Indeed. 


<blockquote>

However, if you select ?Minimal install? and ?standard? under the add-on list, you *do* get tar. And if memory serves I learned the hard way in Fedora 18 that a lot of familiar commands are missing in minimal install without the standard add-on items including ?ifconfig?. Yea, you can?t even easily tell what your IP address is!... unless you are used to the ip command. 

</blockquote>


I think they are trying to educate us... and for me it partially worked :-) 
I have some machines on which I did not install ifconfig, and (partially) 
learned to use ip (after refusing to do so for perhaps 10 or so years). 


<blockquote>

Is there any other commands that are missing on the ?minimal? install that are needed? 

</blockquote>


Needed by vdsm? They are listed as dependencies for it. 
Needed by me? Yes, but that's a personal preference. 


<blockquote>

Would it be easier to mention in the install directions to use the standard add-on if selecting the minimal package set for host deployment? 

</blockquote>


The wiki page already tells to install tar, and I think that's enough. 


<blockquote>

Just thoughts. I also wonder if it would be possible to include tar as a dependency for the RPMs (like ovirt-engine or vdsm) so when installed using a package manager, tar would be checked for. 

</blockquote>


This won't help in our case, as Alon explained in previous mails in this subject - 
these RPMs are installed by the "bundle" (a set of scripts/data files) that we are now 
discussing how should be made to arrive and run. 

Best regards, 
-- 
Didi 

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

From sbonazzo at redhat.com  Tue Aug  6 05:39:06 2013
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Tue, 06 Aug 2013 07:39:06 +0200
Subject: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19
	misses tar at minimal setup
In-Reply-To: <51845645.5954749.1375740119243.JavaMail.root@redhat.com>
References: <733894071.3566217.1374997569084.JavaMail.root@redhat.com>
	<51F4E3E0.600@redhat.com>
	<1199327522.3570177.1375008177999.JavaMail.root@redhat.com>
	<1832045797.3650023.1375082133389.JavaMail.root@redhat.com>
	<1031113778.4037715.1375189923523.JavaMail.root@redhat.com>
	<51845645.5954749.1375740119243.JavaMail.root@redhat.com>
Message-ID: <52008BFA.3060509@redhat.com>

Il 06/08/2013 00:01, Alon Bar-Lev ha scritto:
> Hello Again,
>
> I tend to keep state as-is, require tar at host machine.
>
> Whoever installs Fedora minimal should install tar manually.

+1

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


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



From rgolan at redhat.com  Tue Aug  6 07:33:35 2013
From: rgolan at redhat.com (Roy Golan)
Date: Tue, 06 Aug 2013 10:33:35 +0300
Subject: [Users] [Engine-devel] [Feedback required][host-deploy] Fedora-19
	misses tar at minimal setup
In-Reply-To: <2E2BF622-110C-47C1-8C45-111F4B74C379@redhat.com>
References: <733894071.3566217.1374997569084.JavaMail.root@redhat.com>
	<51F4E3E0.600@redhat.com>
	<1199327522.3570177.1375008177999.JavaMail.root@redhat.com>
	<1832045797.3650023.1375082133389.JavaMail.root@redhat.com>
	<1031113778.4037715.1375189923523.JavaMail.root@redhat.com>
	<2E2BF622-110C-47C1-8C45-111F4B74C379@redhat.com>
Message-ID: <5200A6CF.6070107@redhat.com>

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



From cybertimber2000 at hotmail.com  Tue Aug  6 01:57:41 2013
From: cybertimber2000 at hotmail.com (Nicholas Kesick)
Date: Tue, 6 Aug 2013 01:57:41 +0000
Subject: =?utf-8?Q?RE:_[Users]_[Engine-devel]_[Feedback_required][host-deploy]_Fed?=
	=?utf-8?Q?ora-19_misses_tar_at_minimal_setup?=
Message-ID: <BLU404-EAS74852DFC9519F7F3FE8270A75D0@phx.gbl>

I did some testing with Fedora 18 (waiting for the Fedora 19 dvd to finish downloading) and I think that the behavior was the same way in Fedora 18. In Fedora 18 when installing from DVD if you select ?Minimal Install?, you do not get tar.

 

However, if you select ?Minimal install? and ?standard? under the add-on list, you *do* get tar. And if memory serves I learned the hard way in Fedora 18 that a lot of familiar commands are missing in minimal install without the standard add-on items including ?ifconfig?. Yea, you can?t even easily tell what your IP address is!... unless you are used to the ip command.


 

Is there any other commands that are missing on the ?minimal? install that are needed? Would it be easier to mention in the install directions to use the standard add-on if selecting the minimal package set for host deployment?

 

Just thoughts. I also wonder if it would be possible to include tar as a dependency for the RPMs (like ovirt-engine or vdsm) so when installed using a package manager, tar would be checked for.

 

- Nick

 


From: Alon Bar-Lev
Sent: ?August? ?5?, ?2013 ?6?:?02? ?PM
To: users, arch, engine-devel
Subject: Re: [Users] [Engine-devel] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup



Hello Again,

I tend to keep state as-is, require tar at host machine.

Whoever installs Fedora minimal should install tar manually.

I hope Fedora people will add tar per some of the requests, as tar is important utility in *NIX environment.

I do not think that the extra complexity is required.

If you strongly think otherwise, then I prefer to merge the self extracting python script.

Speak now, and emphasis.

Regards,
Alon Bar-Lev.

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

From dcaroest at redhat.com  Tue Aug  6 14:49:06 2013
From: dcaroest at redhat.com (David Caro Estevez)
Date: Tue, 6 Aug 2013 10:49:06 -0400 (EDT)
Subject: Gerrit hooks, second step
In-Reply-To: <51F8A7A1.3030503@redhat.com>
References: <51F8A7A1.3030503@redhat.com>
Message-ID: <1880208219.5178908.1375800546255.JavaMail.root@redhat.com>

Hi everyone,

Finally got the permissions for the bz user, so tomorrow mornign aroung 7:00 am (CEST) will retake the installation of the hooks. No downtime is expected, but I'll send an email once the intervention is finished.

David


----- Original Message -----
> From: "David Caro" <dcaroest at redhat.com>
> To: arch at ovirt.org, "Itamar Heim" <iheim at redhat.com>
> Sent: Wednesday, July 31, 2013 7:58:57 AM
> Subject: Gerrit hooks, second step
> 
> Hi everyone!
> The installation of the second step for the gerrit hooks has to be
> delayed due to the lack of user permissions for the automation bugzilla
> user, will update again as soon as those permissions get changed.
> 
> In the meantime, the hooks will be disabled as there is no point on
> running them without being able to do anything about it.
> 
> Sorry for the waiting!
> 
> --
> David Caro
> 
> Red Hat Czech s.r.o.
> Continuous Integration Engineer - EMEA ENG Virtualization R&D
> 
> Tel.: +420 532 294 605
> Email: dcaro at redhat.com
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic
> RHT Global #: 82-62605
> 
> 
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From dcaroest at redhat.com  Wed Aug  7 06:29:39 2013
From: dcaroest at redhat.com (David Caro)
Date: Wed, 07 Aug 2013 08:29:39 +0200
Subject: Gerrit hooks, second step
In-Reply-To: <1880208219.5178908.1375800546255.JavaMail.root@redhat.com>
References: <51F8A7A1.3030503@redhat.com>
	<1880208219.5178908.1375800546255.JavaMail.root@redhat.com>
Message-ID: <5201E953.2070703@redhat.com>

The hooks are installed and working for ovirt-engine and vdsm repos.

I'll send an update with the wiki docs as soon as it's written :S

If you have any problems or doubts don't hesitate on ping me (dcaro or 
dcaroest in #ovirt, freenode) or send me an email.


Enjoy!

On Tue 06 Aug 2013 04:49:06 PM CEST, David Caro Estevez wrote:
> Hi everyone,
>
> Finally got the permissions for the bz user, so tomorrow mornign aroung 7:00 am (CEST) will retake the installation of the hooks. No downtime is expected, but I'll send an email once the intervention is finished.
>
> David
>
>
> ----- Original Message -----
>> From: "David Caro" <dcaroest at redhat.com>
>> To: arch at ovirt.org, "Itamar Heim" <iheim at redhat.com>
>> Sent: Wednesday, July 31, 2013 7:58:57 AM
>> Subject: Gerrit hooks, second step
>>
>> Hi everyone!
>> The installation of the second step for the gerrit hooks has to be
>> delayed due to the lack of user permissions for the automation bugzilla
>> user, will update again as soon as those permissions get changed.
>>
>> In the meantime, the hooks will be disabled as there is no point on
>> running them without being able to do anything about it.
>>
>> Sorry for the waiting!
>>
>> --
>> David Caro
>>
>> Red Hat Czech s.r.o.
>> Continuous Integration Engineer - EMEA ENG Virtualization R&D
>>
>> Tel.: +420 532 294 605
>> Email: dcaro at redhat.com
>> Web: www.cz.redhat.com
>> Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic
>> RHT Global #: 82-62605
>>
>>
>> _______________________________________________
>> Arch mailing list
>> Arch at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/arch
>>



--
David Caro

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

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


From psebek at redhat.com  Wed Aug  7 10:03:26 2013
From: psebek at redhat.com (Petr Sebek)
Date: Wed, 7 Aug 2013 06:03:26 -0400 (EDT)
Subject: IPv6 support feature
In-Reply-To: <156528418.11887905.1375789404508.JavaMail.root@redhat.com>
Message-ID: <1068076466.12576251.1375869806231.JavaMail.root@redhat.com>

Hi all,

I started to work on IPv6 support for Ovirt. I created feature page [1] that describes every design decision that was made and current progress. This feature should basically allow Ovirt run on IPv6 protocol in the same way as it now works on IPv4. Every host, storage should be able to be IPv6 addressed. Every created network, network interface should be able to have IPv6 addresses.

Feature page [1] contains all changes, but here is some summary to talk about:

IPv6 support affects VDSM, VDSM-API, Ovirt-Engine GUI, Frontend, Backend, REST API.

In Vdsm works was already started and currently we are working on new shape of ifcfg configurator. We will add new class IPv6 to netmodels for address validation. Also will be need some changes in jsonRpcUtils.py.

We presented new attributes in VDSM-API schema for @NetworkOptions and @SetupNetworkNetAttributes:
ipv6addr - IPv6 address for static configuration
ipv6gateway - gateway for static configuration
ipv6autoconf - to use stateless autoconfiguration of IPv6 addresses
dhcpv6 - to use DHCPv6 service for IPv6 addresses and DNS services
Other records of api already using IPv6 attributes or handling address in string format, so in API shouldn't be more changes, but it needs testing.

Ovirt Engine GUI should accept IPv6 address in every place that accepts address, e.g. create new host. We also should be able to set network to be IPv6 ready. We do this by adding option to IPv6 static configuration, stateless autoconfiguration and DHCPv6. Every nic should also provide information about its IPv6 addresses. There are GUI designs at [1].

In Ovirt-Engine Frontend is need to change two classes that validate address string: IpAddressValidation and HostAddressValidation.

I'm not much aware of Ovirt-Engine Backend changes towards IPv6 so I would much appreciate any suggestion.

In REST API we will have to change Network and HostNic records to contain element "ips" instead of "ip". It will directly affect following actions: /api/networks/{network:id}|rel=update, /api/networks|rel=add, /api/hosts/{host:id}/nics/{nic:id}|rel=update, /api/hosts/{host:id}/nics/setupnetworks|rel=setupnetworks. There are few more records that contain field like "address" or "href" that should be tested, but the API needs no change.

Please also note that there still are some opened questions:
Should we provide option to add more than one IPv6 address to Edit Network static configuration? 
What is the meaning of having both IPv4 AND IPv6 address for the same network? E.g., if this is a migration network, which of the addresses should qemu use? 
How to handle multiple gateways with IPv6?
Should we allow DHCPv6 and stateless autoconfiguration at same time?

I would like to hear your reactions and suggestions to this new feature.

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

Thank you,

Petr ?ebek,
Red Hat Ovirt networking team


From amuller at redhat.com  Wed Aug  7 16:45:47 2013
From: amuller at redhat.com (Assaf Muller)
Date: Wed, 7 Aug 2013 12:45:47 -0400 (EDT)
Subject: IPv6 support feature
In-Reply-To: <1068076466.12576251.1375869806231.JavaMail.root@redhat.com>
References: <1068076466.12576251.1375869806231.JavaMail.root@redhat.com>
Message-ID: <1850607918.24767357.1375893947286.JavaMail.root@redhat.com>

I added the multiple gateways feature under VDSM code changes.

----- Original Message -----
From: "Petr Sebek" <psebek at redhat.com>
To: arch at ovirt.org
Cc: mhuntxu at gmail.com
Sent: Wednesday, August 7, 2013 1:03:26 PM
Subject: IPv6 support feature

Hi all,

I started to work on IPv6 support for Ovirt. I created feature page [1] that describes every design decision that was made and current progress. This feature should basically allow Ovirt run on IPv6 protocol in the same way as it now works on IPv4. Every host, storage should be able to be IPv6 addressed. Every created network, network interface should be able to have IPv6 addresses.

Feature page [1] contains all changes, but here is some summary to talk about:

IPv6 support affects VDSM, VDSM-API, Ovirt-Engine GUI, Frontend, Backend, REST API.

In Vdsm works was already started and currently we are working on new shape of ifcfg configurator. We will add new class IPv6 to netmodels for address validation. Also will be need some changes in jsonRpcUtils.py.

We presented new attributes in VDSM-API schema for @NetworkOptions and @SetupNetworkNetAttributes:
ipv6addr - IPv6 address for static configuration
ipv6gateway - gateway for static configuration
ipv6autoconf - to use stateless autoconfiguration of IPv6 addresses
dhcpv6 - to use DHCPv6 service for IPv6 addresses and DNS services
Other records of api already using IPv6 attributes or handling address in string format, so in API shouldn't be more changes, but it needs testing.

Ovirt Engine GUI should accept IPv6 address in every place that accepts address, e.g. create new host. We also should be able to set network to be IPv6 ready. We do this by adding option to IPv6 static configuration, stateless autoconfiguration and DHCPv6. Every nic should also provide information about its IPv6 addresses. There are GUI designs at [1].

In Ovirt-Engine Frontend is need to change two classes that validate address string: IpAddressValidation and HostAddressValidation.

I'm not much aware of Ovirt-Engine Backend changes towards IPv6 so I would much appreciate any suggestion.

In REST API we will have to change Network and HostNic records to contain element "ips" instead of "ip". It will directly affect following actions: /api/networks/{network:id}|rel=update, /api/networks|rel=add, /api/hosts/{host:id}/nics/{nic:id}|rel=update, /api/hosts/{host:id}/nics/setupnetworks|rel=setupnetworks. There are few more records that contain field like "address" or "href" that should be tested, but the API needs no change.

Please also note that there still are some opened questions:
Should we provide option to add more than one IPv6 address to Edit Network static configuration? 
What is the meaning of having both IPv4 AND IPv6 address for the same network? E.g., if this is a migration network, which of the addresses should qemu use? 
How to handle multiple gateways with IPv6?
Should we allow DHCPv6 and stateless autoconfiguration at same time?

I would like to hear your reactions and suggestions to this new feature.

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

Thank you,

Petr ?ebek,
Red Hat Ovirt networking team
_______________________________________________
Arch mailing list
Arch at ovirt.org
http://lists.ovirt.org/mailman/listinfo/arch


From gvallare at redhat.com  Thu Aug  8 10:48:17 2013
From: gvallare at redhat.com (Giuseppe Vallarelli)
Date: Thu, 8 Aug 2013 06:48:17 -0400 (EDT)
Subject: Network traffic shaping.
In-Reply-To: <51FF5E8A.4010409@redhat.com>
References: <1809186597.402470.1373280341185.JavaMail.root@redhat.com>
	<51FF5E8A.4010409@redhat.com>
Message-ID: <927454428.13264363.1375958897072.JavaMail.root@redhat.com>

----- Original Message -----
| From: "Lior Vernia" <lvernia at redhat.com>
| To: "Giuseppe Vallarelli" <gvallare at redhat.com>
| Cc: arch at ovirt.org
| Sent: Monday, August 5, 2013 10:12:58 AM
| Subject: Re: Network traffic shaping.
| 
| Hey Giuseppe and everyone else,

Hello Lior,

| 
| Sorry for being late to the party. I've read all the e-mails and have
| been rolling the idea around in my head for a couple of days. Here are
| my two main thoughts, more UX-oriented, let me know what you think.
| 
| 1. I would prefer not to be able to create a host network QoS entity,
| which doesn't really have any significance as an independent entity.
| However, I would like to be able to copy the configuration from one host
| to another for the same network, right? So how about we add a
| "Copy/Clone from" UI field that lets you choose a host from which to
| copy the QoS configuration for that network?
| 
| This would appear next to the manual configuration, so users would still
| be able to input other custom values if they prefer. Once we do this, we
| also won't need to enable to define it on a per-network basis, where it
| doesn't really make sense, but we could do with just defining it for
| <host,network> pairs (i.e. say in the edit network dialog when attaching
| a network to a host NIC).

I like your idea and I think it's a good simplification overall.

| To further clarify, copying/cloning would be INSTEAD OF creating a
| Network QoS through some subtab, naming it, and then picking it in a
| list box. There would be no way to create a named host network QoS
| configuration.

I thought it was the right approach simply because it's what have been implemented
already in: http://www.ovirt.org/Features/Network_QoS
(I'll refer to it as Network_QoS from now on)

I didn't want to have 2 different ways to create what I would call
simply QoS (the infamous 6 values) that can be applied a host network,
vnic and so on. That's where the idea of associating a predefined Qos
comes from.

| 2. I would prefer to not have to fill six fields to define QoS. Even if
| there are default values to these fields, it makes it look complicated.

I'm completely with you on this - libvirt only requires the average
attribute, burst and peak are optional, but again for uniformity of
behaviour with Network_QoS I opted to have all 6 user defined.
Perhaps the uniform behaviour is misplaced in this case, I thought
that it might be confusing for the user to provide 6 values in Network_Qos
and only one, average, for QoS but host network side.

I discussed to have only one compulsory value in a different thread
discussion "network and vnic qos" but Doron gave me a rationale (SLA related)
for having all six values defined.

| I think these six values could be replaced by just one typical value for
| the network's traffic. The six-field configuration would still be
| accessible somehow, but I don't want it to be necessary.

+1

| 
| Regarding the empty values discussion, I'm not saying to leave the
| values empty. I get why we want to fill them. But fill them ourselves in
| some reasonable way that users won't be aware of unless they go into
| advanced settings.
| 
| An alternative might be to allow two values, one for inbound traffic and
| another for outbound traffic. However, I think this would only be
| necessary if a user wants to actually manage both inbound and outbound
| traffic in detail, which sounds to me like the uncommon use case. In
| general people would just want to avoid host traffic, either inbound or
| outbound, being taken over by one network.

That's a good idea. My only concern is how does it fit with QoS in the
engine as a whole ? It's almost like we have different definitions of QoS,
which might be fine but maybe we want to find a different naming convention.


| And again, distinguishing
| between inbound and outbound would still be accessible through some
| advanced settings.
| 
| Lior.

Thanks for the contribute, hope my feedback will help.

Giuseppe

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


From lvernia at redhat.com  Thu Aug  8 11:19:41 2013
From: lvernia at redhat.com (Lior Vernia)
Date: Thu, 08 Aug 2013 14:19:41 +0300
Subject: Network traffic shaping.
In-Reply-To: <927454428.13264363.1375958897072.JavaMail.root@redhat.com>
References: <1809186597.402470.1373280341185.JavaMail.root@redhat.com>
	<51FF5E8A.4010409@redhat.com>
	<927454428.13264363.1375958897072.JavaMail.root@redhat.com>
Message-ID: <52037ECD.2040307@redhat.com>



On 08/08/13 13:48, Giuseppe Vallarelli wrote:
> ----- Original Message -----
> | From: "Lior Vernia" <lvernia at redhat.com>
> | To: "Giuseppe Vallarelli" <gvallare at redhat.com>
> | Cc: arch at ovirt.org
> | Sent: Monday, August 5, 2013 10:12:58 AM
> | Subject: Re: Network traffic shaping.
> | 
> | Hey Giuseppe and everyone else,
> 
> Hello Lior,
> 
> | 
> | Sorry for being late to the party. I've read all the e-mails and have
> | been rolling the idea around in my head for a couple of days. Here are
> | my two main thoughts, more UX-oriented, let me know what you think.
> | 
> | 1. I would prefer not to be able to create a host network QoS entity,
> | which doesn't really have any significance as an independent entity.
> | However, I would like to be able to copy the configuration from one host
> | to another for the same network, right? So how about we add a
> | "Copy/Clone from" UI field that lets you choose a host from which to
> | copy the QoS configuration for that network?
> | 
> | This would appear next to the manual configuration, so users would still
> | be able to input other custom values if they prefer. Once we do this, we
> | also won't need to enable to define it on a per-network basis, where it
> | doesn't really make sense, but we could do with just defining it for
> | <host,network> pairs (i.e. say in the edit network dialog when attaching
> | a network to a host NIC).
> 
> I like your idea and I think it's a good simplification overall.
> 
> | To further clarify, copying/cloning would be INSTEAD OF creating a
> | Network QoS through some subtab, naming it, and then picking it in a
> | list box. There would be no way to create a named host network QoS
> | configuration.
> 
> I thought it was the right approach simply because it's what have been implemented
> already in: http://www.ovirt.org/Features/Network_QoS
> (I'll refer to it as Network_QoS from now on)
> 
> I didn't want to have 2 different ways to create what I would call
> simply QoS (the infamous 6 values) that can be applied a host network,
> vnic and so on. That's where the idea of associating a predefined Qos
> comes from.
> 
> | 2. I would prefer to not have to fill six fields to define QoS. Even if
> | there are default values to these fields, it makes it look complicated.
> 
> I'm completely with you on this - libvirt only requires the average
> attribute, burst and peak are optional, but again for uniformity of
> behaviour with Network_QoS I opted to have all 6 user defined.
> Perhaps the uniform behaviour is misplaced in this case, I thought
> that it might be confusing for the user to provide 6 values in Network_Qos
> and only one, average, for QoS but host network side.
> 
> I discussed to have only one compulsory value in a different thread
> discussion "network and vnic qos" but Doron gave me a rationale (SLA related)
> for having all six values defined.

Yeah, I saw that discussion and I see Doron's point. I just wanna
clarify that all 6 values would still be set as per those comments - but
this assignment would be transparent to the users, unless they access
the "advanced settings" (still not sure how that should be accessed).

> 
> | I think these six values could be replaced by just one typical value for
> | the network's traffic. The six-field configuration would still be
> | accessible somehow, but I don't want it to be necessary.
> 
> +1
> 
> | 
> | Regarding the empty values discussion, I'm not saying to leave the
> | values empty. I get why we want to fill them. But fill them ourselves in
> | some reasonable way that users won't be aware of unless they go into
> | advanced settings.
> | 
> | An alternative might be to allow two values, one for inbound traffic and
> | another for outbound traffic. However, I think this would only be
> | necessary if a user wants to actually manage both inbound and outbound
> | traffic in detail, which sounds to me like the uncommon use case. In
> | general people would just want to avoid host traffic, either inbound or
> | outbound, being taken over by one network.
> 
> That's a good idea. My only concern is how does it fit with QoS in the
> engine as a whole ? It's almost like we have different definitions of QoS,
> which might be fine but maybe we want to find a different naming convention.
> 

I'm all for a different naming convention anyway, as we do not really
provide network QoS at the moment - networks are DC-wide entities and we
can't guarantee anything about what happens when packets leave the host.
I actually think "Host Traffic Shaping" is pretty good, I would maybe
call it "Host Traffic Control" because control is a simpler word to
fathom than shaping.

> 
> | And again, distinguishing
> | between inbound and outbound would still be accessible through some
> | advanced settings.
> | 
> | Lior.
> 
> Thanks for the contribute, hope my feedback will help.
> 
> Giuseppe
> 
> | 
> | On 08/07/13 13:45, Giuseppe Vallarelli wrote:
> | > Hi everybody, I'm working to implement traffic shaping at the network level
> | > [1].
> | > This feature is composed by two distinct parts: definition of traffic
> | > shaping
> | > for a logical network entity and optional redefinition of traffic shaping
> | > when
> | > the user is doing a Setup Host Networks task. Initial focus will be on
> | > first
> | > part. There are some points of contact with Network Qos [2] that's why I
> | > proposed
> | > to reuse some code backend side.
> | > 
> | > Cheers, Giuseppe
> | > 
> | > [1] http://www.ovirt.org/Features/Network_traffic_shaping
> | > [2] http://www.ovirt.org/Features/Network_QoS
> | > _______________________________________________
> | > Arch mailing list
> | > Arch at ovirt.org
> | > http://lists.ovirt.org/mailman/listinfo/arch
> | > 
> | 
> 


From sabose at redhat.com  Mon Aug 12 05:41:55 2013
From: sabose at redhat.com (Sahina Bose)
Date: Mon, 12 Aug 2013 11:11:55 +0530
Subject: Gluster Volume asynchronous tasks
Message-ID: <520875A3.6020600@redhat.com>

Hi all,

We are working on a feature to add support to start and monitor gluster 
volume asynchronous tasks (like rebalancing a gluster volume, removing 
brick from volume ) from the oVirt engine.

The operations can be started from the Volumes tab or the Bricks sub-tab 
using the Rebalance, Remove options.
These are long running operations which can be monitored using a task id 
returned from Gluster. We are planning to add the monitoring in the 
existing Task sub tab

The feature description and User flows are at 
http://www.ovirt.org/Features/Gluster_Volume_Asynchronous_Tasks_Management

The detailed design (including REST API design) is at 
http://www.ovirt.org/Features/Detailed_Gluster_Volume_Asynchronous_Tasks_Management.

I would really appreciate if you could review and provide your valuable 
feedback.

thanks
sahina


From emesika at redhat.com  Mon Aug 12 07:51:07 2013
From: emesika at redhat.com (Eli Mesika)
Date: Mon, 12 Aug 2013 03:51:07 -0400 (EDT)
Subject: [Engine-devel] Gluster Volume asynchronous tasks
In-Reply-To: <520875A3.6020600@redhat.com>
References: <520875A3.6020600@redhat.com>
Message-ID: <1731655114.276503.1376293867438.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Sahina Bose" <sabose at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>, arch at ovirt.org, "Michael Pasternak" <mpastern at redhat.com>
> Sent: Monday, August 12, 2013 8:41:55 AM
> Subject: [Engine-devel] Gluster Volume asynchronous tasks
> 
> Hi all,
> 
> We are working on a feature to add support to start and monitor gluster
> volume asynchronous tasks (like rebalancing a gluster volume, removing
> brick from volume ) from the oVirt engine.
> 
> The operations can be started from the Volumes tab or the Bricks sub-tab
> using the Rebalance, Remove options.
> These are long running operations which can be monitored using a task id
> returned from Gluster. We are planning to add the monitoring in the
> existing Task sub tab
> 
> The feature description and User flows are at
> http://www.ovirt.org/Features/Gluster_Volume_Asynchronous_Tasks_Management
> 
> The detailed design (including REST API design) is at
> http://www.ovirt.org/Features/Detailed_Gluster_Volume_Asynchronous_Tasks_Management.
> 
> I would really appreciate if you could review and provide your valuable
> feedback.

I Sahina
Why not using 6the External Tasks feature introduced for 3.3 for those Gluster tasks ???
http://www.ovirt.org/Features/Design/DetailedExternalTasks



> 
> thanks
> sahina
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From sabose at redhat.com  Mon Aug 12 08:51:15 2013
From: sabose at redhat.com (Sahina Bose)
Date: Mon, 12 Aug 2013 14:21:15 +0530
Subject: [Engine-devel] Gluster Volume asynchronous tasks
In-Reply-To: <1731655114.276503.1376293867438.JavaMail.root@redhat.com>
References: <520875A3.6020600@redhat.com>
	<1731655114.276503.1376293867438.JavaMail.root@redhat.com>
Message-ID: <5208A203.2080101@redhat.com>


On 08/12/2013 01:21 PM, Eli Mesika wrote:
>
> ----- Original Message -----
>> From: "Sahina Bose" <sabose at redhat.com>
>> To: "engine-devel" <engine-devel at ovirt.org>, arch at ovirt.org, "Michael Pasternak" <mpastern at redhat.com>
>> Sent: Monday, August 12, 2013 8:41:55 AM
>> Subject: [Engine-devel] Gluster Volume asynchronous tasks
>>
>> Hi all,
>>
>> We are working on a feature to add support to start and monitor gluster
>> volume asynchronous tasks (like rebalancing a gluster volume, removing
>> brick from volume ) from the oVirt engine.
>>
>> The operations can be started from the Volumes tab or the Bricks sub-tab
>> using the Rebalance, Remove options.
>> These are long running operations which can be monitored using a task id
>> returned from Gluster. We are planning to add the monitoring in the
>> existing Task sub tab
>>
>> The feature description and User flows are at
>> http://www.ovirt.org/Features/Gluster_Volume_Asynchronous_Tasks_Management
>>
>> The detailed design (including REST API design) is at
>> http://www.ovirt.org/Features/Detailed_Gluster_Volume_Asynchronous_Tasks_Management.
>>
>> I would really appreciate if you could review and provide your valuable
>> feedback.
> I Sahina
> Why not using 6the External Tasks feature introduced for 3.3 for those Gluster tasks ???
> http://www.ovirt.org/Features/Design/DetailedExternalTasks
Hi Eli,

We still want to be able to start and stop these operations from the engine.
So, when a user wants to say, rebalance a volume, they would go select 
the volume and click on Rebalance Start.
This would then call the BLL command to start rebalance which will 
invoke the corresponding vdsm verb to start the rebalance on the volume.
This is the same as existing flow for other commands. The only 
difference is the vdsm verb will return the task id from gluster, for 
the rebalance operation that was started. And we will monitor the 
progress of the task using the gluster task id (by calling a gluster 
command)

I'm not sure how ExternalTasks would fit in here? I was thinking of 
using ExternalTask support for adding Job/Steps to engine when the 
operation is started outside of engine, that is, from Gluster CLI.
Please correct me if I'm missing something.


>
>
>
>> thanks
>> sahina
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>



From yzaslavs at redhat.com  Mon Aug 12 09:58:15 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Mon, 12 Aug 2013 05:58:15 -0400 (EDT)
Subject: [Engine-devel] Gluster Volume asynchronous tasks
In-Reply-To: <5208A203.2080101@redhat.com>
References: <520875A3.6020600@redhat.com>
	<1731655114.276503.1376293867438.JavaMail.root@redhat.com>
	<5208A203.2080101@redhat.com>
Message-ID: <1028116748.433511.1376301495249.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Sahina Bose" <sabose at redhat.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, arch at ovirt.org
> Sent: Monday, August 12, 2013 11:51:15 AM
> Subject: Re: [Engine-devel] Gluster Volume asynchronous tasks
> 
> 
> On 08/12/2013 01:21 PM, Eli Mesika wrote:
> >
> > ----- Original Message -----
> >> From: "Sahina Bose" <sabose at redhat.com>
> >> To: "engine-devel" <engine-devel at ovirt.org>, arch at ovirt.org, "Michael
> >> Pasternak" <mpastern at redhat.com>
> >> Sent: Monday, August 12, 2013 8:41:55 AM
> >> Subject: [Engine-devel] Gluster Volume asynchronous tasks
> >>
> >> Hi all,
> >>
> >> We are working on a feature to add support to start and monitor gluster
> >> volume asynchronous tasks (like rebalancing a gluster volume, removing
> >> brick from volume ) from the oVirt engine.
> >>
> >> The operations can be started from the Volumes tab or the Bricks sub-tab
> >> using the Rebalance, Remove options.
> >> These are long running operations which can be monitored using a task id
> >> returned from Gluster. We are planning to add the monitoring in the
> >> existing Task sub tab
> >>
> >> The feature description and User flows are at
> >> http://www.ovirt.org/Features/Gluster_Volume_Asynchronous_Tasks_Management
> >>
> >> The detailed design (including REST API design) is at
> >> http://www.ovirt.org/Features/Detailed_Gluster_Volume_Asynchronous_Tasks_Management.
> >>
> >> I would really appreciate if you could review and provide your valuable
> >> feedback.
> > I Sahina
> > Why not using 6the External Tasks feature introduced for 3.3 for those
> > Gluster tasks ???
> > http://www.ovirt.org/Features/Design/DetailedExternalTasks
> Hi Eli,
> 
> We still want to be able to start and stop these operations from the engine.
> So, when a user wants to say, rebalance a volume, they would go select
> the volume and click on Rebalance Start.
> This would then call the BLL command to start rebalance which will
> invoke the corresponding vdsm verb to start the rebalance on the volume.
> This is the same as existing flow for other commands. The only
> difference is the vdsm verb will return the task id from gluster, for
> the rebalance operation that was started. And we will monitor the
> progress of the task using the gluster task id (by calling a gluster
> command)
> 
> I'm not sure how ExternalTasks would fit in here? I was thinking of
> using ExternalTask support for adding Job/Steps to engine when the
> operation is started outside of engine, that is, from Gluster CLI.
> Please correct me if I'm missing something.

Does this mean that from Gluster CLI you will not try and invoke the rebalance command ?
(I mean, I should either use Gluster CLI or Engine's REST API?)

> 
> 
> >
> >
> >
> >> thanks
> >> sahina
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From sabose at redhat.com  Mon Aug 12 10:09:29 2013
From: sabose at redhat.com (Sahina Bose)
Date: Mon, 12 Aug 2013 15:39:29 +0530
Subject: [Engine-devel] Gluster Volume asynchronous tasks
In-Reply-To: <1028116748.433511.1376301495249.JavaMail.root@redhat.com>
References: <520875A3.6020600@redhat.com>
	<1731655114.276503.1376293867438.JavaMail.root@redhat.com>
	<5208A203.2080101@redhat.com>
	<1028116748.433511.1376301495249.JavaMail.root@redhat.com>
Message-ID: <5208B459.7000808@redhat.com>


On 08/12/2013 03:28 PM, Yair Zaslavsky wrote:
>
> ----- Original Message -----
>> From: "Sahina Bose" <sabose at redhat.com>
>> To: "Eli Mesika" <emesika at redhat.com>
>> Cc: "engine-devel" <engine-devel at ovirt.org>, arch at ovirt.org
>> Sent: Monday, August 12, 2013 11:51:15 AM
>> Subject: Re: [Engine-devel] Gluster Volume asynchronous tasks
>>
>>
>> On 08/12/2013 01:21 PM, Eli Mesika wrote:
>>> ----- Original Message -----
>>>> From: "Sahina Bose" <sabose at redhat.com>
>>>> To: "engine-devel" <engine-devel at ovirt.org>, arch at ovirt.org, "Michael
>>>> Pasternak" <mpastern at redhat.com>
>>>> Sent: Monday, August 12, 2013 8:41:55 AM
>>>> Subject: [Engine-devel] Gluster Volume asynchronous tasks
>>>>
>>>> Hi all,
>>>>
>>>> We are working on a feature to add support to start and monitor gluster
>>>> volume asynchronous tasks (like rebalancing a gluster volume, removing
>>>> brick from volume ) from the oVirt engine.
>>>>
>>>> The operations can be started from the Volumes tab or the Bricks sub-tab
>>>> using the Rebalance, Remove options.
>>>> These are long running operations which can be monitored using a task id
>>>> returned from Gluster. We are planning to add the monitoring in the
>>>> existing Task sub tab
>>>>
>>>> The feature description and User flows are at
>>>> http://www.ovirt.org/Features/Gluster_Volume_Asynchronous_Tasks_Management
>>>>
>>>> The detailed design (including REST API design) is at
>>>> http://www.ovirt.org/Features/Detailed_Gluster_Volume_Asynchronous_Tasks_Management.
>>>>
>>>> I would really appreciate if you could review and provide your valuable
>>>> feedback.
>>> I Sahina
>>> Why not using 6the External Tasks feature introduced for 3.3 for those
>>> Gluster tasks ???
>>> http://www.ovirt.org/Features/Design/DetailedExternalTasks
>> Hi Eli,
>>
>> We still want to be able to start and stop these operations from the engine.
>> So, when a user wants to say, rebalance a volume, they would go select
>> the volume and click on Rebalance Start.
>> This would then call the BLL command to start rebalance which will
>> invoke the corresponding vdsm verb to start the rebalance on the volume.
>> This is the same as existing flow for other commands. The only
>> difference is the vdsm verb will return the task id from gluster, for
>> the rebalance operation that was started. And we will monitor the
>> progress of the task using the gluster task id (by calling a gluster
>> command)
>>
>> I'm not sure how ExternalTasks would fit in here? I was thinking of
>> using ExternalTask support for adding Job/Steps to engine when the
>> operation is started outside of engine, that is, from Gluster CLI.
>> Please correct me if I'm missing something.
> Does this mean that from Gluster CLI you will not try and invoke the rebalance command ?
> (I mean, I should either use Gluster CLI or Engine's REST API?)
Rebalance volume command could be invoked in any of the following ways:
1. From the console UI (clicking on Rebalance as shown in 
http://www.ovirt.org/Features/Gluster_Volume_Asynchronous_Tasks_Management#Rebalance_Volume)
2. Using REST API
3. Outside of engine, from Gluster CLI - In such cases, the engine 
should detect that a user has triggered rebalance operation outside the 
engine, and allow the user to monitor progress of this from the engine. 
This is where, we need support to add a Job for an operation that was 
started externally, so that it can be seen in the Tasks tab.
>
>>
>>>
>>>
>>>> thanks
>>>> sahina
>>>> _______________________________________________
>>>> Engine-devel mailing list
>>>> Engine-devel at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>



From iheim at redhat.com  Wed Aug 14 11:37:42 2013
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 14 Aug 2013 14:37:42 +0300
Subject: oVirt updates - August 13th 2013
Message-ID: <520B6C06.8090005@redhat.com>

(some updates I collected from past weeks)

General:
- great oVirt 3.3 test day with 80 bugs reported on various new 3.3
   features.
- oVirt 3.3 RC build soon to come.
- various deep dive sessions started on new 3.3 features[9]
   glance, neutron, power management and async tasks covered so far.


Deployment:
- Karli Sj?berg documented the process of going from oVirt-3.1 on
   Fedora to oVirt-3.2 on CentOS[3]

- Ren? Koch announced version 1.2.1 of the Nagios monitoring plugin[6]

- Christophe Fergeau announced[1] a new spice-xpi 2.8.90 with windows
   support (and proxy support as well)

- Eyal Edri announced ovirt rpm's are available for Fedora 19[7]

- Ren? van der Linden blogged about configuring IPA for oVirt[12]
   also has entries on all of this oVirt deployment[13]

Devel:
- gerrit was upgraded to gerrit 2.6. during the upgrade I forgot David
   Caro work on replacing the robots file so bing servers overloaded the
   server again.
   Juan was kind enough to send a patch to the gerrit project[2] to make
   the robots file configurable so we'll avoid this in the future (well,
   from gerrit 2.8).

- A Clojure library to provision virtual machines in ovirt[11]

Conferences/Talks:
- (upcoming) greg padget will cover new sla mechanism in ovirt[8] at
   LinuxCon/CloudOpen NA (September 17th, New Orleans)
- (upcoming) KvmForum and oVirt sessions at LinuxCon Europe in October

- (past) Udayendu Kar covered KVM and oVirt in an Engineering College
   via a few talks and hands-on[5]
- (past) Livnat Peer did an intro to ovirt session in Israel's open
   source conference August Penguin.


Related:
- Jon Benedict of NetApp published an update on their VSC beta[4]
- VMWare vCloud Automation Center 5.2 added support for RHEV 3.1[10]

Thanks,
    Itamar


[1] http://lists.ovirt.org/pipermail/users/2013-August/015624.html
[2] https://gerrit-review.googlesource.com/48411
[3] http://lists.ovirt.org/pipermail/users/2013-August/015609.html
[4] http://captainkvm.com/2013/08/vsc-for-rhev-beta-is-live/
[5] http://udayendu.livejournal.com/671.html
[6] http://lists.ovirt.org/pipermail/users/2013-July/015352.html
[7] http://resources.ovirt.org/releases/nightly/rpm/Fedora/19
[8] 
http://linuxconcloudopenna2013.sched.org/event/983e0cfa39a71d80e6f5000a9b553cf8?iframe=no&w=900&sidebar=yes&bg=no#.UgtfEE18SsA
[9] http://www.ovirt.org/OVirt_3.3_release_notes
[10] http://www.vmware.com/pdf/vcac-52-kvm-guide.pdf
[11] https://github.com/RedHatQE/ovirt.client
[12] 
https://www.rvanderlinden.net/wordpress/ovirt/administrator-portal/administrator-portal-authentication-via-ipa/
[13] https://www.rvanderlinden.net/wordpress/ovirt/


From iheim at redhat.com  Mon Aug 19 22:30:40 2013
From: iheim at redhat.com (Itamar Heim)
Date: Mon, 19 Aug 2013 18:30:40 -0400
Subject: [Engine-devel] Gluster Volume asynchronous tasks
In-Reply-To: <5208B459.7000808@redhat.com>
References: <520875A3.6020600@redhat.com>
	<1731655114.276503.1376293867438.JavaMail.root@redhat.com>
	<5208A203.2080101@redhat.com>
	<1028116748.433511.1376301495249.JavaMail.root@redhat.com>
	<5208B459.7000808@redhat.com>
Message-ID: <52129C90.1030407@redhat.com>

On 08/12/2013 06:09 AM, Sahina Bose wrote:
>
> On 08/12/2013 03:28 PM, Yair Zaslavsky wrote:
>>
>> ----- Original Message -----
>>> From: "Sahina Bose" <sabose at redhat.com>
>>> To: "Eli Mesika" <emesika at redhat.com>
>>> Cc: "engine-devel" <engine-devel at ovirt.org>, arch at ovirt.org
>>> Sent: Monday, August 12, 2013 11:51:15 AM
>>> Subject: Re: [Engine-devel] Gluster Volume asynchronous tasks
>>>
>>>
>>> On 08/12/2013 01:21 PM, Eli Mesika wrote:
>>>> ----- Original Message -----
>>>>> From: "Sahina Bose" <sabose at redhat.com>
>>>>> To: "engine-devel" <engine-devel at ovirt.org>, arch at ovirt.org, "Michael
>>>>> Pasternak" <mpastern at redhat.com>
>>>>> Sent: Monday, August 12, 2013 8:41:55 AM
>>>>> Subject: [Engine-devel] Gluster Volume asynchronous tasks
>>>>>
>>>>> Hi all,
>>>>>
>>>>> We are working on a feature to add support to start and monitor
>>>>> gluster
>>>>> volume asynchronous tasks (like rebalancing a gluster volume, removing
>>>>> brick from volume ) from the oVirt engine.
>>>>>
>>>>> The operations can be started from the Volumes tab or the Bricks
>>>>> sub-tab
>>>>> using the Rebalance, Remove options.
>>>>> These are long running operations which can be monitored using a
>>>>> task id
>>>>> returned from Gluster. We are planning to add the monitoring in the
>>>>> existing Task sub tab
>>>>>
>>>>> The feature description and User flows are at
>>>>> http://www.ovirt.org/Features/Gluster_Volume_Asynchronous_Tasks_Management
>>>>>
>>>>>
>>>>> The detailed design (including REST API design) is at
>>>>> http://www.ovirt.org/Features/Detailed_Gluster_Volume_Asynchronous_Tasks_Management.
>>>>>
>>>>>
>>>>> I would really appreciate if you could review and provide your
>>>>> valuable
>>>>> feedback.
>>>> I Sahina
>>>> Why not using 6the External Tasks feature introduced for 3.3 for those
>>>> Gluster tasks ???
>>>> http://www.ovirt.org/Features/Design/DetailedExternalTasks
>>> Hi Eli,
>>>
>>> We still want to be able to start and stop these operations from the
>>> engine.
>>> So, when a user wants to say, rebalance a volume, they would go select
>>> the volume and click on Rebalance Start.
>>> This would then call the BLL command to start rebalance which will
>>> invoke the corresponding vdsm verb to start the rebalance on the volume.
>>> This is the same as existing flow for other commands. The only
>>> difference is the vdsm verb will return the task id from gluster, for
>>> the rebalance operation that was started. And we will monitor the
>>> progress of the task using the gluster task id (by calling a gluster
>>> command)
>>>
>>> I'm not sure how ExternalTasks would fit in here? I was thinking of
>>> using ExternalTask support for adding Job/Steps to engine when the
>>> operation is started outside of engine, that is, from Gluster CLI.
>>> Please correct me if I'm missing something.
>> Does this mean that from Gluster CLI you will not try and invoke the
>> rebalance command ?
>> (I mean, I should either use Gluster CLI or Engine's REST API?)
> Rebalance volume command could be invoked in any of the following ways:
> 1. From the console UI (clicking on Rebalance as shown in
> http://www.ovirt.org/Features/Gluster_Volume_Asynchronous_Tasks_Management#Rebalance_Volume)
>
> 2. Using REST API
> 3. Outside of engine, from Gluster CLI - In such cases, the engine
> should detect that a user has triggered rebalance operation outside the
> engine, and allow the user to monitor progress of this from the engine.
> This is where, we need support to add a Job for an operation that was
> started externally, so that it can be seen in the Tasks tab.

and still, it should be considered an internal task, since the engine is 
managing it / detected it.



From mburns at redhat.com  Tue Aug 20 14:26:25 2013
From: mburns at redhat.com (Mike Burns)
Date: Tue, 20 Aug 2013 10:26:25 -0400
Subject: oVirt Node feature requests for 3.1 release
Message-ID: <52137C91.1070607@redhat.com>

Hi all,

We're going into our initial planning cycle for oVirt Node 3.1 and are 
looking for features that are interesting to people.  There are a number 
of ideas that were proposed on our weekly meeting that are listed below. 
  If you would really like to see one or more of the features below, 
please let us know.  If you have an idea for another feature, please 
also reply with a short abstract for that feature.

Thanks

Mike

* Package Refactoring -- make it easier to build custom images for 
different use cases without pulling in unnecessary functionality (I.E., 
virt capabilities when acting as a storage node only).
* re-writes of the storage and installer modules for easier testing
* openvswitch support
* live install of plugins (install on a running system, possibly with 
push model)
* Some sort of announcement model where we identify who we are and what 
we can do to a system (for registration purposes)
* kimchi plugin (http://github.com/kimchi-project/kimchi) for standalone 
use cases


From mburns at redhat.com  Tue Aug 20 14:35:53 2013
From: mburns at redhat.com (Mike Burns)
Date: Tue, 20 Aug 2013 10:35:53 -0400
Subject: [node-devel] oVirt Node feature requests for 3.1 release
In-Reply-To: <52137C91.1070607@redhat.com>
References: <52137C91.1070607@redhat.com>
Message-ID: <52137EC9.2040904@redhat.com>

On 08/20/2013 10:26 AM, Mike Burns wrote:
> Hi all,
>
> We're going into our initial planning cycle for oVirt Node 3.1 and are
> looking for features that are interesting to people.  There are a number
> of ideas that were proposed on our weekly meeting that are listed below.
>   If you would really like to see one or more of the features below,
> please let us know.  If you have an idea for another feature, please
> also reply with a short abstract for that feature.
>
> Thanks
>
> Mike
>
> * Package Refactoring -- make it easier to build custom images for
> different use cases without pulling in unnecessary functionality (I.E.,
> virt capabilities when acting as a storage node only).
> * re-writes of the storage and installer modules for easier testing
> * openvswitch support
> * live install of plugins (install on a running system, possibly with
> push model)
> * Some sort of announcement model where we identify who we are and what
> we can do to a system (for registration purposes)
> * kimchi plugin (http://github.com/kimchi-project/kimchi) for standalone
> use cases

* investigate LiveMedia and oz for building ovirt-node

> _______________________________________________
> node-devel mailing list
> node-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/node-devel



From fabiand at redhat.com  Tue Aug 20 16:12:16 2013
From: fabiand at redhat.com (Fabian Deutsch)
Date: Tue, 20 Aug 2013 18:12:16 +0200
Subject: [node-devel] oVirt Node feature requests for 3.1 release
In-Reply-To: <52137EC9.2040904@redhat.com>
References: <52137C91.1070607@redhat.com> <52137EC9.2040904@redhat.com>
Message-ID: <1377015136.10356.0.camel@fdeutsch-laptop.local>

Am Dienstag, den 20.08.2013, 10:35 -0400 schrieb Mike Burns:
> 
> > * Package Refactoring -- make it easier to build custom images for
> > different use cases without pulling in unnecessary functionality
> (I.E.,
> > virt capabilities when acting as a storage node only).
> > * re-writes of the storage and installer modules for easier testing
> > * openvswitch support
> > * live install of plugins (install on a running system, possibly
> with
> > push model)
> > * Some sort of announcement model where we identify who we are and
> what
> > we can do to a system (for registration purposes)
> > * kimchi plugin (http://github.com/kimchi-project/kimchi) for
> standalone
> > use cases
> 
> * investigate LiveMedia and oz for building ovirt-node

* plugin for standalone/virt-manager mode. To have local/private 
  instances to be used with virt-manager



From mburns at redhat.com  Tue Aug 20 16:13:32 2013
From: mburns at redhat.com (Mike Burns)
Date: Tue, 20 Aug 2013 12:13:32 -0400
Subject: [node-devel] oVirt Node feature requests for 3.1 release
In-Reply-To: <1377015136.10356.0.camel@fdeutsch-laptop.local>
References: <52137C91.1070607@redhat.com> <52137EC9.2040904@redhat.com>
	<1377015136.10356.0.camel@fdeutsch-laptop.local>
Message-ID: <521395AC.9050809@redhat.com>

On 08/20/2013 12:12 PM, Fabian Deutsch wrote:
> Am Dienstag, den 20.08.2013, 10:35 -0400 schrieb Mike Burns:
>>
>>> * Package Refactoring -- make it easier to build custom images for
>>> different use cases without pulling in unnecessary functionality
>> (I.E.,
>>> virt capabilities when acting as a storage node only).
>>> * re-writes of the storage and installer modules for easier testing
>>> * openvswitch support
>>> * live install of plugins (install on a running system, possibly
>> with
>>> push model)
>>> * Some sort of announcement model where we identify who we are and
>> what
>>> we can do to a system (for registration purposes)
>>> * kimchi plugin (http://github.com/kimchi-project/kimchi) for
>> standalone
>>> use cases
>>
>> * investigate LiveMedia and oz for building ovirt-node
>
> * plugin for standalone/virt-manager mode. To have local/private
>    instances to be used with virt-manager

Check out kimchi, that is basically what it does.  It's not 
virt-manager, but a somewhat thinner, cleaner interface.

>
> _______________________________________________
> node-devel mailing list
> node-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/node-devel
>



From sabose at redhat.com  Wed Aug 21 04:46:32 2013
From: sabose at redhat.com (Sahina Bose)
Date: Wed, 21 Aug 2013 10:16:32 +0530
Subject: [Engine-devel] Gluster Volume asynchronous tasks
In-Reply-To: <52129C90.1030407@redhat.com>
References: <520875A3.6020600@redhat.com>
	<1731655114.276503.1376293867438.JavaMail.root@redhat.com>
	<5208A203.2080101@redhat.com>
	<1028116748.433511.1376301495249.JavaMail.root@redhat.com>
	<5208B459.7000808@redhat.com> <52129C90.1030407@redhat.com>
Message-ID: <52144628.9070506@redhat.com>


On 08/20/2013 04:00 AM, Itamar Heim wrote:
> On 08/12/2013 06:09 AM, Sahina Bose wrote:
>>
>> On 08/12/2013 03:28 PM, Yair Zaslavsky wrote:
>>>
>>> ----- Original Message -----
>>>> From: "Sahina Bose" <sabose at redhat.com>
>>>> To: "Eli Mesika" <emesika at redhat.com>
>>>> Cc: "engine-devel" <engine-devel at ovirt.org>, arch at ovirt.org
>>>> Sent: Monday, August 12, 2013 11:51:15 AM
>>>> Subject: Re: [Engine-devel] Gluster Volume asynchronous tasks
>>>>
>>>>
>>>> On 08/12/2013 01:21 PM, Eli Mesika wrote:
>>>>> ----- Original Message -----
>>>>>> From: "Sahina Bose" <sabose at redhat.com>
>>>>>> To: "engine-devel" <engine-devel at ovirt.org>, arch at ovirt.org, 
>>>>>> "Michael
>>>>>> Pasternak" <mpastern at redhat.com>
>>>>>> Sent: Monday, August 12, 2013 8:41:55 AM
>>>>>> Subject: [Engine-devel] Gluster Volume asynchronous tasks
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> We are working on a feature to add support to start and monitor
>>>>>> gluster
>>>>>> volume asynchronous tasks (like rebalancing a gluster volume, 
>>>>>> removing
>>>>>> brick from volume ) from the oVirt engine.
>>>>>>
>>>>>> The operations can be started from the Volumes tab or the Bricks
>>>>>> sub-tab
>>>>>> using the Rebalance, Remove options.
>>>>>> These are long running operations which can be monitored using a
>>>>>> task id
>>>>>> returned from Gluster. We are planning to add the monitoring in the
>>>>>> existing Task sub tab
>>>>>>
>>>>>> The feature description and User flows are at
>>>>>> http://www.ovirt.org/Features/Gluster_Volume_Asynchronous_Tasks_Management 
>>>>>>
>>>>>>
>>>>>>
>>>>>> The detailed design (including REST API design) is at
>>>>>> http://www.ovirt.org/Features/Detailed_Gluster_Volume_Asynchronous_Tasks_Management. 
>>>>>>
>>>>>>
>>>>>>
>>>>>> I would really appreciate if you could review and provide your
>>>>>> valuable
>>>>>> feedback.
>>>>> I Sahina
>>>>> Why not using 6the External Tasks feature introduced for 3.3 for 
>>>>> those
>>>>> Gluster tasks ???
>>>>> http://www.ovirt.org/Features/Design/DetailedExternalTasks
>>>> Hi Eli,
>>>>
>>>> We still want to be able to start and stop these operations from the
>>>> engine.
>>>> So, when a user wants to say, rebalance a volume, they would go select
>>>> the volume and click on Rebalance Start.
>>>> This would then call the BLL command to start rebalance which will
>>>> invoke the corresponding vdsm verb to start the rebalance on the 
>>>> volume.
>>>> This is the same as existing flow for other commands. The only
>>>> difference is the vdsm verb will return the task id from gluster, for
>>>> the rebalance operation that was started. And we will monitor the
>>>> progress of the task using the gluster task id (by calling a gluster
>>>> command)
>>>>
>>>> I'm not sure how ExternalTasks would fit in here? I was thinking of
>>>> using ExternalTask support for adding Job/Steps to engine when the
>>>> operation is started outside of engine, that is, from Gluster CLI.
>>>> Please correct me if I'm missing something.
>>> Does this mean that from Gluster CLI you will not try and invoke the
>>> rebalance command ?
>>> (I mean, I should either use Gluster CLI or Engine's REST API?)
>> Rebalance volume command could be invoked in any of the following ways:
>> 1. From the console UI (clicking on Rebalance as shown in
>> http://www.ovirt.org/Features/Gluster_Volume_Asynchronous_Tasks_Management#Rebalance_Volume) 
>>
>>
>> 2. Using REST API
>> 3. Outside of engine, from Gluster CLI - In such cases, the engine
>> should detect that a user has triggered rebalance operation outside the
>> engine, and allow the user to monitor progress of this from the engine.
>> This is where, we need support to add a Job for an operation that was
>> started externally, so that it can be seen in the Tasks tab.
>
> and still, it should be considered an internal task, since the engine 
> is managing it / detected it.
>

Itamar, yes, you are right. This would need to be treated as an internal 
task as the engine needs to be able to stop it and also monitor it. We 
would probably need a similar mechanism as external task injection, to 
add a Job for the task started from gluster CLI.




From iheim at redhat.com  Wed Aug 21 10:24:16 2013
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 21 Aug 2013 06:24:16 -0400
Subject: [Engine-devel] Gluster Volume asynchronous tasks
In-Reply-To: <52144628.9070506@redhat.com>
References: <520875A3.6020600@redhat.com>
	<1731655114.276503.1376293867438.JavaMail.root@redhat.com>
	<5208A203.2080101@redhat.com>
	<1028116748.433511.1376301495249.JavaMail.root@redhat.com>
	<5208B459.7000808@redhat.com> <52129C90.1030407@redhat.com>
	<52144628.9070506@redhat.com>
Message-ID: <52149550.9030005@redhat.com>

On 08/21/2013 12:46 AM, Sahina Bose wrote:
>
> On 08/20/2013 04:00 AM, Itamar Heim wrote:
>> On 08/12/2013 06:09 AM, Sahina Bose wrote:
>>>
>>> On 08/12/2013 03:28 PM, Yair Zaslavsky wrote:
>>>>
>>>> ----- Original Message -----
>>>>> From: "Sahina Bose" <sabose at redhat.com>
>>>>> To: "Eli Mesika" <emesika at redhat.com>
>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>, arch at ovirt.org
>>>>> Sent: Monday, August 12, 2013 11:51:15 AM
>>>>> Subject: Re: [Engine-devel] Gluster Volume asynchronous tasks
>>>>>
>>>>>
>>>>> On 08/12/2013 01:21 PM, Eli Mesika wrote:
>>>>>> ----- Original Message -----
>>>>>>> From: "Sahina Bose" <sabose at redhat.com>
>>>>>>> To: "engine-devel" <engine-devel at ovirt.org>, arch at ovirt.org,
>>>>>>> "Michael
>>>>>>> Pasternak" <mpastern at redhat.com>
>>>>>>> Sent: Monday, August 12, 2013 8:41:55 AM
>>>>>>> Subject: [Engine-devel] Gluster Volume asynchronous tasks
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> We are working on a feature to add support to start and monitor
>>>>>>> gluster
>>>>>>> volume asynchronous tasks (like rebalancing a gluster volume,
>>>>>>> removing
>>>>>>> brick from volume ) from the oVirt engine.
>>>>>>>
>>>>>>> The operations can be started from the Volumes tab or the Bricks
>>>>>>> sub-tab
>>>>>>> using the Rebalance, Remove options.
>>>>>>> These are long running operations which can be monitored using a
>>>>>>> task id
>>>>>>> returned from Gluster. We are planning to add the monitoring in the
>>>>>>> existing Task sub tab
>>>>>>>
>>>>>>> The feature description and User flows are at
>>>>>>> http://www.ovirt.org/Features/Gluster_Volume_Asynchronous_Tasks_Management
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The detailed design (including REST API design) is at
>>>>>>> http://www.ovirt.org/Features/Detailed_Gluster_Volume_Asynchronous_Tasks_Management.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I would really appreciate if you could review and provide your
>>>>>>> valuable
>>>>>>> feedback.
>>>>>> I Sahina
>>>>>> Why not using 6the External Tasks feature introduced for 3.3 for
>>>>>> those
>>>>>> Gluster tasks ???
>>>>>> http://www.ovirt.org/Features/Design/DetailedExternalTasks
>>>>> Hi Eli,
>>>>>
>>>>> We still want to be able to start and stop these operations from the
>>>>> engine.
>>>>> So, when a user wants to say, rebalance a volume, they would go select
>>>>> the volume and click on Rebalance Start.
>>>>> This would then call the BLL command to start rebalance which will
>>>>> invoke the corresponding vdsm verb to start the rebalance on the
>>>>> volume.
>>>>> This is the same as existing flow for other commands. The only
>>>>> difference is the vdsm verb will return the task id from gluster, for
>>>>> the rebalance operation that was started. And we will monitor the
>>>>> progress of the task using the gluster task id (by calling a gluster
>>>>> command)
>>>>>
>>>>> I'm not sure how ExternalTasks would fit in here? I was thinking of
>>>>> using ExternalTask support for adding Job/Steps to engine when the
>>>>> operation is started outside of engine, that is, from Gluster CLI.
>>>>> Please correct me if I'm missing something.
>>>> Does this mean that from Gluster CLI you will not try and invoke the
>>>> rebalance command ?
>>>> (I mean, I should either use Gluster CLI or Engine's REST API?)
>>> Rebalance volume command could be invoked in any of the following ways:
>>> 1. From the console UI (clicking on Rebalance as shown in
>>> http://www.ovirt.org/Features/Gluster_Volume_Asynchronous_Tasks_Management#Rebalance_Volume)
>>>
>>>
>>> 2. Using REST API
>>> 3. Outside of engine, from Gluster CLI - In such cases, the engine
>>> should detect that a user has triggered rebalance operation outside the
>>> engine, and allow the user to monitor progress of this from the engine.
>>> This is where, we need support to add a Job for an operation that was
>>> started externally, so that it can be seen in the Tasks tab.
>>
>> and still, it should be considered an internal task, since the engine
>> is managing it / detected it.
>>
>
> Itamar, yes, you are right. This would need to be treated as an internal
> task as the engine needs to be able to stop it and also monitor it. We
> would probably need a similar mechanism as external task injection, to
> add a Job for the task started from gluster CLI.
>
>

even if it was started from CLI, wouldn't it be better if engine 
detected it, and still treated it as an internal task, allowing to 
cancel it, etc.?


From sabose at redhat.com  Wed Aug 21 11:19:51 2013
From: sabose at redhat.com (Sahina Bose)
Date: Wed, 21 Aug 2013 16:49:51 +0530
Subject: [Engine-devel] Gluster Volume asynchronous tasks
In-Reply-To: <52149550.9030005@redhat.com>
References: <520875A3.6020600@redhat.com>
	<1731655114.276503.1376293867438.JavaMail.root@redhat.com>
	<5208A203.2080101@redhat.com>
	<1028116748.433511.1376301495249.JavaMail.root@redhat.com>
	<5208B459.7000808@redhat.com> <52129C90.1030407@redhat.com>
	<52144628.9070506@redhat.com> <52149550.9030005@redhat.com>
Message-ID: <5214A257.4000406@redhat.com>


On 08/21/2013 03:54 PM, Itamar Heim wrote:
> On 08/21/2013 12:46 AM, Sahina Bose wrote:
>>
>> On 08/20/2013 04:00 AM, Itamar Heim wrote:
>>> On 08/12/2013 06:09 AM, Sahina Bose wrote:
>>>>
>>>> On 08/12/2013 03:28 PM, Yair Zaslavsky wrote:
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Sahina Bose" <sabose at redhat.com>
>>>>>> To: "Eli Mesika" <emesika at redhat.com>
>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>, arch at ovirt.org
>>>>>> Sent: Monday, August 12, 2013 11:51:15 AM
>>>>>> Subject: Re: [Engine-devel] Gluster Volume asynchronous tasks
>>>>>>
>>>>>>
>>>>>> On 08/12/2013 01:21 PM, Eli Mesika wrote:
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Sahina Bose" <sabose at redhat.com>
>>>>>>>> To: "engine-devel" <engine-devel at ovirt.org>, arch at ovirt.org,
>>>>>>>> "Michael
>>>>>>>> Pasternak" <mpastern at redhat.com>
>>>>>>>> Sent: Monday, August 12, 2013 8:41:55 AM
>>>>>>>> Subject: [Engine-devel] Gluster Volume asynchronous tasks
>>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> We are working on a feature to add support to start and monitor
>>>>>>>> gluster
>>>>>>>> volume asynchronous tasks (like rebalancing a gluster volume,
>>>>>>>> removing
>>>>>>>> brick from volume ) from the oVirt engine.
>>>>>>>>
>>>>>>>> The operations can be started from the Volumes tab or the Bricks
>>>>>>>> sub-tab
>>>>>>>> using the Rebalance, Remove options.
>>>>>>>> These are long running operations which can be monitored using a
>>>>>>>> task id
>>>>>>>> returned from Gluster. We are planning to add the monitoring in 
>>>>>>>> the
>>>>>>>> existing Task sub tab
>>>>>>>>
>>>>>>>> The feature description and User flows are at
>>>>>>>> http://www.ovirt.org/Features/Gluster_Volume_Asynchronous_Tasks_Management 
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> The detailed design (including REST API design) is at
>>>>>>>> http://www.ovirt.org/Features/Detailed_Gluster_Volume_Asynchronous_Tasks_Management. 
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I would really appreciate if you could review and provide your
>>>>>>>> valuable
>>>>>>>> feedback.
>>>>>>> I Sahina
>>>>>>> Why not using 6the External Tasks feature introduced for 3.3 for
>>>>>>> those
>>>>>>> Gluster tasks ???
>>>>>>> http://www.ovirt.org/Features/Design/DetailedExternalTasks
>>>>>> Hi Eli,
>>>>>>
>>>>>> We still want to be able to start and stop these operations from the
>>>>>> engine.
>>>>>> So, when a user wants to say, rebalance a volume, they would go 
>>>>>> select
>>>>>> the volume and click on Rebalance Start.
>>>>>> This would then call the BLL command to start rebalance which will
>>>>>> invoke the corresponding vdsm verb to start the rebalance on the
>>>>>> volume.
>>>>>> This is the same as existing flow for other commands. The only
>>>>>> difference is the vdsm verb will return the task id from gluster, 
>>>>>> for
>>>>>> the rebalance operation that was started. And we will monitor the
>>>>>> progress of the task using the gluster task id (by calling a gluster
>>>>>> command)
>>>>>>
>>>>>> I'm not sure how ExternalTasks would fit in here? I was thinking of
>>>>>> using ExternalTask support for adding Job/Steps to engine when the
>>>>>> operation is started outside of engine, that is, from Gluster CLI.
>>>>>> Please correct me if I'm missing something.
>>>>> Does this mean that from Gluster CLI you will not try and invoke the
>>>>> rebalance command ?
>>>>> (I mean, I should either use Gluster CLI or Engine's REST API?)
>>>> Rebalance volume command could be invoked in any of the following 
>>>> ways:
>>>> 1. From the console UI (clicking on Rebalance as shown in
>>>> http://www.ovirt.org/Features/Gluster_Volume_Asynchronous_Tasks_Management#Rebalance_Volume) 
>>>>
>>>>
>>>>
>>>> 2. Using REST API
>>>> 3. Outside of engine, from Gluster CLI - In such cases, the engine
>>>> should detect that a user has triggered rebalance operation outside 
>>>> the
>>>> engine, and allow the user to monitor progress of this from the 
>>>> engine.
>>>> This is where, we need support to add a Job for an operation that was
>>>> started externally, so that it can be seen in the Tasks tab.
>>>
>>> and still, it should be considered an internal task, since the engine
>>> is managing it / detected it.
>>>
>>
>> Itamar, yes, you are right. This would need to be treated as an internal
>> task as the engine needs to be able to stop it and also monitor it. We
>> would probably need a similar mechanism as external task injection, to
>> add a Job for the task started from gluster CLI.
>>
>>
>
> even if it was started from CLI, wouldn't it be better if engine 
> detected it, and still treated it as an internal task, allowing to 
> cancel it, etc.?

Yes, but I need to add a Job for this internal task, so that it can be 
monitored in the Tasks pane. Any idea if I can use any existing 
framework to do it? I was thinking I would use 
ExecutionHandler.createJob to do this (similar to what's done in 
AddExternalJobCommand)



From emesika at redhat.com  Wed Aug 21 15:15:14 2013
From: emesika at redhat.com (Eli Mesika)
Date: Wed, 21 Aug 2013 11:15:14 -0400 (EDT)
Subject: [Engine-devel] Gluster Volume asynchronous tasks
In-Reply-To: <5214A257.4000406@redhat.com>
References: <520875A3.6020600@redhat.com> <5208A203.2080101@redhat.com>
	<1028116748.433511.1376301495249.JavaMail.root@redhat.com>
	<5208B459.7000808@redhat.com> <52129C90.1030407@redhat.com>
	<52144628.9070506@redhat.com> <52149550.9030005@redhat.com>
	<5214A257.4000406@redhat.com>
Message-ID: <844931179.2143302.1377098114573.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Sahina Bose" <sabose at redhat.com>
> To: "Itamar Heim" <iheim at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, arch at ovirt.org
> Sent: Wednesday, August 21, 2013 2:19:51 PM
> Subject: Re: [Engine-devel] Gluster Volume asynchronous tasks
> 
> 
> On 08/21/2013 03:54 PM, Itamar Heim wrote:
> > On 08/21/2013 12:46 AM, Sahina Bose wrote:
> >>
> >> On 08/20/2013 04:00 AM, Itamar Heim wrote:
> >>> On 08/12/2013 06:09 AM, Sahina Bose wrote:
> >>>>
> >>>> On 08/12/2013 03:28 PM, Yair Zaslavsky wrote:
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>> From: "Sahina Bose" <sabose at redhat.com>
> >>>>>> To: "Eli Mesika" <emesika at redhat.com>
> >>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>, arch at ovirt.org
> >>>>>> Sent: Monday, August 12, 2013 11:51:15 AM
> >>>>>> Subject: Re: [Engine-devel] Gluster Volume asynchronous tasks
> >>>>>>
> >>>>>>
> >>>>>> On 08/12/2013 01:21 PM, Eli Mesika wrote:
> >>>>>>> ----- Original Message -----
> >>>>>>>> From: "Sahina Bose" <sabose at redhat.com>
> >>>>>>>> To: "engine-devel" <engine-devel at ovirt.org>, arch at ovirt.org,
> >>>>>>>> "Michael
> >>>>>>>> Pasternak" <mpastern at redhat.com>
> >>>>>>>> Sent: Monday, August 12, 2013 8:41:55 AM
> >>>>>>>> Subject: [Engine-devel] Gluster Volume asynchronous tasks
> >>>>>>>>
> >>>>>>>> Hi all,
> >>>>>>>>
> >>>>>>>> We are working on a feature to add support to start and monitor
> >>>>>>>> gluster
> >>>>>>>> volume asynchronous tasks (like rebalancing a gluster volume,
> >>>>>>>> removing
> >>>>>>>> brick from volume ) from the oVirt engine.
> >>>>>>>>
> >>>>>>>> The operations can be started from the Volumes tab or the Bricks
> >>>>>>>> sub-tab
> >>>>>>>> using the Rebalance, Remove options.
> >>>>>>>> These are long running operations which can be monitored using a
> >>>>>>>> task id
> >>>>>>>> returned from Gluster. We are planning to add the monitoring in
> >>>>>>>> the
> >>>>>>>> existing Task sub tab
> >>>>>>>>
> >>>>>>>> The feature description and User flows are at
> >>>>>>>> http://www.ovirt.org/Features/Gluster_Volume_Asynchronous_Tasks_Management
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> The detailed design (including REST API design) is at
> >>>>>>>> http://www.ovirt.org/Features/Detailed_Gluster_Volume_Asynchronous_Tasks_Management.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> I would really appreciate if you could review and provide your
> >>>>>>>> valuable
> >>>>>>>> feedback.
> >>>>>>> I Sahina
> >>>>>>> Why not using 6the External Tasks feature introduced for 3.3 for
> >>>>>>> those
> >>>>>>> Gluster tasks ???
> >>>>>>> http://www.ovirt.org/Features/Design/DetailedExternalTasks
> >>>>>> Hi Eli,
> >>>>>>
> >>>>>> We still want to be able to start and stop these operations from the
> >>>>>> engine.
> >>>>>> So, when a user wants to say, rebalance a volume, they would go
> >>>>>> select
> >>>>>> the volume and click on Rebalance Start.
> >>>>>> This would then call the BLL command to start rebalance which will
> >>>>>> invoke the corresponding vdsm verb to start the rebalance on the
> >>>>>> volume.
> >>>>>> This is the same as existing flow for other commands. The only
> >>>>>> difference is the vdsm verb will return the task id from gluster,
> >>>>>> for
> >>>>>> the rebalance operation that was started. And we will monitor the
> >>>>>> progress of the task using the gluster task id (by calling a gluster
> >>>>>> command)
> >>>>>>
> >>>>>> I'm not sure how ExternalTasks would fit in here? I was thinking of
> >>>>>> using ExternalTask support for adding Job/Steps to engine when the
> >>>>>> operation is started outside of engine, that is, from Gluster CLI.
> >>>>>> Please correct me if I'm missing something.
> >>>>> Does this mean that from Gluster CLI you will not try and invoke the
> >>>>> rebalance command ?
> >>>>> (I mean, I should either use Gluster CLI or Engine's REST API?)
> >>>> Rebalance volume command could be invoked in any of the following
> >>>> ways:
> >>>> 1. From the console UI (clicking on Rebalance as shown in
> >>>> http://www.ovirt.org/Features/Gluster_Volume_Asynchronous_Tasks_Management#Rebalance_Volume)
> >>>>
> >>>>
> >>>>
> >>>> 2. Using REST API
> >>>> 3. Outside of engine, from Gluster CLI - In such cases, the engine
> >>>> should detect that a user has triggered rebalance operation outside
> >>>> the
> >>>> engine, and allow the user to monitor progress of this from the
> >>>> engine.
> >>>> This is where, we need support to add a Job for an operation that was
> >>>> started externally, so that it can be seen in the Tasks tab.
> >>>
> >>> and still, it should be considered an internal task, since the engine
> >>> is managing it / detected it.
> >>>
> >>
> >> Itamar, yes, you are right. This would need to be treated as an internal
> >> task as the engine needs to be able to stop it and also monitor it. We
> >> would probably need a similar mechanism as external task injection, to
> >> add a Job for the task started from gluster CLI.
> >>
> >>
> >
> > even if it was started from CLI, wouldn't it be better if engine
> > detected it, and still treated it as an internal task, allowing to
> > cancel it, etc.?
> 
> Yes, but I need to add a Job for this internal task, so that it can be
> monitored in the Tasks pane. Any idea if I can use any existing
> framework to do it? I was thinking I would use
> ExecutionHandler.createJob to do this (similar to what's done in
> AddExternalJobCommand)

Maybe in order to avoid code duplication we should re-factor having a base AddJobCommand and two descendants AddExternalJobCommand and AddInternalJobCommand when the only diff between those is the external flag value while the execute method of both calls super at first and the ancestor has the original code of ddExternalJobCommand in its execute method...


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


From iheim at redhat.com  Wed Aug 21 15:24:21 2013
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 21 Aug 2013 11:24:21 -0400
Subject: [Engine-devel] Gluster Volume asynchronous tasks
In-Reply-To: <844931179.2143302.1377098114573.JavaMail.root@redhat.com>
References: <520875A3.6020600@redhat.com> <5208A203.2080101@redhat.com>
	<1028116748.433511.1376301495249.JavaMail.root@redhat.com>
	<5208B459.7000808@redhat.com> <52129C90.1030407@redhat.com>
	<52144628.9070506@redhat.com> <52149550.9030005@redhat.com>
	<5214A257.4000406@redhat.com>
	<844931179.2143302.1377098114573.JavaMail.root@redhat.com>
Message-ID: <5214DBA5.5090407@redhat.com>

On 08/21/2013 11:15 AM, Eli Mesika wrote:
>
>
> ----- Original Message -----
>> From: "Sahina Bose" <sabose at redhat.com>
>> To: "Itamar Heim" <iheim at redhat.com>
>> Cc: "engine-devel" <engine-devel at ovirt.org>, arch at ovirt.org
>> Sent: Wednesday, August 21, 2013 2:19:51 PM
>> Subject: Re: [Engine-devel] Gluster Volume asynchronous tasks
>>
>>
>> On 08/21/2013 03:54 PM, Itamar Heim wrote:
>>> On 08/21/2013 12:46 AM, Sahina Bose wrote:
>>>>
>>>> On 08/20/2013 04:00 AM, Itamar Heim wrote:
>>>>> On 08/12/2013 06:09 AM, Sahina Bose wrote:
>>>>>>
>>>>>> On 08/12/2013 03:28 PM, Yair Zaslavsky wrote:
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Sahina Bose" <sabose at redhat.com>
>>>>>>>> To: "Eli Mesika" <emesika at redhat.com>
>>>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>, arch at ovirt.org
>>>>>>>> Sent: Monday, August 12, 2013 11:51:15 AM
>>>>>>>> Subject: Re: [Engine-devel] Gluster Volume asynchronous tasks
>>>>>>>>
>>>>>>>>
>>>>>>>> On 08/12/2013 01:21 PM, Eli Mesika wrote:
>>>>>>>>> ----- Original Message -----
>>>>>>>>>> From: "Sahina Bose" <sabose at redhat.com>
>>>>>>>>>> To: "engine-devel" <engine-devel at ovirt.org>, arch at ovirt.org,
>>>>>>>>>> "Michael
>>>>>>>>>> Pasternak" <mpastern at redhat.com>
>>>>>>>>>> Sent: Monday, August 12, 2013 8:41:55 AM
>>>>>>>>>> Subject: [Engine-devel] Gluster Volume asynchronous tasks
>>>>>>>>>>
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> We are working on a feature to add support to start and monitor
>>>>>>>>>> gluster
>>>>>>>>>> volume asynchronous tasks (like rebalancing a gluster volume,
>>>>>>>>>> removing
>>>>>>>>>> brick from volume ) from the oVirt engine.
>>>>>>>>>>
>>>>>>>>>> The operations can be started from the Volumes tab or the Bricks
>>>>>>>>>> sub-tab
>>>>>>>>>> using the Rebalance, Remove options.
>>>>>>>>>> These are long running operations which can be monitored using a
>>>>>>>>>> task id
>>>>>>>>>> returned from Gluster. We are planning to add the monitoring in
>>>>>>>>>> the
>>>>>>>>>> existing Task sub tab
>>>>>>>>>>
>>>>>>>>>> The feature description and User flows are at
>>>>>>>>>> http://www.ovirt.org/Features/Gluster_Volume_Asynchronous_Tasks_Management
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The detailed design (including REST API design) is at
>>>>>>>>>> http://www.ovirt.org/Features/Detailed_Gluster_Volume_Asynchronous_Tasks_Management.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I would really appreciate if you could review and provide your
>>>>>>>>>> valuable
>>>>>>>>>> feedback.
>>>>>>>>> I Sahina
>>>>>>>>> Why not using 6the External Tasks feature introduced for 3.3 for
>>>>>>>>> those
>>>>>>>>> Gluster tasks ???
>>>>>>>>> http://www.ovirt.org/Features/Design/DetailedExternalTasks
>>>>>>>> Hi Eli,
>>>>>>>>
>>>>>>>> We still want to be able to start and stop these operations from the
>>>>>>>> engine.
>>>>>>>> So, when a user wants to say, rebalance a volume, they would go
>>>>>>>> select
>>>>>>>> the volume and click on Rebalance Start.
>>>>>>>> This would then call the BLL command to start rebalance which will
>>>>>>>> invoke the corresponding vdsm verb to start the rebalance on the
>>>>>>>> volume.
>>>>>>>> This is the same as existing flow for other commands. The only
>>>>>>>> difference is the vdsm verb will return the task id from gluster,
>>>>>>>> for
>>>>>>>> the rebalance operation that was started. And we will monitor the
>>>>>>>> progress of the task using the gluster task id (by calling a gluster
>>>>>>>> command)
>>>>>>>>
>>>>>>>> I'm not sure how ExternalTasks would fit in here? I was thinking of
>>>>>>>> using ExternalTask support for adding Job/Steps to engine when the
>>>>>>>> operation is started outside of engine, that is, from Gluster CLI.
>>>>>>>> Please correct me if I'm missing something.
>>>>>>> Does this mean that from Gluster CLI you will not try and invoke the
>>>>>>> rebalance command ?
>>>>>>> (I mean, I should either use Gluster CLI or Engine's REST API?)
>>>>>> Rebalance volume command could be invoked in any of the following
>>>>>> ways:
>>>>>> 1. From the console UI (clicking on Rebalance as shown in
>>>>>> http://www.ovirt.org/Features/Gluster_Volume_Asynchronous_Tasks_Management#Rebalance_Volume)
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2. Using REST API
>>>>>> 3. Outside of engine, from Gluster CLI - In such cases, the engine
>>>>>> should detect that a user has triggered rebalance operation outside
>>>>>> the
>>>>>> engine, and allow the user to monitor progress of this from the
>>>>>> engine.
>>>>>> This is where, we need support to add a Job for an operation that was
>>>>>> started externally, so that it can be seen in the Tasks tab.
>>>>>
>>>>> and still, it should be considered an internal task, since the engine
>>>>> is managing it / detected it.
>>>>>
>>>>
>>>> Itamar, yes, you are right. This would need to be treated as an internal
>>>> task as the engine needs to be able to stop it and also monitor it. We
>>>> would probably need a similar mechanism as external task injection, to
>>>> add a Job for the task started from gluster CLI.
>>>>
>>>>
>>>
>>> even if it was started from CLI, wouldn't it be better if engine
>>> detected it, and still treated it as an internal task, allowing to
>>> cancel it, etc.?
>>
>> Yes, but I need to add a Job for this internal task, so that it can be
>> monitored in the Tasks pane. Any idea if I can use any existing
>> framework to do it? I was thinking I would use
>> ExecutionHandler.createJob to do this (similar to what's done in
>> AddExternalJobCommand)
>
> Maybe in order to avoid code duplication we should re-factor having a base AddJobCommand and two descendants AddExternalJobCommand and AddInternalJobCommand when the only diff between those is the external flag value while the execute method of both calls super at first and the ancestor has the original code of ddExternalJobCommand in its execute method...

and in this case, the code will call AddInternalJobCommand for a job 
detected and not initiated by engine?



From bohai at huawei.com  Wed Aug 21 06:41:10 2013
From: bohai at huawei.com (Bohai (ricky))
Date: Wed, 21 Aug 2013 06:41:10 +0000
Subject: [node-devel] oVirt Node feature requests for 3.1 release
In-Reply-To: <52137C91.1070607@redhat.com>
References: <52137C91.1070607@redhat.com>
Message-ID: <98B730463BF8F84A885ABF3A8F61495165F69024@SZXEMA501-MBS.china.huawei.com>


> -----Original Message-----
> From: node-devel-bounces at ovirt.org [mailto:node-devel-bounces at ovirt.org]
> On Behalf Of Mike Burns
> Sent: Tuesday, August 20, 2013 10:26 PM
> To: node-devel; arch
> Subject: [node-devel] oVirt Node feature requests for 3.1 release
> 
> Hi all,
> 
> We're going into our initial planning cycle for oVirt Node 3.1 and are
> looking for features that are interesting to people.  There are a number
> of ideas that were proposed on our weekly meeting that are listed below.
>   If you would really like to see one or more of the features below,
> please let us know.  If you have an idea for another feature, please
> also reply with a short abstract for that feature.
> 
> Thanks
> 
> Mike
> 
> * Package Refactoring -- make it easier to build custom images for
> different use cases without pulling in unnecessary functionality (I.E.,
> virt capabilities when acting as a storage node only).
> * re-writes of the storage and installer modules for easier testing
+1

> * openvswitch support
+1

> * live install of plugins (install on a running system, possibly with
> push model)
> * Some sort of announcement model where we identify who we are and what
> we can do to a system (for registration purposes)
> * kimchi plugin (http://github.com/kimchi-project/kimchi) for standalone
> use cases
> _______________________________________________
> node-devel mailing list
> node-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/node-devel


From fabiand at redhat.com  Thu Aug 22 09:42:28 2013
From: fabiand at redhat.com (Fabian Deutsch)
Date: Thu, 22 Aug 2013 11:42:28 +0200
Subject: [node-devel] oVirt Node feature requests for 3.1 release
In-Reply-To: <52137C91.1070607@redhat.com>
References: <52137C91.1070607@redhat.com>
Message-ID: <1377164548.2654.0.camel@fdeutsch-laptop.local>

Am Dienstag, den 20.08.2013, 10:26 -0400 schrieb Mike Burns:
> Hi all,
> 
> We're going into our initial planning cycle for oVirt Node 3.1 and are 
> looking for features that are interesting to people.  There are a number 
> of ideas that were proposed on our weekly meeting that are listed below. 
>   If you would really like to see one or more of the features below, 
> please let us know.  If you have an idea for another feature, please 
> also reply with a short abstract for that feature.
> 
> Thanks
> 
> Mike
> 
> * Package Refactoring -- make it easier to build custom images for 
> different use cases without pulling in unnecessary functionality (I.E., 
> virt capabilities when acting as a storage node only).
> * re-writes of the storage and installer modules for easier testing
> * openvswitch support
> * live install of plugins (install on a running system, possibly with 
> push model)
> * Some sort of announcement model where we identify who we are and what 
> we can do to a system (for registration purposes)
> * kimchi plugin (http://github.com/kimchi-project/kimchi) for standalone 
> use cases

I've created a feature page for the 3.1 release in the wiki to track the
feature requests:
http://www.ovirt.org/Node_3.1_release-management

I've also added all features from above.

- fabian



From mburns at redhat.com  Thu Aug 22 11:50:53 2013
From: mburns at redhat.com (Mike Burns)
Date: Thu, 22 Aug 2013 07:50:53 -0400
Subject: [node-devel] oVirt Node feature requests for 3.1 release
In-Reply-To: <1377164548.2654.0.camel@fdeutsch-laptop.local>
References: <52137C91.1070607@redhat.com>
	<1377164548.2654.0.camel@fdeutsch-laptop.local>
Message-ID: <5215FB1D.1080402@redhat.com>

On 08/22/2013 05:42 AM, Fabian Deutsch wrote:
> Am Dienstag, den 20.08.2013, 10:26 -0400 schrieb Mike Burns:
>> Hi all,
>>
>> We're going into our initial planning cycle for oVirt Node 3.1 and are
>> looking for features that are interesting to people.  There are a number
>> of ideas that were proposed on our weekly meeting that are listed below.
>>    If you would really like to see one or more of the features below,
>> please let us know.  If you have an idea for another feature, please
>> also reply with a short abstract for that feature.
>>
>> Thanks
>>
>> Mike
>>
>> * Package Refactoring -- make it easier to build custom images for
>> different use cases without pulling in unnecessary functionality (I.E.,
>> virt capabilities when acting as a storage node only).
>> * re-writes of the storage and installer modules for easier testing
>> * openvswitch support
>> * live install of plugins (install on a running system, possibly with
>> push model)
>> * Some sort of announcement model where we identify who we are and what
>> we can do to a system (for registration purposes)
>> * kimchi plugin (http://github.com/kimchi-project/kimchi) for standalone
>> use cases
>
> I've created a feature page for the 3.1 release in the wiki to track the
> feature requests:
> http://www.ovirt.org/Node_3.1_release-management
>
> I've also added all features from above.

Thanks Fabian.


>
> - fabian
>
> _______________________________________________
> node-devel mailing list
> node-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/node-devel
>



From emesika at redhat.com  Thu Aug 22 13:48:09 2013
From: emesika at redhat.com (Eli Mesika)
Date: Thu, 22 Aug 2013 09:48:09 -0400 (EDT)
Subject: [Engine-devel] Gluster Volume asynchronous tasks
In-Reply-To: <5214DBA5.5090407@redhat.com>
References: <520875A3.6020600@redhat.com> <5208B459.7000808@redhat.com>
	<52129C90.1030407@redhat.com> <52144628.9070506@redhat.com>
	<52149550.9030005@redhat.com> <5214A257.4000406@redhat.com>
	<844931179.2143302.1377098114573.JavaMail.root@redhat.com>
	<5214DBA5.5090407@redhat.com>
Message-ID: <698776276.2763440.1377179289495.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: "Sahina Bose" <sabose at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, arch at ovirt.org
> Sent: Wednesday, August 21, 2013 6:24:21 PM
> Subject: Re: [Engine-devel] Gluster Volume asynchronous tasks
> 
> On 08/21/2013 11:15 AM, Eli Mesika wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Sahina Bose" <sabose at redhat.com>
> >> To: "Itamar Heim" <iheim at redhat.com>
> >> Cc: "engine-devel" <engine-devel at ovirt.org>, arch at ovirt.org
> >> Sent: Wednesday, August 21, 2013 2:19:51 PM
> >> Subject: Re: [Engine-devel] Gluster Volume asynchronous tasks
> >>
> >>
> >> On 08/21/2013 03:54 PM, Itamar Heim wrote:
> >>> On 08/21/2013 12:46 AM, Sahina Bose wrote:
> >>>>
> >>>> On 08/20/2013 04:00 AM, Itamar Heim wrote:
> >>>>> On 08/12/2013 06:09 AM, Sahina Bose wrote:
> >>>>>>
> >>>>>> On 08/12/2013 03:28 PM, Yair Zaslavsky wrote:
> >>>>>>>
> >>>>>>> ----- Original Message -----
> >>>>>>>> From: "Sahina Bose" <sabose at redhat.com>
> >>>>>>>> To: "Eli Mesika" <emesika at redhat.com>
> >>>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>, arch at ovirt.org
> >>>>>>>> Sent: Monday, August 12, 2013 11:51:15 AM
> >>>>>>>> Subject: Re: [Engine-devel] Gluster Volume asynchronous tasks
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 08/12/2013 01:21 PM, Eli Mesika wrote:
> >>>>>>>>> ----- Original Message -----
> >>>>>>>>>> From: "Sahina Bose" <sabose at redhat.com>
> >>>>>>>>>> To: "engine-devel" <engine-devel at ovirt.org>, arch at ovirt.org,
> >>>>>>>>>> "Michael
> >>>>>>>>>> Pasternak" <mpastern at redhat.com>
> >>>>>>>>>> Sent: Monday, August 12, 2013 8:41:55 AM
> >>>>>>>>>> Subject: [Engine-devel] Gluster Volume asynchronous tasks
> >>>>>>>>>>
> >>>>>>>>>> Hi all,
> >>>>>>>>>>
> >>>>>>>>>> We are working on a feature to add support to start and monitor
> >>>>>>>>>> gluster
> >>>>>>>>>> volume asynchronous tasks (like rebalancing a gluster volume,
> >>>>>>>>>> removing
> >>>>>>>>>> brick from volume ) from the oVirt engine.
> >>>>>>>>>>
> >>>>>>>>>> The operations can be started from the Volumes tab or the Bricks
> >>>>>>>>>> sub-tab
> >>>>>>>>>> using the Rebalance, Remove options.
> >>>>>>>>>> These are long running operations which can be monitored using a
> >>>>>>>>>> task id
> >>>>>>>>>> returned from Gluster. We are planning to add the monitoring in
> >>>>>>>>>> the
> >>>>>>>>>> existing Task sub tab
> >>>>>>>>>>
> >>>>>>>>>> The feature description and User flows are at
> >>>>>>>>>> http://www.ovirt.org/Features/Gluster_Volume_Asynchronous_Tasks_Management
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> The detailed design (including REST API design) is at
> >>>>>>>>>> http://www.ovirt.org/Features/Detailed_Gluster_Volume_Asynchronous_Tasks_Management.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> I would really appreciate if you could review and provide your
> >>>>>>>>>> valuable
> >>>>>>>>>> feedback.
> >>>>>>>>> I Sahina
> >>>>>>>>> Why not using 6the External Tasks feature introduced for 3.3 for
> >>>>>>>>> those
> >>>>>>>>> Gluster tasks ???
> >>>>>>>>> http://www.ovirt.org/Features/Design/DetailedExternalTasks
> >>>>>>>> Hi Eli,
> >>>>>>>>
> >>>>>>>> We still want to be able to start and stop these operations from the
> >>>>>>>> engine.
> >>>>>>>> So, when a user wants to say, rebalance a volume, they would go
> >>>>>>>> select
> >>>>>>>> the volume and click on Rebalance Start.
> >>>>>>>> This would then call the BLL command to start rebalance which will
> >>>>>>>> invoke the corresponding vdsm verb to start the rebalance on the
> >>>>>>>> volume.
> >>>>>>>> This is the same as existing flow for other commands. The only
> >>>>>>>> difference is the vdsm verb will return the task id from gluster,
> >>>>>>>> for
> >>>>>>>> the rebalance operation that was started. And we will monitor the
> >>>>>>>> progress of the task using the gluster task id (by calling a gluster
> >>>>>>>> command)
> >>>>>>>>
> >>>>>>>> I'm not sure how ExternalTasks would fit in here? I was thinking of
> >>>>>>>> using ExternalTask support for adding Job/Steps to engine when the
> >>>>>>>> operation is started outside of engine, that is, from Gluster CLI.
> >>>>>>>> Please correct me if I'm missing something.
> >>>>>>> Does this mean that from Gluster CLI you will not try and invoke the
> >>>>>>> rebalance command ?
> >>>>>>> (I mean, I should either use Gluster CLI or Engine's REST API?)
> >>>>>> Rebalance volume command could be invoked in any of the following
> >>>>>> ways:
> >>>>>> 1. From the console UI (clicking on Rebalance as shown in
> >>>>>> http://www.ovirt.org/Features/Gluster_Volume_Asynchronous_Tasks_Management#Rebalance_Volume)
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> 2. Using REST API
> >>>>>> 3. Outside of engine, from Gluster CLI - In such cases, the engine
> >>>>>> should detect that a user has triggered rebalance operation outside
> >>>>>> the
> >>>>>> engine, and allow the user to monitor progress of this from the
> >>>>>> engine.
> >>>>>> This is where, we need support to add a Job for an operation that was
> >>>>>> started externally, so that it can be seen in the Tasks tab.
> >>>>>
> >>>>> and still, it should be considered an internal task, since the engine
> >>>>> is managing it / detected it.
> >>>>>
> >>>>
> >>>> Itamar, yes, you are right. This would need to be treated as an internal
> >>>> task as the engine needs to be able to stop it and also monitor it. We
> >>>> would probably need a similar mechanism as external task injection, to
> >>>> add a Job for the task started from gluster CLI.
> >>>>
> >>>>
> >>>
> >>> even if it was started from CLI, wouldn't it be better if engine
> >>> detected it, and still treated it as an internal task, allowing to
> >>> cancel it, etc.?
> >>
> >> Yes, but I need to add a Job for this internal task, so that it can be
> >> monitored in the Tasks pane. Any idea if I can use any existing
> >> framework to do it? I was thinking I would use
> >> ExecutionHandler.createJob to do this (similar to what's done in
> >> AddExternalJobCommand)
> >
> > Maybe in order to avoid code duplication we should re-factor having a base
> > AddJobCommand and two descendants AddExternalJobCommand and
> > AddInternalJobCommand when the only diff between those is the external
> > flag value while the execute method of both calls super at first and the
> > ancestor has the original code of ddExternalJobCommand in its execute
> > method...
> 
> and in this case, the code will call AddInternalJobCommand for a job
> detected and not initiated by engine?

Yes, Gluster will use the AddInternalJobCommand
> 
> 


From lpeer at redhat.com  Sun Aug 25 10:31:29 2013
From: lpeer at redhat.com (Livnat Peer)
Date: Sun, 25 Aug 2013 13:31:29 +0300
Subject: [node-devel] oVirt Node feature requests for 3.1 release
In-Reply-To: <98B730463BF8F84A885ABF3A8F61495165F69024@SZXEMA501-MBS.china.huawei.com>
References: <52137C91.1070607@redhat.com>
	<98B730463BF8F84A885ABF3A8F61495165F69024@SZXEMA501-MBS.china.huawei.com>
Message-ID: <5219DD01.2030707@redhat.com>

On 08/21/2013 09:41 AM, Bohai (ricky) wrote:
> 
>> -----Original Message-----
>> From: node-devel-bounces at ovirt.org [mailto:node-devel-bounces at ovirt.org]
>> On Behalf Of Mike Burns
>> Sent: Tuesday, August 20, 2013 10:26 PM
>> To: node-devel; arch
>> Subject: [node-devel] oVirt Node feature requests for 3.1 release
>>
>> Hi all,
>>
>> We're going into our initial planning cycle for oVirt Node 3.1 and are
>> looking for features that are interesting to people.  There are a number
>> of ideas that were proposed on our weekly meeting that are listed below.
>>   If you would really like to see one or more of the features below,
>> please let us know.  If you have an idea for another feature, please
>> also reply with a short abstract for that feature.
>>
>> Thanks
>>
>> Mike
>>
>> * Package Refactoring -- make it easier to build custom images for
>> different use cases without pulling in unnecessary functionality (I.E.,
>> virt capabilities when acting as a storage node only).
>> * re-writes of the storage and installer modules for easier testing
> +1
> 
>> * openvswitch support
> +1

+1

In addition we added in oVirt 3.3 integration with Neutron that is
currently only available on RHEL/fedora based nodes.
It would be great if we can look into what are the requirements to
support it on oVirt node as well.

> 
>> * live install of plugins (install on a running system, possibly with
>> push model)
>> * Some sort of announcement model where we identify who we are and what
>> we can do to a system (for registration purposes)
>> * kimchi plugin (http://github.com/kimchi-project/kimchi) for standalone
>> use cases
>> _______________________________________________
>> node-devel mailing list
>> node-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/node-devel
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 
> 



From dfediuck at redhat.com  Tue Aug 27 09:26:44 2013
From: dfediuck at redhat.com (Doron Fediuck)
Date: Tue, 27 Aug 2013 05:26:44 -0400 (EDT)
Subject: deep dive -  scheduling in 3.3
In-Reply-To: <848577339.6673291.1377595288434.JavaMail.root@redhat.com>
Message-ID: <1796377068.6676747.1377595604442.JavaMail.root@redhat.com>

Hi all,
Next Tuesday (September 3rd) at 16:00 UTC+3, we're going to have
a deep dive session on the new oVirt scheduling.

You're more than welcome to join us using:

- Audio only bridge
  * Dial your local access number in: https://www.intercallonline.com/portlets/scheduling/viewNumbers/listNumbersByCode.do?confCode=972545636785
  * Use the following bridge ID: 972545636785

- Visual session (Elluminate)
  * Browse to: https://sas.elluminate.com/m.jnlp?sid=819&password=M.97AA703D4B077C9D0263B1D791D482

Slides will be available after the session.
See you then,
Doron


From amuller at redhat.com  Tue Aug 27 12:00:35 2013
From: amuller at redhat.com (Assaf Muller)
Date: Tue, 27 Aug 2013 08:00:35 -0400 (EDT)
Subject: Upgrade mechanism
In-Reply-To: <1030668764.4646288.1377604596492.JavaMail.root@redhat.com>
References: <1030668764.4646288.1377604596492.JavaMail.root@redhat.com>
Message-ID: <194420905.4647377.1377604835960.JavaMail.root@redhat.com>

While implementing a new form of network configuration persistence I needed a way to run 'upgrade code'.
That is, I need the ability to run a piece of code exactly once, on the first boot of VDSM.

My use case is related to unified network persistence - We intend to persist network information
in a new format, and on the first run of a new VDSM that contains unified network persistence code,
it needs to inspect the kernel state and construct the data in the new format. From then on,
it will be persisted and updated when the setupNetworks verb is received. The upgrade code, then,
needs to run only once.

Instead of implementing a unique and custom solution I thought to introduce a very simple and flexible
upgrade mechanism which suits my needs.
http://gerrit.ovirt.org/#/c/17726/

And the following patch is the actual upgrade code, which demonstrates how the upgrade mechanism is used:
http://gerrit.ovirt.org/#/c/18425/

Clarification: This upgrade mechanism is not related to yum upgrade in any way.

Infra guys (And everyone else) - Any feedback is welcome. Thanks!


From ybronhei at redhat.com  Tue Aug 27 18:54:52 2013
From: ybronhei at redhat.com (Yaniv Bronheim)
Date: Tue, 27 Aug 2013 14:54:52 -0400 (EDT)
Subject: Upgrade mechanism
In-Reply-To: <194420905.4647377.1377604835960.JavaMail.root@redhat.com>
References: <1030668764.4646288.1377604596492.JavaMail.root@redhat.com>
	<194420905.4647377.1377604835960.JavaMail.root@redhat.com>
Message-ID: <524963822.2775568.1377629692154.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Assaf Muller" <amuller at redhat.com>
> To: "arch" <arch at ovirt.org>
> Sent: Tuesday, August 27, 2013 3:00:35 PM
> Subject: Upgrade mechanism
> 
> While implementing a new form of network configuration persistence I needed a
> way to run 'upgrade code'.
> That is, I need the ability to run a piece of code exactly once, on the first
> boot of VDSM.
> 
> My use case is related to unified network persistence - We intend to persist
> network information
> in a new format, and on the first run of a new VDSM that contains unified
> network persistence code,
> it needs to inspect the kernel state and construct the data in the new
> format. From then on,
> it will be persisted and updated when the setupNetworks verb is received. The
> upgrade code, then,
> needs to run only once.
> 
> Instead of implementing a unique and custom solution I thought to introduce a
> very simple and flexible
> upgrade mechanism which suits my needs.
> http://gerrit.ovirt.org/#/c/17726/
> 
> And the following patch is the actual upgrade code, which demonstrates how
> the upgrade mechanism is used:
> http://gerrit.ovirt.org/#/c/18425/
> 

As I commented on the patchset, I recommend to move all this logic to vdsm-tool verb

> Clarification: This upgrade mechanism is not related to yum upgrade in any
> way.
> 
> Infra guys (And everyone else) - Any feedback is welcome. Thanks!
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From lvernia at redhat.com  Wed Aug 28 10:23:03 2013
From: lvernia at redhat.com (Lior Vernia)
Date: Wed, 28 Aug 2013 13:23:03 +0300
Subject: Deep dive - Network QoS / vNIC Profiles
Message-ID: <521DCF87.8010904@redhat.com>

Hello everyone,

Today (August 28th) at 16:00 GMT+3 we're going to have a session about
the oVirt 3.3 features of Network Quality of Service and vNIC Profiles.
You're welcome to join in either or both of the following:

* Audio conference: find your country's access number at the attached
link, and use ID 972506565679.
https://www.intercallonline.com/listNumbersByCode.action?confCode=972506565679

* Elluminate session (video + hopefully audio):
https://sas.elluminate.com/m.jnlp?sid=819&password=M.C34B8602C01AC95648BE69965D4F5B

I will try to record the session.

Yours, Lior.


From dneary at redhat.com  Fri Aug 30 17:20:41 2013
From: dneary at redhat.com (Dave Neary)
Date: Fri, 30 Aug 2013 19:20:41 +0200
Subject: Register now for KVM Forum and the oVirt developers summit!
Message-ID: <5220D469.3020706@redhat.com>

Hi everyone,

The KVM Forum in Edinburgh this year will have lots of great oVirt
related content this year:
http://events.linuxfoundation.org/events/kvm-forum

And on day 3 of the conference, Wednesday October 23rd, we will have an
oVirt Developers Summit, where we will have a small number of oVirt
specific presentations, and working sessions to talk about the future of
oVirt.

Register now - it's free for the first 200 people to sign up!
http://events.linuxfoundation.org/events/kvm-forum/attend/register

We want to get a critical mass of oVirt developers in the same room in
Edinburgh to make good progress on the oVirt 3.4 and beyond project
planning.

We're still putting together a full schedule of oVirt related content,
specifically for the KVM Forum, but already we have a good list of oVirt
content for the week:


Monday, October 21:

11:00am - RAM Snapshots in oVirt - Arik Hadas, Red Hat
12:00pm - oVirt and Cloud-Init integration - Omer Frenkel, Red Hat
2:20pm - Empowering Data Center Virtualization Using KVM - Livnat Peer,
Red Hat
4:40pm - Converged Infrastrucure with Open Source - Theron Conrey

Tuesday, October 22:

11:10am - Notes on Taking KVM-on-KVM Nested Virtualization for a Spin -
Kashyap Chamarthy, Red Hat
12:10pm - Cloud Computing with KVM - Tony Gargya, IBM

Wednesday, October 23:

11:05am - (Tutorial) Scripting And Integration with the oVirt Engine -
Oved Ourfali, Red Hat

Once I have a complete list of oVirt related content in the KVM Forum
and oVirt developer summit, I will come back to the list.

Reserve your spot now! The first 200 to register for the KVM Forum can
go free, and get a discount for the entire conference (including
LinuxCon Euroope and CloudOpen Europe).

Regards,
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