** Changed in: euca2ools
Assignee: (unassigned) => Mitch Garnaat (mitch-garnaat)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/850196
Title:
euca-describe-images crashed with GetoptError in lon
** Changed in: eucalyptus
Assignee: (unassigned) => chris grzegorczyk (chris-grze)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/813295
Title:
urlib.request fails to open Eucalyptus metadata se
This is a UEC upstart init script related issue; marking as invalid
against the eucalyptus upstream.
** Changed in: eucalyptus
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bu
** Changed in: eucalyptus
Assignee: (unassigned) => Daniel Nurmi (nurmi)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/742443
Title:
cc looses database information after restart
--
ubu
All,
I think I've found the problem all! So, looking at:
bzr branch lp:ubuntu/isc-dhcp
1.) the patch I've supplied is being placed at the end of the '00list' file in
debian/patches. not a problem normally i suspect, however:
2.) the patch is not present in the actual code that is being used w
Carlos,
As a debugging aid, I've attached a stand-alone program that uses the
same loop as the patch for dhcpd: running it on the CC right after a
run-instances should result in output like this:
root@eucahost-4-243:~# gcc getifaddrs.c; ./a.out
INTERFACE=lo SCRUBBEDINTERFACE=lo ADDR=127.0.0.1
IN
Carlos,
This is the message that was being thrown when the original problem was
cropping up; if you're still seeing this message with the patch
installed, then it (the patch) is not working properly. The server
should run even though there is no address in the config on the
10.55.55.0/24 subnet,
It turns out that I had(ve) apparmor disabled while working on this
problem, but the new dhcpd needs a slight change to its profile in order
to work. Here is what I saw with apparmor enabled:
root@eucahost-4-243:/var/log/eucalyptus# dmesg
[ 800.347860] type=1400 audit(1300832242.358:24): apparmo
** Changed in: eucalyptus
Status: New => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/476619
Title:
Networking problem in Eucalyptus when VNET_PUBLICIPS has an IP being
used in i
The part of the UEC that uses eucalyptus-ipaddr.conf is package
specific, and so we'll mark it as invalid against the upstream system.
** Changed in: eucalyptus
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubu
** Changed in: eucalyptus
Status: Incomplete => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/470355
Title:
ec2-bundle-vol and ec2-upload-bundle result in non accepted manifest
** Changed in: eucalyptus
Assignee: (unassigned) => chris grzegorczyk (chris-grze)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/731702
Title:
euca-add-user adds a new disabled user, and there
All,
Thanks for this bug report, it does indeed appear that there is a bug in
the new DHCP server that is preventing it from learning that some
interfaces may have multiple IP addresses associated with them. Here is
the result of my findings after looking at the dhcp server code for both
dhcpd3 f
This looks like another gcc linker option ordering issue. revno 1256 of
the eucalyptus branch contains a modified node/Makefile that should
resolve the problem (tested as a clean compile on natty):
root@ubuntu:~# ldd /usr/lib/axis2/services/EucalyptusNC/libEucalyptusNC.so
linux-vdso.so.
** Changed in: eucalyptus (Ubuntu Natty)
Assignee: (unassigned) => Daniel Nurmi (nurmi)
** Changed in: eucalyptus
Assignee: (unassigned) => Daniel Nurmi (nurmi)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Please see revno 1255 (latest) of Eucalyptus (lp:eucalyptus/2.0). That
branch should resolve java and C compilation issues for Natty. The C
compilation fix was twofold: re-arrange the gcc commandlines in various
Makefiles to put system library link options after local object options
(gcc *.c *.o
** Changed in: eucalyptus
Status: Incomplete => Won't Fix
** Changed in: eucalyptus
Status: Won't Fix => Invalid
** Changed in: eucalyptus
Assignee: (unassigned) => Dmitrii Zagorodnov (dmitrii)
--
partition2disk error starting up an instance
https://bugs.launchpad.net/bugs/44
** Changed in: eucalyptus
Status: Incomplete => Fix Released
--
euca-* commands stopped responding
https://bugs.launchpad.net/bugs/639639
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lis
Scott, thank you for pursuing this issue. Indeed, the meta-data service
keys off of the public IP of the VM, since that is the only source
address that is translated when the NCs cannot directly contact the CLC
(MANAGED modes). In order for the meta-data service to work, the VM
needs to be assign
The kvm driver, in the NC, was sending the first 64k of output. Fix is
in revno 1224, which adds some lseek() logic to send back the last 64k
of console output when getConsoleOutput() is invoked.
** Changed in: eucalyptus
Status: New => Fix Committed
--
euca-get-console-output gives firs
Public bug reported:
In the KVM NC driver, the pthread attr was set to detach a new pthread
on create, but was not being passed to the pthread_create() function
leading to the case where the NC will eventually be unable to start a
new pthread. Fix is in revno 1223.
** Affects: eucalyptus
Im
fixed in 1.6.2 revno 1220
--
node registration fails if node is co-located with CC, and node hostname is
detected as local
https://bugs.launchpad.net/bugs/552115
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing li
Public bug reported:
euca_conf has (had) a bug where node registration, if the NC and CC were
running on the same machine, will fail if the host passed to --register-
nodes is detected as being on the same machine.
** Affects: eucalyptus
Importance: Low
Assignee: Daniel Nurmi (nurmi
** Changed in: eucalyptus
Status: In Progress => Fix Released
** Changed in: eucalyptus
Status: Fix Released => Fix Committed
--
memory leaks in NC: getConsoleOutput and startup_thread
https://bugs.launchpad.net/bugs/461444
You received this bug notification because you are a membe
Thierry,
It looks as if this may be a documentation bug: --deregister-cluster and
--deregister-sc takes the 'name' of the cluster, instead of the 'host'
of the component. I just tested with using the cluster name in both
cases, and de-registration is working. However, there are a few issues:
1.
** Changed in: eucalyptus
Status: New => Triaged
** Changed in: eucalyptus
Importance: Undecided => Low
--
euca-run-instances should fail if you try to run more instances than you can
(in a single security group)
https://bugs.launchpad.net/bugs/546293
You received this bug notificatio
** Changed in: eucalyptus
Assignee: (unassigned) => Daniel Nurmi (nurmi)
--
euca-run-instances should fail if you try to run more instances than you can
(in a single security group)
https://bugs.launchpad.net/bugs/546293
You received this bug notification because you are a member of Ubu
It looks like the problem is related to the fact that euca_conf
--deregister will de-register a node, but the uec_component_listener is
not informed when de-registration happens. Thus, if the component
listener is restarted, it will re-register the node as soon as it sees
the avahi publication of
** Changed in: eucalyptus
Status: In Progress => Triaged
--
Partitions presented to instance should be ext3, not ext2
https://bugs.launchpad.net/bugs/457281
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing l
We've modified the MASQ rule to use source !127.0.0.0/8, which resolves
this problem (in Lucid)
--
localhost connection timeouts after start of eucalyptus
https://bugs.launchpad.net/bugs/510086
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubun
Talked with Dustin, we're going to attempt to
a.) back up old scripts/ to the backup directory
b.) remove the old scripts/
c.) install new scripts in /usr/lib/eucalyptus/scripts/
d.) create softlink from /usr/lib/eucalyptus/scripts to /etc/eucalyptus/cloud.d
-Dan
--
please move /etc/eucalyptus
Public bug reported:
if instances are pending (for example, if they fail to run on the NCs),
and the cloud controller is restarted, public address state get be
incorrect, resulting in the inability to run new instances:
euca-run-instances $EMI -k mykey -n 4
The upstream part of this fix (add VNET_CLOUDIP and VNET_LOCALIP to
euca_conf --import-conf) is in revno 1202
-Dan
** Changed in: eucalyptus
Status: New => Confirmed
** Changed in: eucalyptus
Importance: Undecided => Low
** Changed in: eucalyptus
Assignee: (unassigned) =&g
euca-authorize sets up a rule that is specific to a user/security group.
For example, if you are using admin credentials and the group you're
authorizing is 'default', then the rule will apply to all instances run
by 'admin' in the group 'default'. If you acting as different user, say
'foobar', th
Since '--list-nodes' is not reporting '10.55.55.4' as registered, my
guess is that the 'euca_conf --register-nodes 10.55.55.4' did not
complete successfully. Can you check your nodes.list on the CC to see
if '10.55.55.4' was added to the list? If so, then we should check to
make sure the CC is t
All,
Mark, Dustin and I have discussed some ideas around the notion that
having a more 'automated' method of choosing and allocating public IP
addresses in the UEC, while keeping Eucalyptus in MANAGED mode in order
to support all of the networking features that Eucalyptus provides
(Elastic IPs, Se
All,
I'm unable to reproduce this problem with (pre) Eucalyptus 1.6.2; with a
running active CC in MANAGED mode (which has the masq rule in place), I
can telnet to localhost port 22 (for example) without a problem, and
sshing to localhost shows that I'm logged in from 'localhost' (implying
that th
This is really on the (we do our best to keep it)short-list of steps
that one currently needs to perform in order to migrate images (to and
from). Remember that images which are configured to run on xen will
almost surely need some minor modifications (...kernel modules?) in
order to boot properly
All,
Chris has added a bash completion config for euca_conf as of revno 1138;
take a look!
--
euca_conf is missing command-line completion
https://bugs.launchpad.net/bugs/458203
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu
This turns out to be a bit deeper of an issue than anticipated; we're
using parted to create a partition/filesystem during image conversion
time for KVM. parted currently does not support the creation of an ext3
partition using mkpartfs (and, since the partition is in the middle of
the disk image,
Some more context: if the eucalyptus DNS feature is disabled (as it is
in the UEC, by default), then we cannot guarantee that the IP addresses
that are specified by the administrator resolve to an actual hostname
(as, often, users are choosing private/unroutable IP addresses for VMs).
Inventing a h
Thank Thierry,
We've finally been able to (we believe) reproduce this type of condition
on our Lucid machines, and have figured out the reason why it is being
triggered on lucid UEC installations. The Eucalyptus front-end
components (cloud, walrus, sc) require that, on startup, the network
interf
Greetings,
We're having trouble reproducing this problem on our lucid systems
against eucalyptus-cloud-1.6.2~bzr1124-0ubuntu3. We think that the
issue is possibly related to some process startup behavior, but it would
be great to get some more system information or a process by which the
issue ca
The node controller code currently can service at most one request from
the CC at a time, and as such we set the MaxClients to 1 to ensure that
apache does not send multiple requests to a single NC web service. The
error message can safely be ignored!
Regards,
-Dan
--
eucalyptus-nc: server reac
All,
I've been able to confirm that the newest euca/rampart packages, from
proposed, are both functional and do not exhibit the memory leak. To be
specific, i'm running with:
eucalyptus-cc: 1.6~bzr931-0ubuntu7.4
librampart0: 1.3.0-0ubuntu5.1
Thanks!
-Dan
--
Memory leaked per connection
https:
All,
I've verified that the upstream patch, on top of the patch we've
provided, is both functional and does not exhibit the memory leak
problem; the test was to run the CC/NC against patched rampart/c for
approximately 18 hours, watching the memory footprint of the associated
apache2 processes.
-
Thierry, Shankar,
Thank you both for following up on this issue and finding a potential
patch to the memory leak issue in rampart; I'm testing the
rampartc-1.3.0 with the above patch now with a long term eucalyptus
test, and will report back when the test completes (we usually run for
.5 day to ma
To see the effect of this problem, the simplest setup is a multi-cluster
installation (single clc, walrus, and two clusters (cc/sc) each with one
node (nc)). Choose a security group (default is fine) and run one
instance in one cluster, and one instance in the other cluster (this is
controlled at
Network state refers to instance IP addresses and active security group
rules (user defined instance network ingress policies). It is important
to be able to maintain this state in the following scenario:
Eucalyptus is up and running
Users are running VMs and logging in/accessing them via the net
** Changed in: eucalyptus
Status: New => Fix Committed
--
memory leak; rampart_context not freed (memory leaked per connection)
https://bugs.launchpad.net/bugs/460085
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs
the patch required a small patch to eucalyptus that initializes axis2c
in the CC for each NC client connection (most already were handled this
way, except to StartNetwork/RunInstances).
in r946
--
memory leak; rampart_context not freed (memory leaked per connection)
https://bugs.launchpad.net/bu
** Changed in: eucalyptus
Importance: Undecided => High
--
memory leak; rampart_context not freed (memory leaked per connection)
https://bugs.launchpad.net/bugs/460085
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs ma
Public bug reported:
in the eucalyptus-cc upstart script, the line:
rm -f /var/lib/eucalyptus/CC/*
will always clear all CC state when the service is stopped. The
upstream init scripts use:
stop/start/restart
to control the service while maintaining CC state (stored in
/var/lib/eucaly
** Attachment added: "rampartc-1.3.0-euca.patch"
http://launchpadlibrarian.net/34337608/rampartc-1.3.0-euca.patch
** Also affects: eucalyptus
Importance: Undecided
Status: New
** Also affects: eucalyptus (Ubuntu)
Importance: Undecided
Status: New
--
memory leak; rampart_
Public bug reported:
It looks like the rampart_context structure is not freed after
processing (in rampart_in_handler.c), and in the rampart_context_free
function, the section for freeing the receiver_cert is commented out (in
rampart_token_processor.c). In our application (eucalyptus), this is
c
We (Eucalyptus team) have rolled new versions of the images that query
the meta-data service if it exists in preparation for the UEC release
(we've also added a 32 bit versions of each image :). The images are in
testing now, and will be released as soon as they are ready!
--
Non-ubuntu Eucalypt
the java (cloud, walrus, sc) components' logging uses log4j. the
defaults can be found in source under:
clc/modules/core/src/main/resources/log4j.xml
where you'll find the following, which control the file size and the max
number of files of this size that can exist
for the C c
Public bug reported:
There are several helpful links under the new Eucalyptus UEC Theme
'Services' tab. Adding a section that contains information and links
back to Eucalyptus itself would be helpful to users looking for
Eucalyptus user forums, documentation, downloads, and other Eucalyptus
relat
I looks like this bug happens when an authorize is called before the
group is used in another context (run-instances, describe-group, etc).
For example:
euca-authorize (fails)
euca-describe-groups
euca-authorize (success)
Attaching the log file showing exception, and exact commands
** Attachment
Public bug reported:
When trying to install a UEC node from the 20091017 .iso (amd64), the
installation fails during install of qemu-kvm due to a package conflict. Below
is a snippet of /var/log/syslog during the failure:
.
Oct 18 00:10:35 in-target: python-apt is already the newest version
This branch contains a simple fix to change the admin UI version string
to '1.6', in order to help avoid confusion with users having prior
versions of eucalyptus (1.6-devel).
lp:~nurmi/eucalyptus/webuiversion
--
Eucalyptus version string is incorrect (currently 1.6-devel, should be 1.6)
https://
Greetings,
We've analyzed the points in the source tree that are referenced, and
have found that none of them are actually exercised in a Karmic default
eucalyptus running system. More detail on each follows:
GLclient is a testing utility that doesn't get installed by the package (or a
'make in
Public bug reported:
in the karmic package r931, the version string reported through the
admin UI and on the filesystem is set incorrectly (current=1.6-devel,
should be=1.6)
** Affects: eucalyptus (Ubuntu)
Importance: Undecided
Status: New
** Tags: eucalyptus
** Tags added: eucal
committed in eucalyptus revno 926
--
Eucalyptus Public IPs should be submitted in CIDR or range notation
https://bugs.launchpad.net/bugs/438565
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@list
We will be adding the ability for the CC to accept ranges of IPs, using
only the last octet of the IPs, in a near commit of Eucalyptus. All
octets must obviously be between 0 and 255 inclusive. The following
will be accepted:
A.B.C.D-A.B.C.E
where D <= E. Multiple ranges can be specified:
A.B
Niemeyer and I tracked down the issue, which ended up being that the
manifest set by the image store proxy for both the ERI and EMI was
identical.
--
Unable to start images installed/registered via the image store
https://bugs.launchpad.net/bugs/446841
You received this bug notification because y
** Changed in: eucalyptus/1.6
Status: In Progress => Fix Committed
** Changed in: eucalyptus
Status: In Progress => Fix Committed
--
Assignment of IP 169.254.169.254 on CC is conflicting with UEC avahi publish
mechanism
https://bugs.launchpad.net/bugs/449143
You received this bug
Fixed in r922
** Changed in: eucalyptus
Status: In Progress => Fix Committed
** Changed in: eucalyptus/1.6
Status: New => Fix Committed
--
In STATIC mode, the CC is reporting instance's public IP incorrectly (last
number is missing)
https://bugs.launchpad.net/bugs/447555
You rece
Fixed in revno 925
--
Assignment of IP 169.254.169.254 on CC is conflicting with UEC avahi publish
mechanism
https://bugs.launchpad.net/bugs/449143
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs
ish is only
choosing globally scoped subnets to broadcast on?)
This fix is in testing now (Oct11/2009)
** Affects: eucalyptus
Importance: High
Assignee: Daniel Nurmi (nurmi)
Status: In Progress
** Affects: eucalyptus/1.6
Importance: High
Status: In Progress
Public bug reported:
There is a bug in client-marshal-adb.c that causes a segfault in the CC
when the number of running instances is high (sometimes). Fixed in
revno 924
** Affects: eucalyptus
Importance: High
Status: Fix Committed
** Affects: eucalyptus/1.6
Importance: High
My experiments with hot-attaching virtio disks to eucalyptus VMs have
been partially successful. I've been able to attach/detach a virtio
disk to/from a VM once, but the second attach causes a kvm segfault
followed by a libvirtd segfault. Removing eucalyptus from the scenario,
this problem can be
i-DCCA14C3
Functionally, the instance is getting the correct ip, but the reporting
is incorrect.
** Affects: eucalyptus
Importance: Medium
Assignee: Daniel Nurmi (nurmi)
Status: In Progress
** Affects: eucalyptus/1.6
Importance: Undecided
Status: New
** Affec
The problem is that the connection from the NC to Walrus is being
successfully opened, but is being timed out on the server side after two
minutes if no data is written to the wire (which is the case when the
large image is being decrypted/cached). We've increased the retry count
in the NC to 10 r
** Also affects: eucalyptus
Importance: Undecided
Status: New
** Changed in: eucalyptus
Importance: Undecided => High
--
Instances from large, fresh EMIs fail to start just after being registered
https://bugs.launchpad.net/bugs/439410
You received this bug notification because you a
** Changed in: eucalyptus (Ubuntu)
Status: Triaged => In Progress
** Changed in: eucalyptus (Ubuntu)
Assignee: (unassigned) => Dustin Kirkland (kirkland)
--
External command failure not handled correctly in some cases
https://bugs.launchpad.net/bugs/440744
You received this bug notif
** Changed in: eucalyptus (Ubuntu)
Assignee: (unassigned) => Dustin Kirkland (kirkland)
** Changed in: eucalyptus (Ubuntu)
Status: Triaged => In Progress
--
Part of storage controller setup that should run as the eucalyptus user runs as
root
https://bugs.launchpad.net/bugs/436276
Yo
** Changed in: eucalyptus (Ubuntu Karmic)
Status: Triaged => In Progress
** Changed in: eucalyptus (Ubuntu Karmic)
Assignee: (unassigned) => Dustin Kirkland (kirkland)
--
excessive number of CLC sockets to the backend cause the system to stop
updating state
https://bugs.launchpad.ne
** Changed in: eucalyptus (Ubuntu)
Status: Triaged => In Progress
** Changed in: eucalyptus (Ubuntu)
Assignee: (unassigned) => Dustin Kirkland (kirkland)
--
SYSTEM mode, instances do not run
https://bugs.launchpad.net/bugs/430957
You received this bug notification because you are a m
** Changed in: eucalyptus (Ubuntu Karmic)
Assignee: (unassigned) => Dustin Kirkland (kirkland)
** Changed in: eucalyptus (Ubuntu Karmic)
Status: Triaged => In Progress
--
if apache2 is using worker MPM, rampart causing periodic CC segfaults
https://bugs.launchpad.net/bugs/436407
You
** Changed in: eucalyptus (Ubuntu Karmic)
Status: Triaged => In Progress
** Changed in: eucalyptus (Ubuntu Karmic)
Assignee: (unassigned) => Dustin Kirkland (kirkland)
--
over time, c3p0 causes deadlock condition in CLC (database borkage)
https://bugs.launchpad.net/bugs/436885
You re
** Changed in: eucalyptus (Ubuntu Karmic)
Assignee: (unassigned) => Dustin Kirkland (kirkland)
** Changed in: eucalyptus (Ubuntu Karmic)
Status: Triaged => In Progress
--
Eucalyptus restart is needed after autoregistration of components
https://bugs.launchpad.net/bugs/439251
You rece
Is it possible that, at some point, a walrus registration was attempted
with 'localhost'? If so, you'll need to deregister walrus:
euca_conf --deregister-walrus
and try registering again with a valid public IP. This error is
implying that the system believes that a registered walrus lives on
12
Public bug reported:
It looks like the libvirtd daemon is leaking file descriptors to the
logfile that it sets up for each VM. I've attached a typescript showing
the symptom (start vm, inspect lsof, stop vm, inspect lsof, start vm,
inspect lsof, stop vm, inspect lsof), note that the descriptors
r
** Attachment added: "libvirtd-issue.tgz"
http://launchpadlibrarian.net/32683674/libvirtd-issue.tgz
** Also affects: eucalyptus (Ubuntu)
Importance: Undecided
Status: New
** Tags added: eucalyptus
--
libvirtd is leaking file descriptors to /var/log/libvirt/qemu/.log
https://bugs.l
Public bug reported:
When installing a UEC node (from server iso 09272009.1), I'm finding
that the bridge device that is defined in /etc/network/interfaces never
comes up on machine boot. contents of /etc/network/interfaces looks
correct:
---
# This file describes the network
all, here is as much information as I could think of in an attempt to
allow for reproducability (see attached file). Here is what each file
in the attached tarball contains:
setup - quick description of machine set up
orig.libvirt.xml - the XML vm description that is passed to libvirt
kvmcmdline
all, here is as much information as I could think of in an attempt to
allow for reproducability (see attached file). Here is what each file
in the attached tarball contains:
setup - quick description of machine set up
orig.libvirt.xml - the XML vm description that is passed to libvirt
kvmcmdline
I think there may be some confusion here; the original bug, as we
understood it, was that an administrator could not add a user unless
email was configured and working properly (i.e., every addition of a
user required the system to send an email to the user, for the user to
repond, and for the admi
This issue was resolved in Eucalyptus revnos 754-758, which addressed
multiple register/de-register issues (and, reduced the verbosity level
of the output from euca_conf, which can be brought back with the
--verbose flag :)
--
SOAP error when running "euca_conf --deregister-walrus"
https://bugs.l
This issue was resolved in Eucalyptus revnos 754-758, which addressed
multiple register/de-register issues.
--
euca_conf --register-sc returns success even though it fails
https://bugs.launchpad.net/bugs/431832
You received this bug notification because you are a member of Ubuntu
Bugs, which is s
This issue was addressed in Eucalytpus revno 768, and as such should
already be in latest karmic package (854)
** Changed in: eucalyptus (Ubuntu)
Status: Confirmed => Fix Released
--
Invalid S3_URL and EC2_URL in eucarc
https://bugs.launchpad.net/bugs/429734
You received this bug notifica
This problem is fixed in eucalyptus 1.6 revnos >= 760
--
In MANAGED mode, with CLC and CC on same host, on first boot of CLC, Walrus URL
is detected as 169.254.169.254
https://bugs.launchpad.net/bugs/385435
You received this bug notification because you are a member of Ubuntu
Bugs, which is subs
** Also affects: eucalyptus/1.6
Importance: Undecided
Status: New
** Changed in: eucalyptus/1.6
Status: New => Fix Committed
** Changed in: eucalyptus/1.6
Importance: Undecided => Critical
--
SYSTEM mode, instances do not run
https://bugs.launchpad.net/bugs/430957
You receiv
** Changed in: eucalyptus/1.6
Importance: Undecided => Medium
** Changed in: eucalyptus/1.6
Status: New => Confirmed
--
'eucarc' in downloaded credentials zipfile does not contain 'EC2_USER_ID'
https://bugs.launchpad.net/bugs/426389
You received this bug notification because you are a
** Changed in: eucalyptus/1.6
Status: New => Fix Committed
--
over time, c3p0 causes deadlock condition in CLC
https://bugs.launchpad.net/bugs/436885
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubu
If anyone can reproduce this issue, we'll need the logfiles:
/var/log/eucalyptus/cloud-*
in order to diagnose the core issue.
Thank you
--
500 server error when attempting to register ramdisk image
https://bugs.launchpad.net/bugs/428188
You received this bug notification because you are a memb
fixed in revno 892
--
Part of storage controller setup that should run as the eucalyptus user runs as
root
https://bugs.launchpad.net/bugs/436276
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@l
fully addressed in revno 593
** Also affects: eucalyptus/1.6
Importance: Undecided
Status: New
** Changed in: eucalyptus/1.6
Status: New => Fix Committed
** Changed in: eucalyptus/1.6
Importance: Undecided => High
--
SC registration through web UI fails
https://bugs.launchp
82.984011] sym1: <895a> rev 0x0 at pci :00:06.0 irq 10
> [ 1482.989722] sym1: No NVRAM, ID 7, Fast-40, LVD, parity checking
> [ 1482.992017] sym1: SCSI BUS has been reset.
> [ 1483.001733] scsi6 : sym-2.2.3
> r...@10:/lib/modules#
> ----------
1 - 100 of 160 matches
Mail list logo
