I think you're right Darragh.
It was actually Montreal's snow and cold freezing my brain as I
investigated the same issue a while ago and tried to change cirrOS to send
a DHCPDISCOVER every 10 seconds instead of 60 seconds, but then I moved to
something else as I wasn't even sure a new centos base
On Monday, 20 January 2014, 15:33, Jay Pipes wrote:
>Sorry for top-posting -- using web mail client.
no worries - it doesn't bother me.
>
>Is it possible to change the retry interval in Cirros (or cloud-init?) so that
>the backoff is less than 60 seconds?
I think the udhcpc command line paramet
Sorry for top-posting -- using web mail client.
Is it possible to change the retry interval in Cirros (or cloud-init?) so
that the backoff is less than 60 seconds?
Best,
-jay
On Mon, Jan 20, 2014 at 10:23 AM, Darragh O'Reilly <
dara2002-openst...@yahoo.com> wrote:
>
> I did a test to see what
I did a test to see what the dhcp client on cirros does. I killed the dhcp
agent and started an instance. The instance sent the first dhcp offer after
about 35 sec. Then another 60 sec later, and a final one after another 60 sec.
So a revised theory for what happened is this:
t=0 tempest st
Hi Salvatore,
I presume it's this one?
http://logs.openstack.org/38/65838/4/check/check-tempest-dsvm-neutron-isolated/d108e4a/logs/tempest.txt.gz?#_2014-01-19_20_50_14_604
Is it true that the cirros image just fires off a few dhcp discovers and then
gives up? If so, then maybe it did so before
I have been seeing in the past 2 days timeout failures on gate jobs which I
am struggling to explain. An example is available in [1]
These are the usual failure that we associate with bug 1253896, but this
time I can verify that:
- The floating IP is correctly wired (IP and NAT rules)
- The DHCP po
