[oVirt][Quantum] question about quantum CLI
Kris zhang
zhang.kris at gmail.com
Tue Jun 19 03:02:07 UTC 2012
Hi Kotton,
Thanks for these days help, currently i haven't any other questions.
Thanks again,
Kris
On Mon, Jun 18, 2012 at 1:52 PM, Gary Kotton <gkotton at redhat.com> wrote:
> **
> Hi,
> Please see inline.
> Thanks
> Gary
>
>
> On 06/18/2012 04:11 AM, Kris zhang wrote:
>
> Hi Kotton,
>
> Thanks for your detailed answer, and it's very clear, and i still have
> some other questions:
>
> 1) Where i can find the database changes? please correct me if no change
> in db.
>
>
> At the moment in oVirt there are no database changes. The code that you
> are looking at is a POC. We (the community) still need to address the
> database changes.I think that prior to adding the database changes we
> should first add a REST client that can communicate with the Quantum
> service (at the moment this is done via the Quantum CLI). I have a short
> list of items that need to be addressed for a a basic Quantum integration
> (this will at least give us the infrastructure to build on in the future).
> I think that for the first phase we should support the following:
>
> - oVirt Engine will support one Quantum service (the instance
> currently supports only 1 plugin)
> - oVirt installation will have Quantum service as a dependency
> - All hosts in a cluster must have the same networking support. This
> can be one of the following:
> - Legacy oVirt networking
> - Legacy oVirt networking for management and Quantum for VM
> networking
> - When a VDSM host is registered (IP, password etc), one of the above
> methods will registered. If this Quantum, then the relevant configuration
> data will be sent to VDSM. Agent packages will exist on VDSM
> - If a logical network is assigned to a Quantum cluster then this
> network must be registered with Quantum (to get the UUID)
> - All VM's running on this cluster will receive a port ID and pass an
> attachment ID to the Quantum
> - Limitations:
> - No network statistics for logical quantum networks
>
> I think that small secluded changes can help the integration - for
> example:-
> - implement a REST client (used to communicate with Quantum service)
> - update database to store relevant quantum ID's
> - improve VDMS support for Quantum code (have a plugin architecture -
> so that different technologies can plug their code into VDSM)
> - address HOST management
> - packaging
>
>
>
> 2) If the engine server crashed, then how to rebuild the network
> information which generated by ovirt.sh script in the /tmp dir?
>
>
> Please note that this is a POC. All of the data generated by the script is
> persistent - that is, it is stored in the /tmp directory. I am not really
> sure that I understand your question. If oVirt engine crashes then the user
> will not be able to deploy VM's. If the Quantum service crashes then the
> user should not be able to configure Quantum networks or attach ports etc.
> If the quantum service crashes or is unreachable by VDSM then a newly
> deployed VM may not be able to "attach" to the Quantum network. This can be
> averted by having the following - on oVirt engine there should be a process
> that monitors the status of the Quantum service. If this is down then it
> should restart it. This can and should be discussed in more detail.
>
>
> In addition, originally i think the quantum port create is no any
> relationship with vm create, and only be linked when a VIF of a VM attach
> into a port. But your design is different, so there is no port creation in
> the web UI, right?
>
>
> My thinking is that when a VNIC of a VM is linked to a Quantum network
> then the Quantum port should be created. After some discussion I understand
> that the oVirt VNIC has a UUID - this can now be used as the attachment ID.
> In my opinion the Quantum interface should be limited to the host
> management. The rest should be "hidden" from the user.
>
>
> Best regards,
> Kris
>
>
>
> On Fri, Jun 15, 2012 at 2:11 PM, Gary Kotton <gkotton at redhat.com> wrote:
>
>> Hi Kris,
>> You have asked a very interesting and good question. Please see the
>> answers an explanations below. Both flow are used. The "a" flows (1a2a and
>> 3a) are for the network management. The "b" flows (1b and 2b) are for the
>> VM management.
>> Network management (1a):
>> - user create a Quantum network
>> - user will create a Quantum port and attachment
>> VM Management (1b):
>> - users creates a VM
>> - assigned VM to one or more logical networks. Each each assignment
>> will receive the above quantum details
>> VM flow:
>> - VDSM creates the libvirt XML file
>> - (2b) if libvirt version is 0.9.10 or earlier then VDSM will
>> have to create the tap device (via attachment ID) and will set it with type
>> 'ethernet' in the libvirt file (this is what was done in the POC). In
>> addition this it need to notify OVS of the VM ID on the port
>> - in later versions of libvirt, libvirt will do the create via
>> the attachment id
>> - VDSM will start the VM
>> Network flow (2a and 3a):
>> - The Quantum agent polls the Quantum plugin for network changes. If
>> the agent detects a tap device that is part of a network then it will
>> configure the characteristics of this tap device on the OVS. In the case of
>> the POC it will be the VLAN tag of the network
>> Hope that I have answered your questions.
>> Thanks
>> Gary
>>
>>
>> On 06/14/2012 10:49 AM, Kris zhang wrote:
>>
>> Hi Kotton,
>>
>> Thank your very much, and i still have a question:
>>
>> There is a quantum.py file in the gkotton-vdsm_quantum-78427ca.zip. I
>> saw there are some methods (For example: vifAddOpenVswitch() ) to call
>> ovs-vsctl command, that means vdsm will control the ovs, not through ovs
>> quantum agent?
>>
>> The ovs quantum agent code is in the
>> http://bazaar.launchpad.net/~netstack-core/quantum/essex/view/head:/quantum/plugins/openvswitch/agent/ovs_quantum_agent.py
>>
>>
>> [image: Inline image 1]
>>
>> Please see above the image, and there are two ways:
>>
>> First way: 1a, 2a, 3a.
>> Second way: 1b, 2b
>>
>> which way is used in POC?
>>
>> Best regards,
>> Kris
>>
>>
>>
>> On Wed, Jun 13, 2012 at 5:48 PM, Gary Kotton <gkotton at redhat.com> wrote:
>>
>>> On 06/13/2012 11:57 AM, Kris zhang wrote:
>>>
>>> Thanks for you detail answer, and please see the result of the command
>>> quantum update_port,
>>>
>>> The command "quantum update_port" sets the state of the port. In the
>>> case of the ovirt.sh script this sets the port in ACTIVE state.
>>> The "user" is responsible for providing the attachment ID. In the case
>>> of the ovirt.sh script the ID is generated via uuidgen.
>>> Once you have generated a UUID for the attachment you need to pass this
>>> to quantum via the "quantum plug_iface".
>>>
>>>
>>> [image: Inline image 1]
>>>
>>> I run this script from the shell, and you can see there is no an
>>> attachment UUID created. Can you show me your testing result?
>>>
>>>
>>> Please see below:
>>>
>>> openstack at openstack:/tmp$ ./ovirt.sh network create Q_net
>>> openstack at openstack:/tmp$ ./ovirt.sh port create Q_net 12345678
>>> Updated Logical Port with ID: f9f203ab-dab6-4b9c-8dcf-561bcc698c76
>>> on Virtual Network: 8c50db01-54ef-4688-a274-9ab3fcfafe7d
>>> for tenant: default
>>> Plugged interface 24bf26c4-f8eb-46cd-a168-b7a25e64d5b2
>>> into Logical Port: f9f203ab-dab6-4b9c-8dcf-561bcc698c76
>>> on Virtual Network: 8c50db01-54ef-4688-a274-9ab3fcfafe7d
>>> for Tenant: default
>>> openstack at openstack:/tmp$
>>>
>>>
>>> openstack at openstack:/tmp$ ll
>>> total 40
>>> drwxrwxrwt 4 root root 4096 2012-06-13 05:39 ./
>>> drwxr-xr-x 23 root root 4096 2012-05-26 06:39 ../
>>> -rw-rw-r-- 1 openstack openstack 6 2012-06-13 05:38 network.12345678
>>> -rw-rw-r-- 1 openstack openstack 37 2012-06-13 05:38 network.Q_net
>>> -rw-rw-r-- 1 openstack openstack 37 2012-06-13 05:38
>>> network.Q_net.12345678.port
>>> -rw-rw-r-- 1 openstack openstack 37 2012-06-13 05:38
>>> network.Q_net.12345678.port.attach
>>> -rwxrwxrwx 1 openstack openstack 2097 2012-06-13 05:07 ovirt.sh*
>>> -rw-rw-r-- 1 openstack openstack 1797 2012-06-13 05:38 ovirt.txt
>>>
>>> openstack at openstack:/tmp$ cat network.Q_net.12345678.port.attach
>>> 24bf26c4-f8eb-46cd-a168-b7a25e64d5b2
>>> openstack at openstack:/tmp$
>>>
>>> Thanks
>>> Gary
>>>
>>>
>>> BR,
>>> Kris
>>>
>>>
>>> On Wed, Jun 13, 2012 at 2:02 PM, Gary Kotton <gkotton at redhat.com> wrote:
>>>
>>>> Hi Kris,
>>>> Please see my answers and questions below.
>>>> Thanks
>>>> Gary
>>>>
>>>>
>>>> On 06/13/2012 07:31 AM, Kris zhang wrote:
>>>>
>>>> Hi Kotton,
>>>>
>>>> In the file ovirt.sh, there is a line:
>>>>
>>>>
>>>> A bit of background regarding the script. The purpose of the POC was
>>>> to show that Quantum can be run in oVirt. It would have been ideal to write
>>>> a REST client that could interface with the Quantum service. Due to the
>>>> fact that I was not familiar with the oVirt code I felt that a quicker and
>>>> more productive means was to invoke a bash script from the oVirt engine
>>>> code. The script would invoke the quantum cli (this is a client that
>>>> configures the quantum server). In addition to this I did not want to make
>>>> any changes to the database schema. The result was a script that does the
>>>> following:
>>>> 1. Logical Network Management:
>>>> Create:
>>>> ovirt.sh network create <name>
>>>> - the name is the name of the logical network (in the POC
>>>> this is prefixed by "Q_"
>>>> - this invokes the cli to create a network called <name>
>>>> - the UUID returned by the quantum service will be save in
>>>> /tmp/network.<name>
>>>> - the above UUID is read when this logical network is used
>>>> (this in the future will be save in the oVirt data base)
>>>> Delete:
>>>> ovirt.sh network remove <name>
>>>> - the name is the name of the logical network (in the POC
>>>> this is prefixed by "Q_"
>>>> - this invokes the cli to delete a network called <name>
>>>> - the file /tmp/network.<name> is deleted
>>>> 2. VM Port management
>>>> Create:
>>>> ovirt.sh port create <net_name> <vmid>
>>>> - the network name and the vm id are input (the VM id is a
>>>> key to be able to delete it all :))
>>>> - the script does the following:
>>>> - creates a port on the network. saves the port id in
>>>> /tmp/network.<name>.<vmid>.port
>>>> - sets the state of the port to ACTIVE
>>>> - creates an attachment ID (this is the line that you
>>>> had problems with). This is saved in /tmp/network.<name>.<vmid>.attachment
>>>> - saves the network name in a file /tmp/network.<vmid>
>>>> - the UUID's are read when the VM is started so that
>>>> they can be passed to VDSM
>>>> Delete:
>>>> ovirt.sh port remove <vmid>
>>>> - using the vmid the network name is read => enables us to
>>>> get all of the ID's to delete port in quantum
>>>> - cleans all of the files
>>>> The script is called from the ovirt engine. Sorry for the long winded
>>>> explanation.
>>>>
>>>>
>>>> quantum update_port default $NET_UUID $PORT_UUID state=ACTIVE
>>>> uuidgen > /tmp/network.$3.$4.port.attach
>>>>
>>>> ATTACH_UUID=`cat /tmp/network.$3.$4.port.attach`
>>>>
>>>>
>>>> In Quantum the attachment ID is generated by the user. The code above
>>>> generates the attachment ID for the port.
>>>>
>>>>
>>>>
>>>> But i run this command, i found there is no any uuid generated, so
>>>> what's the value of the ATTACH_UUID?
>>>>
>>>> Do you run the script from the shell or is this run via oVirt?
>>>> There is a log of all of the script command - can you please look in
>>>> /tmp/ovirt.txt - this may give us some clues.
>>>> You can run the script commands as described above. This may also help.
>>>> Thanks
>>>> Gary
>>>>
>>>> Best regards,
>>>> Kris
>>>>
>>>>
>>>> On Tue, Jun 12, 2012 at 7:15 PM, Gary Kotton <gkotton at redhat.com>wrote:
>>>>
>>>>> On 06/12/2012 12:36 PM, Itamar Heim wrote:
>>>>>
>>>>>> On 06/12/2012 11:47 AM, Gary Kotton wrote:
>>>>>>
>>>>>>> Hi Kris,
>>>>>>> Thanks for the questions. Please see my inline answers. I have also
>>>>>>> cc'ed the ovirt arch mailing list.
>>>>>>> Thanks
>>>>>>> Gary
>>>>>>>
>>>>>>> On 06/12/2012 11:21 AM, Kris zhang wrote:
>>>>>>>
>>>>>>>> Hi Gkotton,
>>>>>>>>
>>>>>>>> I have some questions:
>>>>>>>>
>>>>>>>> 1) In the file "ovirt.sh", i found the command quantum always use
>>>>>>>> the
>>>>>>>> tenant "default", so if the ovirt don't support multi-tenant?
>>>>>>>>
>>>>>>> oVirt does not support multi tenancy at the moment. Maybe there are
>>>>>>> people on the list who can provide more details about this. The
>>>>>>> initial
>>>>>>> plan was to use the "default" tenant.
>>>>>>>
>>>>>>
>>>>>> ovirt supports multiple users and an RBAC model for permissions
>>>>>> between these users.
>>>>>> what exactly are you looking for?
>>>>>>
>>>>> Quantum support multi tenancy. The integration with oVirt was done
>>>>> with the "default" tenant. This is a different model to that of oVirt.
>>>>> Thanks
>>>>> Gary
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20120619/3219e7f9/attachment.html>
More information about the Arch
mailing list