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 <dtro...@gmail.com> wrote on 02/12/2018 10:24:05 AM: >> >> On Mon, Feb 12, 2018 at 9:13 AM, Graham Hayes <g...@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 >> dtro...@gmail.com >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
Description: OpenPGP digital signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev