Known Issues

This topic lists known issues in Eucalyptus 4.2.1 and its dependencies.

Please contact Eucalyptus Support for known workarounds to these issues.

New known issues for this release:

Issue	Description
Security group rules using instances Public IP are not enforced in MANAGED mode (EUCA-11476)	Security group rules are enforced in the FORWARD chain, which is processed before POSTROUTING (where SNAT happens). Thus, security group rules that use instances public IP addresses will not match in FORWARD chain (packets will have instances' private IP address in the FORWARD chain). See linked bug for more information.
Instance Migration Fails when SELinux is enabled and is in Permissive mode (EUCA-11803)	Instance migration fails when SELinux is enabled and is in permissive mode. Workaround: Disable SELinux and reboot the system. For example: # vi /etc/selinux/config SELINUX=disabled # reboot

Issue

Description

Security group rules using instances Public IP are not enforced in MANAGED mode (EUCA-11476)

Security group rules are enforced in the FORWARD chain, which is processed before POSTROUTING (where SNAT happens). Thus, security group rules that use instances public IP addresses will not match in FORWARD chain (packets will have instances' private IP address in the FORWARD chain). See linked bug for more information.

Instance Migration Fails when SELinux is enabled and is in Permissive mode (EUCA-11803)

Instance migration fails when SELinux is enabled and is in permissive mode.

Workaround: Disable SELinux and reboot the system. For example:

# vi /etc/selinux/config
SELINUX=disabled
# reboot

Outstanding known issues from previous releases:

Issue	Description
Cloud restart necessary when removing public IPs (EUCA-9326)	While running TEST-1905 for edge mode, it was discovered that removing a public IP requires a cloud service restart while adding public/private IPs, removing private IPs and changing the subnet does not require a cloud service restart.
Internal loadbalancer is not functional (EUCA-11324)	In VPC, an internal load balancer has ELB instances that is in a private subnet without a public IP. That instance cannot reach ELB service to retrieve information on the ELB, update its status, etc., without configuring a NAT instance in the VPC. Workaround: None at this time.
Non-default security group for ELB/VPC blocks ports for ELBs (EUCA-11374)	In VPC, all egress ports for non-default security groups are blocked. When the non-default security group is used with the ELB, the ELB will not be functional until the required ports are opened. Workaround: Use Euca2ools to run the following commands to authorize each of the egress ports (TCP:8773 (Web service), UDP:53 (DNS), and UDP:123) for the non-default security group: euca-authorize --egress -P tcp -p 8773 -s 0.0.0.0/0 sg-f3a511c4 euca-authorize --egress -P udp -p 53 -s 0.0.0.0/0 sg-f3a511c4 euca-authorize --egress -P udp -p 123 -s 0.0.0.0/0 sg-f3a511c4
euserv-describe-services with secure http endpoint results in python2.6 InsecureRequestWarning. (EUCA-11519)	When an administrator uses HTTPS and doesn't enable certificate verification, running any command thereafter, will display the InsecureRequestWarning message. Workaround: Use a valid certificate and set `verify-ssl` = `true` in the region's configuration, or use plain HTTP.
ELB access logs collection fails when logs prefix contains an uppercase letter (EUCA-11524)	Uppercase characters in a path is invalid, resulting in an eror. Workaround: Specify the prefix with lowercase characters.
Unable to launch EBS instance or delete volume when launched in different zone than created. (EUCA-10697)	See linked bug for more information.
Failed EMIs from CreateImage might leave behind orphaned snapshots (EUCA-11184)	Use `euca-describe-images` to see if the EMI associated with CreateImage has a `failed` status. If any failed, then: Use `euca-describe-snapshots` to find any snapshot IDs associated with the failed CreateImage EMI ID. The snapshot description includes the EMI ID and Instance ID. Note that the snapshot state can be `failed` or `completed`. Workaround: The cloud administrator and/or cloud user (with proper IAM access to the account's snapshots) can simply delete any orphaned snapshots.