From fabiand at redhat.com  Tue Apr  2 10:11:55 2013
From: fabiand at redhat.com (Fabian Deutsch)
Date: Tue, 02 Apr 2013 12:11:55 +0200
Subject: proposal:supply a way to allow to change ethernet name.
In-Reply-To: <1021657e.2b321.13da69db4ed.Coremail.bigclouds@163.com>
References: <1021657e.2b321.13da69db4ed.Coremail.bigclouds@163.com>
Message-ID: <1364897515.2420.1.camel@fdeutsch-laptop.local>

Am Dienstag, den 26.03.2013, 20:13 +0800 schrieb bigclouds:
> hi,all
>     i take the liberty of proposal a feature, give admin the
> opportunity to change ethernet name.
>    my reasones:
> 1.modern server has several ethernets,but traditional ethernet
> naming scheme is hard for people to know what its name represent.
> 2.sometime ethernet name is unpredictable .for example ifc-xxxx is
> lost, having to change a n ew ethernet card. all those can lead
> confusion.

At least for Fedora 19 there is a feature [1] on track 19 which
addresses this problem (If I understood you correctly).
This won't give you the ability to rename the NICs, but the NIC names
won't change.
This is similar to what biosdevname does, but extends it and isn't
limited to Dell machines.

Does this feature help you (when it lands)?

Greetings
fabian

--
[1]
https://fedoraproject.org/wiki/Features/SystemdPredictableNetworkInterfaceNames



From asegurap at redhat.com  Tue Apr  2 10:17:27 2013
From: asegurap at redhat.com (Antoni Segura Puimedon)
Date: Tue, 2 Apr 2013 06:17:27 -0400 (EDT)
Subject: proposal:supply a way to allow to change ethernet name.
In-Reply-To: <1364897515.2420.1.camel@fdeutsch-laptop.local>
References: <1021657e.2b321.13da69db4ed.Coremail.bigclouds@163.com>
	<1364897515.2420.1.camel@fdeutsch-laptop.local>
Message-ID: <1552769881.343056.1364897847883.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Fabian Deutsch" <fabiand at redhat.com>
> To: arch at ovirt.org
> Sent: Tuesday, April 2, 2013 12:11:55 PM
> Subject: Re: proposal:supply a way to allow to change ethernet name.
> 
> Am Dienstag, den 26.03.2013, 20:13 +0800 schrieb bigclouds:
> > hi,all
> >     i take the liberty of proposal a feature, give admin the
> > opportunity to change ethernet name.
> >    my reasones:
> > 1.modern server has several ethernets,but traditional ethernet
> > naming scheme is hard for people to know what its name represent.
> > 2.sometime ethernet name is unpredictable .for example ifc-xxxx is
> > lost, having to change a n ew ethernet card. all those can lead
> > confusion.
> 
> At least for Fedora 19 there is a feature [1] on track 19 which
> addresses this problem (If I understood you correctly).
> This won't give you the ability to rename the NICs, but the NIC names
> won't change.
> This is similar to what biosdevname does, but extends it and isn't
> limited to Dell machines.
AFAIK biosdevname works for non dell machines. It even used to work for some
VMs :-)
> 
> Does this feature help you (when it lands)?
> 
> Greetings
> fabian
> 
> --
> [1]
> https://fedoraproject.org/wiki/Features/SystemdPredictableNetworkInterfaceNames
> 
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From fabiand at redhat.com  Thu Apr  4 16:21:44 2013
From: fabiand at redhat.com (Fabian Deutsch)
Date: Thu, 04 Apr 2013 18:21:44 +0200
Subject: oVirt cluster level test proposal
In-Reply-To: <51502196.6070508@linux.vnet.ibm.com>
References: <51502196.6070508@linux.vnet.ibm.com>
Message-ID: <1365092504.11957.18.camel@fdeutsch-laptop.local>

Am Montag, den 25.03.2013, 18:06 +0800 schrieb Mark Wu:
> Hi guys,
> 
> As per the discussion before, we don't have  integrated functional tests 
> for oVirt.  So I would like to propose a cluster level test plan.
> Basically, it's composed of igord, cobbler and test cases based on 
> engine REST api. Cobbler stores kickstart files, installation images and 
> test packages repo.
> Igor is responsible to setup test environment according to the test plan 
> and run the test cases inside test host.  I write down a wiki page to 
> describe the work flow:
> http://www.ovirt.org/Ovirt_cluster_level_test
> 
> @Fabian,  according to my investigation on igor,  it should be not 
> difficult to enhance igor to support this proposal.  I would like to get 
> your opinion on it.

Hey Mark,

nice to see this overall proposal which covers all components of oVirt.
I've looked at your proposal and basically agree and think that it
should work.
There are a couple of things which ain't completely clear to me or what
I'd like to comment:

* It should be possible that Igor provisions a host with RHEL, Fedora or
CentOS - but I haven't tried it - I suppose there is some work to do to
get this working.

* Do you want to setup both hosts from scratch at each test (Engine Host
and Node (or VDSM enabled OS))?

* The Engine side host will also need to pull in the igor-client (which
communicates with the igor daemon, the daemon is not sshing into the
client [or host under test]).

* We need to decide when an integration test shall be run.
I'd suggest to run any beta or release candidate against each other.

* A couple of notes on the chart:
  - koan is not used.
  - igor doesn't handle the {kickstarts,RPMS} itself

* Don't underestimate the work to write the testcases, testsuites and
plans :)

I nice first step would be to write an igor testplan which sets up Node
and Engine - maybe it even registers the Node.
This 'simple' testsuite will force us to prepare the ground for more
complex testsuites.
I also strongly recommend to do he development with VMs instead of real
hardware.

Greetings
fabian



From wudxw at linux.vnet.ibm.com  Mon Apr  8 13:59:05 2013
From: wudxw at linux.vnet.ibm.com (Mark Wu)
Date: Mon, 08 Apr 2013 21:59:05 +0800
Subject: oVirt cluster level test proposal
In-Reply-To: <1365092504.11957.18.camel@fdeutsch-laptop.local>
References: <51502196.6070508@linux.vnet.ibm.com>
	<1365092504.11957.18.camel@fdeutsch-laptop.local>
Message-ID: <5162CD29.90706@linux.vnet.ibm.com>

On Fri 05 Apr 2013 12:21:44 AM CST, Fabian Deutsch wrote:
> Am Montag, den 25.03.2013, 18:06 +0800 schrieb Mark Wu:
>> Hi guys,
>>
>> As per the discussion before, we don't have  integrated functional tests
>> for oVirt.  So I would like to propose a cluster level test plan.
>> Basically, it's composed of igord, cobbler and test cases based on
>> engine REST api. Cobbler stores kickstart files, installation images and
>> test packages repo.
>> Igor is responsible to setup test environment according to the test plan
>> and run the test cases inside test host.  I write down a wiki page to
>> describe the work flow:
>> http://www.ovirt.org/Ovirt_cluster_level_test
>>
>> @Fabian,  according to my investigation on igor,  it should be not
>> difficult to enhance igor to support this proposal.  I would like to get
>> your opinion on it.
>
> Hey Mark,
Fabian, thanks for your good comments. Please see my comments inline.
>
> nice to see this overall proposal which covers all components of oVirt.
> I've looked at your proposal and basically agree and think that it
> should work.
> There are a couple of things which ain't completely clear to me or what
> I'd like to comment:
>
> * It should be possible that Igor provisions a host with RHEL, Fedora or
> CentOS - but I haven't tried it - I suppose there is some work to do to
> get this working.
Yes, exactly.  Actually,  my proposal is extending or enhancing igor to 
cover all components of oVirt.
>
> * Do you want to setup both hosts from scratch at each test (Engine Host
> and Node (or VDSM enabled OS))?
Nope, I would like setup new VM based on existing template (using the 
qcow2 image).
For host,  just re-install related rpm packages. But for oVirt node, 
probably we have to re-install the
host in very test.
>
> * The Engine side host will also need to pull in the igor-client (which
> communicates with the igor daemon, the daemon is not sshing into the
> client [or host under test]).
Yes. If we use igor-client to pull tests in engine hosts, we also need 
ship the package and start
the daemon on boot.  I think running remote commands via ssh can cover 
this part. Or we could
run the igor-client by ssh if necessary.
>
> * We need to decide when an integration test shall be run.
> I'd suggest to run any beta or release candidate against each other.
>
Or weekly or biweekly to find the problem early.
> * A couple of notes on the chart:
>    - koan is not used.
>    - igor doesn't handle the {kickstarts,RPMS} itself
>
Yes, I know currently igor doesn't handle that.  But would you like to 
extend igor to support it?
Or we should leave it to other components.

> * Don't underestimate the work to write the testcases, testsuites and
> plans :)
>
> I nice first step would be to write an igor testplan which sets up Node
> and Engine - maybe it even registers the Node.
> This 'simple' testsuite will force us to prepare the ground for more
> complex testsuites.
Good point!  I going  to start with  this simple testsuite you 
mentioned.
> I also strongly recommend to do he development with VMs instead of real
> hardware.
Yes, exactly!  Unfortunately  in my experience, nested kvm is not 
stable enough.  But I think we need
use it more to push it towards stable.
>
> Greetings
> fabian
>




From danken at redhat.com  Mon Apr  8 16:13:46 2013
From: danken at redhat.com (Dan Kenigsberg)
Date: Mon, 8 Apr 2013 19:13:46 +0300
Subject: OpenStack Quantum integration feature page for 3.3
In-Reply-To: <514BFB66.5040106@redhat.com>
References: <20130318081015.GC5072@redhat.com>
	<118069132.2113469.1363595012092.JavaMail.root@redhat.com>
	<20130321131219.GH26392@redhat.com> <514B10E2.60306@redhat.com>
	<20130321210619.GA10337@redhat.com> <514BFB66.5040106@redhat.com>
Message-ID: <20130408161346.GA3100@redhat.com>

On Fri, Mar 22, 2013 at 08:34:14AM +0200, Gary Kotton wrote:
> On 03/21/2013 11:06 PM, Dan Kenigsberg wrote:
> >On Thu, Mar 21, 2013 at 03:53:38PM +0200, Gary Kotton wrote:
> >>On 03/21/2013 03:12 PM, Dan Kenigsberg wrote:
> >>>On Mon, Mar 18, 2013 at 04:23:32AM -0400, Mike Kolesnik wrote:
> >>>>----- Original Message -----
> >>>>>On Mon, Mar 18, 2013 at 03:20:45AM -0400, Mike Kolesnik wrote:
> >>>>>>Hi all,
> >>>>>>
> >>>>>>The feature page for integrating OpenStack Quantum into oVirt is
> >>>>>>available on the wiki:
> >>>>>>http://www.ovirt.org/Features/Quantum_Integration
> >>>>>>
> >>>>>A quote from "Network discovery":
> >>>>>>Currently, we assume that the networks provided by the provider are
> >>>>>>available on all hosts in the data center...
> >>>>>it is not completely clear who are "we" there. I suppose that you
> >>>>>mean
> >>>>>that Engine takes this assumption, and does not verify that a
> >>>>>specific
> >>>>>host is actually connectable by the network provider. That's not much
> >>>>>worse than what Engine does elsewhere: it does not verify that
> >>>>>network
> >>>>>"green" in one host can actually connect with network "green" on
> >>>>>another
> >>>>>host.
> >>>>"We" is oVirt as a whole.
> >>>>
> >>>>Currently we do know which network is available on which host since the user set it up.
> >>>>In the planned integration we wouldn't know, thus we will consider external network as "provided".
> >>>So *Engine* cannot tell if a host is controllable by the defined quantum
> >>>server, and therefore it has to assume that everything is all right,
> >>>putting this burden on the end user.
> >>>
> >>>Garry, does Quantum provide any means to tell - ahead of time - if
> >>>provisioning a virtual network to a specific work is expected to
> >>>succeed? Or, let's say, that the host is utterly misconfigured and is
> >>>unknown to Quantum? Can it at least be done for plugins with host
> >>>agents?
> >>I am not really sure that I understand your question. Can you please
> >>clarify what you mean by "if provisioning a virtual network ... is
> >>expected to succeed".
> >>
> >>Lets take two open source examples:
> >>openvswitch - a integration bridge is provisioned ahed of time, that
> >>is, each host will need to provision an integration bridge on the
> >>OVS. When the agent detects that new port is created on the bridge
> >>then it will configure the relevant VLAN. The Quantum service will
> >>be notified that the port is "UP"
> >>linuxbridge - the nova host that is deplying the VM will create the
> >>networkwork if it does not exist. If this fails the a VM will not be
> >>spawned. Once the network is up the agent will configure the VLAN.
> >>The quantum service will be notified that the port is "UP"
> >>
> >>The assumption is that the hosts will be configured correctly. If
> >I would like to have a clue - ahead of time - if that assumption is
> >valid. The two examples above require the host to notify the Quantum
> >service. But what if the host agent is notifying an utterly different
> >service? Is there some kind of liveliness check between the host and its
> >Quantum service?
> 
> The communication between the host and the quantum service is done
> by a message broker. If the host is updating a different service
> then the port state will not be set as "UP"
> In grizzy a feature was added where one is able to get the state of
> the agents for example:
> 
> openstack at dhcp-4-227:~/devstack$ quantum agent-list
> +--------------------------------------+--------------------+---------------------------+-------+----------------+
> | id                                   | agent_type         | host
> | alive | admin_state_up |
> +--------------------------------------+--------------------+---------------------------+-------+----------------+
> | 1ab54438-9338-4050-a818-7faf28d31eb2 | DHCP agent         |
> dhcp-4-227.tlv.redhat.com | :-)   | True           |
> | 396f03eb-b3af-4ddf-b52f-6a0de65b0574 | L3 agent           |
> dhcp-4-227.tlv.redhat.com | :-)   | True           |
> | 876c7474-9e2e-4533-a27e-1de8ac3544c6 | Open vSwitch agent |
> dhcp-4-227.tlv.redhat.com | :-)   | True           |
> +--------------------------------------+--------------------+---------------------------+-------+----------------+
> 
> If you get an XXX instead of a :) then the agent is down. The above
> is used for scheduling networks and routers to the dhcp and l3
> agents respectively.
> 
> Does this help?

Yes. It seems that this is done at the Quantum server. Is it exposed by
the Quantum API or an extension thereof?

This information is valuable for scheduling VMs, and I'd like to
understand how oVirt can tap into it.

Also, what happens with agent-less plugins? Can Quantum tell who are the
hosts that it controls?

Regards,
Dan.


From gkotton at redhat.com  Mon Apr  8 16:34:12 2013
From: gkotton at redhat.com (Gary Kotton)
Date: Mon, 08 Apr 2013 19:34:12 +0300
Subject: OpenStack Quantum integration feature page for 3.3
In-Reply-To: <20130408161346.GA3100@redhat.com>
References: <20130318081015.GC5072@redhat.com>
	<118069132.2113469.1363595012092.JavaMail.root@redhat.com>
	<20130321131219.GH26392@redhat.com> <514B10E2.60306@redhat.com>
	<20130321210619.GA10337@redhat.com> <514BFB66.5040106@redhat.com>
	<20130408161346.GA3100@redhat.com>
Message-ID: <5162F184.3060104@redhat.com>

On 04/08/2013 07:13 PM, Dan Kenigsberg wrote:
> On Fri, Mar 22, 2013 at 08:34:14AM +0200, Gary Kotton wrote:
>> On 03/21/2013 11:06 PM, Dan Kenigsberg wrote:
>>> On Thu, Mar 21, 2013 at 03:53:38PM +0200, Gary Kotton wrote:
>>>> On 03/21/2013 03:12 PM, Dan Kenigsberg wrote:
>>>>> On Mon, Mar 18, 2013 at 04:23:32AM -0400, Mike Kolesnik wrote:
>>>>>> ----- Original Message -----
>>>>>>> On Mon, Mar 18, 2013 at 03:20:45AM -0400, Mike Kolesnik wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> The feature page for integrating OpenStack Quantum into oVirt is
>>>>>>>> available on the wiki:
>>>>>>>> http://www.ovirt.org/Features/Quantum_Integration
>>>>>>>>
>>>>>>> A quote from "Network discovery":
>>>>>>>> Currently, we assume that the networks provided by the provider are
>>>>>>>> available on all hosts in the data center...
>>>>>>> it is not completely clear who are "we" there. I suppose that you
>>>>>>> mean
>>>>>>> that Engine takes this assumption, and does not verify that a
>>>>>>> specific
>>>>>>> host is actually connectable by the network provider. That's not much
>>>>>>> worse than what Engine does elsewhere: it does not verify that
>>>>>>> network
>>>>>>> "green" in one host can actually connect with network "green" on
>>>>>>> another
>>>>>>> host.
>>>>>> "We" is oVirt as a whole.
>>>>>>
>>>>>> Currently we do know which network is available on which host since the user set it up.
>>>>>> In the planned integration we wouldn't know, thus we will consider external network as "provided".
>>>>> So *Engine* cannot tell if a host is controllable by the defined quantum
>>>>> server, and therefore it has to assume that everything is all right,
>>>>> putting this burden on the end user.
>>>>>
>>>>> Garry, does Quantum provide any means to tell - ahead of time - if
>>>>> provisioning a virtual network to a specific work is expected to
>>>>> succeed? Or, let's say, that the host is utterly misconfigured and is
>>>>> unknown to Quantum? Can it at least be done for plugins with host
>>>>> agents?
>>>> I am not really sure that I understand your question. Can you please
>>>> clarify what you mean by "if provisioning a virtual network ... is
>>>> expected to succeed".
>>>>
>>>> Lets take two open source examples:
>>>> openvswitch - a integration bridge is provisioned ahed of time, that
>>>> is, each host will need to provision an integration bridge on the
>>>> OVS. When the agent detects that new port is created on the bridge
>>>> then it will configure the relevant VLAN. The Quantum service will
>>>> be notified that the port is "UP"
>>>> linuxbridge - the nova host that is deplying the VM will create the
>>>> networkwork if it does not exist. If this fails the a VM will not be
>>>> spawned. Once the network is up the agent will configure the VLAN.
>>>> The quantum service will be notified that the port is "UP"
>>>>
>>>> The assumption is that the hosts will be configured correctly. If
>>> I would like to have a clue - ahead of time - if that assumption is
>>> valid. The two examples above require the host to notify the Quantum
>>> service. But what if the host agent is notifying an utterly different
>>> service? Is there some kind of liveliness check between the host and its
>>> Quantum service?
>> The communication between the host and the quantum service is done
>> by a message broker. If the host is updating a different service
>> then the port state will not be set as "UP"
>> In grizzy a feature was added where one is able to get the state of
>> the agents for example:
>>
>> openstack at dhcp-4-227:~/devstack$ quantum agent-list
>> +--------------------------------------+--------------------+---------------------------+-------+----------------+
>> | id                                   | agent_type         | host
>> | alive | admin_state_up |
>> +--------------------------------------+--------------------+---------------------------+-------+----------------+
>> | 1ab54438-9338-4050-a818-7faf28d31eb2 | DHCP agent         |
>> dhcp-4-227.tlv.redhat.com | :-)   | True           |
>> | 396f03eb-b3af-4ddf-b52f-6a0de65b0574 | L3 agent           |
>> dhcp-4-227.tlv.redhat.com | :-)   | True           |
>> | 876c7474-9e2e-4533-a27e-1de8ac3544c6 | Open vSwitch agent |
>> dhcp-4-227.tlv.redhat.com | :-)   | True           |
>> +--------------------------------------+--------------------+---------------------------+-------+----------------+
>>
>> If you get an XXX instead of a :) then the agent is down. The above
>> is used for scheduling networks and routers to the dhcp and l3
>> agents respectively.
>>
>> Does this help?
> Yes. It seems that this is done at the Quantum server. Is it exposed by
> the Quantum API or an extension thereof?

This is exposed by a Quantum extension. It is not part of the official 
API and may not be supported by some plugins.
You are nonetheless able to query which extensions are supported by the 
plugin.

>
> This information is valuable for scheduling VMs, and I'd like to
> understand how oVirt can tap into it.

If the above extension is supported and the agent on the host is down 
then the scheduler should exclude that host - if that host is selected 
then the VM will not have network connectivity.

>
> Also, what happens with agent-less plugins? Can Quantum tell who are the
> hosts that it controls?

This depends on the extensions supported by the plugin.

At the moment there is a patch in progress (Havana) which will have the 
extension for the port bindings store the host. Once again this may not 
be supported by some plugins.

>
> Regards,
> Dan.



From mkolesni at redhat.com  Tue Apr  9 07:16:04 2013
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Tue, 9 Apr 2013 03:16:04 -0400 (EDT)
Subject: OpenStack Quantum integration feature page for 3.3
In-Reply-To: <5162F184.3060104@redhat.com>
References: <20130318081015.GC5072@redhat.com>
	<118069132.2113469.1363595012092.JavaMail.root@redhat.com>
	<20130321131219.GH26392@redhat.com> <514B10E2.60306@redhat.com>
	<20130321210619.GA10337@redhat.com> <514BFB66.5040106@redhat.com>
	<20130408161346.GA3100@redhat.com> <5162F184.3060104@redhat.com>
Message-ID: <863242454.1383190.1365491764510.JavaMail.root@redhat.com>

----- Original Message -----
> On 04/08/2013 07:13 PM, Dan Kenigsberg wrote:
> > On Fri, Mar 22, 2013 at 08:34:14AM +0200, Gary Kotton wrote:
> >> On 03/21/2013 11:06 PM, Dan Kenigsberg wrote:
> >>> On Thu, Mar 21, 2013 at 03:53:38PM +0200, Gary Kotton wrote:
> >>>> On 03/21/2013 03:12 PM, Dan Kenigsberg wrote:
> >>>>> On Mon, Mar 18, 2013 at 04:23:32AM -0400, Mike Kolesnik wrote:
> >>>>>> ----- Original Message -----
> >>>>>>> On Mon, Mar 18, 2013 at 03:20:45AM -0400, Mike Kolesnik wrote:
> >>>>>>>> Hi all,
> >>>>>>>>
> >>>>>>>> The feature page for integrating OpenStack Quantum into oVirt is
> >>>>>>>> available on the wiki:
> >>>>>>>> http://www.ovirt.org/Features/Quantum_Integration
> >>>>>>>>
> >>>>>>> A quote from "Network discovery":
> >>>>>>>> Currently, we assume that the networks provided by the provider are
> >>>>>>>> available on all hosts in the data center...
> >>>>>>> it is not completely clear who are "we" there. I suppose that you
> >>>>>>> mean
> >>>>>>> that Engine takes this assumption, and does not verify that a
> >>>>>>> specific
> >>>>>>> host is actually connectable by the network provider. That's not much
> >>>>>>> worse than what Engine does elsewhere: it does not verify that
> >>>>>>> network
> >>>>>>> "green" in one host can actually connect with network "green" on
> >>>>>>> another
> >>>>>>> host.
> >>>>>> "We" is oVirt as a whole.
> >>>>>>
> >>>>>> Currently we do know which network is available on which host since
> >>>>>> the user set it up.
> >>>>>> In the planned integration we wouldn't know, thus we will consider
> >>>>>> external network as "provided".
> >>>>> So *Engine* cannot tell if a host is controllable by the defined
> >>>>> quantum
> >>>>> server, and therefore it has to assume that everything is all right,
> >>>>> putting this burden on the end user.
> >>>>>
> >>>>> Garry, does Quantum provide any means to tell - ahead of time - if
> >>>>> provisioning a virtual network to a specific work is expected to
> >>>>> succeed? Or, let's say, that the host is utterly misconfigured and is
> >>>>> unknown to Quantum? Can it at least be done for plugins with host
> >>>>> agents?
> >>>> I am not really sure that I understand your question. Can you please
> >>>> clarify what you mean by "if provisioning a virtual network ... is
> >>>> expected to succeed".
> >>>>
> >>>> Lets take two open source examples:
> >>>> openvswitch - a integration bridge is provisioned ahed of time, that
> >>>> is, each host will need to provision an integration bridge on the
> >>>> OVS. When the agent detects that new port is created on the bridge
> >>>> then it will configure the relevant VLAN. The Quantum service will
> >>>> be notified that the port is "UP"
> >>>> linuxbridge - the nova host that is deplying the VM will create the
> >>>> networkwork if it does not exist. If this fails the a VM will not be
> >>>> spawned. Once the network is up the agent will configure the VLAN.
> >>>> The quantum service will be notified that the port is "UP"
> >>>>
> >>>> The assumption is that the hosts will be configured correctly. If
> >>> I would like to have a clue - ahead of time - if that assumption is
> >>> valid. The two examples above require the host to notify the Quantum
> >>> service. But what if the host agent is notifying an utterly different
> >>> service? Is there some kind of liveliness check between the host and its
> >>> Quantum service?
> >> The communication between the host and the quantum service is done
> >> by a message broker. If the host is updating a different service
> >> then the port state will not be set as "UP"
> >> In grizzy a feature was added where one is able to get the state of
> >> the agents for example:
> >>
> >> openstack at dhcp-4-227:~/devstack$ quantum agent-list
> >> +--------------------------------------+--------------------+---------------------------+-------+----------------+
> >> | id                                   | agent_type         | host
> >> | alive | admin_state_up |
> >> +--------------------------------------+--------------------+---------------------------+-------+----------------+
> >> | 1ab54438-9338-4050-a818-7faf28d31eb2 | DHCP agent         |
> >> dhcp-4-227.tlv.redhat.com | :-)   | True           |
> >> | 396f03eb-b3af-4ddf-b52f-6a0de65b0574 | L3 agent           |
> >> dhcp-4-227.tlv.redhat.com | :-)   | True           |
> >> | 876c7474-9e2e-4533-a27e-1de8ac3544c6 | Open vSwitch agent |
> >> dhcp-4-227.tlv.redhat.com | :-)   | True           |
> >> +--------------------------------------+--------------------+---------------------------+-------+----------------+
> >>
> >> If you get an XXX instead of a :) then the agent is down. The above
> >> is used for scheduling networks and routers to the dhcp and l3
> >> agents respectively.
> >>
> >> Does this help?
> > Yes. It seems that this is done at the Quantum server. Is it exposed by
> > the Quantum API or an extension thereof?
> 
> This is exposed by a Quantum extension. It is not part of the official
> API and may not be supported by some plugins.
> You are nonetheless able to query which extensions are supported by the
> plugin.
> 
> >
> > This information is valuable for scheduling VMs, and I'd like to
> > understand how oVirt can tap into it.
> 
> If the above extension is supported and the agent on the host is down
> then the scheduler should exclude that host - if that host is selected
> then the VM will not have network connectivity.
> 
> >
> > Also, what happens with agent-less plugins? Can Quantum tell who are the
> > hosts that it controls?
> 
> This depends on the extensions supported by the plugin.
> 
> At the moment there is a patch in progress (Havana) which will have the
> extension for the port bindings store the host. Once again this may not
> be supported by some plugins.

Do you know if it will be supported for Linux Bridge & OVS plugins?

> 
> >
> > Regards,
> > Dan.
> 
> 


From gkotton at redhat.com  Tue Apr  9 07:20:15 2013
From: gkotton at redhat.com (Gary Kotton)
Date: Tue, 09 Apr 2013 10:20:15 +0300
Subject: OpenStack Quantum integration feature page for 3.3
In-Reply-To: <863242454.1383190.1365491764510.JavaMail.root@redhat.com>
References: <20130318081015.GC5072@redhat.com>
	<118069132.2113469.1363595012092.JavaMail.root@redhat.com>
	<20130321131219.GH26392@redhat.com> <514B10E2.60306@redhat.com>
	<20130321210619.GA10337@redhat.com> <514BFB66.5040106@redhat.com>
	<20130408161346.GA3100@redhat.com> <5162F184.3060104@redhat.com>
	<863242454.1383190.1365491764510.JavaMail.root@redhat.com>
Message-ID: <5163C12F.6070405@redhat.com>

On 04/09/2013 10:16 AM, Mike Kolesnik wrote:
> ----- Original Message -----
>> On 04/08/2013 07:13 PM, Dan Kenigsberg wrote:
>>> On Fri, Mar 22, 2013 at 08:34:14AM +0200, Gary Kotton wrote:
>>>> On 03/21/2013 11:06 PM, Dan Kenigsberg wrote:
>>>>> On Thu, Mar 21, 2013 at 03:53:38PM +0200, Gary Kotton wrote:
>>>>>> On 03/21/2013 03:12 PM, Dan Kenigsberg wrote:
>>>>>>> On Mon, Mar 18, 2013 at 04:23:32AM -0400, Mike Kolesnik wrote:
>>>>>>>> ----- Original Message -----
>>>>>>>>> On Mon, Mar 18, 2013 at 03:20:45AM -0400, Mike Kolesnik wrote:
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> The feature page for integrating OpenStack Quantum into oVirt is
>>>>>>>>>> available on the wiki:
>>>>>>>>>> http://www.ovirt.org/Features/Quantum_Integration
>>>>>>>>>>
>>>>>>>>> A quote from "Network discovery":
>>>>>>>>>> Currently, we assume that the networks provided by the provider are
>>>>>>>>>> available on all hosts in the data center...
>>>>>>>>> it is not completely clear who are "we" there. I suppose that you
>>>>>>>>> mean
>>>>>>>>> that Engine takes this assumption, and does not verify that a
>>>>>>>>> specific
>>>>>>>>> host is actually connectable by the network provider. That's not much
>>>>>>>>> worse than what Engine does elsewhere: it does not verify that
>>>>>>>>> network
>>>>>>>>> "green" in one host can actually connect with network "green" on
>>>>>>>>> another
>>>>>>>>> host.
>>>>>>>> "We" is oVirt as a whole.
>>>>>>>>
>>>>>>>> Currently we do know which network is available on which host since
>>>>>>>> the user set it up.
>>>>>>>> In the planned integration we wouldn't know, thus we will consider
>>>>>>>> external network as "provided".
>>>>>>> So *Engine* cannot tell if a host is controllable by the defined
>>>>>>> quantum
>>>>>>> server, and therefore it has to assume that everything is all right,
>>>>>>> putting this burden on the end user.
>>>>>>>
>>>>>>> Garry, does Quantum provide any means to tell - ahead of time - if
>>>>>>> provisioning a virtual network to a specific work is expected to
>>>>>>> succeed? Or, let's say, that the host is utterly misconfigured and is
>>>>>>> unknown to Quantum? Can it at least be done for plugins with host
>>>>>>> agents?
>>>>>> I am not really sure that I understand your question. Can you please
>>>>>> clarify what you mean by "if provisioning a virtual network ... is
>>>>>> expected to succeed".
>>>>>>
>>>>>> Lets take two open source examples:
>>>>>> openvswitch - a integration bridge is provisioned ahed of time, that
>>>>>> is, each host will need to provision an integration bridge on the
>>>>>> OVS. When the agent detects that new port is created on the bridge
>>>>>> then it will configure the relevant VLAN. The Quantum service will
>>>>>> be notified that the port is "UP"
>>>>>> linuxbridge - the nova host that is deplying the VM will create the
>>>>>> networkwork if it does not exist. If this fails the a VM will not be
>>>>>> spawned. Once the network is up the agent will configure the VLAN.
>>>>>> The quantum service will be notified that the port is "UP"
>>>>>>
>>>>>> The assumption is that the hosts will be configured correctly. If
>>>>> I would like to have a clue - ahead of time - if that assumption is
>>>>> valid. The two examples above require the host to notify the Quantum
>>>>> service. But what if the host agent is notifying an utterly different
>>>>> service? Is there some kind of liveliness check between the host and its
>>>>> Quantum service?
>>>> The communication between the host and the quantum service is done
>>>> by a message broker. If the host is updating a different service
>>>> then the port state will not be set as "UP"
>>>> In grizzy a feature was added where one is able to get the state of
>>>> the agents for example:
>>>>
>>>> openstack at dhcp-4-227:~/devstack$ quantum agent-list
>>>> +--------------------------------------+--------------------+---------------------------+-------+----------------+
>>>> | id                                   | agent_type         | host
>>>> | alive | admin_state_up |
>>>> +--------------------------------------+--------------------+---------------------------+-------+----------------+
>>>> | 1ab54438-9338-4050-a818-7faf28d31eb2 | DHCP agent         |
>>>> dhcp-4-227.tlv.redhat.com | :-)   | True           |
>>>> | 396f03eb-b3af-4ddf-b52f-6a0de65b0574 | L3 agent           |
>>>> dhcp-4-227.tlv.redhat.com | :-)   | True           |
>>>> | 876c7474-9e2e-4533-a27e-1de8ac3544c6 | Open vSwitch agent |
>>>> dhcp-4-227.tlv.redhat.com | :-)   | True           |
>>>> +--------------------------------------+--------------------+---------------------------+-------+----------------+
>>>>
>>>> If you get an XXX instead of a :) then the agent is down. The above
>>>> is used for scheduling networks and routers to the dhcp and l3
>>>> agents respectively.
>>>>
>>>> Does this help?
>>> Yes. It seems that this is done at the Quantum server. Is it exposed by
>>> the Quantum API or an extension thereof?
>> This is exposed by a Quantum extension. It is not part of the official
>> API and may not be supported by some plugins.
>> You are nonetheless able to query which extensions are supported by the
>> plugin.
>>
>>> This information is valuable for scheduling VMs, and I'd like to
>>> understand how oVirt can tap into it.
>> If the above extension is supported and the agent on the host is down
>> then the scheduler should exclude that host - if that host is selected
>> then the VM will not have network connectivity.
>>
>>> Also, what happens with agent-less plugins? Can Quantum tell who are the
>>> hosts that it controls?
>> This depends on the extensions supported by the plugin.
>>
>> At the moment there is a patch in progress (Havana) which will have the
>> extension for the port bindings store the host. Once again this may not
>> be supported by some plugins.
> Do you know if it will be supported for Linux Bridge&  OVS plugins?

Yes, this is currently supported by these plugins.

>
>>> Regards,
>>> Dan.
>>



From mkolesni at redhat.com  Tue Apr  9 08:01:01 2013
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Tue, 9 Apr 2013 04:01:01 -0400 (EDT)
Subject: OpenStack Quantum integration feature page for 3.3
In-Reply-To: <5163C12F.6070405@redhat.com>
References: <20130318081015.GC5072@redhat.com> <514B10E2.60306@redhat.com>
	<20130321210619.GA10337@redhat.com> <514BFB66.5040106@redhat.com>
	<20130408161346.GA3100@redhat.com> <5162F184.3060104@redhat.com>
	<863242454.1383190.1365491764510.JavaMail.root@redhat.com>
	<5163C12F.6070405@redhat.com>
Message-ID: <721179564.1394725.1365494461793.JavaMail.root@redhat.com>

----- Original Message -----
> On 04/09/2013 10:16 AM, Mike Kolesnik wrote:
> > ----- Original Message -----
> >> On 04/08/2013 07:13 PM, Dan Kenigsberg wrote:
> >>> On Fri, Mar 22, 2013 at 08:34:14AM +0200, Gary Kotton wrote:
> >>>> On 03/21/2013 11:06 PM, Dan Kenigsberg wrote:
> >>>>> On Thu, Mar 21, 2013 at 03:53:38PM +0200, Gary Kotton wrote:
> >>>>>> On 03/21/2013 03:12 PM, Dan Kenigsberg wrote:
> >>>>>>> On Mon, Mar 18, 2013 at 04:23:32AM -0400, Mike Kolesnik wrote:
> >>>>>>>> ----- Original Message -----
> >>>>>>>>> On Mon, Mar 18, 2013 at 03:20:45AM -0400, Mike Kolesnik wrote:
> >>>>>>>>>> Hi all,
> >>>>>>>>>>
> >>>>>>>>>> The feature page for integrating OpenStack Quantum into oVirt is
> >>>>>>>>>> available on the wiki:
> >>>>>>>>>> http://www.ovirt.org/Features/Quantum_Integration
> >>>>>>>>>>
> >>>>>>>>> A quote from "Network discovery":
> >>>>>>>>>> Currently, we assume that the networks provided by the provider
> >>>>>>>>>> are
> >>>>>>>>>> available on all hosts in the data center...
> >>>>>>>>> it is not completely clear who are "we" there. I suppose that you
> >>>>>>>>> mean
> >>>>>>>>> that Engine takes this assumption, and does not verify that a
> >>>>>>>>> specific
> >>>>>>>>> host is actually connectable by the network provider. That's not
> >>>>>>>>> much
> >>>>>>>>> worse than what Engine does elsewhere: it does not verify that
> >>>>>>>>> network
> >>>>>>>>> "green" in one host can actually connect with network "green" on
> >>>>>>>>> another
> >>>>>>>>> host.
> >>>>>>>> "We" is oVirt as a whole.
> >>>>>>>>
> >>>>>>>> Currently we do know which network is available on which host since
> >>>>>>>> the user set it up.
> >>>>>>>> In the planned integration we wouldn't know, thus we will consider
> >>>>>>>> external network as "provided".
> >>>>>>> So *Engine* cannot tell if a host is controllable by the defined
> >>>>>>> quantum
> >>>>>>> server, and therefore it has to assume that everything is all right,
> >>>>>>> putting this burden on the end user.
> >>>>>>>
> >>>>>>> Garry, does Quantum provide any means to tell - ahead of time - if
> >>>>>>> provisioning a virtual network to a specific work is expected to
> >>>>>>> succeed? Or, let's say, that the host is utterly misconfigured and is
> >>>>>>> unknown to Quantum? Can it at least be done for plugins with host
> >>>>>>> agents?
> >>>>>> I am not really sure that I understand your question. Can you please
> >>>>>> clarify what you mean by "if provisioning a virtual network ... is
> >>>>>> expected to succeed".
> >>>>>>
> >>>>>> Lets take two open source examples:
> >>>>>> openvswitch - a integration bridge is provisioned ahed of time, that
> >>>>>> is, each host will need to provision an integration bridge on the
> >>>>>> OVS. When the agent detects that new port is created on the bridge
> >>>>>> then it will configure the relevant VLAN. The Quantum service will
> >>>>>> be notified that the port is "UP"
> >>>>>> linuxbridge - the nova host that is deplying the VM will create the
> >>>>>> networkwork if it does not exist. If this fails the a VM will not be
> >>>>>> spawned. Once the network is up the agent will configure the VLAN.
> >>>>>> The quantum service will be notified that the port is "UP"
> >>>>>>
> >>>>>> The assumption is that the hosts will be configured correctly. If
> >>>>> I would like to have a clue - ahead of time - if that assumption is
> >>>>> valid. The two examples above require the host to notify the Quantum
> >>>>> service. But what if the host agent is notifying an utterly different
> >>>>> service? Is there some kind of liveliness check between the host and
> >>>>> its
> >>>>> Quantum service?
> >>>> The communication between the host and the quantum service is done
> >>>> by a message broker. If the host is updating a different service
> >>>> then the port state will not be set as "UP"
> >>>> In grizzy a feature was added where one is able to get the state of
> >>>> the agents for example:
> >>>>
> >>>> openstack at dhcp-4-227:~/devstack$ quantum agent-list
> >>>> +--------------------------------------+--------------------+---------------------------+-------+----------------+
> >>>> | id                                   | agent_type         | host
> >>>> | alive | admin_state_up |
> >>>> +--------------------------------------+--------------------+---------------------------+-------+----------------+
> >>>> | 1ab54438-9338-4050-a818-7faf28d31eb2 | DHCP agent         |
> >>>> dhcp-4-227.tlv.redhat.com | :-)   | True           |
> >>>> | 396f03eb-b3af-4ddf-b52f-6a0de65b0574 | L3 agent           |
> >>>> dhcp-4-227.tlv.redhat.com | :-)   | True           |
> >>>> | 876c7474-9e2e-4533-a27e-1de8ac3544c6 | Open vSwitch agent |
> >>>> dhcp-4-227.tlv.redhat.com | :-)   | True           |
> >>>> +--------------------------------------+--------------------+---------------------------+-------+----------------+
> >>>>
> >>>> If you get an XXX instead of a :) then the agent is down. The above
> >>>> is used for scheduling networks and routers to the dhcp and l3
> >>>> agents respectively.
> >>>>
> >>>> Does this help?
> >>> Yes. It seems that this is done at the Quantum server. Is it exposed by
> >>> the Quantum API or an extension thereof?
> >> This is exposed by a Quantum extension. It is not part of the official
> >> API and may not be supported by some plugins.
> >> You are nonetheless able to query which extensions are supported by the
> >> plugin.
> >>
> >>> This information is valuable for scheduling VMs, and I'd like to
> >>> understand how oVirt can tap into it.
> >> If the above extension is supported and the agent on the host is down
> >> then the scheduler should exclude that host - if that host is selected
> >> then the VM will not have network connectivity.
> >>
> >>> Also, what happens with agent-less plugins? Can Quantum tell who are the
> >>> hosts that it controls?
> >> This depends on the extensions supported by the plugin.
> >>
> >> At the moment there is a patch in progress (Havana) which will have the
> >> extension for the port bindings store the host. Once again this may not
> >> be supported by some plugins.
> > Do you know if it will be supported for Linux Bridge&  OVS plugins?
> 
> Yes, this is currently supported by these plugins.
> 

Is there an API reference that you can please provide that documents this extension?

> 
> 


From gkotton at redhat.com  Tue Apr  9 11:45:05 2013
From: gkotton at redhat.com (Gary Kotton)
Date: Tue, 09 Apr 2013 14:45:05 +0300
Subject: OpenStack Quantum integration feature page for 3.3
In-Reply-To: <721179564.1394725.1365494461793.JavaMail.root@redhat.com>
References: <20130318081015.GC5072@redhat.com> <514B10E2.60306@redhat.com>
	<20130321210619.GA10337@redhat.com> <514BFB66.5040106@redhat.com>
	<20130408161346.GA3100@redhat.com> <5162F184.3060104@redhat.com>
	<863242454.1383190.1365491764510.JavaMail.root@redhat.com>
	<5163C12F.6070405@redhat.com>
	<721179564.1394725.1365494461793.JavaMail.root@redhat.com>
Message-ID: <5163FF41.9070100@redhat.com>

On 04/09/2013 11:01 AM, Mike Kolesnik wrote:
> ----- Original Message -----
>> On 04/09/2013 10:16 AM, Mike Kolesnik wrote:
>>> ----- Original Message -----
>>>> On 04/08/2013 07:13 PM, Dan Kenigsberg wrote:
>>>>> On Fri, Mar 22, 2013 at 08:34:14AM +0200, Gary Kotton wrote:
>>>>>> On 03/21/2013 11:06 PM, Dan Kenigsberg wrote:
>>>>>>> On Thu, Mar 21, 2013 at 03:53:38PM +0200, Gary Kotton wrote:
>>>>>>>> On 03/21/2013 03:12 PM, Dan Kenigsberg wrote:
>>>>>>>>> On Mon, Mar 18, 2013 at 04:23:32AM -0400, Mike Kolesnik wrote:
>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>> On Mon, Mar 18, 2013 at 03:20:45AM -0400, Mike Kolesnik wrote:
>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>
>>>>>>>>>>>> The feature page for integrating OpenStack Quantum into oVirt is
>>>>>>>>>>>> available on the wiki:
>>>>>>>>>>>> http://www.ovirt.org/Features/Quantum_Integration
>>>>>>>>>>>>
>>>>>>>>>>> A quote from "Network discovery":
>>>>>>>>>>>> Currently, we assume that the networks provided by the provider
>>>>>>>>>>>> are
>>>>>>>>>>>> available on all hosts in the data center...
>>>>>>>>>>> it is not completely clear who are "we" there. I suppose that you
>>>>>>>>>>> mean
>>>>>>>>>>> that Engine takes this assumption, and does not verify that a
>>>>>>>>>>> specific
>>>>>>>>>>> host is actually connectable by the network provider. That's not
>>>>>>>>>>> much
>>>>>>>>>>> worse than what Engine does elsewhere: it does not verify that
>>>>>>>>>>> network
>>>>>>>>>>> "green" in one host can actually connect with network "green" on
>>>>>>>>>>> another
>>>>>>>>>>> host.
>>>>>>>>>> "We" is oVirt as a whole.
>>>>>>>>>>
>>>>>>>>>> Currently we do know which network is available on which host since
>>>>>>>>>> the user set it up.
>>>>>>>>>> In the planned integration we wouldn't know, thus we will consider
>>>>>>>>>> external network as "provided".
>>>>>>>>> So *Engine* cannot tell if a host is controllable by the defined
>>>>>>>>> quantum
>>>>>>>>> server, and therefore it has to assume that everything is all right,
>>>>>>>>> putting this burden on the end user.
>>>>>>>>>
>>>>>>>>> Garry, does Quantum provide any means to tell - ahead of time - if
>>>>>>>>> provisioning a virtual network to a specific work is expected to
>>>>>>>>> succeed? Or, let's say, that the host is utterly misconfigured and is
>>>>>>>>> unknown to Quantum? Can it at least be done for plugins with host
>>>>>>>>> agents?
>>>>>>>> I am not really sure that I understand your question. Can you please
>>>>>>>> clarify what you mean by "if provisioning a virtual network ... is
>>>>>>>> expected to succeed".
>>>>>>>>
>>>>>>>> Lets take two open source examples:
>>>>>>>> openvswitch - a integration bridge is provisioned ahed of time, that
>>>>>>>> is, each host will need to provision an integration bridge on the
>>>>>>>> OVS. When the agent detects that new port is created on the bridge
>>>>>>>> then it will configure the relevant VLAN. The Quantum service will
>>>>>>>> be notified that the port is "UP"
>>>>>>>> linuxbridge - the nova host that is deplying the VM will create the
>>>>>>>> networkwork if it does not exist. If this fails the a VM will not be
>>>>>>>> spawned. Once the network is up the agent will configure the VLAN.
>>>>>>>> The quantum service will be notified that the port is "UP"
>>>>>>>>
>>>>>>>> The assumption is that the hosts will be configured correctly. If
>>>>>>> I would like to have a clue - ahead of time - if that assumption is
>>>>>>> valid. The two examples above require the host to notify the Quantum
>>>>>>> service. But what if the host agent is notifying an utterly different
>>>>>>> service? Is there some kind of liveliness check between the host and
>>>>>>> its
>>>>>>> Quantum service?
>>>>>> The communication between the host and the quantum service is done
>>>>>> by a message broker. If the host is updating a different service
>>>>>> then the port state will not be set as "UP"
>>>>>> In grizzy a feature was added where one is able to get the state of
>>>>>> the agents for example:
>>>>>>
>>>>>> openstack at dhcp-4-227:~/devstack$ quantum agent-list
>>>>>> +--------------------------------------+--------------------+---------------------------+-------+----------------+
>>>>>> | id                                   | agent_type         | host
>>>>>> | alive | admin_state_up |
>>>>>> +--------------------------------------+--------------------+---------------------------+-------+----------------+
>>>>>> | 1ab54438-9338-4050-a818-7faf28d31eb2 | DHCP agent         |
>>>>>> dhcp-4-227.tlv.redhat.com | :-)   | True           |
>>>>>> | 396f03eb-b3af-4ddf-b52f-6a0de65b0574 | L3 agent           |
>>>>>> dhcp-4-227.tlv.redhat.com | :-)   | True           |
>>>>>> | 876c7474-9e2e-4533-a27e-1de8ac3544c6 | Open vSwitch agent |
>>>>>> dhcp-4-227.tlv.redhat.com | :-)   | True           |
>>>>>> +--------------------------------------+--------------------+---------------------------+-------+----------------+
>>>>>>
>>>>>> If you get an XXX instead of a :) then the agent is down. The above
>>>>>> is used for scheduling networks and routers to the dhcp and l3
>>>>>> agents respectively.
>>>>>>
>>>>>> Does this help?
>>>>> Yes. It seems that this is done at the Quantum server. Is it exposed by
>>>>> the Quantum API or an extension thereof?
>>>> This is exposed by a Quantum extension. It is not part of the official
>>>> API and may not be supported by some plugins.
>>>> You are nonetheless able to query which extensions are supported by the
>>>> plugin.
>>>>
>>>>> This information is valuable for scheduling VMs, and I'd like to
>>>>> understand how oVirt can tap into it.
>>>> If the above extension is supported and the agent on the host is down
>>>> then the scheduler should exclude that host - if that host is selected
>>>> then the VM will not have network connectivity.
>>>>
>>>>> Also, what happens with agent-less plugins? Can Quantum tell who are the
>>>>> hosts that it controls?
>>>> This depends on the extensions supported by the plugin.
>>>>
>>>> At the moment there is a patch in progress (Havana) which will have the
>>>> extension for the port bindings store the host. Once again this may not
>>>> be supported by some plugins.
>>> Do you know if it will be supported for Linux Bridge&   OVS plugins?
>> Yes, this is currently supported by these plugins.
>>
> Is there an API reference that you can please provide that documents this extension?

The available extensions can be retrieved via - 
http://docs.openstack.org/api/openstack-network/2.0/content/retrieve_extensions.html

You can also look at 
http://docs.openstack.org/trunk/openstack-network/admin/content/demo_multiple_operation.html

The code is always the most up to date :)

https://github.com/openstack/quantum/blob/master/quantum/extensions/agentscheduler.py

>
>>



From dfediuck at redhat.com  Sun Apr 14 14:39:56 2013
From: dfediuck at redhat.com (Doron Fediuck)
Date: Sun, 14 Apr 2013 10:39:56 -0400 (EDT)
Subject: oVirt history; now in starwars!
In-Reply-To: <454011345.213773.1365950222353.JavaMail.root@redhat.com>
Message-ID: <841637458.213980.1365950396009.JavaMail.root@redhat.com>

Here's a better way to see the project history:

Engine
http://starlogs.net/#oVirt/ovirt-engine

VDSM
http://starlogs.net/#oVirt/vdsm


From wudxw at linux.vnet.ibm.com  Mon Apr 15 14:22:16 2013
From: wudxw at linux.vnet.ibm.com (Mark Wu)
Date: Mon, 15 Apr 2013 22:22:16 +0800
Subject: What's the scalability target of oVirt?
Message-ID: <516C0D18.5030709@linux.vnet.ibm.com>

Hi guys,

As we know,  oVirt is not designed for cloud. It targets for private 
datacenter. I heard some scalability problems about oVirt.
It could be caused by misusing. The workload is too heavy for oVirt 
obviously.  But how can we determine if the load is out of
range oVirt can handle, or oVirt doesn't scale well as expected because 
of some problem. So what's the scalability target of oVirt?

how many hosts can oVirt manage?
how many VMs can oVirt manage?

Is there any declaration about it?

Thanks!
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20130415/61ea4e11/attachment.html>

From iheim at redhat.com  Sat Apr 20 17:51:35 2013
From: iheim at redhat.com (Itamar Heim)
Date: Sat, 20 Apr 2013 20:51:35 +0300
Subject: What's the scalability target of oVirt?
In-Reply-To: <516C0D18.5030709@linux.vnet.ibm.com>
References: <516C0D18.5030709@linux.vnet.ibm.com>
Message-ID: <5172D5A7.8090407@redhat.com>

On 04/15/2013 05:22 PM, Mark Wu wrote:
> Hi guys,
>
> As we know,  oVirt is not designed for cloud. It targets for private
> datacenter. I heard some scalability problems about oVirt.
> It could be caused by misusing. The workload is too heavy for oVirt
> obviously.  But how can we determine if the load is out of
> range oVirt can handle, or oVirt doesn't scale well as expected because
> of some problem. So what's the scalability target of oVirt?
>
> how many hosts can oVirt manage?

in general, scalability is linear on the engine, so its a matter of how 
strong your engine is. you shouldn't have an issue with a few hundred 
hosts (but not in same DC).
your db will need more than a single spindle for such a load.

> how many VMs can oVirt manage?

should be in the thousands without an issue as well.

>
> Is there any declaration about it?

there aren't too many technical limits, just an issue of testing, which 
for ovirt means someone in the community trying it at such a scale and 
helping the developers resolve issues they tackle which may only 
manifest in large scale/loads.


From iheim at redhat.com  Sat Apr 20 20:04:31 2013
From: iheim at redhat.com (Itamar Heim)
Date: Sat, 20 Apr 2013 23:04:31 +0300
Subject: OpenStack Quantum integration feature page for 3.3
In-Reply-To: <971394683.2095416.1363591245101.JavaMail.root@redhat.com>
References: <971394683.2095416.1363591245101.JavaMail.root@redhat.com>
Message-ID: <5172F4CF.60007@redhat.com>

On 03/18/2013 09:20 AM, Mike Kolesnik wrote:
> Hi all,
>
> The feature page for integrating OpenStack Quantum into oVirt is
> available on the wiki:
> http://www.ovirt.org/Features/Quantum_Integration
>
> Please comment.
>
> Regards,
> Mike
>
>
>
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
>

A few questions/comments (inlining relevant parts of 
http://www.ovirt.org/Features/Detailed_Quantum_Integration)

> Support for OVS plugin?

ovs vs. bridge - since we already have bridge support in oVirt, i think 
ovs support is a higher motivation for integrating with quantum.

mike - what's the plan for ovirt-node support for qunatum agents?

 > Current implementation will be done by hooks.

iiuc, this is a temp solution, and you plan to make it a fully featured 
item later on as the integration matures?

> Each network can be provided either by oVirt or by the external provider.

did we look at our code to understand what it would mean to refactor the 
ovirt network code as an external provider as well (doesn't have to be 
out of process, just generalize/modularize our code and not have private 
cases) - there is work for doing something similar for the pluggable 
scheduler, first refactoring the existing scheduling code out as well.

> If a network is externally provided, it will not be editable in oVirt, since the external provider is responsible for managing the actual network configuration.

unless we add support for editing it via the external provider (like we 
support adding an external network and importing it from the external 
provider)?

> This effectively means that the user is responsible for quantum availability on all the hosts in a given cluster the external network is attached to.

we can consider an external provider to also have a health check api, 
then engine can alert on that service not being available, which is what 
the admin will expect.

> Port mirroring is not available for virtual NICs connected to external networks.

is this inherent, or until external providers add support for it/

> Block editing provider API address if there are networks imported from it.

why? what if i changed its dns name, but it is still the same service?

> Integration will be done at this phase for running virtual machine only, so other operations (hot-plug, rewire, etc) will not be supported for externally provided networks.

just wondering - how is hot plug different from run vm, now that we have 
pre device custom properties (since hooks are used)?

> Configuring keystone adds an additional dependency for the administrator to handle.

I think a global config should be fine for now, and in any case, this is 
needed for the glance integration as well

> Libvirt bug still not solved, Linux Bridge support requires quantum hack (or push as a fix for the agent)

bug number?

 > Future phases

I think IPAM, L3 and security groups are interesting to try and leverage 
quantum features

Thanks,
    Itamar



From iheim at redhat.com  Sat Apr 20 21:17:51 2013
From: iheim at redhat.com (Itamar Heim)
Date: Sun, 21 Apr 2013 00:17:51 +0300
Subject: [vdsm] Per device custom properties
In-Reply-To: <391020210.11407030.1363765434106.JavaMail.root@redhat.com>
References: <391020210.11407030.1363765434106.JavaMail.root@redhat.com>
Message-ID: <517305FF.9070004@redhat.com>

On 03/20/2013 09:43 AM, Yair Zaslavsky wrote:
>
>
> ----- Original Message -----
>> From: "Itzik Brown" <ItzikB at mellanox.com>
>> To: "Dan Kenigsberg" <danken at redhat.com>, "Assaf Muller" <amuller at redhat.com>, "Yair Zaslavsky"
>> <yzaslavs at redhat.com>, "Eldan Hildesheim" <ehildesh at redhat.com>, izikb at mellanox.com
>> Cc: vdsm-devel at lists.fedorahosted.org, arch at ovirt.org, "Irena Berezovsky" <irenab at mellanox.com>
>> Sent: Wednesday, March 20, 2013 9:17:08 AM
>> Subject: RE: [vdsm] Per device custom properties
>>
>> Hi,
>>
>> I think that this feature is a good start for enabling vendor
>> specific hints which apply to VM Network/Disk devices.
>> There is a need to add migration  hooks to the list.
>>
>> Itzik
>>
>> -----Original Message-----
>> From: Dan Kenigsberg [mailto:danken at redhat.com]
>> Sent: ??? ? 19 ??? 2013 17:12
>> To: Assaf Muller; Yair Zaslavsky; Eldan Hildesheim;
>> izikb at mellanox.com
>> Cc: vdsm-devel at lists.fedorahosted.org; arch at ovirt.org
>> Subject: Re: [vdsm] Per device custom properties
>>
>> adding arch at ovirt, as this feature is cross sub-project
>>
>> On Sun, Mar 17, 2013 at 09:50:20AM -0400, Assaf Muller wrote:
>>> Hi all,
>>>
>>> Right now we have the ability to define VM-wide properties that may
>>> be
>>> used by hooks.
>>> It is time we have the same functionality on a device basis:
>>> http://www.ovirt.org/Features/Device_Custom_Properties
>>
>> This feature page needs some love and attention.
>>
>> * I received a private communication about the suggested GUI: there
>>    should not be an independent vNIC action called "custom Properties"
>>    -
>>    the dialog for editing per-vNIC custom properties should be part of
>>    defining a new vNIC or editting an existing one. I believe Eldan
>>    (our
>>    GUI designer) concurs.
>>
>> * http://www.ovirt.org/Features/Device_Custom_Properties#Engine is
>>    rather lacking concrete details. Yair, could you improve it, as
>>    well
>>    as the completely empty REST section?
>
> I would prefer Michael Pasternak handles REST-API.
> Regarding the rest of the engine side- I'll assist.
> I would consult with Eli on this, as he was/is the feature owner of VM devices.
>
>>
>>>
>>> For example: If the VM has 2 disks called disk1 and disk2, and two
>>> NICs called nic1 and nic2, and the admin (From the engine) added a
>>> custom property qos: 0.5 for nic1 and a custom property defrag:
>>> None
>>> for disk2. When the VM is started we'll run a hook for nic1 with
>>> its
>>> XML and qos: 0.5 added as an environment variable, and a hook for
>>> disk2 with its XML and defrag: None.
>>>
>>> When a device is hot plugged and it has custom properties we'll run
>>> that hook as well.
>>>
>>> Implementation-wise, hot plug/unplug for disks and NICs is dead
>>> simple
>>> - vmCreate is more problematic:
>>> If the user set a custom property called 'qos: 0.8' for nic3, I'd
>>> want
>>> it exposed as an environment variable called 'qos' for hot plug nic
>>> hooks, but for vmCreate I'd like to prefix the nic's alias.
>>>   However,
>>> when vmCreate is called we don't have the aliases for NICs and
>>> disks.
>>>
>>> The proposed solution is to create a new hook point called
>>> something
>>> like: 'before_device_creation' that will be called before vmCreate.
>>> We'll then call that hook specifically for devices that contains
>>> custom properties, as described in the second paragraph of this
>>> mail.
>>>
>>>
>>> I would love to hear smarter ideas before I move forward. Thanks!
>>
>> I find it quite intuitive, but I'd rather hear if it feats Izik's use
>> case.
>>
>> Dan.
>>
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
>

one point for consideration is we may want to make custom properties 
"managed entities" in the future, rather than 'blobs'. this will 
especially be important to allow managing permissions on them.


From yzaslavs at redhat.com  Sun Apr 21 06:31:21 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Sun, 21 Apr 2013 02:31:21 -0400 (EDT)
Subject: [vdsm] Per device custom properties
In-Reply-To: <517305FF.9070004@redhat.com>
References: <391020210.11407030.1363765434106.JavaMail.root@redhat.com>
	<517305FF.9070004@redhat.com>
Message-ID: <390711462.59378.1366525881662.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Yair Zaslavsky" <yzaslavs at redhat.com>
> Cc: "Itzik Brown" <ItzikB at mellanox.com>, "Michael Pasternak" <mpastern at redhat.com>, "Eldan Hildesheim"
> <ehildesh at redhat.com>, vdsm-devel at lists.fedorahosted.org, "Eli Mesika" <emesika at redhat.com>, arch at ovirt.org,
> izikb at mellanox.com
> Sent: Sunday, April 21, 2013 12:17:51 AM
> Subject: Re: [vdsm] Per device custom properties
> 
> On 03/20/2013 09:43 AM, Yair Zaslavsky wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Itzik Brown" <ItzikB at mellanox.com>
> >> To: "Dan Kenigsberg" <danken at redhat.com>, "Assaf Muller"
> >> <amuller at redhat.com>, "Yair Zaslavsky"
> >> <yzaslavs at redhat.com>, "Eldan Hildesheim" <ehildesh at redhat.com>,
> >> izikb at mellanox.com
> >> Cc: vdsm-devel at lists.fedorahosted.org, arch at ovirt.org, "Irena Berezovsky"
> >> <irenab at mellanox.com>
> >> Sent: Wednesday, March 20, 2013 9:17:08 AM
> >> Subject: RE: [vdsm] Per device custom properties
> >>
> >> Hi,
> >>
> >> I think that this feature is a good start for enabling vendor
> >> specific hints which apply to VM Network/Disk devices.
> >> There is a need to add migration  hooks to the list.
> >>
> >> Itzik
> >>
> >> -----Original Message-----
> >> From: Dan Kenigsberg [mailto:danken at redhat.com]
> >> Sent: ??? ? 19 ??? 2013 17:12
> >> To: Assaf Muller; Yair Zaslavsky; Eldan Hildesheim;
> >> izikb at mellanox.com
> >> Cc: vdsm-devel at lists.fedorahosted.org; arch at ovirt.org
> >> Subject: Re: [vdsm] Per device custom properties
> >>
> >> adding arch at ovirt, as this feature is cross sub-project
> >>
> >> On Sun, Mar 17, 2013 at 09:50:20AM -0400, Assaf Muller wrote:
> >>> Hi all,
> >>>
> >>> Right now we have the ability to define VM-wide properties that may
> >>> be
> >>> used by hooks.
> >>> It is time we have the same functionality on a device basis:
> >>> http://www.ovirt.org/Features/Device_Custom_Properties
> >>
> >> This feature page needs some love and attention.
> >>
> >> * I received a private communication about the suggested GUI: there
> >>    should not be an independent vNIC action called "custom Properties"
> >>    -
> >>    the dialog for editing per-vNIC custom properties should be part of
> >>    defining a new vNIC or editting an existing one. I believe Eldan
> >>    (our
> >>    GUI designer) concurs.
> >>
> >> * http://www.ovirt.org/Features/Device_Custom_Properties#Engine is
> >>    rather lacking concrete details. Yair, could you improve it, as
> >>    well
> >>    as the completely empty REST section?
> >
> > I would prefer Michael Pasternak handles REST-API.
> > Regarding the rest of the engine side- I'll assist.
> > I would consult with Eli on this, as he was/is the feature owner of VM
> > devices.
> >
> >>
> >>>
> >>> For example: If the VM has 2 disks called disk1 and disk2, and two
> >>> NICs called nic1 and nic2, and the admin (From the engine) added a
> >>> custom property qos: 0.5 for nic1 and a custom property defrag:
> >>> None
> >>> for disk2. When the VM is started we'll run a hook for nic1 with
> >>> its
> >>> XML and qos: 0.5 added as an environment variable, and a hook for
> >>> disk2 with its XML and defrag: None.
> >>>
> >>> When a device is hot plugged and it has custom properties we'll run
> >>> that hook as well.
> >>>
> >>> Implementation-wise, hot plug/unplug for disks and NICs is dead
> >>> simple
> >>> - vmCreate is more problematic:
> >>> If the user set a custom property called 'qos: 0.8' for nic3, I'd
> >>> want
> >>> it exposed as an environment variable called 'qos' for hot plug nic
> >>> hooks, but for vmCreate I'd like to prefix the nic's alias.
> >>>   However,
> >>> when vmCreate is called we don't have the aliases for NICs and
> >>> disks.
> >>>
> >>> The proposed solution is to create a new hook point called
> >>> something
> >>> like: 'before_device_creation' that will be called before vmCreate.
> >>> We'll then call that hook specifically for devices that contains
> >>> custom properties, as described in the second paragraph of this
> >>> mail.
> >>>
> >>>
> >>> I would love to hear smarter ideas before I move forward. Thanks!
> >>
> >> I find it quite intuitive, but I'd rather hear if it feats Izik's use
> >> case.
> >>
> >> Dan.
> >>
> > _______________________________________________
> > vdsm-devel mailing list
> > vdsm-devel at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> >
> 
> one point for consideration is we may want to make custom properties
> "managed entities" in the future, rather than 'blobs'. this will
> especially be important to allow managing permissions on them.

+1 - I think we already discussed that in the past. I had a "deja vu" about it, when I went over
the current Wiki.


> 


From mkolesni at redhat.com  Sun Apr 21 08:13:28 2013
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Sun, 21 Apr 2013 04:13:28 -0400 (EDT)
Subject: OpenStack Quantum integration feature page for 3.3
In-Reply-To: <5172F4CF.60007@redhat.com>
References: <971394683.2095416.1363591245101.JavaMail.root@redhat.com>
	<5172F4CF.60007@redhat.com>
Message-ID: <587298342.63906.1366532008476.JavaMail.root@redhat.com>


----- Original Message -----
> On 03/18/2013 09:20 AM, Mike Kolesnik wrote:
> > Hi all,
> >
> > The feature page for integrating OpenStack Quantum into oVirt is
> > available on the wiki:
> > http://www.ovirt.org/Features/Quantum_Integration
> >
> > Please comment.
> >
> > Regards,
> > Mike
> >
> 
> A few questions/comments (inlining relevant parts of
> http://www.ovirt.org/Features/Detailed_Quantum_Integration)

Thanks for the comments and questions, I have answered in-line.

> 
> > Support for OVS plugin?
> 
> ovs vs. bridge - since we already have bridge support in oVirt, i think
> ovs support is a higher motivation for integrating with quantum.

Of course, we will strive to get it in in Phase 1 of the integration, since
it is very beneficial to oVirt.

> 
> mike - what's the plan for ovirt-node support for qunatum agents?

The plan for phase 1 is stated there: 
"No support for pre-built ovirt-node (or RHEV-H)."

> 
>  > Current implementation will be done by hooks.
> 
> iiuc, this is a temp solution, and you plan to make it a fully featured
> item later on as the integration matures?

Yes this is only as an initial step, as we don't want to define a concrete
contract yet with VDSM this seems like a reasonable approach.

> 
> > Each network can be provided either by oVirt or by the external provider.
> 
> did we look at our code to understand what it would mean to refactor the
> ovirt network code as an external provider as well (doesn't have to be
> out of process, just generalize/modularize our code and not have private
> cases) - there is work for doing something similar for the pluggable
> scheduler, first refactoring the existing scheduling code out as well.

Currently there hasn't been much work in that direction, however we need to
consider the fact that Quantum (and many other external providers) will be
providing us with VM network capability only, so perhaps only this part
can be done as a "provider".

However, we should take note that current oVirt implementation for VM
networks is more flexible than that of Quantum, so having it as "provider"
could limit that flexibility.

> 
> > If a network is externally provided, it will not be editable in oVirt,
> > since the external provider is responsible for managing the actual network
> > configuration.
> 
> unless we add support for editing it via the external provider (like we
> support adding an external network and importing it from the external
> provider)?

We could add such support, but it is not planned for Phase 1 currently..

> 
> > This effectively means that the user is responsible for quantum
> > availability on all the hosts in a given cluster the external network is
> > attached to.
> 
> we can consider an external provider to also have a health check api,
> then engine can alert on that service not being available, which is what
> the admin will expect.

As we are trying not to commit for VDSM API for Phase 1, I reckon this can
be done in a later phase.

> 
> > Port mirroring is not available for virtual NICs connected to external
> > networks.
> 
> is this inherent, or until external providers add support for it/

I don't know of such support being available in Quantum networks.
If it would be possible we will of course strive to add it.

> 
> > Block editing provider API address if there are networks imported from it.
> 
> why? what if i changed its dns name, but it is still the same service?

I will delete this.

> 
> > Integration will be done at this phase for running virtual machine only, so
> > other operations (hot-plug, rewire, etc) will not be supported for
> > externally provided networks.
> 
> just wondering - how is hot plug different from run vm, now that we have
> pre device custom properties (since hooks are used)?

I will update this.

> 
> > Configuring keystone adds an additional dependency for the administrator to
> > handle.
> 
> I think a global config should be fine for now, and in any case, this is
> needed for the glance integration as well

Yes I agree.

> 
> > Libvirt bug still not solved, Linux Bridge support requires quantum hack
> > (or push as a fix for the agent)
> 
> bug number?

https://bugzilla.redhat.com/893576
It is listed in the feature page as a dependency, but I will add a link here.

> 
>  > Future phases
> 
> I think IPAM, L3 and security groups are interesting to try and leverage
> quantum features

I will add a section with these directions.

> 
> Thanks,
>     Itamar
> 
> 


From iheim at redhat.com  Sun Apr 21 10:02:23 2013
From: iheim at redhat.com (Itamar Heim)
Date: Sun, 21 Apr 2013 13:02:23 +0300
Subject: OpenStack Quantum integration feature page for 3.3
In-Reply-To: <587298342.63906.1366532008476.JavaMail.root@redhat.com>
References: <971394683.2095416.1363591245101.JavaMail.root@redhat.com>
	<5172F4CF.60007@redhat.com>
	<587298342.63906.1366532008476.JavaMail.root@redhat.com>
Message-ID: <5173B92F.4000300@redhat.com>

On 04/21/2013 11:13 AM, Mike Kolesnik wrote:
>>> Each network can be provided either by oVirt or by the external provider.
>> >
>> >did we look at our code to understand what it would mean to refactor the
>> >ovirt network code as an external provider as well (doesn't have to be
>> >out of process, just generalize/modularize our code and not have private
>> >cases) - there is work for doing something similar for the pluggable
>> >scheduler, first refactoring the existing scheduling code out as well.
> Currently there hasn't been much work in that direction, however we need to
> consider the fact that Quantum (and many other external providers) will be
> providing us with VM network capability only, so perhaps only this part
> can be done as a "provider".
>
> However, we should take note that current oVirt implementation for VM
> networks is more flexible than that of Quantum, so having it as "provider"
> could limit that flexibility.
>

worth thinking about this a bit - mapping the gaps will probably lead to 
a better picture of how this should look like, expecting external 
providers to actually have more features than ovirt currently has.


From iheim at redhat.com  Sun Apr 21 11:03:48 2013
From: iheim at redhat.com (Itamar Heim)
Date: Sun, 21 Apr 2013 14:03:48 +0300
Subject: OpenStack Quantum integration feature page for 3.3
In-Reply-To: <587298342.63906.1366532008476.JavaMail.root@redhat.com>
References: <971394683.2095416.1363591245101.JavaMail.root@redhat.com>
	<5172F4CF.60007@redhat.com>
	<587298342.63906.1366532008476.JavaMail.root@redhat.com>
Message-ID: <5173C794.7030305@redhat.com>

On 04/21/2013 11:13 AM, Mike Kolesnik wrote:
>>> Libvirt bug still not solved, Linux Bridge support requires quantum hack
>>> > >(or push as a fix for the agent)
>> >
>> >bug number?
> https://bugzilla.redhat.com/893576
> It is listed in the feature page as a dependency, but I will add a link here.
>

this is a vdsm bug, not a libvirt one?


From mkolesni at redhat.com  Sun Apr 21 11:11:04 2013
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Sun, 21 Apr 2013 07:11:04 -0400 (EDT)
Subject: OpenStack Quantum integration feature page for 3.3
In-Reply-To: <5173C794.7030305@redhat.com>
References: <971394683.2095416.1363591245101.JavaMail.root@redhat.com>
	<5172F4CF.60007@redhat.com>
	<587298342.63906.1366532008476.JavaMail.root@redhat.com>
	<5173C794.7030305@redhat.com>
Message-ID: <223694425.74865.1366542664541.JavaMail.root@redhat.com>

----- Original Message -----
> On 04/21/2013 11:13 AM, Mike Kolesnik wrote:
> >>> Libvirt bug still not solved, Linux Bridge support requires quantum hack
> >>> > >(or push as a fix for the agent)
> >> >
> >> >bug number?
> > https://bugzilla.redhat.com/893576
> > It is listed in the feature page as a dependency, but I will add a link
> > here.
> >
> 
> this is a vdsm bug, not a libvirt one?
> 

Sorry wrong link copied, the correct one is https://bugzilla.redhat.com/878481


From mpastern at redhat.com  Sun Apr 21 11:48:30 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Sun, 21 Apr 2013 14:48:30 +0300
Subject: Backup Restore API integration feature page available.
In-Reply-To: <OF62C7A2AA.EDD5AA9F-ON87257B53.007B9A0A-88257B53.007C9B6F@us.ibm.com>
References: <OF84DFCFEE.9A2F85EB-ON87257B4F.006D4F6E-88257B4F.006F32EF@us.ibm.com>
	<516E765D.40108@redhat.com>
	<OF844A0D09.9FFC239D-ON87257B50.003FD488-88257B50.004031C8@LocalDomain>
	<OF62C7A2AA.EDD5AA9F-ON87257B53.007B9A0A-88257B53.007C9B6F@us.ibm.com>
Message-ID: <5173D20E.5060102@redhat.com>


Hi Sharad,

On 04/21/2013 01:42 AM, Sharad Mishra wrote:
> Hi Michael,
> 
> Not sure if you had a chance to look at the backup/restore feature wiki page. Let me give you some high level idea on what I am trying to do.

thanks for the "high level"

> 
> 1. When a user wants to backup a VM or disk, he/she issues a command to backup, which may look like 'backup(VM)' and 'backup(disk)'. Internally, this command is broken down
> to taking snapshot, preparing backup disk, making the disk available to backup server using qemu-nbd etc.
> 
> 2. There will be a similar call to restore VM or disk . 'restore(VM)' and 'restore(disk)'.
> 
> My question for you is, how do I go about implementing these rest apis? I need to create an RSDL, what else? Any good patches that show how to add a new call will help.

here how it goes

backup
======

in general we expose such capabilities in api via action, for instance
you can take a look on disk.activate() at [1],

in your case this should be divided to actions on two resources vm/disk., i.e

/api/vms/xxx/backup

/api/vms/xxx/disks/yyy/backup

/api/disks/xxx/backup


q1: the last one is a disk resources that may be not attached to any vm, or on opposite
to be attached in 1:N relation, active/not-active etc., how do you plan to expose 'backup'
here (feature-wise)?

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

restore
=======

q1: iiuc there will be > 1 backup to restore from (am i right?) if so, you should be
exposing sub-collection of backups to restore from, and we need to model this resource accordingly?

> 
> 
> Thanks
> Sharad Mishra
> Open Virtualization
> Linux Technology Center
> IBM
> 
> Inactive hide details for Sharad Mishra---04/17/2013 04:41:10 AM---Michael Pasternak <mpastern at redhat.com> wrote on 04/17/2013 Sharad Mishra---04/17/2013 04:41:10
> AM---Michael Pasternak <mpastern at redhat.com> wrote on 04/17/2013 03:15:57 AM: > From: Michael Pasternak <
> 
> From: Sharad Mishra/Beaverton/IBM
> To: Michael Pasternak <mpastern at redhat.com>,
> Cc: amureini at redhat.com
> Date: 04/17/2013 04:41 AM
> Subject: Re: Adding a new REST API call.
> 
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> 
> 
> Michael Pasternak <mpastern at redhat.com> wrote on 04/17/2013 03:15:57 AM:
> 
>> From: Michael Pasternak <mpastern at redhat.com>
>> To: Sharad Mishra/Beaverton/IBM at IBMUS,
>> Cc: amureini at redhat.com
>> Date: 04/17/13 03:14 AM
>> Subject: Re: Adding a new REST API call.
>>
>> On 04/16/2013 11:14 PM, Sharad Mishra wrote:
>> > Hi Michael,
>> >
>> > I am adding a new feature to support backup and restore using ISV
>> packages in ovirt. As part of that work, I will be adding few new
>> APIs. I am not very familiar with REST
>> > API, can you point me to an example REST API patch that adds a new API ?
>>
>> can you give me some background for this feature?
> 
> The feature page is http://www.ovirt.org/Features/Backup-Restore_API_Integration
> 
> Thanks
> Sharad
> 
>>
>> >
>> > Thanks
>> > Sharad Mishra
>> > Open Virtualization
>> > Linux Technology Center
>> > IBM
>> >
>>
>>
>> --
>>
>> Michael Pasternak
>> RedHat, ENG-Virtualization R&D
>>
> 


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From snmishra at linux.vnet.ibm.com  Mon Apr 22 16:16:58 2013
From: snmishra at linux.vnet.ibm.com (snmishra at linux.vnet.ibm.com)
Date: Mon, 22 Apr 2013 09:16:58 -0700
Subject: Backup Restore API integration feature page available.
In-Reply-To: <5173D20E.5060102@redhat.com>
References: <OF84DFCFEE.9A2F85EB-ON87257B4F.006D4F6E-88257B4F.006F32EF@us.ibm.com>
	<516E765D.40108@redhat.com>
	<OF844A0D09.9FFC239D-ON87257B50.003FD488-88257B50.004031C8@LocalDomain>
	<OF62C7A2AA.EDD5AA9F-ON87257B53.007B9A0A-88257B53.007C9B6F@us.ibm.com>
	<5173D20E.5060102@redhat.com>
Message-ID: <20130422091658.Horde.OtE1XZir309RdWJ6tlqRB_A@imap.linux.ibm.com>


Quoting Michael Pasternak <mpastern at redhat.com>:

> Hi Sharad,
>
> On 04/21/2013 01:42 AM, Sharad Mishra wrote:
>> Hi Michael,
>>
>> Not sure if you had a chance to look at the backup/restore feature  
>> wiki page. Let me give you some high level idea on what I am trying  
>> to do.
>
> thanks for the "high level"
>
>>
>> 1. When a user wants to backup a VM or disk, he/she issues a  
>> command to backup, which may look like 'backup(VM)' and  
>> 'backup(disk)'. Internally, this command is broken down
>> to taking snapshot, preparing backup disk, making the disk  
>> available to backup server using qemu-nbd etc.
>>
>> 2. There will be a similar call to restore VM or disk .  
>> 'restore(VM)' and 'restore(disk)'.
>>
>> My question for you is, how do I go about implementing these rest  
>> apis? I need to create an RSDL, what else? Any good patches that  
>> show how to add a new call will help.
>
> here how it goes
>
> backup
> ======
>
> in general we expose such capabilities in api via action, for instance
> you can take a look on disk.activate() at [1],
>
> in your case this should be divided to actions on two resources vm/disk., i.e
>
> /api/vms/xxx/backup
>
> /api/vms/xxx/disks/yyy/backup
>
> /api/disks/xxx/backup
>
>

Thanks for the explanation Michael.

> q1: the last one is a disk resources that may be not attached to any  
> vm, or on opposite
> to be attached in 1:N relation, active/not-active etc., how do you  
> plan to expose 'backup'
> here (feature-wise)?

I don't think there is anything special to be done to expose backups  
of above mentioned devices. An unattached/1-N/active/not-active should  
all be treated the same for backup purposes. The backup will display  
the disk ID, alias, VMs attached to (if any) etc. for the backedup disk.

>
> [1] http://gerrit.ovirt.org/#/c/3601/
>
> restore
> =======
>
> q1: iiuc there will be > 1 backup to restore from (am i right?) if  
> so, you should be
> exposing sub-collection of backups to restore from, and we need to  
> model this resource accordingly?

Is there any value in keeping multiple backups? I am leaning  towards  
just keeping the latest backup and once a newer backup is available  
for the VM/disk, replacing the older one.

Thanks
Sharad

>
>>
>>
>> Thanks
>> Sharad Mishra
>> Open Virtualization
>> Linux Technology Center
>> IBM
>>
>> Inactive hide details for Sharad Mishra---04/17/2013 04:41:10  
>> AM---Michael Pasternak <mpastern at redhat.com> wrote on 04/17/2013  
>> Sharad Mishra---04/17/2013 04:41:10
>> AM---Michael Pasternak <mpastern at redhat.com> wrote on 04/17/2013  
>> 03:15:57 AM: > From: Michael Pasternak <
>>
>> From: Sharad Mishra/Beaverton/IBM
>> To: Michael Pasternak <mpastern at redhat.com>,
>> Cc: amureini at redhat.com
>> Date: 04/17/2013 04:41 AM
>> Subject: Re: Adding a new REST API call.
>>
>> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>
>>
>> Michael Pasternak <mpastern at redhat.com> wrote on 04/17/2013 03:15:57 AM:
>>
>>> From: Michael Pasternak <mpastern at redhat.com>
>>> To: Sharad Mishra/Beaverton/IBM at IBMUS,
>>> Cc: amureini at redhat.com
>>> Date: 04/17/13 03:14 AM
>>> Subject: Re: Adding a new REST API call.
>>>
>>> On 04/16/2013 11:14 PM, Sharad Mishra wrote:
>>> > Hi Michael,
>>> >
>>> > I am adding a new feature to support backup and restore using ISV
>>> packages in ovirt. As part of that work, I will be adding few new
>>> APIs. I am not very familiar with REST
>>> > API, can you point me to an example REST API patch that adds a new API ?
>>>
>>> can you give me some background for this feature?
>>
>> The feature page is  
>> http://www.ovirt.org/Features/Backup-Restore_API_Integration
>>
>> Thanks
>> Sharad
>>
>>>
>>> >
>>> > Thanks
>>> > Sharad Mishra
>>> > Open Virtualization
>>> > Linux Technology Center
>>> > IBM
>>> >
>>>
>>>
>>> --
>>>
>>> Michael Pasternak
>>> RedHat, ENG-Virtualization R&D
>>>
>>
>
>
> --
>
> Michael Pasternak
> RedHat, ENG-Virtualization R&D
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch





From abaron at redhat.com  Mon Apr 22 20:33:20 2013
From: abaron at redhat.com (Ayal Baron)
Date: Mon, 22 Apr 2013 16:33:20 -0400 (EDT)
Subject: Backup Restore API integration feature page available.
In-Reply-To: <20130422091658.Horde.OtE1XZir309RdWJ6tlqRB_A@imap.linux.ibm.com>
References: <OF84DFCFEE.9A2F85EB-ON87257B4F.006D4F6E-88257B4F.006F32EF@us.ibm.com>
	<516E765D.40108@redhat.com>
	<OF844A0D09.9FFC239D-ON87257B50.003FD488-88257B50.004031C8@LocalDomain>
	<OF62C7A2AA.EDD5AA9F-ON87257B53.007B9A0A-88257B53.007C9B6F@us.ibm.com>
	<5173D20E.5060102@redhat.com>
	<20130422091658.Horde.OtE1XZir309RdWJ6tlqRB_A@imap.linux.ibm.com>
Message-ID: <1855048391.890524.1366662800735.JavaMail.root@redhat.com>



----- Original Message -----
> 
> Quoting Michael Pasternak <mpastern at redhat.com>:
> 
> > Hi Sharad,
> >
> > On 04/21/2013 01:42 AM, Sharad Mishra wrote:
> >> Hi Michael,
> >>
> >> Not sure if you had a chance to look at the backup/restore feature
> >> wiki page. Let me give you some high level idea on what I am trying
> >> to do.
> >
> > thanks for the "high level"
> >
> >>
> >> 1. When a user wants to backup a VM or disk, he/she issues a
> >> command to backup, which may look like 'backup(VM)' and
> >> 'backup(disk)'. Internally, this command is broken down
> >> to taking snapshot, preparing backup disk, making the disk
> >> available to backup server using qemu-nbd etc.
> >>
> >> 2. There will be a similar call to restore VM or disk .
> >> 'restore(VM)' and 'restore(disk)'.
> >>
> >> My question for you is, how do I go about implementing these rest
> >> apis? I need to create an RSDL, what else? Any good patches that
> >> show how to add a new call will help.
> >
> > here how it goes
> >
> > backup
> > ======
> >
> > in general we expose such capabilities in api via action, for instance
> > you can take a look on disk.activate() at [1],
> >
> > in your case this should be divided to actions on two resources vm/disk.,
> > i.e
> >
> > /api/vms/xxx/backup

verb name should not be 'backup' as we're not performing any backup operation, only making the disk available to an external app that can use it for whatever purpose it requires.

> >
> > /api/vms/xxx/disks/yyy/backup
> >
> > /api/disks/xxx/backup
> >
> >
> 
> Thanks for the explanation Michael.
> 
> > q1: the last one is a disk resources that may be not attached to any
> > vm, or on opposite
> > to be attached in 1:N relation, active/not-active etc., how do you
> > plan to expose 'backup'
> > here (feature-wise)?
> 
> I don't think there is anything special to be done to expose backups
> of above mentioned devices. An unattached/1-N/active/not-active should
> all be treated the same for backup purposes. The backup will display
> the disk ID, alias, VMs attached to (if any) etc. for the backedup disk.

Problem is that a disk attached to multiple machines (i.e. shareable disk) does not support snapshots today so you cannot backup it up while there is a running VM to which it is attached.  I'd just skip such disks in V1 (same as direct LUNs).

> 
> >
> > [1] http://gerrit.ovirt.org/#/c/3601/
> >
> > restore
> > =======
> >
> > q1: iiuc there will be > 1 backup to restore from (am i right?) if
> > so, you should be
> > exposing sub-collection of backups to restore from, and we need to
> > model this resource accordingly?
> 
> Is there any value in keeping multiple backups? I am leaning  towards
> just keeping the latest backup and once a newer backup is available
> for the VM/disk, replacing the older one.

Backup app will have many 'backups' or rather many points in time from which to restore but engine has no visibility to this.
The 'backup' is exposed via a direct lun so attaching it to a VM is simple.
The current gap with this is that we do not support snapshots of direct luns today so we need to find a way of running the VM from this volume while copying the data to a permanent location (rather than iSCSI exposed by the backup server).

> 
> Thanks
> Sharad
> 
> >
> >>
> >>
> >> Thanks
> >> Sharad Mishra
> >> Open Virtualization
> >> Linux Technology Center
> >> IBM
> >>
> >> Inactive hide details for Sharad Mishra---04/17/2013 04:41:10
> >> AM---Michael Pasternak <mpastern at redhat.com> wrote on 04/17/2013
> >> Sharad Mishra---04/17/2013 04:41:10
> >> AM---Michael Pasternak <mpastern at redhat.com> wrote on 04/17/2013
> >> 03:15:57 AM: > From: Michael Pasternak <
> >>
> >> From: Sharad Mishra/Beaverton/IBM
> >> To: Michael Pasternak <mpastern at redhat.com>,
> >> Cc: amureini at redhat.com
> >> Date: 04/17/2013 04:41 AM
> >> Subject: Re: Adding a new REST API call.
> >>
> >> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> >>
> >>
> >> Michael Pasternak <mpastern at redhat.com> wrote on 04/17/2013 03:15:57 AM:
> >>
> >>> From: Michael Pasternak <mpastern at redhat.com>
> >>> To: Sharad Mishra/Beaverton/IBM at IBMUS,
> >>> Cc: amureini at redhat.com
> >>> Date: 04/17/13 03:14 AM
> >>> Subject: Re: Adding a new REST API call.
> >>>
> >>> On 04/16/2013 11:14 PM, Sharad Mishra wrote:
> >>> > Hi Michael,
> >>> >
> >>> > I am adding a new feature to support backup and restore using ISV
> >>> packages in ovirt. As part of that work, I will be adding few new
> >>> APIs. I am not very familiar with REST
> >>> > API, can you point me to an example REST API patch that adds a new API
> >>> > ?
> >>>
> >>> can you give me some background for this feature?
> >>
> >> The feature page is
> >> http://www.ovirt.org/Features/Backup-Restore_API_Integration
> >>
> >> Thanks
> >> Sharad
> >>
> >>>
> >>> >
> >>> > Thanks
> >>> > Sharad Mishra
> >>> > Open Virtualization
> >>> > Linux Technology Center
> >>> > IBM
> >>> >
> >>>
> >>>
> >>> --
> >>>
> >>> Michael Pasternak
> >>> RedHat, ENG-Virtualization R&D
> >>>
> >>
> >
> >
> > --
> >
> > Michael Pasternak
> > RedHat, ENG-Virtualization R&D
> > _______________________________________________
> > Arch mailing list
> > Arch at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/arch
> 
> 
> 
> 


From mpastern at redhat.com  Tue Apr 23 07:23:52 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Tue, 23 Apr 2013 10:23:52 +0300
Subject: Backup Restore API integration feature page available.
In-Reply-To: <20130422091658.Horde.OtE1XZir309RdWJ6tlqRB_A@imap.linux.ibm.com>
References: <OF84DFCFEE.9A2F85EB-ON87257B4F.006D4F6E-88257B4F.006F32EF@us.ibm.com>
	<516E765D.40108@redhat.com>
	<OF844A0D09.9FFC239D-ON87257B50.003FD488-88257B50.004031C8@LocalDomain>
	<OF62C7A2AA.EDD5AA9F-ON87257B53.007B9A0A-88257B53.007C9B6F@us.ibm.com>
	<5173D20E.5060102@redhat.com>
	<20130422091658.Horde.OtE1XZir309RdWJ6tlqRB_A@imap.linux.ibm.com>
Message-ID: <51763708.4000302@redhat.com>


Hi Sharad,

On 04/22/2013 07:16 PM, snmishra at linux.vnet.ibm.com wrote:
> 
> Quoting Michael Pasternak <mpastern at redhat.com>:
> 
>> Hi Sharad,
>>
>> On 04/21/2013 01:42 AM, Sharad Mishra wrote:
>>> Hi Michael,
>>>
>>> Not sure if you had a chance to look at the backup/restore feature wiki page. Let me give you some high level idea on what I am trying to do.
>>
>> thanks for the "high level"
>>
>>>
>>> 1. When a user wants to backup a VM or disk, he/she issues a command to backup, which may look like 'backup(VM)' and 'backup(disk)'. Internally, this command is broken down
>>> to taking snapshot, preparing backup disk, making the disk available to backup server using qemu-nbd etc.
>>>
>>> 2. There will be a similar call to restore VM or disk . 'restore(VM)' and 'restore(disk)'.
>>>
>>> My question for you is, how do I go about implementing these rest apis? I need to create an RSDL, what else? Any good patches that show how to add a new call will help.
>>
>> here how it goes
>>
>> backup
>> ======
>>
>> in general we expose such capabilities in api via action, for instance
>> you can take a look on disk.activate() at [1],
>>
>> in your case this should be divided to actions on two resources vm/disk., i.e
>>
>> /api/vms/xxx/backup
>>
>> /api/vms/xxx/disks/yyy/backup
>>
>> /api/disks/xxx/backup
>>
>>
> 
> Thanks for the explanation Michael.
> 
>> q1: the last one is a disk resources that may be not attached to any vm, or on opposite
>> to be attached in 1:N relation, active/not-active etc., how do you plan to expose 'backup'
>> here (feature-wise)?
> 
> I don't think there is anything special to be done to expose backups of above mentioned devices. An unattached/1-N/active/not-active should all be treated the same for
> backup purposes. The backup will display the disk ID, alias, VMs attached to (if any) etc. for the backedup disk.
> 
>>
>> [1] http://gerrit.ovirt.org/#/c/3601/
>>
>> restore
>> =======
>>
>> q1: iiuc there will be > 1 backup to restore from (am i right?) if so, you should be
>> exposing sub-collection of backups to restore from, and we need to model this resource accordingly?
> 
> Is there any value in keeping multiple backups? I am leaning  towards just keeping the latest backup and once a newer backup is available for the VM/disk, replacing the
> older one.

the thing is that if we decide that we should allow multiple backups, api
modelling should be different, e.g

list
====

GET /api/vms/xxx/disks/yyy/backups
GET /api/vms/xxx/backups

fetch
====

GET /api/vms/xxx/disks/yyy/backups/zzz
GET /api/vms/xxx/backups/zzz

create
======

POST /api/vms/xxx/disks/yyy/backups
<backup/>

POST /api/vms/xxx/backups
<backup/>

restore
=======

POST /api/vms/xxx/disks/yyy/backups/zzz/restore
<action/>

POST /api/vms/xxx/backups/zzz/restore
<action/>

while if we have only single instance of the backup, modelling
should look like:

list
====

not available as only single backup exist

fetch
=====

not available as only single backup exist

create
======

POST /api/vms/xxx/disks/yyy/backup
<action/>

POST /api/disks/xxx/backup
<action/>

restore
=======

POST /api/vms/xxx/disks/yyy/restore
<action/>

POST /api/disks/xxx/restore
<action/>

as you can see the design is quite different, so no is
the time for supporting (or not) multiple restore points
decision.

> 
> Thanks
> Sharad
> 
>>
>>>
>>>
>>> Thanks
>>> Sharad Mishra
>>> Open Virtualization
>>> Linux Technology Center
>>> IBM
>>>
>>> Inactive hide details for Sharad Mishra---04/17/2013 04:41:10 AM---Michael Pasternak <mpastern at redhat.com> wrote on 04/17/2013 Sharad Mishra---04/17/2013 04:41:10
>>> AM---Michael Pasternak <mpastern at redhat.com> wrote on 04/17/2013 03:15:57 AM: > From: Michael Pasternak <
>>>
>>> From: Sharad Mishra/Beaverton/IBM
>>> To: Michael Pasternak <mpastern at redhat.com>,
>>> Cc: amureini at redhat.com
>>> Date: 04/17/2013 04:41 AM
>>> Subject: Re: Adding a new REST API call.
>>>
>>> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>>
>>>
>>> Michael Pasternak <mpastern at redhat.com> wrote on 04/17/2013 03:15:57 AM:
>>>
>>>> From: Michael Pasternak <mpastern at redhat.com>
>>>> To: Sharad Mishra/Beaverton/IBM at IBMUS,
>>>> Cc: amureini at redhat.com
>>>> Date: 04/17/13 03:14 AM
>>>> Subject: Re: Adding a new REST API call.
>>>>
>>>> On 04/16/2013 11:14 PM, Sharad Mishra wrote:
>>>> > Hi Michael,
>>>> >
>>>> > I am adding a new feature to support backup and restore using ISV
>>>> packages in ovirt. As part of that work, I will be adding few new
>>>> APIs. I am not very familiar with REST
>>>> > API, can you point me to an example REST API patch that adds a new API ?
>>>>
>>>> can you give me some background for this feature?
>>>
>>> The feature page is http://www.ovirt.org/Features/Backup-Restore_API_Integration
>>>
>>> Thanks
>>> Sharad
>>>
>>>>
>>>> >
>>>> > Thanks
>>>> > Sharad Mishra
>>>> > Open Virtualization
>>>> > Linux Technology Center
>>>> > IBM
>>>> >
>>>>
>>>>
>>>> -- 
>>>>
>>>> Michael Pasternak
>>>> RedHat, ENG-Virtualization R&D
>>>>
>>>
>>
>>
>> -- 
>>
>> Michael Pasternak
>> RedHat, ENG-Virtualization R&D
>> _______________________________________________
>> Arch mailing list
>> Arch at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/arch
> 
> 
> 


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From mpastern at redhat.com  Tue Apr 23 07:24:56 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Tue, 23 Apr 2013 10:24:56 +0300
Subject: Backup Restore API integration feature page available.
In-Reply-To: <1855048391.890524.1366662800735.JavaMail.root@redhat.com>
References: <OF84DFCFEE.9A2F85EB-ON87257B4F.006D4F6E-88257B4F.006F32EF@us.ibm.com>
	<516E765D.40108@redhat.com>
	<OF844A0D09.9FFC239D-ON87257B50.003FD488-88257B50.004031C8@LocalDomain>
	<OF62C7A2AA.EDD5AA9F-ON87257B53.007B9A0A-88257B53.007C9B6F@us.ibm.com>
	<5173D20E.5060102@redhat.com>
	<20130422091658.Horde.OtE1XZir309RdWJ6tlqRB_A@imap.linux.ibm.com>
	<1855048391.890524.1366662800735.JavaMail.root@redhat.com>
Message-ID: <51763748.2060804@redhat.com>

On 04/22/2013 11:33 PM, Ayal Baron wrote:
> 
> 
> ----- Original Message -----
>>
>> Quoting Michael Pasternak <mpastern at redhat.com>:
>>
>>> Hi Sharad,
>>>
>>> On 04/21/2013 01:42 AM, Sharad Mishra wrote:
>>>> Hi Michael,
>>>>
>>>> Not sure if you had a chance to look at the backup/restore feature
>>>> wiki page. Let me give you some high level idea on what I am trying
>>>> to do.
>>>
>>> thanks for the "high level"
>>>
>>>>
>>>> 1. When a user wants to backup a VM or disk, he/she issues a
>>>> command to backup, which may look like 'backup(VM)' and
>>>> 'backup(disk)'. Internally, this command is broken down
>>>> to taking snapshot, preparing backup disk, making the disk
>>>> available to backup server using qemu-nbd etc.
>>>>
>>>> 2. There will be a similar call to restore VM or disk .
>>>> 'restore(VM)' and 'restore(disk)'.
>>>>
>>>> My question for you is, how do I go about implementing these rest
>>>> apis? I need to create an RSDL, what else? Any good patches that
>>>> show how to add a new call will help.
>>>
>>> here how it goes
>>>
>>> backup
>>> ======
>>>
>>> in general we expose such capabilities in api via action, for instance
>>> you can take a look on disk.activate() at [1],
>>>
>>> in your case this should be divided to actions on two resources vm/disk.,
>>> i.e
>>>
>>> /api/vms/xxx/backup
> 
> verb name should not be 'backup' as we're not performing any backup operation, only making the disk available to an external app that can use it for whatever purpose it requires.
> 
>>>
>>> /api/vms/xxx/disks/yyy/backup
>>>
>>> /api/disks/xxx/backup
>>>
>>>
>>
>> Thanks for the explanation Michael.
>>
>>> q1: the last one is a disk resources that may be not attached to any
>>> vm, or on opposite
>>> to be attached in 1:N relation, active/not-active etc., how do you
>>> plan to expose 'backup'
>>> here (feature-wise)?
>>
>> I don't think there is anything special to be done to expose backups
>> of above mentioned devices. An unattached/1-N/active/not-active should
>> all be treated the same for backup purposes. The backup will display
>> the disk ID, alias, VMs attached to (if any) etc. for the backedup disk.
> 
> Problem is that a disk attached to multiple machines (i.e. shareable disk) does not support snapshots today so you cannot backup it up while there is a running VM to which it is attached.  I'd just skip such disks in V1 (same as direct LUNs).

exactly, that's was my point, so let's summarize that in v1, we will have only backup
for the vm or vm-disk.

> 
>>
>>>
>>> [1] http://gerrit.ovirt.org/#/c/3601/
>>>
>>> restore
>>> =======
>>>
>>> q1: iiuc there will be > 1 backup to restore from (am i right?) if
>>> so, you should be
>>> exposing sub-collection of backups to restore from, and we need to
>>> model this resource accordingly?
>>
>> Is there any value in keeping multiple backups? I am leaning  towards
>> just keeping the latest backup and once a newer backup is available
>> for the VM/disk, replacing the older one.
> 
> Backup app will have many 'backups' or rather many points in time from which to restore but engine has no visibility to this.
> The 'backup' is exposed via a direct lun so attaching it to a VM is simple.
> The current gap with this is that we do not support snapshots of direct luns today so we need to find a way of running the VM from this volume while copying the data to a permanent location (rather than iSCSI exposed by the backup server).
> 
>>
>> Thanks
>> Sharad
>>
>>>
>>>>
>>>>
>>>> Thanks
>>>> Sharad Mishra
>>>> Open Virtualization
>>>> Linux Technology Center
>>>> IBM
>>>>
>>>> Inactive hide details for Sharad Mishra---04/17/2013 04:41:10
>>>> AM---Michael Pasternak <mpastern at redhat.com> wrote on 04/17/2013
>>>> Sharad Mishra---04/17/2013 04:41:10
>>>> AM---Michael Pasternak <mpastern at redhat.com> wrote on 04/17/2013
>>>> 03:15:57 AM: > From: Michael Pasternak <
>>>>
>>>> From: Sharad Mishra/Beaverton/IBM
>>>> To: Michael Pasternak <mpastern at redhat.com>,
>>>> Cc: amureini at redhat.com
>>>> Date: 04/17/2013 04:41 AM
>>>> Subject: Re: Adding a new REST API call.
>>>>
>>>> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>>>
>>>>
>>>> Michael Pasternak <mpastern at redhat.com> wrote on 04/17/2013 03:15:57 AM:
>>>>
>>>>> From: Michael Pasternak <mpastern at redhat.com>
>>>>> To: Sharad Mishra/Beaverton/IBM at IBMUS,
>>>>> Cc: amureini at redhat.com
>>>>> Date: 04/17/13 03:14 AM
>>>>> Subject: Re: Adding a new REST API call.
>>>>>
>>>>> On 04/16/2013 11:14 PM, Sharad Mishra wrote:
>>>>>> Hi Michael,
>>>>>>
>>>>>> I am adding a new feature to support backup and restore using ISV
>>>>> packages in ovirt. As part of that work, I will be adding few new
>>>>> APIs. I am not very familiar with REST
>>>>>> API, can you point me to an example REST API patch that adds a new API
>>>>>> ?
>>>>>
>>>>> can you give me some background for this feature?
>>>>
>>>> The feature page is
>>>> http://www.ovirt.org/Features/Backup-Restore_API_Integration
>>>>
>>>> Thanks
>>>> Sharad
>>>>
>>>>>
>>>>>>
>>>>>> Thanks
>>>>>> Sharad Mishra
>>>>>> Open Virtualization
>>>>>> Linux Technology Center
>>>>>> IBM
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Michael Pasternak
>>>>> RedHat, ENG-Virtualization R&D
>>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> Michael Pasternak
>>> RedHat, ENG-Virtualization R&D
>>> _______________________________________________
>>> Arch mailing list
>>> Arch at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/arch
>>
>>
>>
>>


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From kwade at redhat.com  Wed Apr 24 10:28:39 2013
From: kwade at redhat.com (Karsten 'quaid' Wade)
Date: Wed, 24 Apr 2013 03:28:39 -0700
Subject: Unplanned Outage :: Mailman and resources :: 2013-04-24 09:00 UTC
Message-ID: <5177B3D7.3060803@redhat.com>

There was an unplanned outage of lists.ovirt.org/resources.ovirt.org for
30 minutes.

== Details ==

We began receiving disk full alerts from Postfix on linode01.ovirt.org,
that houses lists.ovirt.org and resources.ovirt.org.

I looked around the server to find more disk space, but there was
nothing obvious that I could drop. Regardless, it's clear from existing
needs that more disk space was needed.

I shutdown the server, added 12 GB more to the drive image, and
restarted the host.

== Affected services ==

* Mailman (lists.ovirt.org)
* Package repo (resources.ovirt.org)
* ovirtbot

=== Not-affected services ==

* www.ovirt.org
* wiki.ovirt.org
* jenkins.ovirt.org
* gerrit.ovirt.org

== Future plans ==

Migrate the entire host to a set of VMs running in one of the new
hosting environments. ASAP.
-- 
Karsten 'quaid' Wade, Sr. Analyst - Community Growth
http://TheOpenSourceWay.org  .^\  http://community.redhat.com
@quaid (identi.ca/twitter/IRC)  \v'  gpg: AD0E0C41

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

From emesika at redhat.com  Sun Apr 28 10:01:53 2013
From: emesika at redhat.com (Eli Mesika)
Date: Sun, 28 Apr 2013 06:01:53 -0400 (EDT)
Subject: Adding External Tasks Support - feature page
In-Reply-To: <1314269971.3404090.1367143268934.JavaMail.root@redhat.com>
Message-ID: <1890253966.3404113.1367143313329.JavaMail.root@redhat.com>


Enable plug-in to inject tasks to the engine application using the REST API, change their statuses and track them from the UI.
A task may have other nesting sub-tasks under it. 

More on that :
http://wiki.ovirt.org/Features/ExternalTasks

Regards

Eli Mesika