Open Stack

Yeah, I think it is important that we decouple hostname from domain as
well. This will be consistent with the existing neutron API and allow
proper validation of the hostname for use by the guest OS.

Michael

On Mon, Nov 30, 2020 at 12:31 PM melanie witt <melwittt at gmail.com> wrote:
>
> 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
>
>