On Tue, Oct 03, 2017 at 01:00:13PM -0700, Clint Byrum wrote:

:It's worth noting that AD and Kerberos were definitely not designed
:for clouds that have short lived VMs, so it does not surprise me that
:treating VMs as cattle and then putting them in AD would confuse it.

For instances we have that need Kerberos keytabs we specify the fixed
IP. This works in our OpenStack where it's our IP space so PTR record also
matches, not so well in public cloud where we can reserve an IP and
set forward DNS but not control its reverse mapping.

-Jon

:Excerpts from Tim Bell's message of 2017-10-03 18:46:31 +0000:
:> 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 <cl...@fewbar.com>
:> Date: Tuesday, 3 October 2017 at 19:17
:> To: openstack-operators <openstack-operators@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@lists.openstack.org
:>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
:>     
:
:_______________________________________________
:OpenStack-operators mailing list
:OpenStack-operators@lists.openstack.org
:http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

-- 

_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Reply via email to