integrating with quantum - proposal

[Livnat Peer]

On 30/11/12 08:18, Itamar Heim wrote:
> On 11/26/2012 09:06 AM, Livnat Peer wrote:
>> Hi Guys,
>> I'm about to send the proposal I worked on with Kolesnik to the list.
>>
>> Any political/other objections?
>>
>> http://wiki.ovirt.org/wiki/Quantum_IPAM_Integration
>>
>> We are starting to work on a POC to find the issues we missed in our
>> research so far, sending this to the list can get the discussion going.
>>
>> Livnat
>>
> 
> seems like an interesting solution, moving the problem of central dhcp
> to a distributed dhcp approach.
> 

Itamar,
Thanks for your input, specific replies in-context.

> so iiuc:
> - a per network config to specify if to enable IPAM on the logical
>   network.

yes (assuming that by config you mean property).

> - ability to specify the ip address ranges per logical network?

yes,
We did not look into the specific details yes but generally we expect to
model many of the properties that can be configured via DHCP server and
are mapped in the Quantum's Subnet entity (dns_nameservers, gateway_ip
etc.).
http://wiki.openstack.org/Quantum/APIv2-specification#Subnet

> - would we be able to set a policy at VM (or vnic) level to specify if
>   the vnic is getting the IP from the IPAM, or not?

If there is a use case for that, then why not.
In addition we will add support to specify static IP per vNIC by the
user (when IPAM is enabled on the network).

> - do we expect another mode of IP allocation (via the payload)?

AFAIU configuring IP via the payload is like defining a static IP not
via the engine (from IPAM POV). The engine will find about it via the
guest-agent report.

I guess the question hidden here is very similar to your previous
question, will we support overriding IPAM policy on a vNIC level which
enables setting IP addresses on a network via other means like the
payload (while for other VMs on that network you'd like to get a DHCP
service from oVirt).

In this context (aiming for a more generic IPAM modeling in oVirt) what
we did look at, is integration with Foreman smart-proxy [1]. It also
provides support for DHCP capabilities, but more for the use case of
having a DHCP server defined in your organization and you'd like oVirt
to integrate with it. This part of our work is still on-going, we'll
share ideas after we work on it some more.

[1] https://github.com/theforeman/smart-proxy/tree/develop/lib/proxy/dhcp

> - iiuc, quantum would be the one allocating the ip addresses
>   themselves. i assume there is an API allowing engine to get these ip
>   addresses back to show to admin/user?

In fact this is up to the Quantum plugin to implement. When creating a
Port in Quantum the plugin should allocate an IP for the port as part of
it's implementation (only if DHCP is enabled or subnet defined on the
network).
There is an implementation for the IP address allocation in
QuantumDbPluginV2 (_generate_ip) so the oVirt plugin can reuse the code
from there but we did not look into the specifics of the implementation yet.

Anyway the IP address allocated is part of the Port entity, we can
always query Quantum for the port details and get the IP. Or in the case
of using the oVirt plugin we can have another way to get this
information - however we want to avoid designing the integration around
the specific usage of oVirt plugin so when we get to the more detailed
design we'll have to look into our options there.

> - in ec2, the ip address changes every boot. do we expect the IP to be
>   reserved per mac address, or to be released when the VM goes down
>   (not sure what's the default IPAM behavior).
>   i could be confusing the IP behavior of the floating (public) IPs in
>   ec2 with the private IPs (which may be durable.

The release of the IP address is tightly coupled with the existence of
the Port entity in Quantum. As long as the Port is not deleted the IP is
reserved.
In our modeling we though to create a port in quantum on VM-start and
remove the port on VM-stop, which means for each VM boot (via the
engine) we'll get a new IP allocated, this correlates nicely with DHCP
behavior.
For statically defined addresses - I guess we'll have to keep the port
in Quantum for as long as the VM is defined in the engine - we need to
give it some more thought.

> - we'll need to think about the deployment aspects of qunatum service
>   and its agents.

of course

> - you are designing a "configuration api" by changing the qunatum
>   config and restarting the service. as the config file format may
> change, it may make sense to put a wrapper script around config changes,
> so the implementation of the required config could be change as qunatum
> evolves.

We did not give it a lot of though at this point, obviously something to
consider as part of stabilizing this integration.

> 
> looking forward to see something working from all of this.
> 
> Thanks,
>    Itamar