[Openstack-operators] [nova] Should we allow passing new user_data during rebuild?

Tim Bell Tim.Bell at cern.ch
Tue Oct 3 18:46:31 UTC 2017


We use rebuild when reverting with snapshots. Keeping the same IP and hostname avoids some issues with Active Directory and Kerberos.

Tim

-----Original Message-----
From: Clint Byrum <clint at fewbar.com>
Date: Tuesday, 3 October 2017 at 19:17
To: openstack-operators <openstack-operators at lists.openstack.org>
Subject: Re: [Openstack-operators] [nova] Should we allow passing new	user_data during rebuild?

    
    Excerpts from Matt Riedemann's message of 2017-10-03 10:53:44 -0500:
    > We plan on deprecating personality files from the compute API in a new 
    > microversion. The spec for that is here:
    > 
    > https://review.openstack.org/#/c/509013/
    > 
    > Today you can pass new personality files to inject during rebuild, and 
    > at the PTG we said we'd allow passing new user_data to rebuild as a 
    > replacement for the personality files.
    > 
    > However, if the only reason one would need to pass personality files 
    > during rebuild is because we don't persist them during the initial 
    > server create, do we really need to also allow passing user_data for 
    > rebuild? The initial user_data is stored with the instance during 
    > create, and re-used during rebuild, so do we need to allow updating it 
    > during rebuild?
    > 
    
    My personal opinion is that rebuild is an anti-pattern for cloud, and
    should be frozen and deprecated. It does nothing but complicate Nova
    and present challenges for scaling.
    
    That said, if it must stay as a feature, I don't think updating the
    user_data should be a priority. At that point, you've basically created an
    entirely new server, and you can already do that by creating an entirely
    new server.
    
    _______________________________________________
    OpenStack-operators mailing list
    OpenStack-operators at lists.openstack.org
    http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
    



More information about the OpenStack-operators mailing list