On 2014年09月18日 18:57, Sean Dague wrote:
When we can return the json-schema to user in the future, can we say
that means API accepting utf8 or utf8mb4 is discoverable? If it is
discoverable, then we needn't limit anything in our python code.
On 09/18/2014 06:38 AM, Christopher Yeoh wrote:
On Sat, 13 Sep 2014 06:48:19 -0400
Sean Dague <s...@dague.net> wrote:
On 09/13/2014 02:28 AM, Kenichi Oomichi wrote:
Thanks for bring it up here,
From: Chris St. Pierre [mailto:stpie...@metacloud.com]
Sent: Saturday, September 13, 2014 2:53 AM
Subject: [openstack-dev] [nova] Expand resource name allowed
We have proposed that the allowed characters for all resource
names in Nova (flavors, aggregates, etc.) be expanded to all
printable unicode characters and horizontal spaces:
Currently, the only allowed characters in most resource names are
alphanumeric, space, and [.-_].
We have proposed this change for two principal reasons:
1. We have customers who have migrated data forward since Essex,
when no restrictions were in place, and thus have characters in
resource names that are disallowed in the current version of
OpenStack. This is only likely to be useful to people migrating
from Essex or earlier, since the current restrictions were added
2. It's pretty much always a bad idea to add unnecessary
restrictions without a good reason. While we don't have an
immediate need to use, for example, the ever-useful
http://codepoints.net/U+1F4A9 in a flavor name, it's hard to come
up with a reason people *shouldn't* be allowed to use it.
That said, apparently people have had a need to not be allowed to
use some characters, but it's not clear why:
https://bugs.launchpad.net/nova/+bug/977187 So I guess if anyone
knows any reason why these printable characters should not be
joined in holy resource naming, speak now or forever hold your
I also could not find the reason of current restriction on the bug
report, and I'd like to know it as the history.
On v2 API(not v2.1), each resource name contains the following
restriction for its name:
Resource | Length | Pattern
aggregate | 1-255 | nothing
backup | nothing | nothing
flavor | 1-255 | '^[a-zA-Z0-9. _-]*[a-zA-Z0-9_-]+
| | [a-zA-Z0-9. _-]*$'
keypair | 1-255 | '^[a-zA-Z0-9 _-]+$'
server | 1-255 | nothing
cell | 1-255 | don't contain "." and "!"
On v2.1 API, we have applied the same restriction rule for whole
resource names for API consistency, so maybe we need to consider
this topic for whole names.
Honestly, I bet this had to do with how the database used to be set
So it turns out that utf8 support in MySQL does not support UTF-8 4 byte
multibyte characters (only 1-3 bytes). For example if you do a create
image call with an image name to glance with a 4 byte multibyte
character in the name it will 500. I'd guess we do something
similar in places with the Nova API where we have inadequate input
validation. If you want 4 byte support you need to use utf8mb4 instead.
Oh... fun. :(
I don't know if postgresql has any restrictions (I don't think it
does) or if db2 does too. But I don't think we can/should make it a
complete free for all. It should at most be what most databases support.
I think its a big enough change that this late in the cycle we should
push it off to Kilo. It's always much easier to loosen input validation
than tighten it (or have to have an "oops" revert on an officially
released Nova). Perhaps some tests to verify that everything we allow
past the input validation checks we can actually store.
So, honestly, that seems like a pendulum swing in an odd way.
Havana "use anything you want!"
Juno "strict asci!"
Can't we just catch the db exception correctly in glance and not have it
explode? And then allow it. Exploding with a 500 on a bad name seems the
wrong thing to do anyway.
That would also mean that if the user changed their database to support
utf8mb4 (which they might want to do if it was important to them) it
would all work.
I think some release notes would be fine to explain the current
situation and limitations.
Basically, lets skate towards the puck here, realizing some corner cases
exist, but that we're moving in the direction we want to be, not back
OpenStack-dev mailing list