I noticed that above, 10.55.55.8 is the address of the node controller.
In cases where the correct response is found, that token is the public
IP address of the node. That would explain why the search for a
matching VM's IP would fail.
--
UEC guests sometimes fail on consuming user data (metadat
I've been testing more, now with current lucid images, which have newer
cloud-init.
'ngrep port 8773' on the CLC shows:
T 10.55.55.8:39968 -> 10.55.55.2:8773 [AP]
GET /2009-04-04/meta-data/instance-id HTTP/1.1..Accept-Encoding: identity..
Host: 169.254.169.254..Connection: close..User
I'm testing with a modified version of 20100427.1 (release) in the data
center. In about 4 out of 50 cases, I see the 200 OK error. Running
ngrep to watch data on the CC, I see things like:
T 172.19.1.42:58975 -> 169.254.169.254:80 [AP]
GET /2009-04-04/meta-data/instance-id HTTP/1.1..
more testing has led me to the following:
a.) I cannot reproduce the 200 OK response with empty metadata that we see in
the data center rig on my own hardware. That is still an issue.
b.) It appears that in all my tests the metadata service eventually *does* come
up. On average in my tests (hun
Well, as is often the case, user error added some confusion here.
My system (and possibly kirkland and ttx) have a second dhcp server available
on the network. That dhcp server was responding, and sometimes its response
was being accepted rather than that of the CC.
So, user error causes the '4
** Attachment added: "console log of tty linux based image showing failure"
http://launchpadlibrarian.net/44997795/tty-linux-recreate-console.txt
--
UEC guests sometimes fail on consuming user data (metadata service isn't ready)
https://bugs.launchpad.net/bugs/566792
You received this bug not
I've recreated this with a ttylinux based image, with modifications to access
metadata service early in boot.
I'm attaching that instance here.
this can be registered with 'uec-register-tarball
ttylinux-11.0-fastboot-amd64-0.07.tar.gz mybucket'
it will also boot in smaller than m1.small (ie, you
Assigning to Scott, pending input from the Eucalyptus team
** Changed in: eucalyptus (Ubuntu Lucid)
Assignee: (unassigned) => Scott Moser (smoser)
--
UEC guests sometimes fail on consuming user data (metadata service isn't ready)
https://bugs.launchpad.net/bugs/566792
You received this bug
** Tags added: iso-testing
--
UEC guests sometimes fail on consuming user data (metadata service isn't ready)
https://bugs.launchpad.net/bugs/566792
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs
Attaching logs from Carlos.
** Attachment added: "clc-logs.tar.gz"
http://launchpadlibrarian.net/44918858/clc-logs.tar.gz
--
UEC guests sometimes fail on consuming user data (metadata service isn't ready)
https://bugs.launchpad.net/bugs/566792
You received this bug notification because you ar
** Summary changed:
- UEC guests sometimes fail on consuming user data
+ UEC guests sometimes fail on consuming user data (metadata service isn't
ready)
--
UEC guests sometimes fail on consuming user data (metadata service isn't ready)
https://bugs.launchpad.net/bugs/566792
You received this bu
** Tags added: patch
--
UEC guests sometimes fail on consuming user data
https://bugs.launchpad.net/bugs/566792
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubunt
** Patch added: "diff 0.5.10-0ubuntu1 to 0.5.10-0ubuntu2~debug0"
http://launchpadlibrarian.net/44905246/bug566792-debugdeb.diff
--
UEC guests sometimes fail on consuming user data
https://bugs.launchpad.net/bugs/566792
You received this bug notification because you are a member of Ubuntu
Bugs
I'm attaching a debug version of cloud-init. It has debug printfs
showing when cloud-init-cfg is called, and also better info on
'sleeping' waiting for the metadata service.
** Attachment added: "debug version of cloud-init"
http://launchpadlibrarian.net/44905143/cloud-init_0.5.10-0ubuntu2%7E
Apparently a eucalyptus metadata service issue, as evidenced by previous
comment.
** Changed in: cloud-init (Ubuntu)
Status: New => Invalid
** Changed in: eucalyptus (Ubuntu)
Importance: Undecided => High
** Changed in: eucalyptus (Ubuntu)
Status: New => Confirmed
** Also affec
I've run some tests with this patch applied on the system that Carlos
was running on. The patch seems to do what was intended, to block and
wait for existance of metadata service with instance-id field or wait
for 20 seconds.
The result is that the instances still fail, but now, rather than
faili
Re-attaching. The previous had a intentional typo to test the error
path left in. this wone i hope is better.
** Patch added: "possible workaround patch to cloud-init"
http://launchpadlibrarian.net/44848714/bug566792-workaround.diff
--
UEC guests sometimes fail on consuming user data
https
I'm attaching a possible workaround patch to cloud-utils to work around
this to this Eucalyptus bug.
** Patch added: "possible workaround patch to cloud-init"
http://launchpadlibrarian.net/44848423/bug566792-workaround.diff
** Patch removed: "possible workaround patch to cloud-init"
http://
I've opened a Eucalyptus (and Ubuntu/Eucalyptus task). This is really a
eucalyptus bug. Ideally the instance would not be booted without the
metadata service up and ready. That would be the ideal world. As seen
in bug 308530, EC2 has an issue where if the instance looks too soon,
the metadata s
I modified 'retry_url' in the cloudinit/boto_utils.py to have:
try:
req = urllib2.Request(url)
resp = urllib2.urlopen(req)
content = resp.read()
print "%s [%i]\n\t%s" % (url, resp.getcode(), content)
return content
the result is,
before 'return True' in the above snippet, I added:
import pprint
print "%s\n%s\n%s" % (" begin userdata_raw ",
self.userdata_raw, " end userdata_raw ")
print "%s\n%s\n%s" % (" begin metadata ",
pprint.pprint(self.metadata), " end m
ugh.
I'm somewhat baffled on how this can happen.
WARNING:INSTANCE i-39AC0623: File
"/usr/lib/python2.6/dist-packages/cloudinit/DataSourceEc2.py", line 64, in
get_instance_id
WARNING:INSTANCE i-39AC0623:return(self.metadata['instance-id'])
That indicates that somehow, the 'metadata' membe
** Attachment added: "failed instance run log"
http://launchpadlibrarian.net/44832884/guest-error.log
--
UEC guests sometimes fail on consuming user data
https://bugs.launchpad.net/bugs/566792
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to U
23 matches
Mail list logo
