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 _______________________________________________ Arch mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/arch
