On 11/29/2012 09:07 AM, gong yong sheng wrote:
On 11/29/2012 12:03 AM, Mark McClain wrote:
On Nov 28, 2012, at 8:03 AM, gong yong sheng
<[email protected]> wrote:
On 11/28/2012 08:11 AM, Mark McClain wrote:
On Nov 27, 2012, at 6:33 PM, gong yong sheng
<[email protected]> wrote:
Just wanted to clarify two items:
At the moment all of the dhcp agents receive all of the updates.
I do not see why we need the quantum service to indicate which
agent runs where. This will change the manner in which the dhcp
agents work.
No. currently, we can run only one dhcp agent since we are using
a topic queue for notification.
You are correct. There is a bug in the underlying Oslo RPC
implementation that sets the topic and queue names to be same
value. I didn't get a clear explanation of this problem until
today and will have to figure out a fix to oslo.
And one problem with multiple agents serving the same ip is:
we will have more than one agents want to update the ip's
leasetime now and than.
This is not a problem. The DHCP protocol was designed for multiple
servers on a network. When a client accepts a lease, the server
that offered the accepted lease will be the only process attempting
to update the lease for that port. The other DHCP instances will
not do anything, so there won't be any chance for a conflict.
Also, when a client renews it sends a unicast message to that
previous DHCP server and so there will only be one writer in this
scenario too. Additionally, we don't have to worry about
conflicting assignments because the dhcp agents use the same static
allocations from the Quantum database.
I mean dhcp agent is trying to update leasetime to quantum server.
If we have more than one dhcp agents, this will cause confusion.
def update_lease(self, network_id, ip_address, time_remaining):
try:
self.plugin_rpc.update_lease_expiration(network_id,
ip_address,
time_remaining)
except:
self.needs_resync = True
LOG.exception(_('Unable to update lease'))
I think it is our dhcp agent's defect. Why does our dhcp agent need
the lease time? all the IPs are managed in our quantum server, there
is not need for dynamic ip management in dhcp server managed by dhcp
agent.
There cannot be confusion. The dhcp client selects only one server
to accept a lease, so only one agent will update this field at a
time. (See RFC2131 section 4.3.2 for protocol specifics). The
dnsmasq allocation database is static in Quantum's setup, so the
lease renewal needs to propagate to the Quantum Server. The Quantum
server then uses the lease time to avoid allocating IP addresses
before the lease has expired. In Quantum, we add an additional
restriction that expired allocations are not reclaimed until the
associated port has been deleted as well.
Hi, I am saying in quantum there is no need to use lease time feature
of dnsmasq. We manage ip allocations in quantum, which will commands
dnsmasq to do ip allocation.
What do we do if lease time expires? dnsmasq will allocate the ip to
another VM?
In fact, in our quantum, the code is not working at all or not working
well:
dnsmasq -> update_lease(self, network_id, ip_address,
time_remaining) -> plugin_rpc.update_lease_expiration
-> plugin.update_fixed_ip_lease_expiration(context, network_id,
ip_address,
lease_remaining)
function in plugin:
def update_fixed_ip_lease_expiration(self, context, network_id,
ip_address, lease_remaining):
expiration = (timeutils.utcnow() +
datetime.timedelta(seconds=lease_remaining))
query = context.session.query(models_v2.IPAllocation)
query = query.filter_by(network_id=network_id,
ip_address=ip_address)
try:
fixed_ip = query.one()
fixed_ip.expiration = expiration
except exc.NoResultFound:
LOG.debug("No fixed IP found that matches the network %s
and "
"ip address %s.", network_id, ip_address)
We can see the fixed_ip.expiration is set but it is not saved into DB
at all. (if my observation is right)
This is set in the database and works. The problem is as follows - a VM
terminates and its IP is recycled. The next VM may get this IP. If this
IP was under lease then the dnsmasq will not provide the IP address to
the VM. This means that the VM will have no connectivity.
This is what the feature addresses.
one more question: I am doubting the expiration feature. Why do we
need expiration?
IP is recycled when the port is deleted.
mark
--
Mailing list: https://launchpad.net/~quantum-core
Post to : [email protected]
Unsubscribe : https://launchpad.net/~quantum-core
More help : https://help.launchpad.net/ListHelp
