Open Stack

On 11/30/20 11:50, Sean Mooney wrote:
> On Mon, 2020-11-30 at 18:16 +0000, Jeremy Stanley wrote:
>> On 2020-11-30 10:13:00 -0800 (-0800), Michael Johnson wrote:
>> [...]
>>> So, I think I am in alignment with Sean. The hostname component should
>>> return a 400 if there is an illegal character in the string, such as a
>>> period. We also should use Punycode to store/handle unicode hostnames
>>> correctly.
>> [...]
>>
>> So to be clear, you're suggesting that if someone asks for an
>> instance name which can't be converted to a (legal) hostname, then
>> the nova boot call be rejected outright, even though there are
>> likely plenty of people who 1. (manually) align their instance names
>> with FQDNs, and 2. don't use the hostname metadata anyway?
> unfortunetly we cant do that even if its the right thing to do technically.
> 
> i think the path forward has to be something more like this.
> 
> 1.) add a new workaround config option e.g. disable_strict_server_name_check.
>      for upgrade reason it would default to true in wallaby
>      when strict server name checking is disabled we will transform any malformed
>      numeric  tld by replacing the '.' with '-' or by replacing the hostname with server-<uuid> as we do
>      with unicode hostnames.

Note that the model we've been using for workarounds is that they 
default to "False" and that users "opt in" to working around existing 
behavior by setting them to "True". So I think this should be something 
more like [workarounds]enable_strict_server_name_check = False by 
default and users can opt-in by setting True.

> 2.) add a new api micro versions and do one of:
>     a.) reject servers with invlaid server names that contain '.' with a 400
>     b.) transform server names according to the RFEs (replace all '.' and other disallowed charaters with -)
>     c.) add support for FQDNs to the api.
> 	this coudl be something like adding a new field to store the fqdn  as a top level filed on the server.
>          make hostname contain jsut the host name with the full FQDN in the new fqdn field.
[...]

This would be my preference for the long term: add a new request 
parameter in the API for 'hostname' using a new microversion and 
decouple from the display name and let the display name be a nickname 
for the server.

This is what I hacked into the API downstream while I was at Yahoo 7-ish 
years ago when I was too newb to know how to propose it upstream and 
also hadn't yet experienced the full pain of carrying downstream patches 
long term. I think what I did was mostly just route the new 'hostname' 
request param into the existing code for the display name and then left 
display name alone to be only a label on the instance that is not used 
anywhere else.

I think having the display name and hostname as separate request 
parameters in the API is the way we should have been doing this upstream 
long ago.

Cheers,
-melanie