You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In future azd features, azd will start using the names of services (or elements in azure.yaml) as command targets.
It's important for us to think about what allowed naming characters we should allow. For example, if we allow . characters (which currently breaks parts of azd today -- such as in #3183), we'd have to think about if we ever use . as a property accessor. Example: myapp.api.env would end up being ambiguous for interpretation without escaping.
Early design ideas
We have some prior-art for inspiration from DNS systems, which also influences K8s object names:
contain only lowercase alphanumeric characters or '-'
start with an alphabetic character
end with an alphanumeric character
From how azd is commonly used today, we seem to lean towards RFC 1123 label names -- lowercase, dash-separated, alphanumeric characters.
Use cases to consider
The main question to consider is that whether all language developers will overall be comfortable with whatever naming scheme we choose.
I'm opening up this issue for discussion, hoping we can arrive at some level of consensus. The next phase of implementation is likely to implement the naming scheme as a recommendation in the short/near term, and eventually as a restriction in the longer term.
The text was updated successfully, but these errors were encountered:
With #4403, I'm adding logic for default name generation in azd-init to match RFC 1123 label names as a point of experimentation and gathering user feedback.
In future azd features, azd will start using the names of services (or elements in azure.yaml) as command targets.
It's important for us to think about what allowed naming characters we should allow. For example, if we allow
.
characters (which currently breaks parts of azd today -- such as in #3183), we'd have to think about if we ever use.
as a property accessor. Example:myapp.api.env
would end up being ambiguous for interpretation without escaping.Early design ideas
We have some prior-art for inspiration from DNS systems, which also influences K8s object names:
DNS Subdomain Names RFC 1123
RFC 1123 Label Names - RFC 1123.
RFC 1035 Label Names - RFC 1035.
From how azd is commonly used today, we seem to lean towards RFC 1123 label names -- lowercase, dash-separated, alphanumeric characters.
Use cases to consider
The main question to consider is that whether all language developers will overall be comfortable with whatever naming scheme we choose.
I'm opening up this issue for discussion, hoping we can arrive at some level of consensus. The next phase of implementation is likely to implement the naming scheme as a recommendation in the short/near term, and eventually as a restriction in the longer term.
The text was updated successfully, but these errors were encountered: