Hm.. Its interesting. digging further, I don't understand how this caused a problem on nova. It seems (either by design or happenstance) that the general behavior of the metadata service handles this issue, and boto is designed to read the metadata service as it is implemented.
I actually verified functional 'boto.utils.get_instance_metadata' on both nova and ec2 with a key named "my brickies" (nova folsom as packaged in Ubuntu). The output of the commands below was identical. Example: $ wget http://169.254.169.254/2009-04-04/meta-data/public-keys -O - -q; echo 0=my brickies $ wget http://169.254.169.254/2009-04-04/meta-data/public-keys/0/ -O - -q; echo openssh-key $ wget http://169.254.169.254/2009-04-04/meta-data/public-keys/0/openssh-key -O - -q; ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA3I7VUf2l5gSn5uavROsc5HRDpZdQueUq5ozemNSj8T7enqKHOEaFoU2VoPgGEWC9RyzSQVeyD6s7APMcE82EtmW4skVEgEGSbDc1pvxzxtchBj78hJP6Cf5TCMFSXw+Fz5rF1dR23QDbN1mkHs7adr8GW4kSWqU7Q7NDwfIrJJtO7Hi42GyXtvEONHbiRPOe8stqUly7MvUoN+5kfjBM8Qqpfl2+FNhTYWpMfYdPUnE7u536WqzFmsaqJctz3gBxH9Ex7dFtrxR4qiqEr9Qtlu3xGn7Bw07/+i1D+ey3ONkZLN+LQ714cgj8fRS4Hj29SCmXp5Kt5/82cD/VN3NtHw== my brickies So, the public-keys (also in nova) is special cased, and you do not ever refer to the key name when crawling. So the space shouldn't actually be used. I agree the general suggestion, though, that boto should not be doing requests with unencoded urls. ** Attachment added: "typescript of some other info 'get_instance_metadata'" https://bugs.launchpad.net/cloud-init/+bug/962046/+attachment/3174877/+files/typescript -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/962046 Title: EC2 metadata retrieval fails with spaces in a resource name To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/962046/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
