** Changed in: euca2ools
Assignee: (unassigned) = Mitch Garnaat (mitch-garnaat)
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to euca2ools in Ubuntu.
https://bugs.launchpad.net/bugs/850196
Title:
euca-describe-images crashed
** 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
** 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
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
Server Team, which is subscribed to eucalyptus in Ubuntu.
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.
** Changed in: eucalyptus
Assignee: (unassigned) = Daniel Nurmi (nurmi)
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to eucalyptus in Ubuntu.
https://bugs.launchpad.net/bugs/742443
Title:
cc looses database information after
** 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
--
ubuntu
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
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
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):
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,
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
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):
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,
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
** Changed in: eucalyptus
Assignee: (unassigned) = chris grzegorczyk (chris-grze)
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to eucalyptus in ubuntu.
https://bugs.launchpad.net/bugs/731702
Title:
euca-add-user adds a new
** Changed in: eucalyptus
Status: Incomplete = Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to eucalyptus in ubuntu.
https://bugs.launchpad.net/bugs/470355
Title:
ec2-bundle-vol and ec2-upload-bundle result in
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
Server Team, which is subscribed
** Changed in: eucalyptus
Status: New = Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to eucalyptus in ubuntu.
https://bugs.launchpad.net/bugs/476619
Title:
Networking problem in Eucalyptus when VNET_PUBLICIPS has an
** 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
** 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
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
** 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
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
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
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
** 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
Server Team, which is subscribed to eucalyptus
** 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.
https
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
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
** 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
** 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
Server Team, which is subscribed to eucalyptus in ubuntu.
--
Ubuntu-server-bugs
** 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
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
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
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
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
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
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
** 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 member
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
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
Server Team, which is subscribed to eucalyptus in ubuntu.
--
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:
** 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 member
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
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
** 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 Ubuntu
** 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 notification
** 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 Ubuntu
** 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 notification
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
Server Team, which is subscribed
** 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
Server Team, which is subscribed to eucalyptus in ubuntu.
--
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
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
** 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
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
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
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
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
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) = Daniel
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) = Daniel
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',
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',
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
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
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
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
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
Server Team, which is subscribed to eucalyptus
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
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
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,
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
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
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.
--
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
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
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,
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
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
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
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
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
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
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
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
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.
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.
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
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
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
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
300 seconds is the lowest value that can be set for both IDLE and WAKE;
in your 'cc.log', you should see a warning;
POWER_IDLETHRESH set too low (60 seconds), resetting to minimum (300
seconds)
We're trying to be conservative, in order to avoid the condition where
the CC starts putting nodes to
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
** 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
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
** 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
Server Team, which is subscribed to eucalyptus in
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)
** 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
1 - 100 of 276 matches
Mail list logo
