Public bug reported:
All tests from test_smartos.py fail in a chroot as follows (only first
failure shown):
$ nosetests tests/unittests/test_datasource/test_smartos.py
F
==
FAIL: test_b64_keys
In one way or another, the CloudStack datasource was explicitly enabled.
You or something explicitly configured this datasource on, and to be run
before the Ec2 datasource, so generally its functioning as designed.
Well it wasn't explicitly disabled :-)
Additionally, its not a 404 that we
Public bug reported:
On OpenStack, the CloudStack handler is retyring even if the response is
404, resulting in a 2 min timeout.
IMHO, readurl() should abort in this case.
ci-info: | Route | Destination | Gateway |Genmask| Interface | Flags |
ci-info:
** Branch linked: lp:~juergh/cloud-init/lp1298921
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to cloud-init in Ubuntu.
https://bugs.launchpad.net/bugs/1298921
Title:
cloud-init should give up on 404 errors
To manage notifications
Scott,
Looks good but could be simplified to:
+if [ ${rootdisk%[0-9]p} != ${rootdisk} ] ; then
+rootdisk=${rootdisk%p}
+fi
I don't think you need to adjust $partnum.
Also, can you apply the patch to
growroot/dracut/modules.d/50growroot/growroot.sh as well?
Note that the following (old)
Can we have this patch applied to
growroot/dracut/modules.d/50growroot/growroot.sh as well?
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to cloud-initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1236380
Title:
growroot
Public bug reported:
The growroot script doesn't correctly determine the root device name if
the device name itself ends with a digit and partitions are named root
devicep1, root devicep2 aso. For example, when using an SD card:
$ ls -l /dev/mmcblk0*
brw-rw 1 root disk 179, 0 Oct 7 16:04
Sorry this took so long. Finally found the time to test the 12.04
package and it works. Thanks.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to python-boto in Ubuntu.
https://bugs.launchpad.net/bugs/962046
Title:
EC2 metadata
Hmm... On the hp cloud I get:
ubuntu@juergh-8419-5531:~$ curl 169.254.169.254/2009-04-04/meta-data
local-ipv4
reservation-id
local-hostname
placement/
ami-launch-index
public-hostname
mpi/
hostname
ami-id
public-keys/
instance-action
public-ipv4
block-device-mapping/
ami-manifest-path
mpi/ was present in diablo but removed subsequently:
commit 8ecdc44690ced882205112e017f79dc98cd6aaca
Author: Jesse Andrews anotherje...@gmail.com
Date: Tue Mar 6 20:49:16 2012 -0800
remove undocumented, unused mpi 'extension' to ec2 metadata
--
You received this bug notification because
What does the MD look like on EC2? Curious, can you send a dump? Yes it
seems to be a problem with the nova MD service in that it's different
from EC2 but I still think boto should be able to handle special
characters in MD URLs or is there an EC2 spec that this will never
happen with EC2?
--
nova boot --flavor FLAVOR_ID --image IMAGE_ID --key_name 'my key'
INSTANCE_NAME
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to python-boto in Ubuntu.
https://bugs.launchpad.net/bugs/962046
Title:
EC2 metadata retrieval fails with
I agree that Nova needs to be fixed but we need a cloud-init fix for the
current Nova as well. As for running an API server on each compute node,
I don't think that's a viable solution for our environment. We've
modified memcached to cache the metadata requests and that seems to help
make things
** Package changed: cloud-utils (Ubuntu) = cloud-init (Ubuntu)
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to cloud-init in Ubuntu.
https://bugs.launchpad.net/bugs/894279
Title:
cloud-init fails to fetch metadata with OpenStack
To
14 matches
Mail list logo
