Open Stack

On 12/02/18 16:04, William M Edmonds wrote:
> keystone may have taken "domain", but it didn't take "dns-domain"

No, but the advice at the time was to move to zone, and match DNS
RFCs, and not namespace objects with the service type.

We moved from "domain" -> "zone" and "records" -> "recordsets" in
both the CLI and in our V2 API (in Aug 2013, so the time for change
has long passed).

The point of my initial email was that if we were moving some of the
inconsistent naming for availability zones to something, that
moving it to "availability-zone" would be better than "zone". I think
that point has been made, so lets leave it at that.

- Graham

> 
> Dean Troyer <dtroyer at gmail.com> wrote on 02/12/2018 10:24:05 AM:
>>
>> On Mon, Feb 12, 2018 at 9:13 AM, Graham Hayes <gr at ham.ie> wrote:
>> > OSC only predates Designate by 5 months ...
>>
>> My bad, I didn't check dates.
>>
>> > "Zone" was what we were recommend to use by the OSC devs at the time we
>> > wrote our OSC plugin, and at the time we were also *not* supposed to
>> > name space commands inside service parent (e.g. openstack zone create vs
>> > openstack dns zone create).
>>
>> Namespacing commands and naming options are totally separate things.
>> It is likely I suggested --zone at the time, and in the context of DNS
>> commands it is very clear.  Also, in the context of Compute commands,
>> --zone meaning availability zone is also clear.
>>
>> > For command flags --dns-zone seems like a good idea - but having a plain
>> > --zone is confusing when we have a top level "zone" object in the CLI,
>> > when the type of object that "--zone" refers to is different to
>> > "openstack zone <action>"
>>
>> Again, if there is confusion, things should be more specifically named
>> to remove the confusion.  Maybe allowing "zone" to be assumed to be a
>> DNS zone was a mistake, I've made plenty of those in OSC already, so
>> there is precedent, but it seemed reasonable at the time and we (OSC
>> team) do not control what external plugins do.
>>
>> For example, I really resist using abbreviations in OSC, but in some
>> places to not do so is to buck trends that any semi-experienced user
>> in the field would expect.  The last discussion of this was last week
>> regarding "MTU" in Network commands.
>>
>> These are not hard rules, but strong guidelines that can and should be
>> interpreted in the context that they will be applied.  And in the end,
>> the result should be one that is understandable, clear and even
>> expected by the users.
>>
>> dt
>>
>> --
>>
>> Dean Troyer
>> dtroyer at gmail.com
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> https://urldefense.proofpoint.com/v2/url?
>>
> u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-
>>
> siA1ZOg&r=uPMq7DJxi29v-9CkM5RT0pxLlwteWvldJgmFhLURdvg&m=Fr9TF_mDZVJgACWKoyXcnphs-6rMDWufyRhpQEtUask&s=m5wXNx8okCgs7CbNoMhHEQev0xJCFIq61pcmnWBugSs&e=
>>
> 
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180212/996101ef/attachment.sig>