yahoo-eng-team team mailing list archive

[Douglas Jordan <1752977@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

During Azure preprovisioning, the platform owned VM gets into a polling
loop while we are waiting for the reprovsioning data file (the
customer's ovf_env.xml). If the VM moves from one vnet to another, we
will get a timeout exception on the request to IMDS and thus need to re-
dhcp to get the new IP and network configuration. Currently, that
timeout is 60seconds, and upon further testing IMDS responds within 5-20
milliseconds so we propose moving the timeout to 1 second in order to
speed up the total deployment time for the customer.

In addition, due to IMDS server updates there is a chance it will be
unreachable. If it is, then we could be re-dhcping multiple times, and
it is possible to hit the current limit (5) especially with a max retry
of 5. That would put the VM in an effectively useless state where it
would not be possible to recover. We propose removing the max dhcp retry
count for preprovisioning.

** Affects: cloud-init
     Importance: Undecided
         Status: New

** Merge proposal linked:
   https://code.launchpad.net/~dojordan/cloud-init/+git/cloud-init/+merge/340546

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1752977

Title:
  Azure Preprovisioning waits an extra 60s due to timeout

Status in cloud-init:
  New

Bug description:
  During Azure preprovisioning, the platform owned VM gets into a
  polling loop while we are waiting for the reprovsioning data file (the
  customer's ovf_env.xml). If the VM moves from one vnet to another, we
  will get a timeout exception on the request to IMDS and thus need to
  re-dhcp to get the new IP and network configuration. Currently, that
  timeout is 60seconds, and upon further testing IMDS responds within
  5-20 milliseconds so we propose moving the timeout to 1 second in
  order to speed up the total deployment time for the customer.

  In addition, due to IMDS server updates there is a chance it will be
  unreachable. If it is, then we could be re-dhcping multiple times, and
  it is possible to hit the current limit (5) especially with a max
  retry of 5. That would put the VM in an effectively useless state
  where it would not be possible to recover. We propose removing the max
  dhcp retry count for preprovisioning.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1752977/+subscriptions